[Iccrg] SSDT Scope - summary

[Michael Welzl]

> 1. I agree that resuming after "application constrained" is a more
> clear-cut case for more rapid increase.  If we can improve that case,

Me too.


> 2. It isn't clear to me that the possibility of path changes is a
> sufficient reason not to use better slow-start after timeout.

That was just an example - my point is that, generally, we
should assume to know nothing after an RTO


> 2a) We still start from a low rate and build up, stopping if we get a loss

as with original slow start   :)


> 2b) Most route changes will be between "similar" links -- like
> rerouting within a backbone.  We'd only have problems if, for example,
> we were forced off a GbE link onto an ADSL backup link

too much guesswork IMO


> 2c) Even if we do overshoot significantly, we'll get a stack of losses
> and time out again, but this time with a reduced  ssthresh.

as with original slow start


conclusion: while I'm generally in favor of making slow start
a bit faster in its initial phase, your points above don't
convince me that this would better be done when an RTO occurs
during a connection.


> There may be a smarter way to make use of the fact that we have *some*
> information about probability distribution of the BDP.

yup - if we do, as it might be reasonable to assume in
the app-limited case

cheers
michael