[Iccrg] SSDT contributions

[Michael Scharf]

The "slowness" of slow-start is quite well-understood and has been
studied various times in the last decate (e. g., Heidemann et. al. in
1997). 

I have the impression that the slow-start delay is also one reason for
the widespread deployment of certain middleboxes (WAN optimizers), for
instance, in enterprise networks. But I am not aware of much published
work on this issue.

The potential benefit of new schemes such as quick-start or jump-start
has recently been demonstrated in a number of publications. Our own
experiments suggest that there can be a user-perceivable improvement
if the RTT is of the order of 200ms. But, of course, it also depends a
lot on the communication pattern of the application. 

So far, I've not studied in detail to which extent more aggressive
schemes increase the risk of buffer overshooting. In case of Linux
end-systems, the default packet buffers are rather large and can thus
accommodate some burstiness.

Michael

On Mon, 07 Apr 2008 at 11:56:34, Dirceu Cavendish wrote:
> I would like to solicit experimental/simulation evidence on the following topics.
> 
> - Transaction latencies taking too long to complete, in a large bandwidth delay product networks.
> - Buffer overshoot, causing multiple segment losses/retransmits, potentially causing RTOs
> - Session returning to SS and starting from scratch due to "application constrained" scenario
> 
> If you are working in any of these topics, and is willing to contribute, please come forward. Past results are good enough, to start a discussion on the threads...
> 
> We (KIT) can start with the second topic, buffer overshoot and multiple RTOs...
> I will prepare some charts with data...
> 
> Rgds to all,
> Dirceu