[e2e] TCP flow count estimation

[Bruce A. Mah]

If memory serves me right, Jon Crowcroft wrote:

>  >>  Has the IP layer's function been redefined so that it guarantees that al
> l 
>  >>datagrams must be sent along the same physical path and through 
>  >>order-preserving queues?
> 
>  >>We know that IP does not have order preserving queues in general - fast 
>  >>path processing and service-types violate order.  We also know that in som
> e 
>  >>cases, path stability is violated even in the short term.
> 
> well its easy to try look at this with traceroute - time for some experiments
> 
> but the various pathchar programs rely on this hack, and the tiems when i hav
> e seen them
> break are always when there's a level two hop with some type of bandwidth on 
> demand
> (e.g. ATM VC, or frame relay hop with committed access rate policing via a wi
> ndow/token
> bucket scheme).....

Two knee-jerk-reaction thoughts:

I've also seen {p{,ath}char,clink} break (or at least give odd results)
where packets can take multiple links between two hops (i.e. stripe a
couple of T-1s together for more bandwidth).  Another problem is
store-and-forward switched networks (with or without fancy CAR/QOS/
whatever).

Also it strikes me that this technique only works for "elephant"
connections because it'll take a bunch of measurements to try to get rid
of all the queueing delays.

Bruce.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20011129/70947066/attachment.bin