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

[marcelo bagnulo braun <[e-mail]>]

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?

Regards, marcelo



> But, this might be a very minor point.
>
>             - The second paragraph in section 4, it talks about
>         "performance
>             degradation caused by misinterpretation of the shift
>         count" I dont
>             understand what you are referring to, can you clarify?
>
>
>         When an endpoint A offers shift count 15 but a conventional
>         endpoint B regards it as 14, we could have performance
>         degradation issue.
>         Because when A says "I have X<<15 buffer", B will think "A has
>         X<<14 buffer".
>
>         But, when X=65535, we shouldn't see performance degradation
>         issue because 65535<<14 is the max window size that B can support.
>         So, if A allocates 65535<<15 + 65535<<14 buffer, A can always
>         send X=65535 because B's buffer is at most 65535<<14, it
>         cannot consume the buffer at A more than that.
>
>
>     So, there is no performance degradation issue :-)
>     I guess we agree, i guess just find it confusing when the draft
>     talks about a performance degradation issue where this is not one.
>
>
> Got it. I might think about finding less confusing texts.
> Or, with your proposed scheme, we don't need this part.
>
> Thanks,
> --
> Yoshi