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

[dccp] feedback on draft-burness-dccp-interactive-apps-00.txt



Here are just some nits about your draft.
It is a nice document, and the conclusions seem just right to me.  

- Sally

Section 5, slow-start:
> If we assume a voice (or moderate bit rate video) application with a 
> target rate of 50 packets per second and a typical RTT of 200ms, then 
> it would take about 1 second to reach a suitable data rate. 

Actually, the initial sending rate is four packets per RTT, and the
app has a target window of 10 packets per RTT, so it would take it
half a second to reach its target rate.


About silent spells in voice calls:
> If the voice application is using TFRC in DCCP then, when the 
> application does not receive ACK packets for a time equal to the RTO 
> (retransmit timeout), it assumes the network is seriously congested.  

Actually, if the end-node hasn't been sending in that period, then
it simply assumes that it has been idle for a while, and that other
flows might now be using the bandwidth that it had been using a few
RTTs ago.  It doesn't necessarily assume that the network is
seriously congested.

After such an idle period (when the sender has been idle), the
sender halves its allowed sending rate each four RTTs.  RFC 3448
says that the allowed sending rate is never reduced to less than
two packets per RTT after an idle period.


Section 8, changes in quality

I didn't really understand Section 8.

> There seems little point in an application always probing for more 
> bandwidth if this will always lead to a loss event and a back-off 
> that leads to a lower quality for the user. 

But with CCID-3, you don't necessarily back-off after a loss event.
If you see a stable steady-state loss rate, you maintain a stable
sending rate.  That is the point of TFRC.  And if the flow and
network use ECN, the loss event could be replaced by ECN marking.


I must say that I worry about the ability of best-effort traffic
to handle the needs of video apps that require highly-variable
changes in the sending rate (e.g., factors of ten); it seems to me
that some things are better suited to the use of admissions control,
and that might be one of them.  But one never knows until all of the
work has been done...

Regards,
- Sally
http://www.icir.org/floyd/