Stefan's list from july:
1) Validating models of dependent packet loss that we're
developing for slow start
2) Validating a model on how packet loss affects TCP connection
establishment.
3) See the distribution of advertised receiver windows is.
4) Separate out low bandwidth flows (ie from modems)
5) Separate out short flows
6) Correlation between burstiness and drop rate
7) Effect of multiple slow starts through a bottleneck on drop
rate
(ie can we guess which packets should be proactively dropped with high
probability).
Some more rambling thoughts on what we could do with the traces:
- analyzing web perf bottlenecks - to what extent is each of these a
factor/problem:
server compute time, disk performance, CPU load, connection request
queing?
congestion-induced losses?
protocol? (handshake),
implementation? (ack policy, slow start, stupid congestion
sawtoothing, coarse RTOs, receive window limitations)?
- recognizing TCP implementations
- can we distinguish between different TCP implementations (MS,
Solaris, Linux...)
- how popular are the various implementations?
- how often do the bugs in these implementations pop up, in practice?
- how smart/broken is TCP?
- how are acks typically generated? ack-every-other (spec), ack-every
(best perf; probable for modem), ack-a-few (most common in practice?)
- how many losses are probably caused by ramping up until loss?
- how often is slow start too conservative? too aggressive?
- how often would the proposed 4-MSS initial congestion window for
TCP be too aggressive?
- how often do receive windows limit performance?
- how often would Vegas have been able to detect that a (long) TCP
flow is sending too fast?
- SACK
- how often is SACK used (Win98, Linux 2.1,others? have it)
- how well does it work, in practice?
- can TCP parameters be re-used across flows within an organization
to good effect? can we aggregate/share congestion control info?
- do enough flows go to the same places within short enough time
windows?
- is there a strong enough correlation in the path characteristics
seen by these flows (losses, RTT, RTO, cwnd) for them to share info?
- what if a browser only opens one or two connections to a server?
is it still advantageous?
- how often would a wart be able to send a rate hint or
proactively drop/delay packets?
- could a TCP/HTTP proxy gain anything just by reusing connections
with a server, to avoid TCP handshake and slow start?
- this could probably be answered by HTTP traces
- TCP burstiness
- how bursty is TCP?
- to what extent does burstiness lead to losses?
--> may motivate a smoothed TCP
- how does TCP/HTTP behave over modems?
- how well-utilized are modem links?
- what's the queuing behavior?
- how big are RTOs?
- how big are cwnds?
- what MSSes are being used? which is best?
- what receive windows are being used? which is best?
- multimedia traffic
- how much audio/video traffic is there (Real Video/Audio, MS Media
Player, MBONE)? what are the growth trends?
- how fast are these flows?
- can we say anything about their congestion control behavior?
- any analysis that Vern Paxon did with TCP traces or Hari did with the
Olympic web traces can be repeated with a much wider and more
representative sample of hosts, implementations, and paths