[e2e] ISN regeneration when Stateless SYN cookies are used

[gangadharan annapurna]

I sense some confusion here. Let me clarify:

(a) The server can't achieve anything by advertising a smaller window size, 
it is the client that is controlling this. So, there is really nothing the 
server can do at this point...

(b) It is possible to come up with a scenarrio which deterministically fails 
to establish the connection with the way the ISN is chosen. If I assume that 
ISN is incremented every 4 micro seconds (RFC 793 etc), then it would get 
incremented by 250K per second. So any connection which advertises a window 
size of greater or equal to 250K * RTT is 'never' going to succeed (assuming 
no packet loss, of course). I feel that this is a common occurance with 
window-scaling and should be addressed.

Thanks.




>From: Michael B Greenwald <mbgreen at dsl.cis.upenn.edu>
>To: "gangadharan annapurna" <nallu17 at hotmail.com>
>CC: john at loverso.southborough.ma.us, mbgreen at dsl.cis.upenn.edu,   
>mahesh at erg.abdn.ac.uk, end2end-interest at postel.org
>Subject: Re: [e2e] ISN regeneration when Stateless SYN cookies are used
>Date: Thu, 18 Oct 2001 15:38:43 EDT
>
>    Thu, 18 Oct 2001 23:25:06 +0530
>    "gangadharan annapurna" <nallu17 at hotmail.com>
>
>    However,
>    The problem is lets say U send a SYN which falls within the receive
>    window and the connection is RST.  Now if we do implement a stateless 
>SYN
>    cookie then what exactly must be done to avoid that RST, without
>    keeping any state.
>
>    If we can regenerate the same ISN again, then there is no problem.
>    OR if we make sure that the next ISN that is generated does not fall 
>within
>    the receive window we are OK.
>
>    How do we solve even one of these issues ?
>
>    REMEMBER No State is to be stored.  Becoz if we store a state, we can
>    regenerate the ISN.
>
>Well, we've gone from a correctness problem to a performance problem.
>(Perhaps that is a sufficient answer. :-)
>
>I don't know how serious this performance problem is.  While we cannot
>"make sure" that the next ISN does not fall within the receive window, we
>can increase the probability by sending a smaller window with the SYN
>packet.  Also, how quickly does f(t) increase?  If it holds the same value
>for a short time then delays would have to be relatively large before this
>problem rears its head.  So I'm wondering just how serious this problem is
>in practice.
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp