[e2e] packet-pair probe implementation
Jon Crowcroft
Jon.Crowcroft at cl.cam.ac.uk
Tue May 13 02:16:45 PDT 2003
In missive <20030512143637.50685.qmail at web15202.mail.bjs.yahoo.com>, =?gb2312?q
?Jing=20Shen?= typed:
>>IMHO, packet pair probing will not derive to real value of available band=
>>width if it is not guaranteed that the two packets are scheduled specific=
>>ally along the path. In other words, available BW is the speed with which=
>> we can satulate the e2e path when different queueing mechanism is adopte=
>>d. 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
joking aside:
Van's original release notes with pathchar explain how you derive the
capacity from a series of measurements...
the biggest problem i have had with all the pathchar variants
is level 2 trickery interfering with the queue service rate
(on wireless (MAC and GPRS scheduling), on MPLS (ATM or frame relay
CIF window effects etc), on paths with multilink, isdn channel
bonding, or multipath routing in operation, etc etc etc)
>>
>>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 (typic=
>>al 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, w=
>>here its probably illegal,=20
>>and the ttl may therefore be exceeded sooner than expected. then there ar=
>>e the occasional uses by
>>government agencies of xmas tree (aka bush) packets, accompanied by much =
>>smaller, shadow packets=20
>>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 hear=
>>d)
>>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 th=
>>e 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=20
>>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, =
>>but 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 interactio=
>>n in reverse with
>>packet and anti-packet starting at each point - kind of extreme, adversar=
>>ial queueing)
>>
>>now the trick with this latter idea is how to implement it! i guess it de=
>>pends 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 th=
>>is 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!?
>>"=CF=E0=BC=FB=B2=BB=C8=E7=C1=C4=CC=EC!=B2=BB=B3=F6=C3=C5=D2=BB=D1=F9=C3=E6=
>>=B6=D4=C3=E6=A3=A1=CD=F8=C2=E7=C9=E3=CF=F1=CD=B7=B6=D4=B6=D4=C5=C9=CB=CD=D6=
>>=D0~=B8=CF=BF=EC=D3=C3=C4=E3=B5=C4=D1=C5=BB=A2=B5=E7=D3=CA=D5=CA=BA=C5=B2=
>>=CE=D3=EB=B0=C9=A1=AD=A1=AD
>>--0-275067073-1052750197=:50488
>>Content-Type: text/html; charset=gb2312
>>Content-Transfer-Encoding: quoted-printable
>>X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id h4CEeD112030
>>
>><DIV>IMHO, packet pair probing will not derive to real value of available=
>> bandwidth if it is not guaranteed that the two packets are scheduled spe=
>>cifically along the path.</DIV>
>><DIV> </DIV>
>><DIV>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 w=
>>ant to find is : how the queue on the slowest link could be filled. This =
>>is really different from what PP based.</DIV>
>><DIV> </DIV>
>><DIV>Jing Shen<BR><BR><B><I>Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk&=
>>gt;</I></B> wrote:</DIV>
>><BLOCKQUOTE style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1=
>>010ff 2px solid">In missive <200305031752.h43HqiE18655 at garden.whitehou=
>>se.gov>, Donald Rumsfeld typed:<BR><BR>>>I believe that Jon is e=
>>ssentially wrong. The packet-pair technique<BR>>>is definitely not =
>>one of the weapons of Mbps detection<BR><BR>I have to agree - but i must =
>>reveal a momentary prejudice against pp - i have never been<BR>sure about=
>> the gender identity of the 2 packets in question - typically, one packet=
>> is<BR>large and one small (to elicit different responses) but why? surel=
>>y this is the usual<BR>"bigger is better" type engineering macho thing - =
>>i am sure people (typical male engineers)<BR>think of that MTUs-worth, th=
>>rusting its way thru those queues, while the slight,<BR>deferential-almos=
>>t, acknowlegement sized frame wends its interesting path. of course, the<=
>>BR>alternative, use of similar type packets is in question in some states=
>>, where its probably illegal, <BR>and the ttl may therefore be exceeded s=
>>ooner than expected. then there are the occasional uses by<BR>government =
>>agencies of xmas tree (aka bush) packets, accompanied by much smaller, sh=
>>adow packets <BR>which are hard to detect (i have heard people say that t=
>>here is almost a witch hunt for<BR>these so-called blur or blaring packet=
>>s that are so dificult to pin down - i am sure caida have<BR>elegant tool=
>>s and tweezers that will do the trick tho)<BR><BR>i guess there are those=
>> occasional people (some in scandinavia, i've heard)<BR>who prefer 3-some=
>>s or more, and claim that there<BR>is more fidelity in the reproduction o=
>>f results - i await an IMW paper or two to supprt<BR>this<BR><BR>then the=
>>re's the cloning method - why try a probe when you can imitate the patien=
>>t to perfection?<BR>well, i for one am not a sheep, content merely to fol=
>>low the flock. no, i think that if 0 or 1 <BR>are good enough, then the s=
>>earch should concentrate on figuring out what the capacity of a path is,<=
>>BR>using a lone wolf approach - the idea here is that we send 1 packet ou=
>>t, bu
>>
>>t that it not<BR>only propogates, but it also removes another packet in f=
>>light - so as we extend the<BR>wolverine's ttl, it samples along hops wit=
>>h queues which either have the original, or 1 less,<BR>packet than previo=
>>usly encountered (think of this as a feynman interaction in reverse with<=
>>BR>packet and anti-packet starting at each point - kind of extreme, adver=
>>sarial queueing)<BR><BR>now the trick with this latter idea is how to imp=
>>lement it! i guess it depends on whether<BR>one can affect already queued=
>> packets by modifying the ACL on the output queue (or perhaps<BR>changing=
>> priorities if custom queueing is enabled). a laudable part of this appro=
>>ach is<BR>that it incurs less load than packet-pair....<BR><BR>of course,=
>> i could just be joking...<BR><BR>cheers<BR>jon<BR></BLOCKQUOTE><BR><BR>J=
>>ing Shen<br><br>State Key Lab of CAD&CG<br>ZheJiang University(YuQuan=
>>)<br>HangZhou, ZheJiang Province 310027<br>P.R.China<p><br><hr size=3D1><=
>>b>Do You Yahoo!?</b><br>
>><a href=3D"http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.messenger.yahoo.=
>>com/">"=CF=E0=BC=FB=B2=BB=C8=E7=C1=C4=CC=EC!=B2=BB=B3=F6=C3=C5=D2=BB=D1=F9=
>>=C3=E6=B6=D4=C3=E6=A3=A1=CD=F8=C2=E7=C9=E3=CF=F1=CD=B7=B6=D4=B6=D4=C5=C9=CB=
>>=CD=D6=D0~=B8=CF=BF=EC=D3=C3=C4=E3=B5=C4=D1=C5=BB=A2=B5=E7=D3=CA=D5=CA=BA=
>>=C5=B2=CE=D3=EB=B0=C9=A1=AD=A1=AD</a>
>>--0-275067073-1052750197=:50488--
>>
cheers
jon
More information about the end2end-interest
mailing list