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 > [EMAIL PROTECTED] (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
pgp4KehFJ6AV4.pgp
Description: PGP signature
