[Sis-uce] Thoughts?

[Scott Burleigh]

At 10:23 AM 5/13/2003 +0100, Massimilano.Ciccone@esa.int wrote:

>Hi CFDP folks,
>I've carefully read the UCE concept paper and I have the following comments
>to make:
>
>    I agree with the implementation of a periodic re-examination of the
>    unfinished transaction upon receipt of EOF(No Error).
>    I do not agree with issuing a protocol error upon "Check Timer
>    Expiration". This goes against the nature of CFDP Unacknowledged
>    procedures, where a Notice of Completion (Completed) is issued upon
>    reception of an EOF(No Error) PDU, regardless the completeness of the
>    received file.

Yes, this would be a change in the nature of Unacknowledged transaction 
completion.

>    I propose NOT to introduce a new error code and to issue a Notice of
>    Completion(Completed) in any case (also after the Check Timer expired n
>    times). This would make things much coherent and easier for implementers
>    (unless there is a precise need in declaring an error in case the received
>    file is uncomplete)

I think the need you mention is a key issue.  If the Nth expiration of the 
Check Timer resulted in a Notice of Completion (Completed), then the burden 
of checking the completeness of the file would fall on the application: the 
resulting Finished (No error) indication would be ambiguous, just as in 
fact it is now.  Raising a Fault would remove the ambiguity and give 
mission operators somewhat better control of transaction processing.

You could, of course, do essentially the same thing in the user 
application.  The advantage of building it into the CFDP Recommendation 
itself would be standardizing this behavior so that it doesn't have to be 
re-implemented in every user application.

>    The use of the "Check Timer" could also be triggered by a flag field in
>    the header in order to allow backward compatibility with respect to
>    current CFDP implementations.

You're right, Max, but I think that would actually increase, rather than 
reduce, the impact of this change on implementations.

As proposed, the UCE modification would only affect the receiving entity in 
an Unacknowledged transaction.  All of the changes would be in the service 
interface, with no effect on protocol traffic at all.  An implementation 
that omitted the modification would, as a sender, be indistinguishable from 
one that did not; as a receiver it would of course be backward compatible 
with existing user applications, because its behavior would be unchanged 
from the current standard, and remote senders would be unaffected.

Adding a flag field in the PDU header would entail modifying every sender 
as well, introducing much more serious interoperability concerns.  And it's 
not clear how the sender would know how to set this flag in order to 
produce the behavior desired at the receiver.  Let's please not do that!

Scott