Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Anantha Ramaiah (ananth) wrote:
>  
> 
>> -----Original Message-----
>> From: Fernando Gont 
>> [mailto:[e-mail]] On Behalf Of 
>> Fernando Gont
>> Sent: Monday, May 25, 2009 8:19 AM
>> To: Anantha Ramaiah (ananth)
>> Cc: Joe Touch; [e-mail]; James Polk (jmpolk); tsvwg
>> Subject: Re: [Tsvwg] WGLC for Port Randomization starts now 
>> (April 1st)
>>
>> Anantha Ramaiah (ananth) wrote:
>>
>>> Hmm.. I missed this one.. The draft which we had put out 
>> more than an 
>>> year ago DOES talk about keeping state at the peer to minimize 
>>> collisions. It lists a few algorithms to that effect as well.
>> They probably mean that additional work is required only on 
>> the side that performed the passive close. (i.e., half of the 
>> work is already done).
> 
> Any RFC compliant TCP implementation will honor TIME-WAIT requirement
> and that involves keeping state at the side which initiated the
> connection close.

It's worth noting that many implementations aren't RFC compliant in this
regard, though.

> It is also well known that the side-effect of
> TIME-WAIT requirement leads for the 4-tuple (socket-pairs) to be locked
> for some time. 

That is not a "side effect", that is the *desired* effect.

> It needs to be pointed out at that, other transport
> protocols like SCTP doesn't have the TIME-WAIT requirement since the
> protocol supports in-built mechanisms to deal with the need for the
> same. 

SCTP has a TIME WAIT state for its connection IDs (socket pair and
vtags), just as TCP has for its (socket pair). The difference is that
SCTP has a larger connection ID space, that's *all*.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkob9W0ACgkQE5f5cImnZrseiQCfZEJ3sWltiyvMmSnTkwyyWooy
J5IAoMhmJQBfK5rsxmJeOnUXgsXpGOR8
=OWYf
-----END PGP SIGNATURE-----