[e2e] Google seeks to tweak TCP

[Daniel Havey]

> well, perhaps - sometimes, i just wish TCP would simply
> get out of the way... 
> 
> Jon,
> 
I like this ;^)


> as science is usually thinking in alternatives: What is your
> alternative for TCP? Anybody is free to propose one.
> 
Hmmm, not really.  If a service provider drops non-TCP packets then my TCP alternative will never have a chance to get off the ground.  I could build it, but, what is the point if nobody will use it?

I believe that any new solution must not only play nice with TCP, but be indistinguishable from TCP.  Otherwise the packets may be dropped.


> In addition, I wonder, why we need Science at all. We
> already have Google and Wikipedia and obviously, research is
> no longer being done by academics or by some huge companies
> but by Google.
> 
> Brave new world.

Hehe ;^)  I wish I would have known that before I started this PhD!  We still do research at UCSB anyways ;^)

> And whenever people are exited by simple recipes which save
> the world, we always should keep in mind RFC 1925.
> >     (6)  It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

This is getting interesting.  So the goal of Cubic (from the paper) is to provide more RTT fairness.  It does this.

I don't think that queuing delay is the only cause of large RTTs.  Sometimes a link is just slow and sketchy.  Happens all the time.  maybe 802.11n has negotiated a slow rate or there are lots of retransmissions.  There will probably be a lot of packets in the queue because of this, but, the link is slow and that is why the RTTs are large.  I'm thinking of projects like "Wireless Africa" where links are slow and lossy.

Such links have difficulty even reaching their tiny capacity with Reno.  They do much better with Cubic.

Soooo, if Cubic causes more delay for the faster stations, perhaps it is moving the problem?  The disadvantaged stations are happy, because they are getting their little bit of throughput, and the advantaged stations have to live with a few more tens milliseconds of delay?

Is Cubic causing more of the problem that it solves?

Finally:
If Google is God, then I am an atheist ;^)
That being said, if Google decides to use Cubic on their youtube servers, then I have to live with that choice.

It doesn't really matter what we do with our little receiving stations, because, Google has chosen.  If I want to watch a youtube video then I will comply with their choice.  Even if it is not a good choice for me.

...Daniel

It really would be nice if TCP would just get out of the way...