[e2e] TCP ex Machina

Jon Crowcroft jon.crowcroft at cl.cam.ac.uk
Mon Jul 22 00:04:30 PDT 2013

Richard Clegg at UCL presented a nice study recently where he has being
trying to fit TCP equations to lots if big packet traces...he found
precious few loss events, and the best explanation appears to be that the
world is made of many zebras and mice....zebras are flows that are
application rate limited...e.g video streaming...mice are flows that just
don't make it out if slow start before they are done...eg web transactions,
social media chat etc...it appears TCP CC is rarely invoked these days......

The other comments I'd make about the Remy thing is that it may be
overfitting (like latterday netflix prize entries)..oh and they need to do
more work on fairness I suppose...

But I still like it
On Jul 22, 2013 7:35 AM, "Fred Baker (fred)" <fred at cisco.com> wrote:

> I'm not sure folks are really concerned about operating boundaries as much
> as outcomes. In general, and in specific in the words of Nandita Dukkipati
> and folks like her, I think folks would like to maximize throughput and
> minimize the wall clock time it takes to deliver an item of data. Most of
> our algorithms confuse that with maximizing the amount of data in the
> network at any given time; I'll argue that this maximizes both throughput
> and the probability of loss, which increases the amount of time it takes to
> deliver something. Stated in terms of operating boundaries, I think the
> optimal TCP-or-equivalent probably maximizes throughput while minimizing
> its effective window - it keeps just enough outstanding to maximize
> throughput, and as a result minimizes its own loss rate and the loss rates
> of sessions it interacts with. Literally doing that, as CalTech FAST does,
> runs the risk of being too gentlemanly, but CAIA CDG, which will detect
> when it is competing with a sub-optimal transport like CUBIC, will in
> effect switch to a loss-based algorithm under duress. But I think
> maximizing throughput while minimizing the probability of loss is probably
> the holy grail.

More information about the end2end-interest mailing list