[Tmrg] Round-table PFLDnet submission - transient

[Romaric Guillier]

hi

Lachlan Andrew wrote:
> 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.

and hope that we won't see new algorithms that will propose a reduction 
to 33% :)

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

Sorry, distortion of the reality due to the usual topic I'm studying. Of 
course, you are right, we shouldn't be favouring one part or the other 
of the problem. But as a transient event could be caused by anything 
like a routing change causing a sharp decrease of the available 
bandwidth, sudden congestion or signal power dropping for wireless 
connexions, I thought it was more interesting to focus on this one flow 
rather than on the load we generate to simulate the transient event.

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

That sounds nice. If the number is too big, the flow is too aggressive 
and might be dangerous. If the number is too small, well you probably 
won't get good performance but at least the protocol won't break the 
internet

cheers
Romaric