Subject: Re: [tcpm] Fwd: New Version Notification for draft-harris-estab-wscale-00.txt

From: Jeremy Harris <[email-masked]>
Date: Wed, 21 Dec 2016 16:08:22 +0000

On 01/11/16 15:55, Jeremy Harris wrote:
> I have submitted a draft extending the use of the TCP Wscale option.

[Apologies for the threading break; I didn't receive Yoshifumi's
mail directly]

Yoshifumi Nishida <[email-masked]> wrote:

> 1: This might be beneficial for middle points that want to do some
> network analysis. However, I don't see benefits for sender and
> receiver. So, unless there are strong relationships between network
> analysis app and sender/receiver, sender/receiver won't have good
> motivation to implement and activate this feature. However, such
> relationship might not always exist.

Indeed.  The intent is to make it low-enough cost that it will be
at least commonly available, preferably commonly enabled as a default.

> 2: For the same reason, it seems to be difficult for senders to decide
> whether activate this feature or not.

If it is not enabled by default on a system, it should be possible for
operators to enable it when needed for a packet-capture debug step.

I'll add some words pointing this out.

>    Also, it's difficult to decide the interval for sending this option
> as it totally depends on network analysis apps.
>    It seems that the draft presumes to use one fixed value for
> interval, but I'm not sure if we can find a proper value as I guess
> the requirements can be varied for some reasons.

It's not intended that the option is required in the flow for proper
operation of anything, including any network analysis applications.
It is solely intended as a convenience datum which may be discovered
either manually or by an analysis application.

The draft does not require any specific interval, and I see no
reason for a fixed interval either.  A fixed number of packets is
simple to code, but that should not be part of the specification.

> 3: The requirements in Section 2.3 won't be needed as it's already
> stated in Section 2.2 in RFC7323.
>     So, I think this proposal will require sender-only modification.
> (which is better than updating both sides)

I'll change the wording, to clarify that RFC 7323 still controls this
aspect.

> 4: I think you'll need to refer RFC7323 instead of 1323 as 1323 is obsoleted.

Yes.

-- 
Cheers,
  Jeremy