Carsten Bormann | 21 Jul 17:09 2014

CoAP Congestion Control Wed 15:23–15:43 Territories

We are planning to discuss the current proposal for adding “advanced” congestion control to CoAP at
the Wednesday CoRE meeting.


To enable TSV people to come in and leave after the segment, we have allocated 20 minutes right at the start of
the meeting for this.
So I hope to see some transport people, even if you go on to watch the sparks at the DTNWG BOF afterwards.

Grüße, Carsten

Martin Stiemerling | 15 Jul 08:49 2014

meet your Area Directors: TSV AD "office hours" at IETF-

Dear all,

This is the announcement of the TSV AD "office hours" at the IETF-90 
meeting in Toronto.

The office hours are for the case there are things that you need to 
discuss with the Transport Area Directors in person and aren't able to 
pin us down any other time.

The time slot reserved for the office hours is

Thursday, July 24th, from 11:45 am to 12:45 pm.

The room will be announced on Monday, July 21st.

Please let us know in advance if you are planning to meet us, so that we 
can plan a bit ahead.


   Spencer & Martin

Jose Saldana | 10 Jun 10:38 2014

New version (v7) of TCM-TF draft

Hi all.


A new version (v7) of the main TCM-TF draft has been submitted to the IETF web page.


Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model, draft-saldana-tsvwg-tcmtf-07



Some of the improvements are:


- Stating that TCM-TF must keep backwards compatibility with RFC4170. Some people suggested it on the last BoF, because some devices already implement it.

- Adding some new information about Community Networks.

- Adding the possibility of optimizing UDP traffic of Constrained RESTful Environments (

- Adding three new references.

- Slightly improving some figures.


Your comments will be welcome.


Best regards,


Jose Saldana


A new version of I-D, draft-saldana-tsvwg-tcmtf-07.txt has been successfully submitted by Jose Saldana and posted to the IETF repository.


Name:             draft-saldana-tsvwg-tcmtf

Revision:         07

Title:                Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) Reference Model

Document date:         2014-06-10

Group:             Individual Submission

Pages:                        26







   Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a

   method for improving the bandwidth utilization of network segments

   that carry multiple flows in parallel sharing a common path.  The

   method combines standard protocols for header compression,

   multiplexing, and tunneling over a network path for the purpose of

   reducing the bandwidth.  The amount of packets per second can also be



   This document describes the TCM-TF framework and the different

   options which can be used for each layer (header compression,

   multiplexing and tunneling).





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



Stefan Winter | 5 Jun 15:35 2014

Review of draft-ietf-radext-radius-fragmentation?

Hello tsv-area,

I'm co-chair of radext and the document shepherd for the above document,
and it's currently awaiting its PROTO write-up.

As I went through the latest revision, it occured to me that there are
quite some transport considerations in this, which are beyond my
technical knowledge.

In short:

A protocol that previously had no fragmentation support (RADIUS over
UDP, max size 4096 per datagram, max one datagram in flight, may be
"routed" via RADIUS proxies in a kind of overlay network) now gets some;
the fragmentation is done in a way which is "far away" from the usual
way - no sequence numbers, duplicate detection is based on a randomly
chosen State attribute, there is no explicit NAK for missing chunks and
instead the RADIUS timeout is the only way to detect and correct
fragments gone AWOL. There may be fragmentation-aware and -unaware
RADIUS proxies on the path between sender and ultimate recipient of the

I'm thinking that this warrants a closer look by TSV experts. Am I
asking at the right place?

The draft is here:


Stefan Winter


Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me
Attachment (0x8A39DC66.asc): application/pgp-keys, 3249 bytes
Black, David | 14 May 22:52 2014

Fragmentation and Path MTU text in nvo3 dataplane reqts draft

<WG chair hat off>

Over in the nvo3 WG, draft-ietf-nvo3-dataplane-requirements-03 contains
some text on dealing with the fragmentation and MTU effects of tunnels.
I thought I'd ask for some early review of this text, given recent IESG
excitement around fragmentation and Path MTU topics in another draft: 

I believe that the nvo3 draft is in better shape in these areas.  Nonetheless,
I've included its current text on fragmentation and path MTU below, and (on
behalf of the draft authors and nvo3 WG chairs) I'm looking for input on
what that text should say and why.

In nvo3 terminology, an overlay network is an inner network that is tunneled
over an outer underlay network.  The nvo3 WG also uses "Tenant System" as
the term for a sender/receiver of network traffic because multi-tenancy is
an important motivation for the WG's activities in network virtualization.


3.5. Path MTU

       The tunnel overlay header can cause the MTU of the path to the
       egress tunnel endpoint to be exceeded.

       IP fragmentation SHOULD be avoided for performance reasons.

       The interface MTU as seen by a Tenant System SHOULD be adjusted such
       that no fragmentation is needed. This can be achieved by
       configuration or be discovered dynamically.

       Either of the following options MUST be supported:

          o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
            Extended MTU Path Discovery techniques such as defined in

          o Segmentation and reassembly support from the overlay layer
            operations without relying on the Tenant Systems to know about
            the end-to-end MTU

          o The underlay network MAY be designed in such a way that the MTU
            can accommodate the extra tunnel overhead.


</WG chair hat off>

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

Spencer Dawkins | 13 May 17:21 2014

Fwd: [irtf-discuss] Call for Nominations: 2015 Applied Networking Research Prize (ANRP)

It's worth noting that several previous winners worked in the TSV space, so I'd love to see plenty of good nominee papers.


-------- Original Message -------- Subject: Date: From: Reply-To: To:
[irtf-discuss] Call for Nominations: 2015 Applied Networking Research Prize (ANRP)
Tue, 13 May 2014 09:23:45 +0000
Eggert, Lars <lars <at>>
anrp <at> <anrp <at>>
irtf-discuss <at> <irtf-discuss <at>>

CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2015 ******************************************************************** *** Submit nominations for the 2015 award period of the *** *** Applied Networking Research Prize until October 31, 2014! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: • cash prize of $500 (USD) • invited talk at the IRTF Open Meeting • travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) • recognition at the IETF plenary • invitation to related social activities • potential for additional travel grants to future IETF meetings, based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: • the name and email address of the nominee • a bibliographic reference to the published (or accepted) nominated paper • a PDF copy of the nominated paper • a statement that describes how the nominated paper fulfills the goals of the award • a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety • a brief biography or CV of the nominee • optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at In exceptional cases, nominations may also be submitted by email to anrp <at> IMPORTANT DATES Applications close: October 31, 2014 (hard) Notifications: December 1, 2014 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at

Spencer Dawkins | 18 Mar 03:05 2014

Draft IETF 89 TSVAREA Minutes posted - please review

Our secretary, Linda Dunbar, has posted draft meeting minutes at

Please take a moment to review these - she did a great job of capturing 
our conversations, but there are a few missing names, etc. we'd like to 
fill in.


Spencer and Martin

Matt Mathis | 7 Mar 09:20 2014

"Is there CC?" is the wrong question...

The ongoing debate about tunnels and congestion control is over the wrong question. The presence of congestion control in the tunnel is neither sufficient nor necessary to protect the network from the tunnel.

Let me define two terms: traffic or applications are "elastic" if increasing loss causes decreasing presented load and "regenerative" if increasing loss causes increased load (from the sender to the loss point).   Clearly regenerative traffic is a bad thing because it can cause "latchup" and congestion collapse like behaviors.  You would think that regenerative protocols would be rare, but they are not.

The problem is that it is trivial to construct applications that are regenerative.  For example, if you use TCP to deliver low rate CBR (constant bit rate) traffic, then the TCP retransmissions are regenerative until the loss rate is sufficient to cause the system to fail. This sounds like a corner case, but it is not.  Suppose you are serving 250 kb/s flows to forty thousand individual near clients (20 mS RTT). These flows will do a reasonable job of meeting their target rates at up to several percent loss (I'm guessing 3%).  If I vary the load by increasing the number of flows into a fixed 10 Gb/s shared bottleneck, the total loss rate will suddenly spiral out of control once the aggregate target goodput exceeds the link capacity.  The loss rate will rise until some or all of flows fail to meet the required performance. 

I point out that *every* non-throughput maximizing protocol or application using retransmissions to implement reliable delivery has the potential to be regenerative, because the net goodput is determined by some other part of the system.  The presence of CC is not at all sufficient to eliminate pathological behaviors.

As long as the tunnel does not itself do something regenerative (for example by repairing losses to protect its payload) the tunnel does not change the extent to which its traffic is regenerative.

Congestion control helps because it makes throughput maximizing traffic extremely elastic, which can absorb (offset) other regenerative traffic.  It also guarantees that at some scale all traffic will ultimately become elastic.  However this transition is typically way beyond the point where non-background applications are useful.   Furthermore there are other mechanisms that can make traffic elastic, for example by users abandoning applications when they don't work.

We have been asking the wrong question about tunnels and everything else. The real question is "Under what condition is the traffic regenerative?" or alternatively "Is there sufficient elastic traffic to offset the regenerative traffic in the ensemble?  Is the regeneration sufficient to cause latchup?   These questions are orthogonal to the presence of congestion control.

(There is also a similar set of questions about goodput vs throughput and useless data arriving at the receiver, again related to the strength of the retransmission strategy and not the presence of CC.)

The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.
Michael Welzl | 5 Mar 17:29 2014

TAPS BOF: clarifications and pointer to mailing list

Dear all,

I thought it would be helpful to give a little clarification about the TAPS BOF, for those of you who were there.

I was under the impression that what we're really planning to do didn't quite get across: an API? where? a
middleware? So...

Defining and prescribing *one* API in *one* place of the stack is *not* the major goal of TAPS. The goal is to
identify the services that are provided by IETF-defined transport protocols, look at services that
applications really want from the network, and see how we can map the two onto each other. This is more
abstract than an API in that it is not associated with one particular layer - it is helpful as
implementation guidance for people doing APIs or middlewares. We have written a draft charter that tries
to reflect that quite some time ago already:

If you look at the deliverables, you'll see the actual scope that we are thinking of. We would describe an
example API, and we would specify how the services *can* be provided, but these two things are both meant as examples.

The intention of the agenda was:
- to give an overview of why this is needed (Jon's presentation)
- to give an example of how a richer set of services than just TCP and UDP can benefit an already widely
deployed middleware, as an easy deployment path (don't change applications, just the middleware)
(Martin's presentation)
- to give an *example* of how this could be implemented (Gorry's presentation)
- to explain how this relates to MIF (Margaret's presentation)

I am sorry if this wasn't clear enough; now I see that I should have perhaps given this background initially,
but one always knows better in retrospect...

Please note that there is a website associated with this:
with e.g. drafts, such as draft-hurtig-tsvwg-transport-apis-00 (this one should clarify some things,
hopefully), and also an FAQ page, with answers to questions such as "Shouldn't this be an IRTF activity?".
If you have such questions, the best thing to do would be to check this page, and if you disagree with what you
see there, please join our list and tell us.

=> Well, please join us anyway if you're interested. The list subscription page is:

I thank everyone who attended for a lively and interesting discussion, and I hope we can find a commonly
agreed upon way to take this work ahead.

Michael Welzl

Martin Stiemerling | 28 Feb 10:06 2014

Meet your Area Directors: TSV AD "office hours" at IETF-89

Hi there,

This is the announcement of the TSV AD "office hours" at the IETF-89 
meeting in London.

The office hours are for the case there are things that you need to 
discuss with the Transport Area Directors in person and aren't able to 
pin us down any other time.

The time slot reserved for the office hours is

Thursday, March 6, from 11:45 am to 12:45 pm.

The room will be announced soon.

Please let us know in advance if you are planning to meet us, so that we 
can plan a bit ahead.


   Spencer & Martin

Andrea Bittau | 16 Feb 23:58 2014

new tcpcrypt draft available


For those interested, we posted a revised version of the tcpcrypt
draft (opportunistic TCP encryption):

This will be discussed on Monday morning in tcpm, at the end of
Session 1 (09:00--11:30).

All comments are welcome, including any points that you'd like us to
address in our presentation.