[e2e] congestion control for flows w. small packets

[David P. Reed]

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.


- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html