From nobody Mon Jan 4 21:51:54 2021 Return-Path: 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 21E033A1031; Mon, 4 Jan 2021 21:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 byHjceOATwzn; Mon, 4 Jan 2021 21:51:51 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C542E3A102E; Mon, 4 Jan 2021 21:51:50 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id w79so25635768qkb.5; Mon, 04 Jan 2021 21:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RAF6Zl6wwaPhK4b14x00ObV4H4qzmusrZzlHzeW6Lvk=; b=JdThoxsqSU/oVLth7Qizu2jf4MDT14pfFyGOsixy0riIKDnhEnSEMgafvn/GjWAbTc jI1jfDic4JjSmWrGqOZst/rwDO83wo7ed4TOaefgfqgal1NRhcMgYNAkuRjOXyCM1FM1 NCsX0DHZYp0ICdsWaTbq77KoTmzwlbDPYeAhvoSGFgi7Nazcg90wXalBPbKzXakBYV/B oufSles5maYz465qfHMdXqxxIfYlMjTTCOb5YCury16N8oY13Orvivrv8HyKdYYdWOaQ eZPIiyHP+PhvkxetXjTMobW1qei/CklmL8qc2k7saici160niOhlLSEvyxTA4B31yty0 uHVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RAF6Zl6wwaPhK4b14x00ObV4H4qzmusrZzlHzeW6Lvk=; b=GMn+UQaeJH59NZB554j4raI2V8G882Nx9Mg4TyWOq6y9FrN0iiYoSQ3Lor2p4w85Hg rBaaFMt6t9ekjJ0/IUMf2CTUHPj6Ql1OlO/zHWP/oHHx3U0tJ+Ia3q98D4SdNxjfQTbd oSSjOliyfCvOcNuaTdvaInRxTrIKjHB7JaLWujVzCToWgHP3nUDTA0V/wVD9tfTZI4Tz jO1IYSAUy8k7DuB6HYkkNSrIMOJPVjwSeHvuDm8uZoRarftv7Pg/ugmFltRMfhm8a0EB NloUrTt/kAIm7B2M9M8LBzL8uvC7x4tCgY76Mqn9wGWWNX32pfXfKOnHvwIPSvMksarE 6Bcw== X-Gm-Message-State: AOAM532AXAB0FryJyWtfiTxShNXFumJGnRld6FA5WEN2wONAw7zSQ6Dg h9GucoLQEabJu4HH1SzxJBMVnCbkMQDYzfR0UbrdJT8m X-Google-Smtp-Source: ABdhPJysl6+7KVceMjSanP3clmQz8v5J7Lnga5WXueZ3jpbvPqF1yjaNI8E0nTzZViGo0tG2e1e36xbYygbFre/WDvg= X-Received: by 2002:a05:620a:1279:: with SMTP id b25mr74273948qkl.8.1609825909482; Mon, 04 Jan 2021 21:51:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 4 Jan 2021 21:51:38 -0800 Message-ID: To: tcpm IETF list Cc: tcpm-chairs Content-Type: multipart/alternative; boundary="0000000000007c292505b820cdbf" Archived-At: Subject: Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 05:51:53 -0000 --0000000000007c292505b820cdbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Happy new year everyone, Sorry for taking long time. Based on the feedback we've received, we've concluded the rough consensus of the WG is that this document should be adopted as a WG item for a PS document. So, after some discussions with the authors, we plan to set the following milestone for this draft. Aug 2021 Submit document on RFC6937bis to IESG for publication as a Proposed Standard RFC We appreciate your cooperations! Please let us know you have any questions or comments . -- Yoshi on behalf of tcpm co-chairs On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida wrote: > Hi folks, > > This mail starts a WG adoption call for RFC6937bis draft. > As we've already seen positive supports for this work, we are not asking > people who already expressed their opinions this time. (but, if you want = to > do it for some reason, please go ahead) > However, if you haven't done it yet, especially if you're against it, we > would like to encourage you to provide feedback. > > We are thinking that the intended status of the doc will be PS based on > the feedback we've seen so far. But, if you have opinions on it, please l= et > us know. > > Thank you so much, > -- > Yoshi on behalf of tcpm co-chairs > > > On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis 40google.com@dmarc.ietf.org> wrote: > >> The authors of PRR would like to update PRR to Proposed Standard status. >> This entails introducing a new document as an tcpm work item. >> >> *Please indicate (non) support and/or comment.* >> >> For more details see the tcpm meeting materials from IETF 109 >> minutes: >> https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-00 >> slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 >> >> There were about four "I support this work" remarks at the mic (not >> recorded in the minutes), and about as many in the Meetecho chat. >> >> Abridged IETF/tcpm/PRRbis slides: >> -- >> PRR recap (RFC6937 experimental) >> PRR is a special congestion control effective only during fast recovery >> >> - When inflight >=3D ssthresh, send at loss_beta*rate_before_loss (e.= g. >> loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cubic) >> - When inflight < ssthresh, send at the same or twice the >> delivery_rate (more later) >> - Used by all congestion control modules in Linux during fast recover= y >> - Can be more dominant than the actual C.C. for lossy flows >> that=E2=80=99re in fast recovery constantly (e.g. video streaming = through policers) >> >> -- >> Current Status >> >> - >> >> PRR is widely deployed >> - >> >> At least three major OSs: Linux, Windows, (NetFlix) BSD >> - >> >> Vast majority of Web traffic for years >> - >> >> No changes to algorithms published in RFC 6937 >> - >> >> PRR-CRB - Conservative Reduction Bound - strict packet conversion >> during loss recovery >> - >> >> PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK >> during loss recovery >> - >> >> 2015 Heuristic to dynamically select which reduction bound >> - >> >> Only use PRR-SSRB when making good forward progress >> - >> >> ACKs that advanced snd.una and report no new losses >> - >> >> Resolves some pathological cases with token bucket policers >> - >> >> CC estimates ssthresh before it can possibly measure the token >> rate >> - >> >> The heuristic makes the best of a bad situation >> >> -- >> Tentative path forward >> >> - >> >> Adopt as a tcpm work item >> - >> >> Update the text >> - >> >> Normative RFC 2119 language >> - >> >> Add MAY use the heuristic... >> - >> >> Trim redundant and obsolete language >> - >> >> RFC 6937 repeats itself and is much longer than necessary >> - >> >> Focus on what an implementer needs to know >> - >> >> Use non-normative references to RFC 6937 for prior measurement >> work, etc >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> We must not tolerate intolerance; >> however our response must be carefully measured: >> too strong would be hypocritical and risks spiraling out of >> control; >> too weak risks being mistaken for tacit approval. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > --0000000000007c292505b820cdbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happy new year everyone,
<= br>
Sorry for taking long time.=C2= =A0
Based on the feedback we'v= e received, we've concluded the rough consensus of the WG is that this = document should be adopted as a WG item for a PS document.
So, after some discussions with the authors, we plan to set the following = milestone for this draft.

=C2=A0 =C2=A0Aug 2021=C2= =A0 =C2=A0 =C2=A0Submit document on RFC6937bis to IESG for publication as a= Proposed Standard RFC

We appreciate your coop= erations!=C2=A0
Please let us know you have any questions or comm= ents .
--
=
Yoshi on behalf of tcpm co-chairs
=

On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida <nsd.ietf@gmail.com>= wrote:
Hi folks,

This mail starts a WG adop= tion call for RFC6937bis draft.
As we've already seen positiv= e supports for this work, we are not asking people who already expressed th= eir opinions this time. (but, if you want to do it for some reason, please = go ahead)=C2=A0
However, if you haven't done it yet, especial= ly if you're against it, we would like to encourage you to provide feed= back.

We are thinking that the intended status of = the doc will be PS based on the feedback we've seen so far. But, if you= have opinions on it, please let us know.

Thank yo= u so much,
--
Yoshi on behalf of tcpm co-chairs


On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis <mattmathis=3D40google.com@dmar= c.ietf.org> wrote:
The authors of PRR= would like to update PRR to Proposed Standard status.=C2=A0 This entails i= ntroducing a new document as an tcpm work item.

Please indic= ate (non) support and/or comment.

For more details see the = tcpm meeting materials from IETF 109
slides:=C2=A0https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00

There were about four "I support this work&= quot; remarks at the mic (not recorded in the minutes), and about as many i= n the Meetecho chat.

Abrid= ged IETF/tcpm/PRRbis slides:
--
PRR =C2=A0recap (RFC6937 experimenta= l)
PRR is a special congestion= control effective only during fast recovery
  • When inflight >=3D ssthresh, send at loss_beta*rate_before_= loss (e.g. loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cubic)
  • When inflight < ssthresh, send at t= he same or twice the delivery_rate (more later)
  • Used by all congestion control modules in Linux during fast re= covery
    • Can be more dominant than= the actual C.C. for lossy flows that=E2=80=99re in fast recovery constantl= y (e.g. video streaming through policers)
--
Current Status
=

  • PRR is widely deployed

    • At least thr= ee major OSs: Linux, Windows, (NetFlix) BSD

    • Vast majority of Web traffic for years

  • No changes to algorithms published in RFC 6937

    • = PRR-CRB - Conservative Reduction Bound - strict packet conversion during lo= ss recovery=C2=A0

    • PRR-SSRB - Slowst= art Reduction Bound - one extra segment per ACK during loss recovery=

  • 2015 Heuristic to dynamically select w= hich reduction bound

    • Only use PRR-SSRB when making good forward= progress

        • ACKs that advanced snd.una and report no new losses

    • Resolves some pathological case= s with token bucket policers

      • CC estimates ssthresh before it ca= n possibly measure the token rate

      • = The heuristic makes the best of a bad situation

    --
Tentative path = forward= =C2=A0

  • Adopt as a tcpm work item

  • Update the text

    • Normati= ve RFC 2119 language

    • Add MAY use the heuristic...

    • Trim redundant and obsolete language

      =

      • RFC 6937 repeats itself and is much longer than= necessary

      • = Focus on what an implementer needs to know

      • Use non-normative references to RFC 6937 f= or prior measurement work, etc

=
Thanks,
--MM--
The best way to predict the future is to create it. = =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our = response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypo= critical and risks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being= mistaken for tacit approval.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000007c292505b820cdbf-- From nobody Wed Jan 6 10:29:56 2021 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E473A0FCE; Wed, 6 Jan 2021 10:29:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <160995779438.13112.11737211968348652656@ietfa.amsl.com> Date: Wed, 06 Jan 2021 10:29:54 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-hystartplusplus-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 18:29:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : HyStart++: Modified Slow Start for TCP Authors : Praveen Balasubramanian Yi Huang Matt Olson Filename : draft-ietf-tcpm-hystartplusplus-01.txt Pages : 8 Date : 2021-01-06 Abstract: This doument describes HyStart++, a simple modification to the slow start phase of TCP congestion control algorithms. Traditional slow start can cause overshotting of the ideal send rate and cause large packet loss within a round-trip time which results in poor performance. HyStart++ combines the use of one variant of HyStart and Limited Slow Start (LSS) to prevent overshooting of the ideal sending rate, while also mitigating poor performance which can result from false positives when HyStart is used alone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-hystartplusplus-01 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-hystartplusplus-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 6 12:26:41 2021 Return-Path: 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 A97F23A1107 for ; Wed, 6 Jan 2021 12:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=5jtA/pu/; dkim=pass (2048-bit key) header.d=wizmail.org header.b=Niz4M+pM 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 AxqGjlMG3q4n for ; Wed, 6 Jan 2021 12:26:37 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87F73A109C for ; Wed, 6 Jan 2021 12:26:36 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:To:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=ODuCY1uZY2PKmcXsWzGp5nZep2yL2PpPpWtk31g+P3c=; b=5jtA/pu/iBgI1/Ykrxnum5T0PD E0+nPpAGd/K8Wbzeiv1WqkKBp18HWit3zxV0jshcvk18OKAO9gDBUjY6KUDQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:To:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=ODuCY1uZY2PKmcXsWzGp5nZep2yL2PpPpWtk31g+P3c=; b=Niz4M+pM3fVtYdvIhrDIz6f9K2 MGZSVBjWuePOHCOz/4DUyE5EVX/KiSIzyBwgw6TyDX6YJf9UML0Fm4k4HtclpKqE99P78ULDhvXal qDv/XNJ9ACR/X+W56f97eqvsqqsG7LVM5F4a6CryQWzfemYxv6D0poVStuRL0dpBbkncWrB016pHJ D6O7myQ3BKyqo4epYX+IU0EO/PNol4BCIwWfaWjrQEopEo3oTCZyhB1pzd7ppapHnwlYOXXN4kOjY m8R8JlNxbU9rtUoK/hZDcsef4X0KaVUIwMRNfKDgYPg+s6y4ftcVt097TPlxoKGEocMI/uZVVjXyk tXgEQoRQ==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.110) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1kxFO6-00AXac-O7 for tcpm@ietf.org (return-path ); Wed, 06 Jan 2021 20:26:34 +0000 To: tcpm@ietf.org References: <160995779438.13112.11737211968348652656@ietfa.amsl.com> From: Jeremy Harris Message-ID: Date: Wed, 6 Jan 2021 20:26:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <160995779438.13112.11737211968348652656@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-hystartplusplus-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 20:26:40 -0000 On 06/01/2021 18:29, internet-drafts@ietf.org wrote: > Filename : draft-ietf-tcpm-hystartplusplus-01.txt > Abstract: > can cause overshotting of the ideal send rate Perhaps a typo for "overshooting"? Suggest just "overshoot". Section 1 para 2: > [HyStart]. After the HyStart delay algorithm finds an exit point, > LSS is used in conjunction with congestion avoidance for further It's unfortunate that "LSS" was expanded in the Abstract. Readers who dive straight into the content, expecting it to be complete, will be confused. > LSS is used in conjunction with congestion avoidance for further > congestion window increases until the first packet loss is detected Which congestion-avoidance algorithms are expected to operate in conjunction with LSS? Section 4.2: - appears to be describing the delay-increase detection, which has already been incorporated by reference to the original HyStart. Avoid duplication. - also describes the LSS algorithm, which was incorporated by ref. from RFC 3742. Section 4.3 - Perhaps LOW_CWD should be defined as a factor of IW, given the discussion of the effects of altering it? - MIN,MAX_RTT_THRESH could be renamed MIN,MAX_RTT_DELTA_THRESH. I at first thought that 16ms was unusable for a sat-link, until I realised it was a bound on the *increase* in RTT. -- Cheers, Jeremy From nobody Tue Jan 12 00:03:54 2021 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6FF3A08F4; Tue, 12 Jan 2021 00:03:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: martin.h.duke@gmail.com, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161043863133.17580.15024777506966189593@ietfa.amsl.com> Date: Tue, 12 Jan 2021 00:03:51 -0800 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 110 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 08:03:52 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Technology Overlap: tsvwg quic taps tsvarea iccrg panrg webtrans masque Key Participant Conflict: netconf People who must be present: Yoshifumi Nishida Michael Tuexen Martin Duke Michael Scharf Resources Requested: Special Requests: Please avoid Tuesday (March 9) --------------------------------------------------------- From nobody Wed Jan 13 23:18:50 2021 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D823A11E8; Wed, 13 Jan 2021 23:18:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161060871994.10783.1247396842504892132@ietfa.amsl.com> Date: Wed, 13 Jan 2021 23:18:40 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-prr-rfc6937bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 07:18:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Proportional Rate Reduction for TCP Authors : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-prr-rfc6937bis-00.txt Pages : 19 Date : 2021-01-13 Abstract: This document updates the Proportional Rate Reduction (PRR) algorithm described as experimental in RFC 6937 to standards track. PRR potentially replaces the Fast Recovery and Rate-Halving algorithms. All of these algorithms regulate the amount of data sent by TCP or other transport protocol during loss recovery. PRR more accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the ssthresh, as determined by the congestion control algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-prr-rfc6937bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-prr-rfc6937bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 10:02:31 2021 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A338D3A0A3B; Thu, 21 Jan 2021 10:02:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <161125214660.14673.13772128499350392436@ietfa.amsl.com> Date: Thu, 21 Jan 2021 10:02:26 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-20.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 18:02:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : Transmission Control Protocol (TCP) Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-20.txt Pages : 110 Date : 2021-01-21 Abstract: This document specifies the Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet protocol stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-20 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 10:48:35 2021 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF23A0928 for ; Thu, 21 Jan 2021 10:48:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161125491445.14644.11465054796424884513@ietfa.amsl.com> Date: Thu, 21 Jan 2021 10:48:34 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 18:48:34 -0000 Changed milestone "Submit a document on modifying slow start to avoid large tail drops as a Proposed Standard RFC", set due date to November 2021 from May 2021. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Fri Jan 22 08:07:41 2021 Return-Path: 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 CB3603A1260 for ; Fri, 22 Jan 2021 03:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5rpxe-rsY_Q4 for ; Fri, 22 Jan 2021 03:32:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E3B3A0E00 for ; Fri, 22 Jan 2021 03:32:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D6F0BF4071E; Fri, 22 Jan 2021 03:31:45 -0800 (PST) To: touch@isi.edu, mankin@psg.com, rbonica@juniper.net, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: ananth.nantha@yahoo.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210122113145.D6F0BF4071E@rfc-editor.org> Date: Fri, 22 Jan 2021 03:31:45 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 22 Jan 2021 08:07:40 -0800 Subject: [tcpm] [Editorial Errata Reported] RFC5925 (6406) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 11:32:06 -0000 The following errata report has been submitted for RFC5925, "The TCP Authentication Option". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6406 -------------------------------------- Type: Editorial Reported by: Ananth Rajadurai Section: Section 5.1 Original Text ------------- In Section 5.1, Figure 6 - TCP IPv6 Pseudoheader +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero | Next Header | +--------+--------+--------+--------+ Corrected Text -------------- +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero |Next Hdr| +--------+--------+--------+--------+ Notes ----- In IPv6 pseudoheader, Zero field should be 3 bytes and Next header should be 1 byte. But in RFC 5925, figure 6, it misleads into Zero field 2 bytes and Next header 2 bytes. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) -------------------------------------- Title : The TCP Authentication Option Publication Date : June 2010 Author(s) : J. Touch, A. Mankin, R. Bonica Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Sat Jan 23 08:26:58 2021 Return-Path: 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 BF55C3A134D for ; Fri, 22 Jan 2021 09:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=D94cbjV9; dkim=pass (1024-bit key) header.d=juniper.net header.b=cnpZ91qd 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 mRIY3rbrd5OQ for ; Fri, 22 Jan 2021 09:33:01 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35123A133B for ; Fri, 22 Jan 2021 09:33:00 -0800 (PST) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10MHErdU014667; Fri, 22 Jan 2021 09:32:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=agrqAIVtxRGh0ST6gQx/B1bXdogq+obIYHLeQxP6nFA=; b=D94cbjV9v2R8fKTPWlFVH+Z8NJcNFQ1ESmvKi1+NJaPby+fr1OPmWs+aq0qklq353vcy IJ8RMCOX4yV/JZ3VqWW3db/vI5wej8LVLGfw7Qvf6DrnRvItBSAXupXWYK1I9qxr6vuc hKDI7eGhNkagqxvo3sQhiKcBGKXrn/sUpA3yS6s53RXtcQrLxX67pAQFbXEG7HAnvG4K i7lBcanszCGUP/ss7XPO2Q+niXftNPPshdYpXQTG8WYMrFQYg7ctukVd7orkNI21irau 9QocuWTEhf7cU6rjGm7sVT0KYZIvr5N/IxJInKO5Eu4XmE7w23Q7lqU2/6yFFy8kujz2 7A== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2174.outbound.protection.outlook.com [104.47.55.174]) by mx0b-00273201.pphosted.com with ESMTP id 367mtwhcg0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Jan 2021 09:32:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eVJo/zRNu+n5RszkUoAris8CaYQ7V2pZP3aTrsIrXnf4Oa0E4Gw3n7+4stUnL3iK/nybcFyeA54V9U+MBjk5pUjHYJKrMBqzGkSwzSKO3g5YJBGJJIFbxIhQ4dlVKngP1m9W1HoRidEOmT5b7y0XaQxGdcVlfLJO37r8ym0+TyWmImvzWPBfP+sB6zlg3hxfskyDLjuzESqCtVNRxMJhxNYggQp9m2ns2WcNVUcZ+wMud/Ew+YmDVGbpOMseW4ZMMpH//Ms7pEbUtuWd2/dABywhdmlroLJQiXMxiQ/vJIvDtwdpZNA+b319OgKbw6r4XseYu1ZWB68SsJ0/mT5Apg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=agrqAIVtxRGh0ST6gQx/B1bXdogq+obIYHLeQxP6nFA=; b=g1BgvC0BcqJhW8hInGusVmQx0v1ctUnZUmih82lxCX7je0pcwPJNevw3LhSOdZXTXkDQUxLg9SFFxoWP6vNwxsdJJyS8P7Yw0b0RxCAMPh6HyQAW6THjbvxGwo6uwLgRu712NjntULdZWBQ99gf6Oq83yudkK8YlCe0U1zgfYTCUqoBxPzzxFp9GnTnHJKhmePxdk5/oejCzpfhmqpISs90MUonQ26J+/4zLYylFFo0k7w8Fh2DEyuWq2/3eGu8kd0mQYbfDj8GEh75YU9Lvwax0jbBI5oxteZYbFeCNoTyjmN+Z4RXALUuKeb/TjOIGpSq/cK+wr+/U3fkUhgG5QQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=agrqAIVtxRGh0ST6gQx/B1bXdogq+obIYHLeQxP6nFA=; b=cnpZ91qdsd0zUwhdTZlNV7kXYynTLMgOjdVAXomYkF102ArELhgIRPBC/PlFaEvxpXMttLJj2gv3Gf0C2vhUUlxK9B3qdXWExgtyvgEbEjyWMKmBbk8rQ2+rKOo8Uf93p36rmn2RqnB85KWAvGTOEtNtuTZ7Kx+cH5/IW5me2AQ= Received: from (2603:10b6:208:2f::25) by BL0PR05MB4931.namprd05.prod.outlook.com (2603:10b6:208:5c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.10; Fri, 22 Jan 2021 17:32:47 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::24d3:61f2:4293:e825]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::24d3:61f2:4293:e825%3]) with mapi id 15.20.3805.006; Fri, 22 Jan 2021 17:32:47 +0000 From: Ron Bonica To: RFC Errata System , "touch@isi.edu" , "mankin@psg.com" , "martin.h.duke@gmail.com" , "magnus.westerlund@ericsson.com" , "michael.scharf@hs-esslingen.de" , "tuexen@fh-muenster.de" , "nsd.ietf@gmail.com" CC: "ananth.nantha@yahoo.com" , "tcpm@ietf.org" Thread-Topic: [Editorial Errata Reported] RFC5925 (6406) Thread-Index: AQHW8LI43CW5HtlNzUC24ezWlb0FrKoz56OA Date: Fri, 22 Jan 2021 17:32:47 +0000 Message-ID: References: <20210122113145.D6F0BF4071E@rfc-editor.org> In-Reply-To: <20210122113145.D6F0BF4071E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-01-22T17:32:46Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5818febf-a18f-484b-9bfd-24fa091beff5; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: rfc-editor.org; dkim=none (message not signed) header.d=none; rfc-editor.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ecb30fbb-e067-42d6-a651-08d8befbbc08 x-ms-traffictypediagnostic: BL0PR05MB4931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xp3wqdRD7+pw27A1m3dTuaRX1cGvhhwLiFqv1kLQHF/pgoq5k1mfgcCmGXwPEmE/XPta0qbWZUOsDe0ESJynWVOkb3ZtK38ZSiqcc4y2HLQXMDhWW4MoFdeYVfxNeMEKe41KXqD0vTekOl/layoZZKNso15TPMtFd2Ghc5HQ8RvSZ2GGT9xx1VMxwOCliTTck/MBQMJ4vB9CKTArQ05Ta1C3TsJn0HXIml8dY/ZdG1wUzizZhzPAa//QIjdKkh1P1bouf2c7J1iPUDreTkx01OIt6M71O4s+34h59PLHVSDRIPVY81NKN1KRCGUMcrT0NJDsM8f4xsdzTVmSOUZRPka2BtHdUJPkRQCR0ELNSQdVcjjk0X1rZmcHpf12dtgNuuVdJqUqmWrC8iUatI+ppXcOzg1JJ3pSjU0kgtOguXzHTYAVISwz0msvSdwFu58n/l+I9H3LQvQMu05ZGde5sQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(376002)(39860400002)(346002)(478600001)(316002)(7696005)(966005)(33656002)(110136005)(5660300002)(83380400001)(9686003)(71200400001)(66946007)(86362001)(64756008)(54906003)(6506007)(8676002)(66476007)(66556008)(4326008)(53546011)(52536014)(186003)(8936002)(66446008)(76116006)(55016002)(2906002)(26005)(7416002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?WlRUcGdDbytSSnl2aWh6SkdabHErN1pDSHIwd2dxaHFSRGdGMlo0a2hXYnVI?= =?utf-8?B?eGJCWk8yZmRtZUxVbHVRRy84NkNRUWVaWkFKNkxnTlE5RTNCR1NBaXVaQmVi?= =?utf-8?B?TytDRVcxZHJ1SGM4eExwaWQva2YvczZmR2hCNS81aVF1MVFjcytuY0N3N1lO?= =?utf-8?B?L2dienlFMU9WbXdNZnhuY2J6WVNLQXdpbWhXRlFJQjk5aDZUMSs1bHFRclNz?= =?utf-8?B?alVlc1JtSitWOXV2bGMwUE1ldkhvR3QvenR5aDNOWmZVamgyVkxYakd6bjRE?= =?utf-8?B?ME4wVUVncFlhWXlWUnFheGhidGdkbTZMSXJjNUtqajVoUTZ6azRvbjR4dUtB?= =?utf-8?B?MjIrS1lWN1pTdDQ0R282Q0g3OFNQVW9IWW1LZnB6Mk5wWXI0ZlhKbXJZWkZ3?= =?utf-8?B?c2hVNXhyUVhabHJSTVdwcWx6b0lXMjViVUN1Nis5UmJtaVE2R1VWT2RTTkRU?= =?utf-8?B?MGJyRG9oZXMvbTZLdjcrUE1RQ3FFeTJTLzRMQ29qUUtxczQrRVlwNk9XNmxE?= =?utf-8?B?WFpVdEVyRW01ZlVpYjl2VHZ6RXVkeUN5VHJLVFlTNWYyVU1UUmphOVRmYXNs?= =?utf-8?B?V05XWFRvWjJyNXVHdkJ2Wkx6b1dzL2M2VGRJaElkRUVzYTRqeGczSmZjWjk0?= =?utf-8?B?R04vNm00T3ErUlppVzdjVit5RlY4K21WaVpNU2RSOFNLL3I2Z2grdkxBODdH?= =?utf-8?B?TmRCdHM5a25JOVNvT3p4MGM4ckQyVXpBOFdqdVFZcmIwTE5mNkZDTy9LM1gr?= =?utf-8?B?M2RkOVN5blE1YUFYR1JybU40YXFzY256OHlIVHcxdjZFNlBZQVVCc0JidnRR?= =?utf-8?B?SEtzS0lsclJVUlc3REJJTU1yZjFTTDhlVTZRQWYxWmxpM0tkUWhtRnVUSmVB?= =?utf-8?B?ZFlKc2Q1MkNacjlpbW5WR0dYRW16TEd0UW9XZGNDeTBtZTJaS2MvY2NZems5?= =?utf-8?B?QWxwSnJRSkxid2pBYzNFdmxwSHZEL0Ivc3RHSkd3M1dJbFh6cGtoM1hpd0xw?= =?utf-8?B?SzkvUm1UNnJNZVY4cUpqTmN1KzJOSlh3U1kzaldDQ1g1N09tK08veWhyQ3Iz?= =?utf-8?B?MzkySUxwbVZVeFVLWTVLY3k4c3N3cnpYbkF6dHphZXZEMFk5NVA1MmNvVURT?= =?utf-8?B?TS81WExWTmM3UWIzZ0ZPR1VsSUxmTU9XZ3BWeERXY3JISlhhdGdiazE1VUk5?= =?utf-8?B?OWNFODRLbGVCRGp4U2toUjNtbXlxRVpid0RsREtrcTRUVWVjckRJOTFtbkVS?= =?utf-8?B?Q2VZV2lPNDZtc0pyNWhtWit5NHkxTmxra1FOLzN6ME1nMFZia2ZMNjh3d1Rr?= =?utf-8?B?TmQ4WEQrVXo4aWNELzllTnRpeXU2VTk4TkFtcHJ5eWZMVnhsNmN0NFlOZW4v?= =?utf-8?B?N0k3NTFoQXRlc2g0VnhkZG00TW1laE9aeHdJdFFsTXp0QjBTS3hzOTNyNE04?= =?utf-8?Q?t/t1VDIv?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecb30fbb-e067-42d6-a651-08d8befbbc08 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2021 17:32:47.2588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qap6AEZ9wq2AnqQOsnwamat1wMxSF/vH8a1bmQ96pmnln4DOkqMyF/QtZ86vBsloeuYBvib9VO0vySFxkBhmRg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4931 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-22_13:2021-01-22, 2021-01-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 spamscore=0 impostorscore=0 phishscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101220091 Archived-At: X-Mailman-Approved-At: Sat, 23 Jan 2021 08:26:57 -0800 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (6406) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 17:33:03 -0000 R29vZCBjYXRjaCEgSSBhZ3JlZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoN Cg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBSRkMgRXJyYXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4g DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjIsIDIwMjEgNjozMiBBTQ0KVG86IHRvdWNoQGlzaS5l ZHU7IG1hbmtpbkBwc2cuY29tOyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PjsgbWFy dGluLmguZHVrZUBnbWFpbC5jb207IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTsgbWlj aGFlbC5zY2hhcmZAaHMtZXNzbGluZ2VuLmRlOyB0dWV4ZW5AZmgtbXVlbnN0ZXIuZGU7IG5zZC5p ZXRmQGdtYWlsLmNvbQ0KQ2M6IGFuYW50aC5uYW50aGFAeWFob28uY29tOyB0Y3BtQGlldGYub3Jn OyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQpTdWJqZWN0OiBbRWRpdG9yaWFsIEVycmF0YSBS ZXBvcnRlZF0gUkZDNTkyNSAoNjQwNikNCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBv ZiBjb250ZW50XQ0KDQoNClRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBzdWJt aXR0ZWQgZm9yIFJGQzU5MjUsICJUaGUgVENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbiIuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUg cmVwb3J0IGJlbG93IGFuZCBhdDoNCmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov L3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjQwNl9fOyEhTkV0NnlNYU8tZ2shVFBidXRv RE02ZW05S0ttNS1zemJ2LVJ6QXZZVmNMWU5OM09wRGZJRnpQV0hhVHVFWjNBYW4xOVVfUE13ZGl4 cyQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClR5cGU6IEVkaXRv cmlhbA0KUmVwb3J0ZWQgYnk6IEFuYW50aCBSYWphZHVyYWkgPGFuYW50aC5uYW50aGFAeWFob28u Y29tPg0KDQpTZWN0aW9uOiBTZWN0aW9uIDUuMQ0KDQpPcmlnaW5hbCBUZXh0DQotLS0tLS0tLS0t LS0tDQpJbiBTZWN0aW9uIDUuMSwgRmlndXJlIDYgLSBUQ1AgSVB2NiBQc2V1ZG9oZWFkZXINCg0K Ky0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKw0KfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Kw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICBTb3Vy Y2UgQWRkcmVzcyAgICAgICAgICAgKw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKw0KKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKw0KfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKyAgICAg ICAgRGVzdGluYXRpb24gQWRkcmVzcyAgICAgICAgKw0KfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKy0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0tKw0KfCAgICAgIFVwcGVyLUxheWVyIFBheWxvYWQgTGVuZ3RoICAgfA0K Ky0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKw0KfCAgICAgIFplcm8gICAgICAg fCAgICBOZXh0IEhlYWRlciAgfA0KKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t Kw0KDQpDb3JyZWN0ZWQgVGV4dA0KLS0tLS0tLS0tLS0tLS0NCistLS0tLS0tLSstLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCnwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgU291cmNlIEFkZHJlc3MgICAgICAgICAg ICsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCistLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCnwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgIERlc3RpbmF0aW9uIEFkZHJl c3MgICAgICAgICsNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCnwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCistLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSsNCnwg ICAgICBVcHBlci1MYXllciBQYXlsb2FkIExlbmd0aCAgIHwNCistLS0tLS0tLSstLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tLSsNCnwgICAgICAgICAgICBaZXJvICAgICAgICAgIHxOZXh0IEhkcnwN CistLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSsNCg0KTm90ZXMNCi0tLS0tDQpJ biBJUHY2IHBzZXVkb2hlYWRlciwgIFplcm8gZmllbGQgc2hvdWxkIGJlIDMgYnl0ZXMgYW5kIE5l eHQgaGVhZGVyIHNob3VsZCBiZSAxIGJ5dGUuDQpCdXQgaW4gUkZDIDU5MjUsIGZpZ3VyZSA2LCBp dCBtaXNsZWFkcyBpbnRvIFplcm8gZmllbGQgMiBieXRlcyBhbmQgTmV4dCBoZWFkZXIgMiBieXRl cy4NCg0KSW5zdHJ1Y3Rpb25zOg0KLS0tLS0tLS0tLS0tLQ0KVGhpcyBlcnJhdHVtIGlzIGN1cnJl bnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UgdXNlICJSZXBs eSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUgdmVyaWZpZWQgb3IgcmVqZWN0 ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IGNhbiBs b2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNz YXJ5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUkZDNTkyNSAo ZHJhZnQtaWV0Zi10Y3BtLXRjcC1hdXRoLW9wdC0xMSkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogVGhlIFRDUCBBdXRoZW50aWNh dGlvbiBPcHRpb24NClB1YmxpY2F0aW9uIERhdGUgICAgOiBKdW5lIDIwMTANCkF1dGhvcihzKSAg ICAgICAgICAgOiBKLiBUb3VjaCwgQS4gTWFua2luLCBSLiBCb25pY2ENCkNhdGVnb3J5ICAgICAg ICAgICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KU291cmNlICAgICAgICAgICAgICA6IFRDUCBNYWlu dGVuYW5jZSBhbmQgTWlub3IgRXh0ZW5zaW9ucw0KQXJlYSAgICAgICAgICAgICAgICA6IFRyYW5z cG9ydA0KU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNClZlcmlmeWluZyBQYXJ0eSAgICAgOiBJ RVNHDQo= From nobody Sat Jan 23 08:27:03 2021 Return-Path: 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 AB5153A12D0 for ; Fri, 22 Jan 2021 09:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 e-9B3yjMnJaK for ; Fri, 22 Jan 2021 09:46:39 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D37E3A12CE for ; Fri, 22 Jan 2021 09:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Sr5wCj8nzXz950L5b9X3tuaXDHnVIS65ILgZufheaEs=; b=TCk3OWHs401MaqLJdLPM/4oLI xXJg4ADmL7guBS12c/C0+FoUlJ8ktHNcBB8hJpPOmKXFe4f4bXfzGEchRD1BbN9B3TlTSXZye4wf/ 0gx5lqgKck57zwa3JqVfP3y6fb199HplLQCM3fIjEbs/G26+yAiebxOEnglSDo9mHV8XJlvGpCSgv 75KXGC5i3lw7y5Fg/V18AmZ9vlN5bRPWmE49FxxijSSx5ySY/sxIdpLcljJc/l12a0J4AzrCr2bp0 C+sisckwIf8/Z+em+HBwOErR8gkRdEq8bMjWYhn7TGd4nCUCN2GuusNw1HmxDp85ZgY6cNRoXDpZt n5K8N5EOQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59531 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l30Vz-000maK-Tq; Fri, 22 Jan 2021 12:46:37 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <20210122113145.D6F0BF4071E@rfc-editor.org> Date: Fri, 22 Jan 2021 09:46:30 -0800 Cc: "Dr. Joe Touch" , Allison Mankin , Ron Bonica , Martin Duke , Magnus Westerlund , michael.scharf@hs-esslingen.de, Michael Tuexen , nsd.ietf@gmail.com, tcpm@ietf.org, ananth.nantha@yahoo.com Content-Transfer-Encoding: quoted-printable Message-Id: <8682BE0E-BF90-4CBD-B4F5-5633FFA74549@strayalpha.com> References: <20210122113145.D6F0BF4071E@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Sat, 23 Jan 2021 08:26:57 -0800 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5925 (6406) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 17:46:41 -0000 Hi, all, This report is correct. Recommend =E2=80=9Chold for doc update=E2=80=9D = as the figure is not used as normatively and the corresponding text = description is correct. Joe > On Jan 22, 2021, at 3:31 AM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC5925, > "The TCP Authentication Option". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6406 >=20 > -------------------------------------- > Type: Editorial > Reported by: Ananth Rajadurai >=20 > Section: Section 5.1 >=20 > Original Text > ------------- > In Section 5.1, Figure 6 - TCP IPv6 Pseudoheader >=20 > +--------+--------+--------+--------+ > | | > + + > | | > + Source Address + > | | > + + > | | > + + > +--------+--------+--------+--------+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +--------+--------+--------+--------+ > | Upper-Layer Payload Length | > +--------+--------+--------+--------+ > | Zero | Next Header | > +--------+--------+--------+--------+ >=20 > Corrected Text > -------------- > +--------+--------+--------+--------+ > | | > + + > | | > + Source Address + > | | > + + > | | > + + > +--------+--------+--------+--------+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +--------+--------+--------+--------+ > | Upper-Layer Payload Length | > +--------+--------+--------+--------+ > | Zero |Next Hdr| > +--------+--------+--------+--------+ >=20 > Notes > ----- > In IPv6 pseudoheader, Zero field should be 3 bytes and Next header = should be 1 byte.=20 > But in RFC 5925, figure 6, it misleads into Zero field 2 bytes and = Next header 2 bytes. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) > -------------------------------------- > Title : The TCP Authentication Option > Publication Date : June 2010 > Author(s) : J. Touch, A. Mankin, R. Bonica > Category : PROPOSED STANDARD > Source : TCP Maintenance and Minor Extensions > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Jan 24 22:41:32 2021 Return-Path: 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 5F4253A0A2D; Sun, 24 Jan 2021 22:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 SxKXiLgbBdjo; Sun, 24 Jan 2021 22:41:25 -0800 (PST) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF243A0A2C; Sun, 24 Jan 2021 22:41:25 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10P6ZkfD037456; Sun, 24 Jan 2021 22:41:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=AODARSwXsTXqMXPnDKYZEBRFkh967Lf0JzXrEkMWURM=; b=D5CsX2L3tlSQwL10i9IH8bEg9Ge1vaBvks6S+waRpN89Ki2TKNNP+wCPuqvPtKkHgMg3 ZiQKFCAg3hNqCS/QO8GZRy0juyllJdrImITPGafamg/4pYmPzTtGENJ3KfMtoqqw/3oV lhd/oYs7MDW2Y1uKd/Mqw3rvcrncHvOinGZLk9rV5CylY2H0SaaRojXlqA79FevXClBk Y18e87MtdTvYq8jI6oPvOTJ2g+pqj7UxhAJbAqVEwwEct/189NmFOFtBFJLP0GVoQ4th 1o8ix+pUW8xxghOUPd/ZlbEEoDcnEvhlawVDbP2urJgQRpom35+q7eoUQP2YDmOB0WfN 0A== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp03.apple.com with ESMTP id 3694csdj84-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 24 Jan 2021 22:41:19 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QNH010JF98VB0H0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sun, 24 Jan 2021 22:41:19 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QNH00100951GI00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 24 Jan 2021 22:41:19 -0800 (PST) X-Va-A: X-Va-T-CD: 581375645c6d6179d53fcbe3d7ee3851 X-Va-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-Va-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-Va-CD: 0 X-Va-ID: 810b2e0d-b10b-4fdd-80e4-38d8065e327f X-V-A: X-V-T-CD: 581375645c6d6179d53fcbe3d7ee3851 X-V-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-V-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-V-CD: 0 X-V-ID: a96f0f10-1ca0-42b4-aa10-ca481a626d12 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-25_01:2021-01-22, 2021-01-25 signatures=0 Received: from [17.234.39.209] (unknown [17.234.39.209]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QNH00PG798RIZ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 24 Jan 2021 22:41:15 -0800 (PST) From: Vidhi Goel Message-id: <82D2BE19-7033-4D0E-87BA-0B4E3481AC84@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_44D7E722-083B-44C3-AE5C-4619EBED42F7" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 24 Jan 2021 22:41:14 -0800 In-reply-to: Cc: Martin Duke , Michael Tuexen , "Scheffenegger, Richard" , Mirja Kuehlewind , "tcpm-chairs@ietf.org" To: Joseph Touch , tcpm IETF list References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-25_01:2021-01-22, 2021-01-25 signatures=0 Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 06:41:31 -0000 --Apple-Mail=_44D7E722-083B-44C3-AE5C-4619EBED42F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I apologize for the late response. I support the "Two options=E2=80=9D but with a suggestion which can help = to eliminate the extra 1 byte. How about using 1 Byte (instead of 2) for both Kind (3 bits =3D 7 Kinds) = and Length (5 bits =3D 31 Bytes) combined?=20 1. Kind field - With limited space for ECN code points in IP header, I = don=E2=80=99t foresee that we would be able to have many different = =E2=80=9Ckinds=E2=80=9D. =20 2. Length field - TCP option length is limited to 40 bytes and with = common options like timestamp, SACK etc, I think 31 bytes for ACK ECN = option should be more than what we can fit in. I am no expert in designing protocol bit fields, so feel free to dismiss = my approach. But it would be good to get rid of that 1 byte IMO without = compromising the ability to specify the two option kinds. Thanks, Vidhi > On Dec 3, 2020, at 11:56 AM, Joseph Touch = wrote: >=20 > Hi, all, >=20 > I support one option only. >=20 > I understand the issue with the extra byte - it makes all the = different lengths one byte longer, which seems prohibitive. >=20 > However, why not simply use a bit out of the 24-bit counter? You = currently use only the 24 LSB anyway; how much worse would it be to use = only 23 bits? >=20 > If so, that allows encoding the order in any of the lengths without = needing either an extra byte or two code points. >=20 > FWIW, the end of Sec 2.2 refers to LSB as =E2=80=9Cbits=E2=80=9D; it = seems like it should be bytes. >=20 > Joe >=20 >> On Dec 3, 2020, at 11:28 AM, Martin Duke > wrote: >>=20 >> As an individual, I support 2 option codes. >>=20 >> On Mon, Nov 23, 2020 at 4:43 AM Scheffenegger, Richard = > wrote: >> I am also in favor of using two distinct option codes. >>=20 >> However, >>=20 >> > Or I guess we could say that only one option should be used for a = connection. >>=20 >> I am opposed to this - with two option codes, a sender should be free = to choose whichever he prevers at any one point; For example, if the = sender a segment (e.g. may be the receiver side) has to update the EE1 = couter, but also convey SACK information, it would be good to use the = one, where the EE1 field is first, and omit all remaining fields; >>=20 >> Later in the same connection, that very same host may choose to = update the CE field together with some SACK information, and use the = other codepoint in order to preserve as much TCP option space for the = SACK option... >>=20 >>=20 >> As for extensibility: I would want to avoid that topic, and just = specifiy the three correct supported lengths here, and not mention = (other than ignoring "odd" fractionals of the 3-byte wide counters) what = happens with other lengths...=20 >>=20 >>=20 >> Richard Scheffenegger >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Mirja Kuehlewind >=20 >> Gesendet: Montag, 23. November 2020 12:39 >> An: Neal Cardwell >; Scharf, Michael = >; Bob Briscoe = > >> Cc: Yoshifumi Nishida >; tcpm IETF list >; Scheffenegger, Richard = >; Michael Tuexen = >; = tcpm-chairs@ietf.org >> Betreff: Re: [tcpm] AccECN field order >>=20 >> NetApp Security WARNING: This is an external email. Do not click = links or open attachments unless you recognize the sender and know the = content is safe. >>=20 >>=20 >>=20 >>=20 >> Hi all, >>=20 >> I think I also support two options as this is the most simple = solution. >>=20 >> We probably need to look at section 3.2.3.2. (Path Traversal of the = AccECN Option) again, as I think this section assumes mostly one option. = Or I guess we could say that only one option should be used for a = connection. >>=20 >> Regarding use of the option length for extensibility. I know new = options are hard to deploy but that=E2=80=99s the extensibility = mechanism we have with TCP. Not sure we want to invent a new now. If we = think we need more extensibility for AccECN for any reason, we should = specify valid option length values that include a flags field now. >>=20 >> Mirja >>=20 >>=20 >>=20 >> > On 18. Nov 2020, at 01:03, Neal Cardwell > wrote: >> > >> > As someone who contributes to a TCP implementation, I would put in = a vote for the "Two Option Kinds" proposal outlined in slide 6 here: >> > >> > =20 >> > = https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor = >> > = e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica >> > tion-01#page=3D6 >> > >> > This approach has the virtue of simplicity, which hopefully may = help avoid middlebox bugs, speed standardization and development, and = ease the process of maintaining fast and stable implementations. >> > >> > neal >> > >> > >> > On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael = > = wrote: >> > Inline some comments [ms]. >> > >> > >> > >> > Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll = not follow-up forever in this discussion. I don=E2=80=99t own running = code and a lot of encoding details mainly affect an implementation. >> > >> > >> > >> > IMHO the rest of the WG has to think about the option design more = than=20 >> > me. So, this is mostly about triggering a discussion=E2=80=A6 >> > >> > >> > >> > From: Bob Briscoe > >> > Sent: Tuesday, November 17, 2020 1:20 PM >> > To: Scharf, Michael >; Yoshifumi=20 >> > Nishida > >> > Cc: Michael Tuexen >; tcpm-chairs@ietf.org = ;=20 >> > Mirja Kuehlewind >; Scheffenegger, Richard=20 >> > >; tcpm IETF list = > >> > Subject: Re: AccECN field order >> > >> > >> > >> > Michael, >> > >> > On 17/11/2020 08:10, Scharf, Michael wrote: >> > >> > Bob, >> > >> > >> > >> > I am fine with the two option kinds proposed in -13, but I don=E2=80=99= t buy your arguments why this encoding is better than others. >> > >> > >> > >> > Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward = compatibility=E2=80=9D argument is a very compelling reason for two = codepoints. All proposals I am aware of have their pros and cons. And I = am not aware of a really comprehensive discussion. At least neither the = e-mail below nor today=E2=80=99s meeting discuss all tradeoffs I would = investigate. >> > >> > >> > [BB] You're right - the discussion below is useful and necessary. >> > >> > >> > >> > >> > >> > For instance, the benefit of the length encoding variant would be = to consume only one TCP option codepoint now. If we decided later to = that a flag byte is needed (say, at the end), a follow-up proposed = standard could specify another option format with that flag byte, using = a second codepoint. >> > >> > >> > [BB] >> > * The new codepoint would require years to deploy (including in = proxies) before it works e2e. >> > >> > >> > >> > [ms] That may depend *a lot* on the environment. In environments = where ECN can get deployed today, say in datacenters, rolling out a new = kernel version may perhaps not be the biggest operational challenge. = Also, proxies may not be a significant problem in some of those cases. = Deployment roadmaps are very hard to predict. >> > >> > >> > * Whereas the 'forward compatibility' approach tries to ensure that = AccECN implementations that are being built today will be ready to = interwork with a future extension. >> > * In contrast, if your hypothetical new AccECN codepoint did need = to be deployed later, it would need to include a fall-back to the = current AccECN option when one peer doesn't understand the new = codepoint. >> > >> > >> > >> > [ms] This is a reasonable point, albeit not a particularly strong = one,=20 >> > given that the option is not really required for basic=20 >> > interoperability. Also, a hypothetical follow-up standard could=20 >> > include a way to explicitly request the option=E2=80=A6 >> > >> > >> > * Fall-back would need to avoid a second round of handshake (given=20= >> > this is for low latency), which would only work reliably with an=20 >> > option on the SYN (because the 3rd ACK is unreliable) >> > >> > >> > >> > [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting = AccECN option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cple= ase send me the better AccECN option B=E2=80=9D after the 3-WHS. It = could be an upgrade, not a fallback. Also, at this point we don=E2=80=99t = know what option B would be and in which context it would be needed. = Maybe other protocol features would require negotiation, too. IMHO it is = a solvable problem. >> > >> > >> > * AccECN has so far avoided using any SYN option space, which is = important given that is the scarcest resource. >> > >> > >> > >> > [ms] Yep, but as long as no proposal needs SYN options, this is = nothing that would make one solution better than another. >> > >> > These days, extending TCP is like playing chess - we have to think = multiple moves ahead! >> > >> > >> > >> > [ms] There is one fundamental difference between chess and TCP: In = chess you precisely know the current situation and can predict all = potential moves in advance (albeit there are a lot). However, we don=E2=80= =99t know the future evolution of TCP, ECN and the Internet as a whole, = nor future requirements. If we try to engineer a TCP extension for some = potential future, we may figure out later that reality is different from = what we designed for. As much as I appreciate your attempts to predict = the future, it would be a big surprise to me if you could correctly = predict what TCP will be in 10 years from now. So, instead of trying to = write specifications that take into account future requirements, which = are in fact just unknown, it is more important for me to write = effective, efficient and secure specifications for what is currently = known for sure. >> > >> > >> > >> > [ms] I *don=E2=80=99t* know for sure whether the current AccECN = option will be needed, but I see quite some evidence that support of the = AccECN option(s) is not a top priority these days. That is also = something to think about when designing the details. >> > >> > >> > >> > I need to learn to articulate onto the list all my reasons for = rejecting certain parts of the design space. Sorry about that. >> > >> > Yes, I admit, the current proposal is at the cost of burning two = TCP option codepoints. However, you said yourself when you proposed this = approach, that they are not (currently) a scarce resource. Certainly not = as scarce as option space. I just checked: roughly 15% of the option = codepoint allocation space has been used so far. So that's where I would = suggest we compromise first. >> > >> > [ms] I made a similar calculation some years ago and came to a = similar conclusion. Investing two codepoints for AccECN is something we = can probably afford. But nonetheless we have to reason carefully why it = is really worth the effort. >> > >> > >> > >> > >> > Regarding the resulting codepoint consumption (two option kinds) = and the addition of a flag byte, this approach would basically end up = with the same result as the current proposal in -13 plus some = hypothetical future addition leveraging the length field beyond the = currently known use. >> > >> > >> > >> > And, yes, the length encoding variant may be less flexible and/or = consume some more bits in some cases, but on the plus side it only needs = one codepoint now =E2=80=93 and given that it is entirely unclear = whether any AccECN option will indeed be widely used in future, this is = a big plus. The fact that implementers are quite silent on the option = design is not a good sign. >> > >> > >> > [BB] Here's another possibility then. >> > >> > a) [K|L| EE1B | ECEB | EE0B ] >> > b) [K|L| EE1B | ECEB | EE0B |F] if F =3D 0bXXXXXXX0 >> > c) [K|L| EE0B | ECEB | EE1B |F] if F =3D 0bXXXXXXX1 >> > >> > We'd have to decide which order alternative (a) takes. I've picked = EE1B first only 'cos you're right that there is not currently as much = pressure (on the public Internet) for AccECN with ECT(0). >> > >> > =3D=3DLegend=3D=3D >> > K: Kind (1B) >> > L: Length (1B) >> > ExxB: Echo xx byte counter >> > F: Flags (1B) >> > >> > Alternatives a) and b) are equivalent, at least while the only = allocated flag is for field order. >> > However, alternative b) is available in case other flags are = allocated=20 >> > in future The flags byte can only be omitted if (L % 3 =3D=3D 2). >> > The flags byte is considered present if (L % 3) =3D=3D 0. >> > >> > Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be = assumed to include a flags byte, and current implementations ignore the = last byte. >> > >> > The flags byte is optional to implement (even if the AccECN option = is=20 >> > implemented) If the server includes a flags byte on the SYN/ACK but = the client does not include one on the 3rd ACK or the first data packet, = the server assumes the client does not implement the flags byte and uses = only alternative a) for the remainder of the connection. >> > >> > >> > [ms] I am not sure if we need that, but I take this as existence = proof that other encodings are possible. Personally, I think that other = solutions would be doable if you took one bit from one or multiple = counters for format encoding. At least for some of the byte counters I = don=E2=80=99t think taking one bit for other purposes would result in an = Internet congestion collapse=E2=80=A6 But, I have already said that the = -13 proposal works for me, so I=E2=80=99ll not try to come up with = another variant myself. >> > >> > >> > >> > To me, one potential difference between two proposals would be = incremental deployment. The proposal in -13 only has an advantage if = middleboxes such as firewalls will indeed pass TCP options with a format = that contains content beyond the (first) Accurate ECN standard (i.e., = currently unused length values). IMHO it is too early to know whether = firewalls would indeed allow this in future. >> > >> > >> > >> > =46rom a security perspective, it is not clear to me whether = allowing arbitrary unspecified bytes in a TCP option is a good idea *at = all*. It will be interesting to hear the opinion from SEC area on that. = Personally, I am not convinced that this really makes sense, but I my = concerns are not strong enough to formally push back. I=E2=80=99ll leave = it to others to think about whether this is a bug or a feature. >> > >> > >> > [BB] Well, let's first try to deal with security ourselves: >> > * Octets that are explicitly declared as part of an option cannot = be used for a buffer overflow attack. I don't really need to, but I = could add the following text to the forward compatibility wording: >> > A receiver considers octets beyond those it uses, but within = the specified length, as if they are padding. >> > * And such octets cannot be any different from the current ability = of a sender to add padding. So there's no new attack possible here. >> > * And there's no need to specify a max length for any AccECN = Option, which would just unnecessarily limit flexibility. >> > >> > [ms] I have more thought about the covert channel that some = unspecified bytes in a standards track TCP option could offer=E2=80=A6 = In particular if the AccECN option gets widely deployed and used, would = some malicious users find those bytes useful? For what? For instance, = what in the AccECN protocol design prevents use of these =E2=80=9Cpadding=E2= =80=9D bytes as super-cookie? To me, it is much more important to think = about abuse of whatever we standardize *now*, instead of engineering for = some entirely unknown future. I am not a security expert, but I suggest = a careful analysis of any security implications of the AccECN option. We = seldomly specify new TCP options and malicious users will certainly look = for =E2=80=9Copportunities=E2=80=9D in the spec. So far, I don=E2=80=99t = know whether that whole idea of forward compatibility is a feature or a = bug. >> > >> > >> > >> > Michael >> > >> > >> > >> > Maybe one lesson learnt is that the document could have a = non-normative appendix that explains the rationale for the finally = picked TCP option encoding. That may also help if there are further = questions whether two codepoints are really required, e.g. by the IESG = (if two codepoints are still the design after WGLC). At least for past = TCP option codepoint allocations I recall some discussions late in the = IETF process. In those past cases, good arguments in an appendix and = running code has helped a lot. >> > >> > >> > [BB] I can do that. Appx B is already similar, giving Design = Rationale for the ACE field. >> > >> > >> > Bob >> > >> > >> > >> > >> > >> > Michael >> > >> > >> > >> > >> > >> > >> > >> > From: Bob Briscoe > >> > Sent: Tuesday, November 17, 2020 6:10 AM >> > To: Scharf, Michael >; Yoshifumi=20 >> > Nishida > >> > Cc: Michael Tuexen >; tcpm-chairs@ietf.org = ;=20 >> > Mirja Kuehlewind >; Scheffenegger, Richard=20 >> > >; tcpm IETF list = > >> > Subject: Re: AccECN field order >> > >> > >> > >> > Michael, >> > >> > On 16/11/2020 17:36, Scharf, Michael wrote: >> > >> > Bob, >> > >> > >> > >> > One proposal using the length field with *one option codepoint = only*=20 >> > is detailed in:=20 >> > = https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo = >> > / >> > >> > >> > >> > It is the third option mentioned in this e-mail. One example would = be to use option length values 5/8/11 for one encoding type and option = length values 6/9/12 for the other encoding type (i.e., order of = fields). Or one could use some other combination of length values =E2=80=93= the only requirement is that a certain value for the option length is = only used by one of the option formats. In that approach, the value of = the length field would thus directly describe the encoding of the = option. Unless I miss something, this would work and it would just = require one option codepoint. >> > >> > >> > >> > Thus, alternatives to two option codepoints exist and I have = explained them on the list in March 2020. >> > >> > >> > OK, sorry, yes, I remember this now. >> > >> > As I will explain in the AccECN status update talk today in virtual = Bangkok, the draft has made provision for different length values than = 5/8/11. It says existing implementations MUST accept length values other = than those currently defined. But then read in as many whole 3-byte = fields as they can. >> > >> > This can be used to add a flags byte on the end in future, for = extensibility. Or any other form of extensibility the WG might decide in = the future. >> > >> > I know a flags byte at the end seems odd compared to at the = beginning. But (if decided it's needed in future) it's reasonably easy = to implement by reading the whole option, then processing the last byte, = before reading the rest of the option. >> > >> > I believe you will agree that this is a better way to utilize = different lengths. >> > >> > And thank you for repeatedly emphasizing that you're happy with the = 2-kind scheme, or other alternatives. >> > >> > >> > Bob >> > >> > >> > >> > >> > >> > >> > Anyway, I don=E2=80=99t really care how the options are encoded as = long as the receiver doesn=E2=80=99t need per-connection state for = decoding a TCP option. So, personally, I would be fine with using e.g. = the length field as described in my old e-mail. Or an additional flag = byte. And one could come up with further encodings, e.g., by using one = or a few bits as a short =E2=80=9Ctype=E2=80=9D field for each counter. = This is all about protocol engineering. And all these variants have = their pros and cons. >> > >> > >> > >> > I am also fine with using two option codepoints as specified in = -13; this is probably the approach that consumes the least number of = bits. >> > >> > >> > >> > Michael (w/o any hat) >> > >> > >> > >> > >> > >> > >> > >> > From: Bob Briscoe > >> > Sent: Monday, November 16, 2020 5:52 PM >> > To: Yoshifumi Nishida > >> > Cc: Scharf, Michael >; Michael Tuexen=20 >> > >; = tcpm-chairs@ietf.org ; Mirja Kuehlewind=20 >> > >; Scheffenegger, = Richard=20 >> > >; tcpm IETF list = > >> > Subject: AccECN field order >> > >> > >> > >> > Yoshi, (adding the tcpm list in cc) >> > >> > On 05/11/2020 06:58, Yoshifumi Nishida wrote: >> > >> > Hi Bob, >> > >> > >> > >> > On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe > wrote: >> > >> > Yoshi, >> > >> > On 04/11/2020 06:51, Yoshifumi Nishida wrote: >> > >> > Hi, folks, >> > >> > >> > >> > >> > >> > >> > In my understanding, I'm not sure if we settled down on using two = option kinds or encoding schemes for 24bits fields in acc ecn draft. >> > >> > So, I think there're still something to be clarified and hope = things will be settled at the meeting. >> > >> > >> > [BB] I know a WG can change it's mind at any time. But I'd rather = we just clarified what a previous decision was, to avoid the need to = keep re-opening discussion on a question that have been decided then = changed three different ways already. >> > >> > My memory is not so good these days. I trusted that Michael S = remembered the decision correctly, and I seem to remember that decision = being made. >> > I've just checked the minutes of the last interim: >> > =20 >> > = https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 = >> > 1600/ and they mention Michael's proposal to use two kinds, but = don't=20 >> > record any decision. >> > The jabber log gives no clues about any decision. >> > >> > I can't find an audio or video recording. Can you point me at one? >> > >> > >> > >> > I thought that it's because there was no clear decision at the = meeting. >> > >> > But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA = >> > >> > Please let us know if you have any questions or opinions with = regard to this. >> > >> > >> > [BB] I checked the Youtube link you sent below. >> > >> > First I think we're agreed no-one was fighting for us to keep the = previous way we did this (using the initial value of the field to set = the order for the connection). >> > In my presentation I said there was strong resistance from Michael = to do it a different way. >> > (also, offlist, the co-authors including me also didn't like this = so=20 >> > much. And Ilpo said it made the implementation complex.) >> > >> > Then came the question of what we do instead. There were three = alternative proposals: >> > a) use 2 option kinds >> > b) add a flags byte >> > c) somehow use the length field maybe >> > >> > Michael raised (c) in the meeting as a possibility, but no-one = could think how to distinguish two options of the same length but a = different field order using the length field. Michael said he'd post any = ideas to the list if he could think of any, but that didn't happen. >> > >> > So we're left choosing between (a) and (b). >> > I said in the meeting (and on the list when discussing with Ilpo) = that I'd be happy to go with (b), but only if there was another use for = a flag. Because it would consume 1B more options space in many packets, = which is a scarce resource. >> > >> > Ilpo had a proposed use for another flag (to help synch counters = after a loss), but I think the discussion about it ended that it = wouldn't be helpful, 'cos the way it worked depended on itself (circular = logic). >> > >> > In conclusion, I don't think there was an explicit decision to go = with 2 option kinds, but it ended up as the 'last person standing'. >> > I like it. It's simple. And apparently option kinds are not such a = scarce resource. >> > >> > Perhaps we can ratify this in the WG tomorrow. >> > >> > >> > Bob >> > >> > >> > >> > >> > >> > >> > >> > Thanks, >> > >> > -- >> > >> > Yoshi >> > >> > >> > >> > >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe http://bobbriscoe.net/ = >> > >> > >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe http://bobbriscoe.net/ = >> > >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe http://bobbriscoe.net/ = >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm = >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_44D7E722-083B-44C3-AE5C-4619EBED42F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = apologize for the late response.

I support the "Two options=E2=80=9D but with = a suggestion which can help to eliminate the extra 1 byte.

How about using 1 Byte = (instead of 2) for both Kind (3 bits =3D 7 Kinds) and Length (5 bits =3D = 31 Bytes) combined? 

1. Kind field - With limited space for ECN code points = in IP header, I don=E2=80=99t foresee that we would be able to have many = different =E2=80=9Ckinds=E2=80=9D.  
2. = Length field - TCP option length is limited to 40 bytes and with common = options like timestamp, SACK etc, I think 31 bytes for ACK ECN option = should be more than what we can fit in.

I am no expert in designing protocol = bit fields, so feel free to dismiss my approach. But it would be good to = get rid of that 1 byte IMO without compromising the ability to specify = the two option kinds.

Thanks,
Vidhi

On Dec = 3, 2020, at 11:56 AM, Joseph Touch <touch@strayalpha.com> wrote:

Hi, all,

I support one option = only.

I = understand the issue with the extra byte - it makes all the different = lengths one byte longer, which seems prohibitive.
However, why not simply use a bit out = of the 24-bit counter? You currently use only the 24 LSB anyway; how = much worse would it be to use only 23 bits?

If so, that allows encoding the order = in any of the lengths without needing either an extra byte or two code = points.

FWIW, = the end of Sec 2.2 refers to LSB as =E2=80=9Cbits=E2=80=9D; it seems = like it should be bytes.

Joe

On Dec 3, 2020, at 11:28 AM, Martin Duke <martin.h.duke@gmail.com> wrote:

As an individual, I support 2 option codes.

On Mon, Nov 23, 2020 at 4:43 AM Scheffenegger, = Richard <Richard.Scheffenegger@netapp.com> wrote:
I = am also in favor of using two distinct option codes.

However,

> Or I guess we could say that only one option should be used for a = connection.

I am opposed to this - with two option codes, a sender should be free to = choose whichever he prevers at any one point; For example, if the sender = a segment (e.g. may be the receiver side)  has to update the EE1 = couter, but also convey SACK information, it would be good to use the = one, where the EE1 field is first, and omit all remaining fields;

Later in the same connection, that very same host may choose to update = the CE field together with some SACK information, and use the other = codepoint in order to preserve as much TCP option space for the SACK = option...


As for extensibility: I would want to avoid that topic, and just = specifiy the three correct supported lengths here, and not mention = (other than ignoring "odd" fractionals of the 3-byte wide counters) what = happens with other lengths...


Richard Scheffenegger

-----Urspr=C3=BCngliche Nachricht-----
Von: Mirja Kuehlewind <ietf@kuehlewind.net>
Gesendet: Montag, 23. November 2020 12:39
An: Neal Cardwell <ncardwell@google.com>; Scharf, = Michael <Michael.Scharf@hs-esslingen.de>; Bob = Briscoe <ietf@bobbriscoe.net>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm IETF list = <tcpm@ietf.org>; Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>; Michael Tuexen = <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org
Betreff: Re: [tcpm] AccECN field order

NetApp Security WARNING: This is an external email. Do not click links = or open attachments unless you recognize the sender and know the content = is safe.




Hi all,

I think I also support two options as this is the most simple = solution.

We probably need to look at section 3.2.3.2. (Path Traversal of the = AccECN Option) again, as I think this section assumes mostly one option. = Or I guess we could say that only one option should be used for a = connection.

Regarding use of the option length for extensibility. I know new options = are hard to deploy but that=E2=80=99s the extensibility mechanism we = have with TCP. Not sure we want to invent a new now. If we think we need = more extensibility for AccECN for any reason, we should specify valid = option length values that include a flags field now.

Mirja



> On 18. Nov 2020, at 01:03, Neal Cardwell <ncardwell@google.com> wrote:
>
> As someone who contributes to a TCP implementation, I would put in = a  vote for the "Two Option Kinds" proposal outlined in slide 6 = here:
>
> 
> https://datatracker.ietf.org/meeting/109/materials/slides-109-t= cpm-mor
> = e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica
> tion-01#page=3D6
>
> This approach has the virtue of simplicity, which hopefully may = help avoid middlebox bugs, speed standardization and development, and = ease the process of maintaining fast and stable implementations.
>
> neal
>
>
> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> Inline some comments [ms].
>
>
>
> Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll = not follow-up forever in this discussion. I don=E2=80=99t own running = code and a lot of encoding details mainly affect an implementation.
>
>
>
> IMHO the rest of the WG has to think about the option design more = than
> me. So, this is mostly about triggering a discussion=E2=80=A6
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 1:20 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
> Nishida <nsd.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, = Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 17/11/2020 08:10, Scharf, Michael wrote:
>
> Bob,
>
>
>
> I am fine with the two option kinds proposed in -13, but I don=E2=80=99= t buy your arguments why this encoding is better than others.
>
>
>
> Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward = compatibility=E2=80=9D argument is a very compelling reason for two = codepoints. All proposals I am aware of have their pros and cons. And I = am not aware of a really comprehensive discussion. At least neither the = e-mail below nor today=E2=80=99s meeting discuss all tradeoffs I would = investigate.
>
>
> [BB] You're right - the discussion below is useful and = necessary.
>
>
>
>
>
> For instance, the benefit of the length encoding variant would be = to consume only one TCP option codepoint now. If we decided later to = that a flag byte is needed (say, at the end), a follow-up proposed = standard could specify another option format with that flag byte, using = a second codepoint.
>
>
> [BB]
> * The new codepoint would require years to deploy (including in = proxies) before it works e2e.
>
>
>
> [ms] That may depend *a lot* on the environment. In environments = where ECN can get deployed today, say in datacenters, rolling out a new = kernel version may perhaps not be the biggest operational challenge. = Also, proxies may not be a significant problem in some of those cases. = Deployment roadmaps are very hard to predict.
>
>
> * Whereas the 'forward compatibility' approach tries to ensure that = AccECN implementations that are being built today will be ready to = interwork with a future extension.
> * In contrast, if your hypothetical new AccECN codepoint did need = to be deployed later, it would need to include a fall-back to the = current AccECN option when one peer doesn't understand the new = codepoint.
>
>
>
> [ms] This is a reasonable point, albeit not a particularly strong = one,
> given that the option is not really required for basic
> interoperability. Also, a hypothetical follow-up standard could
> include a way to explicitly request the option=E2=80=A6
>
>
> * Fall-back would need to avoid a second round of handshake (given =
> this is for low latency), which would only work reliably with an =
> option on the SYN (because the 3rd ACK is unreliable)
>
>
>
> [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting = AccECN option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cple= ase send me the better AccECN option B=E2=80=9D after the 3-WHS. It = could be an upgrade, not a fallback. Also, at this point we don=E2=80=99t = know what option B would be and in which context it would be needed. = Maybe other protocol features would require negotiation, too. IMHO it is = a solvable problem.
>
>
> * AccECN has so far avoided using any SYN option space, which is = important given that is the scarcest resource.
>
>
>
> [ms] Yep, but as long as no proposal needs SYN options, this is = nothing that would make one solution better than another.
>
> These days, extending TCP is like playing chess - we have to think = multiple moves ahead!
>
>
>
> [ms] There is one fundamental difference between chess and TCP: In = chess you precisely know the current situation and can predict all = potential moves in advance (albeit there are a lot). However, we don=E2=80= =99t know the future evolution of TCP, ECN and the Internet as a whole, = nor future requirements. If we try to engineer a TCP extension for some = potential future, we may figure out later that reality is different from = what we designed for. As much as I appreciate your attempts to predict = the future, it would be a big surprise to me if you could correctly = predict what TCP will be in 10 years from now. So, instead of trying to = write specifications that take into account future requirements, which = are in fact just unknown, it is more important for me to write = effective, efficient and secure specifications for what is currently = known for sure.
>
>
>
> [ms] I *don=E2=80=99t* know for sure whether the current AccECN = option will be needed, but I see quite some evidence that support of the = AccECN option(s) is not a top priority these days. That is also = something to think about when designing the details.
>
>
>
> I need to learn to articulate onto the list all my reasons for = rejecting certain parts of the design space. Sorry about that.
>
> Yes, I admit, the current proposal is at the cost of burning two = TCP option codepoints. However, you said yourself when you proposed this = approach, that they are not (currently) a scarce resource. Certainly not = as scarce as option space. I just checked: roughly 15% of the option = codepoint allocation space has been used so far. So that's where I would = suggest we compromise first.
>
> [ms] I made a similar calculation some years ago and came to a = similar conclusion. Investing two codepoints for AccECN is something we = can probably afford. But nonetheless we have to reason carefully why it = is really worth the effort.
>
>
>
>
> Regarding the resulting codepoint consumption (two option kinds) = and the addition of a flag byte, this approach would basically end up = with the same result as the current proposal in -13 plus some = hypothetical future addition leveraging the length field beyond the = currently known use.
>
>
>
> And, yes, the length encoding variant may be less flexible and/or = consume some more bits in some cases, but on the plus side it only needs = one codepoint now =E2=80=93 and given that it is entirely unclear = whether any AccECN option will indeed be widely used in future, this is = a big plus. The fact that implementers are quite silent on the option = design is not a good sign.
>
>
> [BB] Here's another possibility then.
>
> a) [K|L| EE1B | ECEB | EE0B ]
> b) [K|L| EE1B | ECEB | EE0B |F]    if F =3D 0bXXXXXXX0
> c) [K|L| EE0B | ECEB | EE1B |F]    if F =3D 0bXXXXXXX1
>
> We'd have to decide which order alternative (a) takes. I've picked = EE1B first only 'cos you're right that there is not currently as much = pressure (on the public Internet) for AccECN with ECT(0).
>
> =3D=3DLegend=3D=3D
> K:    Kind (1B)
> L:    Length (1B)
> ExxB: Echo xx byte counter
> F:    Flags (1B)
>
> Alternatives a) and b) are equivalent, at least while the only = allocated flag is for field order.
> However, alternative b) is available in case other flags are = allocated
> in future The flags byte can only be omitted if (L % 3 =3D=3D = 2).
> The flags byte is considered present if (L % 3) =3D=3D 0.
>
> Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be = assumed to include a flags byte, and current implementations ignore the = last byte.
>
> The flags byte is optional to implement (even if the AccECN option = is
> implemented) If the server includes a flags byte on the SYN/ACK but = the client does not include one on the 3rd ACK or the first data packet, = the server assumes the client does not implement the flags byte and uses = only alternative a) for the remainder of the connection.
>
>
> [ms] I am not sure if we need that, but I take this as existence = proof that other encodings are possible. Personally, I think that other = solutions would be doable if you took one bit from one or multiple = counters for format encoding. At least for some of the byte counters I = don=E2=80=99t think taking one bit for other purposes would result in an = Internet congestion collapse=E2=80=A6 But, I have already said that the = -13 proposal works for me, so I=E2=80=99ll not try to come up with = another variant myself.
>
>
>
> To me, one potential difference between two proposals would be = incremental deployment. The proposal in -13 only has an advantage if = middleboxes such as firewalls will indeed pass TCP options with a format = that contains content beyond the (first) Accurate ECN standard (i.e., = currently unused length values). IMHO it is too early to know whether = firewalls would indeed allow this in future.
>
>
>
> =46rom a security perspective, it is not clear to me whether = allowing arbitrary unspecified bytes in a TCP option is a good idea *at = all*. It will be interesting to hear the opinion from SEC area on that. = Personally, I am not convinced that this really makes sense, but I my = concerns are not strong enough to formally push back. I=E2=80=99ll leave = it to others to think about whether this is a bug or a feature.
>
>
> [BB] Well, let's first try to deal with security ourselves:
> * Octets that are explicitly declared as part of an option cannot = be used for a buffer overflow attack. I don't really need to, but I = could add the following text to the forward compatibility wording:
>     A receiver considers octets beyond those it = uses, but within the specified length, as if they are padding.
> * And such octets cannot be any different from the current ability = of a sender to add padding. So there's no new attack possible here.
> * And there's no need to specify a max length for any AccECN = Option, which would just unnecessarily limit flexibility.
>
> [ms] I have more thought about the covert channel that some = unspecified bytes in a standards track TCP option could offer=E2=80=A6 = In particular if the AccECN option gets widely deployed and used, would = some malicious users find those bytes useful? For what? For instance, = what in the AccECN protocol design prevents use of these =E2=80=9Cpadding=E2= =80=9D bytes as super-cookie? To me, it is much more important to think = about abuse of whatever we standardize *now*, instead of engineering for = some entirely unknown future. I am not a security expert, but I suggest = a careful analysis of any security implications of the AccECN option. We = seldomly specify new TCP options and malicious users will certainly look = for =E2=80=9Copportunities=E2=80=9D in the spec. So far, I don=E2=80=99t = know whether that whole idea of forward compatibility is a feature or a = bug.
>
>
>
> Michael
>
>
>
> Maybe one lesson learnt is that the document could have a = non-normative appendix that explains the rationale for the finally = picked TCP option encoding. That may also help if there are further = questions whether two codepoints are really required, e.g. by the IESG = (if two codepoints are still the design after WGLC). At least for past = TCP option codepoint allocations I recall some discussions late in the = IETF process. In those past cases, good arguments in an appendix and = running code has helped a lot.
>
>
> [BB] I can do that. Appx B is already similar, giving Design = Rationale for the ACE field.
>
>
> Bob
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 6:10 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
> Nishida <nsd.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, = Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 16/11/2020 17:36, Scharf, Michael wrote:
>
> Bob,
>
>
>
> One proposal using the length field with *one option codepoint = only*
> is detailed in:
> https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTv= pC4BNMo
> /
>
>
>
> It is the third option mentioned in this e-mail. One example would = be to use option length values 5/8/11 for one encoding type and option = length values 6/9/12 for the other encoding type (i.e., order of = fields). Or one could use some other combination of length values =E2=80=93= the only requirement is that a certain value for the option length is = only used by one of the option formats. In that approach, the value of = the length field would thus directly describe the encoding of the = option. Unless I miss something, this would work and it would just = require one option codepoint.
>
>
>
> Thus, alternatives to two option codepoints exist and I have = explained them on the list in March 2020.
>
>
> OK, sorry, yes, I remember this now.
>
> As I will explain in the AccECN status update talk today in virtual = Bangkok, the draft has made provision for different length values than = 5/8/11. It says existing implementations MUST accept length values other = than those currently defined. But then read in as many whole 3-byte = fields as they can.
>
> This can be used to add a flags byte on the end in future, for = extensibility. Or any other form of extensibility the WG might decide in = the future.
>
> I know a flags byte at the end seems odd compared to at the = beginning. But (if decided it's needed in future) it's reasonably easy = to implement by reading the whole option, then processing the last byte, = before reading the rest of the option.
>
> I believe you will agree that this is a better way to utilize = different lengths.
>
> And thank you for repeatedly emphasizing that you're happy with the = 2-kind scheme, or other alternatives.
>
>
> Bob
>
>
>
>
>
>
> Anyway, I don=E2=80=99t really care how the options are encoded as = long as the receiver doesn=E2=80=99t need per-connection state for = decoding a TCP option. So, personally, I would be fine with using e.g. = the length field as described in my old e-mail. Or an additional flag = byte. And one could come up with further encodings, e.g., by using one = or a few bits as a short =E2=80=9Ctype=E2=80=9D field for each counter. = This is all about protocol engineering. And all these variants have = their pros and cons.
>
>
>
> I am also fine with using two option codepoints as specified in = -13; this is probably the approach that consumes the least number of = bits.
>
>
>
> Michael (w/o any hat)
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Monday, November 16, 2020 5:52 PM
> To: Yoshifumi Nishida <nsd.ietf@gmail.com>
> Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Michael Tuexen
> <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org; Mirja Kuehlewind
> <ietf@kuehlewind.net>; Scheffenegger, Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: AccECN field order
>
>
>
> Yoshi, (adding the tcpm list in cc)
>
> On 05/11/2020 06:58, Yoshifumi Nishida wrote:
>
> Hi Bob,
>
>
>
> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Yoshi,
>
> On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>
> Hi, folks,
>
>
>
>
>
>
> In my understanding, I'm not sure if we settled down on using two = option kinds or encoding schemes for 24bits fields in acc ecn draft.
>
> So, I think there're still something to be clarified and hope = things will be settled at the meeting.
>
>
> [BB] I know a WG can change it's mind at any time. But I'd rather = we just clarified what a previous decision was, to avoid the need to = keep re-opening discussion on a question that have been decided then = changed three different ways already.
>
> My memory is not so good these days. I trusted that Michael S = remembered the decision correctly, and I seem to remember that decision = being made.
> I've just checked the minutes of the last interim:
>     
> https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-2= 0200429
> 1600/ and they mention Michael's proposal to use two kinds, but = don't
> record any decision.
> The jabber log gives no clues about any decision.
>
> I can't find an audio or video recording. Can you point me at = one?
>
>
>
> I thought that it's because there was no clear decision at the = meeting.
>
> But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA
>
> Please let us know if you have any questions or opinions with = regard to this.
>
>
> [BB] I checked the Youtube link you sent below.
>
> First I think we're agreed no-one was fighting for us to keep the = previous way we did this (using the initial value of the field to set = the order for the connection).
> In my presentation I said there was strong resistance from Michael = to do it a different way.
> (also, offlist, the co-authors including me also didn't like this = so
> much. And Ilpo said it made the implementation complex.)
>
> Then came the question of what we do instead. There were three = alternative proposals:
> a) use 2 option kinds
> b) add a flags byte
> c) somehow use the length field maybe
>
> Michael raised (c) in the meeting as a possibility, but no-one = could think how to distinguish two options of the same length but a = different field order using the length field. Michael said he'd post any = ideas to the list if he could think of any, but that didn't happen.
>
> So we're left choosing between (a) and (b).
> I said in the meeting (and on the list when discussing with Ilpo) = that I'd be happy to go with (b), but only if there was another use for = a flag. Because it would consume 1B more options space in many packets, = which is a scarce resource.
>
> Ilpo had a proposed use for another flag (to help synch counters = after a loss), but I think the discussion about it ended that it = wouldn't be helpful, 'cos the way it worked depended on itself (circular = logic).
>
> In conclusion, I don't think there was an explicit decision to go = with 2 option kinds, but it ended up as the 'last person standing'.
> I like it. It's simple. And apparently option kinds are not such a = scarce resource.
>
> Perhaps we can ratify this in the WG tomorrow.
>
>
> Bob
>
>
>
>
>
>
>
> Thanks,
>
> --
>
> Yoshi
>
>
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_44D7E722-083B-44C3-AE5C-4619EBED42F7-- From nobody Mon Jan 25 07:19:50 2021 Return-Path: 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 0D3623A1476; Mon, 25 Jan 2021 07:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TD4HtlDgwUxo; Mon, 25 Jan 2021 07:19:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BA53A1475; Mon, 25 Jan 2021 07:19:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 30F34F4070A; Mon, 25 Jan 2021 07:19:42 -0800 (PST) To: ananth.nantha@yahoo.com, touch@isi.edu, mankin@psg.com, rbonica@juniper.net X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: martin.h.duke@gmail.com, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210125151942.30F34F4070A@rfc-editor.org> Date: Mon, 25 Jan 2021 07:19:42 -0800 (PST) Archived-At: Subject: [tcpm] [Errata Held for Document Update] RFC5925 (6406) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 15:19:45 -0000 The following errata report has been held for document update for RFC5925, "The TCP Authentication Option". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6406 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ananth Rajadurai Date Reported: 2021-01-22 Held by: Martin Duke (IESG) Section: Section 5.1 Original Text ------------- In Section 5.1, Figure 6 - TCP IPv6 Pseudoheader +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero | Next Header | +--------+--------+--------+--------+ Corrected Text -------------- +--------+--------+--------+--------+ | | + + | | + Source Address + | | + + | | + + +--------+--------+--------+--------+ | | + + | | + Destination Address + | | + + | | +--------+--------+--------+--------+ | Upper-Layer Payload Length | +--------+--------+--------+--------+ | Zero |Next Hdr| +--------+--------+--------+--------+ Notes ----- In IPv6 pseudoheader, Zero field should be 3 bytes and Next header should be 1 byte. But in RFC 5925, figure 6, it misleads into Zero field 2 bytes and Next header 2 bytes. -------------------------------------- RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11) -------------------------------------- Title : The TCP Authentication Option Publication Date : June 2010 Author(s) : J. Touch, A. Mankin, R. Bonica Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Jan 26 14:18:20 2021 Return-Path: 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 7DC703A0317; Tue, 26 Jan 2021 14:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 IIggNx3fPFK4; Tue, 26 Jan 2021 14:18:17 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDD13A02BC; Tue, 26 Jan 2021 14:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YJV8qV8g7cdhynxthQyoLBc86Hxt5SLUoq4aD1ebQok=; b=BTTA8Kt05adXGRzeTT2fHVDRE JJSlHBpdaJj3LiKnM6dRDcByXpD4FcLxLv1GAkE9k3aJSn7fJ39X0s5WGbsJeiwxs3rVR9I1+2Qx+ nYjKNruYqfa2lWOLBg9/3VMFfFV+keewi8y2up7htcSba1s6BzmvMhzxEXZyTM2Lls42U/LyYJxPb GBNiWWsTfiLjMVsrX6AQTiCx/vO5FMtvFEkuH+CDe0jGVhRW5qfmWcDhfTRSGM//zCtJDi6zmWqOd J/ExEo4glr6Xwbsn1J8vJ4Ldfo9vt8dx1tCaKyR97m3wmvEhhrUDuJQe8xceQBtwQi+sGUoKjsIoN 2nB/GNobQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58189 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4Wf3-0009Tm-8B; Tue, 26 Jan 2021 17:18:13 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_31B196AA-A770-4E42-B463-31447AA6C35C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <82D2BE19-7033-4D0E-87BA-0B4E3481AC84@apple.com> Date: Tue, 26 Jan 2021 14:18:09 -0800 Cc: tcpm IETF list , Martin Duke , Michael Tuexen , "Scheffenegger, Richard" , Mirja Kuehlewind , "tcpm-chairs@ietf.org" Message-Id: <4E860829-07EA-43DF-A12F-11A6A98EB96A@strayalpha.com> References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <82D2BE19-7033-4D0E-87BA-0B4E3481AC84@apple.com> To: Vidhi Goel X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 22:18:19 -0000 --Apple-Mail=_31B196AA-A770-4E42-B463-31447AA6C35C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 24, 2021, at 10:41 PM, Vidhi Goel wrote: >=20 > I apologize for the late response. >=20 > I support the "Two options=E2=80=9D but with a suggestion which can = help to eliminate the extra 1 byte. >=20 > How about using 1 Byte (instead of 2) for both Kind (3 bits =3D 7 = Kinds) and Length (5 bits =3D 31 Bytes) combined?=20 Where is this 1 byte?=20 I thought we were talking TCP options. For SYNs and SYN/ACKs, the = approach above violates RFC 793, which defines new TCP options as having = both kind and length - that way, an endpoint can skip over options it = doesn=E2=80=99t know. For other segments, it defeats the point of not wanting to issue two = codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same role.=20 Both are not viable ways forward. > 1. Kind field - With limited space for ECN code points in IP header, I = don=E2=80=99t foresee that we would be able to have many different = =E2=80=9Ckinds=E2=80=9D. =20 > 2. Length field - TCP option length is limited to 40 bytes and with = common options like timestamp, SACK etc, I think 31 bytes for ACK ECN = option should be more than what we can fit in. FWIW, we do have a standards-track update to extend that option length = arbitrarily in non-SYN segments (draft-ietf-tcpm-tcp-edo), once we have = implementations at least. Joe= --Apple-Mail=_31B196AA-A770-4E42-B463-31447AA6C35C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 24, 2021, at 10:41 PM, Vidhi Goel <vidhi_goel@apple.com> wrote:

I apologize for the = late response.

I support the "Two options=E2=80=9D but with a suggestion = which can help to eliminate the extra 1 byte.

How about using 1 Byte (instead of 2) = for both Kind (3 bits =3D 7 Kinds) and Length (5 bits =3D 31 Bytes) = combined? 

Where is this 1 byte? 

I thought we were talking TCP options. For SYNs = and SYN/ACKs, the approach above violates RFC 793, which defines new TCP = options as having both kind and length - that way, an endpoint can skip = over options it doesn=E2=80=99t know.

For = other segments, it defeats the point of not wanting to issue two = codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same = role. 

Both are not viable ways = forward.

1. Kind field - With limited space for ECN code points in IP = header, I don=E2=80=99t foresee that we would be able to have many = different =E2=80=9Ckinds=E2=80=9D.  
2. = Length field - TCP option length is limited to 40 bytes and with common = options like timestamp, SACK etc, I think 31 bytes for ACK ECN option = should be more than what we can fit = in.

FWIW, we do have a standards-track update to = extend that option length arbitrarily in non-SYN segments (draft-ietf-tcpm-tcp-edo), once = we have implementations at least.

Joe
= --Apple-Mail=_31B196AA-A770-4E42-B463-31447AA6C35C-- From nobody Tue Jan 26 18:56:38 2021 Return-Path: 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 0A3453A1114; Tue, 26 Jan 2021 18:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Dg1_-N5AXTUu; Tue, 26 Jan 2021 18:56:32 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72ED3A1113; Tue, 26 Jan 2021 18:56:31 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10R2sBcL060163; Tue, 26 Jan 2021 18:56:28 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=YgQIu/E3EcE3w/ynQBHajHjc42WJAiKEs6ViLfrOb2Y=; b=BDhZHsgPcYFpGG+evvCVAi6sr69a2qZltYUpVVbNo/okNFSTrIQZevbm0hbECLrZlaU8 Dkcw7NX7FTgGOkLoqJNVncZNxMrX2yJps35qsuSMuor01070DkzlvVvTKsO2XjLJKTsM J2XPmCKfyivfqOsf262VTMUGppFa1vtzNEpTR59FBaj071p0kXG98QoVS9n3kwGHDBEw 3ourBmnYNZCr/rVcKGTQ6QpECy9beqR1mvo7VW4d/vRTkclNoujM5UMDCpjDmkzTnrQr qwQ72vPdWBmaH+ZmQJ5Lt5ojvGp5Pfz/gKBMdNcHDT31FtXuceFViKgmjt+cIo5mev54 +g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 368hbwsj5r-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jan 2021 18:56:28 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QNK00BU1O63XN60@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QNK00Z00O3CF900@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -0800 (PST) X-Va-A: X-Va-T-CD: c279b06c8353ce446b254c634a752559 X-Va-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-Va-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-Va-CD: 0 X-Va-ID: 3ce20935-c1ae-49ae-9dc5-2418e41db965 X-V-A: X-V-T-CD: c279b06c8353ce446b254c634a752559 X-V-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-V-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-V-CD: 0 X-V-ID: 2da22301-67f2-4c94-9f9d-0928f42725bd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-26_11:2021-01-26, 2021-01-26 signatures=0 Received: from [17.234.45.201] (unknown [17.234.45.201]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QNK00505O625R00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 18:56:27 -0800 (PST) From: Vidhi Goel Message-id: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_FA6ADFFF-E4E6-408E-B843-2AFB9169548A" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 26 Jan 2021 18:56:26 -0800 In-reply-to: <4E860829-07EA-43DF-A12F-11A6A98EB96A@strayalpha.com> Cc: tcpm IETF list , Martin Duke , Michael Tuexen , "Scheffenegger, Richard" , Mirja Kuehlewind , "tcpm-chairs@ietf.org" To: Joseph Touch References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> <82D2BE19-7033-4D0E-87BA-0B4E3481AC84@apple.com> <4E860829-07EA-43DF-A12F-11A6A98EB96A@strayalpha.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-26_11:2021-01-26, 2021-01-26 signatures=0 Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 02:56:36 -0000 --Apple-Mail=_FA6ADFFF-E4E6-408E-B843-2AFB9169548A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Where is this 1 byte?=20 >=20 > I thought we were talking TCP options. For SYNs and SYN/ACKs, the = approach above violates RFC 793, which defines new TCP options as having = both kind and length - that way, an endpoint can skip over options it = doesn=E2=80=99t know. >=20 > For other segments, it defeats the point of not wanting to issue two = codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same role.=20 >=20 > Both are not viable ways forward. Yes, you are right. Now, that I have re-read the discussion around this topic more, I = don=E2=80=99t see the problem with L =3D 11 or L =3D 12 (with flag byte) = as Acc ECN option length with two different code points. - Vidhi > On Jan 26, 2021, at 2:18 PM, Joseph Touch = wrote: >=20 >=20 >=20 >> On Jan 24, 2021, at 10:41 PM, Vidhi Goel > wrote: >>=20 >> I apologize for the late response. >>=20 >> I support the "Two options=E2=80=9D but with a suggestion which can = help to eliminate the extra 1 byte. >>=20 >> How about using 1 Byte (instead of 2) for both Kind (3 bits =3D 7 = Kinds) and Length (5 bits =3D 31 Bytes) combined?=20 >=20 > Where is this 1 byte?=20 >=20 > I thought we were talking TCP options. For SYNs and SYN/ACKs, the = approach above violates RFC 793, which defines new TCP options as having = both kind and length - that way, an endpoint can skip over options it = doesn=E2=80=99t know. >=20 > For other segments, it defeats the point of not wanting to issue two = codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same role.=20 >=20 > Both are not viable ways forward. >=20 >> 1. Kind field - With limited space for ECN code points in IP header, = I don=E2=80=99t foresee that we would be able to have many different = =E2=80=9Ckinds=E2=80=9D. =20 >> 2. Length field - TCP option length is limited to 40 bytes and with = common options like timestamp, SACK etc, I think 31 bytes for ACK ECN = option should be more than what we can fit in. >=20 > FWIW, we do have a standards-track update to extend that option length = arbitrarily in non-SYN segments (draft-ietf-tcpm-tcp-edo), once we have = implementations at least. >=20 > Joe --Apple-Mail=_FA6ADFFF-E4E6-408E-B843-2AFB9169548A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Where is this 1 = byte? 

I = thought we were talking TCP options. For SYNs and SYN/ACKs, the approach = above violates RFC 793, which defines new TCP options as having both = kind and length - that way, an endpoint can skip over options it = doesn=E2=80=99t know.

For other segments, it defeats the point of not wanting to = issue two codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same role. 

Both are not viable ways = forward.

Yes, you are right.

Now, that I have re-read the discussion = around this topic more, I don=E2=80=99t see the problem with L =3D 11 or = L =3D 12 (with flag byte) as Acc ECN option length with two different = code points.

-
Vidhi

On Jan = 26, 2021, at 2:18 PM, Joseph Touch <touch@strayalpha.com> wrote:



On Jan 24, 2021, at 10:41 PM, Vidhi Goel <vidhi_goel@apple.com> wrote:

I apologize for the = late response.

I support the "Two options=E2=80=9D but with a suggestion = which can help to eliminate the extra 1 byte.

How about using 1 Byte (instead of 2) = for both Kind (3 bits =3D 7 Kinds) and Length (5 bits =3D 31 Bytes) = combined? 

Where is this 1 byte? 

I thought we were talking TCP options. = For SYNs and SYN/ACKs, the approach above violates RFC 793, which = defines new TCP options as having both kind and length - that way, an = endpoint can skip over options it doesn=E2=80=99t know.
For other segments, it defeats the = point of not wanting to issue two codepoints, which is to conserve = codepoints. Instead, it would effectively be assigning 64 codepoints to = the same role. 

Both are not viable ways forward.

1. Kind field - With = limited space for ECN code points in IP header, I don=E2=80=99t foresee = that we would be able to have many different =E2=80=9Ckinds=E2=80=9D. =  
2. Length field - TCP option length = is limited to 40 bytes and with common options like timestamp, SACK etc, = I think 31 bytes for ACK ECN option should be more than what we can fit = in.

FWIW, we do have a standards-track = update to extend that option length arbitrarily in non-SYN segments = (draft-ietf-tcpm-tcp-edo), once we have implementations at = least.

Joe

= --Apple-Mail=_FA6ADFFF-E4E6-408E-B843-2AFB9169548A-- From nobody Tue Jan 26 19:27:55 2021 Return-Path: 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 0A77E3A1176; Tue, 26 Jan 2021 19:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 f14GAc2eBJAB; Tue, 26 Jan 2021 19:27:52 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2C13A1174; Tue, 26 Jan 2021 19:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=q5UUw+QjJ1/A9mgMEEQM4yd6qWDyVok5qcRyOcj0Alk=; b=zEbYuUQbXX1eiHHWlIUPXjXQYD YtftwooxjHK9kIRpdS11uE1fY3C2GY/bVmDcJKLPhQpHeYJek2aVV7nOaEQ62gQ1o48RmoWIy6I5B jdKMVJmY2cWgLXjQmGtD0UUxWfesx2QgLWqRdM8VDB0qq3LM2xkbekzBszD1X9yP7O30Tsaa+f4RT 5B6ymjhbFO212H/SEBKLHBBYwKl5vWgWX0UL6VsCdEVyxEdetAPDjc/lArU2YgMdt/665K9XrZju/ xPG0BeTYzfnh6fJUY67E/nP0gXAhu73udunfd5g0NPXb7hbhYRH4gOalJGIfWMvCdfei9f629n3jG b8PftJnQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51171 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4bUe-001JSx-NR; Tue, 26 Jan 2021 22:27:49 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> Date: Tue, 26 Jan 2021 19:27:44 -0800 Cc: tcpm IETF list , Martin Duke , Michael Tuexen , "Scheffenegger, Richard" , Mirja Kuehlewind , tcpm-chairs@ietf.org Message-Id: <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> To: Vidhi Goel X-Mailer: iPhone Mail (18D52) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 03:27:54 -0000 > On Jan 26, 2021, at 6:56 PM, Vidhi Goel wrote: >=20 > =EF=BB=BF >>=20 >> Where is this 1 byte?=20 >>=20 >> I thought we were talking TCP options. For SYNs and SYN/ACKs, the approac= h above violates RFC 793, which defines new TCP options as having both kind a= nd length - that way, an endpoint can skip over options it doesn=E2=80=99t k= now. >>=20 >> For other segments, it defeats the point of not wanting to issue two code= points, which is to conserve codepoints. Instead, it would effectively be as= signing 64 codepoints to the same role.=20 >>=20 >> Both are not viable ways forward. >=20 > Yes, you are right. >=20 > Now, that I have re-read the discussion around this topic more, I don=E2=80= =99t see the problem with L =3D 11 or L =3D 12 (with flag byte) as Acc ECN o= ption length with two different code points. Please see my note from 12/3/20, which shows how a single codepoints would s= uffice without increasing length.=20 Joe= From nobody Tue Jan 26 19:47:22 2021 Return-Path: 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 03DE73A11AF; Tue, 26 Jan 2021 19:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 wJwMFmCsF_JS; Tue, 26 Jan 2021 19:47:18 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49AB3A11A9; Tue, 26 Jan 2021 19:47:18 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 10R3dSNL062874; Tue, 26 Jan 2021 19:47:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=qjBWg3OkDWM8nAHL084LWdV7PzaLXOsa+uTKJ9HSwWs=; b=aZkmnV1ipdqLrC8jx2Lwkiwu+RDNnyvm0r6clvcrxmFYI7u4uHfLHWZF7ekq7eET8V1i tw3WH26kMwB8EXsF5MjZHxWb0pb8fgnqIzufh7kkwVMpnaD7Ipwy3fYY79yrly+pnlzz v/Ja+DW7uAtj+9UFMiWD4ouY2/HhbsM3NgEFCZfaoNHnpGh68O8NdVmLQqanjSO+mS+a d+IYw9ncTaniEh/9x0eegr2YNDkWCh4MgXJPbeQsIrEoEXMtyXETtu1PWGlTTeaMDQhC tYbwXB+PEvRoJz4PrOQlIRXxTklLT+DgaIKbRhGPsVm+ZcMm76CRleJVwJHTtsy72Owz Fw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 368knyy4mq-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Jan 2021 19:47:15 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QNK003FWQIOLRE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QNK00R00QCQAH00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST) X-Va-A: X-Va-T-CD: fc19b38414bebaf705dacc06d1c6b73e X-Va-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-Va-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-Va-CD: 0 X-Va-ID: 8aeb473c-bd00-45e2-9841-b8eba93a4265 X-V-A: X-V-T-CD: fc19b38414bebaf705dacc06d1c6b73e X-V-E-CD: c397de0df92081fb67992e6aaa66d9e1 X-V-R-CD: 887efa9ca7889cb2b94d9304b8ce126f X-V-CD: 0 X-V-ID: 702849a9-d370-42b7-9078-4e6bfce3552b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_02:2021-01-26, 2021-01-27 signatures=0 Received: from [17.234.45.201] (unknown [17.234.45.201]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QNK00DRCQINC000@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 26 Jan 2021 19:47:12 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Vidhi Goel In-reply-to: <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> Date: Tue, 26 Jan 2021 19:47:11 -0800 Cc: tcpm IETF list , Martin Duke , Michael Tuexen , "Scheffenegger, Richard" , Mirja Kuehlewind , tcpm-chairs@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-27_02:2021-01-26, 2021-01-27 signatures=0 Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 03:47:20 -0000 > Please see my note from 12/3/20, which shows how a single codepoints = would suffice without increasing length.=20 If the TCP option code points is not a scarce resource, then why not = just keep it simple with "two different codepoints=E2=80=9D? Is there a = reason that you think we should use only one code point? Regarding your suggestion of using 1 bit from the 24-bit counter field, = do you mean specify ordering once before the first ECN counter field or = specify before every counter field? For example, if all three counters are present, are you suggesting, a) = or b)? To me b) would make more sense but that makes the implementation = complex as the fields have different length. a) Kind | Length | 1-bit ordering | 23-bit EE1B | 1-bit ordering | = 23-bit ECEB | 1-bit ordering | 23-bit EE0B b) Kind | Length | 1-bit ordering | 23-bit EE1B | 24-bit ECEB | 24-bit = EE0B - Vidhi > On Jan 26, 2021, at 7:27 PM, Joe Touch wrote: >=20 >=20 >=20 >> On Jan 26, 2021, at 6:56 PM, Vidhi Goel wrote: >>=20 >> =EF=BB=BF >>>=20 >>> Where is this 1 byte?=20 >>>=20 >>> I thought we were talking TCP options. For SYNs and SYN/ACKs, the = approach above violates RFC 793, which defines new TCP options as having = both kind and length - that way, an endpoint can skip over options it = doesn=E2=80=99t know. >>>=20 >>> For other segments, it defeats the point of not wanting to issue two = codepoints, which is to conserve codepoints. Instead, it would = effectively be assigning 64 codepoints to the same role.=20 >>>=20 >>> Both are not viable ways forward. >>=20 >> Yes, you are right. >>=20 >> Now, that I have re-read the discussion around this topic more, I = don=E2=80=99t see the problem with L =3D 11 or L =3D 12 (with flag byte) = as Acc ECN option length with two different code points. >=20 > Please see my note from 12/3/20, which shows how a single codepoints = would suffice without increasing length.=20 >=20 > Joe From nobody Tue Jan 26 20:21:53 2021 Return-Path: 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 87AEF3A1209; Tue, 26 Jan 2021 20:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 OiwftAqD-pMM; Tue, 26 Jan 2021 20:21:50 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9D03A1208; Tue, 26 Jan 2021 20:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pdRSg8tnYWG1MzZ2S79qHBDUjzNCd6SFdiG2r3R/o2w=; b=Tr64u9195Y4k0wkTNMqOdC8t0 9Bwgb7ypzRoOrk0nb7gpq1NqpjL8qdojpodeUMVTle4VErEhKhxfsVUBy6oQNq3nNysIcnCAwd7E5 FIyyi+pKm6Spk3dC2Zw5Dn+IoHsjzlzR59rf4Gn5X6ko6w6VwKG8PZ+optpN2a3cYZzIOC9x5onHd Z6Yu3HgxbjT6UW6viVfMNirnJ9Cf12zqZb5KpQ4IF9ynaMhkn6CGdooPtTb2XdKnQO8+4v89cHXj+ P6jCbgo+11laJp/ExvTtBbMyfiK+QCOrC8FALENenZSglXQ2qYr4dNYPkf7syFO+KVRiQS+Dw8PMz 8o4lPqNrA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51636 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4cKr-002Cyy-RY; Tue, 26 Jan 2021 23:21:46 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: Date: Tue, 26 Jan 2021 20:21:42 -0800 Cc: tcpm IETF list , "Scheffenegger, Richard" , Michael Tuexen , Mirja Kuehlewind , tcpm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> To: Vidhi Goel X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 04:21:52 -0000 > On Jan 26, 2021, at 7:47 PM, Vidhi Goel = wrote: >=20 >> Please see my note from 12/3/20, which shows how a single codepoints = would suffice without increasing length.=20 >=20 > If the TCP option code points is not a scarce resource, They are. Very much so. > then why not just keep it simple with "two different codepoints=E2=80=9D= ? Is there a reason that you think we should use only one code point? That=E2=80=99s the core of the discussion we=E2=80=99ve been having. > Regarding your suggestion of using 1 bit from the 24-bit counter = field, do you mean specify ordering once before the first ECN counter = field or specify before every counter field? > For example, if all three counters are present, are you suggesting, a) = or b)? To me b) would make more sense but that makes the implementation = complex as the fields have different length. >=20 > a) Kind | Length | 1-bit ordering | 23-bit EE1B | 1-bit ordering | = 23-bit ECEB | 1-bit ordering | 23-bit EE0B > b) Kind | Length | 1-bit ordering | 23-bit EE1B | 24-bit ECEB | 24-bit = EE0B The point of the bit is to encode the different kinds. (b) does this = just fine. If we want all three counters to be the same length, simply = do so and require the other two =E2=80=9Cfirst bits=E2=80=9D to be zero. Joe From nobody Tue Jan 26 23:45:02 2021 Return-Path: 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 96EB53A1496; Tue, 26 Jan 2021 23:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=eggert.org 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 DHwMGLFSSsL1; Tue, 26 Jan 2021 23:44:58 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FAC3A14A1; Tue, 26 Jan 2021 23:44:58 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:346c:dde7:2098:873d] (unknown [IPv6:2a00:ac00:4000:400:346c:dde7:2098:873d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 03952600073; Wed, 27 Jan 2021 09:44:45 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1611733486; bh=ZJs0c09vCvYgWh77Y1Uh9xqwM/K2ltwDc1ToXZlXqHE=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=weJDtmyJSWDMUmOX3l2RaUFOviIorU1+pF/L0+8HMhIh+q0UJYKV2/UG0sRE8GzwW wJh9YPuaCCaMYPyxoYx9j2kjENb3Y42gC99h66TEXpeACEwZglDDo2CAc1VwUtxBUr 76s2v2KCW0EJ7f9SAu6nRFs9z0fmi9T5LHAqsNZ8= From: Lars Eggert Message-Id: <4AABAED3-4F64-47C6-9243-6864652765D0@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_90CF6FE8-C83C-45EC-8926-19E7322A11FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Wed, 27 Jan 2021 09:44:45 +0200 In-Reply-To: <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> Cc: Vidhi Goel , Michael Tuexen , "Scheffenegger, Richard" , tcpm IETF list , =?utf-8?Q?Mirja_K=C3=BChlewind?= , tcpm-chairs@ietf.org To: Joe Touch References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-MailScanner-ID: 03952600073.A09F8 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 07:45:01 -0000 --Apple-Mail=_90CF6FE8-C83C-45EC-8926-19E7322A11FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-1-27, at 6:21, Joseph Touch wrote: > On Jan 26, 2021, at 7:47 PM, Vidhi Goel = wrote: >>=20 >> If the TCP option code points is not a scarce resource, >=20 > They are. Very much so. = https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-p= arameters-1 shows ~200 out of 256 that are still reserved, i.e., = available. So we aren't in any danger of running out in our lifetimes, = esp. given the limitations in the SYNs. That said, there might be other arguments for why a single option number = is better/cleaner/nicer, but I don't buy the scarcity one. Lars --Apple-Mail=_90CF6FE8-C83C-45EC-8926-19E7322A11FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmARGe0ACgkQVLXDCb9w wVcucQ//WWCRefVkrxWqTZUbx2Jvk3rmM4Z7DKdOdmky84U+Tcs9W3Onktr9b+5F QAHsvmIhOTpBJe2NUQn0+worWu18+G4x2NdWRIkXyyHb5NvMLiVvn/WtMJaKExDE oWBo6z5vXk2QxqYtq6t/+WHR6y7vsTTqF1BQykYHzP71htDWzb9KWW08tlEByNSQ H2p1qgOULXHed1+Iilz+v5RdZImcD7+laq8qhGunZYHwFM2cMeV00L0JHtNRRPzv A8S5V86V7X+q9pAFRO7fBXHIXMkAXY4V1SsBpQZV271IWhpY+Z1XpN/CMCKPJKdP v3oyuPdTStTgw7zX+NpTXQsgxH9tV5Mtkul7C2L4ceXdhIBgtaF0NUEFImkAGLA/ K4rhGfunTTdRCUKB0QxTCPM4oHHruLe9JfqeA0E4uE6Dy7i+fpBSGzB6dOYbKp9F qoselFP1C6jLrm5pQvqlcsESrffEauVG0cutFt07Ta6u0Uo9wE9OkBpbe8tCVsJC lDXVwwY12XrRhhwSOf8leeU7QP2mF5ZQ6E20wNRCttRNKAi23zLT9Tj4anD5OuL4 FN7QcMHmtJ3VRfJmN/tK07xOQFjdDe28WALDUMmgA84HclKKY9JG90dwV2xchzi3 8uCpZEV/wGOq7PA6/JITR3/o4tTGXDPXSsV2FbtJjoG9yNMNeX8= =z9iO -----END PGP SIGNATURE----- --Apple-Mail=_90CF6FE8-C83C-45EC-8926-19E7322A11FA-- From nobody Wed Jan 27 01:44:03 2021 Return-Path: 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 82F183A0BF7; Wed, 27 Jan 2021 01:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netapp.com 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 fJ2fzIcUhj6x; Wed, 27 Jan 2021 01:43:58 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2050.outbound.protection.outlook.com [40.107.243.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40023A0C00; Wed, 27 Jan 2021 01:43:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mkqR4Mf/S7/qZWHzEEo7OrA4qKQzdEDDugD0ErkDamEy0PY/ISH0+DUaz55naFQMLwBor2jy876mXrsPLZE5JP/kDAr/TvpK06WgnSMAK9ny1gQskdRX31rg9mEDIG4RYkz0o7xbDSnaX9kQ24nyhqgNSZiiz8dTsvkKEPU3NGhrfpGwSSKVPDlY3PMMkX7v77SvksP0wuELrI6eDJx2+JZQ/MLzrg1IXI8cTeJomGg2Db2duPyMKUuPcJsquH9axRnHxeFQtayE5TfBfRFamW0iWVEiSrJk/d4mjEt31loKyraJEPN/0x66O9TAY1h4JE25+gN75vCw+7OiMQID0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WS3ree0444wFs6vQEjrCtahZTXpL8flEcbLNg9CuqQg=; b=QHwPt5prvvDEya7wiCI72DSm398oF+e07nmAZvEhpvITn+BDzvLX4csJS3dFYPk53mUTg+E3I4JakAK4DQcxaNmeZFaBIkkLJ6N/tAKIexZoKzWND3cdngMQ80vvZZ9JMf/+EjPfva4pUCCx4iMv5rAHqCac63J17QkbfjnR9FUzVPQEg2JbYcwS9Cxi2cvuaFYRZDV6kXvOJfsk+SHpOpG06y2tfrNEM1P3iCVBHg/eVmFx35jYHvzkYVQoVl+tVj4GIhtMRM8NzwVDWl6fRhJMhYKp7XARQwMKNPosF7OxJBWbcJ+tRPBuuUsh/GqWw2T+Bs3eIy0WQ1euKpy+zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WS3ree0444wFs6vQEjrCtahZTXpL8flEcbLNg9CuqQg=; b=VfaZDxrkE1s4c6nbNistGKAf+N2+iomAijX9gtCOqH2S+IEQ0fhWeSxWP2kU21KdStpDh793cB00b1btmpkL5dShpmDcD1z13tPxnwPNk31aGNndo7cBGzGA8nPuyGiTgH14Lp3s53WkOD3l579HhcPqagVbNrR0bJi4nGHi0UEZ0XuiUsFNDqdqNk47zYae0zLpXiPvEkh18fnkv8qpPAl/JRxNrogLnIsyMGAGZp65CQisdJkHdXLzWiwgHynv5Qxq6/6fZcc5JLh4A7gEIE4ul5TvtHKVyG/7qNLOScPQWkgrrhGnNrSCD72LT9khjRB63xF3bjbJ4K+yT8Jl2g== Received: from SN4PR0601MB3728.namprd06.prod.outlook.com (2603:10b6:803:51::24) by SN6PR06MB5118.namprd06.prod.outlook.com (2603:10b6:805:c5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.19; Wed, 27 Jan 2021 09:43:54 +0000 Received: from SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::1551:a759:21c5:fd41]) by SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::1551:a759:21c5:fd41%7]) with mapi id 15.20.3784.019; Wed, 27 Jan 2021 09:43:54 +0000 From: "Scheffenegger, Richard" To: Joseph Touch , Vidhi Goel CC: tcpm IETF list , Michael Tuexen , Mirja Kuehlewind , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] AccECN field order Thread-Index: AQHWvDjzOJzuvj4he0uzhveqyjTda6nLBXMAgADB2wCAADJ1AIAARcGAgAAi6oCAAKG5gIAIndMAgAAQZaCAECpGAIAAB5iAgFJtdwCAApgbgIAATcAAgAAIvwCAAAVvgIAACaUAgABY9CA= Date: Wed, 27 Jan 2021 09:43:54 +0000 Message-ID: References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> In-Reply-To: <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [91.141.1.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17eed7a7-40e9-45f7-d9c9-08d8c2a80f82 x-ms-traffictypediagnostic: SN6PR06MB5118: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KUbE+EufAddkMwm2JnRlJfeNvUeQ+DoS6AYrwLxOBj2FJl6Xbud6EA15qAeE4MJ3jxDm+j2W1m2rzQqmHaV4pfCddQ+LICKKxIxSVAP08zF7rY0UzDen/OSVqPqUMRYkAMcuDJJXz3pywiCNQk5dQCCP8CbHuEwYJgFT98rwCe4A1LBPd5vigzNd7du3cczUw7eI7DbSLnCV7KWqSPaBaqgXzukAXh0QUGS00Zv3pV7B5bk6NmI2XHiA2dshurwbGzrLHBj/aNEJ4pjeO2j0GKrtNC8yFp/OZ1usqw0K3LWOSsPv05P31xxRY+ukf7qtL+eU6S8vhoaRwWMSvEXESU4+Jl7pgotvhyMdPGTsEqXx/G+Nb2HohI5CoLxEHo2ZjgRp+0kpP3jumNgji1/MYQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN4PR0601MB3728.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(6506007)(83380400001)(478600001)(66476007)(64756008)(86362001)(33656002)(26005)(53546011)(2906002)(110136005)(316002)(66946007)(186003)(8676002)(76116006)(7696005)(66574015)(66446008)(66556008)(54906003)(55016002)(9686003)(71200400001)(52536014)(5660300002)(4326008)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?YU9QbVdPdFdPbU9FTlo5WUlMK0xIaWV0K21UeUU5K2djdnNKc1A0S0lnRlhv?= =?utf-8?B?QmhkYnoxWm11YWtQN1FRam1hNUNsS3pISCsxQXlNY0taN1RHdDhnRFNSdDBH?= =?utf-8?B?M0FRN2tHbFJwUG82ZGRvYStmZ2EyeGV3UmhYZmJCSWRvaUlKVCtPdGZWVEV4?= =?utf-8?B?Ym9kcWhzdGdvQlh1WFVkNHpKdnNTSHd2bmlGMCtuNkVBTE9ZRTdPWnFXNE9J?= =?utf-8?B?M0J3UXcvWEJtZkFMYUQrQitTMjFnTmIrd1JtdTdIUTFZVDhRcDVDMms4Zm5T?= =?utf-8?B?NWJ4eVpWNXA0OGMwdlNVdTlyTml6NmJxMXdnTU9YQlBqK0lrVkUzU3EvOUpG?= =?utf-8?B?Q2hSc1NCZkRJTjU4V21XMXByenVaTjd0SVFkU1dLRzVPNDJEd1NtdFNPVlB2?= =?utf-8?B?aWpxVGQ2dmFaWjA2czRNRXJmRkNnSktpR0t6M0xRSlhRdmRMMktvZVlMWUFG?= =?utf-8?B?bzNpT1ZOZ3R5YjVyTTJNTDlyZnRTd0JJVW5keEU5MDJCN3hiQXREQytEdEdx?= =?utf-8?B?a3krdlJ2bzFWUm1jbnJUai9rbW5kbFBNcUNSUEVtb2dET0RoSGNocmJ0Rkt1?= =?utf-8?B?V216Um51dlkzdSswSG5ncTU2Rm96N0dORVloVkFyV2RiM216OUlDS1lpSVZP?= =?utf-8?B?YWp2UVZoSTBQZTl5Z1lVaWQ5VVFpSjRpSjRoQ1pMUzN3RkVmUzkxMUhzeU1t?= =?utf-8?B?ejdrTjgvV1U1RUd1RFVjQWpVTk5tVUZ4VzY2Q3YzNjY3S0w4bXlTMmduTmg5?= =?utf-8?B?amd0UWFxQjVXbGxQUWNVTExvbVQzK0FUcy9nVU0xWEFvaURZdFp5RFFaMFgv?= =?utf-8?B?Ujh4VXNpUktNcHMzZ3dUUHBIZWFIdnpNbkVleFNORkdHekFsOHdCclM3NFEw?= =?utf-8?B?Z214UUF4Wi9ZZGFVdElvbXRkbVQ0ZDRCZ09oMVU0elJlZEZQUUtMZG5NOUd2?= =?utf-8?B?VzdnTDNINHZhbEFMaXR3Wk1ydVNWVDFCSC9GUlUyV3FSRTdHZWhrOVpvWEQy?= =?utf-8?B?dmdzaGJkR3JLQTFBbFlDS2YycHZoWkx4RFJJanMyb2RWRGYzTkxWYmg1cXNx?= =?utf-8?B?cGtLQ1dheGx2YTlVMVZxczg1T3RoZ0daUkM0M3hOMnlTb1g0ZFV3T3YvcWtx?= =?utf-8?B?b1M0Q2Nsa1VrTkNVZWsreTVqdnJxVDg0OEtpTXZNWkpQOG1BbzlCZmU2WXJJ?= =?utf-8?B?Sk9uaGg2dTZrdm9kMHJ5K0ZTelpWd1BFNHBxandXd1pXNmxyTERsbXZxZHlx?= =?utf-8?B?SUZrampKUGdzYnZERjFuNTNEbWVyWER0RStnWS9Jd0xseXFlQ2VZc0ZiZHhE?= =?utf-8?B?U3JGMUU4bWI1cTI2SWRRcmlub3dOejJuUjRnc0M3OW9lL2lZL1BLMHIwb1VI?= =?utf-8?B?QU01MmRJdGxCM3lSV2VMT1liS0VZMG0wYkp2aDJyWUJlNURJYm5vci9mTHVB?= =?utf-8?Q?4ZZvQ4TA?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN4PR0601MB3728.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17eed7a7-40e9-45f7-d9c9-08d8c2a80f82 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2021 09:43:54.1993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JJS7wdpj0tDD8tx5yOQjovUmCSjqb+zpT7GlFBRyhuouEY4ONGhTjJJkh+dG4j92gnjbsL3Azabo8FnRvpqmeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB5118 Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 09:44:02 -0000 SnVzdCBmb3IgY2xhcml0eSwgdGhlIHN1Z2dlc3Rpb24gd291bGQgYmUgc29tZXRoaW5nIGxpa2U6 DQoNCiBLaW5kIHwgTGVuZ3RoIHwgMS1iaXQgb3JkZXJpbmcgPT0gMCB8IDIzLWJpdCBFRTFCIFsg fCAyNC1iaXQgRUNFQiBbIHwgMjQtYml0IEVFMEIgXSBdDQpBbmQNCiBLaW5kIHwgTGVuZ3RoIHwg MS1iaXQgb3JkZXJpbmcgPT0gMSB8IDIzLWJpdCBFRTBCIFsgfCAyNC1iaXQgRUNFQiBbIHwgMjQt Yml0IEVFMUIgXSBdDQoNCldpdGggdGhlIHR3byB0cmFpbGluZyAzLW9jdGV0IGZpZWxkcyBiZWlu ZyBvcHRpb25hbCBpbiBib3RoIGNhc2VzLg0KDQpBbiBpbmNyZW1lbnQgaW4gdGhlIENFIGNvdW50 ZXIgd291bGQgcmVxdWlyZSBhdCBsZWFzdCAxKzErMyszID0gOCBieXRlIFRDUCBvcHRpb24gc3Bh Y2UuDQoNCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBO YWNocmljaHQtLS0tLQ0KVm9uOiBKb3NlcGggVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPiAN Ckdlc2VuZGV0OiBNaXR0d29jaCwgMjcuIErDpG5uZXIgMjAyMSAwNToyMg0KQW46IFZpZGhpIEdv ZWwgPHZpZGhpX2dvZWw9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogdGNwbSBJRVRG IGxpc3QgPHRjcG1AaWV0Zi5vcmc+OyBTY2hlZmZlbmVnZ2VyLCBSaWNoYXJkIDxSaWNoYXJkLlNj aGVmZmVuZWdnZXJAbmV0YXBwLmNvbT47IE1pY2hhZWwgVHVleGVuIDx0dWV4ZW5AZmgtbXVlbnN0 ZXIuZGU+OyBNaXJqYSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsgdGNwbS1jaGFp cnNAaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBbdGNwbV0gQWNjRUNOIGZpZWxkIG9yZGVyDQoNCk5l dEFwcCBTZWN1cml0eSBXQVJOSU5HOiBUaGlzIGlzIGFuIGV4dGVybmFsIGVtYWlsLiBEbyBub3Qg Y2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUg c2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCg0KDQoNCj4gT24gSmFuIDI2 LCAyMDIxLCBhdCA3OjQ3IFBNLCBWaWRoaSBHb2VsIDx2aWRoaV9nb2VsPTQwYXBwbGUuY29tQGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4NCj4+IFBsZWFzZSBzZWUgbXkgbm90ZSBmcm9tIDEyLzMv MjAsIHdoaWNoIHNob3dzIGhvdyBhIHNpbmdsZSBjb2RlcG9pbnRzIHdvdWxkIHN1ZmZpY2Ugd2l0 aG91dCBpbmNyZWFzaW5nIGxlbmd0aC4NCj4NCj4gSWYgdGhlIFRDUCBvcHRpb24gY29kZSBwb2lu dHMgaXMgbm90IGEgc2NhcmNlIHJlc291cmNlLA0KDQpUaGV5IGFyZS4gVmVyeSBtdWNoIHNvLg0K DQo+IHRoZW4gd2h5IG5vdCBqdXN0IGtlZXAgaXQgc2ltcGxlIHdpdGggInR3byBkaWZmZXJlbnQg Y29kZXBvaW50c+KAnT8gSXMgdGhlcmUgYSByZWFzb24gdGhhdCB5b3UgdGhpbmsgd2Ugc2hvdWxk IHVzZSBvbmx5IG9uZSBjb2RlIHBvaW50Pw0KDQpUaGF04oCZcyB0aGUgY29yZSBvZiB0aGUgZGlz Y3Vzc2lvbiB3ZeKAmXZlIGJlZW4gaGF2aW5nLg0KDQo+IFJlZ2FyZGluZyB5b3VyIHN1Z2dlc3Rp b24gb2YgdXNpbmcgMSBiaXQgZnJvbSB0aGUgMjQtYml0IGNvdW50ZXIgZmllbGQsIGRvIHlvdSBt ZWFuIHNwZWNpZnkgb3JkZXJpbmcgb25jZSBiZWZvcmUgdGhlIGZpcnN0IEVDTiBjb3VudGVyIGZp ZWxkIG9yIHNwZWNpZnkgYmVmb3JlIGV2ZXJ5IGNvdW50ZXIgZmllbGQ/DQo+IEZvciBleGFtcGxl LCBpZiBhbGwgdGhyZWUgY291bnRlcnMgYXJlIHByZXNlbnQsIGFyZSB5b3Ugc3VnZ2VzdGluZywg YSkgb3IgYik/IFRvIG1lIGIpIHdvdWxkIG1ha2UgbW9yZSBzZW5zZSBidXQgdGhhdCBtYWtlcyB0 aGUgaW1wbGVtZW50YXRpb24gY29tcGxleCBhcyB0aGUgZmllbGRzIGhhdmUgZGlmZmVyZW50IGxl bmd0aC4NCj4NCj4gYSkgS2luZCB8IExlbmd0aCB8IDEtYml0IG9yZGVyaW5nIHwgMjMtYml0IEVF MUIgfCAxLWJpdCBvcmRlcmluZyB8IDIzLWJpdCBFQ0VCIHwgMS1iaXQgb3JkZXJpbmcgfCAyMy1i aXQgRUUwQg0KPiBiKSBLaW5kIHwgTGVuZ3RoIHwgMS1iaXQgb3JkZXJpbmcgfCAyMy1iaXQgRUUx QiB8IDI0LWJpdCBFQ0VCIHwgMjQtYml0IEVFMEINCg0KVGhlIHBvaW50IG9mIHRoZSBiaXQgaXMg dG8gZW5jb2RlIHRoZSBkaWZmZXJlbnQga2luZHMuIChiKSBkb2VzIHRoaXMganVzdCBmaW5lLiBJ ZiB3ZSB3YW50IGFsbCB0aHJlZSBjb3VudGVycyB0byBiZSB0aGUgc2FtZSBsZW5ndGgsIHNpbXBs eSBkbyBzbyBhbmQgcmVxdWlyZSB0aGUgb3RoZXIgdHdvIOKAnGZpcnN0IGJpdHPigJ0gdG8gYmUg emVyby4NCg0KSm9lDQoNCg== From nobody Wed Jan 27 09:12:39 2021 Return-Path: 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 06CEA3A09E7; Wed, 27 Jan 2021 09:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 XhVhCrn5rmcp; Wed, 27 Jan 2021 09:12:36 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B9A3A09CF; Wed, 27 Jan 2021 09:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FPYmjxHJHVr0s4/2+C6k5MACUrMZWzxi2xAl7DJPFQQ=; b=MZmI8CVbUjEab5G36UFJyOpzt uFo+3ka2iUPpQk7DFMlHyRYwl9EjEiIf91WoGz9+S7ghfQbJdL1zkkSjdAw2q0V7cEDz3p9EyYUKh yqoCYVq5ENvZROSgbLkYEkolCZ11Q0799Di7TJiQIvO4bv/VFKqN9+/5yNj6tSK6fbjl7qcI1QrUd m6vHPFItvtqG9/uYqWn1N0U45iC58MBQJpNFiqhoywdu/EI76Hx8fOHVPxLvNifvoBUxziGYuVE7W lZYsVuHDC+awUs85l/E+RlI4mk1G+ETDdb/s6PioMUhgeoTA8KobIXsFn24gaytR9WyfWVTBd3k3R e8Ng4UJSQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56027 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4oMo-002nBN-0v; Wed, 27 Jan 2021 12:12:34 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <4AABAED3-4F64-47C6-9243-6864652765D0@eggert.org> Date: Wed, 27 Jan 2021 09:12:30 -0800 Cc: tcpm IETF list , "Scheffenegger, Richard" , Michael Tuexen , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Vidhi Goel , tcpm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0780572E-1718-4FA9-B621-F5F6D294F8A4@strayalpha.com> References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> <4AABAED3-4F64-47C6-9243-6864652765D0@eggert.org> To: Lars Eggert X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 17:12:38 -0000 > On Jan 26, 2021, at 11:44 PM, Lars Eggert wrote: >=20 > On 2021-1-27, at 6:21, Joseph Touch wrote: >> On Jan 26, 2021, at 7:47 PM, Vidhi Goel = wrote: >>>=20 >>> If the TCP option code points is not a scarce resource, >>=20 >> They are. Very much so. >=20 > = https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-p= arameters-1 shows ~200 out of 256 that are still reserved, i.e., = available. Granted, that=E2=80=99s just over 20%. IP protocol numbers are one of the most scarce of popularly used = codepoints, running over 50% assigned. Transport ports are running somewhere around 12%, and we also treat them = as a limited resource. So scarcity is relative.=20 However, we=E2=80=99ve assigned 3 in the past 6 years (not counting = this), and nearly every time the request started by asking for more than = . As you note, there isn=E2=80=99t any risk of running out because we = also recognize that every assignment becomes a potential argument for = precedence for future assignments. This is why we treat them as scarce. Joe From nobody Wed Jan 27 09:19:34 2021 Return-Path: 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 113943A0C9D; Wed, 27 Jan 2021 09:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 OVZWWGDuvmjQ; Wed, 27 Jan 2021 09:19:31 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0F3A0C94; Wed, 27 Jan 2021 09:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SqanqugLcHK7kyvWzjrq+TqIwOYJ/fOFEn7jfw60U40=; b=Loh8WKAeZKUWo8m+cEDHerQxl QZmRlBrjv5gNB+qQPFKVgkPmkt7EnY0e1pAsfmMBSbRsItjF/+1lu188UzRcQQGU+XcVM63FKq3ml C0nbMOAMVGkcpxsl7yM8b8h/Sq8s5C+CjW0FZiqLUA2lrkGz0ob/8GpeK5G7xWjmHlQ706Dv9ROGk MtL4HK5jWotQLW0PUKgJyW7QdmC+Ra0Lz/bPjbaag+tNEgYdFXm4UaE65A0yMQb4Iyo/WfiqwUar1 yV4YRHK97RjzlX2+qK/igZdTtji2pidEQeVEeKPIh3JEEJr+bzswUD6bDibFPNatqFcIZVdqocCcj pHTlkv/Ow==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56448 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4oTV-002ten-TP; Wed, 27 Jan 2021 12:19:30 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: Date: Wed, 27 Jan 2021 09:19:26 -0800 Cc: Vidhi Goel , Michael Tuexen , tcpm IETF list , Mirja Kuehlewind , "tcpm-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <95ACEF0A-61F9-44E7-8BD9-8C1FADCD2583@strayalpha.com> References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 17:19:33 -0000 > On Jan 27, 2021, at 1:43 AM, Scheffenegger, Richard = wrote: >=20 > Just for clarity, the suggestion would be something like: >=20 > Kind | Length | 1-bit ordering =3D=3D 0 | 23-bit EE1B [ | 24-bit ECEB = [ | 24-bit EE0B ] ] > And > Kind | Length | 1-bit ordering =3D=3D 1 | 23-bit EE0B [ | 24-bit ECEB = [ | 24-bit EE1B ] ] >=20 > With the two trailing 3-octet fields being optional in both cases. >=20 > An increment in the CE counter would require at least 1+1+3+3 =3D 8 = byte TCP option space. It would anyway unless we=E2=80=99re now talking about three TCP = codepoints. Strictly, if only the CE counter changed, that could be accomplished = using only 5 bytes by adding another variant, determined by the length = being 5: Kind | Length | 24-bit ECEB At some point, the flexibility in this option needs to be supported = within the option itself. Joe From nobody Wed Jan 27 10:17:47 2021 Return-Path: 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 551793A0D47; Wed, 27 Jan 2021 10:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netapp.com 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 bVEMA67v6d7r; Wed, 27 Jan 2021 10:17:42 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2051.outbound.protection.outlook.com [40.107.244.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC3F3A0D50; Wed, 27 Jan 2021 10:17:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GAddAOkTpDSVjcu4YJ5eJyzZXzt2APkUL0tCBWKardQVkVkZJSPyDoyc2E09sG3om6LUddsXoPyFEcvtoj9ZKTU0W8bHiwo3lMgaWuKNXm6S+rHfUaBx02Ww9ka8IVpVuHBEjwkCN1mmazJ4NbA6GmERS98iCDWRufQFuecQv9MZQGR3ZH2mvOuvEXzwTLorv2lj3cD3Ub4LfyOVUSNqddYoGpEodk6yeB5BCN01L/2dlepLKodE4Y4U+qoUZDGnEhwGYlFwKjNzzQsVZsQinecCG+oCTkyVak+gT58lZCrwEpIt9vzkXWkg6LfSSpCNCVvbLBWKkLRAbHjl6AP6oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSiLlF7A1/lNWRFKriCTlvQMppc++U2XRN0K0NawuCo=; b=G2yzw1tswPJ11jen5T8LmctqG/UbZacAIYv4LusCmJxuSTVWca3CbDhhsMWgnQIyULT30utiTndfUBluXtoxwUQP2tn8f8rKdRWNVBTL0jAyAWHUmLPiuUsbyMsfBMz7lfv/tDxf5v7+psGxFLivAQnQvIDTSIFpk9fd7ef4bcAS2g99iz8C9bT0DUXh7i0UJiO2TSGkG7avDVr2FzIWAzb/C66A8eLtczaL+8wHysuJlkO8szsDTsQKIK8cdlLbtUeC/8cIVgh5umkLr332I9P3BAW9sTw1O7I/sGDIsX4wxWHluN1LtRJxPsV7tqwdKR0WYresxAwuWtnKnw843w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wSiLlF7A1/lNWRFKriCTlvQMppc++U2XRN0K0NawuCo=; b=T3wR305zzs7kyDt+S6af4qmT34ZvNYTkml8birE8RJLgxZhnNCAJihXqwDNhJIx9WjQdRrey/1iOa6/KilV4A3KmWR9z7+dhaISujoMwSg9oE5EO0CR9jxuE4Cj/NRCRNDO830rqquFFNOJ7NQJB+OOayUt5C6YpdGnZm9gdjcb8CnY9+6PN/XyFRr1yzyAXwQLVv/kMCp9BJ/grRQfT0Dsv/ncrJi5GqFprZLyQGXbGJ9zEJfLwNYGyMZGgfQ+E47aho8y19d2TsP0ZJHHHxVE3XXKPk1tKd1/HLJBCzGw38eb5cZv5+V4nD69CsxloU6vBukD2/1mDsF4AbsCfzA== Received: from SN4PR0601MB3728.namprd06.prod.outlook.com (2603:10b6:803:51::24) by SA2PR06MB7371.namprd06.prod.outlook.com (2603:10b6:806:135::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Wed, 27 Jan 2021 18:17:41 +0000 Received: from SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::1551:a759:21c5:fd41]) by SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::1551:a759:21c5:fd41%7]) with mapi id 15.20.3784.019; Wed, 27 Jan 2021 18:17:40 +0000 From: "Scheffenegger, Richard" To: Joseph Touch CC: Vidhi Goel , Michael Tuexen , tcpm IETF list , Mirja Kuehlewind , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] AccECN field order Thread-Index: AQHWvDjzOJzuvj4he0uzhveqyjTda6nLBXMAgADB2wCAADJ1AIAARcGAgAAi6oCAAKG5gIAIndMAgAAQZaCAECpGAIAAB5iAgFJtdwCAApgbgIAATcAAgAAIvwCAAAVvgIAACaUAgABY9CCAAIBYAIAADZcQ Date: Wed, 27 Jan 2021 18:17:40 +0000 Message-ID: References: <2A6CB682-8D99-48AE-A053-1685BA480BB3@apple.com> <880A9E0C-FBC9-4ADC-A11D-C5D3FDDDCE14@strayalpha.com> <8B6B13CD-94B5-4C0B-8771-F008C390A661@strayalpha.com> <95ACEF0A-61F9-44E7-8BD9-8C1FADCD2583@strayalpha.com> In-Reply-To: <95ACEF0A-61F9-44E7-8BD9-8C1FADCD2583@strayalpha.com> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=netapp.com; x-originating-ip: [77.119.130.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42a4cff5-c118-4abc-0081-08d8c2efd59f x-ms-traffictypediagnostic: SA2PR06MB7371: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BtcioJmHd0Fp3rTBaZeXGgVp2LKpFaBzWRFxpr7ub3HmobGObPFIqmyLCxm9D0N01hVP5wvervrXAffWAOLaTofmBRHbXtPi+IB+N05ESnvpcOWlWwwyVEyIFgzibLt3kOHl9TAAfG2mxdlcgUm36SmMzNgOQBD9Z2XBRPjf27iAMUDtWMPXbfmhlPFDpT8diA+aF/1BuhDlYUW1RFQsfiwy55zEQcDvM0Si/w/3tZNw4fFwSqUv29IQRVCVOyPeZ38I9qT8N+nsdiPj6EzktNsx7UmPDunne/hq9frdBaZcqvohm6caOVZ7qv7ZjhJMRgcffGic55mM6/ueiqh1hPjFiUGhjzdsFtUXbD08IdzmLYUuDMAo7w3ap2gN+f4nb7+0Cwum/ASm6UAIZZ1dawGSuX02P7X2YHoUeJ2P0l6NvpiUgwa6qJqk67L6hk4ZzyLVhPv/pfupxRAsDlfz1xNyh/sfnAGxfsJye+xLnTR9icK0Lihufj6NoLMUl2V/jfxRsxNmT3r4apbRAdaymA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN4PR0601MB3728.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(396003)(136003)(346002)(366004)(66556008)(64756008)(186003)(66476007)(9686003)(5660300002)(66446008)(55016002)(52536014)(76116006)(8936002)(26005)(2906002)(54906003)(8676002)(7696005)(53546011)(316002)(71200400001)(66574015)(86362001)(33656002)(6506007)(6916009)(478600001)(83380400001)(4326008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UEFhQ1BYZlJRbmQrWXRnakNvYVlDNVl6RGZrQXV6Rlp2SHNSZWNEamlZZDgv?= =?utf-8?B?YTh3WXhCaEkyN2NpUkxpcTlPMGdFVSt1MEY1NjY2L0U5SitVYmpSMkxINEg5?= =?utf-8?B?RXR1MjZ3dlpXcTQ0QVJkcnFicTBJelg4R3dja2xiNWsrK3FUb0hENFZBZ2Y5?= =?utf-8?B?aDZWbCtwUVZzNTFBeXNVQWNWc3dVM1F6NnJtRFpyc1RHWEt1UFU5M21UNWVD?= =?utf-8?B?OE8vOTR2bjJQUjhZSndQdHJTVTRTaHBIZjdhWGlaUCs3R25PeFpGVUQ5bW1Y?= =?utf-8?B?YWlySDRzd2FNUWgrREYvODR6Vyt5WlBuaTRZS2ZpWW1tR2NlMUk5TUo3b2Rj?= =?utf-8?B?UTFnU255eDJocmNrUlhFK3FVWTBRMmo3ZzF0YmVmRjRlUWNLdmRnWjFQUW51?= =?utf-8?B?dnRLVExpOXozNWgzK2lXbWF3VXRYSlVPUm55bHRuVkpUa0Y4YVMrcmtYY0Vv?= =?utf-8?B?N1M0UTJOMWFTWFl3SFZlMVlvd25HRTUyQ1F1Y0kwWU42aGwvd05ieHJtekFI?= =?utf-8?B?V0hIa0MyUXdPb1BDQityUThSWlVPR0JZZTBsKzFudHR2VGFIQllTNkxienpn?= =?utf-8?B?OWZFZ3B5QzhqVFBPWitQaFdKOVlqVEZ2bzN4RmQxT3NLc3VJYVdJTWV0MG56?= =?utf-8?B?WUlIK1NMdjc1eHl3M0h2YktRY0xMOEdVeXZOY0huRUhiVmI4UktRY2NOejEr?= =?utf-8?B?ZVhkVVMrZ3FFVHNFMFcvbnFPd1BiWEJxMi9hUllWdU5HQmZmR0YvSCtCeVk4?= =?utf-8?B?YWt0aDdZL1dYL3FUa1liQTNXMjBPR1FSc3ZVUnBsaG4xMmZSWWphdjlLSndh?= =?utf-8?B?a210ejBpYzNSdm9BajdhNTJSc1JzWnYzRHIzanF2dWtONkJSSTNZOXlvM2oz?= =?utf-8?B?c2FtYWF3UkphYWNtNEt2MER6ZGVMNGNhc1hpc1Y0Sjc0MVJ6Qi83MVZoRmNH?= =?utf-8?B?cENYYzdwQTUwUjYxVzNDOXVYKzRPcnBBRmhUYXRxQS93ZkVsUDM0ejRkWFY1?= =?utf-8?B?aTdkNzE3ZkdDTjRLNnVBWGNJdEdsWUVWekU5UUxrM00wSm1FcVZIb2tkMGo1?= =?utf-8?B?MGkvUWRBSHZaMFFhb25mN2JuQzhWbGV1YlhqUmxRM1BOSTFYT09NVzc5Q3Fk?= =?utf-8?B?SEZCVStYdzc4eG4wUGdCRC82bkF2M1ljb1pFSytBMUs0U21oeGY0bkVBRG5z?= =?utf-8?B?U3dpYm9DdC9vL3VJZng4YTZXZGozeEJZVHNqTnBWVThNODM0RThiUjc4enBq?= =?utf-8?B?bVBFbFFDY1JNL2E5Si9DR2tEZnp4RllvWXQ4TGo5b0lERXVkUWNCTkl5Nkxj?= =?utf-8?B?ZDcrSjJRU2RwTDRLVzhjblRQeEs1cWVXWnlQbkhNb2hyWDgzYk5sdi9FZlQv?= =?utf-8?B?ZDdhWHM0VXZ1bjdTbXdDb3BtWm9sRVdydmpUeEhaMmsraGRmYnFzY2JXaGtm?= =?utf-8?Q?iNJZGjhC?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN4PR0601MB3728.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42a4cff5-c118-4abc-0081-08d8c2efd59f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2021 18:17:40.9305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jvZ6YT7F1chWIRsEaXlI1JH6i8lQVsoq590uEJmsqLLgxwn46NzLrnwz27xczqhYIbJybR5i8u8r2qVqN6vSyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR06MB7371 Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 18:17:45 -0000 DQpBY3R1YWxseSwgeW91ciBzdWdnZXN0aW9uIGlzIGF0IG9kZHMgd2l0aCBvdXIgY3VycmVudCBm bGV4aWJsZSBsZW5ndGggb2YgdGhlIGFjY2VjbiBvcHRpb24uIA0KDQpXZSBhbHJlYWR5IGFsbG93 IG9uZSwgdHdvIG9yIGFsbCB0aHJlZSBjb3VudGVycyB0byBiZSBwcmVzZW50IC0gdGh1cyB0aGUg cmVxdWlyZW1lbnQgb2YgYW4gZGVtYXJjYXRpb24gYmV0d2VlbiB0aGUgb3JkZXJpbmcuDQoNCldp dGggTGVuPT01LCBhIHNpbmdsZSBjb3VudGVyIG9wdGlvbiBjYW4gb25seSBwcmVzZW50IGVpdGhl ciBFRTFCIG9yIEVFMEIuDQoNCkhvd2V2ZXIsIHdlIGNvdWxkIGFsbG93IExlbj09NiB3aXRoDQoN CktpbmQgfCBMZW5ndGg9PTYgfCAzMi1iaXQgRUNFQg0KDQpGb3IgYSBmdWxsIGFsbG93YWJsZSBB Y2NFQ04gb3B0aW9uIHNldCBvZjoNCg0KS2luZCB8IExlbmd0aD09NSB8IDFiaXQgb3JkZXI9PTAg fCAyM2JpdCBFRTFCDQpLaW5kIHwgTGVuZ3RoPT01IHwgMWJpdCBvcmRlcj09MSB8IDIzYml0IEVF MEINCktpbmQgfCBMZW5ndGg9PTYgfCAzMmJpdCBFQ0VCDQpLaW5kIHwgTGVuZ3RoPT04IHwgMWJp dCBvcmRlcj09MCB8IDIzYml0IEVFMUIgfCAyNGJpdCBFQ0VCDQpLaW5kIHwgTGVuZ3RoPT04IHwg MWJpdCBvcmRlcj09MSB8IDIzYml0IEVFMEIgfCAyNGJpdCBFQ0VCDQpLaW5kIHwgTGVuZ3RoPT0x MSB8IDFiaXQgb3JkZXI9PTAgfCAyM2JpdCBFRTFCIHwgMjRiaXQgRUNFQiB8IDI0Yml0IEVFMEIN CktpbmQgfCBMZW5ndGg9PTExIHwgMWJpdCBvcmRlcj09MSB8IDIzYml0IEVFMEIgfCAyNGJpdCBF Q0VCIHwgMjRiaXQgRUUxQg0KDQoNClJpY2hhcmQgU2NoZWZmZW5lZ2dlcg0KDQotLS0tLVVyc3By w7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IEpvc2VwaCBUb3VjaCA8dG91Y2hAc3RyYXlh bHBoYS5jb20+IA0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAyNy4gSsOkbm5lciAyMDIxIDE4OjE5DQpB bjogU2NoZWZmZW5lZ2dlciwgUmljaGFyZCA8UmljaGFyZC5TY2hlZmZlbmVnZ2VyQG5ldGFwcC5j b20+DQpDYzogVmlkaGkgR29lbCA8dmlkaGlfZ29lbD00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9y Zz47IE1pY2hhZWwgVHVleGVuIDx0dWV4ZW5AZmgtbXVlbnN0ZXIuZGU+OyB0Y3BtIElFVEYgbGlz dCA8dGNwbUBpZXRmLm9yZz47IE1pcmphIEt1ZWhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ+ OyB0Y3BtLWNoYWlyc0BpZXRmLm9yZw0KQmV0cmVmZjogUmU6IFt0Y3BtXSBBY2NFQ04gZmllbGQg b3JkZXINCg0KTmV0QXBwIFNlY3VyaXR5IFdBUk5JTkc6IFRoaXMgaXMgYW4gZXh0ZXJuYWwgZW1h aWwuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVj b2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0KDQoNCg0K PiBPbiBKYW4gMjcsIDIwMjEsIGF0IDE6NDMgQU0sIFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQgPFJp Y2hhcmQuU2NoZWZmZW5lZ2dlckBuZXRhcHAuY29tPiB3cm90ZToNCj4NCj4gSnVzdCBmb3IgY2xh cml0eSwgdGhlIHN1Z2dlc3Rpb24gd291bGQgYmUgc29tZXRoaW5nIGxpa2U6DQo+DQo+IEtpbmQg fCBMZW5ndGggfCAxLWJpdCBvcmRlcmluZyA9PSAwIHwgMjMtYml0IEVFMUIgWyB8IDI0LWJpdCBF Q0VCIFsgfCANCj4gMjQtYml0IEVFMEIgXSBdIEFuZCBLaW5kIHwgTGVuZ3RoIHwgMS1iaXQgb3Jk ZXJpbmcgPT0gMSB8IDIzLWJpdCBFRTBCIA0KPiBbIHwgMjQtYml0IEVDRUIgWyB8IDI0LWJpdCBF RTFCIF0gXQ0KPg0KPiBXaXRoIHRoZSB0d28gdHJhaWxpbmcgMy1vY3RldCBmaWVsZHMgYmVpbmcg b3B0aW9uYWwgaW4gYm90aCBjYXNlcy4NCj4NCj4gQW4gaW5jcmVtZW50IGluIHRoZSBDRSBjb3Vu dGVyIHdvdWxkIHJlcXVpcmUgYXQgbGVhc3QgMSsxKzMrMyA9IDggYnl0ZSBUQ1Agb3B0aW9uIHNw YWNlLg0KDQpJdCB3b3VsZCBhbnl3YXkgdW5sZXNzIHdl4oCZcmUgbm93IHRhbGtpbmcgYWJvdXQg dGhyZWUgVENQIGNvZGVwb2ludHMuDQoNClN0cmljdGx5LCBpZiBvbmx5IHRoZSBDRSBjb3VudGVy IGNoYW5nZWQsIHRoYXQgY291bGQgYmUgYWNjb21wbGlzaGVkIHVzaW5nIG9ubHkgNSBieXRlcyBi eSBhZGRpbmcgYW5vdGhlciB2YXJpYW50LCBkZXRlcm1pbmVkIGJ5IHRoZSBsZW5ndGggYmVpbmcg NToNCg0KS2luZCB8IExlbmd0aCB8IDI0LWJpdCBFQ0VCDQoNCkF0IHNvbWUgcG9pbnQsIHRoZSBm bGV4aWJpbGl0eSBpbiB0aGlzIG9wdGlvbiBuZWVkcyB0byBiZSBzdXBwb3J0ZWQgd2l0aGluIHRo ZSBvcHRpb24gaXRzZWxmLg0KDQpKb2UNCg0K From nobody Wed Jan 27 11:21:42 2021 Return-Path: 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 D7E683A0DF7; Wed, 27 Jan 2021 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 Y4tVv-xXZjbk; Wed, 27 Jan 2021 11:21:39 -0800 (PST) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217683A0DF4; Wed, 27 Jan 2021 11:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Date:Cc:In-Reply-To: From:Mime-Version:Subject:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KXexJcNCRAxAEXPWiDbkusBFexQMHoGfWHGgX/huO2o=; b=sa+Q4vPHSbdEq9ensBHGNdqokb CLz0D5IV8b6D/TeK4EyCWAUBtvjZOLTmn7yoUp6a+dZBnFkZoOBEje2dTlZmh22GlrJdjwSG49Fmb 7SQLsKfY53LgMGBPb2NS7NV4OQ2roiwAGCkcfiveNy1g5CfddYg2pDdLFfIkBbyStI7z9dIcS4LfS M2Gk5WkJjSmBfNetcJNu/+Tw1Ua0FEkuT1LWsQTX9PXr5XhwudaCAXQltZ2lDTchXiV1+Fs1jWx5d BJBQ4wvdGP5rf7iN8PU0DmyqRkV4Ol4yVMUPNZjJL7Z5+iEBIO1TFnts9YK6jGk5aKw78lEZPEfT3 uQ5ofx6A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49463 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l4qNh-000hU8-BG; Wed, 27 Jan 2021 14:21:37 -0500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Apple-Notify-Thread: NO Mime-Version: 1.0 (1.0) X-Universally-Unique-Identifier: 0E42D12C-DDFD-43FB-A1A0-CF33C33B802A From: Joe Touch In-Reply-To: Cc: tcpm IETF list , Vidhi Goel , Michael Tuexen , Mirja Kuehlewind , tcpm-chairs@ietf.org Date: Wed, 27 Jan 2021 11:21:32 -0800 X-Apple-Message-Smime-Encrypt: NO Message-Id: References: To: "Scheffenegger, Richard" X-Mailer: iPhone Mail (18D52) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 19:21:42 -0000 That seems to work.=20 > On Jan 27, 2021, at 10:18 AM, Scheffenegger, Richard wrote: >=20 > =EF=BB=BF > Actually, your suggestion is at odds with our current flexible length of t= he accecn option.=20 >=20 > We already allow one, two or all three counters to be present - thus the r= equirement of an demarcation between the ordering. >=20 > With Len=3D=3D5, a single counter option can only present either EE1B or E= E0B. >=20 > However, we could allow Len=3D=3D6 with >=20 > Kind | Length=3D=3D6 | 32-bit ECEB >=20 > For a full allowable AccECN option set of: >=20 > Kind | Length=3D=3D5 | 1bit order=3D=3D0 | 23bit EE1B > Kind | Length=3D=3D5 | 1bit order=3D=3D1 | 23bit EE0B > Kind | Length=3D=3D6 | 32bit ECEB > Kind | Length=3D=3D8 | 1bit order=3D=3D0 | 23bit EE1B | 24bit ECEB > Kind | Length=3D=3D8 | 1bit order=3D=3D1 | 23bit EE0B | 24bit ECEB > Kind | Length=3D=3D11 | 1bit order=3D=3D0 | 23bit EE1B | 24bit ECEB | 24bi= t EE0B > Kind | Length=3D=3D11 | 1bit order=3D=3D1 | 23bit EE0B | 24bit ECEB | 24bi= t EE1B >=20 >=20 > Richard Scheffenegger >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Joseph Touch =20 > Gesendet: Mittwoch, 27. J=C3=A4nner 2021 18:19 > An: Scheffenegger, Richard > Cc: Vidhi Goel ; Michael Tuexen <= tuexen@fh-muenster.de>; tcpm IETF list ; Mirja Kuehlewind ; tcpm-chairs@ietf.org > Betreff: Re: [tcpm] AccECN field order >=20 > NetApp Security WARNING: This is an external email. Do not click links or o= pen attachments unless you recognize the sender and know the content is safe= . >=20 >=20 >=20 >=20 >> On Jan 27, 2021, at 1:43 AM, Scheffenegger, Richard wrote: >>=20 >> Just for clarity, the suggestion would be something like: >>=20 >> Kind | Length | 1-bit ordering =3D=3D 0 | 23-bit EE1B [ | 24-bit ECEB [ |= =20 >> 24-bit EE0B ] ] And Kind | Length | 1-bit ordering =3D=3D 1 | 23-bit EE0B= =20 >> [ | 24-bit ECEB [ | 24-bit EE1B ] ] >>=20 >> With the two trailing 3-octet fields being optional in both cases. >>=20 >> An increment in the CE counter would require at least 1+1+3+3 =3D 8 byte T= CP option space. >=20 > It would anyway unless we=E2=80=99re now talking about three TCP codepoint= s. >=20 > Strictly, if only the CE counter changed, that could be accomplished using= only 5 bytes by adding another variant, determined by the length being 5: >=20 > Kind | Length | 24-bit ECEB >=20 > At some point, the flexibility in this option needs to be supported within= the option itself. >=20 > Joe >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jan 29 08:03:08 2021 Return-Path: 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 2D3153A1369 for ; Wed, 27 Jan 2021 23:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FsbA_a9yRDQa for ; Wed, 27 Jan 2021 23:40:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB93D3A1368 for ; Wed, 27 Jan 2021 23:40:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 19572F40743; Wed, 27 Jan 2021 23:39:57 -0800 (PST) To: gregory.ietf@gmail.com, ekr@rtfm.com, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: ananth.nantha@yahoo.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210128073957.19572F40743@rfc-editor.org> Date: Wed, 27 Jan 2021 23:39:57 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 29 Jan 2021 08:03:07 -0800 Subject: [tcpm] [Editorial Errata Reported] RFC5926 (6413) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 07:40:04 -0000 The following errata report has been submitted for RFC5926, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6413 -------------------------------------- Type: Editorial Reported by: Ananth Rajadurai Section: 3.1.1.2 Original Text ------------- In section 3.1.1.2 Page 8, figure 1, +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + KDF-AES-128-CMAC + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Input : MK (Master_Key, the variable-length shared secret) + + : I (Input, i.e., the input data of the PRF) + + : MKlen (length of MK in octets) + + : len (length of M in octets) + + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + + + +-------------------------------------------------------------------+ Corrected Text -------------- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + KDF-AES-128-CMAC + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + + Input : MK (Master_Key, the variable-length shared secret) + + : I (Input, i.e., the input data of the PRF) + + : MKlen (length of MK in octets) + + : len (length of I in octets) + + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable) + + + +-------------------------------------------------------------------+ Notes ----- In Input, "len" is described as (length of "M' in octets), but there is no "M" in the input, but it is supposed to mention the length of the Input Data "I", so it should be (length of "I" in octets) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5926 (draft-ietf-tcpm-tcp-ao-crypto-03) -------------------------------------- Title : Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) Publication Date : June 2010 Author(s) : G. Lebovitz, E. Rescorla Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG