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@dsl.cis.upenn.edu> >To: "gangadharan annapurna" <nallu17@hotmail.com> >CC: john@loverso.southborough.ma.us, mbgreen@dsl.cis.upenn.edu, >mahesh@erg.abdn.ac.uk, end2end-interest@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@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 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
