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

Michael Welzl <michawe@ifi.uio.no> Tue, 04 October 2016 14:51 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC59E1298B4; Tue, 4 Oct 2016 07:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idUsX9D2d4ju; Tue, 4 Oct 2016 07:51:51 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CCE1298B3; Tue, 4 Oct 2016 07:51:51 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1brR4O-0003XR-KY; Tue, 04 Oct 2016 16:51:48 +0200
Received: from ppp-94-66-14-119.home.otenet.gr ([94.66.14.119] helo=[192.168.32.102]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1brR4N-0005qK-Gf; Tue, 04 Oct 2016 16:51:48 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: iPhone Mail (13G36)
In-Reply-To: <f5b60670-c347-4d83-a49c-ee738fd27a05@alvestrand.no>
Date: Tue, 04 Oct 2016 17:46:42 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA2AC7C0-DB00-4BFD-9C33-9ED900BCABC4@ifi.uio.no>
References: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> <AEBFDB5A-17DB-450D-8779-FDDCC2782C2D@ifi.uio.no> <d9f43cf8-652c-d03c-339a-b7295a3f2d30@alvestrand.no> <247D0AC1-B726-4C65-868F-66C920C4A55A@ifi.uio.no> <8995aea4-7016-bc93-e58c-c3a4d778c91d@alvestrand.no> <B1E206C6-DBE7-441B-B0B6-C5270A15E71E@ifi.uio.no> <f5b60670-c347-4d83-a49c-ee738fd27a05@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 46905 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 331C1767A3713643C0C06A7EDB926FA907D357FF
X-UiO-SPAM-Test: remote_host: 94.66.14.119 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/yOdPv4ONZvP3g2gJ3khqk7XRa0M>
Cc: RTCWeb IETF <rtcweb@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org
Subject: Re: [rtcweb] Mirja Kühlewind's No Objection on draft-ietf-rtcweb-transports-15: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2016 14:51:56 -0000

thanks!  i agree with this update

Sent from my iPhone

> On 4. okt. 2016, at 10.35, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 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 <harald@alvestrand.no> wrote:
>>> 
>>> Den 30. sep. 2016 12:31, skrev Michael Welzl:
>>>> 
>>>>> On 30. sep. 2016, at 11.41, Harald Alvestrand <harald@alvestrand.no> 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
>>