[e2e] packet-pair probe implementation

[Jon Crowcroft]

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, 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 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