From greg.j.kazz at jpl.nasa.gov Sat Mar 3 12:01:28 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Sat, 3 Mar 2012 04:01:28 -0800 Subject: [Sls-slp] FW: CESG Poll for the three Proximity-1 books In-Reply-To: Message-ID: Sorry – I ment to send this email to SLP. Greg Kazz From: "Kazz, Greg J (313B)" > Date: Fri, 2 Mar 2012 16:18:31 -0800 To: "sls-ngu at mailman.ccsds.org" > Cc: CCSDS Secretariat > Subject: FW: CESG Poll for the three Proximity-1 books 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)" > Date: Wed, 29 Feb 2012 16:15:39 -0800 To: "Scott, Keith L." >, "Gian.Paolo.Calzolari at esa.int" > Cc: Thomas Gannett >, Gilles Moury >, "Hooke, Adrian J (9000)" >, "Greenberg, Edward (313B)" >, "Massimo.Bertinelli at esa.int" >, "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." > Date: Wed, 29 Feb 2012 06:43:56 -0800 To: "Kazz, Greg J (313B)" >, "Gian.Paolo.Calzolari at esa.int" > Cc: Thomas Gannett >, Gilles Moury >, "Hooke, Adrian J (9000)" >, "Greenberg, Edward (313B)" >, "Massimo.Bertinelli at esa.int" >, "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; Scott, Keith L. Cc: Thomas Gannett; Gilles Moury; Hooke, Adrian J (9000); Greenberg, Edward (313B); Kazz, Greg J (313B); Massimo.Bertinelli at esa.int; 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" > Date: Tue, 28 Feb 2012 00:00:27 -0800 To: "Kazz, Greg J (313B)" >, "Massimo.Bertinelli at esa.int" >, "Enrico.Vassallo at esa.int" > Cc: Thomas Gannett >, Gilles Moury > 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: From greg.j.kazz at jpl.nasa.gov Wed Mar 7 18:32:56 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 7 Mar 2012 10:32:56 -0800 Subject: [Sls-slp] Inputs for SLP - Spring 2012 meeting in Darmstadt Message-ID: Dear SLPers, We have been given the deadline of March 11 by the SLS area director to provide him with the list of inputs we are planning to address at the Spring 2012 meeting. So far the list I have is: 1. Determine RID dispositions to Prox-1 DLL book (and where necessary consider the other two Prox-1 books for commonality of wording) 2. Plan for updating Prox-1 GB (which sections are involved, assign writing assignments, etc) Please let me know if you have any other items you wish to have addressed at this meeting – please send me your comments ASAP. Thanks! Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Mar 7 20:33:42 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Wed, 7 Mar 2012 12:33:42 -0800 Subject: [Sls-slp] Registration now open for Spring 2012 CCSDS meetings in Darmstadt Message-ID: Dear SLP and NGU WG members, Registration for the Spring 2012 CCSDS meetings in Darmstadt are now open. Please go to this URL to register: http://public.ccsds.org/meetings/2012Spring/2012SpringReg.aspx Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Wed Mar 7 21:50:05 2012 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 7 Mar 2012 22:50:05 +0100 Subject: [Sls-slp] Inputs for SLP - Spring 2012 meeting in Darmstadt In-Reply-To: References: Message-ID: <25980_1331156998_4F57D806_25980_211002_1_OFFE39C600.F720718B-ONC12579BA.0077E06E-C12579BA.0077F166@esa.int> Sorry Greg (and All), but there was a misunderstanding among us. As SLS Area Director I did not set any deadline for SLP. I just informed you (Greg) about the deadline set for SLS-C&S. Therefore, deadlines for SLP .are set by SLP WG Chair and Members as usual. Regards Gian Paolo From: "Kazz, Greg J (313B)" To: "sls-slp at mailman.ccsds.org" Date: 07/03/2012 19:33 Subject: [Sls-slp] Inputs for SLP - Spring 2012 meeting in Darmstadt Sent by: sls-slp-bounces at mailman.ccsds.org Dear SLPers, We have been given the deadline of March 11 by the SLS area director to provide him with the list of inputs we are planning to address at the Spring 2012 meeting. So far the list I have is: 1. Determine RID dispositions to Prox-1 DLL book (and where necessary consider the other two Prox-1 books for commonality of wording) 2. Plan for updating Prox-1 GB (which sections are involved, assign writing assignments, etc) Please let me know if you have any other items you wish to have addressed at this meeting ? please send me your comments ASAP. Thanks! Greg Kazz Chairman CCSDS SLS-SLP WG_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp 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: From greg.j.kazz at jpl.nasa.gov Thu Mar 15 18:10:53 2012 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (313B)) Date: Thu, 15 Mar 2012 11:10:53 -0700 Subject: [Sls-slp] Status of Pink sheets to AOS Space Data Link Protocol Message-ID: SLS-SLPers, The following changes to the AOS Space Data Link Protocol are still pending as pink sheets. Although minor in nature, I just want to make sure that we are all still in agreement with these changes as were discussed in the WG. Please let me know by Friday March 23 if you have any concerns. If no concerns or changes are given to me, then we will move forward with them and ask CESG/CMC to confirm them for publication. Best regards, Greg Kazz Chairman SLS-SLP WG Link is: http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%207320P21/Overview.aspx DOCUMENT DESCRIPTION: The CCSDS Recommended Standard for AOS Space Data Link Protocol specifies the protocol, services, and procedures pertaining to the CCSDS Version-2 Transfer Frame. The current draft updates Frame Error Control Field Encoding Procedure to be consistent with other CCSDS Space Data Link Protocol specifications; changes all occurrences of 'Packet Service' and 'Packet Transfer Service' to 'Virtual Channel Packet Service'; corrects/clarifies Service Specification '.indication' text; updates/clarifies text relating to Idle Packet generation; and replaces term 'Idle Frame' with 'Only Idle Data (OID) Frame'. AOS Space Data Link Protocol Draft Recommended Standard CCSDS 732.0-P-2.1 (Pink Sheets) Issue 2.1 December 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: