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

From: "Phelan, Tom" <[email-masked]>
Date: Wed, 30 Jul 2003 08:32:18 -0400

Hi Jonathon,

I agree that the assumption of multiple codecs for a single session is an
enormous leap of faith.  Given the difficulties you talk about, it would
appear that you think end-to-end congestion control like what's described in
draft-iab-congestion-00.txt isn't practical.  Do you have any other comments
on that draft?

Tom P.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2003 1:38 AM
> To: Phelan, Tom
> Cc: [email-masked]'; [email-masked]'; Pasco Anderson, Jay
> Subject: Re: [MMUSIC] Two-way media with DCCP and TFRC
> 
> 
> 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.
> 
> Phelan, Tom wrote:
> 
> > 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
> > 
> 
> -- 
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jul 2003 11:39:43 -0400

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.

-Jonathan R.