[Tmrg] Round-table PFLDnet submission - transient

[Lachlan Andrew]

Greetings Romaric,

On 10/12/2007, Romaric Guillier <romaric.guillier at ens-lyon.fr> wrote:
> > However, the max decrease in one RTT isn't very informative.  Should
> > it be big or small?  A flow which randomly sends 0 on odd RTTs and
> > 10Gbps on even RTTs will have a very big "maximum decrease", but
> > doesn't behave at all well.
>
> Yep, I agree with you on that, but if you consider the "time to reduce
> to 33%" metric, you will get a result like one or less than one RTT, but
> it won't tell you either that your protocol is unstable.

True.  I argued against the "time to reduce to x%" metric at the
meeting, but haven't come up with anything better.  The reason for
making it 33% not 50% as originally proposed was an attempt to look
beyond the first "reduction by 50%" that many algorithms have.

To me, the "back-off" measure is about how much room is available for
the newly-arriving flow, rather than the impact on the existing flow.
That is one reason I don't like the "cost" in the original draft -- it
only considers the impact on the long-lived flow, not the impact of
that flow's response on other flows.  Perhaps it would be better to
measure the impact on other flows directly.  How about the measure

    number of packets dropped by the UDP sources in the first x seconds

If the flow backs off nicely, the number of dropped packets will be
small.  Similarly, virtual queue algorithms will be rewarded for not
causing *any* drops when a small UDP flow starts.

> If we want to measure the stability of a protocol when it is facing transient events,

No, I wasn't specifically wanting to measure stability.  I just think
that the sustained back-off is more important than the peak backoff.
Maximum is a very fragile statistic.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan