Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt

Wesley Eddy <wes@mti-systems.com> Thu, 20 December 2012 21:45 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC7E21F8A9D for <tsvwg@ietfa.amsl.com>; Thu, 20 Dec 2012 13:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WOYrNnn8JGw for <tsvwg@ietfa.amsl.com>; Thu, 20 Dec 2012 13:45:45 -0800 (PST)
Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE121F8A9A for <tsvwg@ietf.org>; Thu, 20 Dec 2012 13:45:31 -0800 (PST)
Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qBKLjU84013377 for <tsvwg@ietf.org>; Thu, 20 Dec 2012 16:45:30 -0500
Received: (qmail 16706 invoked by uid 0); 20 Dec 2012 21:45:30 -0000
Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Dec 2012 21:45:30 -0000
Message-ID: <50D386EE.7060509@mti-systems.com>
Date: Thu, 20 Dec 2012 16:45:18 -0500
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: tsvwg@ietf.org
References: <20121128002033.10683.71629.idtracker@ietfa.amsl.com> <AAD74A5C56B6A249AA8C0D3B41F86990151B3B1D@xmb-aln-x10.cisco.com>
In-Reply-To: <AAD74A5C56B6A249AA8C0D3B41F86990151B3B1D@xmb-aln-x10.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [tsvwg] FW: New Version Notification for draft-dhesikan-tsvwg-rtcweb-qos-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2012 21:45:46 -0000

On 11/27/2012 7:27 PM, Subha Dhesikan (sdhesika) wrote:
> This document was originally submitted in RTCWeb WG and was adopted as a WG document.  The transport AD requested that this be moved to TSVWG. Therefore, this document is now submitted as an individual submission to TSVWG. 


To provide some context ... during the Atlanta IETF, it
became clear that having this document in RTCWEB (where
it was a WG draft) was confusing on at least 2 counts:

(1) TSVWG is the place in the IETF where we should be
    making any recommendations about use of DiffServ;
    it would get crazy if every WG had its own set of
    guidance about this.

(2) It seemed to be advocating using multiple 6-tuples
    (address pairs, port pairs, protocol, and DSCP) that
    differ only in their DSCP, for distinguishing the
    QoS desires of individual packets within an RTCWEB
    flow that's muxing potentially lots of different
    things (voice, video, bulk, and interactive data)
    with different QoS desires.

    This was potentially not going to interact well
    with things we have been talking about in RMCAT,
    like allocating congestion responses between
    elastic and inelastic sub-flows.  If those sub-
    flows are on separate 6-tuples, this may not
    make any sense, as they'd be seeing different
    queues within the network.

So, in summary, TSVWG is the right place to talk about
this draft, though I'm not sure it's technically a very
good idea, myself, given other work being done in the
IETF currently.

-- 
Wes Eddy
MTI Systems