[e2e] TCP flow count estimation

[Jon Crowcroft]

In message <F66A04C29AD9034A8205949AD0C901040194D91F at win-msg-02.wingroup.windep
loy.ntdev.microsoft.com>, "Christian Huitema" typed:

 >>This algorithm breaks badly if a box on the way implements some form of
 >>leaky bucket admission control, and if the leaky bucket can allow more
 >>than 2 packets. The test packets will detect the underlying link
 >>capacity, while a stream of real packets would be constrained by the
 >>token arrival rate.
 
yes, i know - thats one of the pathchar failure cases

yet another good reason not to do level2 magic.
 >>
 >>> -----Original Message-----
 >>> From: Jon Crowcroft [mailto:Jon.Crowcroft at cl.cam.ac.uk]
 >>> Sent: Thursday, November 29, 2001 7:02 AM
 >>> To: David P. Reed
 >>> Cc: Jon Crowcroft; end2end-interest; Jon.Crowcroft at cl.cam.ac.uk
 >>> Subject: Re: [e2e] TCP flow count estimation
 >>>=20
 >>>=20
 >>> In message <5.1.0.14.2.20011129094501.0391f488 at mail.reed.com>, "David
 >>> P. Reed" typed:
 >>>=20
 >>>  >>Jon - A cute estimator, but besides doubling the header overhead
 >>> and
 >>>  >>routing overhead network wide ...
 >>>=20
 >>> well, most apps that do long transfers are using MSS and many MSSs are
 >>> 1500 bytes, so
 >>> its not so bad:-)
 >>>=20
 >>>  >>  Has the IP layer's function been redefined so that it guarantees
 >>> that all
 >>>  >>datagrams must be sent along the same physical path and through
 >>>  >>order-preserving queues?
 >>>=20
 >>>  >>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 some
 >>>  >>cases, path stability is violated even in the short term.
 >>>=20
 >>> well its easy to try look at this with traceroute - time for some
 >>> experiments
 >>>=20
 >>> but the various pathchar programs rely on this hack, and the tiems
 >>> when i have 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 window/token
 >>> bucket scheme).....
 >>>=20
 >>> so i dont think there's too many cases in the real net out there that
 >>> would confuse this
 >>> besides, like MTU discovery, you only need to do it at the start of
 >>> every route's
 >>> lifetime (icmp "route changed" message considered useful ? :-)
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>>  >>At 06:24 AM 11/29/2001 +0000, Jon Crowcroft wrote:
 >>>  >>
 >>>  >>
 >>>  >>>here's a daft idea for xmas:
 >>>  >>>
 >>>  >>>if tcp is sending instead of MSS, alternate packets of size
 >>>  >>>MSS-1, and size 1
 >>>  >>>(well payload size)
 >>>  >>>and every packet elicits an ack,
 >>>  >>>it can use path char style estimation of the bottleneck line rate
 >>>  >>>
 >>>  >>>it can use equation basedestimation of the bottlenck avaialble
 >>>  >>>capacity
 >>>  >>>
 >>>  >>>between these two, it can deriv an estimate of the number of other
 >>>  >>>tcps (wel module notknowing their RTTs)
 >>>  >>>
 >>>  >>>this might be useful for somethig....
 >>>  >>>
 >>>  >>>j.
 >>>  >>>oh, if every other packet elicits an ack, then you need to
 >>> intersperse
 >>>  >>>the small/large alternation over  3 packets - simple tho
 >>>  >>>
 >>>  >>>think of it like running 2 seperate tcp flows tho, one with MSS 1
 >>>  >>>bute, one with mtu-41 and estimators for both
 >>>  >>
 >>>=20
 >>>  cheers
 >>>=20
 >>>    jon
 >>

 cheers

   jon