Subject: [MMUSIC] stream switching

From: [email-masked]
Date: Thu, 12 Jun 2003 10:22:18 +0200

Dear MMUSICers,

I have been seeking feedback about the stream switching
use cases and pending requirements described in:
http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-req-00.txt

I would like to first check a few fundamentals:

* Do we agree that constant bit rate UDP (RTP on UDP unicast)
streaming is not a good idea on networks that do not have "ample" bandwidth ?
(i.e. congestion control etc)

Assuming the answer is yes:

I remember that  frame skipping and FGS was briefly discussed in SF
as alternatives to Stream Switching, my answer was that frame skipping
was not capable of covering a wide enough bit rate range and that FGS
was not a primary target because of its lack of acceptance (at least today)
in the industry etc Also a fundamental objection to these techniques is
that they are very codec specific...

So my next question is:

* Can we say that there is a concensus that Stream Switching is a good
candidate for rate and congestion control in streaming (i.e. in the context of RFC3448) ?

regards,

Philippe Gentric
http://www.platform4.philips.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Andreas Kassler" <[email-masked]>
Date: Thu, 12 Jun 2003 11:25:06 +0200

> use cases and pending requirements described in:
http://www.ietf.org/internet-drafts/draft-gentric-mmusic-stream-switching-re
q-00.txt
> that they are very codec specific...

I think there are three main issues:
- stream switching is end-to-end and can be seen as a reaction to congestion
    --> congestion control
- additionally, there is a need to minimize the effects of packet drops in
the
case that there is congestion and it has not been detected yet (e.g. the
routers
are dropping packets but the receiver did not notice it yet). In this case
it is
important that the effects of packet drops on quality are minimized. This
could be achieved by proper application level framing and DSCP marking,
which may lead to automatic frame dropping in routers (e.g. all B-frame
packets have lower priority than I-frame packets).
- frame skipping at the sender does only lead to temporal scalability and
limits
the choices of user QoS scalability to the temporal domain. In contrast,
when
using stream switching, quality scalability or even spatial scalbility may
be achieved.
But this is up to the video provider, who has to encode the alternative
streams in a
proper way. However, the disadvantage of stream switching is the need for
more
resources at the server, as each video alternative consumes disc space. An
alternative
could be to use content delievray and adaptation overlay networks, that
adapt the
content of the video on the fly and thus scale the video to the available
bandwidth.
This could even be done TCP-friendly.

> candidate for rate and congestion control in streaming (i.e. in the
context of RFC3448) ?

I would say it is a candidate, but I doubt you can do it in a TCP friendly
way, unless you
have very fine granular bandwidth steps between the alternative streams.

Regards, Andreas Kassler