multi-homing fixes

Sun Sep 2 17:17:14 UTC 2001

> Understand [1] well, but not [2]. Care to elaborate?
> 
> I'd have thought there were trivial counterexamples (i.e. when
> it 'is so'), f'rinstance when one path has both huge delay and
> large packet loss.

sorry.  yes, it's possible to construct a scenario which makes udp seem like
a fine predictor of tcp performance.  necessary constraints for the experiment
include the number of simultaneous tcp sessions going over the probed path,
and also the average and maximum size of the sessions, and so on.  but for
observed traffic over observed paths, neither measured DNS RTT nor anycast DV
show any similarity to the "time to last byte" of any known TCP implementation,
especially not the bad (and dominant) ones.

the example we used back at vayu was to compare a 56K serial link to a 1Gb/s
satellite link.  anycast DNS says that one of them is better.  TCP says that
the other is better, but only if the file is larger than 16KB.  "you pick."

(i'm trying to decide whether vayu is dead enough that it would be safe to
publish any of the whitepapers we did on this general topic.)