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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 19 Jun 2013 09:46:37 +0200

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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 19 Jun 2013 09:46:53 +0200

On 05/10/2013 10:16 AM, Riccardo Petrocco wrote:
> Dear Wesley and All,
>
>     Maybe someone can comment on whether alternatives like TFRC
>     were investigated or not?  TFRC is Standards Track, and intended
>     for providing a smoother rate like we talked about in the
>     past (LEDBAT may not be good for relatively rate-inelastic
>     flows), but I don't know if the feedback it requires would be
>     compatible with what the PPSPP framing provides or not.
>
>
> We are currently looking into alternatives to LEDBAT for the PPSPP.
> The majority of CCs will require some small modifications to the content
> of the DATA and ACK messages as defined in the draft.
>
>     I also would not think it wise to change to something else
>     that doesn't match the implemented and deployed base, unless
>     the people implementing and deploying agree that something
>     else is clearly better and will be implemented and deployed
>     by them.
>
>
> We will also run some large experiments in a controlled environment to
> evaluate the effect and feasibility of the different solutions.

Good to hear but my question is in what time the WG could expect to see 
results?

This isn't about building up pressure, but more about when the peer 
protocol should be going for publication as RFC.

   Martin