Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-00.txt

["Zimmermann, Alexander" <[e-mail]>]

Hi Joe, Wes,

thank you for this work. I also strongly support this work/doc.

Some comments

* Sec 1:
   - Please add a reference to RFC 793.
   - Please add one or two examples of common option combinations where we have a problem, e.g. TCP TS, SACK, and Multipath TCP

* Sec 2:
   - „A SYN may include user data …“ Please add a reference to RFC 793/TFO

* Sec 4:
   - Should we mention „draft-paasch-mptcp-control-stream“ here?
   - „The six reserved … to be ignored“ —> maybe we can required this in RFC793bis ;-)
   - While it may be not possible to extend the option in a SYN, it’s possible to reduce the space needed, e.g.
     late negotiation. Maybe we can add some text here. 

* Sec 5:
   - „For initial SYN segments (i.e., those whose ACK bit is not set)“. IMO a SYN is a segment where the SYN bit is set.
   - The explanation of the EDO option is in a different order than the figures. Please explain first figure 1 and
     then 2 (or swap the figures)
   - „An endpoint confirming EDO support MAY… in its SYN-ACK“ —> So, a receiver can extend its options space directly
     in his first segment. Right?
   - „Because it overrides an existing TCP header field when present“ -> I don’t get this. You override the data field, no?
     (After reading Sec. 6.3, I have the feeling that I understand what you mean here…)
   - Last para. Add ref to TCP-AO

* Sec 6.3
   - „Once detected, the TCP EDO length option… for all subsequent option processing OF THIS SEGMENT“. Please make it clear
     that subsequent segments may not have the EDO length option and the Data Offset field becomes valid again.
   - BTW I’m not sure if the word override is the best one in this context. Is „invalid“ not more appropriate?

General comment at this point:
   - Should we not require that the Data Offset field must be zero if TCP EDO length option is present, because it has
     no meaning in that case
   - As more I think about TCP EDO updates RFC793…

Alex


Am 22.04.2014 um 16:49 schrieb Joe Touch <[e-mail]>:

> Hi, all,
> 
> Wes and I wrote the following to try to put to rest the issue of extending TCP's option space. Although the primary reason was to summarize why the SYN space cannot be extended, it is written as Standards-Track because it includes an extension for non-SYN segments that could still be useful when SACK, TS, and authentication or encryption options are used together.
> 
> We are seeking this as a TCPM WG doc. Feedback appreciated.
> 
> Joe and Wes
> 
> -------- Original Message --------
> Subject: New Version Notification for draft-touch-tcpm-tcp-edo-00.txt
> Date: Fri, 18 Apr 2014 13:30:46 -0700
> From: [e-mail]
> To: Wesley M. Eddy <[e-mail]>,        Dr. Joseph D. Touch <[e-mail]>, Joe Touch <[e-mail]>,        Wesley Eddy <[e-mail]>
> 
> 
> A new version of I-D, draft-touch-tcpm-tcp-edo-00.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
> 
> Name:		draft-touch-tcpm-tcp-edo
> Revision:	00
> Title:		TCP Extended Data Offset Option
> Document date:	2014-04-18
> Group:		Individual Submission
> Pages:		9
> URL: http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-edo-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-touch-tcpm-tcp-edo/
> Htmlized:       http://tools.ietf.org/html/draft-touch-tcpm-tcp-edo-00
> 
> 
> Abstract:
>   TCP segments include a Data Offset field to indicate space for TCP
>   options, but the size of the field can limit the space available for
>   complex options that have evolved. This document specifies an
>   optional extension to that space and explains why such extensions
>   (including this) cannot be used in the initial SYN.
> 
> 
> 
> 
> 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
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm