Re: Window Scale option

[David Borman <[e-mail]>]

Bob,

> Hmmmm.  It seems clear in retrospect that a host really wants to allow
> its applications to dynamically adjust the amount of receive buffering
> they can have, and thereby possibly adjust the window scaling.  I
> wonder if it's too late to do that, or whether it has to await a
> "second generation TCP".  I recall that Van believed that the window

I think its too late now, TCPng with a 32 bit window field
is the real answer...

> scale ought to be determined in the Syn exchange, but I don't recall
> his argument for it.

The SYN segments are the only ones that are reliably retransmitted.
The alternative was to include a window scale option in every packet,
that applied to just that packet (See section 2.1).  It was felt that
the cost of limiting the Window Scale to the SYN packets was worth
avoiding adding the Window Scale option to every packet.  Trying to
change the window scaling midflight hits two problems: 1) ACKs are
not reliably retransmitted, and 2) we don't ACK acks.  The side that
wants to change its window scaling is typically the side that is
receiving the data, and thus only generating acks...

> I expect the main problem is reliable transmission of the R value in
> ACK segments.  I can imagine something like this: Once the 3 way

Yes.

> handshake has negotiated scaling, any data/ACK packet can carry
> ScaleOption(S,R).  If I want to change my R to R', I start sending a
> receive window with the R' scaling, together with ScaleOption(S,R').
> Once the other side echos R' in its ScaleOption(R',S), I can stop
> sending the option.  This is obviously more complicated than the
> current window scaling scheme, but it would at least support what
> applications really want.

An intersting idea.  But it would be even more complicated than
that if you start talking about multiple changes to (S,R'') before
you get the ack for (R',S).  And sending (S,R') would probably be
in an ACK only packet, requiring the other side to either ACK an
ACK, or defer (S,R') until it has data to send.  I'd rather put
my effort into doing TCPng.

So, assuming that we are not going to be changing how the Window
Scale option works, do you have any problems with recommending
the ability to turn around the window scale option?  And should
it be a MAY or a SHOULD (I'll settle for MAY, but would like
it to be SHOULD)?

		-David Borman, [e-mail]