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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 04 November 2019 18:57 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66106120120 for <tcpm@ietfa.amsl.com>; Mon, 4 Nov 2019 10:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_D3REyrhTvy for <tcpm@ietfa.amsl.com>; Mon, 4 Nov 2019 10:57:03 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13CE120019 for <tcpm@ietf.org>; Mon, 4 Nov 2019 10:57:02 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1F77D25A2A; Mon, 4 Nov 2019 19:57:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1572893821; bh=lBbcMUm1XcvG5FetfWwiAvd/pFmyfnbUZ0/nVqhMhng=; h=From:To:CC:Subject:Date:From; b=QHv6ommn8xQwOuxvooGW9TVinJKV5f47vIXFgJkYQCPz+C/pH00N7jbDz0Y23yoPK OmI/K46lhiBsm1n7lEj0C35tApWEavyD0wwNXZ38fHSIiA9bH0N/Dna8Sq65KYNdqA y6PuaQXOUN1jwaQFDBWzq/4cV80zND/xd0cjVLCA=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6h6_DdyKLWp; Mon, 4 Nov 2019 19:56:59 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 4 Nov 2019 19:56:59 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 4 Nov 2019 19:56:59 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Bob Briscoe <in@bobbriscoe.net>
CC: Richard Scheffenegger <rscheff@gmx.at>, "tcpm@ietf.org" <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
Thread-Topic: [tcpm] On allocating reserved bits in the TCP header
Thread-Index: AdWTQaKubgQDGeLVSb628zuZMsyT0A==
Content-Class: urn:content-classes:message
Date: Mon, 4 Nov 2019 18:56:58 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D4DE45E@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D4DE45Erznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/j2OLnN2bT2QG2vHLT-oeEItlgRM>
Subject: Re: [tcpm] On allocating reserved bits in the TCP header
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 18:57:06 -0000

Bob,

Whether this question has been discussed on the mailing list in the last 2 years also does not matter. The answer may be no, but why would that matter? The interest in the working group in this document has been relatively low for quite some time, as far as I can tell. And the content of documents and the consensus in a working group can change over time. And note that the document is not in WGLC.

I have already mentioned that the nearing completion of 793bis is a perfect example for a new situation, because it allows another solution that was not really realistic earlier.

And there are other new ideas such as draft-gomez-tcpm-ack-pull, which are quite recent and maybe not really well understood. Is this not a new situation that needs to be taken into account when deciding on a bit allocation? That proposal was not known during IETF 99.

I suggest to look forward instead of backward.

Best regards

Michael


Von: Bob Briscoe<mailto:in@bobbriscoe.net>
Gesendet: Montag, 4. November 2019 19:08
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: Richard Scheffenegger<mailto:rscheff@gmx.at>; tcpm@ietf.org<mailto:tcpm@ietf.org>; Mirja Kuehlewind<mailto:ietf@kuehlewind.net>
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

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.

That begs an answer to my other question:

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


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.

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:in@bobbriscoe.net>
Gesendet: Montag, 4. November 2019 15:10
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: Richard Scheffenegger<mailto:rscheff@gmx.at>; tcpm@ietf.org<mailto:tcpm@ietf.org>; Mirja Kuehlewind<mailto:ietf@kuehlewind.net>
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
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:in@bobbriscoe.net>
Gesendet: Sonntag, 3. November 2019 23:04
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: tcpm@ietf.org<mailto:tcpm@ietf.org>; Mirja Kuehlewind<mailto:ietf@kuehlewind.net>; Richard Scheffenegger<mailto:rscheff@gmx.at>
Betreff: Re: [tcpm] On allocating reserved bits in the TCP header

Michael,
On 03/10/2019 12:31, Lars Eggert wrote:

On 2019-9-10, at 13:50, Scharf, Michael <Michael.Scharf@hs-esslingen.de><mailto:Michael.Scharf@hs-esslingen.de> wrote:

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.

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/



_______________________________________________

tcpm mailing list

tcpm@ietf.org<mailto:tcpm@ietf.org>

https://www.ietf.org/mailman/listinfo/tcpm



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/