[Sis-uce] Suggestion for CFDP (add EOF-Received Indication)

[Krupiarz, Christopher]

Max,

Tim can correct me, but I think based on his first email his example is
one-way only part of the time.  Those are good points regarding the Deferred
NAKs.

Since a protocol change should meet some threshold and for the sake of
discussion, is there anything that would meet Tim's requirements but not
require a change to the protocol?  Tim, I'm sure you sure you considered
this, but how about just freezing the ground transactions until two-way
communication is available?  Is there a particular benefit to suspending the
transactions individually?

I think Scott makes a good point that if UCE breaks an implementation it
would be good to correct it.  However, whether the correction is done by
adding a new Indication or by modifying the source to correct the impact of
UCE, a code change would still be required.  Hence, I would suggest that not
be a driving factor but it is worth considering.

Chris


-----Original Message-----
From: Massimiliano.Ciccone at esa.int [mailto:Massimiliano.Ciccone at esa.int] 
Sent: Thursday, April 01, 2004 5:52 AM
To: Scott Burleigh; Timothy Ray
Cc: sis-uce-bounces at mailman.ccsds.org; sis-uce at mailman.ccsds.org
Subject: Re: [Sis-uce] Suggestion for CFDP (add EOF-Received Indication)



Dear Tim and Scott,
I believe that what you are proposing here make sense, but only if we are in
presence of ACKNOWLEDGED transactions. This because, in UNacknowledged mode,
transaction always TERMINATE on receipt of EOF PDU anyway (issuing a
transaction.finished indication). Moreover, it would not make sense to use
the EOF.Received indication as explained in Tim's example if the link was
only one-way all the time. If we are going to use an EOF.Received indication
for triggering suspension of ACKNOWLEDGED transaction, then there are some
provision to make:
   The Transaction must be in "Deferred Nack" mode, to avoid the receiving
   side sending NACK PDUs before reception of EOF.
   The EOF.Received Indication shall report the condition code of the EOF
PDU

Looking forward to your comments

Max



 

                      Scott Burleigh

                      <Scott.Burleigh at jpl.na         To:
sis-uce at mailman.ccsds.org

                      sa.gov>                        cc:

                      Sent by:                       Subject: Re: [Sis-uce]
Suggestion for CFDP (add EOF-Received Indication)                           
                      sis-uce-bounces at mailma

                      n.ccsds.org

 

 

                      31/03/2004 21:02

 

 





At 02:14 PM 3/31/2004 -0500, Timothy Ray wrote:
      Hello all,

      I suggest that we:
         1) Add an "EOF-Received" Indication to CFDP
         2) Add an MIB parameter to enable/disable it
             ("EOF-Received.indication required?" "yes or no") My rationale:
   This Indication is useful for some mission scenarios; CFDP has the
information, why not make it available to the user?

Example of usefulness:
   The Global Precipitation Measurement mission is using CFDP.  Their link
is one-way (telemetry only) most of the time.  They blast files down during
the one-way link, and then enable the feedback loop during the two-way link.
The EOF-Received Indication allows the Receiver to suspend each transaction
upon receipt of an EOF PDU.  All transactions are then resumed at the start
of the two-way link.  (A similar mechanism on-board uses the EOF-Sent
Indication)


Scott wrote:
The relevance of this tweak to the Unacknowledged CFDP Extensions may not be
obvious, but I think it is real.  By turning off Notice of Completion
issuance on receipt of EOF in Unacknowledged mode when the file is not
completely received, UCE disables delivery of the Finished indication under
these conditions.  It is possible that some CFDP implementations might count
on that indication to signal EOF arrival in Unacknowledged mode (regardless
of file delivery completeness), for purposes similar to those Tim describes;
UCE would break those implementations.  By adding an optional EOF-Received
indication we could provide a replacement source for this information
without working too hard.

I definitely DO NOT want to open the door to casual reconsideration of CFDP
specification elements in general.  But I think the UCE revisions do
arguably motivate Tim's proposed mod, and I think the impact of the change
would be modest.  Let's discuss on this list and at the UCE working group
meeting in Montreal.

Scott_______________________________________________
Sis-uce mailing list
Sis-uce at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sis-uce






_______________________________________________
Sis-uce mailing list
Sis-uce at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sis-uce