Bob Briscoe | 30 Jul 13:47 2015

Invitation to subscribe to new DCTCP Evolution mailing list: (tcpPrague <at>

tcpm, tsvwg, tsvarea, iccrg lists

Recently, there have been developments (see URLs at end) that would make it possible to deploy scalable low-latency low-loss protocols like Data Center TCP alongside a mix of traffic, either in data centres and private networks, or even on the public Internet. One approach was demonstrated at the recent IETF in Prague, showing DCTCP giving ultra-low latency over a broadband Internet access while competing with a mix of Internet traffic on roughly equal terms.

As a result of an ad hoc meeting ("Bar BoF" = Birds of a Feather) at the Prague IETF, we have formed a new mailing list.
I'd like to invite you to join the list via: <>

The idea is to ensure that those working on DCTCP implementations across platforms (Free BSD, Linux, Windows, ...) will converge on solutions that will interwork with each other and with existing traffic. Although it is under the IETF's umbrella, we hope and expect that discussion will be as much about implementation as writing standards. However, we get the benefit of the IETF's IPR disclosure rules, and of course it fits the IETF's purpose of interoperability.

The draft notes of the meeting are below.
And below that, is the original announcement with some context and background URLs.
You can catch up on any discussion you've missed using the list archives via the link above.

If you want to respond about something most relevant to tcpprague, pls avoid cross-posting to all the other lists in this announcement.


Bob Briscoe

-------- Forwarded Message -------- Subject: Date: From: To:
Notes: DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Tue, 28 Jul 2015 14:00:46 +0100
Bob Briscoe <ietf <at>>
TCP Prague IETF List <tcpPrague <at>>


These notes have taken a week, because I've only just put my machine back together after having to rebuild the hardware a little :|

Notes: DCTCP Evolution Bar BoF
6-7pm Tue 21 Jul 2015, Budapest room, The Hilton, Prague, CZ

Summary of Actions:
Lars E: Set up tcpprague wiki page
Bob B: Request tcpprague <at> mailing list, via IETF process (requires Area Director approval)
Bob B: Document Rationale - initiate a para on wiki.
Lars E: fwd Dagstuhl invitee list to Bob
Bob B: Set up list on wiki to assign people to invite those not in the room to join.

* 18:00 Introductions - name and interest
Marcelo    Bagnulo Braun    <marcelo <at>>
Praveen    Balasubramanian    <pravb <at>>
Martin    Bekker    <martin.becke <at>>
Bob    Briscoe    <ietf <at>>
Anna    Brunstrom    <anna.brunstrom <at>>
Stuart    Cheshire    <cheshire <at>>
Koen    De Schepper    <koen.de_schepper <at>>
Fabien    Duchen    <fabien.duchene <at>>
Phil    Eardley    <philip.eardley <at>>
Lars    Eggert    <lars <at>>
Michio    Honda    <michio <at>>
Per    Hurtig    <Per.Hurtig <at>>
Jana    Iyengar    <jri <at>>
Naeem    Khademi    <naeem.khademi <at>>
Mirja    Kuehlewind    <mirja.kuehlewind <at>>
Matt    Mathis    <mattmathis <at>>
Andrew    McGregor    <andrewmcgr <at>>
Karen    Nielsen    <karen.nielsen <at>>
Tommy    Pauly    <tpauly <at>>
Andreas Petlund <apetlund <at>>
Costin    Raiciu    <costin.raiciu <at>>
Pasi    Sarolahti    <pasi.sarolahti <at>>
Richard    Scheffenegger    <rs <at>>
David    Schinazi    <dschinazi <at>>
Randall    Stewart    <randall <at>>
Dave    Thaler    <dthaler <at>>
Brian    Trammell   <ietf <at>>
Michael    Tuexen    <Michael.Tuexen <at>>
Felix    Weinrank    <weinrank <at>>
Michael    Welzl    <michawe <at>>
Alex    Zimmermann    <alexander.zimmermann <at>>

* Scope and Agenda Bashing

[Non-italic text is from the materials pre-prepared by Koen De Schepper and Bob Briscoe.
Italic text summarises conversation in the room.]

Meeting is covered by the standard IETF "Note Well" concerning intellectual property.

* Evolving the e2e DCTCP protocol for use alongside existing traffic (whether in DCs, private nets or public Internet).
* Primarily to get DCTCP /developers/ involved early (Windows, FreeBSD, Linux), so that whatever we decide to standardise can be implemented in parallel
  (Doing implementation and standardisation in series is not desirable, in whichever order).
* Primarily an organisational meeting about creating a forum / community to do this work, using people's experience to know what will work best.

Not in Scope:
* Network changes are not in scope unless they impact the list of changes needed to DCTCP
* The in-network side of the solution (two approaches exist [DCttH, Judd15], others may follow).
* Identifier of DCTCP-like traffic (please discuss by email, not in this meeting)

Lars E: Informational draft recording Microsoft's DCTCP should not be stalled by this, as it has value of its own.
   Unanimous agreement.

Praveen S: Microsoft has offered a royalty free license for DCTCP IPR.

Karen N: Is DCTCP over a non-TCP transport (e.g. SCTP) in scope?
   Unanimous "Yes"

Outcome of discussion on the features of this DCTCP-like congestion control that define this work:
  1. Must use ECN, but unlike RFC3168 ECN, marking is not merely equivalent to drop,
    so ECN signals can be more plentiful and sooner than drop.
  2. Packet rate is proportional to 1/p, where p is the ECN marking probability.
Matt M: 1/p makes congestion control scale with the bandwidth, by making the intensity of congestion control signals per RTT invariant.

Stuart Ch: Apple is turning on ECN by default in clients. Currently in developer seeds but probably in the next releases.  Packet loss is also not a mystery.

* 18:15 List of /must-have/ changes before deployment alongside existing traffic.

Matt M: Rather than a "MUST-have" list, produce a prioritised list, because where to draw the necessity line could depend on the use-case.

The following list wasn't formally prioritised in the meeting, but items where some people questioned necessity are shifted down.
  1. Fall back to Reno or Cubic behaviour on loss;
    For how long? quick consensus: 1 RTT, but needs further discussion. ECN response continues to operate in parallel.
  2. Negotiate altered feedback semantics, to convey the extent of ECN marking, not just its existence, and this feedback needs to be robust to loss [RFC-to-be 7560];
    Mirja K, Richard S & Bob B plan to have spec of much simpler solution out soon.
  3. Use of a standardised packet identifier (if ECN-capable is not enough)
    Identifier tbd.
    - - - 8< - - - - - - - - highest line between "must-have for safety" and "would be nice for performance" - - - - - -  8< - - - -
  4. Handle a window of less than 2 when the RTT is low, rather than increase the queue [TCP-sub-mss-cwnd], like TCP Nice.
    Michael W: Is this "must-have"? Quite a complicated step.
    Bob B: Yes, but, otherwise DCTCP will pollute ultra-low latency queues from the start.
  5. Average ECN feedback over its own RTT, not the hard-coded RTT suitable only for data-centres, perhaps reduce cwnd by seg-size/2 per ECN Echo, like Relentless TCP [Mathis09];
    ???: How bad would long-RTT flows be?  More generally, how can we evaluate all this?
    Bob B: With mixed RTTs, flows with RTT > a couple of ms will respond too quickly to bursts. Whatever, it's already been implemented by Mohammad Alizadeh in Linux, and evaluated, so this is easy.
  6. Heuristic testing for classic ECN bottlenecks
    The idea would be to detect a 'classic' RFC316 bottleneck by whether appreciable delay growth accompanies the marking (originally suggested by Michael W).
    Bob B: Complex and slow to detect, so it would have to learn and cache for new flows - suggest this should only be a must-have if measurements prove it to be a problem - i.e. if a significant proportion of classic ECN bottlenecks exist
    Matt M: No need for this - rate mismatch no worse than TCP already sees with RTT discrepancies.
     - - - 8< - - - - - - - - lowest line between "must-have for safety" and "would be nice for performance" - - - - - -  8< - - - -
  7. Costin R: Faster-than-additive increase (similar to Cubic)
    A performance improvement, not "must-have", but would be nice to have while we're doing this.
  8. [Not discussed in the meeting, but added by Bob B for the record]: Less drastic exit from slow-start, to match less drastic rate reduction per mark.
    Currently, because marking threshold is shallow, slow start exits earlier than with drop, unnecessarily increasing completion time.

Costin R: Any other way to evolve towards DCTCP over mixed networks, without separate queues in the network?
Bob B: To discuss on ML, and if we continue with the proposed approach, we must record the rationale on the WIki.

* 18:30 Brainstorm to identify people not present who will be important to this.

<!-- body,div,table,thead,tbody,tfoot,tr,th,td,p { font-family:"Liberation Sans"; font-size:x-small } --> Mohammad    Alizadeh    < <at>>
Grenville    Armitage    <garmitage <at>>
Fred    Baker    <fred <at>>
Stephen    Bensley    <sbens <at>>
Daniel    Borkmann    <daniel.borkmann <at>>
Yuchung    Cheng    <ycheng <at>>
Kenjiro    Cho    <kjc <at>>
邓灵莉/Lingli    Deng    <denglingli <at>>
Eric    Dumazet    <edumazet <at>>
Gorry    Fairhurst    <gorry <at>>
Jamal    Hadi Salim    <hadi <at>>
Glenn    Judd    <glenn.judd <at>>
Midori    Kato    <katoon <at>>
Kenneth    Klette Jonassen    <kennetkl <at>>    (already subscribed)
Sridharan,    Murari    <muraris <at>>
Hiren    Panchasara    <hiren.panchasara <at>>
Hagen     Pfeifer    <hagen <at>>
Balaji    Prabhakar    <balaji <at>>
KK    Ramakrishnan    <kk <at>>
Lawrence    Stewart    <lstewart <at>>
Dave    Taht    <dave.taht <at>>
Florian    Westphal    <fw <at>>

Agreed to cc to the following for awareness, but no need to invite to join the list:
Stephen    Hemminger    <stephen <at>>
David    Miller    <davem <at>>

Missing types of organisations:
  • Network operators (not so relevant for e2e protocol, but need to be motivated to deploy the network part)
  • CDNs
[Bob B adds: Subsequent to mtg, Erik Nygren tells me Xin Zhang leads Akamai's congestion control team. Also I noticed Hiren used to work at Limelight, so may have contacts]

Lars E: Co-organising a Dagstuhl retreat around DCTCP. Will forward list of invitees to Bob to notify once the ML exists.
Also Lars's list of FreeBSD and Linux devs.

* 18:40 What is the best way to ensure the outputs from a number of separate developers all converge in parallel to standardisation?
Common Test Suite
Interop events
Serving paths (e.g. Google's) capable of serving this

* 18:50 Next steps: Actions to set up suitable MLs, tools, with timesales etc.

Discussed pros and cons of hosting ML on
General agreement: use for ML - because the IPR Note Well is useful.

Name for ML?
Matt M: TCP Prague (for an evolving protocol, a meaningless tag is best).
Karen N: ecn-prague, because it's not just TCP?

Agreed: tcpprague <at>

Bob B: ML - ask SpencerD/MartinS, following the documented process
Lars E: Set up wiki page - for assigning people to send out invitations

* End 19:05

Notes: Bob Briscoe, helped by Andrew McGregor
28 Jul 2015

-------- Forwarded Message -------- Subject: Date: From: To: CC:
DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Mon, 20 Jul 2015 22:46:14 +0100
Bob Briscoe <ietf <at>>
Mirja Kuehlewind <mirja.kuehlewind <at>>, EGGERT, Lars <lars <at>>, Dave Thaler <dthaler <at>>, Praveen Balasubramanian <pravb <at>>, Alex Zimmermann <alexander.zimmermann <at>>, Richard Scheffenegger <rs <at>>, Fred Baker <fred <at>>, Matt Mathis <matt.mathis <at>>, Andrew McGregor <andrewmcgr <at>>, Dave Taht <dave.taht <at>>, Stuart Cheshire <cheshire <at>>, Michael WELZL <michawe <at>>, Andreas Petlund <andreas <at>>, Gorry Fairhurst <gorry <at>>, Anna Brunstrom <anna.brunstrom <at>>
De Schepper, Koen (Koen) <koen.de_schepper <at>>


DCTCP evolution 'bar BoF': Tue 21 Jul 2015, 17:40, Prague
Location: Unless I have emailed with a room location before then, pls meet at the IETF reception.

Koen & I are trying to get together people in Prague who are involved in development of DCTCP across platforms (Windows, Free BSD, Linux, etc), and who are interested in evolving it for use on heterogeneous networks, e.g.
* data centres with a mix of TCP flavours, not just DCTCP
* private networks
* the public Internet

Pls fwd this invite to anyone in Prague who ought to be involved that I've missed (pls cc everyone else too).

Sorry for short notice.

One purpose of the session will be to build a community beyond the IETF, so I'd like us to compose an email to a wider set of people after the session, e.g.:

Stephen Bensley <sbens <at>>
Glenn Judd <glenn.judd <at>>
Daniel Borkmann <daniel.borkmann <at>>
Florian Westphal <fw <at>>
邓 灵莉/Lingli Deng <denglingli <at>>
Mohammad Alizadeh < <at>>
Stephen Hemminger <stephen <at>>
David S. Miller <davem <at>>
Sridharan, Murari <muraris <at>>
Yuchung Cheng <ycheng <at>>

Koen & Bob

PS. Below is some background, and some agenda ideas. Pls discuss, bash and add your own.

We've recently developed an AQM that allows DCTCP to co-exist with Cubic/Reno etc. with zero config. Links below.

We have to add some necessary mechanisms to DCTCP (listed below) so it will be safe alongside other traffic. Two questions:

Q1. We don't want to fork DCTCP. Does anyone think a fork optimised for homogeneous DCTCP would be better?

Q2. Anyone interested in helping?
We have an idea how to do each one, but sharing the load would be great - there's Linux, FreeBSD, Windows, etc. to cover.

List of the 4 essential 'safety' mods to DCTCP (copied from the IETF Internet Draft linked below) and one that might need to be essential:

   o  fall back to Reno or Cubic behaviour on loss;


   o  negotiate its altered feedback semantics, which conveys the extent

      of ECN marking, not just its existence, and this feedback needs to

      be robust to loss [I-D.ietf-tcpm-accecn-reqs];


   o  handle a window of less than 2 when the RTT is low, rather than

      increase the queue [TCP-sub-mss-w].


   o  average ECN feedback over its own RTT, not the hard-coded RTT

      suitable only for data-centres, perhaps like Relentless

      TCP [Mathis09];    o  Use of a standardised packet identifier (if ECN-capable is not enough)    o  Heuristic testing for classic ECN bottlenecks (optional?)

We're trying to move fast because if we can get on top of other developments (e.g. Apple's recent release of ECN), it will mean less messy classification code in the AQM.
So the links below are not on official sites yet.

‘Data Centre to the Home’: Ultra-Low Latency for All

* 1ms 99%-ile queuing delay for all DCTCP traffic in thousands of expts incl. high load,
   over an e2e test network with real broadband equipment.
* DCTCP co-existence with Reno & Cubic, with no transport ID inspection.
* less ops per packet than RED
* Zero config

IETF Draft to standardise those parts of the AQM relevant to interop
(not yet submitted to IETF):

Koen & Bob

Jose Saldana | 29 Jul 13:13 2015

RV: New Version Notification for draft-saldana-tsvwg-simplemux-03.txt

Hi all,

I have just submitted a new version of the Simplemux draft.

The main improvement is that it now permits the multiplexing of packets of any length.



> -----Mensaje original-----
> De: internet-drafts <at> [mailto:internet-drafts <at>]
> Enviado el: miƩrcoles, 29 de julio de 2015 13:12
> Para: Jose Saldana <jsaldana <at>>; Jose Saldana <jsaldana <at>>
> Asunto: New Version Notification for draft-saldana-tsvwg-simplemux-03.txt
> A new version of I-D, draft-saldana-tsvwg-simplemux-03.txt
> has been successfully submitted by Jose Saldana and posted to the IETF
> repository.
> Name:		draft-saldana-tsvwg-simplemux
> Revision:	03
> Title:		Simplemux. A generic multiplexing protocol
> Document date:	2015-07-29
> Group:		Individual Submission
> Pages:		14
> URL:  
> 03.txt
> Status:
> Htmlized:
> Diff: 
> Abstract:
>    There are some situations in which multiplexing a number of small
>    packets into a bigger one is desirable.  For example, a number of
>    small packets can be sent together between a pair of machines if they
>    share a common network path.  Thus, the traffic profile can be
>    shifted from small to larger packets, reducing the network overhead
>    and the number of packets per second to be managed by intermediate
>    routers.
>    This document describes Simplemux, a protocol able to encapsulate a
>    number of packets belonging to different protocols into a single
>    packet.  It includes the "Protocol" field on each multiplexing
>    header, thus allowing the inclusion of a number of packets belonging
>    to different protocols (multiplexed packets) on a packet of another
>    protocol (tunneling protocol).
>    In order to reduce the overhead, the size of the multiplexing headers
>    is kept very low (it may be a single byte when multiplexing small
>    packets) .
> 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

Jose Saldana | 28 Jul 17:37 2015

A question about packet loss when multiplexing

Hi, Gorry,


Last Wednesday in Prague you asked me about the of effect packet loss of compressed tunnel packets, and if this is stressed in wireless scenarios.


There are some things to be considered here:


1- If you use header compression, a lost packet may be translated into a burst of wrong packets, because you may lose the ROHC context. You can use ROHC bidirectional to minimize the effect of this.


2- If you lose a multiplexed packet, you lose a number of packets. But the packet loss probability may be the same overall. For example:

You send 1000 pps with a 1% packet loss. So you lose 10 pps.

If you multiplex in groups of 10 packets, then you only send 100 pps. So you will only lose 1 pps, but that packet will have 10 small packets inside.


3- But (2) may not be entirely true if you are in a wireless scenario, where packet loss probability may grow with packet size.


In the Bar-BoF on Thursday we also talked about the potential utility of multiplexing in satellite scenarios. What do you think?






gorry | 27 Jul 09:34 2015

Opening-up for comments on the TCP-Stealth draft

I promised people I would send a list of "comments" following the previous
discussion of
the TCP Stealth draft, to see if people would be able to come to some
conclusions on
the TSVWG list.

So  here's a short summary of previous TCPM/TCPINC issues/comments from
-00 onwards.  The original text of the comments can be found on other IETF
lists... Feel free to expand - or explain which have already been
addressed... Using the TSVWG mailing list.




Intended for use with SSH, not as a HTTP replacement. How widely usable is

One comment was that this is about minimizing visible Internet footprint,
but not hiding from a listener.

The authors claim it's useful as a small change for connecting to services
in ways
that defeat "script kiddies" without setting up port knocking.

This doesn't discuss (or cite) RFC6528, but seems like it is a play on the
key cited in Sec 3 of that RFC.

Someone said something like:
"seems like a syn-cookie variant, with no need to standardize"


It was suggested that it would be easy to identify stealth sessions (ISN
and port
reuse vs. randomization) and to interfere with segments in-transit and
cause drops.

A static ISN for 4-tuple increases the collisions.

Middleboxes that update ISN will stop this working.

Changing TSval could affect TCP PAWS.


Is MD5 the correct algorithm?

Why not use TLS client certs instead?

Someone asked where's key propagation?

I saw a concern with sending RSTs upon a failed port knock (vs. being silent)


Gorry | 26 Jul 20:33 2015

WGLC : draft-ietf-tsvwg-sctp-failover-11.txt to end 10th August 2015.

This email starts a short (2 week) WGLC to confirm that the above draft is ready to publish as a PS. Comments
are welcome via the TSVWG mailing list.

Best wishes, 
Gorry & David
TSVWG Co-Chairs

diffserv marking for rtcwb data channel



I don’t think that it makes much difference (though see further below…) whether one use

different sctp associations for multiple data channels with different

diffserv code points or have this feature be built into SCTP.


The differences I can think of are:

·         end-point performance (only significant if cache and cpu constrained)

·         flow control handling – can be both good and bad to have separate receiver windows perhaps


I do question, however, whether it is a “good” choice to use the diffserv marking and sctp association split for

prioritization of the traffic instead of SCTP scheduling differentiation within one and the same association over a non-marked

or homogeneously marked network.

Especially the two have very different characteristics from a (coupled) congestion control perspective (including loss recovery).


But if both possibilities go in, I suppose that we will learn much more about this in the future.

But one should perhaps do well  to provide some starting ground rules for when one or the other is considered

most appropriate to use – possible try to describe the conditions under which one would like to use one or

the other.  


Finally there was a comment at the tsvwg meeting that the same 5-tuple with different diffserv markings would not get

through the network – if that generally is correct,  then the solution is very easy: one MUST use different associations to get port (5-tuple) differentiation.

I think that if this is correct, one also wants to ask what happens if the diffserv is changed for the same 5-tuple – i.e., is the network

robust to this change even if it is not robust to concurrent usage of different markings for the same 5-tuple.


BR, Karen  




Roland Bless | 23 Jul 19:12 2015

Why a new DSCP can help with Lower Effort deployment


Bob Briscoe commented (to the proposal of using
000010 as new DSCP for LE) that we may simply burn another
DSCP and gain nothing. I don't think so, because we at least
get rid of the ambiguity DSCP CS1 => CS PHB (RFC 2474) or
DSCP CS1 => LE PDB (RFC 3662). This would be at least a step

So let's assume an application wants to use Lower Effort
as defined in RFC 3662. The following cases may occur:
1.) Marked as DSCP CS1
   a.) handled as LE [good]
   b.) bleached => handled as BE [maybe bad (I)]
   c.) dropped [app must be prepared for this (II)]
   d.) handled as in RFC2474 => priority inversion [bad]

2.) Marked as DSCP LE = 000010
   a.) handled as LE [good]
   b.) bleached => handled as BE [maybe bad (I)]
   c.) dropped [app must be prepared for this (II)]

(I) the original intent of LE is to not harm the BE traffic
(II) "the network makes no commitment to deliver LE packets"

So with a new DSCP outcome d.) will disappear, which IMHO is
a good thing.


Fred Baker (fred | 23 Jul 17:47 2015

Two comments re draft-szigeti-tsvwg-ieee-802-11e

First, I think having a defined mapping between IP DSCPs and supporting QoS marks of various topologies is
beneficial to end to end QoS. I suppose it goes without saying that a co-author on a paper is willing to work
on the topic and thinks it's a good idea, but - I am willing to work on the topic and thinks it's a good idea.

Second, whatever discussion we have on specific mappings, I think Tim's original proposal is 80% of the way
there, and is malleable to what it needs to be. Hence, I support the adoption of this draft, and fully expect
that some of its specific recommendations may change in time.

Fred Baker (fred | 22 Jul 09:11 2015

Fwd: New Version Notification for draft-szigeti-tsvwg-ieee-802-11e-01.txt

> Begin forwarded message:
> From: <internet-drafts <at>>
> Subject: New Version Notification for draft-szigeti-tsvwg-ieee-802-11e-01.txt
> Date: July 22, 2015 at 6:28:18 AM GMT+2
> To: Tim Szigeti <szigeti <at>>, Fred Baker <fred <at>>, Fred Baker <fred <at>>, Tim
Szigeti <szigeti <at>>
> A new version of I-D, draft-szigeti-tsvwg-ieee-802-11e-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> Name:		draft-szigeti-tsvwg-ieee-802-11e
> Revision:	01
> Title:		Guidelines for DiffServ to IEEE 802.11 Mapping
> Document date:	2015-07-22
> Group:		Individual Submission
> Pages:		24
> URL:  
> Status:
> Htmlized:
> Diff: 
> 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.
> 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

Joe Touch | 22 Jul 00:12 2015

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

FYI. Minor changes for clarification.


-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-01.txt
Date: Tue, 21 Jul 2015 15:04:46 -0700
From: internet-drafts <at>
To: Dr. Joseph D. Touch <touch <at>>, Joe Touch <touch <at>>

A new version of I-D, draft-touch-tsvwg-udp-options-01.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	01
Title:		Transport Options for UDP
Document date:	2015-07-21
Group:		Individual Submission
Pages:		8

   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


New Liaison Statement, "Explicit Congestion Notification for Lower Layer Protocols"

Title: Explicit Congestion Notification for Lower Layer Protocols
Submission Date: 2015-07-20
URL of the IETF Web page:
Please reply by 2015-10-30
From: Transport Area Working Group (David Black < <at>>)
To: 3GPP (Susanna.Kooistra <at>
Cc: Gonzalo Camarillo <gonzalo.camarillo <at>>,Gorry Fairhurst
<gorry <at>>,Martin Stiemerling <mls.ietf <at>>,Spencer Dawkins
<spencerdawkins.ietf <at>>,John Kaippallimalil <John.Kaippallimalil <at>>,Bob
Briscoe <ietf <at>>,Transport Area Working Group Discussion List <tsvwg <at>>
Response Contact: David Black < <at>>
Technical Contact: Bob Briscoe <ietf <at>>
Purpose: For comment


In 2001, the IETF introduced explicit congestion notification (ECN) to the Internet Protocol as a
proposed standard [RFC3168]. The purpose of ECN was to notify congestion without having to drop packets.
The IETF originally specified ECN for cases where buffers were IP-aware. However, ECN is now being used in
a number of environments including codec selection and rate adaptation, where 3GPP protocols such as
PDCP encapsulate IP. As active queue management (AQM) and ECN become widely deployed in 3GPP networks and
interconnected IP networks, it could be incompatible with the standardized use of ECN across the
end-to-end IP transport [RFC7567].

The IETF is now considering new uses of ECN for low latency [draft-welzl-ecn-benefits] that would be
applicable to 5G mobile flows. However, the IETF has realized that it has given little if any guidance on
how to add explicit congestion notification to lower layer protocols or interfaces between lower layers
and ECN in IP.

This liaison statement is to inform 3GPP, in particular those groups including those involved in 3GPP
Release-10 work on the work item ECSRA_LA (TR23.860) - SA4, CT4, SA2 and RAN2. Please distribute to all
groups that have used or plan to use IETF ECN /AQM RFCs in 3GPP specifications. 

The IETF has started work on guidelines for adding ECN to protocols that may encapsulate IP and interfacing
these protocols with ECN in IP. Then IP may act in its role as an interoperability protocol over multiple
forwarding protocols. This activity is led by the IETF's transport services working group (tsvwg).

The IETF tsvwg kindly asks 3GPP:
1) to tell the IETF tsvwg which 3GPP working groups could be affected by this work.
2) To inform the IETF tsvwg of any specific 3GPP specifications affected by this work.
3) to forward this liaison statement to these affected working groups, and to invite them to review the
latest draft of the guidelines, available here:

Review comments are particularly welcome on:
  - comprehensibility for the 3GPP community
  - usefulness and applicability
  - technical feasibility

Review comments may be posted directly to the IETF tsvwg mailing list <mailto: tsvwg <at>>. Postings
from non-subscribers may be delayed by moderation. Alternatively, subscription is open to all at: <>.

The following IETF specifications or drafts are particularly relevant to this activity (the relevance of
each of them is explained in the first item below):
* draft-ietf-tsvwg-ecn-encap-guidelines
* RFC3168 updated by RFC4301, RFC6040 (ECN in respectively: IP/TCP, IPsec & IP-in-IP tunnels)
* RFC6679 (ECN in RTP)
* RFC5129 updated by RFC5462 (ECN in MPLS)
* RFC4774 (Specifying alternative semantics for the ECN field)
* RFC7567 (Recommendations Regarding Active Queue Management
* draft-welzl-ecn-benefits (Benefits to Applications of Using ECN)

--David L. Black (TSVWG co-chair)

No document has been attached