RE: [dccp] Would a DCCP flow need to send 2x its preferred rate?

["Phelan, Tom" <tphelan@sonusnet.com>]

Hi Qiaobing,

It appears that it isn't necessary to send extra data to get the
"protection" I was seeking.  I was erroneously assuming that when TFRC
reduced the send rate, it reduced from what you were actually sending, not
from what you were allowed to send.  Given this I think that the
recommendation in my draft was unnecessary, and I'll be modifying it.

If DCCP can do it why can't TCP?  In the particular case I was talking
about, the DCCP app was sending less than it was "allowed" to.  It seemed
reasonable to put some (but not necessarily all) of that excess allowance to
good use.  Most TCP apps always send at the maximum allowed rate, so padding
wouldn't be possible.  If a TCP app was satisfied with less than the allowed
rate, I suppose it could "pad" to preserve that rate.  But it's difficult to
imagine such a restrained app using TCP with its abrupt rate variations and
in-order delivery.  It seems to me that these types of apps are better
served by DCCP/TFRC (or they just ignore congestion issues and use UDP).

Tom Phelan


> -----Original Message-----
> From: Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com]
> Sent: Wednesday, December 03, 2003 12:39 PM
> To: Eddie Kohler
> Cc: avt@ietf.org; dccp@ietf.org
> Subject: Re: [dccp] Would a DCCP flow need to send 2x its preferred
> rate?
> 
> 
> Eddie Kohler wrote:
> 
> > > But, if people suddenly realize that turning off their 
> encoder silence
> > > detection immediately gives them better voice quality and 
> start to do so in a
> > > large scale, what good it would do to the network? Would 
> IAB have the power to
> > > tell people not to do so?
> >
> > TCP-friendliness without silence suppression is probably 
> better for the
> > best-effort Internet than non-TCP-friendliness with silence 
> suppression.
> >
> 
> Eddie,
> 
> I wish I could be as optimistic as you. I wonder if anyone on 
> the list has some
> numbers that can show what percentage of additional media 
> data will be injected into
> the network if codecs would stop doing silence detection 
> (motion detection for
> video).
> 
> Fundamentally, I am concerned that this DCCP 
> "app-who-sends-more-will-get-rewarded"
> feature will be taken advantage of in the wrong way (the 
> draft that starts this
> discussion is the first attempt for this, but it won't be the last).
> 
> If this behavior of "sending filler data when no real data to 
> send" becomes a
> recommended practice for media-over-DCCP (as you and Tom seem 
> to suggest), what
> would stop the same recommendation be made for app over TCP? 
> For an app over a long
> lived TCP connection, the sender can also benefit from 
> sending "filler data" to keep
> the pipe from collapsing, so as to avoid the penalty of going 
> through another slow
> start when it has real data to send next time. But I think 
> this is hardly something
> that should be recommended for TCP based apps. Why should it 
> be more acceptable for
> DCCP then?
> 
> regards,
> -Qiaobing
> 
> 
> >
> > Eddie
> 
> 
> _______________________________________________
> dccp IETF mailing list: dccp@ietf.org
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
> 

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html