Re: [tcpm] New Version Notification for draft-ietf-tcpm-accurate-ecn-11.txt

["Scharf, Michael" <[e-mail]>]

Bob,

Regarding „The WG chose the first counter bit, so I wrote it up.“: We all know that working group documents can take several iterations before converging to the „best“ solution that has (hopefully unanimous) WG consensus. If the working group has change control over the content, discussing technical pros and cons of a document update is business as usual. Yet, I don’t think that many iterations will be required for this specific option encoding question, given that there are many straightforward and trivial solutions that would all address my concern.

Other than that, I am only interested in discussing technical pros and cons of alternatives to the proposal -11, in order to find a better engineering approach. My concerns are not related to formal proofs of protocol correctness.

Thanks

Michael (chair hat off, as usual)


Von: Bob Briscoe<mailto:[e-mail]>
Gesendet: Donnerstag, 12. März 2020 19:59
An: Scharf, Michael<mailto:[e-mail]>; tcpm IETF list<mailto:[e-mail]>
Cc: Richard Scheffenegger<mailto:[e-mail]>; Mirja Kuehlewind<mailto:[e-mail]>
Betreff: Re: AW: [tcpm] New Version Notification for draft-ietf-tcpm-accurate-ecn-11.txt

Michael,

On 10/03/2020 23:27, Scharf, Michael wrote:
Bob,

Out of my head, I am not aware of any IETF protocol that uses TLV encoding with ambiguous message formats, i.e., message with the same type but different message formats depending on earlier messages. For instance, this can easily get messy during debugging. And a protocol that is hard to debug is *not robust* in my point of view.

I understand that the highest bit solution is not ideal. I am merely pushing back on the notion that it is completely unacceptable.


I have already pointed out that IMHO a tool like Wireshark cannot correctly decode the option for a partial PCAP trace. The same applies to any passive monitoring tool that uses sampling. This has significant operational impact. Well, your mileage may vary, but I see no value in obscuring the counters by an „unorthodox“ encoding that requires keeping state to figure out what the option format actually is.

And I am not a hardware expert, but if AccECN should really be sucessful, hardware offloading in NICs will probably matter in future. Thus, the length of options is not the only tradeoff to be considered to make the protocol sucessful. As far as I understand, simple stateless message formats help a lot when it comes to hardware offloading.
That was indeed why we originally had a fixed field order.

I proposed two alternative ways to allow different field orders: a) two option kinds or b) first counter bit.
The WG chose the first counter bit, so I wrote it up.

I just wish this WG would make up its mind, and have some discipline so that people know in advance that a decision will not be reversed at the next meeting. Then people know that they have to stop reading their email and really think carefully before making a decision.



It is well understood that many implementers may try to avoid the option altogether. An „unorthodox“ encoding will almost certainly not help to get the option widely deployed.

Just to repeat myself, if I had to pick between the current proposal in -11 and two different option codepoints, I would go for the latter. We have >150 TCP option codepoints left. That resource is not so scarce after all. I fail to see any real-world benefit of the proposal in -11 as compared to two separate codepoints.

In a nutshell, I believe you should look for an option design that can be processed by a stateless decoder. In other words, KISS. There are plenty of ways how to do that, and adding a byte is only one of them. I have already mentioned several other alternatives, and probably there are more (e.g., one could use a 2-bit type field for each counter to identify it). All of them seem *simpler* to me than the current proposal in -11.

To me, this idea in -11 *is broken* and this should be fixed in -12.
I don't think you have answered my questions sufficiently to make such a claim. You have given examples of cases where 3rd party monitoring will get confused. But calling that "broken" is, I think, an overstatement. How does the protocol itself /break/?

You have said it doesn't allow the order to be changed mid connection. But that is not "broken". That is a feature that I'm not convinced is needed. If the occasional connection would have made more efficient use of 3B of option space if it had been able to switch to a different field order, is that worth the extra complexity?

That is what I was getting at from my questions: What is actually "not robust / broken" about it? In what case(s) can it fail? Have you proved these problems exist (whether paper proof or empirical)?

What I don't want to happen (again) is that the WG swings to yet another solution, before a proper case has been made for the need to do so.


Bob


Michael


Von: Bob Briscoe<mailto:[e-mail]>
Gesendet: Dienstag, 10. März 2020 23:00
An: Scharf, Michael<mailto:[e-mail]>; tcpm IETF list<mailto:[e-mail]>
Cc: Richard Scheffenegger<mailto:[e-mail]>; Mirja Kuehlewind<mailto:[e-mail]>
Betreff: Re: [tcpm] New Version Notification for draft-ietf-tcpm-accurate-ecn-11.txt

Michael,

I agree extensibility is nice. And I'm open to a design with a 1 octet field immediately after the length field, for flags and the like. In fact, I encouraged Ilpo to put his idea to the list (which he had put to be offlist). But let's be disciplined about this if we're going to start down this road...

1) This is not the time for "it would be nice if". I want to go back to your original email and ask you to be much more specific about the problems envisaged. I agree the idea of switching field order based on the first bit is unorthodox, but what is actually "not robust" about it? In what case(s) can it fail? Have you proved these problems exist (whether paper proof or empirical)?

2) We have a very *inextensible* lack of TCP option space to deal with. And we don't know what other important options might be invented in future. So we shouldn't burn even a single byte unless we have good reason to. Extensibility is good. But it does burn space.

3) I haven't asked my co-authors, but I know that Mirja wanted the design to be as simple as possible, and now we're moving away from that.

If it ain't broken don't fix it.



Bob

On 09/03/2020 20:00, Scharf, Michael wrote:
With chair hat off, I really wonder if the solution to encode the two different orders in the TCP Option is an example for good and robust protocol engineering.

For instance, the current design makes it hard to decode the field in a monitoring tool (such as Wireshark). Also, as far as I understand, it does not allow to switch the encoding during a connection, which limits flexibility. We almost certainly do not understand *now* all future use cases of this Standard.

Unless I miss something, there would be several other solutions:

First, IMHO, we have enough TCP option codepoints left to spend two codepoints if there is a good reason for doing so. As compared to the current design proposal in -10/-11, spending two different option kinds would look to me like *much* better protocol engineering.

Second, if the TCPM community insists in only one option kind codepoint for whatever reason, IMHO one could add one „sub-type“ byte to the option. The TCP Option field has to be multiples of 4 byte, i.e., if a segment only contains a 11 byte AccECN TCP option, an additional NOP TCP option is needed for padding, no? So, what downside have 12 bytes as compared to 11 bytes? For the shorter variants, the overhead of a „sub-type“ field increases, but it may still be within reasonable limits. What do I miss?

Third, one could use different lengths for the different orders, e.g., lenths 5/8/11 for type 0 and 6/9/12 for type 12. Is this not possible?

In all these cases, the resulting protocol looks simpler and more robust to me. What prevents us from using the KISS principle?

Michael



Von: Bob Briscoe<mailto:[e-mail]>
Gesendet: Freitag, 6. März 2020 04:34
An: tcpm IETF list<mailto:[e-mail]>
Cc: Richard Scheffenegger<mailto:[e-mail]>; Mirja Kuehlewind<mailto:[e-mail]>
Betreff: Re: [tcpm] New Version Notification for draft-ietf-tcpm-accurate-ecn-11.txt

tcpm,

You will have seen draft-10 then draft-11 in quick succession, as already explained.
The diffs from draft-09 to -10 were those that had built up since Jul'19.
The diffs from draft-10 to -11 were solely those for the change from EXP track to STD track.
Draft-10 doesn't seem to display in the list of links to each version, but you can manually write the URL.

The main technical changes in draft-10 were numerous - many will be recognized from list discussion since Jul'19.
Particular thanks to Ilpo Järvinen who identified many niggles (and their solutions) while writing and testing a full Linux implementation (based on Olivier Tilmans's, in turn based on Mirja's).

  *   Allowed 2 different orders of the fields in the AccECN Option
  *   Reflect IP-ECN field of SYN/ACK only on ACK of SYN/ACK, not also on first data packet
     *   greatly simplifies implementation, esp with TFO.
     *   repeating on first data packet was for reliable delivery, which is now achieved with ACE counter (see next bullet)
  *   Increment the ACE counter if CE on SYN/ACK (but still not if CE on SYN)
     *   Reliable delivery of feedback of CE on SYN/ACK
  *   Redefine 'first packet' as first to arrive, not first in sequence in 2 cases:
     *   Handshake reflection on the ACK of the SYN/ACK
     *   In the test for zeroing of ACE
     *   Reason: greatly simplifies implementation
  *   if ACE could have wrapped more than once, SHOULD assume “safest likely case”
not "conservatively assume" it did cycle
     *   Reason: avoid unnecessary hit on performance
  *   More robustness (with flexibility) in rules for when to include an AccECN Option
     *   Change-triggered AccECN Option as SHOULD, not MUST
     *   SHOULD follow change-triggered AccECN Option with another (removes ambiguity if ACK thinning or loss)
     *   when same counter continues to increment, SHOULD consistently include it every n ACKs
     *   Made rule about precedence of SACK conditional (max 2 SACK blocks)
     *   MAY exclude counters that have not changed for the whole connection
  *   Allowed an AccECN server not to implement RFC3168 ECN (all clients still have to)
  *   Precluded mixed capability negotiation from either end
     *   reduces freedom to choose SYN & SYN/ACK fall-back strategies
     *   to prevent cases where each end's outcome after handshake could be inconsistent (in reordering corner-cases)
  *   Reserved the codepoint combination used by the historic nonce case
  *   Merged in a number of points from RFC3168 that we hadn't covered
     *   (a whole new subsection about obligations to do with ECN)
  *   Explicit about checking "acceptable packets"
     *   before counting their ECN markings or before counting the ECN feedback they carry
  *   Required retransmitted Fallback SYN to use same ISN
     *   allows servers to detect ECN downgrade SYN attacks
  *   Handled corner cases like In-window SYN during TIME-WAIT


Bob
On 06/03/2020 02:24, [e-mail]<mailto:[e-mail]> wrote:



A new version of I-D, draft-ietf-tcpm-accurate-ecn-11.txt

has been successfully submitted by Bob Briscoe and posted to the

IETF repository.



Name:            draft-ietf-tcpm-accurate-ecn

Revision: 11

Title:           More Accurate ECN Feedback in TCP

Document date:   2020-03-05

Group:           tcpm

Pages:           58

URL:            https://www.ietf.org/internet-drafts/draft-ietf-tcpm-accurate-ecn-11.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/

Htmlized:       https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-11

Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-11



Abstract:

   Explicit Congestion Notification (ECN) is a mechanism where network

   nodes can mark IP packets instead of dropping them to indicate

   incipient congestion to the end-points.  Receivers with an ECN-

   capable transport protocol feed back this information to the sender.

   ECN is specified for TCP in such a way that only one feedback signal

   can be transmitted per Round-Trip Time (RTT).  Recent new TCP

   mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP)

   or Low Latency Low Loss Scalable Throughput (L4S) need more accurate

   ECN feedback information whenever more than one marking is received

   in one RTT.  This document specifies a scheme to provide more than

   one feedback signal per RTT in the TCP header.  Given TCP header

   space is scarce, it allocates a reserved header bit, that was

   previously used for the ECN-Nonce which has now been declared

   historic.  It also overloads the two existing ECN flags in the TCP

   header.  The resulting extra space is exploited to feed back the IP-

   ECN field received during the 3-way handshake as well.  Supplementary

   feedback information can optionally be provided in a new TCP option,

   which is never used on the TCP 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







--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/