[Sis-csi] Green book thoughts

[Scott Burleigh]

Lee.Neitzel at EmersonProcess.com wrote:

> As you know, there are significant fixed and variable costs associated 
> with design, implementation, testing, and deployment of each layer 
> protocol.
>
In my mind, this is the key point in this discussion.

Keith H. is clearly right that UDP is entirely entirely appropriate for 
applications where data completeness is not important.  He's also 
clearly right that UDP and UDP-like transmission has historically been 
used for operations of nearly all spacecraft mission (that I can think 
of), where all communications have been between The Spacecraft and The 
Ground.  I agree with him and with David that the simplicity of that 
model in that environment has proven to be very valuable, even though it 
means that -- if you care about data completeness -- you need some sort 
of manual command procedure to effect the retransmission of data that 
got lost or corrupted in transmission from the spacecraft to the ground.

The question, I think, is whether or not that model is appropriate for 
communications among the elements of a cislunar network, such as the 
fleet of Constellation vehicles.  The topology we're contemplating in 
that environment would not be pairwise communication between The 
Spacecraft and The Ground, but rather multi-hop communication through 
relays (e.g., relay satellites) functioning as IP routers.

Again, if data completeness is not important then UDP is perfectly 
adequate for conveying data throughout that network.  But if data 
completeness is important some of the time, then one or more 
retransmission mechanisms are needed in the protocols; I haven't yet 
heard anyone suggest that manually commanded retransmission would be a 
cost-effective way of assuring completeness of data exchange among 
multiple surface rovers and orbiters at the moon.

As Lloyd points out, UDP is a terrific platform for building new 
protocols on: it imposes little overhead, it does message delimitation, 
it provides port numbers for multiplexing of higher-layer protocols, it 
provides checksums (if you want them), and the standard socket library 
makes implementation very straightforward.  But there are significant 
fixed and variable costs associated with the design, implementation, 
testing, and deployment of each layer of protocol.  I would say that's 
particularly true of protocols that do retransmission, which if done 
well is not as easy as it sounds.  This suggests that if an existing, 
proven transport protocol provides retransmission then you should use it 
rather than reinvent retransmission yourself, unless you've got a good 
reason not to.

I think we all agree that there are some good reasons not to use TCP in 
all cases where you need a retransmitting protocol, so there are clearly 
cases where it makes more sense to use something else -- very likely 
something built on top of UDP, because UDP is such a fine platform for 
building new protocols on.  But it remains true that each such new 
protocol costs money.  If retransmission were reinvented in every 
application-layer protocol flown on every spacecraft:

a.    Each one would impose significant additional mission cost.

b.   Some of them would have bugs that wouldn't be found in testing 
prior to flight, imposing significant additional mission risk.

c.   None of them would be interoperable.  In order to interoperate, 
spacecraft would have to fly multiple protocols at this layer of the 
stack, further increasing mission cost and complexity (and therefore risk).

d.   Each one would pose a potential congestion threat to the network 
since, as experience in the Internet has shown us, retransmission 
procedures that aren't carefully designed with congestion in mind will 
increase it.  And congestion will indeed be possible, because this is a 
network, with routers and "trunk lines", and not just a set of pairwise 
communication links.

So in this architecture document I think we want *not* to encourage 
every flight software manager to look at each mission as yet another 
opportunity to demonstrate what fools the designers of TCP were.  The 
architecture needs to support the insertion of alternatives to TCP where 
they are needed, but the fewer the better.  Suppose we leave it at that?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20060419/8e3cd7e8/attachment.html