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

[Yoshifumi Nishida <[e-mail]>]

Hi Marcelo,

Thanks for reading the draft! Sorry, I forgot to CC to tcpm..So, I resent
it.

On Wed, Jan 18, 2017 at 11:30 PM, marcelo bagnulo braun <[e-mail]>
wrote:

> Hi,
>
> Thanks for writing this draft, seems useful to me.
>
> A couple of minor comments:
>
> - I understand that this extension MUST be used with PAWS, correct? I
> mean, using a larger RCVWND without PAWS is likely to result in inability
> to distinguish old duplicate packets from new ones, correct? Should this
> requirement of this being used in conjunction with PAWS be explicitly
> stated?
>

That's right. We presume the use of PAWS here. We can add some texts.

>
> - If an endpoint that does support this extension communicates with
> endpoints that do not support this extension, it will result in the
> endpoint that does support the extension to be allocating the double buffer
> size for every connection with a legacy endpoint that it should. I agree
> that is not fatal, but wouldnt this be a problem in terms of resources?
> Would this excess of demand in resource usage would make adoption of this
> extension not very attractive? Maybe it would be better to use the 15 shift
> count when the other endpoint also replies with a 15 shift count or
> something like this?
>

Yes, we have thought about it before. One potential issue of the approach
is it will require other endpoint to use 15 shift count, although it might
want to use smaller shift count. WS option exchange is one way
notification. So, I just didn't want to use it as a negotiation mechanism
to activate the feature.
On the other hand, we presumed not so many TCP connections want to use this
feature, such as at most 10 connections at one time.
Also, adding a certain negotiation mechanism to activate the feature could
be another way.  (01 version has described the mechanism, which is deleted
in 02 version) We've compared these points and have chosen the current
mechanism.


> - 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.

Thanks,
--
Yoshi