[e2e] packet-pair probe implementation

[Michael Welzl]

Hi,


> > 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".
> 
> I spent a great deal of time in simulation environments working with
> packet pair and other methods of available bandwidth discovery. My 
> opinion is that packet pair can be used as a "reasonably good estimation"
> of the volume of data you can successfully transmit over a given path. 

So that's the bottleneck bandwidth ... the bottleneck capacity ...
to nominal bottleneck link bandwidth ... whatever - but not what I
meant when I said "available bandwidth". These terms are just
confused too often.


Anyway, this ...

> In order to maximise "goodput" rather than "throughput", I used packet pair
> as an estimation of the available capacity on the link. A token bucket flow
> control element was then initiated to send at the estimated rate. The flow
> from the token bucket was changed in response to variations in RTT. Therefore
> after a small number of ACKs had been returned, I was able to quickly 
> adjust the transmission rate in response to the current network status. This
> change was proportional to the change in network conditions (increase/decrease
> in RTT).
> 
> So like I say, I believe that packet pair is a good "estimator", bearing
> in mind that the information is ~1/2 RTT old by the time you receive it.
> Furthermore, as others have mentioned, it is slightly dependent on the
> queueing algorithms configured on the path. However, I'm inclined to 
> forget these as a major influencing factor from a Real World point of view.

... sounds very reasonable to me.

I also tend to believe that it's a good idea for a congestion control
mechanisms to use packet pair. I like these approaches (LDA+, PLM, ..).

Cheers,
Michael