[MMUSIC] Bundling and QoS marking (was: Question about Bundle and Legacy Interop)
worley@ariadne.com (Dale R. Worley) Thu, 14 March 2013 17:54 UTC
Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1094321F8CD0 for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 10:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgDVp-6FsVqZ for <mmusic@ietfa.amsl.com>; Thu, 14 Mar 2013 10:54:02 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A021F8976 for <mmusic@ietf.org>; Thu, 14 Mar 2013 10:54:01 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r2EHqqL9031769 for <mmusic@ietf.org>; Thu, 14 Mar 2013 13:52:54 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r2EHqqgX427252 for <mmusic@ietf.org>; Thu, 14 Mar 2013 12:52:52 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r2EHqqYZ436030; Thu, 14 Mar 2013 13:52:52 -0400 (EDT)
Date: Thu, 14 Mar 2013 13:52:52 -0400
Message-Id: <201303141752.r2EHqqYZ436030@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: mmusic@ietf.org
In-reply-to: <92B7E61ADAC1BB4F941F943788C08828047D3FC7@xmb-aln-x08.cisco.com> (eckelcu@cisco.com)
References: <E44893DD4E290745BB608EB23FDDB7623BD7B3@008-AM1MPN1-042.mgdnok.nokia.com> <92B7E61ADAC1BB4F941F943788C08828047D3FC7@xmb-aln-x08.cisco.com>
Subject: [MMUSIC] Bundling and QoS marking (was: Question about Bundle and Legacy Interop)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 17:54:04 -0000
> From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com> > > > From: Markus.Isomaki@nokia.com > > > > I've seen some drafts claiming that Bundle would be harmful in for instance > > cellular networks for QoS differentiation. Is that the motivation where the > > non-Bundled RTCWeb use comes from, or are there some other good > > reasons? > > Not just for cellular but for any scenario in which QoS is based on > using different 5-tuples for media flows for which different > treatment is desired. The question of QoS differentiation is interesting and probably one we have to address, as mobile devices have bandwidth limitations. If it's possible to mark individual packets within a transport flow for different QoS treatments, then we need to define QoS markings as an "application level" attribute rather than a "transport level" attirbute. If QoS differentiation is done entirely based on transport associations (5-tuples), then the strategy would be to have several bundles of m= lines, one for each QoS type. The naive way to do this, that is, just offering two different bundles, is suboptimal if the offerer doesn't know whether different media types need to be in different transport flows or not, because it prevents the answerer from arranging for all the media to be in one bundle (using one transport association, i.e., port) if the answerer knows that there is no QoS problem. This is a situation where using hierarchical bundling would provide a solution: If the offerer does not have a need for different transport flows for audio and video, but is concerned that the answerer might have such a need, it builds an offer containing a master bundle that contains two subordinate bundles, one containing (e.g.) the audio streams and one containing the video streams. If the answerer does not want to separate audio and video, it accepts all the bundling, and then all media are in one transport flow. If the answerer wants to separate audio and video, it rejects the top-level bundle, but accepts each subordinate bundle individually, thus arranging for two transport flows, one containing audio and one containing video. Dale
- [MMUSIC] Question about Bundle and Legacy Interop… Markus.Isomaki
- Re: [MMUSIC] Question about Bundle and Legacy Int… Charles Eckel (eckelcu)
- Re: [MMUSIC] Question about Bundle and Legacy Int… Ted Hardie
- Re: [MMUSIC] Question about Bundle and Legacy Int… Markus.Isomaki
- Re: [MMUSIC] Question about Bundle and Legacy Int… Paul Kyzivat
- Re: [MMUSIC] Question about Bundle and Legacy Int… Ted Hardie
- Re: [MMUSIC] Question about Bundle and Legacy Int… Paul Kyzivat
- Re: [MMUSIC] Question about Bundle and Legacy Int… Dale R. Worley
- [MMUSIC] Bundling and QoS marking (was: Question … Dale R. Worley