From dissinger@gst.com Mon May 12 19:02:45 2003 From: dissinger@gst.com (Neil Dissinger) Date: Mon, 12 May 2003 14:02:45 -0400 Subject: [Sis-uce] test Message-ID: From Scott.Burleigh@jpl.nasa.gov Mon May 12 20:50:43 2003 From: Scott.Burleigh@jpl.nasa.gov (Scott Burleigh) Date: Mon, 12 May 2003 12:50:43 -0700 Subject: [Sis-uce] Thoughts? Message-ID: <5.2.0.9.2.20030512122950.03b4ead8@mail2.jpl.nasa.gov> --=====================_251001370==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, BOF members. I have been supposing that the change described in the UCE Concept Paper was simple and non-controversial enough to make establishment of the SIS UCE Working Group rapid and straightforward. Here's where we test that idea. There seem to be three general points on which we need to reach rough consensus before we propose WG formation to the Area Director; please let me know your thoughts on all three. 1. Technical concept. Is there anything about the technical concept (in the repository at http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215) that we need to revise? Rob Smith doesn't have funding to participate in the BOF, but he has asked me to pass this comment along: "I've just read through your proposed extension to Unacknowledged CFDP to counter out-of-order delivery. This looks like a very sensible suggestion to me. However, I feel that 'Check Limit' nomenclature is not the best description of the (clearly defined) error. 'Check' could describe almost any of the CFDP faults, e.g. NAK Limit, Positive Acknowledgement Limit, etc. as they all involve some kind of check. I think this would be clearer with a more descriptive name, like: a. Transaction Lifetime Limit b. Reordering Leeway Limit c. Unacknowledged Extension Limit Or some permutation of the above." I personally think "Check Limit" is okay, but please speak up if you disagree. 2. Charter. Is there anything about the Charter (same repository) that is unreasonable? In particular, would JPL, GSFC, and ESTEC be prepared to provide the resources to support the necessary demonstrations and interoperability testing? 3. Working group chair. When we propose the new Working Group to the Area Director, we need to identify someone who is willing and able to be its Chair. I will volunteer, but if anyone else would like to take this on (or nominate some other lucky BOF member), please feel free! Scott --=====================_251001370==.ALT Content-Type: text/html; charset="us-ascii" Hi, BOF members. I have been supposing that the change described in the UCE Concept Paper was simple and non-controversial enough to make establishment of the SIS UCE Working Group rapid and straightforward. Here's where we test that idea. There seem to be three general points on which we need to reach rough consensus before we propose WG formation to the Area Director; please let me know your thoughts on all three.

1.      Technical concept.

Is there anything about the technical concept (in the repository at http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215) that we need to revise?

Rob Smith doesn't have funding to participate in the BOF, but he has asked me to pass this comment along:

"I've just read through your proposed extension to Unacknowledged CFDP to counter out-of-order delivery. This looks like a very sensible suggestion to me. However, I feel that 'Check Limit' nomenclature is not the best description of the (clearly defined) error. 'Check' could describe almost any of the CFDP faults, e.g. NAK Limit, Positive Acknowledgement Limit, etc. as they all involve some kind of check.

I think this would be clearer with a more descriptive name, like:
a. Transaction Lifetime Limit
b. Reordering Leeway Limit
c. Unacknowledged Extension Limit

Or some permutation of the above."

I personally think "Check Limit" is okay, but please speak up if you disagree.

2.      Charter.

Is there anything about the Charter (same repository) that is unreasonable? In particular, would JPL, GSFC, and ESTEC be prepared to provide the resources to support the necessary demonstrations and interoperability testing?

3.      Working group chair.

When we propose the new Working Group to the Area Director, we need to identify someone who is willing and able to be its Chair. I will volunteer, but if anyone else would like to take this on (or nominate some other lucky BOF member), please feel free!

Scott
--=====================_251001370==.ALT-- From Massimilano.Ciccone@esa.int Tue May 13 10:23:44 2003 From: Massimilano.Ciccone@esa.int (Massimilano.Ciccone@esa.int) Date: Tue, 13 May 2003 10:23:44 +0100 Subject: [Sis-uce] Thoughts? Message-ID: 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. 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) 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. Regards Max SW Engineer Data Handling Section ************************************** VITROCISET - 2200 AG Noordwijk The Netherlands ESTEC - ESA (TOS- ESD) e-mail: Massimiliano.Ciccone@ESA.int \|/ Ph: +31-71-5655310 @ @ __________________________________o00-(_)-00o___ Scott Burleigh cc: Sent by: Subject: [Sis-uce] Thoughts? sis-uce-admin@mailma n.ccsds.org 2003/05/12 20:50 Hi, BOF members. I have been supposing that the change described in the UCE Concept Paper was simple and non-controversial enough to make establishment of the SIS UCE Working Group rapid and straightforward. Here's where we test that idea. There seem to be three general points on which we need to reach rough consensus before we propose WG formation to the Area Director; please let me know your thoughts on all three. 1. Technical concept. Is there anything about the technical concept (in the repository at http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215) that we need to revise? Rob Smith doesn't have funding to participate in the BOF, but he has asked me to pass this comment along: "I've just read through your proposed extension to Unacknowledged CFDP to counter out-of-order delivery. This looks like a very sensible suggestion to me. However, I feel that 'Check Limit' nomenclature is not the best description of the (clearly defined) error. 'Check' could describe almost any of the CFDP faults, e.g. NAK Limit, Positive Acknowledgement Limit, etc. as they all involve some kind of check. I think this would be clearer with a more descriptive name, like: a. Transaction Lifetime Limit b. Reordering Leeway Limit c. Unacknowledged Extension Limit Or some permutation of the above." I personally think "Check Limit" is okay, but please speak up if you disagree. 2. Charter. Is there anything about the Charter (same repository) that is unreasonable? In particular, would JPL, GSFC, and ESTEC be prepared to provide the resources to support the necessary demonstrations and interoperability testing? 3. Working group chair. When we propose the new Working Group to the Area Director, we need to identify someone who is willing and able to be its Chair. I will volunteer, but if anyone else would like to take this on (or nominate some other lucky BOF member), please feel free! Scott From Scott.Burleigh@jpl.nasa.gov Tue May 13 17:35:46 2003 From: Scott.Burleigh@jpl.nasa.gov (Scott Burleigh) Date: Tue, 13 May 2003 09:35:46 -0700 Subject: [Sis-uce] Thoughts? In-Reply-To: Message-ID: <5.2.0.9.2.20030513090709.00a74720@mail2.jpl.nasa.gov> 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 From Scott.Burleigh@jpl.nasa.gov Wed May 21 21:02:08 2003 From: Scott.Burleigh@jpl.nasa.gov (Scott Burleigh) Date: Wed, 21 May 2003 13:02:08 -0700 Subject: [Sis-uce] Thoughts? In-Reply-To: Message-ID: <5.2.0.9.2.20030521123447.00b0e9f0@mail2.jpl.nasa.gov> Hi. We've now had a little over a week to mull over the UCE technical concept and charter, and from the low volume of traffic on this mailing list I figure none of this stuff is extremely controversial. The concern Max discussed in his email certainly needs to be explored, as do the points that Son Ho brought up to me in off-list email a couple of weeks ago, but I think these are all design details rather than objections that go to the validity of the concept itself. I would suggest that hammering out those details is exactly what a Working Group is for, so I plan to take the current Concept Paper and Charter to the SIS Area Director on Monday morning and propose that the UCE BOF metamorphose into a new UCE Working Group. (By default, all members of the BOF will automatically become members of the Working Group -- which for most of us will not entail any significant additional work.) Does anyone have any objections? Scott From Christopher.Krupiarz@jhuapl.edu Thu May 22 16:28:38 2003 From: Christopher.Krupiarz@jhuapl.edu (Krupiarz, Christopher) Date: Thu, 22 May 2003 11:28:38 -0400 Subject: [Sis-uce] Thoughts? Message-ID: <69252A37C3A6A844930C8C8AC4116DE94ECE27@spacemsg3.dom1.jhuapl.edu> All, The following is an exchange regarding Scott's concept that he suggested be forwarded to the mailing list. I'll put my NAK comments here so that it doesn't get too garbled: The NAK timer would serve pretty much the same thing, but it would send a NAK that may be unnecessary in the event of late arriving PDUs. Thus the sender would end up using bandwidth to resend PDUs that the receiver was probably shortly to receive. Of course, this is all dependent upon someone using acknowledged mode which, as you say, isn't likely. Therefore it's probably not worth introducing the added complexity to acknowledged mode. Chris --------------------------------------------- Christopher J. Krupiarz Space Department, Embedded Applications Group Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, Maryland 20723 christopher.krupiarz@jhuapl.edu Voice: 443-778-5056 FAX: 443-778-3839 --------------------------------------------- > -----Original Message----- > From: Scott Burleigh [mailto:Scott.Burleigh@jpl.nasa.gov] > Sent: Thursday, May 22, 2003 10:57 AM > To: Krupiarz, Christopher > Subject: RE: [Sis-uce] Thoughts? > > > At 09:16 AM 5/22/2003 -0400, you wrote: > >Scott, > > > >FYI, I see no problem with the concept. It sounds like it's > needed and this > >looks like a good solution. One question: do you see any > scenarios where > >acknowledged mode would still be used even with a > retransmitting link layer? > > Actually, no. If the link layer is reliable, I think > acknowledged-mode > CFDP would be unnecessary overhead. > > >I was trying to come up with some but none seemed terribly > realistic. I was > >thinking along the lines of maybe a sensor web or a rover > that couldn't > >handle the extra complexity may communicate to some waypoint > that was using a > >retransmitting link layer. > > I suspect that the link-layer retransmission being proposed > at JPL will be > simpler than acknowledged-mode CFDP, but I agree that the > scenario you're > talking about is possible. If the rover is using ack-mode > CFDP over a > non-retransmitted link, then the waypoint will have to be > doing the same > thing in order for the two to communicate. The question then > is what the > waypoint-to-earth communication looks like. > > If you're using Extended Procedures then you've got only a > single CFDP > transaction end-to-end; I'm pretty sure you'd have to stick with > acknowledged mode on the waypoint-to-earth link even if that > link layer had > its own retransmission. > > I think that's in fact an argument against Extended Procedures that I > hadn't considered. If you are instead using > Store-and-Forward Overlay, > then the waypoint-to-earth transmission is a separate > transaction with a > potentially different configuration: it could be > unacknowledged-mode CFDP > over the retransmitting link. A little cleaner. > > >The reason I ask is that if there were, it would > >naturally be beneficial to have the Check Timer on > acknowledged EOFs in > >order to reduce NAK traffic. > > Can you tell me a little more about how you'd see this > operating? I'm > thinking that in acknowledged mode we already have the NAK > timer doing > essentially the same thing (i.e., it starts when you receive > an EOF and not > all of the file data and metadata have been received). > > Scott > > P.S.: please don't feel inhibited about posting this kind of > exchange to > the sis-uce mailing list. This stuff is highly relevant to > the charter of > the BOF and the future WG. > From Scott.Burleigh@jpl.nasa.gov Thu May 22 17:20:22 2003 From: Scott.Burleigh@jpl.nasa.gov (Scott Burleigh) Date: Thu, 22 May 2003 09:20:22 -0700 Subject: [Sis-uce] Thoughts? In-Reply-To: <69252A37C3A6A844930C8C8AC4116DE94ECE27@spacemsg3.dom1.jhua pl.edu> Message-ID: <5.2.0.9.2.20030522090655.00ac5ff0@mail2.jpl.nasa.gov> At 11:28 AM 5/22/2003 -0400, Krupiarz, Christopher wrote: >All, > >The following is an exchange regarding Scott's concept that he suggested be >forwarded to the mailing list. I'll put my NAK comments here so that it >doesn't get too garbled: > >The NAK timer would serve pretty much the same thing, but it would send a >NAK that may be unnecessary in the event of late arriving PDUs. Thus the >sender would end up using bandwidth to resend PDUs that the receiver was >probably shortly to receive. Of course, this is all dependent upon someone >using acknowledged mode which, as you say, isn't likely. Therefore it's >probably not worth introducing the added complexity to acknowledged mode. Okay, I think I see your point: if there were a Check cycle timer operating in parallel with the NAK cycle timer in acknowledged mode, but on a much shorter period, then it could detect file completion sooner without increasing the risk of issuing an unnecessary NAK and triggering unnecessary retransmission. It would reduce NAK traffic if you would otherwise run with a NAK timer period so short that premature re-NAKing was likely (it would let you increase the NAK timer period without increasing delay in delivering completed files); if you were already using a long-period NAK timer, then it would reduce file delivery latency. There's certainly value in this; the question would be whether that value would justify the additional complexity in the spec and in the implementations. I'm inclined toward minimizing additional complexity in CFDP at this point, even at the cost of sub-optimal performance, but what do you guys think? Scott > > -----Original Message----- > > From: Scott Burleigh [mailto:Scott.Burleigh@jpl.nasa.gov] > > Sent: Thursday, May 22, 2003 10:57 AM > > To: Krupiarz, Christopher > > Subject: RE: [Sis-uce] Thoughts? > > > > > > At 09:16 AM 5/22/2003 -0400, you wrote: > > >Scott, > > > > > >FYI, I see no problem with the concept. It sounds like it's > > needed and this > > >looks like a good solution. One question: do you see any > > scenarios where > > >acknowledged mode would still be used even with a > > retransmitting link layer? > > > > Actually, no. If the link layer is reliable, I think > > acknowledged-mode > > CFDP would be unnecessary overhead. > > > > >I was trying to come up with some but none seemed terribly > > realistic. I was > > >thinking along the lines of maybe a sensor web or a rover > > that couldn't > > >handle the extra complexity may communicate to some waypoint > > that was using a > > >retransmitting link layer. > > > > I suspect that the link-layer retransmission being proposed > > at JPL will be > > simpler than acknowledged-mode CFDP, but I agree that the > > scenario you're > > talking about is possible. If the rover is using ack-mode > > CFDP over a > > non-retransmitted link, then the waypoint will have to be > > doing the same > > thing in order for the two to communicate. The question then > > is what the > > waypoint-to-earth communication looks like. > > > > If you're using Extended Procedures then you've got only a > > single CFDP > > transaction end-to-end; I'm pretty sure you'd have to stick with > > acknowledged mode on the waypoint-to-earth link even if that > > link layer had > > its own retransmission. > > > > I think that's in fact an argument against Extended Procedures that I > > hadn't considered. If you are instead using > > Store-and-Forward Overlay, > > then the waypoint-to-earth transmission is a separate > > transaction with a > > potentially different configuration: it could be > > unacknowledged-mode CFDP > > over the retransmitting link. A little cleaner. > > > > >The reason I ask is that if there were, it would > > >naturally be beneficial to have the Check Timer on > > acknowledged EOFs in > > >order to reduce NAK traffic. > > > > Can you tell me a little more about how you'd see this > > operating? I'm > > thinking that in acknowledged mode we already have the NAK > > timer doing > > essentially the same thing (i.e., it starts when you receive > > an EOF and not > > all of the file data and metadata have been received). > > > > > > Scott > > > > P.S.: please don't feel inhibited about posting this kind of > > exchange to > > the sis-uce mailing list. This stuff is highly relevant to > > the charter of > > the BOF and the future WG. > > >_______________________________________________ >Sis-uce mailing list >Sis-uce@mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sis-uce From Christopher.Krupiarz@jhuapl.edu Thu May 22 17:45:18 2003 From: Christopher.Krupiarz@jhuapl.edu (Krupiarz, Christopher) Date: Thu, 22 May 2003 12:45:18 -0400 Subject: [Sis-uce] Thoughts? Message-ID: <69252A37C3A6A844930C8C8AC4116DE94ECE2A@spacemsg3.dom1.jhuapl.edu> Scott, I was thinking of operating serially although I hadn't thought of the advantages you mention for a parallel timer. I envisioned that once the EOF is received, the Check Timer is started for a bit to get any stragglers, then, if the file is still not complete, start the NAK process. Thus no NAKs are sent in the most likely case. With a link without retransmissions, the Check Timer would be 0. However, unless someone can come up with a compelling example of using acknowledged mode over a link with retransmissions, I'm all for minimizing complexity and leaving it out. Even then, the worst case scenario is probably the transmission of one NAK since I don't see the NAK timer set so tight that it didn't get the rest of the PDUs that were still in transmission before the NAK timer timed out (this skips over why the NAK would have even timed out to begin with since delivery is guaranteed by the link layer--this stuff can really make your head spin :). Chris -----Original Message----- From: Scott Burleigh [mailto:Scott.Burleigh@jpl.nasa.gov] Sent: Thursday, May 22, 2003 12:20 PM To: sis-uce@mailman.ccsds.org Subject: RE: [Sis-uce] Thoughts? At 11:28 AM 5/22/2003 -0400, Krupiarz, Christopher wrote: >All, > >The following is an exchange regarding Scott's concept that he suggested be >forwarded to the mailing list. I'll put my NAK comments here so that it >doesn't get too garbled: > >The NAK timer would serve pretty much the same thing, but it would send a >NAK that may be unnecessary in the event of late arriving PDUs. Thus the >sender would end up using bandwidth to resend PDUs that the receiver was >probably shortly to receive. Of course, this is all dependent upon someone >using acknowledged mode which, as you say, isn't likely. Therefore it's >probably not worth introducing the added complexity to acknowledged mode. Okay, I think I see your point: if there were a Check cycle timer operating in parallel with the NAK cycle timer in acknowledged mode, but on a much shorter period, then it could detect file completion sooner without increasing the risk of issuing an unnecessary NAK and triggering unnecessary retransmission. It would reduce NAK traffic if you would otherwise run with a NAK timer period so short that premature re-NAKing was likely (it would let you increase the NAK timer period without increasing delay in delivering completed files); if you were already using a long-period NAK timer, then it would reduce file delivery latency. There's certainly value in this; the question would be whether that value would justify the additional complexity in the spec and in the implementations. I'm inclined toward minimizing additional complexity in CFDP at this point, even at the cost of sub-optimal performance, but what do you guys think? Scott > > -----Original Message----- > > From: Scott Burleigh [mailto:Scott.Burleigh@jpl.nasa.gov] > > Sent: Thursday, May 22, 2003 10:57 AM > > To: Krupiarz, Christopher > > Subject: RE: [Sis-uce] Thoughts? > > > > > > At 09:16 AM 5/22/2003 -0400, you wrote: > > >Scott, > > > > > >FYI, I see no problem with the concept. It sounds like it's > > needed and this > > >looks like a good solution. One question: do you see any > > scenarios where > > >acknowledged mode would still be used even with a > > retransmitting link layer? > > > > Actually, no. If the link layer is reliable, I think > > acknowledged-mode > > CFDP would be unnecessary overhead. > > > > >I was trying to come up with some but none seemed terribly > > realistic. I was > > >thinking along the lines of maybe a sensor web or a rover > > that couldn't > > >handle the extra complexity may communicate to some waypoint > > that was using a > > >retransmitting link layer. > > > > I suspect that the link-layer retransmission being proposed > > at JPL will be > > simpler than acknowledged-mode CFDP, but I agree that the > > scenario you're > > talking about is possible. If the rover is using ack-mode > > CFDP over a > > non-retransmitted link, then the waypoint will have to be > > doing the same > > thing in order for the two to communicate. The question then > > is what the > > waypoint-to-earth communication looks like. > > > > If you're using Extended Procedures then you've got only a > > single CFDP > > transaction end-to-end; I'm pretty sure you'd have to stick with > > acknowledged mode on the waypoint-to-earth link even if that > > link layer had > > its own retransmission. > > > > I think that's in fact an argument against Extended Procedures that I > > hadn't considered. If you are instead using > > Store-and-Forward Overlay, > > then the waypoint-to-earth transmission is a separate > > transaction with a > > potentially different configuration: it could be > > unacknowledged-mode CFDP > > over the retransmitting link. A little cleaner. > > > > >The reason I ask is that if there were, it would > > >naturally be beneficial to have the Check Timer on > > acknowledged EOFs in > > >order to reduce NAK traffic. > > > > Can you tell me a little more about how you'd see this > > operating? I'm > > thinking that in acknowledged mode we already have the NAK > > timer doing > > essentially the same thing (i.e., it starts when you receive > > an EOF and not > > all of the file data and metadata have been received). > > > > > > Scott > > > > P.S.: please don't feel inhibited about posting this kind of > > exchange to > > the sis-uce mailing list. This stuff is highly relevant to > > the charter of > > the BOF and the future WG. > > >_______________________________________________ >Sis-uce mailing list >Sis-uce@mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sis-uce _______________________________________________ Sis-uce mailing list Sis-uce@mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sis-uce From Massimilano.Ciccone@esa.int Fri May 23 16:28:50 2003 From: Massimilano.Ciccone@esa.int (Massimilano.Ciccone@esa.int) Date: Fri, 23 May 2003 16:28:50 +0100 Subject: [Sis-uce] Thoughts? Message-ID: The method proposed by Chris can be translated in eliminating sub-section (a) in paragrhaph 4.1.6.4.5 of CFDP Blue Book. I see it as an advantage only in case PDUs can be delivered order (Data after EOF PDU), but I don't think it is worth it to undergo the change process for this particular case. But now a question sprang my mind... How is this NAK (acknowledged only) discussion related to the Unacknowledge procedures of CFDP ? Max SW Engineer Data Handling Section ************************************** VITROCISET - 2200 AG Noordwijk The Netherlands ESTEC - ESA (TOS- ESD) e-mail: Massimiliano.Ciccone@ESA.int \|/ Ph: +31-71-5655310 @ @ __________________________________o00-(_)-00o___ From Christopher.Krupiarz@jhuapl.edu Fri May 23 15:35:37 2003 From: Christopher.Krupiarz@jhuapl.edu (Krupiarz, Christopher) Date: Fri, 23 May 2003 10:35:37 -0400 Subject: [Sis-uce] Thoughts? Message-ID: <69252A37C3A6A844930C8C8AC4116DE94ECE32@spacemsg3.dom1.jhuapl.edu> The original question for Scott was whether it would be worth applying the Check Timer to the acknowledged procedures. If it was, it would seem worthwhile to modify the concept at this point to include this as opposed to revisiting it later. However, after this discussion, it would appear to not be a concern. Chris -----Original Message----- From: Massimilano.Ciccone@esa.int [mailto:Massimilano.Ciccone@esa.int] Sent: Friday, May 23, 2003 11:29 AM To: sis-uce@mailman.ccsds.org Subject: RE: [Sis-uce] Thoughts? The method proposed by Chris can be translated in eliminating sub-section (a) in paragrhaph 4.1.6.4.5 of CFDP Blue Book. I see it as an advantage only in case PDUs can be delivered order (Data after EOF PDU), but I don't think it is worth it to undergo the change process for this particular case. But now a question sprang my mind... How is this NAK (acknowledged only) discussion related to the Unacknowledge procedures of CFDP ? Max SW Engineer Data Handling Section ************************************** VITROCISET - 2200 AG Noordwijk The Netherlands ESTEC - ESA (TOS- ESD) e-mail: Massimiliano.Ciccone@ESA.int \|/ Ph: +31-71-5655310 @ @ __________________________________o00-(_)-00o___ _______________________________________________ Sis-uce mailing list Sis-uce@mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sis-uce From Scott.Burleigh@jpl.nasa.gov Fri May 23 22:41:18 2003 From: Scott.Burleigh@jpl.nasa.gov (Scott Burleigh) Date: Fri, 23 May 2003 14:41:18 -0700 Subject: [Sis-uce] Working Group formation proposal Message-ID: <5.2.0.9.2.20030523133528.00ad8ea0@mail2.jpl.nasa.gov> Bob, I believe there is sufficient agreement on concept and charter among the members of the Unacknowledged-CFDP Extensions (UCE) BOF to proceed with forming a new Unacknowledged-CFDP Extensions Working Group in the Space Internetworking Services area. Both the draft Charter and initial Technical Concept paper for the UCE work are at http://secretariat.gst.com/docu/dscgi/ds.py/View/Collection-215. I have assurances that JPL will provide the resources called for in the Charter; I'm hoping to get commitments from ESTEC and GSFC by the end of the month. As no one else has volunteered yet, I expect I would be chairing the Working Group. Please let me know of any additional support you would need to bring this proposal to the CESG. Thanks, Scott