Re: [rtcweb] Mirja Kühlewind's No Objection on draft-ietf-rtcweb-transports-15: (with COMMENT)

[Harald Alvestrand <[e-mail]>]

After listening to the (silent) list and considering the matter further,
I'm adding the following paragraph at the end of the "local
prioritization" section:

   Note that this specification doesn't dictate when disparate streams
   are to be "congestion controlled under the same congestion control
   regime".  The issue of coupling congestion controllers is explored
further in
   [I-D.ietf-rmcat-coupled-cc].

and adding that as an informational reference.


Den 30. sep. 2016 14:28, skrev Michael Welzl:
> 
>> On 30. sep. 2016, at 12.59, Harald Alvestrand <[e-mail]> wrote:
>>
>> Den 30. sep. 2016 12:31, skrev Michael Welzl:
>>>
>>>> On 30. sep. 2016, at 11.41, Harald Alvestrand <[e-mail]> wrote:
>>>>
>>>> Wanting to ask ....
>>>>
>>>> do you have commitment from some of the browser vendors that they intend
>>>> to add -coupled to their congestion control code?
>>>
>>> No committment, but I did have some hope that you guys at Google would be interested?
>>> Stefan was interested in coupling the data channel with the media channel, which is probably a straightforward way of adapting our coupling algorithm.
>>>
>>> We’re going to work on this code ourselves; we already have preliminary code on coupling + shared bottleneck detection in Chromium, but this is work in progress that was interrupted for a year due to a contract that let us focus on coupling TCP for a while (which also works very well, BTW; we’ll provide an update at ICCRG in Seoul). So we’re (well: Safiqul is) just about to get back to it.
>>>
>>>
>>>> That would go a long way towards allaying my fear that this would be
>>>> another RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" requirement.
>>>
>>> I think what I’m asking for is a far cry from a MUST.
>>> It’s merely about putting a reference there such that implementers see both possibilities (coupling and/or dscp), not only one (dscp).
>>>
>>
>> The DSCP section would be the wrong section for it anyway.
>>
>> References to -coupled should be in the "local prioritization" section
>> (4.1).
> 
> I agree. I didn’t mean for this to be in the same section.
> 
> 
>> My worry about -coupled in the previous round is that it's a *specific*
>> instance of coupled congestion controllers (and experimental-track).
>>
>> We don't yet know if it's *the* way.
> 
> Understood - but:
> 
> 1) draft-ietf-rmcat-coupled-cc doesn’t say that the algorithm in it is *the* way. I believe it correctly acknowledges that you could e.g. also have a single congestion control instance for everything ("congestion manager” style coupling). Both implementations have their pro’s and con’s - our algorithm is easier in some ways, e.g. for turning on and off (which is useful when coupling flows to multiple destinations).
> 
> 
> 2) as I said, we have lots of indications that this algorithm works for *many* controllers with only minimal changes.
> 
> Some details:
> We successfully used it with NADA and GCC ( http://heim.ifi.uio.no/michawe/research/publications/noms2016.pdf ), but also TFRC and RAP  ( http://heim.ifi.uio.no/michawe/research/publications/csws14.pdf ), LEDBAT ( slide 31: http://heim.ifi.uio.no/michawe/research/publications/caia2014.pdf ), also LEDBAT combined with another congestion control (don’t remember which, maybe RAP), and most recently TCP. TCP is perhaps an extreme case because it has so many states. If you ignore all this and just blindly apply our algorithm, you get pretty much the behavior of E-TCP, which isn’t bad ( http://www.isi.edu/div7/publication_files/effects_of_ensemble.pdf ). We have improved on it by correctly incorporating the states - this makes things better, but note that all of this is better than simply leaving flows as they are and let them compete against each other, in particular when the goal is to minimize latency.
> 
> 
> I’d find it pretty strange if this isn’t enough reason to justify a mention of this possibility and a reference.
> 
> 
>> That said, I personally wouldn't worry too much about mentioning it, but
>> it's a post-IESG change without IESG buy-in, so I'll want more
>> authorization to do that.
> 
> Sure
> 
> cheers,
> Michael
>