Subject: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-01

From: "Zimmermann, Alexander" <[email-masked]>
Date: Sat, 8 Nov 2014 20:58:14 +0000

Hi Joe,

yesterday I found some time to re-read the draft. A couple of points

*** Technical ***

* The whole drafts reads like we have *two* EDO options, aka the „TCP EDO
request option“ and the „TCP EDO length option“, but actually we only have
one option, the EDO option. I found this a bit confusing. Saying this, why
do we not include the Header_length field in any EDO frame, i.e. also in
the SYN. For signaling (EDO negotiation) we can use values for the
Header_length that are less than the DO value.

* Page 4: „A null EDO length option contains the same value as the DO field,
i.e., it does not extend the TCP option space“ Personally, I don’t like the
term „null“ because it gives (at least me) the wrong impression that the
Header_length contains 0. Could we say „neutral“ instead of „null“?

* Page 5: „When processing a segment, EDO needs to be visible within the
area indicated by the Data Offset field“. Be more expect here, by saying
that the EDO option must be in the first 40 Bytes after the fixed TCP
header. IMO it makes it a bit more clearer.

*** Editorial ***

* Page 6: Personally, I would swap the text and speak first about the
placement of the EDO option and then about the alignment.

* Section 7 Related Work - into an appendix?

*** Nits ***

* page 13: „The following discusses three of the most notable past …“
Actually, you discuss 4 approaches.

* Sec. 12: Acknowledgments. Last word. There is a missing „n“ at the
end of the name :-)

Alex

---

From: Joe Touch <[email-masked]>
Date: Sat, 08 Nov 2014 19:49:17 -0800

Hi, Alex,

Thanks for the feedback.

Some comments below.

Joe

> Header_length that are less than the DO value.

The SYN is the last place we want to burn space that has no purpose.
That's why the option has two variants - the signal and the actual use.
I'll see what I can do to clarify that.

> Header_length contains 0. Could we say „neutral“ instead of „null“?

"redundant" might be more accurate; point taken.

> header. IMO it makes it a bit more clearer.

I will clarify, but it's not that it's just in the first 40 bytes. It's
that it's within the space indicated by DO as well (DO can be less than
15 - and EDO needs to be visible within that area).

> * Section 7 Related Work - into an appendix?

I don't have the draft in front of me; I'll take a look at these as
well, but I'd like to hear from others before making such changes.

> Actually, you discuss 4 approaches.

Agreed; this isn't a Monty Python skit ;-)

> * Sec. 12: Acknowledgments. Last word. There is a missing „n“ at the

Will fix, of course.

---

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Sun, 9 Nov 2014 19:54:33 +0000

Hi Joe,

> Am 08.11.2014 um 17:49 schrieb Joe Touch <[email-masked]>:
> 
> Hi, Alex,
> 
> Thanks for the feedback.
> 
> Some comments below.
> 
> Joe
> 

OK, I see. Point taken. But the same applies to the SYN/ACK too. So,
additional question: why do we not send „TCP EDO request option“ back
to the client?

Moreover, w/ RFC2018 we have more or less the same. Some negotiation and
the actual usage of the option. Any harm to burn two „kinds“ like RFC2018?

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Sun, 9 Nov 2014 20:00:59 +0000

Hi Joe,

---

From: Joe Touch <[email-masked]>
Date: Sun, 09 Nov 2014 12:03:41 -0800

Comments below...

On 11/9/2014 11:54 AM, Zimmermann, Alexander wrote:
> OK, I see. Point taken. But the same applies to the SYN/ACK too. 

Yes. The SYN/ACK either needs to similarly conserve space and use just
the flag variant *if* EDO extension isn't allowed (that's how the
current spec is written).

If we allow use of the EDO extension space in the SYN/ACK (e.g., if
we're not as worried about asymmetric middlebox corruption), then we'd
use the regular EDO variant which would extend the space --- in that
case, the space the option consumes isn't an issue.

> So,

That's what the current draft says to do for SYN/ACK, for the reason above.

> the actual usage of the option. Any harm to burn two „kinds“ like RFC2018?

We've since learned better ;-)

In specific, we want fate-sharing of the option kind. We don't want the
impact of a bug that works on one kind but doesn't handle the other.

There's also no benefit. The difference between the option types can be
determined by the length of a single type.

Joe

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Sun, 9 Nov 2014 21:28:25 +0000

> Am 09.11.2014 um 10:03 schrieb Joe Touch <[email-masked]>:
> 
> Comments below…

Dito

> That’s what the current draft says to do for SYN/ACK, for the reason above.

IMO, that not the case. Page 4, sec 4, second para:

„ If receiver of that SYN agrees to support EDO, it responds with a null EDO
length option in the SYN/ACK. A null EDO length option contains the same value
as the DO field, i.e., it does not extend the TCP option space.“

If I understand this correctly the server sends back the „TCP EDO length option“
meaning that the „Header_length“ is non empty. If we all agree (and I’m not sure
about this) that asymmetric middle box corruption is common and we cannot
extent the option space in a SYN/ACK via EDO, why we could not echo back:

+--------+--------+
|  Kind  | Length |
+--------+--------+

from the server side?

Alex

---

From: Joe Touch <[email-masked]>
Date: Sun, 9 Nov 2014 16:39:32 -0800

> On Nov 9, 2014, at 1:28 PM, Zimmermann, Alexander <[email-masked]> wrote:
> 
> 

Yes.  I had thought about that after the revision and thought I changed it. 

> extent the option space in a SYN/ACK via EDO, why we could not echo back:

Yes. That's what I had intended but missed in the revision. Sorry for the confusion. I'll fix in the next rev. 

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 13 Nov 2014 01:09:43 +0000

Another point:

* Page 4: „A null EDO length option contains the same value as the DO field, i.e., it does not extend the TCP option space“

"DO field" is not formally mentioned prior to this instance in the draft; If the -02 mentiones it in other places, I suggest to introduce it somewhere "... the TCP header data offset field (DO field)", or alternatively simply refer to it in full words.

"When the EDO length is invalid, the TCP	segment MUST be silently dropped"

When is EDO length invalid? Is that meant to refer to the length field of the EDO option (4), or the "edo length option" as a whole, ie. when the Header_length is < DO, (inclusive) or > Segement_Length?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Zimmermann,
> Alexander
> Sent: Samstag, 08. November 2014 10:58
> To: Joe Touch; [email-masked]
> Subject: [tcpm] Comments to draft-ietf-tcpm-tcp-edo-01
> 
> Hi Joe,
> 
> * Page 4: „A null EDO length option contains the same value as the DO
> field, i.e., it does not extend the TCP option space“ Personally, I don’t
> like the term „null“ because it gives (at least me) the wrong impression
> that the Header_length contains 0. Could we say „neutral“ instead of
> „null“?
> 
> * Sec. 12: Acknowledgments. Last word. There is a missing „n“ at the end
> of the name :-)
> 
> Alex
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Nov 2014 21:20:54 -0800

Hi, Richard,

Thanks for the additional comments. Notes below...

Joe

On 11/12/2014 5:09 PM, Scheffenegger, Richard wrote:
> 
> Another point:
> 
> * Page 4: „A null EDO length option contains the same value as the 
> DO field, i.e., it does not extend the TCP option space“
> 
> "DO field" is not formally mentioned prior to this instance in the
> draft; If the -02 mentiones it in other places, I suggest to introduce
> it somewhere "... the TCP header data offset field (DO field)", or
> alternatively simply refer to it in full words.

Will fix (in the first sentence of the Intro).

> When is EDO length invalid? Is that meant to refer to the length 
> field of the EDO option (4), or the "edo length option" as a whole,
> ie. when the Header_length is < DO, (inclusive) or >
> Segment_Length?

There are two different issues for validity, as you point out:

	a well-formed EDO option

	a meaningful EDO length field value

I'll revise and clarify accordingly.

---