o today's 590s macroscopic paper suggests a particular model for tcp
behavior that suggests tcp is hypersensitive to loss. we could do some
http gets of typical web documents and see how far off from the model they
are. while doing this, are losses really still 5%, like paxson says they
were?
o a question: is TCP's crappy behavior today (as seen in the macroscopic
paper) caused by the additive increase being to anemic, the additive
increase not being gradually adaptive (a la Vegas), or the multiplicative
decrease being too drastic (and not being gradually adaptive somehow). we
could re-do the simulations from the macroscopic paper, modifying tcp to
look at these factors independently.
o more particular, but maybe well-known: why do we have the particular
constants for additive increase (one MSS per RTT) and multiplicative
decrease (cwnd=/2) that we do? the former seems to liberal and the latter
too conservative to me.
o Thinking out loud about one traffic shaping vision: Why is it so hard to
deploy a new TCP (say, Vegas, or SACK)? taking the wart traffic shaping
idea to the limit, one could imagine a model for networks that would help
alleviate this problem, by centralizing all smarts about networks, just as
Kimera advocates centralizing smarts about security. the end hosts have
absolutely stupid network stacks, which never change. for WAN flows, they
talk only with a single wart (or wart cluster) for the institution in
which they live, using a credit-based scheme. this can be blindingly fast,
since LANS are overprovisioned. wrt to forwarding to the WAN, the wart
does snazzy vegas-style TCP using shared info (SPAND plus maybe deducing
shared bottlenecks) about bottlenecks to set initial congestion windows.
when the ietf recommends some new tcp variant, you need only change one
TCP stack per university, company, and ISP.
o A random thought: if i'm reading the macroscopic paper right, the
bandwidth acheivable by TCP is inversely proportional to the RTT. i'm
probably missing something huge here, but it seems terribly awfully broken
that making a the wire twice as long halves the bandwidth i can get. Going
to JZ's physical analogies (which i think is a great idea): if i made a
water pipe twice as long, would i expect to be able to push only half as
much water through? This may go back to the suggestion of adding routers
along long paths and doing hop-by-hop stuff to give more immediate
feedback.
o another random thought: we may want to find an alternative to "wart"
before the retreat...
neal