Subject: Re: [tcpm] On allocating reserved bits in the TCP header

From: "Rodney W. Grimes" <[email-masked]>
Date: Sat, 2 Nov 2019 14:25:00 -0700 (PDT)

Reviving this thread,

> Hi all,
> 
> Disclaimer: I write this note as individual contributor to TCPM. It is possible that I end up in the rough part of the TCPM consensus in this case. That would be unusual, but it is not impossible. If so, this e-mail documents my concerns (again). Reasonable people can reasonably disagree, and that does not prevent the working group from moving forward. I'd also like to announce that I would prefer not to serve as shepherd for a document if consensus has to be declared against me, in order to avoid any bias.
> 
> Given that we need to finish draft-ietf-tcpm-accurate-ecn, and given other recent TCPM discussions on reserved TCP header bits, I have thought about the IANA considerations of allocating a reserved header bit. This e-mail is not about the question of _whether_ to allocate a bit. It is about the _how_.
> 
> That question was discussed in the past for draft-ietf-tcpm-accurate-ecn already quite a bit, e.g. during IETF 99. During that discussion, I have raised concerns against allocating a bit in the main TCP to an experiment without backing by a standards track RFC. I may have been in the rough part of the consensus in the room when that discussion took place. But I have not changed my mind.
> 
> The statement in RFC 2780 is: "The reserved bits in the TCP header are assigned following a Standards Action process."
> 
> RFC 8126 explains: "For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream."
> 
> And I think that requirement in RFC 2780 is correct. I probably don't have to expand on why IETF rules make sense to me. RFC 2780 and RFC 8126 don't leave much room for interpretation, as far as I understand them.
> 
> It is well-known that bit 7 requested by draft-ietf-tcpm-accurate-ecn has previously been allocated to an experimental RFC (RFC 3540). That happened before I have joined IETF mailing lists, and I am not familiar with the corresponding discussions, most notably regarding compliance with RFC 2780. In any case, given that RFC 3540 is now historic and the bit is has status "reserved", the current IANA registration of TCP header flags is apparently compliant to RFC 2780.
> 
> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.
>  
> And actually I believe it would not be hard to do so. For instance, TCPM could publish a short standards track RFC that allocates e.g. bit 7 for experiments. That could solve the allocation needed by draft-ietf-tcpm-accurate-ecn. Similar to RFC 8311, a standards track document could precisely define what experimentation is allowed with that bit. It would be a short document that could be finished on fast track, possibly even in parallel to draft-ietf-tcpm-accurate-ecn, provided that there is consensus on allocating e.g. bit 7 to a well-defined area of experimentation. It has been pointed out in the past that such as standards track document would result in overhead. I believe that the overhead would be small and worth the effort.
> 
> In any case, I feel uncomfortable with creating a precedent for IETF process violation regarding any of the reserved bits in the TCP header.

I have reviewed the above, and am in full agreement.

As author of draft-grimes-tcpm-tcpsce, which is also requesting use of a TCP bit for experimental purpose, ask what the next steps are?

-- 
Rod Grimes                                                 [email-masked]

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 3 Nov 2019 14:51:27 +0000

> As author of draft-grimes-tcpm-tcpsce, which is also requesting use of a TCP bit
> for experimental purpose, ask what the next steps are?

The usual dos and don'ts apply: Socialize the idea, get feedback, consider the feedback, update the document, convince the working group, etc.

We have 4 reserved bits left in the TCP header. There has been a past and completed experiments with bit 7. The past use could be considered a precedent when publishing a standards track document that allows new experiments with reserved bits. The precedent only exist for bit 7.

I am aware of at least 4 different ideas that have been posted recently to this list regarding use of a reserved bit. If the TCPM working group (well, actually the IETF) reached consensus that more than one experiment was useful, we may have to think about a way of negotiating what experiment is in use on a connection. Or find another solution.

As an individual contributor to TCPM, my current thinking is that one bit (i.e., bit 7) would be enough for experimentation - for the time being.

This is my personal view. The last change to the main TCP header was done in 2001. It is hard to predict what the IETF consensus would be these days.

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 3 Nov 2019 22:04:14 +0000

Michael,

On 03/10/2019 12:31, Lars Eggert wrote:
> On 2019-9-10, at 13:50, Scharf, Michael <[email-masked]> wrote:
> Agreed.
> Lars

If asked this question in isolation, I would go for a quick RFC. But 
this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 
at IETF-99 (it was for the IESG to be asked to make a process 
exception). This is just a choice between processes. There's no 
difference to the technical outcome. Please can we just do it the way we 
already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum 
decision 'cos they didn't get what they wanted in the previous one.

Background
This issue was extensively discussed already. After a long offlist 
thread with the author of RFC8311 and others, a thread on tsvwg ran betw 
3 to 12 Jul 17:
https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD 
Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 
7 and assign it to itself, which would need the IESG to agree a process 
exception. That outcome was recorded on this slide for discussion in the 
subsequent tcpm WG meeting:
https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
record that "There is strong but not unanimous consensus in the room for 
assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be 
asked to make a process exception.

I didn't like that decision either, but this is just process. Can we 
move on please.

Bob

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 02:00:09 +0000

Bob,

With chair hat on: There was a discussion „in the room“ during IETF 99 and the outcome of a hum „in the room“ is documented in the minutes. In TCPM, consensus is confirmed on the list so that all contributors can comment. Please don’t refer to room discussions as working group „decisions“.

With chair hat off, I believe there was never a formal consensus decision in TCPM to explicitly violate RFCs. And, anyway, the working group could change past decisions, at least prior to completing a WGLC. In this specific case, as individual contributor, I explicitly and very strongly disagree to move forward with an invalid IANA considerations section.

Thanks

Michael

Von: Bob Briscoe<mailto:[email-masked]>
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michael<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Mirja Kuehlewind<mailto:[email-masked]>; Richard Scheffenegger<mailto:[email-masked]>
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,

On 2019-9-10, at 13:50, Scharf, Michael <[email-masked]><mailto:[email-masked]> wrote:

Agreed.

Lars

If asked this question in isolation, I would go for a quick RFC. But this is not in isolation.

The decision on what process to use has already been made - in Jul 2017 at IETF-99 (it was for the IESG to be asked to make a process exception). This is just a choice between processes. There's no difference to the technical outcome. Please can we just do it the way we already decided to.

Altho I'm a Brit, I am not a fan of people trying to re-run a referendum decision 'cos they didn't get what they wanted in the previous one.

Background
This issue was extensively discussed already. After a long offlist thread with the author of RFC8311 and others, a thread on tsvwg ran betw 3 to 12 Jul 17:
    https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM
This thread ends by deferring to a meeting arranged at IETF-99 during AD Office Hours, at which the tcpm chairs were represented.
The outcome of that meeting was to expect the AccECN draft to rename bit 7 and assign it to itself, which would need the IESG to agree a process exception. That outcome was recorded on this slide for discussion in the subsequent tcpm WG meeting:
    https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7
The tcpm minutes here:
    https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00
record that "There is strong but not unanimous consensus in the room for assigning the codepoint."
and the process proposal remained unchanged: that the IESG would be asked to make a process exception.

I didn't like that decision either, but this is just process. Can we move on please.

Bob

---

From: Joe Touch <[email-masked]>
Date: Sun, 3 Nov 2019 19:08:34 -0800

Why do we need this process exception?

We have 793bis in process. If we need to assign a bit in the header - to any specific use or as experimental - that seems like the appropriate venue in which to do so.

Joe

> On Nov 3, 2019, at 6:00 PM, Scharf, Michael <[email-masked]> wrote:
> 
> Bob,
>  
> Von: Bob Briscoe <mailto:[email-masked]>
> An: Scharf, Michael <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; Mirja Kuehlewind <mailto:[email-masked]>; Richard Scheffenegger <mailto:[email-masked]>
>> On 2019-9-10, at 13:50, Scharf, Michael <[email-masked]> <mailto:[email-masked]> wrote:
>     https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM <https://mailarchive.ietf.org/arch/msg/tsvwg/kUYwVJQXQfHztQzKtg7FfpSFSPM>
>     https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7 <https://datatracker.ietf.org/meeting/99/materials/slides-99-tcpm-more-accurate-ecn-feedback-in-tcp-02#page=7>
> The tcpm minutes here:
>     https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00 <https://datatracker.ietf.org/meeting/99/materials/minutes-99-tcpm-00>
> Bob Briscoe                               http://bobbriscoe.net/ <http://bobbriscoe.net/>_______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Mon, 4 Nov 2019 09:55:14 +0200

> We have 793bis in process. If we need to assign a bit in the header - to any specific use or as experimental - that seems like the appropriate venue in which to do so.

If the timelines align, that would be the obvious place to stick that assignment, agreed.

But I'm not sure the timelines do align. 793bis seems to progress at a slow-but-steady pace (I'll point out it was supposed to be done two years ago...) but it seems likely that experiments want to happen sooner.

Lars

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 08:11:46 +0000

I believe that 793bis gets more and more mature. We will need further reviews in the next months. Given that this is a -bis for an Internet Standard, there are unknowns… The tentative plan is a WGLC early 2020.

A short PS focusing just on the assignment could perhaps be finished faster than 793bis. And that approach would also not change the scope of 793bis, i.e., 793bis would only include changes with IETF consensus.

Because of that, I would slightly prefer a short dedicated PS. But 793bis would also work for me. Any formally correct solution is better than a process violation.

Michael

Von: Lars Eggert<mailto:[email-masked]>
Gesendet: Montag, 4. November 2019 08:55
An: Joe Touch<mailto:[email-masked]>
Cc: Scharf, Michael<mailto:[email-masked]>; Mirja Kühlewind<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Richard Scheffenegger<mailto:[email-masked]>; Bob Briscoe<mailto:[email-masked]>
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 4 Nov 2019 06:06:04 -0800

Slow but steady is the only way we should be modifying TCP. 

I don’t expect this “short PS” to get through faster than 793bis anyway. I.e., it’s a big leap from agreeing on process to agreeing on the solution.

Joe

> On Nov 4, 2019, at 12:11 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Von: Lars Eggert <mailto:[email-masked]>
> An: Joe Touch <mailto:[email-masked]>
> Cc: Scharf, Michael <mailto:[email-masked]>; Mirja Kühlewind <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Richard Scheffenegger <mailto:[email-masked]>; Bob Briscoe <mailto:[email-masked]>
> On 2019-11-4, at 5:08, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> But I'm not sure the timelines do align. 793bis seems to progress at a slow-but-steady pace (I'll point out it was supposed to be done two years ago....) but it seems likely that experiments want to happen sooner.
> 
> Lars
> 
> _______________________________________________
> tcpm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Nov 2019 14:10:14 +0000

Michael,

At the time, I had collected a list of possible process options, 
collected from the preceding ML discussions. I preferred including the 
AccECN assignment in RFC8311 (which was ending WGLC at that time). I do 
not recall you agreeing with me, although you are now arguing for the 
same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years 
ago) when it would have been timely to do so?

One then has to ask what new situation has arisen that makes this 
decision need to be revisited.

Bob

On 04/11/2019 02:00, Scharf, Michael wrote:
>
> Bob,
>
> With chair hat on: There was a discussion „in the room“ during IETF 99 
> and the outcome of a hum „in the room“ is documented in the minutes. 
> In TCPM, consensus is confirmed on the list so that all contributors 
> can comment. Please don’t refer to room discussions as working group 
> „decisions“.
>
> With chair hat off, I believe there was never a formal consensus 
> decision in TCPM to explicitly violate RFCs. And, anyway, the working 
> group could change past decisions, at least prior to completing a 
> WGLC. In this specific case, as individual contributor, I explicitly 
> and very strongly disagree to move forward with an invalid IANA 
> considerations section.
>
> Thanks
>
> Michael
>
> *Von: *Bob Briscoe <mailto:[email-masked]>
> *Gesendet: *Sonntag, 3. November 2019 23:04
> *An: *Scharf, Michael <mailto:[email-masked]>
> *Cc: [email-masked] <mailto:[email-masked]>; Mirja Kuehlewind 
> <mailto:[email-masked]>; Richard Scheffenegger 
> <mailto:[email-masked]>
> *Betreff: *Re: [tcpm] On allocating reserved bits in the TCP header
>
> Michael,
>
>> On 2019-9-10, at 13:50, Scharf, Michael<[email-masked]>  wrote:
> The decision on what process to use has already been made - in Jul 
> 2017 at IETF-99 (it was for the IESG to be asked to make a process 
> difference to the technical outcome. Please can we just do it the way 
> we already decided to.
>
> Altho I'm a Brit, I am not a fan of people trying to re-run a 
> referendum decision 'cos they didn't get what they wanted in the 
> previous one.
>
>
> Background
> thread with the author of RFC8311 and others, a thread on tsvwg ran 
> betw 3 to 12 Jul 17:
> This thread ends by deferring to a meeting arranged at IETF-99 during 
> AD Office Hours, at which the tcpm chairs were represented.
> The outcome of that meeting was to expect the AccECN draft to rename 
> bit 7 and assign it to itself, which would need the IESG to agree a 
> process exception. That outcome was recorded on this slide for 
> discussion in the subsequent tcpm WG meeting:
> Bob Briscoehttp://bobbriscoe.net/
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 4 Nov 2019 16:39:04 +0000

Bob,

The IETF consensus for RFC 8311 was to return the status of the bit to „reserved“ and this RFC was published by TSVWG, not by TCPM. I was not much in the loop, but I have agreed to the approach taken by RFC 8311 for the bit. The formal implications of the „reserved“ status according to RFC 8311 follow from RFC 2780, which does not foresee an IESG allocation.

I have already argued during IETF 99 for a standards track solution. By that time, this would have implied a new small PS document, not RFC8311. The other variant of using 793bis proposed by Joe has not really been realistic 2 years ago.

BTW, given the potential solution via 793bis, we are in a different situation now, no?

At the end of the day,  we need to find a solution that has strong TCPM consensus, or, better, even unanimous consensus. And, to me it sounds like a bad idea to have an IETF last call discussion about process violations for a document with possibly rather rough WG consensus, most notably regarding a change of the main TCP header that affects every single Internet device. I really suggest to think about alternatives.

Best regards

Michael

Von: Bob Briscoe<mailto:[email-masked]>
Gesendet: Montag, 4. November 2019 15:10
An: Scharf, Michael<mailto:[email-masked]>
Cc: Richard Scheffenegger<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mirja Kuehlewind<mailto:[email-masked]>
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,

At the time, I had collected a list of possible process options, collected from the preceding ML discussions. I preferred including the AccECN assignment in RFC8311 (which was ending WGLC at that time). I do not recall you agreeing with me, although you are now arguing for the same process, but with a new PS RFC.

Was the decision questioned at the time on the mailing list (2 years ago) when it would have been timely to do so?

One then has to ask what new situation has arisen that makes this decision need to be revisited.

Bob

Thanks

Michael

Michael,

Agreed.

Lars

Background

Bob

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Nov 2019 18:08:02 +0000

Michael,

You said decisions are finalized on the ML. Then when I asked whether 
the decision had been questioned on the ML at the time 2 yrs ago, you 
didn't answer.

Bob

On 04/11/2019 16:39, Scharf, Michael wrote:
>
> Bob,
>
> The IETF consensus for RFC 8311 was to return the status of the bit to 
> „reserved“ and this RFC was published by TSVWG, not by TCPM. I was not 
> much in the loop, but I have agreed to the approach taken by RFC 8311 
> for the bit. The formal implications of the „reserved“ status 
> according to RFC 8311 follow from RFC 2780, which does not foresee an 
> IESG allocation.
>
> I have already argued during IETF 99 for a standards track solution. 
> By that time, this would have implied a new small PS document, not 
> RFC8311. The other variant of using 793bis proposed by Joe has not 
> really been realistic 2 years ago.
>
> At the end of the day,  we need to find a solution that has strong 
> TCPM consensus, or, better, even unanimous consensus. And, to me it 
> sounds like a bad idea to have an IETF last call discussion about 
> process violations for a document with possibly rather rough WG 
> consensus, most notably regarding a change of the main TCP header that 
> affects every single Internet device. I really suggest to think about 
> alternatives.
>
> Best regards
>
> Michael
>
> *Gesendet: *Montag, 4. November 2019 15:10
> *Cc: *Richard Scheffenegger <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; Mirja Kuehlewind <mailto:[email-masked]>
> AccECN assignment in RFC8311 (which was ending WGLC at that time). I 
> do not recall you agreeing with me, although you are now arguing for 
> the same process, but with a new PS RFC.
>
>> With chair hat on: There was a discussion „in the room“ during IETF 
>> 99 and the outcome of a hum „in the room“ is documented in the 
>> minutes. In TCPM, consensus is confirmed on the list so that all 
>> contributors can comment. Please don’t refer to room discussions as 
>> working group „decisions“.
>>