Re: TCP ex Machina
Jon Crowcroft <[email protected]>
| Newsgroups | gmane.network.end2end |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected] 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 <[email protected]> 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