Odd congestion window behaviour [ was: Draft email to freebsd-net ]

[Mark Allman]

Sorry, I am way behind.

> IMO if you want to follow the true spirit of RFC3390 and RFC2581 then
> yes.. you should ONLY use RFC3390 (or 2581) to set your initial
> cwnd.
> 
> I am adding Mark Allman on this to get his opinion.. Mark, here
> is your big chance to chime in on something that has had your
> name in comments in FreeBSD code for years...
> 
> Basically let me referesh your memory in case you are not on
> net at freebsd.org (or you can go look at the thread).
> 
> Currently FreeBSD will dig into its hostcache and set the
> cwnd of a new connection to the previous value with some constraints..
> 
> James posted these a fe days ago when noting funny behavior.
> 
> I chimed in and said really IMO using the previous cwnd
> of old connections is NOT a good idea.. (I can see using
> the previous ssthresh.. but not cwnd).. and it is exactly
> why our SCTP implementation DOES NOT do this..
> 
> What do you think Mark (since your name is in the comments
> to justify this action)..

I am not sure I follow this.  The place where I know my name is (was) in
the code is about spurious RTOs, not caching CC state between
connections.

In general, I think caching CC state between connections can be useful.
But, one needs to be careful on how you do it and there is (as far as I
know), no well vetted and specified way to cache CC state.  I.e., if
some connection uses a cwnd of X bytes and then ends and another
connection comes along.... (a) Can that connection just use a cwnd of X
bytes?  (b) Does it matter how long after the first connection ends that
the second connection is initiated?  (c) If it matters, how long should
we view the cwnd of X as being valid?  (d) Should the value of X decay?
(e) Should a TCP doing this be required to pace to mitigate the
burstiness of simply starting with a big cwnd?  Etc.  So, it seems to me
that there are really lots of questions that need to be carefully
thought about and answered before one used such a scheme.  That said, I
do support the general concept and wish someone would write down some
specifics that the community could agree to.

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070831/dcd3d718/attachment.pgp