[e2e] congestion control for flows w. small packets
David P. Reed
dpreed at reed.com
Wed Nov 21 08:34:28 PST 2001
At 02:13 PM 11/20/2001 -0500, stanislav shalunov wrote:
>I take issue with streaming audio as an example of an application that
>needs to send small packets. Streaming audio applications buffer
>hundreds of milliseconds (or sometimes even units of seconds) worth of
>audio. Buffering an additional serialization delay of an MTU-sized
>packet shouldn't be a problem even at rates as low as 8Kb/s (1.5s).
>But even this buffering isn't required if the sender plays a file off
>disk rather than a live show.
In fact, streaming audio (and video) *users* actually get the best
experience if the beginning of the session involves a hefty (full capacity
of the network) burst to load up the playback buffer with seconds or more
of content ahead of the play point, and then the flow can settle back to a
steady flow of large segments.
Thus TCP's "slow start" is exactly wrong for such applications.
If someone wants to think about it, FTP's that are targeted at disks
benefit from the same initial burst (to create a "full disk rotation" of data).
The point I'm making here is that latency measured at the user can be
reduced by making the traffic burstier, even when there is a natural "rate"
that describes the asymptotic behavior of the application. And this
latency has a huge benefit in the user experience, enough to pay for.
WWW Page: http://www.reed.com/dpr.html
More information about the end2end-interest