Re: [MMUSIC] Feedback requested on requirements - DES F5

[[e-mail] (Dale R. Worley)]

> From: Christer Holmberg <[e-mail]>
> 
> >   DES F5  Bundles may contain other bundles as constituents.
> >
> >   Of course, no bundle may directly or indirectly contain itself.  (I
> >   don't expect any current implementation to implement bundles within
> >   bundles, but we should design the mechanism to allow this, as some
> >   day we will likely need it.)
> 
> I am not sure I understand this. Why would a bundle need to contain
> other bundle(s)?

When I wrote the original version of this, I thought "I don't see any
specific need for this, but I expect that uses for it will develop
over time."

Later, a question arose about a conflict between bundling and QoS
marking of transport flows.  If QoS is determined by the transport
association (5-tuple), then you may not want to bundle audio and video
together -- if you have two audio flows and two video flows, you would
bundle the audio flows together and the video flows together.  OTOH,
if QoS is not an issue, you want to bundle audio and video together.
The difficulty is that the offerer may not know which situation is
present at the answerer and so the offerer has a problem generating an
offer that expresses that either of these possibilities is acceptable
in the answer.

One solution is hierarchical bundling:  Put all the audio into one
bundle and all the video into another bundle, and then put those two
bundles into one super-bundle.  The answerer decides whether to accept
the super-bundle (and send everything on one transport 5-tuple) or to
reject the super-bundle but accept each component bundle (and thus
send audio on one 5-tuple and video on another 5-tuple).

(The signaling gets a bit more complicated but the multiplexing and
demultiplexing processes remain the same as with one-level bundling.)

The original of this discussion is:

http://www.ietf.org/mail-archive/web/mmusic/current/msg10516.html

    > From: "Charles Eckel (eckelcu)" <eckelcu at cisco.com>
    > 
    > > From: Markus.Isomaki at 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