I agree that CN is not a general solution for all apps and alkl scenarios.
I guess it would be good to understand where this helps, where this
could hinder.
Gorry
Magnus Westerlund wrote:
Hi Gorry,
You are right that this may mitigate the issue if you have CN traffic.
But I don't think that will happen for an VoIP application if the RTT is
100 ms. That represents commonly 5 frames. At that rate the rate of
change of the transmission rate may be to slow to easily maintain a
reasonable end to end delay.
There are clearly other use cases where you don't have CN. Thus I don't
think CN is the answer to all users of DCCP.
More comments inline.
Gorry Fairhurst wrote:
Although I agree that CN packets are a function of the media codec,
they *COULD* offer a mitigation to the effects of longer delay paths.
When the Path RTT is short (e.g. less than a tenth of a second), then
the "TFRC" algorithm already grows a window in a short time (e.g.
still much less than a second). Therefore the fact that CN packets are
sent > PRRT, isn't really an issue, the window will grow quickly
anyway, we may not need faster-restart...
When the PRTT is many tenths of a second or more, it can take many
PRTT to build a suitabel rate (i.e. long time), and the user would
notice. That's why we have faster-retransmit proposed. However, in the
case of a long path delay, a media codec that sends CN, will also
effectively "ping" the receiver, just as needed...
However, several things puzzle me, and I'd be interested in thoughts:
* Should DCCP/TFRC understand that CN corresponds to a "silent"
period, rather than a drop in the media rate?
Isn't this trying to put a little to much intelligence into the
transport layer about the traffic? Then we would need to have load rules
for the "ping" traffic, etc. I think you clearly raises a valid concern
here. The possibility to distinguish between normal drop in media rate
and the CN period. To me it seems that one should actually have a faster
restart rate calculated and being aged for all application induced rate
reduction. So that the application may utilize the gain fast restart
provides compared to the currently allowed rate based on actually
transmitted traffic.
* If CN is treated differently, what rules govern what counts as
"ping" and what counts as "data"?
clearly an issue.
* Should DCCP/TFRC set a maximum rate for these pings -- in the case
of a 1ms RTT, one packet every 4 RTTs is quite a lot!
Due to the purpose of the ping packets I don't think that you can change
that for very short paths. The will change quicker and the congestion
control state will also become invalid quicker. Are you worried about
short and very thin pipes?
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
