Bob Briscoe | 26 Mar 21:07 2015

Added 'Rule #1' to draft-ietf-tsvwg-ecn-encap-guidelines-02.txt


We realised that inappropriate uses of the IP-ECN field need to be 
precluded. E.g. the 3GPP toggle of the IP-ECN field to downgrade the 
codec. So we added the following 'Rule #1' before all the other rules:

3.  Guidelines in All Cases

    RFC 3168 specifies that the ECN field in the IP header is intended to
    be marked by active queue management algorithms.  Any congestion
    notification from an algorithm that does not conform to the
    recommendations in [I-D.ietf-aqm-recommendation] MUST NOT be
    propagated from a lower layer into the ECN field in IP.


>From: <internet-drafts <at>>
>To: John Kaippallimalil <john.kaippallimalil <at>>,
>         Bob Briscoe
>         <bob.briscoe <at>>,
>         Patricia Thaler <pthaler <at>>,
>         Pat Thaler
>         <pthaler <at>>,
>         "Bob J. Briscoe" <bob.briscoe <at>>,
>         "John
>  Kaippallimalil" <john.kaippallimalil <at>>
>Subject: New Version Notification for
>  draft-ietf-tsvwg-ecn-encap-guidelines-02.txt
(Continue reading)

Erik Nordmark | 26 Mar 20:49 2015

UDP vs. IP usage guidelines (draft-ietf-tsvwg-rfc5405bis)


As I said at the mike, most of the UDP usage guidelines document applies 
equally to applications and tunnels that use IP.
The only part that clearly doesn't apply is the port number aspect.

I don't want to create the impression that applications or tunneling 
approaches can dealing with this issues by running over IP instead of 
running over UDP.

I wonder whether it would make sense to add a section saying that the 
guidelines applies to using other datagram protocols (that do not have 
their own congestion control mechanism i.e. exclude DCCP).

Alternatively it might make sense to introduce a separate IP usage 
guidelines document in intarea which says in essence "everything but 
section 5.1 in draft-ietf-tsvwg-rfc5405bis applies to applications or 
tunnels that use IP". But that sounds a lot more heavy weight.


Erik Nordmark | 26 Mar 20:36 2015

UDP usage guidelines and tunnels

Two questions on the draft.

In section 3.1.7 on tunnels there is a reference to circuit breaker in 
bullet #3.
It is intentional that circuit breaker is not mentioned in bullet #2? 
(which is about payload that isn't congestion controller).

The UDP tunnels I know that carry non-congestion controlled traffic also 
carry congestion-controlled traffic.
Would it be useful to include that level of detail? Basically the tunnel 
would carry a mixture of bullet #1 and bullet #2 traffic.
In such a case the different type of traffic can be treated differently 
by the tunneling mechanism.
AFAICT that wouldn't cause any issues, but I don't think it is obvious 
from the text in the section that such a flexibility exists.
One could argue that one could have two difference instances of the 
tunnel or sub-tunnels for the two types of traffic and bullet #1 and #2 
would apply to those separately.


Andrew Mcgregor | 26 Mar 20:29 2015

draft-ietf-tsvwg-circuit-breaker and B4 'circuit breaker'

I mentioned at the mic in Dallas that there is something similar to a circuit breaker in Google's B4 network.  The ACM SIGCOMM paper describing B4 is, which can be found online in various places.  Section 4.2 briefly discusses Bandwidth Enforcer, and amongst its functionality is a circuit breaker (which is not explicitly described, but aspects of which fall into all three of the draft's categories).

Andrew McGregor | SRE | andrewmcgr <at> | +61 4 1071 2221
IETF Secretariat | 26 Mar 01:18 2015

Milestones changed for tsvwg WG

Deleted milestone "Submit 'SCTP NAT Specification’' as a BCP RFC".

Changed milestone "Submit 'Quick Failover Algorithm in SCTP' to the
IESG for consideration as a Proposed Standard RFC", added
draft-ietf-tsvwg-sctp-failover to milestone.

Changed milestone "Submit 'SCTP New Data Chunk' as a Proposed Standard
RFC", added draft-ietf-tsvwg-sctp-ndata to milestone.

Changed milestone "Submit 'DSCP packet markings for RTCWeb QoS' to
IESG as a Proposed Standard RFC", added draft-ietf-tsvwg-rtcweb-qos to

Changed milestone "Submit 'SCTP NAT Support' to IESG for consideration
as a PS RFC", set due date to December 2015 from November 2014, added
draft-ietf-tsvwg-natsupp to milestone.

Changed milestone "Submit 'Behavioral Requirements Updates'’ as a BCP
RFC", set due date to December 2015 from November 2014, added
draft-ietf-tsvwg-behave-requirements-update to milestone.

Changed milestone "Submit 'Specification of GRE in UDP encapsulation'
to IESG as a PS RFC", added draft-ietf-tsvwg-gre-in-udp-encap to

Changed milestone "Submit 'Network Transport Circuit Breakers' to
IESG", added draft-ietf-tsvwg-circuit-breaker to milestone.


Scharf, Michael (Michael | 24 Mar 23:27 2015

RFC 6077 "Open Research Issues in Internet Congestion Control"

This is probably well-known: Section 3.1 discusses the ICCRG understanding of research challenges for
network supported congestion control.

Michael (as co-author)

Anna Brunstrom | 24 Mar 16:05 2015

SCTP socket API section needed for rto-restart?

Dear all,

In the tcpm session just now there was a discussion as to weather a SCTP 
socket API section should be added to the rto-restart draft or not. As 
there was no consensus in the room, we would like feedback from the 
mailing list.

As tsvwg handles SCTP, the question goes to both the tcpm and the tsvwg 
mailing lists.

The draft is at, and describes 
a small update to the RTO timer management algorithm.

Any other feedback on the document is of course also welcome.


Black, David | 24 Mar 14:24 2015

Tsvwg slides - use this link

Something seems to be wrong with the IETF-92 meeting materials link on
the IETF home page.

Slides for the TSVWG meeting later today can be found here:

All of Tuesday's slides are there, and we hope to have all of Thursday's
slides uploaded later today or sometime tomorrow morning.  Michael [8.],
Karen [9.], Bob [12.] and Xingpeng [13.] - this is your reminder to
please send slides sometime today [agenda item number is in square

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

Black, David | 23 Mar 19:55 2015

draft-ietf-tsvwg-port-use-09.txt - TSVWG focus

The two currently relevant versions of draft-ietf-tsvwg-port-use are:
	+ -07, the version resulting from IETF Last Call
	+ -09, the current version with changes from IESG Evaluation
We're not done with IESG Evaluation yet, but are getting close; there
will probably be a -10 version in the not too distant future.

Most of the changes from -07 to -09 are editorial, with the notable
exception of a complete rewrite of Section 7.4. "Support for Security."

We expect to discuss this new 7.4 text in the tsvwg meeting tomorrow,
so it would be helpful for those interested in this draft to review
that Section 7.4 text prior to the meeting.  Thanks in advance.

Here's a link to the datatracker page for this draft:

and a link directly to the Section 7.4 text:


> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces <at>] On Behalf Of Joe Touch
> Sent: Monday, March 23, 2015 1:30 PM
> To: internet-drafts <at>; i-d-announce <at>
> Cc: tsvwg <at>
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-09.txt
> Hi, all,
> This is another update based on IESG feedback.
> Key changes since 07:
> 	- title, abstract, intro changed for clarified focus
> 	- minor tweaks throughout for clarification
> 	- Sec 7.4 and 8 substantially revised based on IESG review
> Joe
> On 3/23/2015 10:08 AM, internet-drafts <at> wrote:
> >
> > 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           : Recommendations on Using Assigned Transport Port
> Numbers
> >         Author          : Joe Touch
> > 	Filename        : draft-ietf-tsvwg-port-use-09.txt
> > 	Pages           : 23
> > 	Date            : 2015-03-23
> >
> > Abstract:
> >    This document provides recommendations to application and service
> >    protocol designers on how to use the assigned transport protocol
> >    port number space and when to request a port assignment from IANA.
> >    It provides designer guidelines on how to interact with the IANA
> >    processes defined in RFC6335, thus serving to complement (but not
> >    update) that document.
> >
> >
> > 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
> >
> > Internet-Drafts are also available by anonymous FTP at:
> >
> >

Black, David | 23 Mar 18:49 2015

New agenda, Tue slides available

The Dallas agenda has been revised again; there will be updates on a couple of WG draft on Thu, and the behave
draft will now be covered in the chairs update.

v4 is the current agenda here:
If you get v3 or earlier, hit reload ;-).

Slide sets 1-5, and maybe 7 will be taken upon Tuesday.

Thursday presenters - keep those slides coming - we need them by tomorrow (Tue) evening ... or your draft
could join the behave draft as being removed from the Thu agenda (hint).

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

Gorry Fairhurst | 22 Mar 22:03 2015

Editorial comments draft-ietf-tsvwg-natsupp-07.txt

I separately sent some questions on the new draft. The list below contains mainly minor comments on the new test.

Best wishes,



“To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available.
The end result of this is that only one SCTP capable host can be behind a NAT.”
- While I think this text may be very important fro the introduction, it is not really necessary in the
abstract. We can just specify the mechanisms.
- The abstract also need stop say that the document defines the NAT behaviour required to support SCTP.
- I think (am I correct) that the view of a NAT maps to one public IP address. Is this the case? Can we say this?
“The authors feel”
- Authors appears more than once. While it may be true, this phrase should’t appear in a WG draft, unless
the authors may differ in opinion to the WG. I don’t think this us the case. I suggest we simply make the
statement and see if there is working group consensus. If there is any doubt, please raise this at a WG
meeting in the presentation and confirm the outcome on the list.
“much as TCP does today” 
- I suggest “in the same way that a TCP session can use a NAT”
- Do you also need to add a clause saying: “The reader is also assumed to be familiar with the terminology in
RFC4960, and XXXX.
- It could be worth prefixed “Verification Tag” with “SCTP” in case a NAT implementor does not
immediately understand these terms.
“add considerable”
- Better perhaps as: “considerably adds”
“considered by the authors”
- should be removed.
”it should be noted that”
- should be removed.
Says that an error chunk SHOULD be sent.
- Why SHOULD in this case. I can see that potentially the chunk may not be delivered, but why not say MUST send.
This seems in line with other recommendations later to require sending in 6.3
- Could we add a sentence saying what is in the section, such as:
“This section defines the formats used to support NAT traversal. Section 5.1 and 5.2 describe chunks
generated by NATs and interpreted by SCTP end hosts. 5.3 describes parameters set by end hosts and used by
NATs and end hosts.” (checking of course these statements are correct).
- In several places this speaks of extending, rather than updating. This may or may not be the correct term.
What is the compliance statement with respect to the SCTP base sec. Are implementations expected to
implement the NAT travseral endpoint support, or is this optional? How does the WG wish to handle this and
what are reasonable expectations of a “full” SCTP stack?
- In several places this makes assumptions of the IANA registry update. Can you please add a note, such as
this below before each of these to ensure these are not overlooked when we go for publication:
Section 6.
- Would it be possible to rename this section “End host and NAT Procedures”. This could be helpful to
ensure readers get to the correct sections.
Section 6.1:
- Excess letters after [RFC4960] ???
Section 6.2:
- I wonder if a NAT implementor a little unfamiliar with SCTP would benefit from a few short words that
explained how SCTP-INIT normally works without a NAT. I found this a sudden change in the expected
background of the reader.
Section 6.3:
- Insert “-“ between “TCP” and “like”
Section 6.3:

“These procedures SHOULD be followed only if the appropriate error cause code for colliding NAT table
state is included AND the association is in the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK). If the
endpoint is in any other state an SCTP endpoint SHOULD NOT respond.”
- I couldn’t work this out. Following a SHOULD with a condition is always a recipe for making a difficult
sentence. Does this mean (or not):
If the appropriate error cause code for colliding NAT table state is included and the association is also in
the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK), then these procedures SHOULD be followed.”?
Or is it “MUST” under this specific case?
- and the next phrase has a “If” and a SHOULD NOT, that’s not entirely clear to me when and why you would not.
- Could you please think about making the RFC2119 language simpler?
“For the NAT”
-insert comma after “NAT” and before “tracking”
- can we start a new line with the NAT behaviour, I’m keen to see separation between paras that tell NATs
what to do and paras that tell host stacks what to so. (more later).
“i. e.” should be “i.e.,”
- If this is the same as RFC4960, then please cite, if not explain the difference between this and an SCTP end
host fragment reassembly rule.
- I think this section is informative, if it is, it would be nice to have a sentence saying so at the start.
- I think this section should not the possibility of off-path attacks and provide a more or less standard
sentence saying how SCTP provides protection from off-path data insertion, stating that this
protection remains when NATs are used. This “background” may also help readers understand a little
more of SCTP.