[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-ietf-ipsec-new-auth-00.txt



At 04:34 PM 5/14/97 -0400, Perry E. Metzger wrote:
>
>Stephen Kent writes:
>> 	Larger window sizes are multiples of 32, so the term "arbitrary"
>> may be no more appropriate for them as it is for the base size of 32.
>> Recall that we chose 32 mostly because of the ability to do efficient
>> window management in a 32-bit machine, which is sort of arbitrary, right?
>> There is no requirement for a receiver to support anything other than 32,
>> so I'm not sure what (non-local) burden is implied if a receiver does
>> choose to support bigger windows.  However, if the Wg wants to mandate
>> support for ONLY a fixed set of window sizes, maybe 32 and 64 would
suffice.
>
>I'm curious -- how wide to TCP windows get on a high bandwidth delay
>product link?

We're talking apples and oranges here -- the "window" under discussion for
ipsec is the out-of-order packet window, which has little to do with the
size of a TCP window.  The former is intended to protect us against
routing and network-level weirdnesses; the latter is a bound on performance.

But if you're interested in the TCP window size, see RFC1323.  Briefly,
though, the effective window size variable is raised to 32 bits from 16.
Thus, you can get really good performance if you can allocate 4 gigabytes
of main memory for TCP input buffers...