[Sis-csi] Green book thoughts

[Scott Burleigh]

Keith Hogie wrote:

> More thoughts about Keith Scott, and Scott Burleigh's comments
> inline below.
>
> Scott Burleigh wrote:
>
>> Scott, Keith L. wrote:
>>
>>> Keith,
>>>
>>> I've integrated most of this into the document, but I have a few issues
>>> inline.
>>>
>>>> -----Original Message-----
>>>> From: sis-csi-bounces at mailman.ccsds.org 
>>>> [mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
>>>> Sent: Thursday, March 30, 2006 12:48 PM
>>>> To: sis-csi at mailman.ccsds.org
>>>> Subject: [Sis-csi] Green book thoughts
>>>
>>>> 4.4 Automated Data Forwarding
>>>>
>>>>  Not sure if the SLE reference really fits here.  That is a
>>>> reference to the old circuit switch concept and not routing
>>>> based on addresses in packets.  SLE doesn't do IP packet
>>>> forwarding and doesn't apply in an end-to-end IP architecture
>>>> does it
>>>>   
>>>
>>> I think the data forwarding part of SLE here (as opposed to the service
>>> management part) is just a tunneling mechanism like GRE.  Its inclusion
>>> allows the space (data) link protocol to be terminated somewhere else
>>> besides the ground station.  That's how many agencies are set up to
>>> operate now, and they'll probably continue with it until they can get
>>> equipment at the ground stations to terminate the space data links AND
>>> something to provide reliability, or ate least comprehensive data
>>> accounting.
>>
> SLE is not really like GRE.  GRE operates at the network layer
> as part of the packet routing process and simply forwards packets
> one-by-one.  SLE is a tunnel operating above the transport layer
> and has TCP acknowledgments.  It also is related to the legacy
> "circuit" concept where there is only one hop beyond the ground
> station.  At the last SCAWG there was a discussion about being
> able to forward data received with errors.  You can do that with
> SLE but it only applies to the first hop from the ground station.
> If packets are forwarding across multiple space links based on
> IP addresses, you cannot forward errored data.  At some point we
> need to decide if we are moving to packet forwarding or staying with
> the circuit model.

We probably don't have to make a decision between one or the other.  
There's no real reason the infrastructure can't support both, if 
missions are willing to pay for both.

Suppose what you're transmitting is CFDP PDUs wrapped in UDP datagrams 
in IP packets, within AOS frames.  When the ground station receives one 
such AOS frame it can either (a) extract the IP packet from the frame 
and forward it (acting as an IP router) or else (b) simply copy the 
frame (acting as a repeater) onto a TCP/IP connection to a mission ops 
center [that is, SLE], where upon receipt the IP packet is extracted 
from the frame and forwarded -- i.e., the IP router is at the MOC rather 
than at the station.  You've got an AOS "circuit" and an IP router in 
either case; it's just a question of where you terminate the circuit and 
where you place the router.

> There are already many stations that forward IP packets directly
> and things like "reliability" and "data accounting" are not a
> problem.  The concept of "networking" in space means that some
> of the legacy notions of moving data over a single link from
> the control center to a spacecraft need to change.  A packet
> forwarding model has some significant differences from the
> current circuit model.

I suspect the reason "reliability" and "data accounting" are not a 
problem in these cases is that missions have chosen not to worry about 
them, since IP won't provide them anyway.  That is very likely the right 
model, but it will remain a mission choice so long as missions are in 
the driver's seat.  If we want to encourage that model, we'll need to 
convince the missions that we've got an alternative way of providing 
comparable performance -- here, completeness of data.

Missions that have got zero interest in completeness of data return will 
of course be somewhat easier to convince.  Probably part of the 
difference in our views here is that JPL has had very few such missions, 
while I gather from what you say below that Goddard has had a good 
many.  I suspect that's why we come to such different conclusions about 
the utility of just providing UDP/IP service and letting the 
applications worry about everything else.

>>>> 4.6 Transport layer
>>>>
>>>>  --- insert after first paragraph ---
>>>>
>>>>  UDP provides a data delivery very similar to standard
>>>> TDM and CCSDS packet delivery systems that are currently
>>>> used for space communication.  It's unreliable delivery
>>>> attribute means that it does not utilize any process,
>>>> such as acknowledgments, for determining if the data
>>>> gets to its destination.  Reliable delivery can be
>>>> implemented over UDP in the application layer if desired
>>>> with applications such as CFDP.  
>>>
>>> This is true, but I don't want to give mission software people the
>>> impression that they can just hack up reliability on a per-application
>>> basis.
>>
> But mission people can do whatever reliability they want on
> a per-application basis.  That is one of the great features
> of layers and the Internet.  The only people that need to agree
> on an end-to-end reliable transfer protocol are the two end systems
> (e.g. satellite and control center).  On the current Internet there
> are all sorts of different reliable data delivery options that
> co-exist.  They are both TCP and UDP based.
>
>> Absolutely.  That would be a serious blow to interoperability and 
>> low-cost mission software development, just as abandoning TCP in the 
>> terrestrial Internet would be.  A huge step backward.
>
> The big interoperability comes from using IP everywhere and does
> not require TCP at all.  The Internet has both TCP and UDP
> traffic flowing over it all the time.  Things like voice and video
> and my son's Game Boy use UDP for all sorts of streaming operations.
> TCP is the wrong answer for many data flows.  We don't want to
> abandon TCP but we also cannot mandate only TCP.  All current
> space missions operate in a UDP-like mode and there are many good
> reasons for that.

All current deep space missions have operated in a UDP-like mode (with 
manually commanded retransmission as necessary) up until Deep Impact and 
MESSENGER, which use the standardized retransmission protocol provided 
by CFDP rather than mission-specific retransmission procedures.  One of 
the principal reasons for that was perhaps the absence of any alternative.

Maybe all current near-earth missions also operate in a UDP-like mode, 
for which I would guess there are many good reasons.  But TCP/IP 
apparently works fine over near-earth space links, so the absence of any 
alternative would not seem to be one of those reasons.

>>>  CFDP is sort of a special case and I'm not sure how well even
>>> it would play in a mixed envrionment (that is, I'm not sure if CFDP
>>> implements TCP-friendly congestion control).
>>
>> It does not.  There is no congestion control in the CFDP design.
>
> I don't see CFDP as a special case.  That is exactly the mode that
> lots of missions want to use and will continue to use.  It works
> very well for space communications across a dedicated RF link.  I
> realize that UDP file transfer mechanisms have potential for
> flooding a network and that CFDP does not specify any flow control.
> But missions do have a very strong flow control in that they
> have a fixed upper limit on their RF transmission rate.

Sure.  But flow control is different from congestion control.  So long 
as we don't have a true network, but only pairwise links between 
spacecraft and their ground stations, we have got no routers and 
therefore can have no congested routers.  When we start deploying a 
real, honest-to-gosh network in cislunar space, that will probably change.

> When a satellite turns on its power hungry transmitter,
> it wants to be able to fill the RF link with data and does not
> want to worry about flow control by any protocol.  Especially
> any protocol that might require a two-way link.  The bandwidth
> of the link has been set during mission design and the software
> wants to allocate it among things like housekeeping data and
> science data.  Satellites do not operate in a highly interactive
> or whimsical nature like people surfing the Internet.  They
> have much more highly planned and predictable data transfers.

Sure, we've done things that way for many years.  I don't think you'll 
be able to extend that model to in-space routers in a cost-effective 
manner, though.

> Also, as propagation delays get longer, it becomes even more
> important to use UDP based protocols because you cannot get
> any interactive flow control information.  Also with the current
> high downlink rates and very low uplink rates UDP works much
> better to allow missions to shove data down and not need to
> have ACKs coming back up.  Things like TDRSS demand access are
> another reason for using UDP.  DAS only gives you a one-way
> link so you have to use something like CFDP over UDP.

Yes, TCP breaks down.  That's exactly why we've been putting so much 
thought into the DTN architecture, which is designed to give users 
comparable service in a standardized, reusable, scalable infrastructure 
for operations over these problematic links.  The point is to save the 
space program money by not requiring every mission to roll their own 
non-interoperable custom solutions to these problems.

Scott