Re: [rtcweb] [rmcat] 5 tuples and rmcat-cc-requirements-01

Michael Welzl <michawe@ifi.uio.no> Mon, 30 December 2013 17:00 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54041AE143; Mon, 30 Dec 2013 09:00:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level:
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.538] autolearn=ham
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 zCPdVLKZ8FxR; Mon, 30 Dec 2013 09:00:10 -0800 (PST)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8C81AE2B4; Mon, 30 Dec 2013 09:00:09 -0800 (PST)
Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1VxgCA-0003Ot-98; Mon, 30 Dec 2013 18:00:02 +0100
Received: from 089144207156.atnat0016.highway.bob.at ([89.144.207.156] helo=[192.168.1.3]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1VxgC5-0003py-TP; Mon, 30 Dec 2013 18:00:02 +0100
References: <CAA93jw7FDddn2n23fm=rdUsDyGakNfyLkJDgNjoC43fSc4GnSA@mail.gmail.com>
In-Reply-To: <CAA93jw7FDddn2n23fm=rdUsDyGakNfyLkJDgNjoC43fSc4GnSA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Message-Id: <F3C1E5A6-CB9A-4343-9CD1-F9714338A6DC@ifi.uio.no>
X-Mailer: iPhone Mail (9B206)
From: Michael Welzl <michawe@ifi.uio.no>
Date: Mon, 30 Dec 2013 17:59:52 +0100
To: Dave Taht <dave.taht@gmail.com>
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 11183 max rcpts/h 44 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: 7EF5353F7CF375735F3A40245F4F63808A8A370C
X-UiO-SPAM-Test: remote_host: 89.144.207.156 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10 max/h 3 blacklist 0 greylist 0 ratelimit 0
Cc: "rmcat@ietf.org" <rmcat@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [rmcat] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 30 Dec 2013 17:00:14 -0000

Sent from my iPhone

On 30. des. 2013, at 01:02, Dave Taht <dave.taht@gmail.com> wrote:

> I finally had a chance to read over
> 
> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-01
> 
> and also work at reproducing some of the difficulties present in the
> current implementation of chrome in light of the two papers presented
> at the last ietf on google congestion control. I went through tons of
> tests and packet captures that pretty much reproduced the legion of
> problems documented in
> 
> https://speakerdeck.com/vr000m/evaluating-googles-congestion-control-for-webrtc
> and the other paper presented at ietf...
> 
> and also fed webrtc traffic through the fq_codel and pie queue
> management systems (with pretty good results). I have tons of captures
> from each experiment if anyone wants them.
> 
> So, I have some comments on this requirements document. (I'm new to
> paying attention on rmcat, so a few of my questions are probably
> answered by some document I haven't read yet. Steers appreciated. for
> all I know I'm on the wrong mailing lists too. Sorry)
> 
> In particular, the flows I was looking at multiplexed voice and video
> on the same 5 tuple. I am curious as to the justification for this, as
> voice (without silence suppression) is isochronous and video is not.
> (is silence suppression used in webrtc?)
> 
> To me, multiplexing these two very different flows on the same ports
> is not a good idea except under extreme port pressure, and not useful
> in ipv6 or in non-natted environments at all. Even in a natted
> environment, saving a single port is a false savings as (for example)
> dns lookups punch dozens of holes through nat on a regular basis.
> 
> Requiring that in most or all cases these two flow types be on unique
> 5 tuples would give smarter queue management techniques on routers
> (like sfq, or sqf (deployed at FT), or fq_codel (deployed at
> free.fr)), a fighting chance. In particular it gives voice much higher
> probability for drop-and-delay free behavior, and analyzing the delta
> in drops and delay between a separate voice tuple and video tuple
> could provide insight as to the congestion in the system.

that's why we want to couple the congestion controllers in such cases. no need for queuing to regulate fairness, you do it in the sender!


> 
> In current implementations, is it possible to force flows onto
> different tuples? What are the other flaws in suggesting or requiring
> a different tuple?
> 
> (note I'm not suggesting bulk data traffic get unique 5 tuples per flow)
> 
> Some comments on section 3
> 
>        A.  If possible, it should also share information and adaptation
>            with other non-RTP flows between the same endpoints, such as
>            a WebRTC data channel
> 
> I might argue that looking at the traffic on the whole browser would
> be good. The browser deprioritizing background web page loads while a
> webrtc session is active would be useful in the presence of
> congestion.
> 
>        B.  The most correlated bandwidth usage would be with other
>            flows on the same 5-tuple, but there may be use in
>            coordinating measurement and control of the local link(s).
> 
> As I note above you can get more congestion information from a pair of
> flows than one.
> 
>        C.  Use of information about previous flows, especially on the
>            same 5-tuple, may be useful input to the algorithm,
>            especially to startup performance of a new flow.
> 
> A 4 tuple may also provide insight, or even two (ip to ip)
> 
>        4B.  When additional input signals such as ECN are available,
>            they should be utilized if possible.
> 
> I would not mind seeing an implementation that negotiated ECN, but it
> is out of scope on this document. Is it discussed elsewhere, or
> implemented elsewhere? Is an ipv6 version of webrtc implemented
> anywhere? I am under the impression it can be made to work in
> freeswitch...
> 
>   6.   Flows managed by this algorithm and flows competed against at a
>        bottleneck may have different DSCP markings depending on the
>        type of traffic.  A particular bottleneck or section of the
>        network path may or may not honor these markings.
> 
> And in fact, may not preserve them. It would be good to be aware
> if they are being preserved in both directions and mark appropriately,
> and also to probe if packets with particular classifications are being
> dropped
> or treated weirdly. This includes detecting for e2e ECN awareness.
> 
>        A.  In WebRTC, a division of packets into 4 classes is
>            envisioned in order of priority: faster-than-audio, audio,
>            video, best-effort, and bulk-transfer.  Typically the flows
>            managed by this algorithm would be audio or video in that
>            heirarchy, and feedback flows would be faster-than-audio.
> 
> faster-than-audio? RTCP Signalling? what?
> 
> I still have to think about RTCP signalling as it's very hard to pick
> out of the data I have, if it's even in there.
> 
>   10.  The algorithm should quickly adapt to initial network conditions
>        at the start of a flow.  This should occur both if the initial
>        bandwidth is above or below the bottleneck bandwidth.
> 
> The algorithm I looked over has particularly bad behavior on taking
> back bandwidth after it has been used up by another flow, taking many
> seconds to ramp up. I like the idea of periodically probing to ratchet
> up to a higher rate, with a slow-start-like burst (a higher resolution
> frame sent in parallel with lower rate data).  But in terms of the
> requirements, adding a
> 
>        The algorithm should quickly recover from a loss in bandwidth,
> recovering voice first, if possible.
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html