Subject: [MMUSIC] Re: [dccp] stream switching (was: Using DCCP for VoIP)

From: [email-masked]
Date: Thu, 17 Jul 2003 10:33:20 +0200

colin perkins wrote:

>Do the ideas in draft-gentric-mmusic-stream-switching-req-00.txt help any
>here?

I confirm the problems you report are the same ones the
"stream switching" proposal aims to solve, see below for details.

--> "Phelan, Tom" <[email-masked]> writes:
> Hi Sally,
>
> Thanks for the response.  See inline ...
>
> Tom P.
>
> [clipped]
> > >The DCCP documents talk about VoIP being one of the main
> > applications for
> > >DCCP.  I've been trying to figure out a reasonable way for a VoIP
> > >application to use DCCP.  Here's what I've come up with so
> > far.  Corrections
> > >and comments would be appreciated.
> > >

Apart from the fact that my original concern was for "media delivery"
i.e. an application where -contrary to VoIP- end to end delay is
not critical, the problems are exactly the same for *all*
media traffic, be it voice, video, text, etc

audio is a very good case for study since it
is so critical in terms of *gaps* in the stream.
however the case of *multiple* streams (A+V to start with)
must be considered (see end of the mail)!

[clipped]

> > >Now assume the network becomes congested and one (at least)
> > of my packets
> > >get dropped.  DCCP decides it must back off the transmission
> > rate, so one of
> > >my 'send's fails with EWOULDBLOCK.

This is clearly not very rich feedback, a blocking send is so very drastic!

I would love to see the DCCP stack give earlier feedback something in the spirit of:

"hey, be ready to change your rate because the connection state
seems to indicate that the available bandwidth is decreasing"

and then something like:

"hey, the available bandwidth has reduced to xxx kb/s, change your rate ASAP"

and in case of "emmergencies" (which definition would actually depend
on the congestion control that has been chosen) if the DCCP stack has
the impression that the available rate is extremely rapidly decreasing
it would send:

"hey reduce your rate to yyy kb/s NOW"

and for increases:

"hey, you can increase your rate up to zzz kb/s" (the codec
can take its time then, there is never any emmergency)

[clipped]

> > We would also like to understand better how DCCP would or would not
> > work for a VoIP flow that did not have an adaptive codec, but we
> > have not worked this through.  (E.g., under congestion, some fraction
> > of the packets from the codec would be dropped by the DCCP sender.)
> >
> > >If the codec family can support this change on the fly,
> > that's great.  But
> > >if it requires renegotiation, I'll need to wait for that.
> > If I renegotiate
> > >in band, then my change request packet will get queued until
> > DCCP decides it
> > >can transmit again.  If I renegotiate out of band, then that
> > channel might
> > >be having it's problems too.  At any rate, there will be a
> > round-trip delay
> > >or so before I can start sending packets again.
> >

stream switching is *exactly* about solving this: how to change
the rate by switching *codecs* (and/or codec config since a lot
of recent codec have wide ranges of parameters/profiles/rates etc)

deployed (streaming) products show that it is not only possible, it works fine.

the assumption is that the negociation takes time,
also the instanciation of the ressources -especially on thin client- also takes time
so it *must* take place "before". This before could be at session start,
but it could also be at anytime during the session, but then not on short notice,
(especially not with a blocking write!?-)

So -again- it is very important that the DCCP stack gives early feedback
so as to have time to "setup" (RTSP-wise) the required codecs.

> > If negotiation is required, this is about the codec, not about DCCP,
> > right?
>
> Right.  This was meant to indicate that the app probably can't
> immediately change its sending rate.
>

if the app "cannot change its rate" DCCP will be a very little use *anyway* no?

I think you must assume that either the codec rate can be changed (true for
most video codecs and a lot of recent audio codecs) and if the change of rate
goes beyond the flexibility of a given codec you must change the codec and/or its configuration.
[In the stream switching drafts the former is described as "transparent"
and the latter as "non transparent"]

Note that for coding efficiency reasons it is a *very bad idea*
to try to drive a video codec with rapid instantaneous changes of rate.

anyway the key issue is that DCCP *and* the codec(s) must have a way to
talk, be configured etc ... work together hand in hand

> > It's also not clear why you need to stay quiet until the codec change
> > request is acknowledged. DCCP has reduced its allowable send
> > rate, but not
> > to zero.

the codecs need to know the exact target rate, DCCP must give this as output
(the rate of that feedback could be configurable ?)

the "contract" between the codecs and the DCCP stack is very simple:
the chosen configuration MUST have a rate smaller (or equal) to the target.

> That is probably true, but I'm not sure how the other end would react to
> receiving old-codec packets while the new codec is half-negotiated.

It cannot (see above).

Another problem is the ability to distinguish between the packet containing data of one codec
or the other since for most decoder feeding the wrong type
of syntax can be very bad (can even lead to crashes etc)

This issue is addressed in the stream switching proposal:
typically with RTP the "old codec" uses one (dymamically attributed)
PT and the new one uses another one.

There was the possibility to use another "port",
but with DCCP this would be stupid no?

this leads me to the following question:

Can we assume that a given DCCP *connection* will be used
to transport each media e.g. "audio" (i.e. eventually with codec changes
on the fly, indicated by changes in PT of RTP packets)?

Then for audio+video there will be 2 DCCP connections right?

How is the DCCP feedback going to work then?

Indeed in stream swithing I always assumed that the target
is the *pair* A+V i.e. the target rate can be obtained
using SEVERAL combination, examples:

5 kb/s AMR audio + 245 kb/s video = 250 kb/s, basic audio
40 kb/s AAC audio + 210 kb/s video = 250 kb/s, better audio
80 kb/s AAC stereo + 170 kb/s video = 250 kb/s, good audio

******************

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

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

---

From: Damon Lanphear <[email-masked]>
Date: 17 Jul 2003 11:24:57 -0700

Philippe,

Can you explain the assumptions that inform your assertion that a
blocked write attempt is "drastic" for an A/V application?  I understand
how this may be the case for VoIP.  But for streaming A/V I have very
sincere doubts.

I am guessing that the difference between explicitly stating the rate to
the application and socket blocking is that DCCP is providing reaction
time to the application for whatever adaptation the app may need to do
to fulfill DCCPs transmission requirements. 

I submit that an application can achieve the same ends with socket
blocking semantics.  

I maintain that trigger points for codec adaptaion aka "stream
switching" should be based on the state of the post network buffer, not
changes in rate. A streaming A/V client application will have some
amount of post-network buffer. As we know, the purpose of this buffer is
to trade end-to-end delay for the ability to mitigate fluctuations in
delivery rate. If this buffer runs dry, then the media decoding stalls.
And the user experience is no longer seamless. The rate may vary a lot,
but the buffer may never drain to dangerous levels.  Decreases in codec
quality in such cases are completely avoidable.  

To illustrate how my notion of stream adaptation would work with DCCP:

In my model of an A/V application using DCCP, the application reads data
from the recipient DCCP end point at the rate required to fill its
post-network buffer.  If the rate is not fast enough to fill the buffer,
the buffer drains, if it fills all the way, it stops reading. In either
case, rate decrease due to congestion or rate decrease due to app slow
down, the DCCP rate will slow and the sending DCCP end point will
block.  At this point the transmitting DCCP will admit data either at
the rate permitted by congestion control or the rate permitted by the
read rate of the receiving application.  

The transmitting application has knowledge of the time line of the
media.  It therefore knows how the time line of the media shifts
relative to the delivery time line.  If the media time line is ahead of
the delivery timeline, then the buffer is filling, else the buffer is
draining.  We can even estimate the state of the buffer with this
information.  We therefore have enough information to determine trigger
points for media rate adaptations ("stream switching").  The DCCP never
has to signal the app with a rate, since the app knows the rate at which
it is sending AND it knows the rate it would need to achieve the
required timeline shift to maintain the state of the post network buffer
at a healthy level.  

The idea of a blocking socket need to be limited to just BSD sockets. 
The k/u shared buffer concept that the ICIR interns are driving can
provide the same semantics.  Either you have space to write into the
transmit queue or you don't.

I also assume that if a codec requires lead time for rate switching,
negotiation, etc., then its the wrong codec for this type of
application.  At the very least, the codec should not require setting up
a new decoder in response to a dynamic switch. Inter-key frame time for
video should be the longest time lag over which a switch should have to
take place.     

> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
-- 
Damon Lanphear <[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Jul 2003 17:54:55 +0200

Hi Damon and Philippe,

I agree with you Damon that there shouldn't be a large problem for a 
streaming server to use a blocking socket as long some time-out of 
fairly short time (100-500 ms) is available. Then a streaming server can 
maintain its relation to the expected transmission schedule. When 
falling to much behind the server can simply switch to a lower bit-rate 
version and see if that enables it to catch up with the transmission 
schedule. However to make such a mechanism to provide decent performance 
some limitations are needed, like client buffer sizes, initial buffering.

I think that as long as you have some receiver buffer to enable the 
sender side to have time to decide on what the appropriate response is 
to a blocking operation this can work. However in applications that does 
not have this behaviour, like VoIP as you mention, that only have a 
receiver buffer to remove network jitter and which desire a end-to-end 
delay below 400 ms.

However for the control model that I think Philippe is having in mind 
the blocking socket does not work very well. My understanding of the 
model Philippe is using in his proposal for stream switching control for 
RTSP is that the server will basically send according to transmission 
schedule for the current rate. Then when the client detects that the 
network buffers builds up for that rate and that media is not delivered 
fast enough the client will signal the server to drop to lower rate. The 
new rate will then allow the network buffers to drain and the client 
buffer to refill in time sense. That way the server has no need to 
maintain close control over the receiver buffers as this is monitored 
and controlled by the client.

I think that one major issue around the stream switching is what control 
models one envision to use. The second question is then how this relates 
to any congestion control mechanism in use. It seams to me that having a 
client controlled stream switching model may not work that well with the 
suggested congestion control models provided by DCCP.

Further comments to your reply.

> read rate of the receiving application.  

I don't think using app slow signalling is appropriate for a streaming 
session, I think that a bit more flow control is actually required to 
prevent wasting bandwidth on packets that get dropped on the receiver 
side due to overflowing buffers. However this can be accomplished at 
application layer for those application that needs this.

> video should be the longest time lag over which a switch should have to

Due to how media codecs work there are switching points that will result 
in optimal quality and there are other points that will result in worse 
quality. However to my understanding switching down in rate can normally 
be achieved with very little degradation due to the simple fact that we 
are switching from a fuller codec state to a less complete state. For 
upswitches in rate there is usually more need for finding the optimal 
switch point or quality will suffer severely. However there is no time 
pressure when switching up so one can wait for these points in the 
presentation.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]