Subject: [AVT] RE: [dccp] Re: DCCP Media Guide

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Nov 2003 09:26:03 -0500

Again, I think the most acceptable response to congestion for 
video is to rate shift down once, or if necessary, twice to
get to an "acceptable" level of errors.  So, it's not freeze 
frame vs rapid rate shift, it's rate shift down vs rapid rate shift.

We have a different error result than freeze, and it seems to work
better (less objectionable), but it doesn't change the equation.
If you get too many errors, you lower the rate until you don't
get "too many".

It would be interesting to look at the voice response to changing
packetization period.  Clearly, the effect of the loss of one large
packet is worse than the effect of a small packet.  Small packets have
more bit rate, so, you would presumably be sending larger packets
when you have congestion.  What does that do to the perceived quality?
It's going to get worse as congestion gets worse, which in some sense
is "good", but is it actually worse than a higher packet loss rate,
but less problem for each loss?  Probably depends on the loss pattern.
If it were random, than the smaller problem, larger percentage is
probably better, but it's not random.

There are people who know a lot about such things.  I'm not one of them.
Do we have some of that expertise around on the list?  Has that idea
been tried?

I do think we need to split this thread, or at least mark replies with
"Applies to interactive real time" vs "applies to non-interactive real
time".
I appreciate several comments on the thread that DCCP may have more
applicability to non-interactive streams.  While many of the effects
are similar (rate shift to non-interactive is just as objectionable
to non-interactive as it is to interactive), some things are clearly
different (slow start, for example).

Brian

> -----Original Message-----
> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 8:25 AM
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [dccp] Re: DCCP Media Guide
> 
> 
> Hi Phillipe,
> 
> [snipped]
> > The other idea I have been trying to advocate for a while 
> > because I believe it is another key to the problem
> > is that media does not need to be constant bit rate, nor 
> > constant packet rate, nor constant packet size.
> 
> I'm glad you brought this up.  There have been a lot of 
> comments on this
> thread about the difficulties in the human perception of 
> rate-shifting, and,
> in general, I'd have to say the comments are pretty accurate, 
> especially
> given the current state of the art in codec design.  However, 
> I can think of
> at least two instances where rate shifting is either workable 
> or better than
> the current practice.
> 
> One case involves audio codecs such as G.711 and changing the 
> packetization
> interval.  G.711 with 10ms packetization is about 96K IP bps 
> on the wire.
> 40ms packetization gives about 72K bps.  I think that 
> changing between these
> two rates is often close to imperceptible.  A similar thing 
> can be done with
> G.729A (although I'm not sure the standard allows it), giving 
> more variation
> in the bit rate - 10ms packetization is about 38.4K bps and 
> 40ms is 14.4K.
> 
> Another case involves video transmission.  As you change 
> between a high and
> low encoding rate the image the user sees is likely to change 
> back and forth
> between clear and grainy, and this is likely to be annoying.  
> But I imagine
> it's less annoying than the current practice of freezing the 
> video (and
> continuing the audio) when there's insufficient bandwidth for 
> the high-res
> video.  I imagine that layered encoding techniques like 
> Gerard Babonneua
> mentioned can fit this mode of operation nicely.
> 
> Given that there are these low-hanging-fruit stream shifting 
> methods, I
> wonder what others are available if we put our minds to it?
> 
> Tom Phelan
> 
> > These 3 things (delay, reliability, variable rate/packaging) 
> > should give some slack
> > for the design of a solution with added value no?
> > 
> > regards,
> > 
> > 
> > Philippe Gentric
> > Chief Architect
> > Philips Software
> > [email-masked]
> > http://www.software.philips.com
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> _______________________________________________
> 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
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Nov 2003 09:53:17 -0500

> probably better, but it's not random.

We have looked at this systematically, varying the packetization 
threshold. See the papers by Wenyu Jiang and myself at 
http://netbib.info and http://www1.cs.columbia.edu/~wenyu/

> Do we have some of that expertise around on the list?  Has that idea

See above and references therein.

---

From: Stephen Casner <[email-masked]>
Date: Wed, 26 Nov 2003 09:35:51 -0800 (PST)

> If you get too many errors, you lower the rate until you don't

One quick point, relating back to the start of the thread:  If you are
competing with one or more TCP streams and the total traffic is
filling the available bottleneck bandwidth, then if you back off the
video rate as a result of the loss induced by TCP rate probing, the
TCP streams will expand to fill the bandwidth you freed and then probe
for more until you stop.

                                                        -- Steve

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 27 Nov 2003 10:25:18 -0500

On Wed, 26 Nov 2003 09:35:51 -0800 (PST)
> TCP streams will expand to fill the bandwidth you freed and then probe

Dear Stephen;

Tue in theory, but maybe not in practice. See, e.g.,
Stanislav Shalunov's work on tcp tuning.

According to 
http://www.internet2.edu/~shalunov/writing/tcp-perf.html

most TCP implementations are badly tuned for broadband 
and don't actually deliver much more than 500 kbps at best.

I notice empirically that UDP flat rate audio and video can co-exist with 
tcp in practice, and wonder if poor tcp performance might be one of the reasons why.

Maybe if the ideas in
http://www.internet2.edu/~shalunov/tcpar/
were adopted it would become much harder to send video over the Internet.

Regards
Marshall

---

From: Stephen Casner <[email-masked]>
Date: Thu, 27 Nov 2003 11:10:10 -0800 (PST)

Marshall,

> and don't actually deliver much more than 500 kbps at best.

Banking on that for a media protocol design would be unwise.

> I notice empirically that UDP flat rate audio and video can co-exist
> with tcp in practice, and wonder if poor tcp performance might be
> one of the reasons why.

Sure.  Flat-rate is the key.  If the UDP traffic does not back off in
response to TCP's probing, then TCP stays within the bandwidth that is
left.  The root of this whole discussion is that if you have ever more
flat-rate UDP traffic, it will push all the TCP out of the way until
the network is saturated with UDP traffic, then the UDP streams will
experience loss.  The TCP folks say that UDP traffic is unfair; DCCP
is being developed as a response.  Now in this conversation, we're
discussing how to keep TCP from pushing DCCP out of the way.

                                                        -- Steve