[Css-csts] Revised Forward Procedures for integration into the
Framework
Martin Götzelmann
martin.goetzelmann at telespazio-vega.de
Wed Jun 19 03:47:13 EDT 2013
Dear Erik and Members of the CSTS WG,
I believe that the question whether we need to support voice and video and if so what quality of service we need to support has much more impact on the service specification that needs to be carefully analysed. . If my memory serves me well, we had discussed this briefly on the Boulder meeting and the conclusion at that time was that we were not targeting voice and video but rather command data although some applications (e.g. robotic control) had demanding requirements with respect to jitter.
It is my understanding that you cannot run isochronous data across a TCP connection with good quality because flow control, retransmissions and artificial delays to manage congestion control are likely to destroy the isochronous character of the data stream. On the other hand there are protocols that stream video and voice data over HTTP over TCP (see e.g. http://en.wikipedia.org/wiki/HTTP_Live_Streaming ) which are typically based on some intelligent buffering approach.
True support for isochronous data requires an unreliable transport protocol such as UDP that can lose data and from the discussion so far I understand that is what we are talking about. As the transport protocol does not know what data are transmitted there is no guarantee that only complete TRANSFER DATA Invocations will be lost - it is well possible that other invocations or returns (e.g. START, STOP, UNBIND, etc.) are lost or delivered out of sequence and therefore such a transport is not suitable for the data processing service as defined now independent of the question of sequence counters. If we need to support isochronous data then we would have to foresee a control channel based on a reliable transport and a data channel based on an unreliable transport - an example of such an approach is the Tsunami UDP protocol that uses a TCP based control channel and a UDP based data transfer channel.
Another problem to consider is the size of TRANSFER DATA invocations, because a unreliable transport such as UDP typically limits the size of the data units that can be transmitted to the maximum size of a packet minus the size of the transport and network layers. Either this limitation would have to accepted or the application would have to deal with segmentation and assembly taking account of the fact that some segments may be lost.
In conclusion, I think we should either stick to the specification that CSTSes require a reliable transport service or we need to seriously consider how we design the services on top of an unreliable transport (or combination of reliable and unreliable transport). Of course we cannot prevent that somebody uses an unreliable transport for the services as specified now but I feel we should strongly discourage such an approach because it will not work reliably.
Coming back to the use of counters in the simple DPP: As has been clearly stated the ONLY reason for this counter is to uniquely identify the data unit in reports sent back to the user. I had not considered the potential ambiguities resulting from unreasonably large increments a problem, trusting that implementers are mostly reasonable people, but I concede that this approach is not "water proof". Due to the considerations above I do not consider increment by 1 a problem either - the reaction of a PEER-ABORT should only be a problem during testing in case the user of provider application is not implemented correctly. One could use something like an UUID but then uniqueness checking will require always to check all queued data.
As the counter ONLY presents a unique identifier for the data, I feel that specifying options for its processing is too much overhead. Because the counter is not ensuring sequence continuity, sending a 'sequence discontinuity' event does not seem to be appropriate either. Therefore I only see the following options if we cannot agree on enforcing a unique identification:
a) we do not specify how to increment the sequence number, remove the requirement on the provider to check the sequence number and just require that it is copied into the respective notifications. I do not like this approach very much because the reporting scheme (data sequence last OK, data sequence last processed) only makes sense if sequence numbers are sequential and the increment is known to the user. However the approach would at least *allow* the user to use sequence numbers that make the reports meaningful.
b) we remove the process completion report and the references to data units from production status change reports if these are of no concern for BDPP and introduce them only for the SCDPP.
Kind Regards, Martin
-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: 19 June 2013 02:57
To: Wolfgang.Hell at esa.int; John Pietras; Sylvain Gully
Cc: css-csts-bounces at mailman.ccsds.org; css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Revised Forward Procedures for integration into the Framework
Wolfgang,
I am no doubt coming in to this at least somewhat if not to a good degree out of context. Nonetheless, I have to ask about the ability to deliver data types such as voice and video -- in this case, it seems to me that we would want to continue delivering the data, dropping the out of sequence data, and just continue rather than having the overall voice/video service severally punished via a PEER-ABORT. It does seem to me that this behavior could be parameterized such that the option to enforce strict sequencing or not is established at bind time.
Since I am not fluent with the details I will await the working group deliberation, but I think the ability to support isochronous data types that tolerate data drops outs, at least as an optional configuration, is a good idea.
Best regards,
-Erik
-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Wolfgang.Hell at esa.int
Sent: Friday, June 14, 2013 2:26 AM
To: John Pietras; Sylvain Gully
Cc: css-csts-bounces at mailman.ccsds.org; css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] Revised Forward Procedures for integration into the Framework
John and Sylvain,
As announced, this is my response to the questions and concerns you raised regarding the changed specification of the sequence-counter in the BDPP.
Your understanding of why the change was made is exactly right. I can see from your discussion that you have considered exactly the same options as we did, only your final conclusion is different.
What you suggest is certainly feasible. However, to me it looks somewhat inconsistent. On the one hand you agree that the Framework as is mandates a reliable underlying communications service. If we stick to that, then there is no reason not to accept the modified +1 increment requirement of the sequence-counter value in BDPP. If we are serious about considering Framework based services over unreliable networks, then we should lift the assumptions in section 1.3.1 of the Framework. But then we need to look at the complete picture. Running over an unreliable network is likely to affect also other procedures. What is the point in considering this case for the forward procedures only? This is just my personal view.
I look forward to discussing this issue during the next telecon and will be glad to update the forward procedures as per the outcome of the discussion.
For now, I have not applied any changes with respect to this point.
Best regards,
Wolfgang
|------------>
| From: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|John Pietras <john.pietras at gst.com> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"Wolfgang.Hell at esa.int" <Wolfgang.Hell at esa.int> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|"css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org> |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|10/06/2013 19:22 |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [Css-csts] Revised Forward Procedures for integration into the Framework |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>------------------------------------------------------------------------------------------------------------------------------------------------------|
|css-csts-bounces at mailman.ccsds.org |
>------------------------------------------------------------------------------------------------------------------------------------------------------|
Wolfgang and CSTSWG colleagues ---
I have reviewed the latest versions (V13) of the forward Procedures. With one exception, my comments below are organized sequentially from the (simple) Data Processing Procedures (DPP) to Buffered DPP (BDPP) to Sequence-Controlled DPP (SCDPP). As usual, some of my comments may address concerns that have already been addressed in a CSTSWG meeting, and if so I apologize for re-raising settled matters.
My one comment that is "out of sequence" has to do with the decision made between versions 12 and 13 to require that the data-sequence-counter must increase by 1 and causes a PEER-ABORT if it does not. This is not in keeping with the concept of non-sequence-controlled DPPs, of which the Framework BDPP is a (the) prime example. The original driver for allowing alternatives to the old DPP (which has now essentially become the SCDPP) was to loosen the tight controls on what was deemed acceptable for transmission across the forward link (with the understanding that some higher-layer protocols and/or application processes would provide the necessary ultimate protection).
By my understanding, the desired behavior at the simple DPP level is really just that the P-D invocations be uniquely identified: the strict
increment-by-1 requirement is only necessary for the SCDPP. I can see by the previous email exchanges that the struggle to define how these counter values can be ensured to be unique has caused a lot of re-definition which finally led to the simplified increment-by-1 approach.
It is true that the increment-by-1 requirement does not actually limit the behavior of DPPs when the underlying communication service guarantees complete and in-sequence delivery (which is currently required by the CSTS SFW). However, at various times the possibility has been raised of allowing (n the future) some CSTSes to run over "unreliable" networks. The use case that was used to justify what has become the BDPP - maximization of frame
(CADU) transfer even if frames are missing - would be one such candidate for running over an unreliable network connection. However, under the V13 definitions, having a frame dropped by the underlying network would cause the service to PEER-ABORT, which is exactly the behavior that motivated many of the changes in the Enhanced FCLTU service.
I have discussed this situation with several NASA colleagues (Tim Ray, Tom Wickline, Erik Barkley, Peter Shames and Ed Greenberg) and the consensus is that we would prefer that the BDPP (and therefore the simple DPP from which it is derived) *not* require strict enforcement of the increment-by-1/PEER-ABORT approach in all cases. Indeed, for NASA's needs, it is not even necessary that the BDPP procedure enforce uniqueness of the sequence numbers. In the most basic form it would be acceptable to NASA to have the specification include a warning to the users that they *should* put unique values in the sequence counters to avoid ambiguity in the notifications.
NASA is not necessarily opposed to the existence of some form of BDPP that enforces a strict by-1 incrementing, but we would like there to be some form that does *not* enforce it (and we would propose that the future Forward Frames CSTS use the less-strict version). Two possible ways to do this, of course, are (a) by use of derived procedures or (b) as options within a single procedure. In our discussions, three levels behavior were identified:
1. Ignore - The values of the data-sequence-counter have no effect
on the behavior of the DPP. The DPP will reflect whatever values that the user puts in in the parameters that are reported via the NOTIFY operation.
2. Notify - Add an event 'sequence discontinuity', to be reported
by the DPP whenever the data-sequence-counter is not 1+ the value of the immediately-preceding P-D invocation. The behavior of the DPP is otherwise not affected.
3. Enforce - Have the DPP enforce the strict incrementing of the
counter by PEER-ABORTing is there is a discontinuity on the sequence counter values.
To keep things simplest and allow the greatest extensibility, the DPP should roll back to a version that just ignores the counter value (other than to use its value when generating the NOTIFY invocations). Derived procedures (BDPP, SCDPP, and procedures that are derived from them) could then modify the behavior as appropriate. This rollback would solve a problem in the V13 SCDPP, which specifies that out-of-sequence P-D Invocations be merely rejected, in contrast to the current requirement of the parent DPP that a PEER-ABORT be triggered (see comment C.1, below).
We hope that the CSTSWG will consider these points.
Now back to the rest of the comments:
NOTE - in the following comments, the section numbers are those found in the documents. That is, they all begin at section 1. (If there are future draft releases of the Forward procedures, might I suggest that they be put into a single document? That way the sections will be uniquely identified, at least with respect to the Forward Procedures.)
A. (SIMPLE) DATA PROCESSING PROCEDURE
1. Section 2.1.3.2.2: The requirement " Each PROCESS-DATA
invocation shall include a sequence number" is redundant with the definition of the PROCESS-DATA invocation as defined in COMMON OPERATIONS. This requirement under the DPP should be deleted.
B. BUFFERED DATA PROCESSING PROCEDURE
1. Section 1.1.2.1 (Purpose), last paragraph: This paragraph
doesn't really address the purpose of the procedure. Also, is the list of ways that transfer mode is selected intended to be exhaustive or merely representative? I suggest dropping this paragraph in section 1.1.2.1, and making any statements regarding how the mode is to be specified in section 1.1.4.2.2.
2. Section 1.1.2.2 (Concepts), first paragraph: I think that there
is a typographical error in "by the Data Processing procedure in thus making the procedure implementable". I *think* what the paragraph is trying to say is " The Buffered Data Processing procedure extends the Data Processing procedure (see <REF>) and in particular provides specifications for the handling of Input Queue overflow conditions that are left unspecified by the Data Processing procedure. The specification of this behavior makes the Buffered Data Processing procedure implementable."
3. 1.1.4.2.1 (Transfer Buffer): if the User submits only P-D
invocations (that is, no buffer is used), is it necessary to specify a Transfer Buffer size?
4. 1.1.4.2.1.2: "Transfer Buffer size" sounds like a configuration
parameter, and as such should use the convention for parameter names (e.g., transfer-buffer-size in Courier font).
5. 1.1.4.2.1.2: In order to increase readability of the
requirement, commas should be placed between "size" and "expressed" and between "Buffer" and "shall".
6. 1.1.4.2.1.5: The second paragraph (When receiving an individual
un-buffered ..." should be given its own paragraph number.
7. 1.1.4.2.2.1, NOTE 2: The latency timer initial value is defined
by the processing-latency-limit parameter. Suggest making this NOTE more-direct by replacing "the latency timer initial value" to "the value of the processing-latency-limit parameter".
8. 1.1.4.2.2.3 states "The size of the Input Queue for incoming
PROCESS-DATA operations shall be defined by the service using this procedure ..." , but there is no requirement specifying the *units* of the Input Queue. In order for it to be used consistently with the Transfer Buffer, it must be defined in the same units - that is, a number of P-D invocations.
9. 1.1.4.2.2.4: "maximum" in "maximum Transfer Buffer size" is
redundant, since Transfer Buffer size (transfer-buffer-size) is defined as the maximum possible value.
10. 1.1.4.2.2.4, NOTEs: Is this behavior inherent in the procedures
themselves, in the abstract requirements on the underlying comm service, or of the TCP-based ISP-1? I think that this is driven by the constraints/behavior of ISP-1. Should these NOTEs make that point? (I think we've had a discussion on this before.)
11. 1.1.4.2.2.4, NOTE 3: The NOTE discusses multiple instances of
BDPP operated in complete mode, but the effects are more global - any other procedure that is part of a service that uses the BDPP will be subject to having its messages in the User-to-Provider direction blocked if/when the BDPP instance stops reading from the comm service. The NOTE should be generalized to addressed this larger issue.
12. 1.1.4.2.2.12, NOTE: I believe that the "Processing of Data
Units" is really intended to be the header of a new section (1.1.4.3?) If this is true, then the following paragraph (currently 1.1.4.2.2.13) should be 1.1.4.3.1.
C. SEQUENCE-CONTROLLED DPP
1. 1.1.2.2, third paragraph, and 1.1.4.2.3: These section
describe/require a behavior in which a P-D invocation with an out-of-sequence value in the data-sequence-counter parameter results in a rejection of the invocation. However, the SCDPP is derived from the DPP. Version 13 of which mandates that such a sequencing error result in a PEER-ABORT. NOTE that if the recommendation proposed above is adopted, the DPP would leave the behavior undefined so that the SCDPP could define it as it currently is (reject, not PEER-ABORT).
2. 1.1.5.2.1, Table 1-3: The table might be misinterpreted as
implying that the Standard Operation Header invocation parameters and the data-sequence-counter invocation parameter are also extension parameters.
Suggest putting "See Note" after the "M" in the invocation column for the Standard Operation Header and the data-sequence-counter, and follow the table with the following NOTE: "The parameters of the Standard Operation Header invocation and the data-sequence-counter invocation parameter are as specified for the Common PROCESS-DATA operation (<ref>) and are not extension parameters. They are shown in table 3-1 because they are extension parameters of the Return".
Best regards,
John
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
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.
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list