Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC

From: Aaron Falk <[email-masked]>
Date: Mon, 4 Aug 2003 10:47:57 -0700

<catching up...>

Jonathan Rosenberg wrote:
> 
> Firstly, as Brian has pointed out, rate adaptive codecs for VoIP are 
> very rare. Practically speaking, nearly all commercial VoIP phones use 
> single rate codecs. Many can support multiple codecs. However, 
> frequently, once a codec is selected, it cannot be changed easily 
> during the call. This is commonly the case for hardware phones, where 
> I believe the codecs are stored in flash and downloaded into RAM once 
> a codec is selected in the call. We have had a lot of folks ask how, 
> in SIP, to signal that the called party has to pick one of the N 
> offered codecs, and then stick to it. RFC 3264 describes means for 
> doing that.
> 
> Such a phone would not permit rate adaptivity by switching codecs as 
> you describe below. Thus, it would be all or nothing in terms of 
> sending rate.

Jonathan-

Looking down the road, do you think that rate adaption is a reasonable
thing to expect of future VoIP phones?  I.e., I'd like to understand
if the design is being influenced by technology limitations which will
reasonably go away.

> Even assuming there was rate adaptivity for voice, there are 
> perceptual issues when the encoding is frequently changed. It is 
> apparently more annoying for users to oscillate between high and low 
> rate codecs, than to stay constant with a medium rate codec. I seem to 
> recall some studies along these lines in the late 90s by Jean Bolot 
> and his students, though I cannot find the specific reference.

This seems a point less likely to go away.  Perhaps this is (one
reason) why rate adaption isn't in current phones.

So, is the right thing to do to ramp up at the beginning of the call
to the best rate you can get, then only ramp down?  This overcomes
Tom's concerns about probing bandwidth.

--aaron  

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

---

From: Sally Floyd <[email-masked]>
Date: Mon, 04 Aug 2003 12:13:26 -0700

>For VoIP, perhaps slowstart at startup is simply unnecessary.  Lets
>look at what TCP does.  Assume a 1500 byte MSS, and 200ms RTT.  Thus
>the starting rate for a TCP connection will be one packet/RTT, which
>is 1500*8/0.2 = 60Kb/s.  And this is assuming an initial window of one
>packet, which is pretty conservative these days.

Initial windows:

The current standard for TCP, RFC 3390 on Increasing TCP's Initial Window
(Proposed Standard), permits an initial window of
    min (4*MSS, max (2*MSS, 4380 bytes))
bytes. That is, at least two MSS, and up to four MSS, up to an initial
window of 4380 bytes.  TCP Initial windows of two packets are not uncommon,
and initial windows of three or four packets can occasionally be
observed.  ("http://www.icir.org/tbit/June2003/initwin.512.txt").

The question on the table seems to be whether RFC 3390 could be adapted
for low-rate VoIP flows using DCCP to allow initial windows of 4380 bytes
regardless of packet size.

It certainly seems reasonable to me.  (I am agreeing with Mark's previous
email on this.)

If the congested link is a low-bandwidth one, then the limitation is in
bytes per second rather than packets per second, and 4380 bytes
in small, spaced-out packets would be less of a load than 4380 bytes 
in 2-4 larger packets.

If the congested link is a high-bandwidth one, and the limitation is
in bytes per second, then the argument above still holds.

If the congested link is a high-bandwidth one and the limitation
is in packets per second, then it is still the case that the VoIP
flows would be pacing their packets out, which would limit the
damage they would do if 4380 bytes was too high for the allowed
sending rate.  So it strikes me as liveable, for a rate-limited,
low-bandwidth, long-lifetime app like VoIP, to resume with sending rates
up to 4380 bytes per RTT after a quiescent period.

Quiescent periods:

The question then would be whether best-effort VoIP could, after a long
quiescient period, resume sending with a sending rate of up to 4380 bytes
per RTT (assuming that it got to send at least that much before
the quiescent period).  Again, this seems plausible to me, for the
reasons that Mark described (though it would of course have to be
looked at a bit more).

And the diatribe about best-effort service:

I can't imagine a viable justification for a best-effort flow to
resume sending at a sending rate significantly higher than 4380
bytes per RTT after a long idle period.   My own assumption is that
there are certain rules that go along with best-effort traffic, and
one of them is that you don't trash competing TCP traffic.  Flows
that have strict requirements for QoS probably aren't going to get
their needs met with best-effort service with or without DCCP or
other forms of congestion control.

- Sally
http://www.icir.org/floyd/

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 4 Aug 2003 17:06:59 -0400

Two comments:

All of these calculations break if it's video rather than audio.
We need reasonable rules for video also.  The same problems
occur, although some video algorithms are not constant data rate.

Also
> reasons that Mark described (though it would of course have to be
This of course says that it's all right to do it.  I simply want
to point out to those not familiar that this can happen.  Most
audio codecs employ Voice Activity Detection.  They don't send
compressed data when no one is talking.  Incidentally, they do 
play locally sourced "comfort noise" to the receiver because it
turns out to be disconcerting to hear real silence.  Some codecs
send periodic messages indicating silence should continue (sort of
a keep-alive), but they are small, and spaced out.  There are
several circumstances (a large conference for example), where it
is normal to not have anything said in one direction for a very
long time.

---

From: Sally Floyd <[email-masked]>
Date: Mon, 04 Aug 2003 17:16:55 -0700

>There are

Yep.  For an illustration of this, you could see Section 4.1 on "Lessons
from audio traffic" from the following:

Comments on Measurement-based Admissions Control for Controlled-Load Services.
Floyd, S., Technical Report, July 1996.
URL "http://www.icir.org/floyd/papers.html".

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Mon, 04 Aug 2003 13:43:17 -0700

Jonathan -

>My take on draft-iab-congestion is that, for voip, what the draft 
>effectively implies is that you will send at your specific 
>codec-defined rate, and then when congestion hits the defined 
>percentage, stop. That is, there will be a binary choice of either 
>sending or not, as opposed to a continuum of rates.
>
>I dont think that this is a bad thing, but does mean that the 
>threshold loss rate is incredibly important. The current draft talks 
>about relatively high loss rates, ones where the voice quality is 
>probably already unacceptable. However, it is my understanding that 
>these rates are very sensitive to the assumed TCP parameters, and that 
>they could be quite a bit lower if computed differently.

Yep, but the allowed loss rates could also be quite a bit higher
with yet a different set of TCP parameters.  E.g., for a TCP connection
with reasonably fine-grained timestamps, implemented so that a
backed-off retransmit timer is reset when a retransmitted packet
makes it through and is acked.  (This would be perfectly conformant
with the standards.)  It is on my to-do list to run these simulations,
to compare with the simulations in the draft, just to illustrate
the range of possible TCP behaviors.

For all of the simulations in that draft, a useful validation would be for
someone to run experiments with a TCP connection with 100 ms round-trip
times, with dummy-net introducing random packet drops with probability p.

- Sally

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Aug 2003 10:27:08 -0400

Generally, there is no "silence".  On some algorithms, if you
remain REALLY still, the data rate drops very low, but I've never
seen zero.

Brian

> -----Original Message-----
> From: Phelan, Tom [mailto:[email-masked]]
> Sent: Tuesday, August 05, 2003 9:47 AM
> To: 'Rosen, Brian'; 'Sally Floyd'; Mark Handley
> Cc: 'Aaron Falk'; Jonathan Rosenberg; [email-masked]';
> [email-masked]'; Pasco Anderson, Jay
> Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC 
> 
> 
> Hi Brian,
> 
> Do we have the same problem that we have with voice?  That is, silence
> suppression reduces the transmit rate to zero for many RTTs.  Does
> "stillness" suppression also reduce the rate to zero?  Or is 
> there a minimum
> rate that's greater than zero?
> 
> Tom P.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Aug 2003 10:31:17 -0400

Yeah, and this is one of the most difficult scenarios to get to work.
You are not sending anything, then all of a sudden, you are sending
full rate audio and video.  In some codecs, the start of video is an
instant peak rate transfer, and if you lose some of it, it causes
retries, or really annoying visual results.  The audio start is very
important; you have to get the audio through, and you don't have
anything like a second to get it up.  The result of doing it
wrong is clipping of the initial utterance, which is really annoying
and causes people to get into really weird behavior.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, August 05, 2003 9:51 AM
> To: Phelan, Tom
> Cc: 'Rosen, Brian'; 'Sally Floyd'; Mark Handley; 'Aaron 
> Falk'; Jonathan
> Rosenberg; [email-masked]'; [email-masked]'; Pasco Anderson, Jay
> Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC
> 
> 
> In a conference, it is quite common that video-follows-audio, 
> i.e., only 
> the current (and maybe the most recent) speaker sends video. 
> Thus, the 
> problem is somewhat similar - when somebody starts speaking, 
> you want to 
> immediately have decent-quality video of that speaker.
> 
> Phelan, Tom wrote:
> 
> > Hi Brian,
> > 
> > 
> > "stillness" suppression also reduce the rate to zero?  Or 
> is there a minimum