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

[Harald Alvestrand <[e-mail]>]

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

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.

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.

Harald