[Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00
"Bless, Roland (TM)" <roland.bless@kit.edu> Thu, 12 June 2014 13:39 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 719A21B2A1C; Thu, 12 Jun 2014 06:39:16 -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 BqieqdTW9YJ3; Thu, 12 Jun 2014 06:39:14 -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 E9A9C1B2A2C; Thu, 12 Jun 2014 06:39:13 -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 1Wv5Dh-00070y-Jp; Thu, 12 Jun 2014 15:39:09 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id CA6FEA808C0; Thu, 12 Jun 2014 15:39:11 +0200 (CEST)
Message-ID: <5399AD7F.20805@kit.edu>
Date: Thu, 12 Jun 2014 15:39:11 +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: tsvwg@ietf.org
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1402580349.
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/_Hp2TyUupTpLC55NdsSvnFflYuA
Cc: dart@ietf.org
Subject: [Dart] 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: Thu, 12 Jun 2014 13:39:16 -0000
Hi, some remarks on draft-ietf-tsvwg-rtcweb-qos-00: Sec. 2: The mitigation for such action is through an authorization mechanism. 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). Sec. 4: The below uses the concept of a media flow, however these are commonly not equivalent to a transport flow, i.e. as defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). I think one should try to use definitions that do not depend on the classifier type like 5-tuple, because as Brian already mentioned, for IPv6 a 3-tuple (IPsrc, IPdst, Flow Label) may be sufficient and header fields of the 5-tuple are not always accessible. I liked the definition of microflow in DiffServ as being an application-to-application flow of packets, usually being identified by that well known 5-tuple. For elements within the network microflows are usually the most fine grained distinction level for flows (except when you apply multi-field classifier that do some DPI and add the SSRC etc.). (nit: is probably a word like "text" missing in the first cited sentence above?) Proper definitions for media flow, RTP session, transport flow etc. may help to avoid confusion, so maybe one could try to combine efforts with draft-york-dart-dscp-rtp-00? Sec. 5: SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. 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. The above table assumes that packets marked with CS1 is treated as "less than best effort". However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the priority of the packets may be changed from what is intended. BTW, there is no "less than best effort" PHB defined, but a Lower Effort Per-Domain Behavior (PDB) in RFC 3662 (http://tools.ietf.org /html/rfc3662). This RFC is also the source for the recommendation of using the CS-1 codepoint for that purpose, so you may considering referencing it. 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?! Regards, Roland
- [Dart] Comments on draft-ietf-tsvwg-rtcweb-qos-00 Bless, Roland (TM)
- Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-r… Subha Dhesikan (sdhesika)
- Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-r… Bless, Roland (TM)
- Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-r… Gorry Fairhurst
- Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-r… Brian E Carpenter
- Re: [Dart] [tsvwg] Comments on draft-ietf-tsvwg-r… gorry