[Sis-csi] Green book thoughts

[Ed Criscuolo]

(I inadvertently replied this to Scott instead of
posting it to the list this morning, so I'm resending
it)

I think we're mostly in violent agreement. The language
semantics are just getting in the way.

The network folks are counting from the bottom up: Whatever is
three layers up from the physical is THE Transport layer.
Anything above that, like CFDP, is application.

The application folks are counting from the top down: Whatever
is one layer down from the application is THE transport layer.
In this view, CFDP is transport.

Note that nothing has changed, were really just argueing over
what to call it.

Nobody is suggesting that retransmission be a custom non-standard
application, "... reinvented in every application-layer protocol
flown on every spacecraft." That has obvious cost and
interoperability impacts.  We need to have a standardized set of
recommendations, regardless of whether we call them "Transport
Protocols" or "Application Services".  The idea is that you can't
afford to "re-invent the wheel" every time.  We want to use
existing stuff, not create it from scratch.

Note that this approach includes both formal standards, such
FTP/CFDP/NORM, and de-facto standards, such as SKYPE and REAL.


Ed

----------------

Scott Burleigh wrote:

 >   Lee.Neitzel at EmersonProcess.com 
<mailto: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
 >
 >
 > ------------------------------------------------------------------------
 >
 > _______________________________________________
 > Sis-CSI mailing list
 > Sis-CSI at mailman.ccsds.org
 > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi


Scott Burleigh wrote:

> Chris.Taylor at esa.int wrote:
> 
>> This is one of the more interesting discussions that has been 
>> generated by
>> group and there is another aspect related to retransmission that has 
>> not been
>> touched upon. From what I have seen over the years ( I work in the 
>> area of
>> flight system design), ground controllers are extremely careful and  
>> hesitant
>> when it comes to releasing commands to the spacecraft. Automated 
>> sequences
>> are anathema and there is still a clear preference to release each 
>> command by
>> hand. I guess this practise is easily understood when it is considered 
>> that a
>> single incorrect command could result in the unrecoverable loss of  
>> remote
>> hardware.
>>
> You are certainly right, Chris, but I would suggest that this is 
> something of an artifact of history.  In the past, the only bits we ever 
> sent to spacecraft were commands, so it was true that any uplink had the 
> potential to crash the spacecraft.  Automated retransmission protocols 
> are different: positive and negative acknowledgements are not commands 
> and (unless your protocol implementation is inexcusably poorly written 
> and tested) they won't ever crash a spacecraft.
> 
>> Some may argue that this is even more reason for relying on
>> automated software but as this is also hand crafted and subject to 
>> bugs, I
>> believe the "man in the loop" aspect will remain important part of 
>> spacecraft
>> control.
>>  
>>
> There is a persistent fallacy here, I think.  There are clearly critical 
> spacecraft operational decisions that should only be made by humans 
> exercising informed judgement.  There are, just as clearly, routine 
> operational decisions that have got to be made by on-board software, 
> either because the control loop through a human would be too long to 
> enable timely response or because there are just too many of them to 
> make manually in a cost-effective way.  The latter require that software 
> be written and tested with great care, but however well that work is 
> done you are going to rely on it; you've got no real choice.  If there 
> are bugs, you fix them and *re-use the corrected software in the next 
> mission instead of starting over again so that new bugs can be 
> invented*.  But bugs in software, once soundly corrected, can never 
> recur.  Human errors shouldn't, but always can and sometimes do.
> 
>> This is backed up here by the slow take-up of CFDP. I still remember the
>> faces of horror when I made the original proposal for CFDP to our revered
>> CCSDS management council. The flight systems guys were in favour but the
>> support from the ground system institutions was miserable and it was 
>> treated
>> somewhat with disbelief that someone was suggesting automatic 
>> retransmission
>> to and from a spacecraft. So far we do not have a CFDP implementation 
>> on any
>> ESA spacecraft and even though the take up from NASA has been more 
>> positive,
>> I'm pretty sure that only the connectionless procedures have so far been
>> implemented.
>>  
>>
> Not true, actually.  The acknowledged procedures of CFDP were routinely 
> used for command sequence upload to the Deep Impact spacecraft and are 
> used every day for engineering telemetry download from MESSENGER.  
> What's more, the CFDP acknowledgements sent from the ground system to 
> the MESSENGER spacecraft are issued automatically, without operator 
> intervention, just as intended in the CFDP design.
> 
>> It should also not be forgotten that CCSDS packet telecommand has 
>> supports
>> ARQ for  in the form of the COP procedures ( basically HDLC). Here ESA 
>> has
>> taken a lead and for years, due to a standard ASIC, all our spacecraft 
>> have
>> had the opportunity to use retransmission on the forward link. Two 
>> points are
>> however worthy of note: in a typical mission retransmission has not been
>> triggered; if it has been triggered there was significant effort to 
>> find out
>> why. In reality, this comes down to the links that are used. The 
>> forward link
>> is typically over-engineered to cover contingency situations (we also 
>> have
>> enough power on the ground to fry fish and clips onboard), and the return
>> links are so well coded that data loss hardly considered.
>>
>> I guess one message from this is that we should be looking at the link
>> characteristics before deciding what is necessary higher up in the 
>> stack. If
>> our links are near on perfect occasional data loss due to link errors 
>> could
>> be acceptable and errorrs (e.g. due to SEUs in the flight system) can be
>> covered by application level checksum.
>>  
>>
> Sure.  Or techniques like erasure coding can even recover lost or 
> corrupted data without retransmission, if there's not too much loss.
> 
>> On the question of congestion, I still believe that the mission 
>> preplanning
>> will counteract the lack of overall bandwidth. The idea that data 
>> transfer
>> will not have a major element of preplanning doesn't make much sense if
>> crucial or mandatory data transmission is to be protected. Presumably
>> automated tools will be available to determine what each element needs to
>> transmit and in what time frame, so it should be easy enough to ensure 
>> that
>> the bandwidth is available when it is needed. It is also simple enough to
>> implement rate control for unbounded transfers such as file transfers. 
>> We are
>> already using this technique in the Columbus element of ISS where the
>> ethernet Lan is shared by several payloads and the Columbus system. We 
>> simply
>> slug the packet (UDP) release rate for each payload so that the maximum
>> allocated bandwidth is never exceeded. The release rate being 
>> configurable as
>> part of the mission timeline.
>>  
>>
> Right, you've got to have rate control, and contacts are going to be 
> scheduled (possibly automatically) for a number of reasons.  But I would 
> say that congestion control in this context is more a question of buffer 
> overrun (resulting in data loss) rather than lack of bandwidth, and in a 
> truly networked communication environment you do have to worry about 
> that at routers.  Sure, we're not facing any problem remotely like this 
> at the moment.  But in a denser and more richly interconnected cislunar 
> network environment I believe it will matter.
> 
> We don't have to predict the future accurately right now in order to 
> settle the main question, though.  I think we just want to say that we 
> know UDP support will be necessary, we think it's possible that support 
> for TCP will be necessary in some contexts, we agree that other non-TCP 
> mechanisms for assuring data transmission completeness may be necessary 
> as well, but we agree that heedless proliferation of those mechanisms 
> would impose undesirable costs on the space flight community.
> 
> Scott
> 
> 
> _______________________________________________
> Sis-CSI mailing list
> Sis-CSI at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi