[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 []) 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 []) 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"

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.