I-D Action: draft-ietf-tsvwg-sctp-prpolicies-02.txt
2014-04-08 11:30:31 GMT
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol Authors : Michael Tuexen Robin Seggelmann Randall R. Stewart Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-prpolicies-02.txt Pages : 7 Date : 2014-04-08 Abstract: This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-prpolicies-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
Milestones changed for tsvwg WG
2014-03-27 15:39:31 GMT
Added milestone "Submit 'DSCP packet markings for RTCWeb QoS' to IESG as a Proposed Standard RFC", due September 2014. URL: http://datatracker.ietf.org/wg/tsvwg/charter/
TSVWG has adopted draft-ietf-tsvwg-rtcweb-qos
2014-03-25 07:43:23 GMT
The chairs judge the consensus of this WG is to adopt: draft-dhesikan-tsvwg-rtcweb-qos with the intention of publishing this as a Proposed Standard. Authors: Please upload a new revision of the draft, updated by the discussion at the London IETF meeting as "draft-ietf-tsvwg-rtcweb-qos" Gorry, James, & David TSVWG Co-Chairs
Fwd: SCTP Congestion Control
2014-03-18 11:00:45 GMT
I will be gratitude for you help in advance, my research focus on Congestion control of SCTP actually I'm workout develop and optimize the slow start and congestion avoidance in SCTP.
kindly below the peace of C++ code regarding congestion control SCTP protocol which fetch from NS2 in addition some question notes.
- spDest->iCwnd += MIN(spDest->iNumNewlyAckedBytes, (int)uiMaxDataSize);
- tiCwnd++; // trigger changes for trace to pick up
- if(spDest->iPartialBytesAcked >= spDest->iCwnd &&
- spDest->iOutstandingBytes >= spDest->iCwnd )
- DBG_PL(AdjustCwnd, "adjusting cwnd") DBG_PR;
- if(spDest->iCwnd <= spDest->iPartialBytesAcked)
- spDest->iPartialBytesAcked -= spDest->iCwnd;
- spDest->iPartialBytesAcked = 0;
- spDest->iCwnd += uiMaxDataSize;
- tiCwnd++; // trigger changes for trace to pick up
kindly any recommendations or advice ...
Review of draft-tuexen-tsvwg-sctp-prpolicies-03.txt
2014-03-12 17:50:13 GMT
[Everyone except Michael: I volunteered to be a reviewer on the SCTP "PR-policies" draft while at the IETF in London. This exchange between me and Michael Tuexen are a part of that review process.]
Re: "... the RTCWeb guys [don't want the combination of timed reliability and lifetime] "
Re: " The current API allows you only to have a single parameter... So we would not define a "generic combination" of existing policies, but a single new policy having two parameters and having the semantics of combining two existing policies."
If the current API allows you only to have a single parameter, then I presume (by extension) that you cannot have priority (this draft) and timed reliability (RFC 3758) combination either.
I am SURE that if you asked the "RTCWeb guys" if they wanted that particular combination that they would have said YES!
Indeed, I was on a call just yesterday where priority within a PR-SCTP stream was discussed (where they assumed "timed-reliability" was in effect). This is of particular use for video (and video encoding in screen sharing modes).
So, I see we have (at present) three dimensions of PR policy:
1) Timed Reliability
2) Limited Retransmissions
For the record, I don't think people will come up with additional policies for a specific stream ... but there is something I don't like about your proposal to create another policy that is a combination of two or three of the existing ones because of the combinatorics involved (individual policies for 1&2, 2&3, 1&3, 1&2&3). One more policy and that gets untenable!
Since the "retransmission decision" is conditioned by policy ... (presumably a break from within an "if and if else" portion) ... I don't see the combination as being particularly hard in code.
Is the issue here simply that you don't want to make the new API a little more complex? Or backward compatibility?
I think the key point here is that at least "priority" and "timed reliability" are probably desired together. What do others think?
TSV WG notes from IETF-89, london
2014-03-12 15:42:15 GMT
Thanks to our note-takers! I've now uploaded the notes and tried to cross-check with the audio recording: http://www.ietf.org/proceedings/89/minutes/minutes-89-tsvwg Please check and send the Chairs an email if you think there are changes needed (if something was said not reflected correctly)! Best wishes, Gorry, David and James (tsvwg co-chairs)
Standards language comments on draft-ietf-tsvwg-sctp-failover
2014-03-12 15:35:11 GMT
This document was presneted at the IETF meeting in Londin and I am performing a review to understand the request to update the document status to PS. Please do not take this as crictism of the propsed method, it is not. This document needs a much clearer abstract that sets the scope, rather than motivates an update. I also need to see a document with stronger standards recommendations to proceed with a more detailed review. Gorry (tsvwg co-chair) ---- Abstract. I think the abstract needs to be more clearly worded: "However, if the SCTP standard is followed, there can be a significant delay during the migration. During this period, SCTP might not be able to transmit much data to the peer. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of the SCTP failover mechanism and specifies an alternative failover procedure for SCTP that improves its performance during and after failover. The procedures require only minimal modifications to the current specification." - This reads like a proposal, instead you should be clear about what this document as an update offers, rather than trying to justify the change. I think this document updates RFC 4960. - If it does, then is the mechanism that you describe here an OPTIONAL extension to the spec, or a REQUIRED update to the spec. I think it is the former. I also understnad that this is a sender-side only change, and that it does not impact the SCTP receiver, is this correct. These details need to be clear in the abstract and also the introduction to this ID. --- Section 2 defines terminology, but then section 3,4 seem purely informative. I'd personally prefer to see the RFC 2119 declaration at the start of section 5, and clearly state at the start of section 5 that it defines the normative update. --- Section 3. It may be worth adding a starting sentence, saying that "this section provides an informative review of the need for this update". You could also add "This assumes familiarity with the terminology in [RFC4960]." --- Section 4 - I do not really understand what your intent is with this sentence: " The following approaches are conceivable for the solutions of this issue." - Are these previously proposed approaches? - Do these contradict the RFCs published. - Does the WG (or authors) have any opinion about the suitability of deploying these 2 methods in the general Internet? Section 4.1 "ignores several recommendations in [RFC4960]." (1) OK, I could read RFC 4960, but then I would prefer just to ask: What do you mean by "ignores", are these RFC 2119 recommendations, or just discussed items. (2) Maybe the text you are looking for is that it "would contradict recommendations in [RFC4960]."? - I assume each is called out in turn later in the document? - So does this conclude that these approaches are not recommended? Section 4.2 "However, if we can choose smaller value" ^^^^^^^^^^^^^^ - could we change this to "However, if the sender uses a smaller value" "can contribute to keep RTO value small." - is this better witten as: "can contribute to a small RTO value." - I'm assuming this is not deisrable due to increased probability of RTO expiry, but you don't say? - please explain what this causes. "although it needs to ignore several recommendations described in the Section 15 of [RFC4960]." - as above, ignoring? what? - is this actually updating? - So does this conclude that these approaches are not recommended? --- Section 5.1 (first part) The first part appears to define a different approach. Is this intended as the proposed update, or is an alternative like other methods in section 4. I'm unclear. Section 5.1 (second part) "tweaking the PMR value" is this "tuning the PMR value"? "between Active and Failed states." ^ - insert /the/ "detection procedure is modified" ^^^^^^^^ - Probably clearer to say as: "This document updates SCTP's failure detection procedure to include the PF state." "address will be incremented" ^^^^^^^ - address MUST be incremented. " 3. The sender SHOULD avoid data transmission to PF destinations." - You say SHOULD - can you give examples of when not to do this? " When all destinations are in either PF or Inactive state, the sender MAY either move the destination from PF to Active state (and transmit data to the active destination) or the sender MAY transmit data to a PF destination. " - You say MAY ... or MAY ..., I don't understand this construct - I suspect that you mean MUST do either this ... or this .... "It is recommended" - is that a SHOULD, i.e. RECOMMENDED - or can you rephrase this as an example. "In case of a tie" ^ - insert /the/ "with same error" ^ - insert /the/ "the sender MAY choose the last active destination." - I am not sure I understand the MAY here, the need I think is to specify an outcome for a tie, and this is one example. I don't see that MAY is helpful, either give it as ane example, or say SHOULD and provide a counter example when it is not true. "4. Only heartbeats MUST be sent to PF destination(s) once per RTO." - I don't understand the "MUST" - Is it that "heartbeats MUST be sent to PF destination(s) once per RTO" or is it something else? "If an heartbeat is unanswered, the sender increments the error counter and exponentially backs off the RTO value. " - Isn't this part of the spec: /increments/MUST increment/ "If error counter is" ^ - insert /the/ "5. When the sender receives an heartbeat ACK from a PF destination, the sender clears the destination's error counter and transitions the PF destination back to Active state." - There is no requirement, could we change "clears" to "MUST clear" " The sender should perform slow-start as specified in Section 7.2.1 of [RFC4960] when it sends data on this destination." - should? - why only should and not MUST? "6. Additional (PMR - PFMR) consecutive timeouts on a PF destination confirm the path failure, upon which the destination transitions to the Inactive state." /transitions/MUST transition/ "This proposal recommends " - Is this an example, or a real recommendation? - It is anyway not a proposal when published... Suggest /This update RECOMMENDS/ "In case of a tie (multiple Inactive destinations with same error count), the sender MAY choose the last active destination." - As above, I am not sure I understand the MAY here, the need I think is to specify an outcome for a tie, and this is one example. I don't see that MAY is helpful, either give it as ane example, or say SHOULD and provide a counter example when it is not true. "9. SCTP shall provide the means to expose the PF state of its" /SCTP shall/an SCTP sender MUST/ ? destinations as well as SCTP SHOULD notify the ULP of the state /as well as SCTP SHOULD/In addition, an SCTP sender SHOULD transitions from Active to PF and from PF to Active state. "SCTP can provide the means to suppress exposure of PF state and" /SCTP can/An SCTP sender MAY/ "PF state to ULP" ^ - insert /the/ /if quick/ ^ - insert /the/ "there is no serious problem with SCTP in terms of path" - This isn't clear to me, I think you need to explain what was tested and why this does not pose a problem - are the tests for performance? conenctivity? and in what conditions? - Are you claiming therefore that there is no risk when used in the general Internet? or there is no evidence of problems in the general Internet? - I'm not sure. If I understand, Section 5.2 appears to describe why someting is not an issue - this is good to have, but it seems a little odd in the middle of the spec. Section 5.3 * I have not understood if this is a REQUIRED part of the update, an optional part or what. Is this section also normative? "Post failover then, by [RFC4960] behavior, an SCTP sender migrates - Found this hard to follow. - Could it mean "When the original path (primary) is restored after a failover, [RFC4960] requires the SCTP sender to migrate..." "in scenarios where this path's characteristics are better." - is this the original (primary) or the failover path, sorry for being dense. "it as new primary.' ^ - insert /the/ Failover allows SCTP sender to continue ^ - insert /an/ "Details, as originally outlined in [CARO02], are:" - if this is part of this ID, then you need to ammed the wording to not be ambiguous about the spec. For example. "[CARO02] described a description of a method. This update requires the following:" Please use MUST SHOULD MAY RECOMMENDS carefully in this list of 4 points. 1. suggest you chnage / the SCTP implementation autonomously selects/ to /the SCTP sender MUST selects/ 2. /shall/MUST/ 3. /recommended/RECOMMENDED/ 4. /It must be/It MUST be/ "We recommend that SCTP-PF should stick to the standard RFC4960 behavior as default," suggest: "The default behaviour for an SCTP-PF implementation is to use the standard method sepcified in RFC4960." --- Section 7. You should state the security considerations of RFC 4960 also apply to this document. This document does not raise new security concerns.
TSVWG adopted draft-briscoe-tsvwg-ecn-encap-guidelines
2014-03-09 08:54:45 GMT
The TSVWG Chairs have considered adoption of the above draft, and the WG call for adoption has now concluded. The recent London IETF meeting confirmed support from the people present in the meeting room, and the consensus was to adopt this as a WG item. The authors were asked to submit a revised ID to the ID-archive. Comments are welcome on this document. Gorry, James, and David TSVWG Co-Chairs.
WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos - 24th March 2014
2014-03-09 08:47:12 GMT
The TSVWG Chairs are considering adoption of the above draft. This draft has been discussed at previous IETF meetings and on the list. At the recent London IETF meeting it received strong support from the people present in the meeting room, and no comments against adopting this draft as a TSVWG work item. The WG chairs now invite any further comments on this adoption. If there are concerns or comments about adoption please send comments to the list or to the Chairs. We plan to make a final decision on this adoption on 24th March 2014. Gorry, James, and David TSVWG Co-Chairs.