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

From: Jeremy Harris <[email-masked]>
Date: Tue, 1 Nov 2016 15:55:59 +0000

Dear All,

I have submitted a draft extending the use of the TCP Wscale option.
Comments and suggestions are welcome.

-- 
Jeremy

-------- Forwarded Message --------
Subject: New Version Notification for draft-harris-estab-wscale-00.txt
Date: Mon, 31 Oct 2016 06:27:03 -0700
From: [email-masked]
To: Jeremy Harris <[email-masked]>

A new version of I-D, draft-harris-estab-wscale-00.txt
has been successfully submitted by Jeremy Harris and posted to the
IETF repository.

Name:		draft-harris-estab-wscale
Revision:	00
Title:		WSCALE options in established TCP connections
Document date:	2016-10-31
Group:		Individual Submission
Pages:		3
URL:
https://www.ietf.org/internet-drafts/draft-harris-estab-wscale-00.txt
Status:         https://datatracker.ietf.org/doc/draft-harris-estab-wscale/
Htmlized:       https://tools.ietf.org/html/draft-harris-estab-wscale-00

Abstract:
   The TCP Window Scale option modifies the interpretation of packets in
   a flow but is transmitted only at the start of the connection.  As
   such there is a problem for observability and fault-finding, since a
   packet capture by a third party may miss the start of a relevant
   connection.  This document describes the use of TCP options to
   provide the scale values during a connection.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 10 Nov 2016 15:21:37 -0800

Hi Jeremy,

I think this is simple protocol and might be useful for some middle
points that analyze network traffic.
I have the following comments on the draft.

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.

2: For the same reason, it seems to be difficult for senders to decide
whether activate this feature or not.
   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.

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)

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

Thanks,
--
Yoshi

On Tue, Nov 1, 2016 at 8:55 AM, Jeremy Harris <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm