Re: [tcpm] Fwd: comment about draft-nishida-tcpm-maxwin-02

[Yoshifumi Nishida <[e-mail]>]

Hi Marcelo,

On Fri, Jan 20, 2017 at 12:28 PM, marcelo bagnulo braun <[e-mail]>
wrote:

> below...
>
> El 20/01/17 a las 20:32, Yoshifumi Nishida escribió:
>
>
>>     What about this:
>>     The shift count is expressed in a byte, but only the values
>>     between 1 and 14 are acceptable as per RFC 7323.
>>     With this draft, the 15 shift count value would become acceptable,
>>     but it seems we will never need more than 16 values in the shift
>>     count (unless we increase the TCP seq number).
>>     So, this means that we have 4 bits to play with in the shift count
>>     field.
>>     One way of using it would be the following:
>>     We divide the shift count filed in two fields of 4 bits. The first
>>     4 bits are used to express the shift count for legacy (RFC7323)
>>     endpoints.
>>     The last 4 bits are used to express the shift count for endpoints
>>     that support this specification.
>>
>>     So, this would result in the following combinations:
>>     - updated client talks to updated server: it expresses its own
>>     shift count using the last 4 bits, the server replies expressing
>>     its own shift count in the last 4 bits. Both endpoints understand
>>     that they are talking to updated endpoints, so they use the new
>>     values.
>>     - updated client talks to legacy server. It expresses its own
>>     shift count using the last bits. The legacy server receives the
>>     option, checks that the value is larger than 14 and then uses 14
>>     as shift count for this client. The server replies with its own
>>     shift count encoded in the first 4 bits. The client understands
>>     that the server is legacy and uses a 14 shift count for its own
>>     shift count.
>>     - legacy client talking to legacy or updated server, behaves as
>>     described in RFC7323
>>
>>     If we do this, then when both endpoints are updated, one of the
>>     endpoints can use a smaller shift count even if the other endpoint
>>     uses a 15 shift count. This doesnt help in the situation where the
>>     server is legacy, but at least in the long run if this extension
>>     is widely deployed, the behaviour is the desired one.
>>
>>     what do you think?
>>
>>
>> I've thought about it and I think it's a pretty good idea. It's more
>> explicit than the current scheme, but doesn't consume extra option space.
>> In this scheme, when an updated endpoint talks to a non-updated endpoint,
>> the shift count will automatically 14. But, I guess this cannot be solved
>> without adding extra negotiation scheme. So, I think it's acceptable.
>> One question I have is if we need to use 4bits for this. It might be ok
>> to use just one bit in the last 4 bits to indicate it supports new version.
>>
>
> agree.
> So, the shift count field in the WSO could then look like this:
>
> +----------+
> |SSSS|L|RRR|
> +----------+
>
> With SSSS being 4 bits used to express the shift count, L, being the bit
> to express the Large window support and RRR 3 reserved bits.
>
> Makes sense?
>

Yes, make sense to me. Thanks!
--
Yoshi