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

"Bless, Roland (TM)" <roland.bless@kit.edu> Tue, 24 June 2014 08:30 UTC

Return-Path: <roland.bless@kit.edu>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228D71B299A; Tue, 24 Jun 2014 01:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWUgQ4kxtbUE; Tue, 24 Jun 2014 01:30:27 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 88B651B299F; Tue, 24 Jun 2014 01:30:26 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1WzM7R-0002lx-GS; Tue, 24 Jun 2014 10:30:21 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id B0523A804D5; Tue, 24 Jun 2014 10:30:24 +0200 (CEST)
Message-ID: <53A93720.6040604@kit.edu>
Date: Tue, 24 Jun 2014 10:30:24 +0200
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
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)" <sdhesika@cisco.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <5399AD7F.20805@kit.edu> <AAD74A5C56B6A249AA8C0D3B41F8699037C38F8A@xmb-aln-x10.cisco.com>
In-Reply-To: <AAD74A5C56B6A249AA8C0D3B41F8699037C38F8A@xmb-aln-x10.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1403598621.
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/2GNzacrZFPb53putQ1KzGvtjkic
Cc: "dart@ietf.org" <dart@ietf.org>
Subject: Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-rtcweb-qos-00
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=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
> http://tools.ietf.org/html/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.

Regards,
 Roland