[e2e] TCP ex Machina

[Jon Crowcroft]

while linux (pick your flavour) cubic isn't vanilla, neither is
microsoft's compound tcp - the latter might have seen a bit more
eval in the literature but the former has seen a lot more big iron
deployment and doesn't appear to have broken the internet yet
(although there are rumours and reports of corner case problems)
but i dont think either of these are "non tcp" - they are variants
on CC behaviour....

but this isn't relevant to the _starting point_ of this discussion
which was the annoucement of an interesting, useful, and
peer-reviewed paper on an experiment on accelating TCP cc research

the folks from MIT just posted a perfectly reasonable message 
about this valuble contribution, 
and some people choose to link their
work with a line of argument, 
which is unfair, and unjustly
including them 
(by at the least not changing the subject line).

also - the ability to do any deployment testing of a new tcp in
anger _requires you_ to be wireline compatible with TCP because of
the "non stadard" but ubiquitous NATs and other middleboxes (as
reported in several papers - e.g. UCL fine wotk on deploying MPTCP
and the difficulties testing in the real world which doesn;t
confoirm to the IETF model much at all any more)

so the gold standard you quite reasonably want to hold people to, 
to show their work doesn't do harm in the wild, 
requires them to do "harm" by making
their new variant TCP appear chameleon like, 
vanilla TCP, so they can get results 

(this, as well as simulation of jain-fairness
beahvous or Remy v. reno, is something I hope the MIT folks do
next)


In missive <51F2B580.9040703 at isi.edu>, Joe Touch typed:

 >>Hi, Jon,
 >>
 >>On 7/25/2013 9:53 PM, Jon Crowcroft wrote:
 >>> I'm sorry, but this smacks of "orthodoxy"
 >>> which is anathema to good science.
 >>
 >>I'm not referring to science, or research. I'm referring to changes to 
 >>TCP that are being pushed for deployment or already deployed.
 >>
 >>E.g., TCP-CT is not an approved IETF standard. It was not taken to 
 >>through the IETF process. But it is *deployed* in Linux. As an example 
 >>of bad behavior, TCP-CT uses a TCP option codepoint that is reserved for 
 >>experiments that are not widely deployed.
 >>
 >>> the reality is that the nature of
 >>> most of the "optimization" work that makes it into good conferences
 >>> (nsdi, icnp, sigcomm, pick your fave)
 >>> are in the nature of the word you use - extensions
 >>
 >>There are different kinds of TCP extensions, falling into at least two 
 >>broad categories:
 >>
 >>	A- extensions to TCP itself
 >>		A1- some intended to make TCP more robust or address
 >>		a corner case
 >>		A2- some intended to correct a problem in TCP's design
 >>		A3- some intended to support a specific use case
 >>
 >>	B- using the TCP protocol ID and coarsely conforming to TCP's
 >>	connection establishment
 >>
 >>I'm not referring to A1 or A2, which includes some published research.
 >>
 >>I'm concerned more about B, and somewhat about A3.
 >>
 >>B-style extensions are really new transport protocols. That's a valid 
 >>area of research, but the deployment reality is that no such new 
 >>transports can traverse widely-deployed non-standard network elements 
 >>(e.g., NATs). So B is really a new transport masquerading as TCP.
 >>
 >>A3 are extensions to optimize specific use cases. The trouble with such 
 >>optimizations is that they can easily undermine a key feature of TCP - 
 >>that it falls back to working nearly all the time it possibly can.
 >>
 >>I don't consider breaking that key property of TCP a good thing.
 >>
 >>Experimentation is fine, as is research. But the medical community 
 >>doesn't start playing with new meds by handing them out on street 
 >>corners like candy.
 >>
 >>...
 >>> so of course there might be extensions which would kick in,
 >>> in the wrong circumstances and do harm -
 >>>
 >>> so do you believe any OS vendor or
 >>> community would ship those?
 >>
 >>Linux. Cisco. Alcatel-Lucent. This is a partial list of vendors who have 
 >>deployed code that uses *the same* experimental codepoint.
 >>
 >>> do you believe that unless the papers about them showed a net win,
 >>> anyone would use them?
 >>
 >>Yes. Linux has done this repeatedly.
 >>
 >>...
 >>> instead of waiting a duty cycle of 1 grad-student-year for a next
 >>> TCP congestion control idea,
 >>> you use a big cluster of machines and evolutionary computing
 >>> to run at the rate of around 100 graduate students-per-week
 >>> and pick the best according to some metric -
 >>>
 >>> you could, if you like, pick a different metric
 >>
 >>I did, and you took issue with it.
 >>
 >>Joe
 >>

 cheers

   jon