Subject: Re: [Tsvwg] Follow-up : Effects of port randomization with TCP TIME-WAIT state

From: "Patrick Tate (ptate)" <[email-masked]>
Date: Mon, 20 Oct 2008 08:10:37 -0400

Hi Mark,

Good points, please see below ... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, September 08, 2008 2:00 PM
> To: Patrick Tate (ptate)
> Cc: Fernando Gont; [email-masked]
> Subject: Re: [Tsvwg] Follow-up : Effects of port 
> randomization with TCP TIME-WAIT state 
> 
> 
> I took a spin through this draft and I don't really see the 
> point, I guess.  I find it maddening.  A few comments ...
> 
>   + Basically, this draft says "ports can collide if you use the port
>     randomization stuff from the other draft".  OK, but that 
> draft says
>     as much.  And, then this draft essentially goes on to say that it
>     has been observed in the field.  The insinuation is that this is a
>     Really Big Deal.  However, the maddening part is that even though
>     there is apparently this "experience" the draft does not 
> quantify it
>     in any way.  Does this mean you're seeing 3 collisions a 
> week where
>     before you saw none?  30?  300?  3000?  What is the magnitude of
>     this "problem"?  Should I care?

Well, we ran into this issue when customers running a VXML application
upgraded from Windows 2000 server to Windows 2003 IIS.  Now 2003 IIS has
a longer TcpTimedWaitDelay setting, and thus customers started hitting
collisions with our random port generation algorithm.  Each phonecall
through a customer's router would invoke the VXML application which
would 
last a few seconds to 20 or 30 seconds and bring in several HTTP pages.
There were calls at the rate of 1-2 per second, so effectively we had
TCP connections for the VXML application coming up between a few msecs
to few hundred msecs apart.  

> 
>   + And, method 2... This is mis-labeled.  If you have to keep a
>     timestamp per tuple then it isn't a bit-array.
> 
>   + When describing method 3 you note that the cost of method 2 is
>     pretty low in terms of memory (~8KB, as you note).  But, this is
>     just wrong because (a) you fail to include the overhead of keeping
>     timestamps around and (b) it's 8KB **for each (IP,IP,service)
>     tuple**.

For some machines, global tracking of a single port space across the
few IP addresses it can handle is all that is needed and thus not too
much memory is required for methods 1 and 2.  But we should certainly
expand on this description and say these things.

> 
>   + You miss a method that might work well for most machines: just
>     keeping a list of the tuples and the time at which they were last
>     used.  In the same memory as for a bit array of the whole 
> port space
>     you could track 400+ connections (using gross math).  That seems
>     like plenty for a large class of machines.

Is this a linked list of tuples?  Might be a good alternative approach,
but also the lookup time for determining a collision after producing a
randomized port value would not be as quick as for a bit array ...

> 
>   + In comparison to methods 1 & 2, method 3 seems like the obvious
>     approach to recommend.  I wonder why you even bother sketching 1 &
>     2?  Seems like in practical terms it would need to be 3 or what I
>     sketched in the last bullet.

Well, with method 3, the timeout of a given port can be up to 4*MSL, 
where method 1 times out the port at 2*MSL, thus yielding more accurate
recycling of the ports.  One could simply track the ports globally in a
single table rather than per tuple, depending on the number of IP
addresses
and nature of the function of the machine, which leads to fairly low
memory
requirements for method 1 & 2.  

> 
> The last two bullets above are really me being academic.  I 
> think before we go down the path of recommending that hosts 
> track this sort of stuff we should understand the problem.  
> You have not demonstrated there is a problem that needs to be solved.

Your point is well taken.  Anantha and I will update the draft with
numbers quantifying the connection rate/frequency etc. and results of 
our own experimentation with this and put it out for review.

-Patrick

> allman