Michael Tuexen | 22 Jul 16:21 2014

Name of the new DATA chunk

Dear all,

it was suggested to use I-DATA chunk for Interleaving DATA chunk as a better
name for the chunk defined in

Any opinons?

Best regards

Fred Baker (fred | 22 Jul 16:18 2014

Text from RFC 3246 regarding excess traffic

   The EF PHB is intended to be a building block for low loss services.
   However, under sufficiently high load of EF traffic (including
   unexpectedly large bursts from many inputs at once), any device with
   finite buffers may need to discard packets.  Thus, it must be
   possible to establish whether a device conforms to the EF definition
   even when some packets are lost.  This is done by performing an
   "off-line" test of conformance to equations 1 through 4.  After
   observing a sequence of packets entering and leaving the node, the
   packets which did not leave are assumed lost and are notionally
   removed from the input stream.  The remaining packets now constitute
   the arrival stream (the a_j's) and the packets which left the node
   constitute the departure stream (the d_j's).  Conformance to the
   equations can thus be verified by considering only those packets that
   successfully passed through the node.

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded.  This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration).
Adrian Farrel | 22 Jul 14:56 2014

Progressing foo-over-UDP

In London I took an action to write up suggested text for how to handle the
concerns of congestion and checksum in UDP-over-foo.

I think we had some agreement of what was needed (look at the minutes of TSVWG -
or was it TSV Area? - from London).

Of course, I have let you all down. I have about 75% of the necessary text for
MPLS-over-UDP (as a concrete example), but I am not complete. You don't need to
know my excuses.

Attached below (so you can laugh at me) is the text I have so far. it is work in
progress, but since I am currently getting in the way, some of you might want to
take the pen (if no-one wants to, I will try to continue and complete this).



x.  Applicability and Deployment of MPLS-in-UDP

   It is helpful to categorise the type of networks in which this
   solution might be deployed.  That is, it is useful to look at the
   type of network over which the UDP tunnel might run, and the type of
   network that may be running MPLS.  An understanding of these 
   categories will lead to the realization that deploying MPLS-in-UDP in
   some environments is entirely safe, in other scenarios might cause 
   issues to the networks involved but is a local choice for the 
   operators of those networks, while in other situations the deployment
   might be significantly harmful to other services or traffic outside
(Continue reading)

Black, David | 20 Jul 21:19 2014

Toronto Tue agenda posted, send slides!!

The tsvwg agenda for Tuesday (both sessions) was posted a while back:


Those presenters who haven't already sent slides (thank you to those who
have) should send slides ASAP, by mid-day Monday at the latest please.

If the tsvwg meeting starts on Tuesday w/o slides for an agenda item,
the chairs may impose a 3-5min time limit for a brief verbal summary + Q&A.

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

Karen E. Egede Nielsen | 20 Jul 16:34 2014

comments to RFC3758



Having studied RFC3758 in a little detail (in connection with draft-ietf-tsvwg-sctp-prpolicies)

then there is an issue with the present document text, which I think deserves

clarification. Or at least I am not sure about how to interpret the text.


I hope that the wg may help guide on what the right clarification/understanding is.


The issue relate to handling of the flightsize and the calculated

receiver window rwnd when abandoning a message and/or receiving a (S)ACK of the Forward TSN, respectively.


The rule A2) (section 3.5) says:



       When a data chunk is "abandoned", the sender MUST treat the data
       chunk as being finally acked and no longer outstanding.


This MUST clearly must not be taken literally as it indeed is being disclaimed by a number of following

recommendations given:


Section 3,5, A2)


       The sender MUST NOT credit an "abandoned" data chunk to the
       partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2],
       and MUST NOT advance the cwnd based on this "abandoned" data


Section 3,5 F5)


       If the decision to "abandon" a chunk is made, no matter how such
       a decision is made, the appropriate congestion adjustment MUST be
       made as specified in RFC 2960 if the chunk would have been marked
       for retransmission later (e.g., either by T3-Timeout or by Fast



What I would have like to see, however, would be some disclaimers and/or more explicit descriptions of what

to do/or not do with with the flight-size and the calculated rwnd when a message is abandoned.


Here there are clearly 2 options in terms of how to interpret the “MUST treat as no longer outstanding”:


From a conservative congestion control perspective then I would opt for that the data chunk should not be taken out of the flightsize and sliding window protocol variables before a SACK of the TSN/respectively of the FORWARD TSN has been received (conditional to F5).


Alternatively if the intend of RFC3758 is to have an abandoned TSN be taken out of flight-size immediately, then I first and foremost think that

the implication via-a-vis congestion control should be explicitly described in the document (if the message is in-flight one is in fact overshooting the cwnd) and secondly then for the sender not to send outside of rwnd, one would then want to more stringently specify that a delayed FORWARD TSN MUST be sent no later than with the first data chunk after the abandon of a message. This may be the intend of C3) and F2) of the document, but it is not written explicitly.


Thanks in advance.


BR, Karen





Michael Welzl | 14 Jul 00:15 2014



This is just a heads-up, that Gorry & I will briefly present draft‐welzl‐ecn‐benefits-01 at TSVWG.


internet-drafts | 4 Jul 21:54 2014

I-D Action: draft-ietf-tsvwg-rsvp-app-id-vv-profiles-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           : Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams
        Authors         : James Polk
                          Subha Dhesikan
	Filename        : draft-ietf-tsvwg-rsvp-app-id-vv-profiles-02.txt
	Pages           : 15
	Date            : 2014-07-04

   RFC 2872 defines an Resource Reservation Protocol (RSVP) object for
   application identifiers.  This document uses that App-ID and gives
   implementers specific guidelines for differing voice and video
   stream identifications to nodes along a reservation path, creating
   specific profiles for voice and video session identification.

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:

internet-drafts | 4 Jul 19:55 2014

I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-05.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           : DTLS Encapsulation of SCTP Packets
        Authors         : Michael Tuexen
                          Randall R. Stewart
                          Randell Jesup
                          Salvatore Loreto
	Filename        : draft-ietf-tsvwg-sctp-dtls-encaps-05.txt
	Pages           : 8
	Date            : 2014-07-04

   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol originally defined to run on top of the network protocols
   IPv4 or IPv6.  This document specifies how SCTP can be used on top of
   the Datagram Transport Layer Security (DTLS) protocol.  Using the
   encapsulation method described in this document, SCTP is agnostic
   about the protocols being used below DTLS, explicit IP addresses can
   not be used in the SCTP control chunks.  As a consequence, the SCTP
   associations are single homed.

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:

Ruediger.Geib | 4 Jul 13:41 2014

WG: New Version Notification for draft-geib-tsvwg-diffserv-intercon-06.txt

Dear TSV WG,

after a discussion with Fred Baker and David Black, I've revised my draft. I've clarified that it supports a
1:1 DSCP mapping at interconnection points and that an n:1 DSCP mapping is not supported. Further it goes
into more details on limitations on DSCP mappings resulting from MPLS deployment (in particular Short
Pipe MPLS model for non tunneled IPv4 traffic).

Discussion with Fred and David is ongoing, please don't interpret the above as 'having reached consent'. 



-----Ursprüngliche Nachricht-----
Von: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Gesendet: Freitag, 4. Juli 2014 13:31
An: Geib, Rüdiger; Geib, Rüdiger
Betreff: New Version Notification for draft-geib-tsvwg-diffserv-intercon-06.txt

A new version of I-D, draft-geib-tsvwg-diffserv-intercon-06.txt
has been successfully submitted by Ruediger Geib and posted to the IETF repository.

Name:		draft-geib-tsvwg-diffserv-intercon
Revision:	06
Title:		DiffServ interconnection classes and practice
Document date:	2014-07-04
Group:		Individual Submission
Pages:		16
URL:            http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffserv-intercon-06.txt

Status:         https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/

Htmlized:       http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-intercon-06

Diff:           http://www.ietf.org/rfcdiff?url2=draft-geib-tsvwg-diffserv-intercon-06

   This document proposes a limited and well defined set of QoS PHBs and
   PHB groups to be applied at (inter)connections of two separately
   administered and operated networks.  Many network providers operate
   Treatment Aggregate of different DiffServ classes.  This draft offers
   a simple and constrained interconnection concept which may simplify
   operation and negotiation of DiffServ at interconnection points.


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.

The IETF Secretariat

gorry | 3 Jul 15:01 2014

TSVWG - Request for Agenda Items for Toronto meetings

Hi tsvwg'ers,

This is a request for people to offer presentations on drafts to be
presented to the tsvwg working group at the Toronto IETF.

I've upload a very initial agenda here:

Many of the talks are marked TBC (editors please confirm). We do have
space to discuss additional drafts.

Please send all requests and any corrections to the chairs asap.

Gorry, David and James
(tsvwg co-chairs)

Weixinpeng | 3 Jul 11:37 2014


Hi all,

A new version of draft-wei-tsvwg-tunnel-congestion-feedback-02 is submitted.

Comments are welcomed!



Best Regards,




Name:               draft-wei-tsvwg-tunnel-congestion-feedback

Revision:  02

Title:                  Tunnel Congestion Feedback

Document date:       2014-07-03

Group:               Individual Submission

Pages:               18

URL:            http://www.ietf.org/internet-drafts/draft-wei-tsvwg-tunnel-congestion-feedback-02.txt

Status:         https://datatracker.ietf.org/doc/draft-wei-tsvwg-tunnel-congestion-feedback/

Htmlized:       http://tools.ietf.org/html/draft-wei-tsvwg-tunnel-congestion-feedback-02

Diff:           http://www.ietf.org/rfcdiff?url2=draft-wei-tsvwg-tunnel-congestion-feedback-02



   This document describes a mechanism to calculate congestion of a

   tunnel segment based on RFC 6040 recommendations, and a feedback

   protocol by which to send the measured congestion of the tunnel from

   egress to ingress router. A basic  model for measuring tunnel

   congestion and feedback is described, and a protocol for carrying the

   feedback data is outlined.