question 1: how bad does TCP burstiness hurt?
--------
o motivation: most (>~85%) of packets are sent in slow start and hosts
are supposed to send acks for every other packet, so most packets will be
sent in bursts of 2-3, rather than nicely paced by acks as Van presumably
originally envisioned. this presumably leads to some level of needless
q-ing and loss. how bad is it? this will help tell us how important
traffic smoothing is.
o experiment 1: do ns simulations of lots of short TCP flows going thru
multiple congested bottleneck links where
a) everyone's using today's bursty tcp
b) everyone's using a more sane, smoothed tcp
(perhaps spreading window out evenly over a full RTT)
c) one lonely person is doing a smooth tcp (to see if they get hurt
or get an unfair-ly large share)
o experiment 2: do internet measurements of a
a) a regular TCP that is sending repeatedly to lots of places in the
net
b) TCP that has been hacked to send at a smooth rate, sending to the
same places at roughly the same times
question 2: what are the "optimal" constants for TCP cwnd increase?
-------
o motivation: though maybe vern has looked at this, i don't know of
anyone who has justified the rates of cwnd increase used in TCP.
o experiments: again, use ns and TCP hacking to look at TCPs with varying
rates of cwnd increase during slow start and congestion avoidance.
question 3: how stable is the available or "safe" bandwidth?
---------------
o motivation: i dunno if anyone has looked at how quickly the available
bandwidth changes, or the rate at which cwnd info should be aged for
schemes like Venkat's fast start. there is an implicit assumption that
the "safe" rate is stable over the order of a few RTT. but i don't know if
this has been established.
o goal: find a model that says: "if i know my TCP bandwidth is X now, for
what bandwidth Y can i be Z% confident that my bandwidth in T seconds from
now will be at least Y?" [this should allow us to fast/jump start to
bandwidth Y if we have cwnd info that is T seconds old]
o experiment 1: look at TCP traces to try to find a relationship between
window size, time, and the probability of a loss
o experiment 2: use a tool like Stefan's (a bizarro user-level TCP) to
send random amounts of data each RTT, to try to build up a table that
relates your cwnd this RTT, your cwnd next RTT, and the odds you'll
experience a drop in the next RTT.
neal