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

From: "Phelan, Tom" <[email-masked]>
Date: Mon, 28 Jul 2003 10:20:31 -0400

Hi,

I've come up with the following scheme for using DCCP/TFRC with two-way
interactive media.  As a reminder, two-way media differs from one-way live
in being very intolerant of delay.  One-way live differs from one-way
pre-recorded in having a maximum transmit rate equal to the encoding rate
(rather than the disk read rate).

The procedure here is a significant departure from current practice.  I
haven't been able to fully digest the system implications of this scheme
yet, but some of them, especially with regard to congestion and call
admission control seem pretty exciting.

Assume that each end of the connection is capable of using a number of
codecs with increasing bandwidth needs, where each step up is less than
twice the rate of the previous step, and that the sender can switch between
them at "low cost" (perhaps a big assumption).  Assume also that DCCP
provides immediate feedback to the application when it changes the computed
sending rate.

To start, the calling part sends an INVITE (loosely using SIP terminology)
indicating the IP address and DCCP port to use for media at its end.
Without informing the called user, the called system responds to the INVITE
by connecting to the media port.  Both end systems then begin exchanging
test data, at the (slowly increasing) rate allowed by TFRC.  The purpose of
this test data is to see what rate the connection can be ramped up to.  If
that rate is less than a minimum acceptable rate, the call is cleared
(conceptually, the calling user hears "fast busy" and the called user is
never informed of the incoming call).  Note that once the rate has ramped up
sufficiently for the highest rate codec there's no need to go further.

If an acceptable rate can be achieved, the called user is informed of the
incoming call.  The test data is continued during this period.  Once the
called user accepts the call, the test data is replaced by real data at the
same rate.

If congestion is encountered during the call, TFRC will reduce its allowed
sending rate.  When that rate falls below the codec currently is use, the
sender switches to a lower rate codec.  If the rate continues to fall the
sender will eventually get to its lowest rate codec.  If the TFRC rate
continues to fall past the lowest rate codec, the sender must discard
packets to conform to that rate.

If the network capacity is sufficient to support one of the lower rate
codecs, eventually the congestion will clear and TFRC will slowly increase
the allowed transmit rate.  Since the application will continue to transmit
at its codec rate, TFRC will limit this increase to at most twice the
current sending rate (my interpretation of the TFRC paper here, I could be
wrong :-)).  This is the reason that the sender must use a codec suite with
rates in steps of less that two times the previous rate.  If the TFRC rate
increases sufficiently for the next codec step, the sender may switch to the
higher rate step.  If the network can't support the new rate, eventually
congestion will reappear and the sender will fall back to the lower rate.
Over time the sender will oscillate between the lower and higher rate with a
period equal to the time it takes TFRC to probe between the two rates.

This procedure doesn't work when silence suppression is in use.  I need to
think about that some more.

Tom P.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Jul 2003 10:32:24 -0400

Like all measurement-based admissions control mechanism (and dozens have 
been proposed...), this one may well introduce unacceptable call setup 
delays. Once the other side has accepted a call, the last thing you want 
is "dead air", even for a few milliseconds (since the 'Hello' will get 
lost, which messes up the human two-way handshake pretty badly).

You have a bit more room prior to ringing, but acceptable post-dial 
delay is probably no more than a second or two for landline phones. If 
you consider that the call may well be an emergency call, you really 
don't want to go probing the network for a few seconds before you 
connect to the PSAP...

I'm not arguing against measurement-based admission control, but 
existing published experience has not been very encouraging, from what I 
can tell.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Jul 2003 01:37:56 -0400

This kind of scheme might work for video. I have seen interactive 
video applications which tell the user that the video is being 
prepared, after call setup. It is OK if that takes a few seconds to 
do. However, VoIP is quite different, and there are some further 
issues there.

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.

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.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com