Spencer Dawkins | 18 Mar 03:05 2014
Picon

Draft IETF 89 TSVAREA Minutes posted - please review

Our secretary, Linda Dunbar, has posted draft meeting minutes at 
http://www.ietf.org/proceedings/89/minutes/minutes-89-tsvarea.

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.

Thanks,

Spencer and Martin

Matt Mathis | 7 Mar 09:20 2014
Picon

"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.)

Thanks,
--MM--
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
Picon
Picon

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:
https://sites.google.com/site/transportprotocolservices/home/charter-proposal-before-bof

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:
https://sites.google.com/site/transportprotocolservices/
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:
https://sympa.uio.no/ifi.uio.no/info/transport-services

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.

Cheers,
Michael Welzl

Martin Stiemerling | 28 Feb 10:06 2014
Picon

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.

Thanks,

   Spencer & Martin

Andrea Bittau | 16 Feb 23:58 2014
Picon

new tcpcrypt draft available

Hi,

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

http://www.ietf.org/id/draft-bittau-tcp-crypt-04.txt

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.

thanks!

Linda Dunbar | 15 Feb 00:11 2014

Agenda for TSV area meeting in London 89th IETF

At London 89th IETF meeting, the TSV area meeting will be 9am~11:30am on Thurs March 6  at Viscount.

 

Here is the draft agenda:

 

- TSV AD/NOMCOM  (20 minutes)

- ANRP talk - Keith Winstein -- (20 + 10 minutes)

- How to train other protocol designers about UDP Design Considerations

  (10 + 20 minutes)

- Foo over UDP tunneling discussion - what recommendations does TSV make (and why)? (15 minutes)

- New ideas about ECN  (15 + 15 + 30 minutes)

 

 

Linda (the secretary)

philip.eardley | 14 Feb 10:09 2014

Transport services BoF

Jose, all – sorry, (as I think you guessed!) my comment was about the transport services bof, not TCM-TF

 

phil

 

De: tcmtf [mailto:tcmtf-bounces <at> ietf.org] En nombre de philip.eardley <at> bt.com
Enviado el: miércoles, 12 de febrero de 2014 11:59
Para: jsaldana <at> unizar.es; tcmtf <at> ietf.org
CC: tsv-area <at> ietf.org
Asunto: Re: [tcmtf] BoF preparation: Improvements in TCM-TF according to the received comments

 

<< Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For an application programmer, using protocols other than TCP or UDP is hard>>

 

One thing I think would be useful is to analyse this as a migration problem. I know lots of people have thought about why migration is hard. My take is that the crucial issues are to make sure there is incremental benefit (the party migrating gets a benefit now and not when everyone else has migrated) and to try and ensure migration can be one party at a time (so others don’t have to care – ‘party’ is most obviously one end host, but in some circumstances can be eg ‘Apple iOS’). There’s some quite nice stuff in RFC5218.

 

Best wishes

Phil

 

From: tsv-area [mailto:tsv-area-bounces <at> ietf.org] On Behalf Of Jose Saldana
Sent: 05 February 2014 12:05
To: tcmtf <at> ietf.org
Cc: tsv-area <at> ietf.org
Subject: BoF preparation: Improvements in TCM-TF according to the received comments

 

Hi all,

 

In order to prepare the BoF in London, I have tried to summarize the questions that have been discussed, in order to include the improvements in the charter and in the two drafts.

 

On behalf of clarity, I will send different messages with the solutions for each problem.

 

If you think there are other problems, please start a new thread.

 

 

Problems discussed in the BoF:

 

1) TCP multiplexing and effect on TCP dynamics. (I think this was the main problem).

 

2) Path MTU discovery issues

 

3) Are we adding latency and complexity to save relatively little bandwidth?

 

4) Do vendors want standards in this space?

 

 

Problems discussed in the list:

 

5) Why is ROHC not a solution?

 

 

Jose

 

Jose Saldana | 6 Feb 10:22 2014
Picon

Using the concept of "latency budget" for TCM-TF

Hi all,

 

The report of the Workshop on Reducing Internet Latency (http://www.internetsociety.org/latency2013) talks about a very interesting concept: “latency budget”:

 

“A latency budget is applicable to the application and is consumed by sources of latency.”

“Latency budgets can be hard or soft and may be derived from biological or computational expectations.”

“The application operates effectively only when the cost is kept within the budget.”

 

Since TCM-TF savings require the addition of an small latency as a counterpart, perhaps we could say something like “if an amount of latency budget is available, a part of it can be consumed in multiplexing packets, thus providing bandwidth savings”.

 

And some sentences of the draft about delay limits could even be rewritten accordingly: for example, instead of talking about “delay recommendations” in section 6, we could talk about “latency budget” for each application.

 

What do you think?

 

Best regards,

 

Jose

 

Jose Saldana | 5 Feb 13:06 2014
Picon

Improvements in TCM-TF according to the received comments: Problem 3: additional delays

Problem:

 

Are we adding latency and complexity to save relatively little bandwidth?

Bob Briscoe: (…) “I am concerned about adding latency and complexity to save relatively little bandwidth - when there will be a need for checking the network path.”

Tim Chown: “bufferbloat - could be increasing buffers to group packets up.”

 

 

The answer is related to the idea of TCM-TF itself: it is summarized in n.4 of the charter draft:

 

4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment.

 

In addition, the second draft is about additional delay limits. If you have some “delay budget” available, you can use it.

 

R. Peon: “application can sometimes send multiple packets with the same message so that they have unique probability of loss (not correlated), this is an application choice that needs to be known by a tunnel.”

 

The idea is that a tunnel does not include a number of packets from the same flow, but from different ones.

 

Jose

 

Jose Saldana | 5 Feb 13:05 2014
Picon

Improvements in TCM-TF according to the received comments: Problem 1. TCP multiplexing

Problem:

 

TCP multiplexing and effect on TCP dynamics. I think this was the main problem.

 

[R. Peon]  This is not being done by a host; it is in network, if a separator does not include timing, it could lose delay signals for congestion control based on delay.

 

Solution:

This concern is related to TCP, and it no longer exist because TCP multiplexing is not being considered.

 

 

Jose

 

Jose Saldana | 5 Feb 13:05 2014
Picon

BoF preparation: Improvements in TCM-TF according to the received comments

Hi all,

 

In order to prepare the BoF in London, I have tried to summarize the questions that have been discussed, in order to include the improvements in the charter and in the two drafts.

 

On behalf of clarity, I will send different messages with the solutions for each problem.

 

If you think there are other problems, please start a new thread.

 

 

Problems discussed in the BoF:

 

1) TCP multiplexing and effect on TCP dynamics. (I think this was the main problem).

 

2) Path MTU discovery issues

 

3) Are we adding latency and complexity to save relatively little bandwidth?

 

4) Do vendors want standards in this space?

 

 

Problems discussed in the list:

 

5) Why is ROHC not a solution?

 

 

Jose

 


Gmane