James Polk | 7 Apr 21:37 2014


please ignore

James Polk (jmpolk | 8 Apr 21:25 2014


test, please ignore
internet-drafts | 8 Apr 13:30 2014

I-D Action: draft-ietf-tsvwg-sctp-prpolicies-02.txt

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

   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:

There's also a htmlized version available at:

A diff from the previous version is available at:

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:

IETF Secretariat | 27 Mar 16:39 2014

Milestones changed for tsvwg WG

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/

Gorry Fairhurst | 25 Mar 08:43 2014

TSVWG has adopted draft-ietf-tsvwg-rtcweb-qos

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

ihab jabor | 18 Mar 12:00 2014

Fwd: SCTP Congestion Control

My name is Ihab ,
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.
I've been implemented SCTP through various simulation scenarios then I've been draw CWND also figure out many performance factors like throughput and queue size.   
I used SCTP RFC 2690 in NS2 which have been implemented by Protocol Engineering Lab in University of Delaware,
 kindly below the peace of C++ code regarding congestion control SCTP protocol which fetch from NS2 in addition some question notes.

Slow start::::
  1. {
  2.       spDest->iCwnd += MIN(spDest->iNumNewlyAckedBytes, (int)uiMaxDataSize);
  3.       tiCwnd++; // trigger changes for trace to pick up
  4.     }

Congestion avoidance

  1. if(spDest->iPartialBytesAcked >= spDest->iCwnd &&
  2.      spDest->iOutstandingBytes >= spDest->iCwnd )
  3.     {
  4.       DBG_PL(AdjustCwnd, "adjusting cwnd") DBG_PR;
  5.       if(spDest->iCwnd <= spDest->iPartialBytesAcked)
  6.           spDest->iPartialBytesAcked -= spDest->iCwnd;
  7.       else
  8.         spDest->iPartialBytesAcked = 0;
  9.       spDest->iCwnd += uiMaxDataSize;
  10.       tiCwnd++; // trigger changes for trace to pick up
  11.     }

kindly any recommendations or advice ...

Michael Ramalho (mramalho | 12 Mar 18:50 2014

Review of draft-tuexen-tsvwg-sctp-prpolicies-03.txt

[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.]




Michael (Tuexen),


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

3) Priority


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?


Michael Ramalho



gorry | 12 Mar 16:42 2014

TSV WG notes from IETF-89, london

Thanks to our note-takers!

I've now uploaded the notes and tried to cross-check with the audio


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)

Gorry Fairhurst | 12 Mar 16:35 2014

Standards language comments on draft-ietf-tsvwg-sctp-failover

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.

(tsvwg co-chair)



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
- 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 

"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 

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,"

"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.

gorry | 9 Mar 09:54 2014

TSVWG adopted draft-briscoe-tsvwg-ecn-encap-guidelines

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.

gorry | 9 Mar 09:47 2014

WG Adoption Call for draft-dhesikan-tsvwg-rtcweb-qos - 24th March 2014

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.