[e2e] TCP ex Machina

[Jon Crowcroft]

yes, i think it is hard (probably patholiogically hard) to come up
with a network scenario that would make you do (significantly)
worse than human designed CCs...

purely hypothetically, one can imagine an adversarial network
designer, designing a total extinction event for any evolutionary
congestion control system  - however, such a designer wou;dn't get
employed for very long - i suggest that it is reasonable to
consider that network designers (e.g. queuing discipline hackers in
switch/router companies, buffer dimensioning scientists in ISPs and
Telcos) aren't really trying to be adversarial, and are more
inclined to consider the types of customer flows they are supporting

thinkin about the axelrod game one can play, the scenario is one
where players are competing for a share of flow, but players are
members of species, for whom there are many individuals, so the
strategies for each species compete, but dont want to drive flow
rate (population) to zero for other individuals in the same gene
pool, so the evolution of a mix of cooperation (i.e. tcp
friendliness) is inevitable - designers who manually avoid this
will end up being blocked by ISPs (thru deployment of TCP-bad
detectors in all those middleboxes (that already mung with tcp))...

imho

In missive <CAMzhQmO4JKJgLhG-XAePCy-rVyUKaPmZrXXmK28h3azu17cWLg at mail.gmail.c
om>, Keith Winstein typed:

 >>Hello Detlef,
 >>
 >>I appreciate your thoughts.
 >>
 >>You wrote, "I'm not completely convinced that this approach actually yields
 >>a congestion control algorithm which can be generalized and works with an
 >>arbitrary scenario."
 >>
 >>Of course, neither are we. As I wrote, this is academic research, in
 >>simulation, and we hope it will represent the beginning of a longer
 >>conversation.
 >>
 >>To be clear, no current CC scheme works with arbitrary scenarios.
 >>Human-designed loss-triggered schemes do poorly if the network has big
 >>buffers or exposes stochastic loss. Delay-triggered schemes have had other
 >>difficulties that you noted. The best in-network schemes to date don't work
 >>well with the varying link speeds seen in wireless links.
 >>
 >>All of these schemes make assumptions about the network. We think it would
 >>be better if the assumptions and goals were explicit. And if you're going
 >>to do that, you may as well try to make the scheme be a function of those
 >>inputs.
 >>
 >>In our paper, we showed that computers can generate congestion-control
 >>schemes that outperform human-designed schemes over particular ranges of
 >>simulated example networks. We publish these sets of scenarios and the
 >>simulation setup for turnkey replication. (http://web.mit.edu/remy)
 >>
 >>What would be cool would be if you used the Remy tool and demonstrated
 >>concrete use cases where a computer-generated scheme could not be developed
 >>to give acceptable performance over the whole set. That would be pretty
 >>interesting! And then we can talk about, well, why does that happen, and
 >>whether there is another congestion signal or search strategy we should add
 >>that fixes the problem, or whether this represents a more fundamental
 >>difficulty.
 >>
 >>We've shown it works -- in certain ranges of scenarios. If you can show it
 >>doesn't work in other cases, that's very interesting and would motivate
 >>further discussion. We are trying to break it too!
 >>
 >>Best regards,
 >>Keith
 >>
 >>
 >>On Thu, Sep 19, 2013 at 4:04 PM, Detlef Bosau <mail at detlef-bosau.de> wrote:
 >>
 >>> Unfortunately, the discussion I wanted to initialte did not really start
 >>> perhaps due to the difficulties with some posts?
 >>>
 >>> Nevertheless, I would appreciate any comment on my remarks.
 >>>
 >>>
 >>> Thanks,
 >>>
 >>> Detlef
 >>>

 cheers

   jon