IETF Secretariat | 31 Oct 18:11 2014

Milestones changed for tsvwg WG

Changed milestone "Submit 'SCTP PR Polices' as a PS RFC", resolved as


Black, David | 29 Oct 16:42 2014

Preliminary Honolulu agenda posted

This is assignment of drafts to the two meeting sessions; time allocations
will be in the final agenda that is posted next week.

If you want tsvwg agenda time and haven't requested it yet, now would be a
good time to do so.  There is one request that showed up this morning that
the chairs haven't dealt with yet, so it's not reflected in this preliminary
tsvwg agenda.

HEADS-UP: The Tuesday conflict between the first tsvwg session and the new
IRTF Proposed Data Center Latency Control Research Group (dclcrg) session
is a serious problem that was overlooked in assembling the Honolulu IETF
meeting agenda.  Therefore:

*** The Tuesday tsvwg session is likely to be shortened and start late ***

Please do not complain to your WG chairs about this - we found out too
late to do anything about it.

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 <at>        Mobile: +1 (978) 394-7754

(Continue reading)

gorry | 29 Oct 15:01 2014

WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014


This is the start of a WGLC on "Quick Failover Algorithm in SCTP".

This WGLC will last until Wednesday, 19th November, 2014, this includes
the period of the coming IETF meeting.

A good note to the list is "I have read this version of the draft,
and I approve (or support) its progression to RFC". The chairs
request notes to the list showing support to get a sense of the WG.

Of course, you can ask for alternate text (where you supply the
actual replacement text, or convey the meaning sufficiently to the
authors) for anywhere in the document that you find unclear or troublesome.

TSVWG chairs

Andreas Terzis | 29 Oct 03:21 2014

New draft draft-flinck-mobile-throughput-guidance-00.txt

Hi all,

I want to draw your attention to a draft we submitted on using explicit information from the network about the capacity of the radio link available to a mobile device:

While the proposed mechanism is application-agnostic, we describe how it can be used for mobile video delivery. Moreover, we present test results from an end-to-end prototype developed for mobile video delivery. 

Your review and comments are appreciated

Best regards,

Andreas Terzis

Mo Zanaty (mzanaty | 29 Oct 02:18 2014


While reviewing this draft for becoming mandatory in rtcweb data channels, I see two issues, which are independent of rtcweb.

1. If negotiated, NDATA must be used for all messages. The NDATA format requires 8 more bytes than DATA (for MID+FSN). But these extra 8 bytes are only useful for fragmented messages. To avoid this overhead for small non-fragmented messages, can we relax / optimize this rule to be NDATA must be used for all *fragmented* messages, while non-fragmented messages continue to use DATA?

Proposed change to the next-to-last paragraph of section 1.1:

   The support of the N-DATA chunk is negotiated during the association
   setup using the Supported Extensions Parameter as defined in
   [RFC5061].  If N-DATA support has been negotiated for an association
   N-DATA chunks are used for all user-messages and no DATA chunks.  It
   should be noted, that an SCTP implementation needs to support the
   coexistence of associations using DATA chunks and associations using
   N-DATA chunks.

   The support of the N-DATA chunk is negotiated during the association
   setup using the Supported Extensions Parameter as defined in
   [RFC5061].  If N-DATA support has been negotiated for an association
   N-DATA chunks are used for all fragmented user messages, and
   DATA chunks are used for all non-fragmented user messages.  It
   should be noted, that an SCTP implementation needs to support the
   coexistence of associations using DATA chunks and associations using
   N-DATA chunks.

2. Fragmented messages can’t be interleaved. This significantly dilutes the value of NDATA. Apps that truly care about head of line blocking can’t rely on NDATA at all. They must implement app layer fragmentation with messages well below common MTUs to avoid blocking, hence defeating NDATA. NDATA is arguably harmful for these apps, since it is 8 bytes closer to exceeding the MTU, forcing SCTP fragments and hence risking HOL blocking. To avoid this, can we relax this rule to allow interleaving fragmented messages, since MID is already part of NDATA?

Proposed change to the last paragraph of section 3.1:

   The sender MUST NOT have more than one ordered fragmented message
   being produced in any one stream.  The sender MUST NOT have more than
   one un-ordered fragmented message being produced in any one stream.
   The sender MAY have one ordered and one unordered fragmented message
   being produced within a single stream.  At any time multiple streams
   MAY be producing an ordered or unordered fragmented message.

   The sender MAY have more than one ordered fragmented message
   being produced in any one stream.  The sender MAY have more than
   one un-ordered fragmented message being produced in any one stream.
   The sender MAY have multiple ordered and unordered fragmented messages
   being produced within a single stream.  At any time multiple streams
   MAY be producing multiple ordered or unordered fragmented messages.


Black, David | 29 Oct 00:45 2014

WGLC draft-ietf-tsvwg-port-use-05 : David Black's comments (2 of 2)

I've now gone back and reviewed my concerns and comments on this
draft expressed as a WG chair.  I think this version of the draft
is ok wrt those concerns and comments.  Specifically:

-1- Relationship to RFC 6335

This is now clear.  The -05 draft says in both the Abstract and
Introduction that it does not modify RFC 6335, and the draft
Introduction now describes one purpose of this draft as providing
guidance to applicants for port numbers.

-2- Secure and non-secure ports

I'm satisfied with the text on allocation of secure and non-secure
ports in Section 7.4 that resulted from discussion on the list.

-3- Scarcity

On balance, I think the case has been made that continuing to treat
ports as a somewhat scarce resource is a good thing to do in order
to avoid future problems caused by running out of ports.  We do not
face a port availability crisis in the near future in part because of
the effective manner in which port assignment has been functioning,
so encouraging it to continue to function in that effective manner is
a good thing to do.  The current port assignment process does treat
ports as a somewhat scarce resource.

In addition, some of the more contentious text on this topic in the
-04 version has been removed or toned down in the -05 version.

-- Process note

Between the material on allocation of secure and non-secure ports,
the discussion of firewall interactions, and other matters, this draft
contains significantly more security material than is typical for
tsvwg drafts.  For that reason I'm going to suggest that we (WG chairs)
explicitly ask for a security directorate review of this draft after
the RFC Publication request is submitted (working with our ADs to
figure out exactly when that request should be made).

We may also want to explicitly ask for an applications directorate

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 <at>        Mobile: +1 (978) 394-7754

Carry | 28 Oct 15:25 2014

Re: New Version Notification for draft-wei-tsvwg-tunnel-congestion-feedback-03.txt

I have had a review of the document, and there are some questions to be
1. It seems that after egress fed back the congestion volume information,
the ingress still won't have any information about the congestion
information on specific traffic flow?

2.In real deployment, more than one tunnels would be concatenated together
to form a path of traffic, so how to deal with this kind of situation?

- Jianning

Gorry Fairhurst | 27 Oct 15:43 2014

Change of intended publication status for draft-ietf-tsvwg-sctp-failover

This is a short note to confirm the change in the milestone for the 
intended publication status for draft-ietf-tsvwg-sctp-failover from EXP 
to PS.

There are several important changes that have taken place within the WG
that motivate this proposed change of status, and these were discussed 
at the TSVWG meeting in Toronto and on the list. Nobody objected to the

The changes are:

1)  The reason that it was proposed as experimental was due to that the 
work initially looked to address some more fundamental changes to the CC
operation of SCTP.

These intended changes are no longer part of the specification and
consequently the spec is fully aligned with the CC operation as 
specified in RFC4960.

2) In addition there might have been some concerns about the possibility 
for this mechanism to introducing path bouncing with potential harmful 
network impacts. These concerns, however, are believed to be unfounded 
as addressed in Appendix B

We expect this document to shortly sent for WGLC.

(TSVWG Co-Chair)

Gorry Fairhurst | 27 Oct 15:29 2014

TSVWG Status Summary October 2014

The list below shows the status of the working group documents as we see 
it. Please check below and comment on drafts using the list. Please do 
send any corrections/omissions to the chairs.

Gorry, David & James
(TSVWG Chairs)
October 2014

Document recently published:

IDs in RFC Editor Queue ( :

draft-ietf-tsvwg-rsvp-pcn - Document Shepherd: David

IDs in IESG processing:
draft-ietf-tsvwg-sctp-prpolicies - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-prpolicies
Nov 2013, Adopted SCTP PR Polices intended for publication as a PS RFC
March 2014, Next revision expected for WGLC.
Gorry read 20-May-2014, needs to be PS, explain Info section in wrietup
Revised ID May 2014.
1-Jul-2014 Gorry reviewed standards language
WGLC started to end July 21st, 2014
- support JHS, KN, MB, IR, GF; comments from Karen Nielson, Brian 
Bidulock, Gorry
Note: the socket API stuff, which is informational, is completely 
implemented in FreeBSD and will be released in FreeBSD 10.1
Revised ID after WGLC
All Authors responded to IPR check.
WG Shepherd write-up 27th Oct 2014

New proposed work:
draft-eggert-tsvwg-rfc5405bis (adoption request soon)
draft-geib-tsvwg-diffserv-intercon-02.txt (next version expected to be 
called for adoption)

WG Drafts with Chairs:
draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry
Replaces: draft-tuexen-tsvwg-sctp-dtls-encaps-01
WG adopted 13/12/2013. Support {AB, IR, SL, MB, TD}
[Milestone: Jan 2014, PS] Implemented in Firefox (FF21).
Required by RTCweb. Comments received.
WGLC ended 28th February 2014.
Comments from Joe Touch (draft updated)
Review comments and revised ID published.
Eric Rescorla has reviewed this.
WAITING: Waiting for one author (R. Jesup) to confirm IPR
DUE: Security input needed to determine text describing DTLS version and 
how to deal with DTLS versioning.

draft-ietf-tsvwg-port-use - Document Shepherd: Gorry
Replaces: draft-touch-tsvwg-port-use-00
- Intended to be advice to protocol designers needing a port.
5 people looked at this document, Prague IETF-80
Individual -01 July 2011
IETF-81 insufficient feedback from WG at this time.
IETF-82, discussed.
Adopted by WG Presented IETF-86, March 2013
Milestone updated to June 2014
Mar 2014, Chairs WGLC to be started after current WG actions.
- IANA review comments received
- Sent review requests to RAI, APPS, and SEC areas during 1st WGLC.
+ Comments May 2014: Paul Hoffman; Lars Eggert; IANA; David Black;
5 Jun 2014, WGLC completed - comments received.
Revised ID after WGLC; Elliot OK with changes;
DUE:  Working Group Last Call for comments 14/10/2014, due to conclude 

draft-ietf-tsvwg-sctp-failover - Document Shepherd: James (backup 
shepherd: gorry)
Replaces: draft-nishida-tsvwg-sctp-failover
Individual-00 Presented in Prague, IETF-80.
- Understood not to conflict with draft-tuexen-tsvwg-sctp-multipath
- PF has been implemented in FreeBSD; Linux SCTP implements partially, 
that they intend to implement full support and have no comments to the 
technical solution; Ericsson have an implementation;
Adopted by WG 26/6/2012. [Milestone: Jul 2013, EXP]
Thought ready for WGLC, four people volunteered to review.
Review done by GF with a view to the milestone becoming PS.
++ Committed reviewers : Michael Tuexen (more if possible)
Milestone update request to AD/IESG sent Oct 2014
Due: WGLC to be started in Nov 2014.

WG Drafts
Replaces: draft-polk-tsvwg-rsvp-app-id-vv-profiles
-01 Presented in Beijing, IETF-79.
-02, 14-Mar-2011
Presented IETF-80.
Seek to coordinate with music with partner ID:
Gorry liaised with MMUSIC WG Chairs on companion draft (norm ref from 
this tsvwg draft).
Adopted as a TSVWG work item, December 2013, [Milestone Jul 2013].
This will update a RFC 2872 (PS).
Presented at IETF-86,
Mar 2013 (no comments)
Expected ready for WGLC (waiting on MMUSIC)
DUE: Reviewers are needed to prepare for a WGLC
draft-ietf-tsvwg-sctp-ndata - PS
- replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013,
Adopted , intended for publication as a PS RFC
Mar 2014, 5-6 people had read.
Named changed proposed at IETF-90 (Interleaved data?) and clarification 
of use-case.
DUE: Revised ID needed.
draft-tsvwg-gre-in-udp-encap - PS Document Shepherd: David
- replaces: draft-yong-tsvwg-gre-in-udp-encap
Dec 2013, Adopted , intended for publication as a PS RFC
Feb 2014, discussion of scope and applicability of circuit breakers
Mar 2014 consider MUST implement, SHOULD use in these environments for CB
DUE: Revised ID needed to address congestion control and UDP Zero 
Checksum for IPv6.  Revised text has been developed for MPLS-in-UDP 
draft, but needs adaptation and generalization for GRE (vs. MPLS).
DUE: Revised ID expected for Honolulu with initial adaptation - expect 
to discuss generalization in meeting.
draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David
- Replaces: draft-dhesikan-tsvwg-rtcweb-qos
- RTCweb and QoS Markings
- Authors requested TSVWG adoption.
- Who has read the draft? (lots 10's of people)
25-Mar-2014, Adopted by tsvwg
- Who thinks it is important to do work in the IETF? (Many)
I-D updated after initial TSVWG feedback
Mar 2014, Adoption call (strong support in WG meeting London)
Adoption call concluded 24 Match 2014: intended as a PS RFC for Sept 2014
++ Magnus agreed to review this.
Early OPS-Dir review received from Fred Baker.
Oct 2014, DART draft (draft-ietf-dart-dscp-rtp): IETF LC completed, now 
in IESG evaluation.
DUE: Please comment on list, and see DART draft as related material.
draft-ietf-tsvwg-circuit-breaker - Document Shepherd: TBD
Call for WG adoption issued - August 2014, adopted 28th Aug.
Milestone set - Oct 2014 (by David Black)
DUE: Please comment on list

Expired WG documents:

draft-ietf-tsvwg-ecn-encap-guidelines - Document Contact: Gorry
replaced draft-briscoe-tsvwg-ecn-encap-guidelines
-00 Presented in Prague, IETF-80.
- comments at IETF-80 (see minutes)
New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89
++ forward an appropriate message (perhaps your note to the mailing list 
for approval to adopt) to ieee-ietf-coord <at>
++ Reviewers: Andrew McGregor, Dirk Kutscher, Richard Scheffnegger, 
Brian Tramwell.
Mar 2014, WG Call for adoption started, to end 4th March 2014
19 for, 1 against. 8 echoed on the list
Adoption call concluded and document adopted.
* ecn-encap-guidelines and AQM are the main new things they need to know 
on <>IEEE802.1Q)
DUE: Please comment on list.
draft-ietf-tsvwg-intserv-multiple-tspec - Document Shepherd: David
WG interest in this topic recorded at IETF-78.
Charter update needed to progress this work.
5 Reviews needed to determine energy/technical direction.
WG -05 (presented in Beijing, IETF-79)
WG -06 (presented in Prague, IETF-80)
2 reviews from RSVP-DIR received (Bruce Davie, ?)
2 additional reviews promised (Ken Carlberg, Francois LeF)
Chairs asked AD for a Charter update (IESG agreed)
Draft discussed at IETF-80, and request to update charter agreed
- AD advised 4 named reviewers will be required
Adopted for progression as PS, for May 2012
- New name: 'RSVP Multiple Instance'.
Draft is now expired and dead.
DUE: Draft authors will request replacement with 
draft-polk-rsvp-multi-instance-object (and WG adoption of that draft in 
Honolulu, IETF-91)
draft-ietf-tsvwg-natsupp - Document Shepherd: James
Replaces: draft-stewart-natsupp-tsvwg
Dependency from BEHAVE WG.
Adopted as a work item 21 Sept 2010 (Gorry).
WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg
Authors restructured draft (-03)
Added support for single and multi-homed support.
IETF-86: 3 people in meeting had read -04 or -05.
Feb 2014, Authors please update following comments and align to related 
draft on SCTP NAT (conflicts found in language)
Authors expected to produce a single document to replace both.
++ Dan Wing has committed to review this.
++ Fred Baker has committed to review this.
Chairs: We plan to start a WGLC, but are expecting this document to be 
restructured and merged with draft-ietf-tsvwg-sctpnat
draft-ietf-tsvwg-sctpnat - Document Shepherd: Gorry
Will replace: draft-ietf-behave-sctpnat-03.txt Adopted Nov 2013.
Former BEHAVE WG work item that defines SCTP NAT support
Feb 2014, Authors please update following comments and align to related 
draft on SCTP NAT (conflicts found in language)
Chairs: - authors have requested a single document to replace both.
++ Fred Baker will review next version.
Separated the simpler case for single-homed use - this separation should 
be clearer
Chairs: We plan to start a WGLC, but are expecting this document to be 
restructured and merged with draft-ietf-tsvwg-sctpnat
draft-ietf-tsvwg-behave-requirements-update - Document Shepherd: David
Replaces: draft-ietf-behave-requirements-update-00
Nov 2013, Former BEHAVE WG work item intended for publication as a BCP
Mar 2014, Irene R reviewed this and found no conflict with SCTP drafts.
Some suggestions (in no particular order) for a shepherd:
++ Dave Thaler, may review, as former behave co-chair
++ David Harrington, has been around in behave, and he knows how to do 
this and volunteered multiple times.
++ Ask Jana to review this.
++ Dan has committed to review this.
Chairs: Check intention and planned timeline.
DUE: Please comment on list
The following have received recent discussion at TSVWG meetings or on
the list. Inclusion in the list below does not indicate support for
these specific drafts and other contributions are also warmly welcomed.
Authors request to be considered for adoption
draft-geib-tsvwg-diffserv-intercon - Document Contact: David
DiffServ interconnection classes
New ID presented in Atlanta, IETF-85.
ID presented in Orlando, IETF-86, Mar 2013. Mar 2014, intended scope 
unclear at IETF London Adoption call to be considered, but scope needs 
to be first refined and a revised draft is necessary to avoid 
implications of broader applicability.
July 2014 - ID presented in Toronto. Strong hum of support to work on 
this, but a revised draft is needed first.
DUE: revised draft required, WG adoption call expected on that next version.
- Individual (Gorry & Lars)
Mar 2014, the ADs proposed the WG re-open the UDP Guidelines RFC for 
update to include this work and other topics.
The authors of both drafts agreed to progress this work.
NOTE: Update milestone in charter, if adopted: ‘Multicast UDP 
Guidelines’ is being incorporated in this.
Presented IETF-90, Hum supporting adoption, none against.
++ Brian Tramwell and Jana agreed to review this.
Chairs:Adoption call to be started on list.
- Individual (no decision to adopt at this time)
- QoS-aspects to be discussed in tsvwg (thought to also be relevant to 
- Thought to fall within TSVWG charter
--- draft-lai-tsvwg-normalizer
- Thought to fall within TSVWG charter
- Presented IETF-88 ---
Discussed at IETF-84, Vancouver
This draft is related to the new rmcat work.
Comments received on list prior to IETF-85. Comments IETF-90.
Authors request WG adoption at IETF-90
Request for people to read this ID, need more review comments.
DUE: Revised ID needed
replaces draft-welzl-ecn-benefits, Individual (Michael Welzl)
- Thought to be within tsvwg or aqm WGs.
- Has been adopted as a work item in AQM, may be WGLC'ed in both.
- Please discuss on AQM WG List

Re: SCTP mis indication counting during Fast Recovery

Hi Randy,


Thanks a lot for the willingness to continue this discussion !!

Please see below.



From: Randall Stewart [mailto:rrs <at>]
Sent: 24. oktober 2014 20:24
To: Karen Elisabeth Egede Nielsen
Cc: bidulock <at>; Michael Tuexen
Subject: Re: [tsvwg] SCTP mis indication counting during Fast Recovery




I think the reason is because you only *know* the receivers perspective

based on the SACK.

[Karen] This I think is the case for Highest Newly Ack’ed part of the algorithm.


But this part


(#) If an endpoint is in Fast

   Recovery and a SACK arrives that advances the Cumulative TSN Ack

   Point, the miss indications are incremented for all TSNs reported

   missing in the SACK.


which is NOT stipulating new SACK information, necessarily addresses the senders perspective of having retransmitted the TSN now newly cumulatively Ack’ed.

The motivation for the increase of the mis indication count of the non-SACK’ed TSNs up  until the highest’es SACK indeed is that this TSN, i.e., the newly cum Ack’ed TSN, have been sent and received after the non-SACK’ed TSNs up  until the highest SACK.


This must be the only reasonable way to interpret this sentence given we already have the Highest Newly Ack’ed algorithm.


Correct ?


Sure you may have sent two tailing TSN’s in a packet 

at the same time (your case I think) as you sent the other packets.. <or> you may

have *just* sent the trailing two TSN’s..

[Karen] Yes you MAY just have sent them. Still you send them before entering FR (!)


(My assumption is for increase of mis indication count only up to and including FR Exit point).


you don’t know if the receiver has had time

to get them or not..

[Karen] Well at least you have retransmitted a lost TSN which now gets cumack’ed,

and this retransmitted TSN was sent after the trailing TSNs.

This is the same argument used for the non-SACK’ed TSNs up  until the highest’es SACK


The idea is that I can only base my incrementing of the gap’s based on what is in the SACK.. not

based on what I sent.

[Karen] Then you should not have the prescription (#) in the first place. Should you ?


Either way one is looking at an Errata – or where did I go wrong ?


BR, Karen



On Oct 23, 2014, at 11:23 PM, Karen Elisabeth Egede Nielsen <karen.nielsen <at>> wrote:

discussion as closed, we/I will get what we/I want from RFC6675 additions to SCTP.


However, getting these arguments from you, then out of curiosity, I wonder if you have the time and

the strength to explain the motivation for the existing text of RFC4960 saying:


If an endpoint is in Fast Recovery and a SACK

arrives that advances



Randall Stewart






Jose Saldana | 27 Oct 10:36 2014

An implementation of TCM

Hi all,


We have just finished an implementation of TCM.


The implementation is simple, but it works. Its name is “Simplemux”. It runs in Linux. It is programmed in C, and makes use of TUN/TAP. It is here:


It is able to:


- compress headers with ROHC (using this implementation:

- multiplex a number of packets using separators (something similar to PPPMux)

- the tunnel is naïve at this stage: just an IP/UDP header using port 55555


- It implements four different policies for selecting which packets will be multiplexed together: period, timeout, number of packets and packet size limit.



The plan is to perform some tests with real traffic. We will report the results in this list. If someone else is interested on collaborating and/or doing some tests, do not hesitate to contact me.


Best regards,


Jose Saldana