Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06

[Martin Stiemerling <[e-mail]>]

On 05/10/2013 03:28 AM, Wesley Eddy wrote:
> On 4/30/2013 5:18 AM, Martin Stiemerling wrote:
>> 2) LEDBAT as congestion control vs. PPSPP
>> The PPSP peer protocol is intended for the Standards Track and relies in
>> a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an
>> **experimental** delay-based congestion control algorithm.
>> A Standards Track protocol cannot normatively rely on an Experimental
>> congestion control mechanism (or RFC in general).
>> There are ways out of this situation:
>> i) Do not use ledbat: this would call for another congestion control
>> mechanism to be described in the PPSPP draft.
>> ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track:
>> Possible, but a very long way.
>> iii) Agree on having PPSPP also as Experimental protocol.
>>
>> I'm currently leaning towards option iii), but this is my pure personal
>> opinion as an individual in the IETF.
>
>
> Another option would be to mark it as a DOWNREF during the
> IETF Last Call, right?  That assumes the WG can make the
> case for why this is okay as a DOWNREF (e.g. wide deployment
> experience, and lack of cataclysms).

This would be one way of dealing with it in a procedural way, but I am 
not sure if this will solve the issue that we get a lot of push back on 
using an experimental CC mechanism in a standards track protocol without 
any real proof that LEDBAT is working on a large scale.

I am in support for LEDBAT but I can see a number of valid questions 
down the road in any further review.

One way out would be to have measurements and deployment results that 
show LEDBAT in action.

   Martin