What are we trying to do?

["Marie-Jose Montpetit" <vze2prqh@verizon.net>]

I've been following the list for quite a while. The discussions are great
but I worry that we are forgetting a bit what we are trying to achieve here.
Especially, if we want to submit this to the transport people in the IETF,
we need so know exactly what the result of our WG will be. I tend to agree
that changing a standard for a trickle of improvement is not worthwhile. If
this small improvement however comes with a lot of added flexibility and
added interworking with other people then great!

So here is my shopping list of requirements/questions to ask ourselves.
Maybe this will evolve in a requirements ID so feel free to trash.

1. What satellite network  topology are we talking about
seems an idiotic question but I think some of the discussion we have had on
the use of PIDs and connectionless/connection oriented is related to the
overall topology; where are the switches/routers, are the PIDS rewritten
anywhere?
I can think of a few basic architectures:
- standard bentpipe with gateways: the users are "hidden" behind the
gateway; really the easy architecture and the ones I suppose favored by the
original broadcasters; in this really there is one fat pipe
- multiple gateways - more interesting since then you can get in mux/demux
issues and multicasting; this scales to the case where you have meshed
terminals that act one side as satellite gateways and the other as routers;
cute issues of return channel and satellite to MAC to IP addressing; the IP
DVB people have looked at that a lot when Patrick Schnell was there.
- meshed topology with onboard processing - much more addressing challenges!
Switching onboard creates interesting questions for the use of DVB; BTW the
usual "VC" is to link an uplink cell to a downlink beam in essence creating
a satellite switching from uplink to downlink (hence my question on
re-writing PIDs on board)
there are probably other architectures and variants of the above... the
DVB-T people may have other topologies...
2. What services are we transporting?
The discussion this morning about IPv6 was interesting... I think the
services should be looked into more closely than just unicast-multicast.
Satellites can be used for many things and if we want to be part of the
mobile-ip infrastructure then IPv6 is a requirement... But is it? I think we
need a list of things we will transport and to go a bit beyond the usual VBR
traffic for multimedia... Also it would help define what we need in terms of
QoS and availability of the service - a big thing as you know if you go Ka
band
3. Where are the users?
If we do not have direct access to the end users then we should look
carefully at addressing and not make it overly complicated. I have the
mentality that the routers above us are fast at IP routing and cheap and we
should not try to do their jobs; also filtering on too many addresses could
be interesting in another way: are we going to have a satellite-BGP-like
architecture?
4. Where are we in the stack?
We seem to discuss disparately about link, MAC, network... I suppose the new
encapsulation would be both link and MAC; the Internet works so maybe we
want to leave the upper layer alone except in terms of intercepting QoS?
5. QoS
How are we going to use TOS or RSVP or whatever NSIS comes up with (are we
monitoring them?);  do we want to do inband or out of band signaling/setup
ahead a flow?
6. Related to above: end to end delay
We need a delay budget that includes the end to end: modulation, coding etc.
not just segmentation. Then we may find that
for certain VBR services that have tight jitter requirements sending a 1/2
empty packet is the only way to meet the QoS. Yes wasted bandwidth but added
revenues...

I think I could go on forever... Could be fun to see what the DVB-T and even
the cable people have to say. Also the people on commercial implementations,
speak up! The new encapsulation should enable new services yes but also I
suppose increased revenues somewhere.

BTW about the IPR issues: there are patented protocols in the Internet (Real
and RTSP I think for example) and tag switching and MPLS probably have
specifics patented by one company or another.

Sorry for this long email. I've been off for a long time (maybe that was a
good thing?).

Marie-Jose
marie@mjmontpetit.com