Re: [tcpPrague] [aqm] L4S status update

Hi Roland, Ingemar, Bob, Dave,

I see congestion control mainly as an inter-flow-protocol that regulates how to share the bandwidth. Up to now it was agreed to adapt the rate to 1/sqrt(p). 

Any congestion control deviating from this rule has been proven to fail. Ignoring drop will get you either pushed away, or you push away other traffic. I think most people agree with this?

Also BBR will face the same problem if it keeps on ignoring drop. I tried a few long BBR flows next to long Cubic flows on our L4S testbed and currently (depending on the RTT, rate and queue size) it either starves itself, starves Cubic, or oscillate between the 2 previous cases over 20 second intervals. I also tried only BBR flows on a PIE AQM. Same story there, either high drop (15%), no drop or oscillations, also depending on the same parameters. Try it yourself and see... I see a lot of value in the other BBR mechanisms though, but not the drop ignoring aspects.

I don't see solutions without network support when new congestion controls ignore drop and still need to support other tcp flows which are deployed now...... Up to now there are at least 2 network supported solutions:  DualQ Coupling that is an inter-protocol-translator (and therefor needs to know both protocols) and complete flow isolation like FQ which is the inter-flow-protocol inhibitor (for all flows) and takes over the end-systems role to share the BW (so not really according to the end-to-end principle).

For L4S, our main goal should be to define a new inter-flow-protocol between L4S flows (L4S drafts assumes rate adapted based on ect(1) marking probability). Ones this is decided, we can couple it to the Classic drop/mark law. The network needs to support the coupling, as it is the only one that knows the drop and the marking of both classes. It depends on the end-systems, but it is according to the end-to-end principle, because it is the least and most simple role that the network can have.

If a delay based protocol can be defined (like rate = F(queue delay)? ) then it could also be coupled to a classic drop probability with network support. But I don't think there is a proposal available. Also I don't think a delay based protocol can achieve the same low latency results as an explicit signal.

Koen.

> -----Original Message-----
> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Bless, Roland (TM)
> Sent: dinsdag 22 november 2016 17:46
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Bob Briscoe
> <ietf@bobbriscoe.net>; tsvwg IETF list <tsvwg@ietf.org>; TCP Prague List
> <tcpPrague@ietf.org>; AQM IETF list <aqm@ietf.org>; tcpm IETF list
> <tcpm@ietf.org>
> Subject: Re: [aqm] [tcpPrague] L4S status update
> 
> Hi Ingemar,
> 
> my point was that it's probably better to refrain from
> building CC-specific behavior into network elements as the
> CC algorithms may evolve faster and in more flexible ways
> than we can foresee. Thus, it would be good to have a separation
> (or coupling) scheme that actually doesn't depend on the
> 1/sqrt(p) dropping law.
> 
> Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S:
> > As regards to comments around other new congestion control algorithms
> > and that they may need adapted dropping likelihood relation between a
> > classic queue and L4S queue. I have not tried out but I suspect that
> > BBR may get an unfair treatment, at the same time it is possible that
> > other delay based CCs may suffer.
> 
> It would be interesting to see what happens if BBR is sorted into
> the L4S queue in comparison to what happens if BBR is sorted into
> the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)).
> 
> > They question however if this is a major problem?, one may as well
> > see this as an incentive to switch over to scalable congestion
> > controls and L4S ? There is after all no requirement to stick to a
> > particular congestion control no matter what. ?
> 
> Yes, and that's why I find that built-in coupling law too limiting.
> 
> > The question whether or not endpoint dependency should be built into
> > the networks is of course  a valid question but given that the state
> > of the art congestion controls like Reno and Cubic rely on a
> > 1/sqrt(p) function then that is perhaps OK ?. There will for a
> > foreseeable time come updated endpoint based congestion control
> > algorithms that are optimized  for one thing or the other (I am
> > guilty too :-). However if one can distinguish between two classes
> > (classic and L4S) where classic belong to the 1/sqrt(p) family then I
> > believe that it is possible to solve the problem. If we try find a
> > solution where classic = "all sorts of non-scalable non-L4S dependent
> > congestion controls" then I believe that we easily end up in big
> > problems.
> 
> I'm not sure. Maybe we have a class of "queue-filling" CCs and
> a class of low-delay targeted CCs.
> 
> Regards,
>  Roland
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm