Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00

"Bless, Roland (TM)" <> Tue, 24 June 2014 08:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 228D71B299A; Tue, 24 Jun 2014 01:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aWUgQ4kxtbUE; Tue, 24 Jun 2014 01:30:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88B651B299F; Tue, 24 Jun 2014 01:30:26 -0700 (PDT)
Received: from ([] by with esmtp port 25 iface id 1WzM7R-0002lx-GS; Tue, 24 Jun 2014 10:30:21 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by (Postfix) with ESMTPS id B0523A804D5; Tue, 24 Jun 2014 10:30:24 +0200 (CEST)
Message-ID: <>
Date: Tue, 24 Jun 2014 10:30:24 +0200
From: "Bless, Roland (TM)" <>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Subha Dhesikan (sdhesika)" <>, "" <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-Timestamp: 1403598621.
Cc: "" <>
Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jun 2014 08:30:30 -0000

Hi Subha,

thanks for you reply, see comments inline:

> An authorization mechanism alone is probably not sufficient, because 
> DS boundary nodes may need to police (e.g., remark/drop) incoming 
> traffic according to some agreed/negotiated traffic profile for some 
> of the PHBs, e.g., the EF PHB does not work properly if its traffic 
> class is overloaded (see below).
> SD: Agreed. The previous line states: " Therefore, the DSCP value
> may be remarked at the network edge through policy to any other DSCP 
> value, including best effort.".   There is already a mention that 
> apckers may be remarked or dropped and any additional mitigation is 
> outside the scope of this draft.

Unfortunately, this doesn't address my comment. DSCP remarking by
provider policy is somewhat different from having policers installed
(e.g., a token bucket w/ marker and dropper) that perform traffic
conditioning according to some installed traffic profile. Static
remarking of DSCPs may be caused by using a different DCSP/PHB mapping
or lack of DiffServ support etc. which is slightly different.

> The problem with using EF is that if too many EF marked packets are
> injected into a DS domain, they probably void the EF properties for
> other users within this domain (background is that the service rate of
> EF packets on a given output interface must exceed their arrival rate at
> that interface over long and short time intervals - this is usually
> checked by admission control before use and policing at DS boundary
> nodes during use). Therefore, maybe some discussion w.r.t. RFC5865
> may be useful.

> SD: Agreed that admission control is very useful and relevant. This
> draft is intended for the selection and use of the right DSCP for
> webrtc media flows. There is a mention of over-subscription in the
> beginning.

Sure, however, my point was that simply injecting traffic marked with a
DSCP for a PHB that normally requires prior admission control is
somewhat problematic: either guarantees for already admitted flows
are violated or such traffic has to be dropped.

> If a packet enters a QoS domain that has no support for the above 
> defined Data Types/Application (service) classes, then the network 
> node at the edge will remark the DSCP value based on policies.
> Yes, but even if there is support for these classes traffic
> conditioning (e.g., remarking/dropping etc.) may be necessary and
> applied. Remarking to different PHBs may also lead to packet
> reordering within a media flow?! 

>SD: Remarking/dropping may occur, which is mentioned in the draft.

Same issue as above: remarking caused by a static DS domain policy
(PHBx -> PHBy) is different from remarking and other actions that
boundary nodes may perform for individual flows according to
traffic profiles.