Subject: [tcpm] Comments on draft-zimmermann-tcpm-echo-option

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 20 Jul 2015 10:12:08 +0200

Hi,

I gave a quick look at draft-zimmermann-tcpm-echo-option-00, so here are a few thoughts (as individual IETF participant, of course).

* it would be nice to have a few examples in the intro about how this could be used. I gather you are planning a separate document for spurious timeouts, and separate document is good, but some motivating examples also here would not harm.

* It is required that at most one Echo option is included per segment. Is there any reason to limit the number of options? I couldn’t immediately see why having multiple instances of the option would cause problems, or could it?

* "A TCP sender MAY send an empty TCP Echo option with Length=2 on the SYN…” — this would not have to be limited just to SYNs, right? Can’t think of any useful reason for sending empty echo pings mid-connection (some sort of diagnostics, perhaps?), but can’t see any reason to disallow that either. Also, it might be helpful clarification to note that when ExID is used, length will be different.

* "it is NOT RECOMMENDED to send easily decipherable data in the clear as data in the TCP Echo option…” — I don’t think this recommendation is necessary. Depends on the intended use, I guess. There are other ways for encrypting TCP header when that is needed.

Will send some additional editorial nits to authors directly...

- Pasi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 20 Jul 2015 09:49:28 +0000

Hi,

> * it would be nice to have a few examples in the intro about how this
> could be used. I gather you are planning a separate document for spurious
> timeouts, and separate document is good, but some motivating examples also
> here would not harm.

Certainly; SYN Cookies (drafted by Bob) is another example that needs the different semantics.

> * It is required that at most one Echo option is included per segment. Is
> there any reason to limit the number of options? I couldn't immediately
> see why having multiple instances of the option would cause problems, or
> could it?

Yes, there are issues with that, and they are plentiful. The easy way out was to side-step this, and only allow (just as with every other TCP option so far) only a single instance of the option, and only reflect the option most recently observed by the receiver.

Issues include, but are not limited to
o) semantics
o) ordering
o) meddleboxes
o) receiver state
o) implementation issues

> * "A TCP sender MAY send an empty TCP Echo option with Length=2 on the
> SYN..." - this would not have to be limited just to SYNs, right? Can't think
> of any useful reason for sending empty echo pings mid-connection (some
> sort of diagnostics, perhaps?), but can't see any reason to disallow that
> either. Also, it might be helpful clarification to note that when ExID is
> used, length will be different.

We did not want this document to specify a full in-session negotiation protocol - as that problem has been discussed on the list earlier, it's a hard issue and beyond the scope of what we want to achive with this draft.

> * "it is NOT RECOMMENDED to send easily decipherable data in the clear as
> data in the TCP Echo option..." - I don't think this recommendation is
> necessary. Depends on the intended use, I guess. There are other ways for
> encrypting TCP header when that is needed.

Even when only the receiver can decode (or make educated guesses about) the contents of a field that is supposed to be immutable, it has shown issues in the past (reference early cubic implementations, that could be persuaded to give very large shares of bandwidth to a receiver that slightly modifies the TCP timestamp echo value). We also believe that this recommendation (not even a SHOULD or MUST) is in-line with RFC7258. 

> Will send some additional editorial nits to authors directly...

Thanks, we'll fix these in the next revision.

Best regards,
  Richard

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 20 Jul 2015 12:41:20 +0200

> Issues include, but are not limited to

Ok. I thought that “just echo what you saw in latest segment” might have been sufficient, perhaps in the same order than in incoming packet. Middleboxes might have issues even with single option.

So if there were multiple different uses for this mechanism, one would need to make a choice, or bundle the data somehow.

The semantics of what to echo seems difficult question even with single option: if the first segment includes the option and second does not, and ACK is sent only after the second segment, is it correct to echo the option from the first segment? This is pretty difficult to answer without knowing what the intended uses are. It could be that different uses need different semantics.

> We did not want this document to specify a full in-session negotiation protocol - as that problem has been discussed on the list earlier, it's a hard issue and beyond the scope of what we want to a…

I did not propose in-session negation, but only asked if it is possible to send a zero-payload Echo option? Might be silly, but does not seem harmful. Now that I better read the draft, it seems to allow this in earlier text, which is ok, I guess.

> Even when only the receiver can decode (or make educated guesses about) the contents of a field that is supposed to be immutable, it has shown issues in the past (reference early cubic implementati…

Fine, it may be necessary to protect against cheating receivers, depending on what the option is used for. Ideally RFC 7258 should be addressed with a common solution so that one does not need to obfuscate each protocol field or option separately. But as you say, the language here is not too restrictive.

- Pasi

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 21 Jul 2015 22:45:48 -0700

How does echo option work with TSO / GRO or stretched ACKs. They are
all common cases now.

TCP Efiel works very well already with TCP timestmaps (which
unfortunately takes 12 bytes option space). It's not clear if this new
option provide substantial benefit? Sure having a packet sequence
field improves identifying spurious re-transmission, reordering, RTT
estimation. But the benefits are too minor to justify a new option.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 22 Jul 2015 11:27:14 +0000

Hi Yuchung,

The echo option is one part (providing new semantics, useful for a lot of cases, as for example SYN cookies);

The Spurious retransmission detection facility builds on top of the new semantics, yielding detection capability under more (arguable, corner) cases than TSopt - at lower overhead, while enabling further uses (which are partially in Linux TCP already, agreed, but not standardized). 

The interaction with TSO should be benign, as in the design for SRD we keep the same Echo option until the sender enters loss recovery; thus copying the option over into any header is the expected behavior.

On GRO, a chance in the tcp options should trigger the hand off to TCP already, and we don't expect this to run significantly different, as for SRD, the Echo option changes when there is a reordering / non-consecutive packet received, which should be treated by GRO already (but Joe's finding seem to indicate that GRO is sometimes broken with options, from the EDO slildes presented just now).

Finally, after a hallway conversation with Matt, I think that the Echo Option, in the design for SRD, could also be used for PAWS - taking away another exclusive use case for timestamps - replacing that with a smaller (wire overhead) option. But I would have to think about this more....

Best regards,
  Richard

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Yuchung Cheng
> Sent: Mittwoch, 22. Juli 2015 07:46
> To: Pasi Sarolahti
> Cc: [email-masked] Extensions
> Subject: Re: [tcpm] Comments on draft-zimmermann-tcpm-echo-option
> 
> How does echo option work with TSO / GRO or stretched ACKs. They are all
> common cases now.
> 
> TCP Efiel works very well already with TCP timestmaps (which unfortunately
> takes 12 bytes option space). It's not clear if this new option provide
> substantial benefit? Sure having a packet sequence field improves
> identifying spurious re-transmission, reordering, RTT estimation. But the
> benefits are too minor to justify a new option.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jul 2015 11:31:10 -0700

FWIW, I really wish this option could find a way to use one TCP Kind
codepoint. What's the reason for not doing so? It seems consistent with
the other requirements indicated in the document.

(and no, I don't consider "detecting blind unknown-option reflectors a
valid reason; TCP isn't designed as a diagnostic tool for byzantine
failures)

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 22 Jul 2015 19:20:03 +0000

Today in the presetation there was also a comment to have the same mechanism for symetric data transport using only a single tcp option codepoint.

For our specific use case, the counter for srd does not need to be very large - reducing it to 6 bit and using 2 bits of the first byte to signal something like this would work in our use case...

Is this would you were thinking of?

Best regards,
   Richard Scheffenegger

> Am 22.07.2015 um 20:31 schrieb "Joe Touch" <[email-masked]>:
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jul 2015 12:43:37 -0700

> Is this would you were thinking of?

Yup.

(also, have you considered whether you can reuse the original Echo
codepoint? if you flip a bit in the response, you would always know the
difference)

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 22 Jul 2015 20:00:49 +0000

Hi Joe,

We can certainly ask IANA to reuse that codepoint if and when we pass the signaling draft, even though the semantics are different than in the old spec - but there is no use of the echo option that i know of (happy to hear about that though).

Thanks!

Best regards,
   Richard Scheffenegger

> Am 22.07.2015 um 21:44 schrieb "Joe Touch" <[email-masked]>:
> 
> 
>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 22 Jul 2015 18:18:48 -0700

> The echo option is one part (providing new semantics, useful for a lot of cases, as for example SYN cookies);
What problems does echo solve that syn-cookies don't? not mentioned in draft.

> The Spurious retransmission detection facility builds on top of the new semantics, yielding detection capability under more (arguable, corner) cases than TSopt - at lower overhead, while enabling f…
which features are you talking about here? (again not clear from draft)

> The interaction with TSO should be benign, as in the design for SRD we keep the same Echo option until the sender enters loss recovery; thus copying the option over into any header is the expected…

Is echo option length fixated throughout the connection?

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 23 Jul 2015 06:37:14 +0000

Hi Yuchung,

> What problems does echo solve that syn-cookies don't? not mentioned in

I was referring to Bob's SYN Cookie proposal, not the traditional syn cookie in ISN/TSval - https://tools.ietf.org/html/draft-briscoe-tcpm-echo-cookie-00. The traditional approach is limited in the number of bits you can "store" in-flight, while the echo option would allow larger hashes, thus more state to be exchanged (limited by the available option bytes, after accounting for the needed options in the SYN).

> > The Spurious retransmission detection facility builds on top of the new
> semantics, yielding detection capability under more (arguable, corner)
> cases than TSopt - at lower overhead, while enabling further uses (which
> are partially in Linux TCP already, agreed, but not standardized).
>

In the SRD case, the echo option can be thought of as an abbreviated control stream sequence counter; I understand that in QUIC, as also in SCTP, you have two independent counters, one for the sequence of segments, and one for the ordering of payload bytes. Whatever that enables, can be enabled with the Echo option (I am interested in improved loss recovery, lost retransmission detection/recovery; Alex approach was from the reordering side / spurious retransmission detection). With other words, using that you can fully separate the "what" from "when" to send, within TCP.

> > The interaction with TSO should be benign, as in the design for SRD we
> keep the same Echo option until the sender enters loss recovery; thus
> copying the option over into any header is the expected behavior.
> 

No, the option is of variable length - and can be omitted if the sender is so inclined. The current thinking is, that whatever is present (the omission by itself is also a signal) in a segment that triggers an ACK, is being reflected back. Between the signaling protocol (TCP Echo opt) and the uses there is a distinction - a mechanism such as SRD would basically send an echo option on every transmitted (data) segment, for a constant feedback.

Another mechanism such as https://tools.ietf.org/html/draft-briscoe-tcpm-echo-cookie-00 would use the echo option only during 3WHS...

And still other mechanisms may sporadically send out some data, but none at other times (with an empty, len=2, echo option during SYN)

Best regards,
  Richard