[e2e] packet-pair probe implementation

[Michael Welzl]

Hi all,

Isn't this discussion pointless unless we have an idea what exactly
the "available bandwidth" may be?

I mean, the available bandwidth during what interval? Or an available
bandwidth that will be available for interval x with probability y,
according to prediction method z?

Sadly, it's more complicated than "bottleneck capacity with
cross traffic".

Cheers,
Michael


On Mon, 2003-05-12 at 16:36, Jing Shen wrote:
> IMHO, packet pair probing will not derive to real value of available
> bandwidth if it is not guaranteed that the two packets are scheduled
> specifically along the path.
>  
> In other words, available BW is the speed with which we can satulate
> the e2e path when different queueing mechanism is adopted. So, what we
> want to find is : how the queue on the slowest link could be filled.
> This is really different from what PP based.
>  
> Jing Shen
> 
> Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:
>         In missive <200305031752.h43HqiE18655 at garden.whitehouse.gov>,
>         Donald Rumsfeld typed:
>         
>         >>I believe that Jon is essentially wrong. The packet-pair
>         technique
>         >>is definitely not one of the weapons of Mbps detection
>         
>         I have to agree - but i must reveal a momentary prejudice
>         against pp - i have never been
>         sure about the gender identity of the 2 packets in question -
>         typically, one packet is
>         large and one small (to elicit different responses) but why?
>         surely this is the usual
>         "bigger is better" type engineering macho thing - i am sure
>         people (typical male engineers)
>         think of that MTUs-worth, thrusting its way thru those queues,
>         while the slight,
>         deferential-almost, acknowlegement sized frame wends its
>         interesting path. of course, the
>         alternative, use of similar type packets is in question in
>         some states, where its probably illegal, 
>         and the ! ttl may therefore be exceeded sooner than expected.
>         then there are the occasional uses by
>         government agencies of xmas tree (aka bush) packets,
>         accompanied by much smaller, shadow packets 
>         which are hard to detect (i have heard people say that there
>         is almost a witch hunt for
>         these so-called blur or blaring packets that are so dificult
>         to pin down - i am sure caida have
>         elegant tools and tweezers that will do the trick tho)
>         
>         i guess there are those occasional people (some in
>         scandinavia, i've heard)
>         who prefer 3-somes or more, and claim that there
>         is more fidelity in the reproduction of results - i await an
>         IMW paper or two to supprt
>         this
>         
>         then there's the cloning method - why try a probe when you can
>         imitate the patient to perfection?
>         well, i for one am not a sheep, content merely to follow the
>         flock. no, i think that if 0 or 1 
>         are good enough, then the search should concentrate on
>         figuring out what the capacity of a path is,
>         using! a lone wolf approach - the idea here is that we send 1
>         packet out, bu t that it not
>         only propogates, but it also removes another packet in flight
>         - so as we extend the
>         wolverine's ttl, it samples along hops with queues which
>         either have the original, or 1 less,
>         packet than previously encountered (think of this as a feynman
>         interaction in reverse with
>         packet and anti-packet starting at each point - kind of
>         extreme, adversarial queueing)
>         
>         now the trick with this latter idea is how to implement it! i
>         guess it depends on whether
>         one can affect already queued packets by modifying the ACL on
>         the output queue (or perhaps
>         changing priorities if custom queueing is enabled). a laudable
>         part of this approach is
>         that it incurs less load than packet-pair....
>         
>         of course, i could just be joking...
>         
>         cheers
>         jon
> 
> 
> Jing Shen
> 
> State Key Lab of CAD&CG
> ZheJiang University(YuQuan)
> HangZhou, ZheJiang Province 310027
> P.R.China
> 
> 
> 
> ______________________________________________________________________
> Do You Yahoo!?
> "相见不如聊天!不出门一样面对面！网络摄像头对对派送中~赶快用你的雅虎电邮帐号参与吧……
-- 
Michael Welzl <michael.welzl at uibk.ac.at>
University of Innsbruck