RE: DCCP for VoIP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ingemar,

This thread got started while I was on vacation, so I'm a little late
jumping in, but...

The basic topic here is meant to be part of
draft-ietf-dccp-tfrc-media-02.txt -- please check that out, especially
section 4.3.1, which is meant to deal with two-way interactive
applications.  It doesn't yet incorporate some of the latest
developments (CCID4 and FR), but it should be useful (there's been some
information on this thread that'll help me update it).  Any comments
would be appreciated.

Tom P.

> -----Original Message-----
> From: Ingemar Johansson S (LU/EAB)
> [mailto:ingemar.s.johansson@xxxxxxxxxxxx]
> Sent: Monday, August 20, 2007 2:38 AM
> To: Sally Floyd; Eddie Kohler
> Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp' working
group;
> Roksana Boreli
> Subject: RE:  DCCP for VoIP
> 
> Hi
> 
> One issue that may be important to know in this aspect is that there
> will probably need to be some limit to how often feedback is
transmitted
> esp. for VoIP applications with low birate.
> 
> Low bitrate VoIP typically have a bitrate of 5-12kbps (payload
bitrate)
> and in 3GPP the bearers that are specified (today) for these services
> have an RTT in the range 200-700ms depending on load and coverage
> situation. One of the worries regarding DCCP is that feedback cost too
> much and having more than one feedback per RTT will further increase
the
> system load.
> 
> One solution may be that an extra condition is added that specifies
that
> feedback should not consume more than X percent of the total
transmitted
> bitrate combined with the rule that feedback should be transmitted
> atleast once per RTT.
> Maybe a little odd formulation but hopefully the intention is
> understood. Anyway, with this rule feedback would not consume an
> unreasonable amount of BW for low bitrate VoIP applications.
> 
> Ingemar
> 
> 
> > -----Original Message-----
> > From: Sally Floyd [mailto:sallyfloyd@xxxxxxx]
> > Sent: den 20 augusti 2007 02:27
> > To: Eddie Kohler
> > Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp'
> > working group; Roksana Boreli
> > Subject: Re:  DCCP for VoIP
> >
> > > This sounds like a very interesting idea.  While the
> > documents specify
> > > that feedback is sent once per RTT, since this is what TFRC
> > > recommends, I think more frequent feedback is a fine idea even for
> > > low-loss-rate/low-RTT scenarios (twice or four times per
> > RTT, say?),
> > > and probably mandatory for high-RTT scenarios.  My guess is Sally
> > > would agree.  Perhaps someone could suggest a change to the
CCID3/4
> > > language.
> >
> > TFRC (RFC 3448) only has a smalll discussion about sending
> > multiple feedback packets per RTT.  E.g., in Section 6:
> >
> >      "If the sender is transmitting at a high rate (many
> > packets per RTT)
> >      there may be some advantages to sending periodic
> > feedback messages
> >      more than once per RTT as this allows faster response to
> > changing RTT
> >      measurements, and more resilience to feedback packet loss."
> >
> > TFRCbis (draft-ietf-dccp-rfc3448bis-02.txt) adds more
> > clarification about what needs to be done when the receiver
> > sends multiple feedback
> > packets per RTT.   From feedback from Arjuna.  In Section 6:
> >
> >      "If
> >      the receiver was sending k feedback packets per RTT, step (4)
of
> >      Section 6.2 would be modified to set the feedback timer to
expire
> >      after R_m/k seconds.  However, each feedback packet would still
> >      report the receive rate over the last RTT, not over a fraction
of
> >      an RTT."
> >
> > I think it is good to allow multiple feedback packets per RTT.
> > However, I personally wouldn't be inclined to make it the
> > default recommendation for all scenarios, for CCID 3/4, until
> > there has been a little more experience with it.  Just in
> > case there is some drawback or implementation issue that pops up...
> >
> > - Sally
> > http://www.icir.org/floyd/
> >
> >
> >




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux