[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Re: [dccp] stream switching (was: Using DCCP for VoIP)
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.
On Thu, 2003-07-17 at 01:33, philippe.gentric@philips.com wrote:
> 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" <tphelan@sonusnet.com> 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)
>
> > > 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
> philippe.gentric@philips.com
> http://www.platform4.philips.com
>
>
>
> _______________________________________________
> dccp IETF mailing list: dccp@ietf.org
> list info: https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
--
Damon Lanphear <damonlan@real.com>
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic