Lucy yong | 29 Jun 22:07 2016

FW: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-12.txt

FYI. This version addresses the comments/suggestions from Donald Eastlake, Eliot Lear, 
and Martin Stiemerling in WGLC process. I like to thank them for their detail reviews.


-----Original Message-----
From: internet-drafts <at> [mailto:internet-drafts <at>] 
Sent: Wednesday, June 29, 2016 3:01 PM
To: Lucy yong; Xuxiaohu; Edward Crabbe; Tom Herbert
Subject: New Version Notification for draft-ietf-tsvwg-gre-in-udp-encap-12.txt

A new version of I-D, draft-ietf-tsvwg-gre-in-udp-encap-12.txt
has been successfully submitted by Lucy Yong and posted to the IETF repository.

Name:		draft-ietf-tsvwg-gre-in-udp-encap
Revision:	12
Title:		GRE-in-UDP Encapsulation
Document date:	2016-06-29
Group:		tsvwg
Pages:		24




   This document specifies a method of encapsulating network protocol
   packet within GRE and UDP headers. This GRE-in-UDP encapsulation
   allows the UDP source port field to be used as an entropy field.
(Continue reading)

internet-drafts | 29 Jun 22:01 2016

I-D Action: draft-ietf-tsvwg-gre-in-udp-encap-12.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 of the IETF.

        Title           : GRE-in-UDP Encapsulation
        Authors         : Lucy Yong
                          Edward Crabbe
                          Xiaohu Xu
                          Tom Herbert
	Filename        : draft-ietf-tsvwg-gre-in-udp-encap-12.txt
	Pages           : 24
	Date            : 2016-06-29

   This document specifies a method of encapsulating network protocol
   packet within GRE and UDP headers. This GRE-in-UDP encapsulation
   allows the UDP source port field to be used as an entropy field.
   This may be used for load balancing of GRE traffic in transit
   networks using existing ECMP mechanisms. This document also
   specifies GRE-in-UDP tunnel requirements for two applicability
   scenarios: (1) general Internet; (2) a traffic-managed controlled
   environment. The controlled environment has less restrictive
   requirements than the general Internet.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

(Continue reading)

Black, David | 29 Jun 16:01 2016

RFC 5405bis draft - non-congestion-controlled IP traffic

A while back, in response to Martin Stiemerling's comments on the GRE/UDP draft,
I wrote:

> [2] IP traffic congestion control assumptions.
> > - I do disagree with "IP-traffic can be assumed to be
> > congestion-controlled.", even though it is stated in RFC 5405, as there
> > is a lot of IP traffic that is not congestion controlled, such as
> > multicast traffic...
> > Section 4, even states that multicast and broadcast traffic can be
> > carried over GRE-UDP! None of both is in general congestion controlled!
> Well, this is actually an issue with the rfc5405bis draft, and this issue needs
> to be fixed there, as RFC 5405 is (and the rfc5405bis draft will be) the
> Transport Area's statement to the rest of the IETF on congestion control
> guidelines and requirements for UDP usage.

This is indeed an issue with the 5405bis draft.  In particular, Martin has
effectively pointed out that this text in Section 3.1.11 is wrong because
it encompasses multicast and broadcast traffic:

   IP-based traffic is generally assumed to be congestion-controlled,
   i.e., it is assumed that the transport protocols generating IP-based
   traffic at the sender already employ mechanisms that are sufficient
   to address congestion on the path.  Consequently, a tunnel carrying
   IP-based traffic should already interact appropriately with other
   traffic sharing the path, and specific congestion control mechanisms
   for the tunnel are not necessary.

Changing "IP-based traffic" to "IP-based unicast traffic" in three places
(Continue reading)

Joe Touch | 29 Jun 00:08 2016

Fwd: New Version Notification for draft-touch-tsvwg-udp-options-03.txt

Hi, all,

See below.

Updated to correct/clarify text, legacy issues, etc.


-------- Forwarded Message -------- Subject: Date: From: To:
New Version Notification for draft-touch-tsvwg-udp-options-03.txt
Tue, 28 Jun 2016 15:02:53 -0700
internet-drafts <at>
Joe Touch <touch <at>>, Dr. Joseph D. Touch <touch <at>>

A new version of I-D, draft-touch-tsvwg-udp-options-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 03 Title: Transport Options for UDP Document date: 2016-06-28 Group: Individual Submission Pages: 13 URL: Status: Htmlized: Diff: Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP to provide a location, syntax, and semantics for transport layer options. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at The IETF Secretariat

Black, David | 28 Jun 01:59 2016

draft-szigeti-tsvwg-ieee-802-11 - Adopted by TSVWG

The WG chairs conclusion is that the rough consensus of the TSVWG WG is to adopt
this draft as a WG draft.   The authors should submit a draft-ietf-tsvwg-* version, and
this draft will be included in the WG drafts portion of the TSVWG Berlin meeting agenda.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces <at>] On Behalf Of Black, David
> Sent: Thursday, June 09, 2016 1:14 AM
> To: tsvwg <at>
> Subject: [tsvwg] WG adoption call: draft-szigeti-tsvwg-ieee-802-11 - through June
> 25
> This is a TSVWG call for interest in WG adoption of draft-szigeti-tsvwg-ieee-802-
> 11.
> If you have read the draft and support WG adoption of it as a work item
> and WG draft, please send an email to the list (tsvwg <at> saying so.
> NB: It is important to say that you've read the draft.  If you're willing
> to review/comment on future versions of this draft and/or implement this
> draft, please say so on the list or in email directly to the chairs
> (tsvwg-chairs <at>
> Authors: We (chairs) assume that you support WG adoption of your draft, so
> there's no need to say so on the list.  However, we do need each author to
> publicly state on the list that their direct, personal knowledge (if any) of any
> IPR related to this document has already been disclosed, in conformance
> with BCPs 78 and 79.
> This adoption call will run for about 2 weeks, ending at midnight, prevailing
> US Eastern Time on Saturday June 25.  To get things started, I hereby state
> as an individual that I have read the draft and support WG adoption of it.
>              Guidelines for DiffServ to IEEE 802.11 Mapping
>                    draft-szigeti-tsvwg-ieee-802-11-01
> Abstract
>    As internet traffic is increasingly sourced-from and destined-to
>    wireless endpoints, it is crucial that Quality of Service be aligned
>    between wired and wireless networks; however, this is not always the
>    case by default.  This is due to the fact that two independent
>    standards bodies provide QoS guidance on wired and wireless networks:
>    specifically, the IETF specifies standards and design recommendations
>    for wired IP networks, while a separate and autonomous standards-
>    body, the IEEE, administers the standards for wireless 802.11
>    networks.  The purpose of this document is to propose a set
>    Differentiated Services Code Point (DSCP) to IEEE 802.11 User
>    Priority (UP) mappings to reconcile the marking recommendations
>    offered by these two standards bodies, and, as such, to optimize
>    wired-and-wireless interconnect QoS.
> Thanks, --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953     Cell: +1 (978) 394-7754
> <at>
> ----------------------------------------------------

"IETF Secretariat" | 24 Jun 18:01 2016

tsvwg - Requested sessions have been scheduled for IETF 96

Dear Gorry Fairhurst,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

tsvwg Session 1 (2:00:00)
    Friday, Morning Session I 1000-1200
    Room Name: Bellevue size: 200
    tsvwg Session 2 (1:30:00)
    Wednesday, Afternoon Session II 1550-1720
    Room Name: Charlottenburg II/III size: 175

Request Information:

Working Group Name: Transport Area Working Group
Area Name: Transport Area
Session Requester: Gorry Fairhurst

Number of Sessions: 2
Length of Session(s):  2 Hours, 1.5 Hours
Number of Attendees: 75
Conflicts to Avoid: 
 First Priority: tsvarea iccrg aqm rmcat rtcweb tcpm mptcp nvo3 dclcrg taps ippm opsawg opsarea intarea
 Second Priority: v6ops tram tcpinc nfsv4 dispatch
 Third Priority: ccamp artarea precis

Special Requests:
  [If rtcweb has 2 sessions, 1 must not conflict] 
[Must not conflict with Transport Area BoFs]


Michael Welzl | 24 Jun 14:17 2016

Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ?

Dear all,

We recently did DSCP related measurements that lead us to propose a change to draft-ietf-tsvwg-rtcweb-qos.
These measurements are reported in this paper:
... which will be presented at the ANRW workshop, the Saturday before the IETF meeting.

The paper reports on tests between people's homes and 3 servers that we ran - one in Oregon (amazon cloud) and
two in Norway. This gave us 185 distinct paths (IP address pairs). The test was a TCP handshake, done with
raw sockets, and we played around with values in the IP header. Meanwhile, Runa (main author) did some more
tests from various public places during a trip from Norway to India, essentially confirming the finding
we discuss here; we'll ask for a slot to report about both the data in the ANRW paper and the newer data in the
MAPRG session.

The number of data points isn't exactly huge in both cases, but still relevant, we believe: it is about a
persistent failure that we saw on different paths, and so we think it's probably reasonable to take it into
account (given that a fix shouldn't be very complicated either).

We used, as input, DSCP values from the table in draft-ietf-tsvwg-rtcweb-qos.
Here are some sentences copy + pasted from our paper:

"To minimize the chance that congestion-based drops make us believe in a failure
to communicate using certain values in the IP header, we re-tried failed packet
exchanges up to three times, and we sent an ICMP packet just ahead of every
measurement packet. We only assumed a communication failure when the test
failed three times and the ICMP packet succeeded."

"Considering table 1 in [6], we assumed the flow type “Interactive Video with or
without Audio” with application priorities “Very low” (DSCP value CS1 (8)), “Low”
(DF (0)) or “Medium” (AF42 (36)), and flow type “Audio” with application prioritiy
“High” (EF PHB (46))."

"We did see consistent packet drops too: on 23 paths for DSCP value 8, 21 paths
for 36, 19 for 46."

We also saw DSCP value changes, but nothing very alarming there - in one case, AF42 was changed to AF41, which
is even nice  :)     however, this consistent drop behavior that appears only when using a DSCP value != 0 isn't
good at all. Now these things could in principle have happened close to our 3 servers, meaning there were
only few devices that did it, but in fact this measurement was a part of a larger measurement campaign in
which we also checked where such packet drops typically happened. The result was: most such drops seem to
be close to the client, which may indicate that there were in fact multiple such boxes.

We believe that draft-ietf-tsvwg-rtcweb-qos should say: if setting the DSCP values as proposed here
consistently produces packet drops, senders should fall back to DSCP 0. WebRTC shouldn't "fail" because
of the DSCP.


gorry | 23 Jun 16:47 2016

Please tell us if you have new work or would like to present a draft in TSVWG

 Hi tsvwg'ers,

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

Priority will be assigned to time that progresses WG drafts, to bring
individual drafts to the attention of the WG and (in least order of
priority) to describe new work relevant to the TSVWG Charter.

Please send all requests and any corrections to the chairs
<tsvwg-chairs <at>> asap, and we'll publish a preliminary meeting

Gorry and David
(tsvwg co-chairs)

gorry | 23 Jun 16:39 2016

WGLC for draft-ietf-tsvwg-diffserv-intercon - to end 10th July 2016

This email announces a TSVWG Working Group Last Call (WGLC) on:

            Diffserv-Interconnection classes and practice
                     Intended status: Informational

This WGLC will run for 2 weeks, ending on 10th July 2016. The results
of the WGLC will be presented at the Berlin IETF meeting.

Comments should be sent to the tsvwg <at> list.   Please cc: the WG
chairs at tsvwg-chairs <at> to track your comments as part of the WGLC

As part of this WGLC, comments are requested on the usability of this
draft, and the relation to published RFCs.

Thanks, Gorry
(TSVWG Co-Chair)

IETF Secretariat | 23 Jun 16:13 2016

The TSVWG WG has placed draft-szigeti-tsvwg-ieee-802-11 in state "Call For Adoption By WG Issued"

The TSVWG WG has placed draft-szigeti-tsvwg-ieee-802-11 in state 
Call For Adoption By WG Issued (entered by Gorry Fairhurst)

The document is available at

To end June 25th 2016

internet-drafts | 21 Jun 08:57 2016

I-D Action: draft-ietf-tsvwg-diffserv-intercon-06.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 of the IETF.

        Title           : Diffserv-Interconnection classes and practice
        Authors         : Ruediger Geib
                          David L. Black
	Filename        : draft-ietf-tsvwg-diffserv-intercon-06.txt
	Pages           : 21
	Date            : 2016-06-20

   This document defines a limited common set of Diffserv PHBs and
   codepoints (DSCPs) to be applied at (inter)connections of two
   separately administered and operated networks, and explains how this
   approach can simplify network configuration and operation.  Many
   network providers operate MPLS using Treatment Aggregates for traffic
   marked with different Diffserv PHBs, and use MPLS for interconnection
   with other networks.  This document offers a simple interconnection
   approach that may simplify operation of Diffserv for network
   interconnection among providers that use MPLS and apply the Short-
   Pipe tunnel mode.

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: