[Sls-ngu] FW: CESG Poll for the three Proximity-1 books

Fri Mar 2 19:18:31 EST 2012

Dear NGU,

Below is a dialog I had with Keith Scott, SIS Area director, on his question concerning the 5-year Review copy of the Prox-1 Data Link Layer blue book.
Please read through this discussion and let me know if you have any comments concerning the proposed RID dispositions to those questions which I believe need to be turned into RIDs.  Below is my summary of 5 RIDs for consideration.
- Thanks Greg

Item 1: Note 2 in Section 4.3.2.2. The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the next. Elimination of this problem is left to the controlling data system.
Recommended Change: The mechanisms provided in this specification will not eliminate the possibility of duplicate data associated with the transition between the end of one session and the beginning of the next.

Item 2.  The section numbers around 4.2.5 -- 4.2.7 seem busted.  Maybe they should be:

4.2.5 MAC BUFFERS
4.2.5.1 SENT_TIME_BUFFER
4.2.5.1.1 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected.
4.2.5.2 RECEIVE_TIME_BUFFER
4.2.5.2.2 The RECEIVE_TIME_BUFFER shall store all of the ingress clock times, associated frame sequence numbers and QoS Indicator when time tag data is collected.

Tom to fix please.

Item 3.  6.2.2.1.1
It is unclear from the below when or if the receiver is powered on in half-duplex mode:

"...
b) connecting-T: In the Physical Layer, the Connecting-Transmit state in full duplex
shall dictate that the ***receiver (sequentially in half duplex)*** and transmitter are
powered on and enabled to process received frames, and that the transmitter is
enabled for asynchronous channel operations. (***In half duplex, only the transmitter is
powered on.***) The Hail Activity shall be conducted while MODE is connecting-T.

b) connecting-T: In this state the Hail Activity/Sequence is conducted. Applicable to both Full-Duplex and Half-Duplex operations. The Receiver is powered on through out this state. The Transmitter is powered on and off potentially multiple times during this Activity.

Item 4: 6.2.3.7  REMOTE_SCID_BUFFER
Are the tests mentioned done on reception or transmission?  It seems like this is trying to ensure that all frames are sent to the same destination spacecraft ID?
All tests are carried out upon reception.  I need to reference 3.2.2.9 here which lists all of the tests by the receiving node– we will make this a RID. This buffer is just a receptical for the value of the Remote_spacecraft_ID i.e., partnered node MIB parameter.
New Definition – REMOTE_SCID_BUFFER shall be used to hold the value of the Remote_spacecraft_ID of the partnered node. See 3.2.2.9

Item 5: 6.2.3.9  RECEIVING_SCID_BUFFER
"...or it may be loaded with the spacecraft ID contained in the first valid received frame." -- First of WHAT (I think 'first valid received frame of a new connection where the sourceOrDest parameter of the frame is DESTINATION' [since if the first valid received frame has sourceOrDestination set to source then the value of the SCID will be the transmitter -- or is this not possible?])?
Again, one has to interpret the S/D flag differently if one is the Sending node or the Receiving node.  Yes it is the initial valid received frame of a session.  However this refers to the optional test when S/D = SOURCE, since the test when S/D = DESTINATION is always made. See section 3.2.2.9 and section 6.2.4.2.  We accept some of the rewording as a RID – we will update with the wording "the initial valid received frame of a session" and in 6.2.4.2 as well.

End of Items.
From: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: Wed, 29 Feb 2012 16:15:39 -0800
To: "Scott, Keith L." <kscott at mitre.org<mailto:kscott at mitre.org>>, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: Thomas Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "Hooke, Adrian J (9000)" <adrian.j.hooke at jpl.nasa.gov<mailto:adrian.j.hooke at jpl.nasa.gov>>, "Greenberg, Edward (313B)" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>, "Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>" <Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>>, "Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>" <Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>>
Subject: Re: CESG Poll for the three Proximity-1 books

Keith,

If that’s the case, we’re done (though I still think the note is misleading).

In sessions that are "stiched together" in order to send a complete data set, the sending application has to pick a point in the data set to resume transmitting from. Depending how the first session ended and what termination mechanism in Prox–1 was chosen, the "sender"(master) may not be aware that the last frame(s) within the window were accepted by the "receiving node"(slave) because the acknowledgement for them was generated, transmitted, but never received by the master (went out of view). So when the master starts transmitting again in session 2, it may start with what it believes the last frame acknowledged was, which could be one or more frames that the other side already acknowledged.  So that's a simple example of how duplicates could be passed on without intervention by the controlling data system.  Again it's not Prox-1's job to solve this.

I think we can relook at the wording of the note and see if we can come up with something more precise. There is the possiblity of duplicate data being passed under that condition.

Thanks,

Greg

From: "Scott, Keith L." <kscott at mitre.org<mailto:kscott at mitre.org>>
Date: Wed, 29 Feb 2012 06:43:56 -0800
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Cc: Thomas Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "Hooke, Adrian J (9000)" <adrian.j.hooke at jpl.nasa.gov<mailto:adrian.j.hooke at jpl.nasa.gov>>, "Greenberg, Edward (313B)" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>, "Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>" <Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>>, "Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>" <Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>>
Subject: RE: CESG Poll for the three Proximity-1 books

Greg,

With respect to the following:
How do we reconcile 2.2.3.2:
The Sequence Controlled service ensures that data are reliably transferred across the space link and delivered in order, without gaps, errors, or duplications within a single
communication session without COP-P resynchronization during the session (see 4.3.2).
with Note 2 in section 4.3.2.2:
2 The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the
next. Elimination of this problem is left to the controlling data system.
GPC: they do not in conflict as there is guarantee within a session but not across session. It may be this should be highlighted somehow in section 2 too.

Is what you’re saying with note 2 “if the sending *application* (prox-1 user) injects duplicate data across a session boundary (perhaps as a result of transmitting a bit of ‘rewind’ to brute-force cover the break between two sessions?) then prox-1 will delivery duplicate user data?”  If that’s the case, I’d suggest rewording the note to be clear – not much Prox-1 can/could be expected to do in this case.  I’m getting this from your response below (my emphasis):
The bounds on duplicate data is not a function of Prox-1 but rather how much of a "rewind" the user plans to do if they are stitching Prox-1 sessions together by brute force. We eliminated the possibility of frame counter ambiguity in Prox-1 by limiting the window size N to 127. This is due to the duality of interpreting sequence counts whenever a rollover occurs using modulo arithmetic … in our case with counts greater than 127. Since the sequence counter is a mod 256 counter, there is no way for us to deal with unique sequence counter unless we limit N to 127.

If that’s the case, we’re done (though I still think the note is misleading).

If the prox-1 user provides a single, non-overlapping data object to prox-1 that is transferred across multiple sessions and if I *CAN* have duplicate data delivered that is associated with the transition between sessions, that duplicate data has to show up during one of the sessions (probably the second in a causal universe).  If there are no COP-P resynchronization events during either session, then I’ve got duplicate data in a session with no resynchroniztion events?

I’m fine with the rest of your dispositions.

                                --keith

========
Just a comment:
I believe the following formulations are equivalent, just that the second is clearer.  Regardless, I’m fine with your wording if you prefer it.

2.2.3.2
I think where it says: "...without gaps, errors, or duplications within a single communication session *without COP-P resynchronization during the session*..."?

might be better phrased as:
"... without gaps, errors, or duplications within a single communication session *when COP-P resynchronization is not required during the session (see 4.3.2).*"
[or maybe it should have been “in those cases where COP-P resynchronization is not required…”]

From: Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov]
Sent: Tuesday, February 28, 2012 4:12 PM
To: Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>; Scott, Keith L.
Cc: Thomas Gannett; Gilles Moury; Hooke, Adrian J (9000); Greenberg, Edward (313B); Kazz, Greg J (313B); Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>; Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>
Subject: Re: CESG Poll for the three Proximity-1 books

G.P./Keith, et al

My answers are in RED below. Thanks for the questions!

Greg

From: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Tue, 28 Feb 2012 00:00:27 -0800
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>" <Massimo.Bertinelli at esa.int<mailto:Massimo.Bertinelli at esa.int>>, "Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>" <Enrico.Vassallo at esa.int<mailto:Enrico.Vassallo at esa.int>>
Cc: Thomas Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>, Gilles Moury <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Subject: CESG Poll for the three Proximity-1 books

Dear All,
        as far as I can see on the web, the CESG poll reported only votes stating "APPROVE UNCONDITIONALLY" and the 3 polls got quorum.

So next step should be the CMC Poll to authorize to start Agency Review.

Greg,
        Keith Scott  also voted "APPROVE UNCONDITIONALLY"  but with the comments reported below.
It is my understanding that they do not prevent starting the CMC Poll, but I would appreciate your fast reaction to know your opinion and which comments can be solved at once and which one should be converted to RIDs (author SLP WG Chair on behalf of Keith I would propose) for discussion within Agency Review.

I wish you all a nice day.

Gian Paolo

PS I took the freedom of inserting one personal comment.
--------------------------------------------------------------------------------------------------------------------
Prox-1 Data Link Layer

2.2.3.2
How do we reconcile 2.2.3.2:
The Sequence Controlled service ensures that data are reliably transferred across the space link and delivered in order, without gaps, errors, or duplications within a single
communication session without COP-P resynchronization during the session (see 4.3.2).
with Note 2 in section 4.3.2.2:
2 The mechanisms provided in this specification will not eliminate duplicate data associated with the transition between the end of one session and the beginning of the
next. Elimination of this problem is left to the controlling data system.
GPC: they do not in conflict as there is guarantee within a session but not across session. It may be this should be highlighted somehow in section 2 too.
------

** Figure 2-1 at the top:
"INPUT of USER DATA + Routing Info" -- is it really routing information?  Maybe "USER DATA + Control Info"?  If this referrs specifically to the Port ID then OK, I suppose the control of data output from the receiver is a form of routing.

This meshes with 2.1.6 'Addressing' where one could use 'The Port ID provides the means to *direct* user data internally...'
Yes, PORT ID is the output port to which the data is routed, so I would stick to this term.
------

2.2.3.2
I think where it says: "...without gaps, errors, or duplications wthin a single communication session *without COP-P resynchronization during the session*..."?

might be better phrased as:
"... without gaps, errors, or duplications within a single communication session *when COP-P resynchronization is not required during the session (see 4.3.2).*"

AND it seems like there may be duplicates anyway if there are other sessions (as above)?

Recall that Prox-1 was built for point to point links involving independent comm sessions. Every session is independent of the previous or next one.
For data continuity between sessions, Prox-1 always relies upon higher layer protocols, e.g., CFDP, LTP, DTN, etc… Prox-1 has an elegant way of ending a session by both sides declaring they have no more data to send, but to date the missions use the physical exit strategy- node no longer in view - to terminate the session and keep the data flowing until the bitter end. Prox-1 guarentees no gaps, duplicates or errors (based upon the CRC-32 undetected error rate and the link FER) within a single session.

I don't like the rewording above because it states a negative requirement – something that cannot be validated.

----

"SDUs supplied by a sending user for transfer with the Sequence Controlled quality of service are inserted into transfer frames as required and transmitted on a Physical Channel (PC) in the order in which they are presented."

The frames may be initially transmitted in the order in which they are presented, but retransmissions will mess with this ordering, correct?
The overall order of the frames is still preserved. Retransmission would force a go-back-N number of frames to be retransmitted and then forward progress should then reoccur.
----

"4.2.6 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected."

What does this mean?  Does 'when time tag data is collected' apply to all of the data mentioned (1. egress times, 2. frame sequence number, 3. QoS indicators) or are the first two always stored and QoS indicators only included when time tag data is collected?  Does this mean '...andthe QoS indicator of when time tag...' (and if so, what exactly does that mean?)

4.2.6.1
Same issue as 4.2.6
Time tag data is the Raw snap shots of the clock when a Prox-1 frame ingresses or egresses a defined point on the spacecraft. All the other data (FSN, QoS indicator) is meta data associated with each clock value. These buffers are identified on both the Send and Receive sides.
-----

The section numbers around 4.2.5 -- 4.2.7 seem busted.  Maybe they should be:

4.2.5 MAC BUFFERS
4.2.5.1 SENT_TIME_BUFFER
4.2.5.1.1 The SENT_TIME_BUFFER shall store all of the egress clock times, associated frame sequence numbers, and QoS Indicator when time tag data is collected.
4.2.5.2 RECEIVE_TIME_BUFFER
4.2.5.2.2 The RECEIVE_TIME_BUFFER shall store all of the ingress clock times, associated frame sequence numbers and QoS Indicator when time tag data is collected.

Tom to fix please.
-----

4.3.2.2 (and Reliable Data Transfer in general)
Is the user informed of whether COP-P resynchronization has taken place during the course of a single communication session?  If not, how does the receiver know if there may be duplicate data?  Does detectingresynchronization require setting the MIB parameter Resync_Local to 'false'?  If the user is required to monitor the RESYNC variable (7.1.2) to detect resynchronization, is there any guarantee that the user will detect the change (that is, if the user reads 1/second, will they notice the resynch event?)

Note 1 in section 4.3.2.2 -- how is the delivery of duplicate data due to factors outside the scope of the Proximity-1 protocol?  It seems that duplicate data may be delivered because the Proximity-1 protocol does not detect duplication across resynchronization events, but I suspect a more robust COP-like protocol *could*.  The point is, the duplicate data is a result of the Prox-1 reliability mechanisms not being robust across resynchronzation, not some sort of external factor.

What are the 'bounds' on duplicate data reception associated with Note 2 in section 4.3.2.2?  Are all data received with 256 frames of a communication session boundary suspect of duplication, e.g.?

Prox-1 notifies the "user" I.e., the vehicle controller on the Sending side when COP-P  (Sending node) detects loss of synchronization (Synch_Timer expires). Prox-1 gives the user two options regarding how to handle resynchronization. If the MIB parameter Resync-Local is set to "true", then Prox-1 COP-P Sending Node will force the other side to reset it's sequence counter. The receiving node is simply data driven and responds to the sending node. If set to "false", it's up to the Sending Node vehicle controller on how to deal with the out of sync condition, which is then outside of the protocol. Some missions may simply not care if one overflight (of short duration) didn't go as planned or they may invoke their own strategy. … The "user" doesn't monitor the RESYNC variable that is an internal variable within the COP-P to monitor when the resync condition terminates.

The only way I am aware for the receiving node to get duplicate data is to stich together data from several prox-1 sessions where the data controller allowed overlap but this was not a consequence of Prox-1. Even during a resync, the protocol can't accept duplicate frame numbers. The worst case is no forward progress if the Receiving Node's expected frame counter, V(R), exceeds the window size, which could occur through SEU hit on that register.

The bounds on duplicate data is not a function of Prox-1 but rather how much of a "rewind" the user plans to do if they are stiching Prox-1 sessions together by brute force. We eliminated the possibility of frame counter ambiguity in Prox-1 by limiting the window size N to 127. This is due to the duality of interpreting sequence counts whenever a rollover occurs using modulo arithmetic … in our case with counts greater than 127. Since the sequence counter is a mod 256 counter, there is no way for us to deal with unique sequence counter unless we limit N to 127.

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

6.2.2.1.1
It is unclear from the below when or if the receiver is powered on in half-duplex mode:

"...
b) connecting-T: In the Physical Layer, the Connecting-Transmit state in full duplex
shall dictate that the ***receiver (sequentially in half duplex)*** and transmitter are
powered on and enabled to process received frames, and that the transmitteris
enabled for asynchronous channel operations. (***In half duplex, only the transmitter is
powered on.***) The Hail Activity shall be conducted while MODE is connecting-T.

I agree this text needs some clean up. What's important here is that the state of the transmitter changes in half-duplex depending upon who controls the Prox-1 Token. The receiver can be on all the time. This is a RID to make this read clearly.

6.2.3.7  REMOTE_SCID_BUFFER
Are the tests mentioned done on reception or transmission?  It seems like this is trying to ensure that all frames are sent to the same destination spacecraft ID?
All tests are carried out upon reception.  I need to reference 3.2.2.9 here which lists all of the tests by the receiving node– we will make this a RID. This buffer is just a receptical for the value of the Remote_spacecraft_ID i.e., partnered node MIB parameter.
New Definition – REMOTE_SCID_BUFFER shall be used to hold the value of the Remote_spacecraft_ID of the partnered node. See 3.2.2.9

6.2.3.9  RECEIVING_SCID_BUFFER
"...or it may be loaded with the spacecraft ID contained in the first valid received frame." -- First of WHAT (I think 'first valid received frame of a new connection where the sourceOrDest parameter of the frame is DESTINATION' [since if the first valid received frame has sourceOrDestination set to source then the value of the SCID will be the transmitter -- or is this not possible?])?
Again, one has to interpret the S/D flag differently if one is the Sending node or the Receiving node.  Yes it is the initial valid received frame of a session.  However this refers to the optional test when S/D = SOURCE, since the test when S/D = DESTINATION is always made. See section 3.2.2.9 and section 6.2.4.2.  We accept some of the rewording as a RID – we will update with the wording "the initial valid received frame of a session" and in 6.2.4.2 as well.

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sls-ngu/attachments/20120302/069d2607/attachment-0001.html