Re: [rtcweb] Prioritization

Michael Welzl <michawe@ifi.uio.no> Fri, 02 May 2014 20:13 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 4FEAC1A6F68 for <rtcweb@ietfa.amsl.com>; Fri, 2 May 2014 13:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 BMQHZsddwBqY for <rtcweb@ietfa.amsl.com>; Fri, 2 May 2014 13:13:33 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69B1A0928 for <rtcweb@ietf.org>; Fri, 2 May 2014 13:13:33 -0700 (PDT)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1WgJpq-0005JF-2n; Fri, 02 May 2014 22:13:30 +0200
Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1WgJpp-0004r3-Az; Fri, 02 May 2014 22:13:30 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_D58498ED-82BE-4725-A35D-EF978254730E"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <5363D48B.7050001@alvestrand.no>
Date: Fri, 2 May 2014 22:13:27 +0200
Message-Id: <EB4AEF9C-0C55-417F-8398-C51CD57A0FF2@ifi.uio.no>
References: <20140425084726.8812.24604.idtracker@ietfa.amsl.com> <535A21E3.7070008@alvestrand.no> <535A5ACC.9070700@viagenie.ca> <535A6151.1060501@alvestrand.no> <535A68E1.9090901@viagenie.ca> <535A78FF.20700@alvestrand.no> <535A7C73.6050701@viagenie.ca> <CABkgnnWkOGdSzP42rZ-aGjFkGDOOGOfk64rq-80GjeVPZJAqaw@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A484504DFEA3@TK5EX14MBXC298.redmond.corp.microsoft.com> <F60C5C26-CFFE-45D1-BF1A-D1C320835C8A@cisco.com> <CABkgnnWcE+KaDk4OnHo0wDwK_gz_4gSr_F5FRe-X1gf41hKotQ@mail.gmail.com> <5363D48B.7050001@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1874)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 6 sum msgs/h 2 total rcpts 15926 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 99158EE82D5C02B1368D0B14861D36764D699EAC
X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 95.34.115.59 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 2 total 1427 max/h 14 blacklist 0 greylist 1 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6Clk9xF48mLjCaCs10DYfTvAjCs
Cc: rtcweb@ietf.org, safiqul Islam <safiquli@ifi.uio.no>
Subject: Re: [rtcweb] Prioritization
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: Fri, 02 May 2014 20:13:36 -0000

Hi,


>> The DSCP markings and how they might interact with this are just an
>> additional layer of uncertainty, primarily.
> Hence the note about "under a common congestion controller" - if DSCP
> markers are respected, having a common congestion controller covering
> different DSCP classes doesn't make much sense - they don't "see" the
> same network.
> 
> If they're not respected .... they could more usefully be grouped together.


This is the current version of the paragraph in draft-welzl-rmcat-coupled-cc-02 that relates to this matter (here, SBD means Shared Bottleneck Detection), and FGI = Flow Group Identifier - a number used to decide whether flows should be controlled together):

***

   SBD uses knowledge about the flows to determine which flows belong in
   the same Flow Group (FG), and assigns FGIs accordingly.  This
   knowledge can be derived from measurements, by considering
   correlations among measured delay and loss as an indication of a
   shared bottleneck, or it can be based on the simple assumption that
   packets sharing the same five-tuple (IP source and destination
   address, protocol, and transport layer port number pair) and having
   the same Differentiated Services Code Point (DSCP) in the IP header
   are typically treated in the same way along the path.  The latter
   method is the only one specified in this document: SBD MAY consider
   all flows that use the same five-tuple and DSCP to belong to the same
   FG.  This classification applies to certain tunnels, or RTP flows
   that are multiplexed over one transport (cf. [
transport-multiplex
]).
   In one way or another, such multiplexing will probably be recommended
   for use with rtcweb [
rtcweb-rtp-usage].
***

Any comments on this text?

Our plan is to write a separate complementary document that will describe a measurement-based SBD method. Both mechanisms are in the works and we'll submit them (or: are in the process of submitting them) to RMCAT.

Cheers,
Michael