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

From: "Phelan, Tom" <[email-masked]>
Date: Mon, 28 Jul 2003 16:17:43 -0400

Hi,

Henning has pointed out a basic problem with the two-way media over DCCP
procedure - the "probe" time must be small enough to meet user expectations
of connect time, probably on the order of magnitude of one second.  Note
that this seems to me to be a fundamental problem with any congestion
control that uses slow-start, not just TFRC.  Whether this can be achieved
with TFRC depends on the details of TFRC slow-start.

As I understand it, TFRC basically starts with an initial rate, and then
doubles it every round-trip time until congestion is encountered.  RFC3448
says that the initial rate is 1 packet/second.  Now I have to admit that one
packet per round-trip time sounds more like TCP's behavior to me, but I'll
go with what the RFC says.  Note that the difference is *very* significant
for two-way voice.  I'd appreciate it if someone had some authoritative
info.

Let's assume that a voice call has a minimum acceptable codec of G.711 with
40ms packetization interval.  That translates to 25 packets/second.  The
TFRC rate will be 1 pkt/sec in the first RTT, 2 in the second, 4 in the
third and so on, reaching 32 pkt/sec in the sixth RTT.  Add two more RTTs
for the initial DCCP connection handshake, and you have 8 RTTs.  If the RTT
is 100ms (on the hairy edge of usable for voice) then you have held up the
connection progress for 800ms.  If the RTT is 20ms the ramp up time is 160ms
- hardly noticeable.

If the minimum codec has a 20ms packetization interval, that doubles the
needed rate, but only adds one round-trip time to the ramp up.

So, the questions are:  Does this analysis hold water?  If it does, are
these connection setup delays acceptable?

Tom P.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, July 28, 2003 10:32 AM
> To: Phelan, Tom
> Cc: [email-masked]'; [email-masked]'; Pasco Anderson, Jay
> Subject: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC
> 
> 
> 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
> 
> 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
> 
> 
> _______________________________________________
> 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
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 28 Jul 2003 16:23:53 -0400

Phelan, Tom wrote:
What happens if only one of these packets gets lost?