From nobody Tue Jun 1 01:35:30 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 788FE3A040C for ; Tue, 1 Jun 2021 01:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=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 wRUTRk9ztnBQ for ; Tue, 1 Jun 2021 01:35:23 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 D4AD33A040A for ; Tue, 1 Jun 2021 01:35:22 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id v8so13470143qkv.1 for ; Tue, 01 Jun 2021 01:35:22 -0700 (PDT) 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; bh=JRryeugH2fKnAlfDuJUGeUXfofcla/3Jt9WYAR0x58Y=; b=p5zoIDfaUqUfuT7AgQouRpZbExTKXvbMLHoxhe4kfybhedsnxV1a5jIrjDXbs/eJTQ m2YNw6tP7WdlL9BhnR58DzlVisCWvD+QmdQ7dSQ67yoIZMErDw14VYsUrE+WL+I3u4i+ YRsevZWwGt6X5e58S0I27GvgVXdjmMJDy/JYWEiGNBUpXYzh02j3Pn0M95o79fQugiFB dO8mWVVAYlSGELIDjL2PIn+X+1OBpkyN8tRw/sBrQMhIfgvKmUCi000pwvjqEJ/JQ+Sv HKcrMWRbhzjMbnIpnM+I3V4KOHTFZxz2wy4eWrkm0dYRh4dBCwt6qQCMVhelXrWQbtxK sP5g== 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; bh=JRryeugH2fKnAlfDuJUGeUXfofcla/3Jt9WYAR0x58Y=; b=fOVeV53sDRquoPIu7UEglOLgJ+n94yBo9kyoUsEMD2bIX+IMaeQKm30Gg/EkxlEi9O ShIc6YHEADdPOiuJuxJ0O6j1/MNsdeqLIT+0ZclEmr2/8v2QuWThkbiXm7hS++RM6ot+ kX6jGSCBY5CUVrJEdZkU9xvon5fwWRiwo9Pov78kTqZaK3N/wb/IC92lm3/uH9gCEdGq Zd9eLo7gdrOM2+7/XcgR641TKKu7ACV9YUG8EwHLhB8tDdgo1ggng6uSNJdZsM/1QlHo Qn1kFsi3BDwpNwtMZJBjf9z0kHCPm6w1EhJQ4Eh9qowR7QH/v+2sG7UCm/FtNY7MjD1W udFA== X-Gm-Message-State: AOAM530A/1iSv0q6QTvHtGvx3/4YYJxOUethVwUJIL0YIUcxHX8Veu1O ThCF0/CPrb75jJhttmQtzP+UgoM8agrpxkGj6mCQKDyoXUU= X-Google-Smtp-Source: ABdhPJzAWmOIvPzV2Xjpqs71K0rzvfIATz89IFq9aJb37OFDBO337vT2YJROh8UiAxF3tpOsnKCx0ac3x+nWzAY28SI= X-Received: by 2002:a37:2c07:: with SMTP id s7mr1614135qkh.454.1622536520594; Tue, 01 Jun 2021 01:35:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Tue, 1 Jun 2021 01:35:09 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000f1f86105c3b03899" Archived-At: Subject: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02 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, 01 Jun 2021 08:35:28 -0000 --000000000000f1f86105c3b03899 Content-Type: text/plain; charset="UTF-8" Hello, I have the following comments on this draft. 1: While this draft focuses on only TCP, CUBIC can actually be applied to other transport protocols such as QUIC, SCTP. Do we want to mention it in the draft or is it out of scope? 2: Section 3.1 "After a window reduction in response to a congestion event is detected by duplicate ACKs or Explicit Congestion Notification-Echo (ECN-Echo, ECE) ACKs [RFC3168 ], CUBIC remembers the congestion window..." I think the events detected by RACK (or PTO for QUIC) can also be included here. 3: Section 4.1.1 It seems that the text version of the draft uses b_cubic and a_aimd, while the pdf version of the draft uses different names. But, I prefer to use the same names in both versions to avoid confusion. 4: Section 4.2 I personally prefer to refer the equations in the draft as 'Equation' rather than 'Figure' if there's no strong reason for it. 5: Section 4.3 It seems to me that there are two meanings for a_aimd in this section. One is the additive factor for CUBIC and the other is a generic parameter for AIMD() function. This looks a bit confusing to me. 6: Section 4.3 The description for P is required for Figure 3. 7: Section 4.3 I think The analysis in [FHP00] doesn't include delayed ACK factor. So, the AIMD TCP model here can be a bit aggressive compared to a TCP that doesn't enable ABC and uses delayed ACK. This is fine, but I think it might be good to clarify it. 8: Section 4.3 I am not very sure why segments_acked is used rather than byted_acked here. What is the benefit of it? How do we calculate when the acks are split? Also, I think it should be clarified that cwnd is expressed in segments here in this case. 9: Section 4.3 "Note that once _W_est_ reaches _W_max_, that is, _W_est_ >= _W_max_, ..." I might miss something, but I'm not sure why a_aimd can be set to 1 to be compatible with AIMD TCP. Does this mean b_cubic is also updated? If not, why this can be compatible? 10: Section 4.5: " The convex profile ensure that the window increases very slowly at the beginning.." I am wondering how much this part is accurate. Because of Principal 2, even though cwnd is increased through convex profile, I think it will be overridden by linear growth by AIMD. 11: Section 4.7: "we update w_max as follows, before the window reduction as described in section 4.6" I am wondering if reducing w_max is the right approach here. Because if we reduce w_max, CUBIC can exit from convex region earlier than the case where fast convergence is not used. It seems to me that keeping w_max and reducing only cwnd (using smaller value than b_cubic) look more conservative. 12: Section 5.2 and Section 5.3. Do these results are based on the algorithms and the parameter values described in the draft? If there're differences, I think it should be described. Thanks, -- Yoshi On Thu, May 13, 2021 at 1:19 AM Yoshifumi Nishida wrote: > Hi, > > Sorry. The link for the draft was not correct. Please use this one. > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-02 > -- > Yoshi > > On Thu, May 13, 2021 at 12:57 AM Yoshifumi Nishida > wrote: > >> Hello everyone, >> >> This e-mail initiates the WGLC for >> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-01 >> Please send your feedback to the ML. >> This WGLC runs until * Monday Jun 6 * >> >> The intended status of the draft is Proposed Standard. >> We appreciate your cooperation. >> >> Thanks, >> -- >> tcpm-chairs >> >> --000000000000f1f86105c3b03899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello, I have the following comments on t= his draft.

1: While this draft foc= uses on only TCP,=C2=A0 CUBIC can actually be applied to other transport pr= otocols=C2=A0
=C2=A0 =C2=A0 such as QUIC, SCTP. Do we want to men= tion it in the draft or is it out of scope?

2: Section 3.1 "After a window reduction in response to a congest= ion event is
     detected by duplicate ACKs o=
r Explicit Congestion Notification-Echo
     (ECN-Echo, ECE) ACKs [RFC3168], CUBIC remembers the congestion window...&qu=
ot;

   I think the eve=
nts detected by RACK (or PTO for QUIC) can also be included here.

3: Section 4.1.1
    It seems that the text version of the draft uses b_cubic and a_aimd=
, while the pdf version of the 
    draft uses differ=
ent names. But, I prefer to use the same names in both versions to avoid co=
nfusion.

4: Section 4.2  I=
 personally prefer to refer the equations in the draft as 'Equation'=
; rat=
her than 'Figure'  if there's 
    no strong reason for it.  

5: Section 4.=
3  It seems to me that there are two meanings for a_aimd in this section. <=
/font>
    One is the additive factor for CUBIC and the oth=
er is a generic parameter for AIMD() function. 
    T=
his looks a bit confusing to me.

6: Section 4.3  The description for P is required for Figure 3.

7: Section 4.3  I think The an=
alysis in [FHP00] doesn't include delayed ACK factor. So, the AIMD TCP =
model here 
   can be a bit aggressive compared to a =
TCP that doesn't enable ABC and uses delayed ACK. 

8: Section 4.3  I am not very sure why =
segments_acked is used rather than byted_acked here. What is the benefit of=
 it?
    How do we calculate when the acks are split?=
 
   Also, I think it should be clarified that cwnd i=
s expressed in segments here in this case.

9: Section 4.3  "Note that once _W_est_ reaches _W_ma=
x_, that is, _W_est_ >=3D _W_max_, ..."
   I might miss something, but I'm not su=
re why  a_aimd can be set to 1 to be compatible with AIMD TCP.
=

   Does=
 this mean b_cubic is also updated? If not, why this can be compatible?
10: Section 4.5: " The convex profile ensure that the wind=
ow increases very slowly at the beginning.."
   I am wondering ho=
w much this part is accurate. Because of Principal 2,  even though cwnd is =
increased 
   through convex profile, I think it will be overridden by=
 linear growth by AIMD. 

11: Section 4.7: "we update w_=
max as follows, before the window reduction as described in section 4.6&quo=
t;
   I am wondering if reducing w_max is the right approach here. Bec=
ause if we reduce w_max, CUBIC
   can exit from convex region earlier =
than the case where fast convergence is not used. 
   It seems to me=
 that keeping w_max and reducing only cwnd (using smaller value than b_cubi=
c) 
   look more conservative. 

=
12: Section 5.2 and Section 5.3. Do these results are based on the algorith=
ms and the parameter values 
   described in the draf=
t?  If there're differences, I think it should be described. 
   
Thanks,
--
Yoshi


On Thu, May 13, 2021 at 1:19 AM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
Hi,

Sorry. The link fo=
r the draft was not correct. Please use this one.
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-02<=
div>--
Yoshi

On Thu, May 13, 2021 at 12:57 AM Yoshifumi Nishi=
da <nsd.ietf@gma=
il.com> wrote:
Hello everyone,
Please send your feedback to the =
ML.
This WGLC runs until * Monday Jun 6 *

The intended status of =
the draft is Proposed Standard.
We appreciate your cooperation.

Thanks,
--
tcpm-chairs
--000000000000f1f86105c3b03899-- From nobody Tue Jun 1 01:38: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 D99313A045B for ; Tue, 1 Jun 2021 01:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 2NSxgukN8I4w for ; Tue, 1 Jun 2021 01:38:53 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 C17A93A044F for ; Tue, 1 Jun 2021 01:38:53 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id c124so8710708qkd.8 for ; Tue, 01 Jun 2021 01:38:53 -0700 (PDT) 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=YQMoOUwSHoDVUUZ51Iz7ak+EeuPrdig//pCs6kvv+HE=; b=oPur2uk4oCHJr9ZUnq7bygfY7MPD7wo2Vu1BjRqCtmKF9LAml//6K7qrAr/ZTtB8Xr rYlQ74mYwecOuoea538Dz/a+hww0XwrnuUGgoYgjR/3dDiE/xJtg1IKwDf6Ki4MODL34 frlCA6/LL5WCTcPr+FY7HfcQeRKctajmpUa2rC8SdUznm0aI+u697AmIsufw/65kiFlh 8Sh07YJPU9/Puf7MdqhPfQ4Mub04hD2YOGa+vxJTsPi1gikXB7bxA+eJEaxUyLR3NfqQ T40D50Qzhr+RrWxrO+ZgTM/n6500pQkc4+TflHeUzwwIFXpXvtC+s+oRRmnYn92nWTBZ 13pg== 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=YQMoOUwSHoDVUUZ51Iz7ak+EeuPrdig//pCs6kvv+HE=; b=pZtC0u4WgF4vzOd4NxHPJnYGdXZ/A3iQoGV3DyeaJy7w81OROTEfvpwK7c0YnRWthR OndTvSqPO4kBPgZ/mE7z1U7lhMdot3TVZmlMzZxy9paWC7UcNPyMWdWGplfE8YCHK2sM 0NLay1r3Ig5W99w59NC8ndgeZMXiGF4TqIC5wqUu+R1KwjM7Bg/Fde7ZY2x9DSGc5RJp 1cmwOuaiq2u0V9O2es85ECAEhDCKbtAtEoyR2bA3Iqzjx8RiFfTfeUoq35dvnsr04MDK p2g28PRo1JOJTRdvuPKGqHucUB8rZVY3npzEzCBJRFucFSqrnFBNQusrGBBeshzwVTut xWWg== X-Gm-Message-State: AOAM5339mV1Z5s6Xwm4zVVUT6k1YoxEkMt4v5PmiCjUQIZFtQ1ZX4UZw N6DJ2ObopujszUU1Ek8DevIPGLUdnQMApzoztZE= X-Google-Smtp-Source: ABdhPJwIcE3zTnGWoiT6QMkCTLdiZ+Q56jgk8228y690g+/WVCYAmCg+l7S5n1SsUiOBfeNSvG44MyZFTaGSqp/9vdc= X-Received: by 2002:a37:2c07:: with SMTP id s7mr1625974qkh.454.1622536732248; Tue, 01 Jun 2021 01:38:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Tue, 1 Jun 2021 01:38:41 -0700 Message-ID: To: Krishna Khanal Cc: "tcpm@ietf.org Extensions" , Christoph Paasch Content-Type: multipart/alternative; boundary="0000000000008f8e0905c3b04538" Archived-At: Subject: Re: [tcpm] RFC8684: TFO with MPTCP V1 example shows incorrect data map 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, 01 Jun 2021 08:38:57 -0000 --0000000000008f8e0905c3b04538 Content-Type: text/plain; charset="UTF-8" Hello, I personally think this looks make sense and worth reporting as an errata. Please point it out if I missed something. -- Yoshi On Thu, May 13, 2021 at 11:37 AM Krishna Khanal wrote: > The example for TCP Fastopen with MPTCPv1 in RFC8684, Appendix-B.3 shows > the listener sending an incorrect data-ack in its first data packet to the > initiator sent immediately after its SYN-ACK. > > initiator listener > | | > | S 0(20) , | > | --------------------------------------------------------> | > | | > | S. 0(0) ack 21 | > | <-------------------------------------------------------- | > | | > | . 1(100) ack 21 | > | <-------------------------------------------------------- | > > > At this point, the listener has not received the initiator's key, so it cannot generate the data-ack in it's response packets. > > > The correct behaviour would be to set flag 'A' to 0 and exclude sending data-ack until the initiator's key is received. > > > initiator listener > | | > | S 0(20) , | > | --------------------------------------------------------> | > | | > | S. 0(0) ack 21 | > | <-------------------------------------------------------- | > | | > | . 1(100) ack 21 | > | <-------------------------------------------------------- | > > > Thanks, > > Krishna > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000008f8e0905c3b04538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I personally think this looks make s= ense=C2=A0and worth reporting as an=C2=A0errata.
Please point it = out if I missed something.
--
Yoshi

On Thu, May 13, 2021= at 11:37 AM Krishna Khanal <erkrishna.khanal@gmail.com> wrote:
The example for TCP Fastopen = with MPTCPv1 in RFC8684, Appendix-B.3 shows the listener sending an incorre= ct data-ack in its first data packet to the initiator sent immediately afte= r its SYN-ACK. 

 initiator                    =
                                listener
       |                                                           |
       |    S  0(20) <MP_CAPABLE>, <TFO cookie>                =
    |
       | --------------------------------------------------------> |
       |                                                           |
       |    S. 0(0) ack 21 <MP_CAPABLE>                            |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  1(100) ack 21 <DSS ack=3D1 seq=3D1 ssn=3D1 dlen=3D100>=
      |
       | <-------------------------------------------------------- |

At this=C2=
=A0point, the listener has not received the initiator's key, so it cann=
ot generate the data-ack in it's response packets.

The correct behaviour would be to set flag 'A&#=
39; to 0 and exclude sending data-ack until the initiator's key is rece=
ived.

initiator=
                                                    listener
       |                                                           |
       |    S  0(20) <MP_CAPABLE>, <TFO cookie>                =
    |
       | --------------------------------------------------------> |
       |                                                           |
       |    S. 0(0) ack 21 <MP_CAPABLE>                            |
       | <-------------------------------------------------------- |
       |                                                           |
       |    .  1(100) ack 21 <DSS seq=3D1 ssn=3D1 dlen=3D100, M=3D1, A=
=3D0>  |
       | <-------------------------------------------------------- |

Thanks,
Krishna


_______________________________________________

tcpm mailing list

tcpm@ietf.org

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




--0000000000008f8e0905c3b04538--


From nobody Tue Jun  1 02:18:43 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 0851D3A0D3F; Tue,  1 Jun 2021 02:18:42 -0700 (PDT)
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 J3l9ThnTNVgp; Tue,  1 Jun 2021 02:18:37 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 272143A0D3E; Tue,  1 Jun 2021 02:18:34 -0700 (PDT)
Received: from smtpclient.apple (unknown [212.68.24.84]) (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 5723F600315; Tue,  1 Jun 2021 12:18:24 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1622539104; bh=XbyJuwxHEKoL1Q0CIzSXpbFRg0X6ngxc40+J9Ui7geY=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=e39SrRQhNG7gyV/OPbKQQS+Vy0st1gztBBH2W9TuQIUv5BOFMWn43Jt+xuMLMHoeS LfY67hTA0XOB5lvRHeXaltQcB69TacLBTiZN4wycrkMHarEfpL++jafQ0fZ58MJF9+ 8MmWIYUXOcqgx/qys5+Bn35DmOa+w9AUb6uc0/VI=
From: Lars Eggert 
Message-Id: <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_34BA0137-614B-4143-B281-A10864F5E1C0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Tue, 1 Jun 2021 12:18:23 +0300
In-Reply-To: 
Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rfc8312bis@ietf.org
To: Yoshifumi Nishida 
References:   
X-MailScanner-ID: 5723F600315.A0584
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: 
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
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, 01 Jun 2021 09:18:42 -0000

--Apple-Mail=_34BA0137-614B-4143-B281-A10864F5E1C0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

many thanks for the review!

On 2021-6-1, at 11:35, Yoshifumi Nishida  wrote:
> 1: While this draft focuses on only TCP,  CUBIC can actually be =
applied to other transport protocols
>     such as QUIC, SCTP. Do we want to mention it in the draft or is it =
out of scope?

I've opened https://github.com/NTAP/rfc8312bis/issues/61 for this.

Note that we did discuss CUBIC for QUIC in =
https://github.com/NTAP/rfc8312bis/issues/45.

> 2: Section 3.1 "After a window reduction in response to a congestion =
event is
>      detected by duplicate ACKs or Explicit Congestion =
Notification-Echo
>      (ECN-Echo, ECE) ACKs [
> RFC3168], CUBIC remembers the congestion window..."
>=20
>    I think the events detected by RACK (or PTO for QUIC) can also be =
included here.

I opened https://github.com/NTAP/rfc8312bis/issues/62

> 3: Section 4.1.1
>     It seems that the text version of the draft uses b_cubic and =
a_aimd, while the pdf version of the
>     draft uses different names. But, I prefer to use the same names in =
both versions to avoid confusion.

The PDF is actually corrupt, due to a Unicode bug in the datatracker PDF =
generation. See https://github.com/NTAP/rfc8312bis/issues/46.

> 4: Section 4.2  I personally prefer to refer the equations in the =
draft as 'Equation' rather than 'Figure'  if there's
>     no strong reason for it.

With kramdown-xml2rfc2629, it's unfortunately not possible to change =
this. We would need to add an RFC Editor Note instructing them to =
manually make the change. Opened =
https://github.com/NTAP/rfc8312bis/issues/63

> 5: Section 4.3  It seems to me that there are two meanings for a_aimd =
in this section.
>     One is the additive factor for CUBIC and the other is a generic =
parameter for AIMD() function.
>     This looks a bit confusing to me.

Opened https://github.com/NTAP/rfc8312bis/issues/64

> 6: Section 4.3  The description for P is required for Figure 3.

Opened https://github.com/NTAP/rfc8312bis/issues/65

> 7: Section 4.3  I think The analysis in [FHP00] doesn't include =
delayed ACK factor. So, the AIMD TCP model here
>    can be a bit aggressive compared to a TCP that doesn't enable ABC =
and uses delayed ACK.
>   This is fine, but I think it might be good to clarify it.

Opened https://github.com/NTAP/rfc8312bis/issues/66

> 8: Section 4.3  I am not very sure why segments_acked is used rather =
than byted_acked here. What is the benefit of it?
>     How do we calculate when the acks are split?
>    Also, I think it should be clarified that cwnd is expressed in =
segments here in this case.

Opened https://github.com/NTAP/rfc8312bis/issues/67

> 9: Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, =
_W_est_ >=3D _W_max_, ..."
>    I might miss something, but I'm not sure why  a_aimd can be set to =
1 to be compatible with AIMD TCP.
>    Does this mean b_cubic is also updated? If not, why this can be =
compatible?

Opened https://github.com/NTAP/rfc8312bis/issues/68

> 10: Section 4.5: " The convex profile ensure that the window increases =
very slowly at the beginning.."
>    I am wondering how much this part is accurate. Because of Principal =
2,  even though cwnd is increased
>    through convex profile, I think it will be overridden by linear =
growth by AIMD.

Opened https://github.com/NTAP/rfc8312bis/issues/69

> 11: Section 4.7: "we update w_max as follows, before the window =
reduction as described in section 4.6"
>    I am wondering if reducing w_max is the right approach here. =
Because if we reduce w_max, CUBIC
>    can exit from convex region earlier than the case where fast =
convergence is not used.
>    It seems to me that keeping w_max and reducing only cwnd (using =
smaller value than b_cubic)
>    look more conservative.

Opened https://github.com/NTAP/rfc8312bis/issues/70

> 12: Section 5.2 and Section 5.3. Do these results are based on the =
algorithms and the parameter values
>    described in the draft?  If there're differences, I think it should =
be described.

Opened https://github.com/NTAP/rfc8312bis/issues/71

Thanks,
Lars



--Apple-Mail=_34BA0137-614B-4143-B281-A10864F5E1C0
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-----

iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmC1+18ACgkQVLXDCb9w
wVesQw/9HvfNBz7Z7XL2yKNM9nWq8jNwoWJ+PgVLjl94ol2SXyQJkrOMyvv01J26
6NVYKlRjnWlTsPa/E+kvpozj+9Z1ynFFFLUbvw8Gy3SYVG6/PVlVl0UPz9DtpGah
+2L6Yrn2NiP9HzseJHGH1/LHZuFbWAWuBCUBbkMq1nkcs290IrzINNJfNpKRdyMI
mnonFTUhGebxbAq46SXK6qiAc9umMto3pCOpUsTRxzGAUkuEMfTAnr8zom8Qnhcu
L6a6+lAcGch5jRmMSe5evUcyyPFB/WcIGNEKuW42/igs7DWguIAmr8avbbW5KF88
rl+R/gwlV3ZhOce9IP6nhcASIa+6wwQLafELWo53rtUdfPDxHb68SbEJjOuBuqM0
q3Vlyuu2f7gkp3NQBZXV/iHYmNzXTKeMfyhjMklStG+v+PjzN2QeJRomKliwSyQl
hv4wHZiGIpymf/UBILF6CK9EuY82hbuBE1YtxK047OyfDqdT1r8v0gjv8h20ubM1
j5D/ipXUY9XHs/cJQfPCKTzC1mn63iSexUNQRLTKvpRVvMrN2LfYFE64Kx5ex8eB
gE+EIwgBr+6OzrkNsxttdCdlSQyej9ejNFcXer6BkeqVPv4Fqu2g7Z3hPQy3yfTb
KA21aADju7oCeI7V44eSopsfTQ8mOA8VmLOCzPwinnNqBtOHTRw=
=lYbd
-----END PGP SIGNATURE-----

--Apple-Mail=_34BA0137-614B-4143-B281-A10864F5E1C0--


From nobody Wed Jun  2 02:47:28 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 3E3303A3CD9; Wed,  2 Jun 2021 02:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level: 
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoGbcPfRbmpg; Wed,  2 Jun 2021 02:47:21 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 3C46A3A3CDB; Wed,  2 Jun 2021 02:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1622627240; x=1654163240; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0iwuD8CJHsVG2/0DwtgmiohNye8iI8LOEsQEqHAl3bM=; b=5NjCj5J5oY+TxqxdAJxJioLO97hQfxNQOqzLiR1uwsT+q884k7vPFQuh l/4v53dh6ph0CQsjJSpY2RAwYLKHdwNcozUyhRrGDGo3V+vsKW60E/w1O P+gL2jaNHE5tNLvpE8SnwSe5b9MQdWITHj84F8UY0yuVbx/tjiaWevr5e osRTKTDKP3TY1p16/EJz3dsMARrDBZG/2IKsFghSBna8TNIkWktFQeaDZ 1Ymkju//EBYhfSViDKo1hJU+fBSRjtzEpX7SKzE+WrlilTV2P5dgCQa/A IWdZSMr/UHuKDAa6gSyGP+U+YxcQBTf6Yc8Mi6AVcwvMTs1cXrjYQwmuB Q==;
IronPort-SDR: n8F4aE5jHo1rNPb5ZhNh2jIxtTHkI/Sdue3RPw/lrlzcAYvPwYqxKPtolFi7YO8BZsMMR/gogN tKrLYYZDsmGw==
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A1tDj96mBF/vmIUSOv9m14bSffDbpDfPxim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V7ZYmPE7P+VUssS8b+exoYJPwPk819fZOkPAs1MSZLX?= =?us-ascii?q?fbUQyTXcBfBOrZsnPd8kLFh5NgPMtbAs9D4dDLZmSS7vyKoDVQcexQvOVvmZ?= =?us-ascii?q?rA7YuwoRYdKHAPV0gJ1XYiNu/xKDwPeOAyP+tCKHPq3Ls9m9PPQwVwUi28PB?= =?us-ascii?q?M4tgr4yuHjpdbDW1orFhQn4A6BgXeD87jhCSWV2R8YTndm3aoi2XKtqX272o?= =?us-ascii?q?yT99WAjjPM3W7a6Jpb3PH7zMFYOcCKgs8Jbh3xlweTYph7UbHqhkF2nAjv0i?= =?us-ascii?q?durDD/mWZmAy1B0QKWQohzm2q15+DU6kdr15Yl8y7BvZKsm72jeNtwMbsxuW?= =?us-ascii?q?sQSGqo16NnhqAg7EsD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSp?= =?us-ascii?q?Z2Us4dkWUzxjIfLH47JlOx1GnnKpgZMCjW3ocbTbpbVQGQgoBL+q3iYp0eJG?= =?us-ascii?q?bzfqEygL3d79ENpgEN86Ix/r1pop4vzuNOd6V5?=
Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 02 Jun 2021 11:47:16 +0200
IronPort-SDR: c2dTRBoH/ljLK6VEWDfA+G3mhW4Bikaaz2b8omqjVVNyxWkrcPTUSAHfk7iEAQqBv8UvxYt/Am MaR6bNW77IUqRX2V5EAbaXQj2Sgc+GmlI=
X-IronPort-AV: E=Sophos;i="5.83,241,1616454000"; d="scan'208";a="340228905"
X-MGA-submission: =?us-ascii?q?MDEgEmM9y2bcX+n/hWN33r8AtWLE+UJswXLyaC?= =?us-ascii?q?+f5XtZzVIr8B2Ri4bwQaHBMLSqPdb0lrYfcxC7RJU/gxTDRGkTpU2sxX?= =?us-ascii?q?QEY7Gb4b4/bdsPJCsIroAIR2qk6FLCiUoVSfK3BTCGEXJKcpWHf+4V8W?= =?us-ascii?q?x/pKnsnH584qmHKMsMGr9DLQ=3D=3D?=
Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 02 Jun 2021 11:47:17 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 2 Jun 2021 11:47:16 +0200
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Wed, 2 Jun 2021 11:47:16 +0200
Received: from DEU01-BE0-obe.outbound.protection.outlook.com (104.47.7.175) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 2 Jun 2021 11:47:15 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DjSkm97xSyS058j8yGhLzJSM3XktyBDrVbjsaTZQbo6ydnItqkZmO4MfOzFrqkVvK34+QGbgQszDcKJIr5fOKOT4RLpBjNN9pLNHqbBLzqYgklxCpl0+eTI2M2IImoTx10nCnuzgg3OeiZrsjPbZ1UKOnNgFs3zPu1+5tuWRAd4SjYHEjin85UINXzkCGQzhwDXuU6WffcLYlmY0+EnqeHiK9TKaDAE2DChY0c395atHIycrWdbKhu445PwaXb1usBN8Aiuf3T+L/JguI+HMk51mQ8dJgM/7+AGZFN7dK8/NuCby30gmcgwU8CPIz6Yy9dHpJ0JBLnveJU8OatEoeg==
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=0iwuD8CJHsVG2/0DwtgmiohNye8iI8LOEsQEqHAl3bM=; b=bCT6FAmFRWqb+LZ1kTMywIy30hzh59PhlycA2K5yYvazaoNMF1AGpiLehdIizZjBtyLBklmsgeP64twzg0THnvAvDiG6QVofvNLCXNyHIyOyc0miBv9GRzqIfo+flKbe+KTuFOghdsVHWTgcdIj38TBMyIigQYLV+CayFQUuEz9yEpJcXLza2zQsXtEUY9nQ0vCU0ub7sSUvGaR8Lg3JCsjkoXLuazfE/gYknNVYJnndefe3WqjXrnkqHOU1I5F3bNYpw6MvRDU0vG/9Qw4FaqsgLUTZbramAQtZRKEvM7zbaRjJXGMgXed+i0+xA0WJSSd/nOX68gLN/LXTzP1OGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:40::10) by FRYP281MB0438.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:41::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.11; Wed, 2 Jun 2021 09:47:15 +0000
Received: from FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM ([fe80::dcab:9699:172f:4fa1]) by FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM ([fe80::dcab:9699:172f:4fa1%3]) with mapi id 15.20.4195.020; Wed, 2 Jun 2021 09:47:15 +0000
From: 
To: , 
Thread-Topic: MPTCP Robe IPR
Thread-Index: AddNamsT67TJ9DI8T+G86z3sPrFnfg==
Date: Wed, 2 Jun 2021 09:47:15 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [79.237.80.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f09040d7-f64a-4e2a-e5f8-08d925ab6781
x-ms-traffictypediagnostic: FRYP281MB0438:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Pbqx4zYB+VM8dmtUZA0HCcR/CUyrdn9kzlfFe0Lw+jP2iRgmbNyavVg7tK5GstazAKcZ7gPKpWLgVDwAsCbpYHjqi3BaNCCqSzBiR1G3Z/aiEILP0g+unOdQ1IDRfEbFtJYQsXfMyHPzvtCG0uGGkZA+A95PEIezNveTWgTTBHzhwz0lZ2dTs5Iq/6TEY/KlhJkEJ2vJ2xCpg7GzMW7gOAcg0rtT5Rti1efyCGxWG5dqBu2lHP211TRd00C4qb7nbszfeh7LkVfN9/+klgwmHfJQHJYRFjch6JZl+h9WYZP0LRAs/ZHQ5O4hU6mkHCqhVaU898orNrPUaFe6X0MttFyuvXwqH9frSe6aD6sLl/upKqhsdznnFv6cB9G2mkgyn/IU8BEElrS86YiHYohvpdBoyn0ECx3KcepFxm03tu0ifjwCA587l4+NhbyLKJbyNdxi/C5rAtYUDyC580S+qRxB85BOAxuNi18UAwVjGees3JXu1lvPk4Koke1BW4/mcabrh8iXeVkYkkiuhWuym8y2MCd6Y1qFmK7YdlHfEFDSudasjYntdF921MXNh3b6L1dsHELRel4ySdv6RyAqehKzfo0Xtr+OL3b9KoCdaMo6jdDOVP5MB+Av4C6BamQr7IkUXz3qWgFMS4GIJ2YtWNR1WrPkf4HKvd9NWkOyWFTv4FOlNsuYFcNA5qV+dpANQHyhVIAzUsXxnNgvwj+/UA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFS:(366004)(39860400002)(346002)(136003)(396003)(376002)(83380400001)(71200400001)(8936002)(76116006)(8676002)(122000001)(33656002)(4326008)(966005)(66446008)(66556008)(110136005)(66476007)(38100700002)(66946007)(64756008)(6506007)(7696005)(3480700007)(316002)(52536014)(5660300002)(186003)(2906002)(55016002)(9686003)(86362001)(26005)(4744005)(478600001)(7116003); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?sQhDvNdHj/L93gS99TAQGgAcesN7uXCHczYq5Dh/9mCea0fsS6fBSJZ4d7KY?= =?us-ascii?Q?jOwg9mzlCNLWY9XfEisOGeI1cqQdYfNXgCLD/YU1NaaZPtIywL+0LkPwvA20?= =?us-ascii?Q?lSGXCmaTM8ZJ10GSb9S9rmeKQYHtdz6UHKfFJ2FPD/NcPFGTy0rIUXJbk0gp?= =?us-ascii?Q?4kmg0eDnmtAfB42JBjN5qTetUFjtMYVTkprC8KZggy7QcwXz259jEXMUq8nn?= =?us-ascii?Q?LndpjDK12CaCh6MhZ3o9vycugIvTwGCXiZXSKjIeXMaiF+xIjFgGeoWzkmWD?= =?us-ascii?Q?DKPeodfMHE62Kf6NUWyKHhlC5CceCLXysaQ/RrDvip9p0xfBwAA/BQpcNM9D?= =?us-ascii?Q?YkC0fL0DbowifKyo2HhF3jqVlheTP9I2H52QaZCUzoYqxEXXEAFFYgkDhQpt?= =?us-ascii?Q?5kGrRuqBaGt38zA/LjpTVzA7FpR9uf8E1+VeBPfpgmtLkVGRWwL2zR4pK+YU?= =?us-ascii?Q?iAdZTur+7tITh58BVNxbKCeUBXaXBwajVtE5RURFHj2Oahxkmq1t6uAkNaNj?= =?us-ascii?Q?9lm/rvgeAn/JzMgEN9jkDuRsTOUuvzh6AokNAjsnp2pE4XVWw85H/1qpXYgn?= =?us-ascii?Q?Qw0XMFiA4/NnpiBFcLGQ/4l9HSJLVCIz7wJrMHch217HIrznn93GkN5LPx2b?= =?us-ascii?Q?a2eOCehsJDaeEbFgl1kLjvrCZl+b3EUyhvtYYerxRrZkzjzC4LROLpgc5bX3?= =?us-ascii?Q?QoC3QsUY6gk/vYFJ9doVBivO42bO55ylqYudkioSxKOWZXrmA9mj3tDQd9+C?= =?us-ascii?Q?/4sMqI/m1kRdWKHO3AECjZrHl6o6Rb9BjOZu1PUeG6vaQu4v5IQ6f7B6AUDz?= =?us-ascii?Q?X2FDH/wrnwnvc06chAe7dWzoSQ2AqlZvN61iEZUC5/dJyXl5Ed7WNOvgdILb?= =?us-ascii?Q?UF+LJh+G2JBVVnjmltUpQnpzh7oX41eCMIAOjxrqbdReq2xcB6H/kvZMLrSp?= =?us-ascii?Q?BTcxbED1CuhLAOv+ZcRpCllXgQHsaSXD5lHFrFmEbyO4JL6+XpFzuRyqfaTO?= =?us-ascii?Q?ljcCTb9ldM/qR/JFgT1lzMqDscOu7VAA5bW2xyap9pUdOIp2jLxZEZa+0iwp?= =?us-ascii?Q?9sfK9YWAlhnK7kWNoq3q93xGUb1c1JFvrGr7zPW1U+Tm8sgupRU7zjV3fLGp?= =?us-ascii?Q?emhYJLmVR+XCvy0Dpf+plgAlM4e/AOQtfXHMGQTHrEEpfUNbg5eAgR1+4dv4?= =?us-ascii?Q?cLpznbLX4XkosvUhLj9bhSE1cnkrQFlja2993S8KESe2dUTkoY2gc/ZOUcsp?= =?us-ascii?Q?ZhWcG/BZ+ggzjaYFUzditYPcxH6LwAwF1PyiWc7zBufQWe7pty2gY1PmB7y6?= =?us-ascii?Q?ZOl3lrPhfM1DNHU1xRWqWLvk?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: FRYP281MB0405.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f09040d7-f64a-4e2a-e5f8-08d925ab6781
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2021 09:47:15.5299 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QGMPMQU9mtyJT4OAT1EpN1rAhWOq+6hnOMU8d2leGaNmp3jhuAuOAh/o1egVJ3pKL+y2pYehPyHI3hqsyx5nIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0438
X-OriginatorOrg: telekom.de
Archived-At: 
Subject: [tcpm] MPTCP Robe IPR
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, 02 Jun 2021 09:47:26 -0000

Dear all,

After now several rounds of discussing https://datatracker.ietf.org/doc/dra=
ft-amend-tcpm-mptcp-robe/ on the mailinglist and IETF meetings it seems, th=
at the blocking subject for adoption are merely the existing IPR declaratio=
ns.

In an interesting chat discussion along the last TCPM@IETF110 session, Lars=
 Eggert found, that licensing declarations are already provided and from hi=
s personal view to be sufficient. However, there were different views on th=
at in the chat discussion. That's why I want continue this on the mailingli=
st to find a solution, or better, to get a common understanding which licen=
ses are in general demanded by IETF to get adoption.=20

https://datatracker.ietf.org/ipr/4312/
https://datatracker.ietf.org/ipr/4423/

Both declarations provides licensing as followed: "Reasonable and Non-Discr=
iminatory License to All Implementers with Possible Royalty/Fee"

Br

Markus


From nobody Thu Jun  3 02:47:49 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 80EA53A31DB for ; Thu,  3 Jun 2021 02:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level: 
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 jQeHscEgGWSq for ; Thu,  3 Jun 2021 02:47:43 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33EA3A3211 for ; Thu,  3 Jun 2021 02:47:42 -0700 (PDT)
Received: from smtpclient.apple (ip-109-42-0-103.web.vodafone.de [109.42.0.103]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AE9F87220B804; Thu,  3 Jun 2021 11:47:35 +0200 (CEST)
From: tuexen@fh-muenster.de
Message-Id: <025CE34B-A2DC-409C-9A2B-B5D7A4E826B1@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_F7EDBFC6-0017-4865-AAA8-C4C31F55ADFC"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 3 Jun 2021 11:47:34 +0200
In-Reply-To: <3ece7e28-c247-f980-3f31-5ea64314fff3@mti-systems.com>
Cc: tcpm@ietf.org
To: Wesley Eddy 
References: <62b0a3c2-3ec5-c3d9-7a1c-909e11a23d0c@erg.abdn.ac.uk> <3ece7e28-c247-f980-3f31-5ea64314fff3@mti-systems.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [tcpm] Additional editorial comments on draft-ietf-tcpm-rfc793bis-20
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, 03 Jun 2021 09:47:48 -0000

--Apple-Mail=_F7EDBFC6-0017-4865-AAA8-C4C31F55ADFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On 17. May 2021, at 16:34, Wesley Eddy  wrote:
>=20
> On 3/12/2021 5:13 AM, Gorry Fairhurst wrote:
>> I did some very careful reading of a few sections of  rfc793bis, and =
have additional some late editorial comments.
>>=20
>> I suspect these really are minor, but I'd hope worthwhile:
>>=20
>> ---
>>=20
>> (1a) The text uses /may not/, in these two places:
>>=20
>> /Note that some options may not be included on all segments/
>>=20
>> - I wonder if this is umambiguous to all English speakers (it's not =
so clear to me), I think it could be better as
>>=20
>> /Note that some options might not be included on all segments/
>>=20
>> or ...
>>=20
>> /Some of the segments might not include include all options/
>>=20
>> ... of something like that this?
>>=20
>> ---
>>=20
>> (1b) I'd suggest similarly avoiding /may not/ in the description of =
IP Option processing.
>>=20
>> ---
>>=20
>> (2) The document seems to be missing an IPv6 "view" of extensions in =
the IP Options part, section 3.6.1 (This is mentioned in the =
pseudo-header compuation). I suggest we add a brief sentence saying the =
calculation of "IPv6 Extension Headers" follows thar for IP Option size.
>=20
>=20
> I missed your couple of comments above in the prior -21 revision, but =
Michael S. reminded me of them, and I've incorporated them into the -22 =
revision just posted.  On the IPv6 comment, I changed the notion of "IP =
options" in a couple of places to "IPv4 options or IPv6 extension =
headers" which I think accomplishes the right thing.
Hi Wes,

I found one more issue on page 79/80.

OLD
               SYN-RECEIVED STATE

                  If SND.UNA < SEG.ACK =3D< SND.NXT then enter =
ESTABLISHED
                  state and continue processing with variables below set
                  to:

                     SND.WND <- SEG.WND
                     SND.WL1 <- SEG.SEQ
                     SND.WL2 <- SEG.ACK

                     If the segment acknowledgment is not acceptable,
                     form a reset segment,

                        

                     and send it.
NEW
               SYN-RECEIVED STATE

                  If SND.UNA < SEG.ACK =3D< SND.NXT then enter =
ESTABLISHED
                  state and continue processing with variables below set
                  to:

                     SND.WND <- SEG.WND
                     SND.WL1 <- SEG.SEQ
                     SND.WL2 <- SEG.ACK

                  If the segment acknowledgment is not acceptable,
                  form a reset segment,

                     

                  and send it.

The change is only the indentation of the last sentence.

Best regards
Michael
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_F7EDBFC6-0017-4865-AAA8-C4C31F55ADFC
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow
ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw
KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5
c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy
MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK
EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg
ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH
l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F
XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba
L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL
NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz
9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU
k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD
VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC
LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv
cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB
BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw
Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw
DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6
dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+
hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS
T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7
h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD
AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy
ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu
MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx
RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n
c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i
YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp
1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W
LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI
TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk
P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M
ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P
AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV
HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM
z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v
dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n
bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI
KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF
BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv
b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/
DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN
T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+
lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v
9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7
EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3
DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp
bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw
IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy
MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z
dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX
MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ
NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R
VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k
yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E
OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG
AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw
ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW
BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg
BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0
cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g
PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy
bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu
LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv
ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6
Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw
DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7
1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5
b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4
fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y
KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB
ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l
cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG
A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl
AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2
MDMwOTQ3MzRaMC8GCSqGSIb3DQEJBDEiBCCl/lPvfno5SeqsHKsLjJAYGf1H6YAAAnOq2HbhuEHr
XzCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1
ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD
VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20
MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8
VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu
IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n
IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEADD+Q+f+704NCg0awxI5c1uVu87aj
/51Ac9TsrlI14P5g+8gYRexJpmcdbj11Kge5cxPNyYoLSdfRWzpWR6W4XSSbYm3Oq3V9Mf28T1Td
VZdetXhP/8crBu7MRun89gOjG5vC0BLtlbHpGbyc9s/XLeZKlM33jmeglXy9xti/GX9dBc0UZMEc
9SUfWvfm946UIqK8gaH1wL4Tu+hGai1HY1IVFlEYFE9td+3WpCuA0FmcfrUZ+FCqCEc2+8x2APgu
kPVgkdgPKU9kdd9qGYrECUTr6LZOyFlF/+vFKnwQ4Dj+dgByuhhwfCttlQ+5Lut0C4IPeviuFGrI
BSP6oHWhWwAAAAAAAA==
--Apple-Mail=_F7EDBFC6-0017-4865-AAA8-C4C31F55ADFC--


From nobody Sun Jun  6 20:05:21 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 72F2D3A3326 for ; Sun,  6 Jun 2021 20:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=mti-systems-com.20150623.gappssmtp.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 huNPDi2LhzFK for ; Sun,  6 Jun 2021 20:05:14 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 58B7C3A3325 for ; Sun,  6 Jun 2021 20:05:14 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id j62so1597967qke.10 for ; Sun, 06 Jun 2021 20:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=wSRf03IGYfcMswRmBNpQ+hC1hR3RK0dGmZ7Hm+tGAnQ=; b=loL5EeCuWybuR8jlMPDJ/mNPIYf9gEERZ8b+PU4tbaKTRlssDpPXSDfrQ2uuRJ5Ow9 9EptREAEPPPbojo005TM/rmL69jduHGDO02++Se3LckPUdr8BY53Dp1ONBOktXHBTJZd cTF6YA6+nOsk7+G1ClPMhmFALFDCtyQa6SXCZHWUfnMTT2RnPCbdd4SvXop3wSSmmcFY o8Ar5nAgmgTovBWpJNSlEk2saNATi5RbvIUi4aOCFJs2oPT3tGOhdj+D2AwmzDf8pg3C DgG8YhcvXaG+QH6bNZc6s4lsprTwrF/gH4fess0UjI5lDgVt0JfkCvNQq7F0kLfZnah3 vkPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wSRf03IGYfcMswRmBNpQ+hC1hR3RK0dGmZ7Hm+tGAnQ=; b=WYPJI5QnbG//pgGdZkFguKvMAWBH455nEkQeZ2KSC+2xTr7zZuzKE3/f6IXzk4JPXJ iA+MmxHmj/pHxEhLaYbbkLRO+T743iV8y9wBOtXe+WX3OsoN9ENDgq/UxkMFweyAjmOD 4FgXQ1nUu72gZFYDRC8eAHlhXW5zdbC2cba/+NSYXBYSEjddrFOzj09kASH7WtkkIhwC wPscNfZIGzGl0u14UdsM6+QaTOwhTJfXFb13MDl3bpE5FAmP/vbmZUaNiOTl5d0Aowv5 i/++rIAu//xYWq+AbxZiSZKaT40r9Y3ZP9Jm9QS5yrcpElTkpYuZC5ZRs5KgjtE078dj WEYg==
X-Gm-Message-State: AOAM530+EH0tTvHB2uNa0k5ybrx9EDxWaZ7Q3RyFp3pdiU09YJpN1lYh ZH+cFm3OTUjroGcKR1EdQzlWs7CRAyg9UO8m
X-Google-Smtp-Source: ABdhPJxkMl73dEcFDWBP/DQ0RQT4Z7/L7kl1ci3tmBbZP70/krIQtNoUph9MtWdyxCukJAEHPBae/w==
X-Received: by 2002:ae9:c30f:: with SMTP id n15mr14113469qkg.71.1623035112099;  Sun, 06 Jun 2021 20:05:12 -0700 (PDT)
Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id k19sm3176301qkj.89.2021.06.06.20.05.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 20:05:11 -0700 (PDT)
To: tuexen@fh-muenster.de
Cc: tcpm@ietf.org
References: <62b0a3c2-3ec5-c3d9-7a1c-909e11a23d0c@erg.abdn.ac.uk> <3ece7e28-c247-f980-3f31-5ea64314fff3@mti-systems.com> <025CE34B-A2DC-409C-9A2B-B5D7A4E826B1@fh-muenster.de>
From: Wesley Eddy 
Message-ID: <86a03630-a462-aa04-df80-c7fcf4b5fbe3@mti-systems.com>
Date: Sun, 6 Jun 2021 23:05:05 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <025CE34B-A2DC-409C-9A2B-B5D7A4E826B1@fh-muenster.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] Additional editorial comments on draft-ietf-tcpm-rfc793bis-20
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, 07 Jun 2021 03:05:20 -0000

Thanks Michael, the fix you mention below is in my working copy of the 
next -23 revision, but I just wanted to point out that it looks like 
this is minor issue of extra indentation is from the original RFC 793.  
I'm assuming it's obvious that we want to fix it, and just pointing this 
out to the working group for completeness.


On 6/3/2021 5:47 AM, tuexen@fh-muenster.de wrote:
> Hi Wes,
>
> I found one more issue on page 79/80.
>
> OLD
>                 SYN-RECEIVED STATE
>
>                    If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
>                    state and continue processing with variables below set
>                    to:
>
>                       SND.WND <- SEG.WND
>                       SND.WL1 <- SEG.SEQ
>                       SND.WL2 <- SEG.ACK
>
>                       If the segment acknowledgment is not acceptable,
>                       form a reset segment,
>
>                          
>
>                       and send it.
> NEW
>                 SYN-RECEIVED STATE
>
>                    If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
>                    state and continue processing with variables below set
>                    to:
>
>                       SND.WND <- SEG.WND
>                       SND.WL1 <- SEG.SEQ
>                       SND.WL2 <- SEG.ACK
>
>                    If the segment acknowledgment is not acceptable,
>                    form a reset segment,
>
>                       
>
>                    and send it.
>
> The change is only the indentation of the last sentence.
>
> Best regards
> Michael
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Sun Jun  6 20:41: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 E81A83A342B for ; Sun,  6 Jun 2021 20:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 N6gQGTvA21sd for ; Sun,  6 Jun 2021 20:41:39 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 BF8AD3A342A for ; Sun,  6 Jun 2021 20:41:39 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id c124so15414226qkd.8 for ; Sun, 06 Jun 2021 20:41:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=9qUdpQboQ/hk47FuuZhhZrkjmjQlRfxSwBdXfTp1tPw=; b=cKB7hPnhGzblVEVvKeIb5Y8oWES9tizybJIJEcinKmfQUXfREuctyiqMjBJTZvVoB6 wHVhvVq/O+e27eFI2G9ju/7oj/ELj/SXVcdKnMgo53q9cqqATrhHiSaOqpLqd6UhGCVt oPjMSg61tmsx/8C9gSitK6vO/8/jvwfB6fZHI5FfM0jtAJOT1NOVf6s6GZTiFrwnb6VX at28J4G4ysKTQbdG5IscyNfN3aJHC400dWAmZo1Ss/axT++sX2HMe7peWTo9/1WWAmjC WtdGxPb5nE51irO1BrCDxEtnHw15ZaRythf9H7aDpmkcDndARxGirNMUvUJ2cguOpggD yW8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=9qUdpQboQ/hk47FuuZhhZrkjmjQlRfxSwBdXfTp1tPw=; b=uLvUjobf4q4uCOkslbPtaW08KNAZnrnR1NLl/qkAAp9N/ulAXNFzpnfWkE8/YVUjOA qgAoPm/X2EuFO8uQJvZHEx2IN4bcF1GZ5ghFcXnBrgKDjUQK7RytDcu5/Z3j1whoUW2P 0ynhcqO+P4HUOEmvOqJkToeI2ZlJmY28ARDlwiE8q5XUqtJ1be/ZFlDy+/Ng4x6ZfMgn 4QnI57c/79a8Ua1FXJXcTe4lCdA/k5hFFAG8OgEzdleh4kKj09pbWljt6wQRs/ai2h9S 7OOqkzHjZdLX4/1cwna4xtJsDBF4ODuw9ZmvG6y/6gXeqPcGWdJoJvemj46RSrCMA8bJ fygw==
X-Gm-Message-State: AOAM531lUoPcj4MYZBDxw9iET3i1Kf7qdcm0Yqr7n40h4ZA5bpmkpiZX 1nmQwzcLZTYVEuRFrZnrlgf97HljVUPaknN4
X-Google-Smtp-Source: ABdhPJzWPptKputBIsQH7m3+RIoSkngEI5Kyit+6JpSps+pQVY74VZCTnbKlvgGgVU9ewBsUIXQgqA==
X-Received: by 2002:a37:cc5:: with SMTP id 188mr14759773qkm.112.1623037297028;  Sun, 06 Jun 2021 20:41:37 -0700 (PDT)
Received: from [192.168.1.14] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id m126sm5856503qke.16.2021.06.06.20.41.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 20:41:36 -0700 (PDT)
To: tuexen@fh-muenster.de, "Scheffenegger, Richard" 
Cc: "tcpm@ietf.org" 
References: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at> 
From: Wesley Eddy 
Message-ID: 
Date: Sun, 6 Jun 2021 23:41:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm]  in SYN-SENT (793bis)
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, 07 Jun 2021 03:41:41 -0000

I'm just noting that since this thread looked inconclusive, I haven't 
made any changes in 793bis in response.



From nobody Sun Jun  6 20:48:19 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 744F23A345E; Sun,  6 Jun 2021 20:48:17 -0700 (PDT)
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.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <162303769741.722.9916384330684875344@ietfa.amsl.com>
Date: Sun, 06 Jun 2021 20:48:17 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-23.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: Mon, 07 Jun 2021 03:48:18 -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-23.txt
	Pages           : 112
	Date            : 2021-06-06

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 is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-23


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



From nobody Sun Jun  6 21:50:23 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 7C8843A360F for ; Sun,  6 Jun 2021 21:50:21 -0700 (PDT)
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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 TRBt2EL6lJ1c for ; Sun,  6 Jun 2021 21:50:17 -0700 (PDT)
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 249023A360E for ; Sun,  6 Jun 2021 21:50:16 -0700 (PDT)
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=+xkU/GXDTToCKCJIUsshEi+TaNhSKgWYpBe1OSgY/2k=; b=mU47zF9KjzrgnFQ/IpK3aZr9QX 1LYftr9i38MKrdt+g1WISrFidngOBO/RvKm4CeLPa44etEofQLOq1paC1qhC/HCywkQQBXAfJnOxM 5xwsdCqv5C7kvc4+mzni2DIhWmTF2asbOlTQ8uocSLlVG+qhb3lSRxFrTti5rh7BJQqDYYuCRt5dT BTViSxJuJHNTYMmMPsn+O3ZzgqpxEdYFCq1NjoaWcmUB6doENJzmoq8WjBn49SHrtEHYBhPXa8rms akEI2KNKKs9yMH6Eq5I9tZhdS6J2+X/1Aqv1wHGc8yewCQGdwyjKJ0G75DsA9gGOVHtydUSaIkrHt 6S6oQ9zg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61757 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.94.2) (envelope-from ) id 1lq7DE-000qrn-Rd; Mon, 07 Jun 2021 00:50:13 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch 
In-Reply-To: 
Date: Sun, 6 Jun 2021 21:50:07 -0700
Cc: Michael Tuexen , "Scheffenegger, Richard" , "tcpm@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at>  
To: Wes Eddy 
X-Mailer: Apple Mail (2.3654.60.0.2.21)
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]  in SYN-SENT (793bis)
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, 07 Jun 2021 04:50:22 -0000

Seemed conclusive to me; Michael=E2=80=99s response appeared to answer =
it from what I understand.

> On Jun 6, 2021, at 8:41 PM, Wesley Eddy  wrote:
>=20
> I'm just noting that since this thread looked inconclusive, I haven't =
made any changes in 793bis in response.
>=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Mon Jun  7 00:01:11 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 9850D3A39C9 for ; Mon,  7 Jun 2021 00:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 sUVOtuUgclQw for ; Mon,  7 Jun 2021 00:01:04 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573F63A39C6 for ; Mon,  7 Jun 2021 00:01:03 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:4008:ef91:c993:1666]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 1B108721E2809; Mon,  7 Jun 2021 09:00:55 +0200 (CEST)
From: tuexen@fh-muenster.de
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_1014A06F-42E0-42E6-B12A-DB27CA3000A9"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Mon, 7 Jun 2021 09:00:54 +0200
In-Reply-To: 
Cc: Wes Eddy , "tcpm@ietf.org" 
To: Joseph Touch 
References: <8f501fee-4cd5-46be-5549-a66186f3ac5b@gmx.at>   
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: 
Subject: Re: [tcpm]  in SYN-SENT (793bis)
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, 07 Jun 2021 07:01:10 -0000

--Apple-Mail=_1014A06F-42E0-42E6-B12A-DB27CA3000A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On 7. Jun 2021, at 06:50, Joseph Touch  wrote:
>=20
> Seemed conclusive to me; Michael=E2=80=99s response appeared to answer =
it from what I understand.
I agree. Just to be clear: My (individual) view is that there are no =
changes in RFC 793bis needed.
The TCP stack Richard is referring to now has a updated fix which is =
compliant to RFC 793bis.

Best regards
Michael
>=20
>> On Jun 6, 2021, at 8:41 PM, Wesley Eddy  wrote:
>>=20
>> I'm just noting that since this thread looked inconclusive, I haven't =
made any changes in 793bis in response.
>>=20
>>=20
>> _______________________________________________
>> 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=_1014A06F-42E0-42E6-B12A-DB27CA3000A9
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow
ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw
KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5
c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy
MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK
EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg
ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH
l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F
XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba
L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL
NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz
9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU
k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD
VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC
LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv
cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB
BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw
Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw
DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6
dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+
hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS
T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7
h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD
AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy
ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu
MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx
RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n
c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i
YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp
1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W
LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI
TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk
P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M
ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P
AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV
HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM
z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v
dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n
bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI
KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF
BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv
b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/
DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN
T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+
lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v
9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7
EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3
DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp
bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw
IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy
MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z
dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX
MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ
NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R
VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k
yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E
OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG
AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw
ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW
BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg
BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0
cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g
PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy
bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu
LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv
ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6
Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw
DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7
1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5
b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4
fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y
KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB
ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l
cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG
A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl
AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2
MDcwNzAwNTRaMC8GCSqGSIb3DQEJBDEiBCCXftiWaX2jIBLbFVQliOjFhG7opEwcQB986kh8SUpl
MjCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1
ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD
VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20
MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8
VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu
IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n
IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAABIztS2nNLGTEHo9RGH23nqupexj
SM/crqZWnpG6E0eZlvuSlFBextZc3Vq5jhCkJdQjdu2FbhkqdXNBz9vrG3HUXtY2U0Bs47e+kjzZ
MyK/37dY0+xJFyv0dFHBNNsWoZepGItQcP1Qn44Z/0W1JXGHMtrGZOY+84f6+93DB/P6jmS4y+6F
vO/ZiGZ6p9KDbUFACrAyhzltwA1ZbN/HMwsLX0jhYgfviKlkEMU5PFUDIHMgtV1rDDYSq3mIcz7E
JifTyb/GvCS/4S+1BqcSrHzHDBLsjp2G7KmZo03GTjI1nanDjokwY7AGc+mJWqzvef0HiVt8ngDg
V+OH5i4PdAAAAAAAAA==
--Apple-Mail=_1014A06F-42E0-42E6-B12A-DB27CA3000A9--


From nobody Tue Jun  8 00:27: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 538F83A25E2; Tue,  8 Jun 2021 00:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level: 
X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 R-OFkRyODpsJ; Tue,  8 Jun 2021 00:27:32 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 60A1F3A25E0; Tue,  8 Jun 2021 00:27:32 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 1587I9aB003658; Tue, 8 Jun 2021 00:27:27 -0700
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=siVWHybPSSdQt7xujqC2F++FTmLP18wixeWY4EtPmAk=; b=J4ESKa33AjP2msfB5GcZlLhSmA0qHk/WKzxVJbuwWkHwgkBfST5oMjZXGEK/Rs4+lNHX qgZy4p8hA8z5N7QAxG+8GPzWAYIk80ylBS0NUCbiK0nho4GBGCMNaeAxJDHkk8xcQ5kP tpVlSSTPnGsmSfmWM58XB38ZvbCzVfGZhrJAS/3Z39hB5UBCeV80W/qx9CKAxIJwJSTy Fy+QLNDiVXsvHR4g7p7nNyz27Utfgb7/4xS7ojMcq9R4FsPsQ9kMNAeVOmaPyc247I/E 1477ke0J8niSyms6rmAX2+wT0kuFxo83i7lRYT6Oppj6lvSn/tjf3dAh3y1xfJZCE4wQ Eg== 
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3907x42b9u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 08 Jun 2021 00:27:27 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUD00LZZGPQQ5D0@rn-mailsvcp-mta-lapp04.rno.apple.com>;  Tue, 08 Jun 2021 00:27:26 -0700 (PDT)
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.9.20210415 64bit (built Apr 15 2021)) id <0QUD00D00GN2LE00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 08 Jun 2021 00:27:26 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 22b197be277b53ec1f96ba572e51d931
X-Va-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-Va-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-Va-CD: 0
X-Va-ID: 1b1dcbed-304e-441f-8d68-b9afd48a2f8f
X-V-A: 
X-V-T-CD: 22b197be277b53ec1f96ba572e51d931
X-V-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-V-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-V-CD: 0
X-V-ID: 7c3d3fa7-9a2c-43f9-9250-03f40db646b9
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-08_05:2021-06-04, 2021-06-08 signatures=0
Received: from smtpclient.apple (unknown [17.11.41.60]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUD00QMJGPQ9X00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 08 Jun 2021 00:27:26 -0700 (PDT)
From: Vidhi Goel 
Message-id: 
Content-type: multipart/alternative; boundary="Apple-Mail=_FA8C4B90-C4EC-429D-AD40-6C84CF3B98A0"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Tue, 08 Jun 2021 00:27:25 -0700
In-reply-to: <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org>
Cc: Lars Eggert , draft-ietf-tcpm-rfc8312bis@ietf.org
To: "tcpm@ietf.org Extensions" , Yoshifumi Nishida 
References:    <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-08_05:2021-06-04, 2021-06-08 signatures=0
Archived-At: 
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
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, 08 Jun 2021 07:27:38 -0000

--Apple-Mail=_FA8C4B90-C4EC-429D-AD40-6C84CF3B98A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello Yoshi and folks,

As we are addressing the below issues raised by Yoshi, for one of the =
issues (https://github.com/NTAP/rfc8312bis/issues/64 =
), it would be great if =
you could take a look and provide opinion about whether using alpha_aimd =
as a variable and then assigning a constant value to it for Cubic in the =
draft is confusing or not.

And, of course, you are welcome to look at other issues and provide your =
input.

Thanks,
Vidhi

> On Jun 1, 2021, at 2:18 AM, Lars Eggert  wrote:
>=20
> Hi,
>=20
> many thanks for the review!
>=20
> On 2021-6-1, at 11:35, Yoshifumi Nishida  wrote:
>> 1: While this draft focuses on only TCP,  CUBIC can actually be =
applied to other transport protocols
>>    such as QUIC, SCTP. Do we want to mention it in the draft or is it =
out of scope?
>=20
> I've opened https://github.com/NTAP/rfc8312bis/issues/61 for this.
>=20
> Note that we did discuss CUBIC for QUIC in =
https://github.com/NTAP/rfc8312bis/issues/45.
>=20
>> 2: Section 3.1 "After a window reduction in response to a congestion =
event is
>>     detected by duplicate ACKs or Explicit Congestion =
Notification-Echo
>>     (ECN-Echo, ECE) ACKs [
>> RFC3168], CUBIC remembers the congestion window..."
>>=20
>>   I think the events detected by RACK (or PTO for QUIC) can also be =
included here.
>=20
> I opened https://github.com/NTAP/rfc8312bis/issues/62
>=20
>> 3: Section 4.1.1
>>    It seems that the text version of the draft uses b_cubic and =
a_aimd, while the pdf version of the
>>    draft uses different names. But, I prefer to use the same names in =
both versions to avoid confusion.
>=20
> The PDF is actually corrupt, due to a Unicode bug in the datatracker =
PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46.
>=20
>> 4: Section 4.2  I personally prefer to refer the equations in the =
draft as 'Equation' rather than 'Figure'  if there's
>>    no strong reason for it.
>=20
> With kramdown-xml2rfc2629, it's unfortunately not possible to change =
this. We would need to add an RFC Editor Note instructing them to =
manually make the change. Opened =
https://github.com/NTAP/rfc8312bis/issues/63
>=20
>> 5: Section 4.3  It seems to me that there are two meanings for a_aimd =
in this section.
>>    One is the additive factor for CUBIC and the other is a generic =
parameter for AIMD() function.
>>    This looks a bit confusing to me.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/64
>=20
>> 6: Section 4.3  The description for P is required for Figure 3.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/65
>=20
>> 7: Section 4.3  I think The analysis in [FHP00] doesn't include =
delayed ACK factor. So, the AIMD TCP model here
>>   can be a bit aggressive compared to a TCP that doesn't enable ABC =
and uses delayed ACK.
>>  This is fine, but I think it might be good to clarify it.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/66
>=20
>> 8: Section 4.3  I am not very sure why segments_acked is used rather =
than byted_acked here. What is the benefit of it?
>>    How do we calculate when the acks are split?
>>   Also, I think it should be clarified that cwnd is expressed in =
segments here in this case.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/67
>=20
>> 9: Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, =
_W_est_ >=3D _W_max_, ..."
>>   I might miss something, but I'm not sure why  a_aimd can be set to =
1 to be compatible with AIMD TCP.
>>   Does this mean b_cubic is also updated? If not, why this can be =
compatible?
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/68
>=20
>> 10: Section 4.5: " The convex profile ensure that the window =
increases very slowly at the beginning.."
>>   I am wondering how much this part is accurate. Because of Principal =
2,  even though cwnd is increased
>>   through convex profile, I think it will be overridden by linear =
growth by AIMD.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/69
>=20
>> 11: Section 4.7: "we update w_max as follows, before the window =
reduction as described in section 4.6"
>>   I am wondering if reducing w_max is the right approach here. =
Because if we reduce w_max, CUBIC
>>   can exit from convex region earlier than the case where fast =
convergence is not used.
>>   It seems to me that keeping w_max and reducing only cwnd (using =
smaller value than b_cubic)
>>   look more conservative.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/70
>=20
>> 12: Section 5.2 and Section 5.3. Do these results are based on the =
algorithms and the parameter values
>>   described in the draft?  If there're differences, I think it should =
be described.
>=20
> Opened https://github.com/NTAP/rfc8312bis/issues/71
>=20
> Thanks,
> Lars
>=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_FA8C4B90-C4EC-429D-AD40-6C84CF3B98A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hello=
 Yoshi and folks,

As =
we are addressing the below issues raised by Yoshi, for one of the =
issues (https://github.com/NTAP/rfc8312bis/issues/64), it would =
be great if you could take a look and provide opinion about whether =
using alpha_aimd as a variable and then assigning a constant value to it =
for Cubic in the draft is confusing or not.

And, of course, you are welcome to look =
at other issues and provide your input.

Thanks,
Vidhi

On Jun 1, 2021, at 2:18 AM, Lars Eggert <lars@eggert.org> =
wrote:

Hi,

many thanks for the =
review!

On 2021-6-1, at 11:35, Yoshifumi =
Nishida <nsd.ietf@gmail.com> wrote:
1: While this draft focuses on only TCP, =
 CUBIC can actually be applied to other transport protocols
    such as QUIC, SCTP. Do we want to mention =
it in the draft or is it out of scope?

I've opened https://github.com/NTAP/rfc8312bis/issues/61 for this.

Note that we did discuss CUBIC for QUIC in https://github.com/NTAP/rfc8312bis/issues/45.

2: =
Section 3.1 "After a window reduction in response to a congestion event =
is
     detected by duplicate ACKs or =
Explicit Congestion Notification-Echo
 =
    (ECN-Echo, ECE) ACKs [
RFC3168], =
CUBIC remembers the congestion window..."

 =
  I think the events detected by RACK (or PTO for QUIC) can =
also be included here.

I =
opened https://github.com/NTAP/rfc8312bis/issues/62

3: =
Section 4.1.1
    It seems that the text =
version of the draft uses b_cubic and a_aimd, while the pdf version of =
the
    draft uses different names. But, I =
prefer to use the same names in both versions to avoid confusion.

The PDF is actually corrupt, due =
to a Unicode bug in the datatracker PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46.

4: =
Section 4.2  I personally prefer to refer the equations in the =
draft as 'Equation' rather than 'Figure'  if there's
 =
   no strong reason for it.

With kramdown-xml2rfc2629, it's unfortunately not possible to =
change this. We would need to add an RFC Editor Note instructing them to =
manually make the change. Opened https://github.com/NTAP/rfc8312bis/issues/63

5: =
Section 4.3  It seems to me that there are two meanings for a_aimd =
in this section.
    One is the additive =
factor for CUBIC and the other is a generic parameter for AIMD() =
function.
    This looks a bit confusing to =
me.

Opened https://github.com/NTAP/rfc8312bis/issues/64

6: =
Section 4.3  The description for P is required for Figure 3.

Opened https://github.com/NTAP/rfc8312bis/issues/65

7: =
Section 4.3  I think The analysis in [FHP00] doesn't include =
delayed ACK factor. So, the AIMD TCP model here
 =
  can be a bit aggressive compared to a TCP that doesn't =
enable ABC and uses delayed ACK.
  This is fine, but =
I think it might be good to clarify it.

Opened https://github.com/NTAP/rfc8312bis/issues/66

8: =
Section 4.3  I am not very sure why segments_acked is used rather =
than byted_acked here. What is the benefit of it?
 =
   How do we calculate when the acks are split?
   Also, I think it should be clarified that cwnd =
is expressed in segments here in this case.
Opened https://github.com/NTAP/rfc8312bis/issues/67

9: =
Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, =
_W_est_ >=3D _W_max_, ..."
   I might miss =
something, but I'm not sure why  a_aimd can be set to 1 to be =
compatible with AIMD TCP.
   Does this mean =
b_cubic is also updated? If not, why this can be compatible?

Opened https://github.com/NTAP/rfc8312bis/issues/68

10: =
Section 4.5: " The convex profile ensure that the window increases very =
slowly at the beginning.."
   I am wondering how =
much this part is accurate. Because of Principal 2,  even though =
cwnd is increased
   through convex profile, I =
think it will be overridden by linear growth by AIMD.

Opened https://github.com/NTAP/rfc8312bis/issues/69

11: =
Section 4.7: "we update w_max as follows, before the window reduction as =
described in section 4.6"
   I am wondering if =
reducing w_max is the right approach here. Because if we reduce w_max, =
CUBIC
   can exit from convex region earlier =
than the case where fast convergence is not used.
 =
  It seems to me that keeping w_max and reducing only cwnd =
(using smaller value than b_cubic)
   look more =
conservative.

Opened https://github.com/NTAP/rfc8312bis/issues/70

12: =
Section 5.2 and Section 5.3. Do these results are based on the =
algorithms and the parameter values
   described =
in the draft?  If there're differences, I think it should be =
described.

Opened https://github.com/NTAP/rfc8312bis/issues/71

Thanks,
Lars


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

=

--Apple-Mail=_FA8C4B90-C4EC-429D-AD40-6C84CF3B98A0--


From nobody Thu Jun 10 02:02:49 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 05C963A3ADF; Thu, 10 Jun 2021 02:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl3uuDZ21cpw; Thu, 10 Jun 2021 02:02:43 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB443A3ADA; Thu, 10 Jun 2021 02:02:42 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 8162F25A16; Thu, 10 Jun 2021 11:02:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623315760; bh=h8dHOCNn+q9zsMM6sWzJv1xivnscWuh8x7V09tm9zYg=; h=From:To:CC:Subject:Date:From; b=DwaJMfM/GxH2muGv8e2PMiV/PSz5BFIP5E3qaw+GCA2Ex3I+5ch4vBohAHP+OcBMg LGud/oWRq7voANV6ukV30HqzP+KqYJ8xpAjSXLW8Qdz0t3mD0zEH9EEJq8mwaT6Ixa kodKW10klkdC8SaoytoNkCijgUlZyFjJWSAvWLcE=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k6ZQO5f2LmQ; Thu, 10 Jun 2021 11:02:39 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 10 Jun 2021 11:02:39 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 10 Jun 2021 11:02:38 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 11:02:38 +0200
From: "Scharf, Michael" 
To: "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQ==
Date: Thu, 10 Jun 2021 09:02:38 +0000
Message-ID: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 09:02:48 -0000

Dear all,

As document shepherd, I have started to work on my write-up for 793bis. Giv=
en that 793bis may one of the most important deliverables of TCPM, I'd like=
 to ensure that the write-up correctly describes the TCPM consensus. Theref=
ore, I share the text before actually hitting the button.

If the write-up listed below is not accurate or misses important details, p=
lease let me know ASAP (on-list of off-list).

I plan to forward 793bis to our AD tomorrow.

Thanks

Michael


***

1. Summary

The document shepherd is Michael Scharf .

The responsible Area Director is Martin Duke .

This document specifies the Transmission Control Protocol (TCP) as "bis" do=
cument to RFC 793. It obsoletes RFC 793 as well as a several other RFCs tha=
t specified additions to RFC 793. It also updates RFC 1122, and it should b=
e considered as a replacement for the portions of that document dealing wit=
h TCP requirements.

The purpose of this document is to bring together all the IETF Standards Tr=
ack changes that have been made to the base TCP functional specification an=
d unify them into an update of RFC 793. The document focuses on the common =
basis all TCP implementations must support to interoperate. With one except=
ion, protocol modifications compared to RFC 793 are limited to standards-tr=
ack RFCs or verified erratas, i.e., changes of TCP standards that already h=
ave IETF consensus.

RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The s=
ame applies to 793bis. The TCPM working group requests publication of 793bi=
s on Standards Track. If approved, the document should replace RFC 793 as "=
STD 7".


2. Review and Consensus

The TCPM working group has worked on this document for more than 6 years, a=
nd many TCPM contributors have reviewed the specification during that time.=
 In particular, many TCP implementers have provided detailed comments based=
 on operational experience. The document was relatively stable in the lates=
t versions. During and after WGLC, several comprehensive reviews flagged so=
me open issues that all got resolved.

793bis improves the specification of TCP but it does not modify the TCP pro=
tocol. TCP is a complex protocol and even minor wording details in the prot=
ocol specification can matter. Given the restriction to TCP changes that al=
ready have IETF consensus, there has never been any major controversy about=
 the main content.

Nonetheless, several questions were non-trivial and triggered longer discus=
sions in TCPM. These issues can roughly be subdivided in three categories:

1/ Being published in 1981, RFC 793 defines several protocol mechanisms tha=
t have become outdated and may not be implemented at all in a modern TCP/IP=
 stack. However, in some cases the corresponding specification in RFC 793 n=
ever got updated or obsoleted and is still formally valid. Appendix A.1 sum=
marizes some of these issues. The TCPM consensus for those cases is to docu=
ment the issues in 793bis, but not to change the TCP standards. The require=
d changes to the TCP standards should be handled by dedicated, narrow-focus=
ed RFCs that would have to reach IETF consensus first. This de-risk strateg=
y ensures that each TCP protocol change can be properly and comprehensively=
 reviewed.

2/ There are some known issues in the standards-track specification of TCP =
that exist but only matter in corner cases. An example is documented in App=
endix A.2. In Internet usage of TCP, these conditions are rarely occurring.=
 Common operating systems include different alternative mitigations, and th=
e standard has not been updated yet to codify one of them. Also, there is n=
o known best approach. Given the lack of practical relevance, the TCPM cons=
ensus is to describe these known problems, but not to change the TCP standa=
rds in 793bis. Again, these problems could be solved by future, dedicated, =
narrow-focused RFC that would have to reach IETF consensus first.=20

3/ There are known deviations between mandatory-to-implement requirements i=
n the TCP standard and some widely deployed implementations. An example are=
 some details in Section 3.8.3, such as the numerical value in MUST-23. Tho=
se cases typically do not affect interoperability with other implementation=
s. The TCPM working group has discussed whether to change the standard in s=
uch cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from=
 going down that road in 793bis, given the huge installed base with a very =
large variety of TCP implementations. Similar like in the previous cases, 7=
93bis may get updated by narrow-focused RFCs.

There is one important exception to the decision not to include new guidanc=
e in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP c=
ongestion control was developed after publication of RFC 793 and the state-=
of-the-art has evolved a lot as compared to RFC 1122. While there are numer=
ous RFCs that specify TCP congestion control, there is no clear normative g=
uidance on the required minimum in all TCP implementations that would be ap=
propriate for 793bis. However, 793bis cannot just stay silent on congestion=
 control. Given the lack of other applicable wording in existing standards,=
 Section 3.8.2 includes new text and is therefore different to the rest of =
the document. Section 3.8.2 was comprehensively reviewed by the TCPM workin=
g group and in particular by TCP implementers. The section is short and str=
aightforward, and the wording was chosen very carefully to reflect existing=
 TCP standards and operational experience in the Internet. Also, given ongo=
ing research, TCP congestion control will most likely further evolve in fut=
ure. Section 3.8.2 enables such a further evolution while defining importan=
t base requirements.

Running code exists - in billions of TCP/IP stacks. Given the very limited =
scope of modifications in the 793bis document, all TCP implementations that=
 are already compliant to the TCP standards before publication of 793bis sh=
ould be compliant to 793bis as well.

The shepherd believes that the 793bis document has unanimous support from t=
he entire TCPM working group.


3. Intellectual Property

The editor has stated that his direct, personal knowledge of any IPR relate=
d to this document has already been disclosed, in conformance with BCPs 78 =
and 79. The editor is not aware of any IPR relevant for the base TCP protoc=
ol. Since 793bis does not change the TCP protocol, relevant IPR would have =
to be disclosed already for the existing RFCs included in 793bis.

There is a Cisco IPR disclosure from year 2004 related to the Internet-Draf=
t that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 59=
61 is one source of changes included in 793bis. In all places in 793bis whe=
re the recommendations from RFC 5961 are mentioned, 5961 is prominently ref=
erenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes descri=
bed in RFC 5961 are optional and not mandatory-to-implement.

It has been suggested that the owner of the IPR disclosed in https://datatr=
acker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it=
 applies to 793bis, or not.

The TCPM working group is aware of the IPR disclosure related to RFC 5961, =
which is known already for a long time. The document shepherd has verified =
on the TCPM mailing list that the TCPM working group is fine with the propo=
sed text in 793bis related to RFC 5961. In the TCPM working group there are=
 no known concerns regarding this IPR disclosure related to an optional mec=
hanism.


4. Other Points

The intended status listed in the document is "Proposed Standard". As all m=
ain TCP implementations are supposed to comply with 793bis, the document ma=
y fulfill the requirements of an "Internet Standard" according to RFC 2026 =
and RFC 7127.=20

idnits reports some warnings, such as obsolete references. These are all fa=
lse positives. The document refers to some obsolete documents to provide hi=
storical context.

The IANA Considerations in Section 5 include some editorial clean-up of the=
 TCP entries in the IANA registry. The modifications neither change any all=
ocation nor any policy in the IANA registry. These purely editorial changes=
 have been discussed in the TCPM working group for a long time and there is=
 unanimous consensus in TCPM that this clean-up is useful.

All errata to RFC 793 and related RFCs have been considered in this "bis" d=
ocument.

When Wes started working on a 793bis document in 2013, the document shepher=
d, as well as many other TCPM contributors, were pretty convinced that writ=
ing a 793bis document is an impossible endeavor. Well, after many years, we=
 are proven wrong. Many thanks to Wes as editor!


From nobody Thu Jun 10 07:49:26 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 EBCA53A42FE; Thu, 10 Jun 2021 07:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 XLATWEiN0N8N; Thu, 10 Jun 2021 07:49:20 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 AEB4E3A42FC; Thu, 10 Jun 2021 07:49:19 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4G16Lk001dzBscm;  Thu, 10 Jun 2021 16:49:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1623336558; bh=s5daEFxYi3Q1u8dOxI13TekNzt/itUbdl85gH0C+MTk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=SZuOrGGGIUAqmGdOgsiAOUV8qQydoHkH9KlmtHup752lxBj/rVoyvtpb6bF+VxG8z QArhal1T3azdwvPVuqHeVmE3Iw3Q5T0/ieJXItpOqz/JmPMpR4Ae0IFXSPeM/fKiw6 AZUS30I2CArSvcyI5mGDhdl9RbHxXrj24cgzKHJ4quzxE8s0ZD/hYOfyWR3Zw4K6oB iYbZauox872dtqaya5F9ybzzA6J8rZiEr9x1nFMlU0X3N/Jo8eWe351qIHIZh5Irip RhctDQF8BbOCtxUZrugHg3+SXV5RkXoq/dkI4YlQWHoqThBRig4it3+cZBlFfioQJV 4Shd7C1HrHUdg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar03.francetelecom.fr (ESMTP service) with ESMTPS id 4G16Lj65X4zCqkv;  Thu, 10 Jun 2021 16:49:17 +0200 (CEST)
From: 
To: "Scharf, Michael" , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAMP1VQ
Date: Thu, 10 Jun 2021 14:49:16 +0000
Message-ID: <3560_1623336557_60C2266D_3560_462_1_787AE7BB302AE849A7480A190F8B9330353A7B8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
In-Reply-To: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 14:49:25 -0000

Hi Michael,=20

One comment about the IANA part, we have agreed to move one existing IANA *=
*registry** to be a **sub-registry** under the existing TCP registry. I wou=
ld update the IANA part accordingly.=20

Other than that, this looks good. Thanks.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf,
> Michael
> Envoy=E9=A0: jeudi 10 juin 2021 11:03
> =C0=A0: tcpm@ietf.org
> Cc=A0: tcpm-chairs 
> Objet=A0: [tcpm] Draft schepherd write-up for 793bis
>=20
> Dear all,
>=20
> As document shepherd, I have started to work on my write-up for
> 793bis. Given that 793bis may one of the most important deliverables
> of TCPM, I'd like to ensure that the write-up correctly describes
> the TCPM consensus. Therefore, I share the text before actually
> hitting the button.
>=20
> If the write-up listed below is not accurate or misses important
> details, please let me know ASAP (on-list of off-list).
>=20
> I plan to forward 793bis to our AD tomorrow.
>=20
> Thanks
>=20
> Michael
>=20
>=20
> ***
>=20
> 1. Summary
>=20
> The document shepherd is Michael Scharf  esslingen.de>.
>=20
> The responsible Area Director is Martin Duke
> .
>=20
> This document specifies the Transmission Control Protocol (TCP) as
> "bis" document to RFC 793. It obsoletes RFC 793 as well as a several
> other RFCs that specified additions to RFC 793. It also updates RFC
> 1122, and it should be considered as a replacement for the portions
> of that document dealing with TCP requirements.
>=20
> The purpose of this document is to bring together all the IETF
> Standards Track changes that have been made to the base TCP
> functional specification and unify them into an update of RFC 793.
> The document focuses on the common basis all TCP implementations
> must support to interoperate. With one exception, protocol
> modifications compared to RFC 793 are limited to standards-track
> RFCs or verified erratas, i.e., changes of TCP standards that
> already have IETF consensus.
>=20
> RFC 793 and RFC 1122 are ubiquitously implemented Internet
> Standards. The same applies to 793bis. The TCPM working group
> requests publication of 793bis on Standards Track. If approved, the
> document should replace RFC 793 as "STD 7".
>=20
>=20
> 2. Review and Consensus
>=20
> The TCPM working group has worked on this document for more than 6
> years, and many TCPM contributors have reviewed the specification
> during that time. In particular, many TCP implementers have provided
> detailed comments based on operational experience. The document was
> relatively stable in the latest versions. During and after WGLC,
> several comprehensive reviews flagged some open issues that all got
> resolved.
>=20
> 793bis improves the specification of TCP but it does not modify the
> TCP protocol. TCP is a complex protocol and even minor wording
> details in the protocol specification can matter. Given the
> restriction to TCP changes that already have IETF consensus, there
> has never been any major controversy about the main content.
>=20
> Nonetheless, several questions were non-trivial and triggered longer
> discussions in TCPM. These issues can roughly be subdivided in three
> categories:
>=20
> 1/ Being published in 1981, RFC 793 defines several protocol
> mechanisms that have become outdated and may not be implemented at
> all in a modern TCP/IP stack. However, in some cases the
> corresponding specification in RFC 793 never got updated or
> obsoleted and is still formally valid. Appendix A.1 summarizes some
> of these issues. The TCPM consensus for those cases is to document
> the issues in 793bis, but not to change the TCP standards. The
> required changes to the TCP standards should be handled by
> dedicated, narrow-focused RFCs that would have to reach IETF
> consensus first. This de-risk strategy ensures that each TCP
> protocol change can be properly and comprehensively reviewed.
>=20
> 2/ There are some known issues in the standards-track specification
> of TCP that exist but only matter in corner cases. An example is
> documented in Appendix A.2. In Internet usage of TCP, these
> conditions are rarely occurring. Common operating systems include
> different alternative mitigations, and the standard has not been
> updated yet to codify one of them. Also, there is no known best
> approach. Given the lack of practical relevance, the TCPM consensus
> is to describe these known problems, but not to change the TCP
> standards in 793bis. Again, these problems could be solved by
> future, dedicated, narrow-focused RFC that would have to reach IETF
> consensus first.
>=20
> 3/ There are known deviations between mandatory-to-implement
> requirements in the TCP standard and some widely deployed
> implementations. An example are some details in Section 3.8.3, such
> as the numerical value in MUST-23. Those cases typically do not
> affect interoperability with other implementations. The TCPM working
> group has discussed whether to change the standard in such cases
> (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from
> going down that road in 793bis, given the huge installed base with a
> very large variety of TCP implementations. Similar like in the
> previous cases, 793bis may get updated by narrow-focused RFCs.
>=20
> There is one important exception to the decision not to include new
> guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion
> Control". TCP congestion control was developed after publication of
> RFC 793 and the state-of-the-art has evolved a lot as compared to
> RFC 1122. While there are numerous RFCs that specify TCP congestion
> control, there is no clear normative guidance on the required
> minimum in all TCP implementations that would be appropriate for
> 793bis. However, 793bis cannot just stay silent on congestion
> control. Given the lack of other applicable wording in existing
> standards, Section 3.8.2 includes new text and is therefore
> different to the rest of the document. Section 3.8.2 was
> comprehensively reviewed by the TCPM working group and in particular
> by TCP implementers. The section is short and straightforward, and
> the wording was chosen very carefully to reflect existing TCP
> standards and operational experience in the Internet. Also, given
> ongoing research, TCP conge  stion control will most likely further
> evolve in future. Section 3.8.2 enables such a further evolution
> while defining important base requirements.
>=20
> Running code exists - in billions of TCP/IP stacks. Given the very
> limited scope of modifications in the 793bis document, all TCP
> implementations that are already compliant to the TCP standards
> before publication of 793bis should be compliant to 793bis as well.
>=20
> The shepherd believes that the 793bis document has unanimous support
> from the entire TCPM working group.
>=20
>=20
> 3. Intellectual Property
>=20
> The editor has stated that his direct, personal knowledge of any IPR
> related to this document has already been disclosed, in conformance
> with BCPs 78 and 79. The editor is not aware of any IPR relevant for
> the base TCP protocol. Since 793bis does not change the TCP
> protocol, relevant IPR would have to be disclosed already for the
> existing RFCs included in 793bis.
>=20
> There is a Cisco IPR disclosure from year 2004 related to the
> Internet-Draft that resulted in RFC 5961
> (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of
> changes included in 793bis. In all places in 793bis where the
> recommendations from RFC 5961 are mentioned, 5961 is prominently
> referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the
> changes described in RFC 5961 are optional and not mandatory-to-
> implement.
>=20
> It has been suggested that the owner of the IPR disclosed in
> https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to
> make clear whether it applies to 793bis, or not.
>=20
> The TCPM working group is aware of the IPR disclosure related to RFC
> 5961, which is known already for a long time. The document shepherd
> has verified on the TCPM mailing list that the TCPM working group is
> fine with the proposed text in 793bis related to RFC 5961. In the
> TCPM working group there are no known concerns regarding this IPR
> disclosure related to an optional mechanism.
>=20
>=20
> 4. Other Points
>=20
> The intended status listed in the document is "Proposed Standard".
> As all main TCP implementations are supposed to comply with 793bis,
> the document may fulfill the requirements of an "Internet Standard"
> according to RFC 2026 and RFC 7127.
>=20
> idnits reports some warnings, such as obsolete references. These are
> all false positives. The document refers to some obsolete documents
> to provide historical context.
>=20
> The IANA Considerations in Section 5 include some editorial clean-up
> of the TCP entries in the IANA registry. The modifications neither
> change any allocation nor any policy in the IANA registry. These
> purely editorial changes have been discussed in the TCPM working
> group for a long time and there is unanimous consensus in TCPM that
> this clean-up is useful.
>=20
> All errata to RFC 793 and related RFCs have been considered in this
> "bis" document.
>=20
> When Wes started working on a 793bis document in 2013, the document
> shepherd, as well as many other TCPM contributors, were pretty
> convinced that writing a 793bis document is an impossible endeavor.
> Well, after many years, we are proven wrong. Many thanks to Wes as
> editor!
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Thu Jun 10 08:21: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 4B5813A43CA; Thu, 10 Jun 2021 08:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 inIgq6SunJP5; Thu, 10 Jun 2021 08:21:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 422C63A43C4; Thu, 10 Jun 2021 08:21:13 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr24.francetelecom.fr (ESMTP service) with ESMTPS id 4G173W3pPwz2013;  Thu, 10 Jun 2021 17:21:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1623338471; bh=IWmlRhGDGdwhC5pY5IG8W8bnfGXelkBVImACzSRWnB0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=HXxJDhM4qJh5XqioK5jFL73TCqKaW+JsW3wev90/k/8vCYY+1cpBXqeTVsKHo7QSY +98xhyMLo+RtvdURNBLbFlNOf0bkbfrLKNEia/QOpskEqv2lmbWkNc8Fu+l6Z/c8Cb JO9GX5UDir88F4QTQmXczeXJNn0yJrZipyAwH/8JTFGxTvu1VrTCkwFABcC4jZXWhL 9Pc6dn8tWZzsMv/hYZK+pS/IIVwIRlQccbLQPjY+FFU9wLwI31RJ0s9REfgUF8mr67 8tTYKp+2p9XSGiHjQYW1lk/BBqXL5QzadZUInOZZnr0HnjVF23dRDxp565mWgp2pqN /PESIpGxTOEVw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4G173W2sfYzDq7j;  Thu, 10 Jun 2021 17:21:11 +0200 (CEST)
From: 
To: "Scharf, Michael" , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAMP1VQAAEn3SA=
Date: Thu, 10 Jun 2021 15:21:10 +0000
Message-ID: <14061_1623338471_60C22DE7_14061_318_1_787AE7BB302AE849A7480A190F8B9330353A7C4C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de> <3560_1623336557_60C2266D_3560_462_1_787AE7BB302AE849A7480A190F8B9330353A7B8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <3560_1623336557_60C2266D_3560_462_1_787AE7BB302AE849A7480A190F8B9330353A7B8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 15:21:19 -0000

Re-,

FWIW, here is a proposal for the IANA part of the write-up:=20

OLD:=20

The IANA Considerations in Section 5 include some editorial clean-up of the=
 TCP entries in the IANA registry. The modifications neither change any all=
ocation nor any policy in the IANA registry. These purely editorial changes=
 have been discussed in the TCPM working group for a long time and there is=
 unanimous consensus in TCPM that this clean-up is useful.

NEW:

The IANA section includes many actions:
(1) Update the structure of the TCP flags registry to include a new column =
called "Assignment Notes"=20
(2) Rename "Bit" column of the TCP flags registry to "Bit Offset"
(3) Update the TCP flags registry to include all assigned TCP flags, not on=
ly those initially assigned in RFC 3168. 10-15 values are assigned.=20
(4) Move the existing TCP flags registry to be as sub-registry of the TCP r=
egistry.

There was unanimous consensus in TCPM with these changes.

Cheers,
Med

> -----Message d'origine-----
> De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoy=E9=A0: jeudi 10 juin 2021 16:49
> =C0=A0: Scharf, Michael ; tcpm@ietf.org
> Cc=A0: tcpm-chairs 
> Objet=A0: Re: [tcpm] Draft schepherd write-up for 793bis
>=20
> Hi Michael,
>=20
> One comment about the IANA part, we have agreed to move one existing
> IANA **registry** to be a **sub-registry** under the existing TCP
> registry. I would update the IANA part accordingly.
>=20
> Other than that, this looks good. Thanks.
>=20
> Cheers,
> Med
>=20
> > -----Message d'origine-----
> > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf,
> Michael
> > Envoy=E9=A0: jeudi 10 juin 2021 11:03 =C0=A0: tcpm@ietf.org Cc=A0: tcpm-
> chairs
> >  Objet=A0: [tcpm] Draft schepherd write-up for
> > 793bis
> >
> > Dear all,
> >
> > As document shepherd, I have started to work on my write-up for
> > 793bis. Given that 793bis may one of the most important
> deliverables
> > of TCPM, I'd like to ensure that the write-up correctly describes
> the
> > TCPM consensus. Therefore, I share the text before actually
> hitting
> > the button.
> >
> > If the write-up listed below is not accurate or misses important
> > details, please let me know ASAP (on-list of off-list).
> >
> > I plan to forward 793bis to our AD tomorrow.
> >
> > Thanks
> >
> > Michael
> >
> >
> > ***
> >
> > 1. Summary
> >
> > The document shepherd is Michael Scharf  > esslingen.de>.
> >
> > The responsible Area Director is Martin Duke
> > .
> >
> > This document specifies the Transmission Control Protocol (TCP) as
> > "bis" document to RFC 793. It obsoletes RFC 793 as well as a
> several
> > other RFCs that specified additions to RFC 793. It also updates
> RFC
> > 1122, and it should be considered as a replacement for the
> portions of
> > that document dealing with TCP requirements.
> >
> > The purpose of this document is to bring together all the IETF
> > Standards Track changes that have been made to the base TCP
> functional
> > specification and unify them into an update of RFC 793.
> > The document focuses on the common basis all TCP implementations
> must
> > support to interoperate. With one exception, protocol
> modifications
> > compared to RFC 793 are limited to standards-track RFCs or
> verified
> > erratas, i.e., changes of TCP standards that already have IETF
> > consensus.
> >
> > RFC 793 and RFC 1122 are ubiquitously implemented Internet
> Standards.
> > The same applies to 793bis. The TCPM working group requests
> > publication of 793bis on Standards Track. If approved, the
> document
> > should replace RFC 793 as "STD 7".
> >
> >
> > 2. Review and Consensus
> >
> > The TCPM working group has worked on this document for more than 6
> > years, and many TCPM contributors have reviewed the specification
> > during that time. In particular, many TCP implementers have
> provided
> > detailed comments based on operational experience. The document
> was
> > relatively stable in the latest versions. During and after WGLC,
> > several comprehensive reviews flagged some open issues that all
> got
> > resolved.
> >
> > 793bis improves the specification of TCP but it does not modify
> the
> > TCP protocol. TCP is a complex protocol and even minor wording
> details
> > in the protocol specification can matter. Given the restriction to
> TCP
> > changes that already have IETF consensus, there has never been any
> > major controversy about the main content.
> >
> > Nonetheless, several questions were non-trivial and triggered
> longer
> > discussions in TCPM. These issues can roughly be subdivided in
> three
> > categories:
> >
> > 1/ Being published in 1981, RFC 793 defines several protocol
> > mechanisms that have become outdated and may not be implemented at
> all
> > in a modern TCP/IP stack. However, in some cases the corresponding
> > specification in RFC 793 never got updated or obsoleted and is
> still
> > formally valid. Appendix A.1 summarizes some of these issues. The
> TCPM
> > consensus for those cases is to document the issues in 793bis, but
> not
> > to change the TCP standards. The required changes to the TCP
> standards
> > should be handled by dedicated, narrow-focused RFCs that would
> have to
> > reach IETF consensus first. This de-risk strategy ensures that
> each
> > TCP protocol change can be properly and comprehensively reviewed.
> >
> > 2/ There are some known issues in the standards-track
> specification of
> > TCP that exist but only matter in corner cases. An example is
> > documented in Appendix A.2. In Internet usage of TCP, these
> conditions
> > are rarely occurring. Common operating systems include different
> > alternative mitigations, and the standard has not been updated yet
> to
> > codify one of them. Also, there is no known best approach. Given
> the
> > lack of practical relevance, the TCPM consensus is to describe
> these
> > known problems, but not to change the TCP standards in 793bis.
> Again,
> > these problems could be solved by future, dedicated, narrow-
> focused
> > RFC that would have to reach IETF consensus first.
> >
> > 3/ There are known deviations between mandatory-to-implement
> > requirements in the TCP standard and some widely deployed
> > implementations. An example are some details in Section 3.8.3,
> such as
> > the numerical value in MUST-23. Those cases typically do not
> affect
> > interoperability with other implementations. The TCPM working
> group
> > has discussed whether to change the standard in such cases (e.g.,
> > downgrade MUST-23 to a SHOULD), but finally refrained from going
> down
> > that road in 793bis, given the huge installed base with a very
> large
> > variety of TCP implementations. Similar like in the previous
> cases,
> > 793bis may get updated by narrow-focused RFCs.
> >
> > There is one important exception to the decision not to include
> new
> > guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion
> > Control". TCP congestion control was developed after publication
> of
> > RFC 793 and the state-of-the-art has evolved a lot as compared to
> RFC
> > 1122. While there are numerous RFCs that specify TCP congestion
> > control, there is no clear normative guidance on the required
> minimum
> > in all TCP implementations that would be appropriate for 793bis.
> > However, 793bis cannot just stay silent on congestion control.
> Given
> > the lack of other applicable wording in existing standards,
> Section
> > 3.8.2 includes new text and is therefore different to the rest of
> the
> > document. Section 3.8.2 was comprehensively reviewed by the TCPM
> > working group and in particular by TCP implementers. The section
> is
> > short and straightforward, and the wording was chosen very
> carefully
> > to reflect existing TCP standards and operational experience in
> the
> > Internet. Also, given ongoing research, TCP conge  stion control
> will
> > most likely further evolve in future. Section 3.8.2 enables such a
> > further evolution while defining important base requirements.
> >
> > Running code exists - in billions of TCP/IP stacks. Given the very
> > limited scope of modifications in the 793bis document, all TCP
> > implementations that are already compliant to the TCP standards
> before
> > publication of 793bis should be compliant to 793bis as well.
> >
> > The shepherd believes that the 793bis document has unanimous
> support
> > from the entire TCPM working group.
> >
> >
> > 3. Intellectual Property
> >
> > The editor has stated that his direct, personal knowledge of any
> IPR
> > related to this document has already been disclosed, in
> conformance
> > with BCPs 78 and 79. The editor is not aware of any IPR relevant
> for
> > the base TCP protocol. Since 793bis does not change the TCP
> protocol,
> > relevant IPR would have to be disclosed already for the existing
> RFCs
> > included in 793bis.
> >
> > There is a Cisco IPR disclosure from year 2004 related to the
> > Internet-Draft that resulted in RFC 5961
> > (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of
> > changes included in 793bis. In all places in 793bis where the
> > recommendations from RFC 5961 are mentioned, 5961 is prominently
> > referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the
> > changes described in RFC 5961 are optional and not mandatory-to-
> > implement.
> >
> > It has been suggested that the owner of the IPR disclosed in
> > https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure
> to
> > make clear whether it applies to 793bis, or not.
> >
> > The TCPM working group is aware of the IPR disclosure related to
> RFC
> > 5961, which is known already for a long time. The document
> shepherd
> > has verified on the TCPM mailing list that the TCPM working group
> is
> > fine with the proposed text in 793bis related to RFC 5961. In the
> TCPM
> > working group there are no known concerns regarding this IPR
> > disclosure related to an optional mechanism.
> >
> >
> > 4. Other Points
> >
> > The intended status listed in the document is "Proposed Standard".
> > As all main TCP implementations are supposed to comply with
> 793bis,
> > the document may fulfill the requirements of an "Internet
> Standard"
> > according to RFC 2026 and RFC 7127.
> >
> > idnits reports some warnings, such as obsolete references. These
> are
> > all false positives. The document refers to some obsolete
> documents to
> > provide historical context.
> >
> > The IANA Considerations in Section 5 include some editorial clean-
> up
> > of the TCP entries in the IANA registry. The modifications neither
> > change any allocation nor any policy in the IANA registry. These
> > purely editorial changes have been discussed in the TCPM working
> group
> > for a long time and there is unanimous consensus in TCPM that this
> > clean-up is useful.
> >
> > All errata to RFC 793 and related RFCs have been considered in
> this
> > "bis" document.
> >
> > When Wes started working on a 793bis document in 2013, the
> document
> > shepherd, as well as many other TCPM contributors, were pretty
> > convinced that writing a 793bis document is an impossible
> endeavor.
> > Well, after many years, we are proven wrong. Many thanks to Wes as
> > editor!
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>=20
> ____________________________________________________________________
> _____________________________________________________
>=20
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler a l'expediteur et le
> detruire ainsi que les pieces jointes. Les messages electroniques
> etant susceptibles d'alteration, Orange decline toute responsabilite
> si ce message a ete altere, deforme ou falsifie. Merci.
>=20
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender
> and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
> Thank you.
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Thu Jun 10 09:14:28 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 45EBC3A4560; Thu, 10 Jun 2021 09:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=btconnect.onmicrosoft.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 PE46Be-TKpFZ; Thu, 10 Jun 2021 09:14:21 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140108.outbound.protection.outlook.com [40.107.14.108]) (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 7B63E3A4564; Thu, 10 Jun 2021 09:14:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RVob/d09NVEP9BbaW4dpezZYMyzu/4if3xDZ0I0n37xWYgKl9WwbjXLzUaiDKwBVvhY28efYUXGXdfP5iM8XvjmavUq7DS9RxrCPAWFH5/5bnBaDDQ4Ar2FUogCNb81WwoOXWGbGRD5Guye2d38Frn2aZHQ6wUrh6E0ezysESFTFpQVjn1ybDUj8xlqXqQ4I8vZpCMinDKd1WwyFz/4ro60ClkaXKu3UrV0RtMf7oDkoy3H2qJwciOC/H5QZVSk0ccLZP42/GDtcP4eK9BtS7MqTKGz2RsB4CRw6Ar2kynggvlOerSLWYB8aYEmfF+EuqUWMBoBa2JRoo6dtBOvg3g==
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=AorGQQ+8hsb6aMwq6dUqLjzV3avb3cmLQncGC7ibs7Q=; b=fqdKdcIdsnumg8szwV0bqLmrnMsTyXsAH8+JabvBpcbUGI/hNmY3DINGtNjvH3sjceBg3SBbVD3+ROFI/O+sNhM0KcPLHDxCpR7MKuBDHmnag+pJE8HAfzIiegW6e2eSahDy+SdwsBADhDD988NqKbjUV2jErLBGVgOmGptc6tHNsZdMtchWF5d0d7x9d/WIlx6Fgs8HqxRw0nGBfnNp0YAerATrr8r7B2OLCWQ3eYHhVWxi7VBcNxgUTKzNrdXddbL0yBKZszzW/T0HjRC2y5m0UzJ4ICNxYrXoL/nepiTFrXtFA4Rpql1w/1Qh85QX9yLkswGZ106GyxtfqUeZcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AorGQQ+8hsb6aMwq6dUqLjzV3avb3cmLQncGC7ibs7Q=; b=UcOgNAEd8sg0tDFL+LQso12+T9rKU372R6zPmnkyG9ENBncra++l+bsFCfbBKT1VV3VjVtnA3uZFPEEnUXhhAvF09+NR4TpMqflKSFQpkc+L9Wmib8svPfOzCPCl5IR8Bw/dmnIdDEouuPKOHs7LSMwyHhvXFK/fADRDZwMrgRw=
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB7PR07MB4475.eurprd07.prod.outlook.com (2603:10a6:5:38::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.17; Thu, 10 Jun 2021 16:14:16 +0000
Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::ddb2:16dd:9380:90c7]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::ddb2:16dd:9380:90c7%3]) with mapi id 15.20.4219.021; Thu, 10 Jun 2021 16:14:16 +0000
From: tom petch 
To: "Scharf, Michael" , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAPNXYw
Date: Thu, 10 Jun 2021 16:14:16 +0000
Message-ID: 
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
In-Reply-To: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none;hs-esslingen.de; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.143.250.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4d433876-31e8-4793-0855-08d92c2acb84
x-ms-traffictypediagnostic: DB7PR07MB4475:
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: QUOw/iotHUSzyhf9X/S/VkKrM5LzQfXYYl/UoSNVsVYF+03t+KBXh4NF76QLouLSeJPKYHl7HJF/lCICZGqAUYV270cQ5fKcXZdDGaESaQpiJJ3Yo5pCuFkY3mhvo0+UvS2dvdseyJf73cPIn2WBgFPa2yiftYsdAZNs4TVSRSNeQpEJVM7ADsR2PQtddHY2mSwMyBrOYqUHTEovT0xw1gyTIY8q9mcjIxcbtcBANnOBF1iOezfe+0X5DQfdnrd0Wp7Jhcd9p8/lLoDMjXU3Nuy3xO/XcjXMClyf168u+N9Sj45Go6GhYS4xgL0utFmPVU6onx7Ih9+/FNupz/4hU6OekK2BDn9mw37nH5g+fUD0Ptmvqm+qGI4aG1ZHVUfnEVNLGW0P/Rq2FXglIOUF+IrJTS68wZhMIgZa2LjstJG25x0fQppkVMNHVuINYQJ1CEKYPTPAQ446YBmJ6Qg2+F54cgSdQ/zo7xjcemxgcZJoSEtGUO7tShgjsySob3V5qDi/6KaLWYlt9oUvuIxzxP8cNJlSWQ5pU4+sPJCf4tRvWPWz+vb7bpS4458Mst9bDpWOKl3l4lgUMYHxA6HyuKJIknVCUMzy4w42yIn1xtvlL5cRL2l+u2LCnL4mekMHpEOmwQ4VhaupKeHQb7XWuR3M23xDiFtMl3KwtzA/P5WVBpnrc7WPTj1EglZPsrlsZSCGQ7VRrl4FyLzlpF0MKajoN2SFisbm8uFjhRPpYRbwntnnl5oY13/EjDYpwM5l
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(396003)(346002)(376002)(366004)(136003)(39860400002)(91956017)(66476007)(66946007)(33656002)(66446008)(76116006)(7696005)(66574015)(966005)(6506007)(66556008)(64756008)(55016002)(8676002)(2906002)(5660300002)(52536014)(4326008)(186003)(83380400001)(86362001)(8936002)(26005)(71200400001)(38100700002)(122000001)(9686003)(110136005)(478600001)(316002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?jP6/snkeP0pjVJ1L0C8LUwjDlCjByXQ/pZAyXFej7KJdyTJ3rjjkPylAOu?= =?iso-8859-1?Q?Bxrpz0RjIOadur3DcnBQxybjlLEOWkG8XyggbWmItLk4NRhD3nfSij4kfH?= =?iso-8859-1?Q?p34gV+9bv4pr/k0M0FJRzXuCt2zXOWKNrwN3J7nuRfOx6+MlbA53TOayJ5?= =?iso-8859-1?Q?om+LxySh6lo+JM49Yw/J8+M7YS6miTo3qhpZ2jGftNQhIibblMW8oFKSY1?= =?iso-8859-1?Q?67vzGcVr9/ODpBuEO4BBbiksHkmlmYTZg/rJMA+8r2zJGKbsIj0EH7/vqz?= =?iso-8859-1?Q?N5T7y/tERPmg8gMSECCDEQ8anFm1PACXkm3+9PIqf1C5AQslBMkjiWn8dG?= =?iso-8859-1?Q?23Ui630h22F48D6t0xba1hEd39yaWNOC1D4D4GEUds43Dv8NVuKt5f+O1x?= =?iso-8859-1?Q?YfXeQUj2tfHQzAHjHjqtOL3NH2WytLohJzipv4FVLVi/DhuCujjAPNefvG?= =?iso-8859-1?Q?3ApUyaWfsk34ujhM8notgczLSaLR++KkVxlTSF8C89AQSmKAEBvfGvGdNz?= =?iso-8859-1?Q?7FyymZw5PQgE4wi+XKqsYfWcR0J7DGC+0DmklypT1eJDQzB4ZEgsJMvRTX?= =?iso-8859-1?Q?Bw7/GwSR7rkMn+7wpIrdzNfQvYHbSWTfc7eo62lmbaXH+XNKS68t4KXmp0?= =?iso-8859-1?Q?RJMNuC0M4EUDt+08ayUxeXVZLpxEqA16yReVikqsb+4MZYCoa2ubyZao5h?= =?iso-8859-1?Q?ZfPf0AND0s262kSPGr/wP0IR81/N+LX+gkXDglj73F/3n4r9M9N9yrGadD?= =?iso-8859-1?Q?ShmowCzeyTAKoFC3Y2pQcju2Fbr/wM7/EJejy/Gkwuw/mgO2wnUMnfRMoY?= =?iso-8859-1?Q?i5wjdVguM3xEyhciCcWEikZaow0Na/I4wbgc2TRVlIO050SIaz6KutmTZf?= =?iso-8859-1?Q?2e98M0tkMTTb6MDXkhaRqyDgLfBzu6nT1BF237z7cdG/wUtluzXUd5RGcU?= =?iso-8859-1?Q?wX89m7mwDi88y681gziI4cCSq7oRKmvDxUg+6kpL5gMVFczXkixEkteX4a?= =?iso-8859-1?Q?J9FqsWjrUjX9dxWbMme0JeMZ7sPb8zgU6tl4avSvu6Y+vTkb0XFM2JKhSS?= =?iso-8859-1?Q?E4aNaErXvnY7bOoBvvM9y8kAtBozAvOb+eqRYr3Azujs5854Lf2LZCdXfh?= =?iso-8859-1?Q?K70cIzYNkxm32PD8GoBCcCE22goMfUroEdfkQ0MPC+ZHiCTHQe1xec6zwH?= =?iso-8859-1?Q?5iFKqwcLqpfwhJtu/KF949C2uTqTkR8zUErqwCByN2IdHw92aWNlhlr8nI?= =?iso-8859-1?Q?B+jnanw7e589JyM1s0ILuPmIaWnIkLiXDwkfjM/v38rzMa783O4Y+dEwEH?= =?iso-8859-1?Q?Z3BYzEVzw+ZIS84ZyF9Zgd8KJ0+p1EsPUdaJgTaQjKquoHw=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d433876-31e8-4793-0855-08d92c2acb84
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2021 16:14:16.3092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aWG4q+/L8aM4uOUIDj+Q5g/5mk9dN0pg0A2KgE9+8tzejugxIqlpIQiZiNgUDyVn+1E23eMHc5zG8u4CceBz/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4475
Archived-At: 
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 16:14:27 -0000

From: tcpm  on behalf of Scharf, Michael =0A=
Sent: 10 June 2021 10:02=0A=
=0A=
Dear all,=0A=
=0A=
As document shepherd, I have started to work on my write-up for 793bis. Giv=
en that 793bis may one of the most important deliverables of TCPM, I'd like=
 to ensure that the write-up correctly describes the TCPM consensus. Theref=
ore, I share the text before actually hitting the button.=0A=
=0A=
If the write-up listed below is not accurate or misses important details, p=
lease let me know ASAP (on-list of off-list).=0A=
=0A=
I plan to forward 793bis to our AD tomorrow.=0A=
=0A=
=0A=
Michael=0A=
=0A=
Lots of good stuff but it does not appear to follow the template, a layout =
which I find  useful when wanting to check on an aspect thereof, such as va=
lidation by sundry tools, as it saves me having to work my way through it.=
=0A=
=0A=
Tom Petch=0A=
p.s. Reviewing 793bis has been on mytodo list for an embarrassing number of=
 years:-(=0A=
=0A=
Thanks=0A=
=0A=
Michael=0A=
=0A=
=0A=
***=0A=
=0A=
1. Summary=0A=
=0A=
The document shepherd is Michael Scharf .=
=0A=
=0A=
The responsible Area Director is Martin Duke .=0A=
=0A=
This document specifies the Transmission Control Protocol (TCP) as "bis" do=
cument to RFC 793. It obsoletes RFC 793 as well as a several other RFCs tha=
t specified additions to RFC 793. It also updates RFC 1122, and it should b=
e considered as a replacement for the portions of that document dealing wit=
h TCP requirements.=0A=
=0A=
The purpose of this document is to bring together all the IETF Standards Tr=
ack changes that have been made to the base TCP functional specification an=
d unify them into an update of RFC 793. The document focuses on the common =
basis all TCP implementations must support to interoperate. With one except=
ion, protocol modifications compared to RFC 793 are limited to standards-tr=
ack RFCs or verified erratas, i.e., changes of TCP standards that already h=
ave IETF consensus.=0A=
=0A=
RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The s=
ame applies to 793bis. The TCPM working group requests publication of 793bi=
s on Standards Track. If approved, the document should replace RFC 793 as "=
STD 7".=0A=
=0A=
=0A=
2. Review and Consensus=0A=
=0A=
The TCPM working group has worked on this document for more than 6 years, a=
nd many TCPM contributors have reviewed the specification during that time.=
 In particular, many TCP implementers have provided detailed comments based=
 on operational experience. The document was relatively stable in the lates=
t versions. During and after WGLC, several comprehensive reviews flagged so=
me open issues that all got resolved.=0A=
=0A=
793bis improves the specification of TCP but it does not modify the TCP pro=
tocol. TCP is a complex protocol and even minor wording details in the prot=
ocol specification can matter. Given the restriction to TCP changes that al=
ready have IETF consensus, there has never been any major controversy about=
 the main content.=0A=
=0A=
Nonetheless, several questions were non-trivial and triggered longer discus=
sions in TCPM. These issues can roughly be subdivided in three categories:=
=0A=
=0A=
1/ Being published in 1981, RFC 793 defines several protocol mechanisms tha=
t have become outdated and may not be implemented at all in a modern TCP/IP=
 stack. However, in some cases the corresponding specification in RFC 793 n=
ever got updated or obsoleted and is still formally valid. Appendix A.1 sum=
marizes some of these issues. The TCPM consensus for those cases is to docu=
ment the issues in 793bis, but not to change the TCP standards. The require=
d changes to the TCP standards should be handled by dedicated, narrow-focus=
ed RFCs that would have to reach IETF consensus first. This de-risk strateg=
y ensures that each TCP protocol change can be properly and comprehensively=
 reviewed.=0A=
=0A=
2/ There are some known issues in the standards-track specification of TCP =
that exist but only matter in corner cases. An example is documented in App=
endix A.2. In Internet usage of TCP, these conditions are rarely occurring.=
 Common operating systems include different alternative mitigations, and th=
e standard has not been updated yet to codify one of them. Also, there is n=
o known best approach. Given the lack of practical relevance, the TCPM cons=
ensus is to describe these known problems, but not to change the TCP standa=
rds in 793bis. Again, these problems could be solved by future, dedicated, =
narrow-focused RFC that would have to reach IETF consensus first.=0A=
=0A=
3/ There are known deviations between mandatory-to-implement requirements i=
n the TCP standard and some widely deployed implementations. An example are=
 some details in Section 3.8.3, such as the numerical value in MUST-23. Tho=
se cases typically do not affect interoperability with other implementation=
s. The TCPM working group has discussed whether to change the standard in s=
uch cases (e.g., downgrade MUST-23 to a SHOULD), but finally refrained from=
 going down that road in 793bis, given the huge installed base with a very =
large variety of TCP implementations. Similar like in the previous cases, 7=
93bis may get updated by narrow-focused RFCs.=0A=
=0A=
There is one important exception to the decision not to include new guidanc=
e in 793bis. The exception is Section 3.8.2 "TCP Congestion Control". TCP c=
ongestion control was developed after publication of RFC 793 and the state-=
of-the-art has evolved a lot as compared to RFC 1122. While there are numer=
ous RFCs that specify TCP congestion control, there is no clear normative g=
uidance on the required minimum in all TCP implementations that would be ap=
propriate for 793bis. However, 793bis cannot just stay silent on congestion=
 control. Given the lack of other applicable wording in existing standards,=
 Section 3.8.2 includes new text and is therefore different to the rest of =
the document. Section 3.8.2 was comprehensively reviewed by the TCPM workin=
g group and in particular by TCP implementers. The section is short and str=
aightforward, and the wording was chosen very carefully to reflect existing=
 TCP standards and operational experience in the Internet. Also, given ongo=
ing research, TCP conge=0A=
 stion control will most likely further evolve in future. Section 3.8.2 ena=
bles such a further evolution while defining important base requirements.=
=0A=
=0A=
Running code exists - in billions of TCP/IP stacks. Given the very limited =
scope of modifications in the 793bis document, all TCP implementations that=
 are already compliant to the TCP standards before publication of 793bis sh=
ould be compliant to 793bis as well.=0A=
=0A=
The shepherd believes that the 793bis document has unanimous support from t=
he entire TCPM working group.=0A=
=0A=
=0A=
3. Intellectual Property=0A=
=0A=
The editor has stated that his direct, personal knowledge of any IPR relate=
d to this document has already been disclosed, in conformance with BCPs 78 =
and 79. The editor is not aware of any IPR relevant for the base TCP protoc=
ol. Since 793bis does not change the TCP protocol, relevant IPR would have =
to be disclosed already for the existing RFCs included in 793bis.=0A=
=0A=
There is a Cisco IPR disclosure from year 2004 related to the Internet-Draf=
t that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 59=
61 is one source of changes included in 793bis. In all places in 793bis whe=
re the recommendations from RFC 5961 are mentioned, 5961 is prominently ref=
erenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes descri=
bed in RFC 5961 are optional and not mandatory-to-implement.=0A=
=0A=
It has been suggested that the owner of the IPR disclosed in https://datatr=
acker.ietf.org/ipr/421/ updates the IPR disclosure to make clear whether it=
 applies to 793bis, or not.=0A=
=0A=
The TCPM working group is aware of the IPR disclosure related to RFC 5961, =
which is known already for a long time. The document shepherd has verified =
on the TCPM mailing list that the TCPM working group is fine with the propo=
sed text in 793bis related to RFC 5961. In the TCPM working group there are=
 no known concerns regarding this IPR disclosure related to an optional mec=
hanism.=0A=
=0A=
=0A=
4. Other Points=0A=
=0A=
The intended status listed in the document is "Proposed Standard". As all m=
ain TCP implementations are supposed to comply with 793bis, the document ma=
y fulfill the requirements of an "Internet Standard" according to RFC 2026 =
and RFC 7127.=0A=
=0A=
idnits reports some warnings, such as obsolete references. These are all fa=
lse positives. The document refers to some obsolete documents to provide hi=
storical context.=0A=
=0A=
The IANA Considerations in Section 5 include some editorial clean-up of the=
 TCP entries in the IANA registry. The modifications neither change any all=
ocation nor any policy in the IANA registry. These purely editorial changes=
 have been discussed in the TCPM working group for a long time and there is=
 unanimous consensus in TCPM that this clean-up is useful.=0A=
=0A=
All errata to RFC 793 and related RFCs have been considered in this "bis" d=
ocument.=0A=
=0A=
When Wes started working on a 793bis document in 2013, the document shepher=
d, as well as many other TCPM contributors, were pretty convinced that writ=
ing a 793bis document is an impossible endeavor. Well, after many years, we=
 are proven wrong. Many thanks to Wes as editor!=0A=
=0A=
_______________________________________________=0A=
tcpm mailing list=0A=
tcpm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tcpm=0A=


From nobody Thu Jun 10 09:23:57 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 D54DC3A45AB; Thu, 10 Jun 2021 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoLC0pGGX-J3; Thu, 10 Jun 2021 09:23:50 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBA93A45A9; Thu, 10 Jun 2021 09:23:49 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 4D24025A20; Thu, 10 Jun 2021 18:23:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623342227; bh=rPY7DRBIKbjhHVuXb7BXk+mgLPYxuJOkwRS06Z9qvS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ppKEp3LQOy9dSFmLgWo5H8+dBEH03clbRAH9qMGYcbZpfgGlOuB5Xs0tPDZ7TPLCd kApHuhJyT92DhZNWl7tckgvFnH+dO0ImNS9xwTmJBDh50XWh2v4XyCJ2S4zWEPr3HS MT2Z2gAzTKlD+G9094335iZoL+VIij97lU9JX4ZM=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19KLAG2ZSjCP; Thu, 10 Jun 2021 18:23:45 +0200 (CEST)
Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 10 Jun 2021 18:23:45 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 10 Jun 2021 18:23:45 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 18:23:45 +0200
From: "Scharf, Michael" 
To: tom petch , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAPNXYwAABWk3A=
Date: Thu, 10 Jun 2021 16:23:45 +0000
Message-ID: <430978e6927f4dfe95b9269c3bcd3a21@hs-esslingen.de>
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 16:23:56 -0000

The write-up uses the official "essay" template https://www.ietf.org/chairs=
/document-writeups/ .

I personally prefer that template over the "Q&A" one, and have used the "es=
say" one in the past many times already.

Michael


> -----Original Message-----
> From: tom petch 
> Sent: Thursday, June 10, 2021 6:14 PM
> To: Scharf, Michael ; tcpm@ietf.org
> Cc: tcpm-chairs 
> Subject: Re: Draft schepherd write-up for 793bis
>=20
> From: tcpm  on behalf of Scharf, Michael
> 
> Sent: 10 June 2021 10:02
>=20
> Dear all,
>=20
> As document shepherd, I have started to work on my write-up for 793bis.
> Given that 793bis may one of the most important deliverables of TCPM, I'd
> like to ensure that the write-up correctly describes the TCPM consensus.
> Therefore, I share the text before actually hitting the button.
>=20
> If the write-up listed below is not accurate or misses important details,
> please let me know ASAP (on-list of off-list).
>=20
> I plan to forward 793bis to our AD tomorrow.
>=20
> 
> Michael
>=20
> Lots of good stuff but it does not appear to follow the template, a layou=
t
> which I find  useful when wanting to check on an aspect thereof, such as
> validation by sundry tools, as it saves me having to work my way through =
it.
>=20
> Tom Petch
> p.s. Reviewing 793bis has been on mytodo list for an embarrassing number =
of
> years:-(
>=20
> Thanks
>=20
> Michael
>=20
>=20
> ***
>=20
> 1. Summary
>=20
> The document shepherd is Michael Scharf  esslingen.de>.
>=20
> The responsible Area Director is Martin Duke .
>=20
> This document specifies the Transmission Control Protocol (TCP) as "bis"
> document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs
> that specified additions to RFC 793. It also updates RFC 1122, and it sho=
uld be
> considered as a replacement for the portions of that document dealing wit=
h
> TCP requirements.
>=20
> The purpose of this document is to bring together all the IETF Standards =
Track
> changes that have been made to the base TCP functional specification and
> unify them into an update of RFC 793. The document focuses on the
> common basis all TCP implementations must support to interoperate. With
> one exception, protocol modifications compared to RFC 793 are limited to
> standards-track RFCs or verified erratas, i.e., changes of TCP standards =
that
> already have IETF consensus.
>=20
> RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The
> same applies to 793bis. The TCPM working group requests publication of
> 793bis on Standards Track. If approved, the document should replace RFC 7=
93
> as "STD 7".
>=20
>=20
> 2. Review and Consensus
>=20
> The TCPM working group has worked on this document for more than 6
> years, and many TCPM contributors have reviewed the specification during
> that time. In particular, many TCP implementers have provided detailed
> comments based on operational experience. The document was relatively
> stable in the latest versions. During and after WGLC, several comprehensi=
ve
> reviews flagged some open issues that all got resolved.
>=20
> 793bis improves the specification of TCP but it does not modify the TCP
> protocol. TCP is a complex protocol and even minor wording details in the
> protocol specification can matter. Given the restriction to TCP changes t=
hat
> already have IETF consensus, there has never been any major controversy
> about the main content.
>=20
> Nonetheless, several questions were non-trivial and triggered longer
> discussions in TCPM. These issues can roughly be subdivided in three
> categories:
>=20
> 1/ Being published in 1981, RFC 793 defines several protocol mechanisms t=
hat
> have become outdated and may not be implemented at all in a modern
> TCP/IP stack. However, in some cases the corresponding specification in R=
FC
> 793 never got updated or obsoleted and is still formally valid. Appendix =
A.1
> summarizes some of these issues. The TCPM consensus for those cases is to
> document the issues in 793bis, but not to change the TCP standards. The
> required changes to the TCP standards should be handled by dedicated,
> narrow-focused RFCs that would have to reach IETF consensus first. This d=
e-
> risk strategy ensures that each TCP protocol change can be properly and
> comprehensively reviewed.
>=20
> 2/ There are some known issues in the standards-track specification of TC=
P
> that exist but only matter in corner cases. An example is documented in
> Appendix A.2. In Internet usage of TCP, these conditions are rarely occur=
ring.
> Common operating systems include different alternative mitigations, and t=
he
> standard has not been updated yet to codify one of them. Also, there is n=
o
> known best approach. Given the lack of practical relevance, the TCPM
> consensus is to describe these known problems, but not to change the TCP
> standards in 793bis. Again, these problems could be solved by future,
> dedicated, narrow-focused RFC that would have to reach IETF consensus
> first.
>=20
> 3/ There are known deviations between mandatory-to-implement
> requirements in the TCP standard and some widely deployed
> implementations. An example are some details in Section 3.8.3, such as th=
e
> numerical value in MUST-23. Those cases typically do not affect
> interoperability with other implementations. The TCPM working group has
> discussed whether to change the standard in such cases (e.g., downgrade
> MUST-23 to a SHOULD), but finally refrained from going down that road in
> 793bis, given the huge installed base with a very large variety of TCP
> implementations. Similar like in the previous cases, 793bis may get updat=
ed
> by narrow-focused RFCs.
>=20
> There is one important exception to the decision not to include new
> guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Contro=
l".
> TCP congestion control was developed after publication of RFC 793 and the
> state-of-the-art has evolved a lot as compared to RFC 1122. While there a=
re
> numerous RFCs that specify TCP congestion control, there is no clear
> normative guidance on the required minimum in all TCP implementations
> that would be appropriate for 793bis. However, 793bis cannot just stay si=
lent
> on congestion control. Given the lack of other applicable wording in exis=
ting
> standards, Section 3.8.2 includes new text and is therefore different to =
the
> rest of the document. Section 3.8.2 was comprehensively reviewed by the
> TCPM working group and in particular by TCP implementers. The section is
> short and straightforward, and the wording was chosen very carefully to
> reflect existing TCP standards and operational experience in the Internet=
.
> Also, given ongoing research, TCP conge
>  stion control will most likely further evolve in future. Section 3.8.2 e=
nables
> such a further evolution while defining important base requirements.
>=20
> Running code exists - in billions of TCP/IP stacks. Given the very limite=
d scope
> of modifications in the 793bis document, all TCP implementations that are
> already compliant to the TCP standards before publication of 793bis shoul=
d
> be compliant to 793bis as well.
>=20
> The shepherd believes that the 793bis document has unanimous support
> from the entire TCPM working group.
>=20
>=20
> 3. Intellectual Property
>=20
> The editor has stated that his direct, personal knowledge of any IPR rela=
ted
> to this document has already been disclosed, in conformance with BCPs 78
> and 79. The editor is not aware of any IPR relevant for the base TCP prot=
ocol.
> Since 793bis does not change the TCP protocol, relevant IPR would have to
> be disclosed already for the existing RFCs included in 793bis.
>=20
> There is a Cisco IPR disclosure from year 2004 related to the Internet-Dr=
aft
> that resulted in RFC 5961 (https://datatracker.ietf.org/ipr/421/). RFC 59=
61 is
> one source of changes included in 793bis. In all places in 793bis where t=
he
> recommendations from RFC 5961 are mentioned, 5961 is prominently
> referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes
> described in RFC 5961 are optional and not mandatory-to-implement.
>=20
> It has been suggested that the owner of the IPR disclosed in
> https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure to make
> clear whether it applies to 793bis, or not.
>=20
> The TCPM working group is aware of the IPR disclosure related to RFC 5961=
,
> which is known already for a long time. The document shepherd has verifie=
d
> on the TCPM mailing list that the TCPM working group is fine with the
> proposed text in 793bis related to RFC 5961. In the TCPM working group
> there are no known concerns regarding this IPR disclosure related to an
> optional mechanism.
>=20
>=20
> 4. Other Points
>=20
> The intended status listed in the document is "Proposed Standard". As all
> main TCP implementations are supposed to comply with 793bis, the
> document may fulfill the requirements of an "Internet Standard" according
> to RFC 2026 and RFC 7127.
>=20
> idnits reports some warnings, such as obsolete references. These are all =
false
> positives. The document refers to some obsolete documents to provide
> historical context.
>=20
> The IANA Considerations in Section 5 include some editorial clean-up of t=
he
> TCP entries in the IANA registry. The modifications neither change any
> allocation nor any policy in the IANA registry. These purely editorial ch=
anges
> have been discussed in the TCPM working group for a long time and there i=
s
> unanimous consensus in TCPM that this clean-up is useful.
>=20
> All errata to RFC 793 and related RFCs have been considered in this "bis"
> document.
>=20
> When Wes started working on a 793bis document in 2013, the document
> shepherd, as well as many other TCPM contributors, were pretty convinced
> that writing a 793bis document is an impossible endeavor. Well, after man=
y
> years, we are proven wrong. Many thanks to Wes as editor!
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Jun 10 09:47:16 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 B16DC3A07E2; Thu, 10 Jun 2021 09:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neeRiRtQWGtk; Thu, 10 Jun 2021 09:47:08 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115F73A07BA; Thu, 10 Jun 2021 09:47:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E36F925A22; Thu, 10 Jun 2021 18:47:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623343626; bh=1imB9AnkCyekid8qnN9C3thmeG+/blezCGQs274kXWM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MTX1wDwZOlDHA9Zt9nC5KGZPISBaq2hIC3mCrSHlqh6sENjTuxRWeF3Zhw60IFQgr /FE5C5k+V6pmAgUoJRlTje7fvJcsL6EEJrtizobyiAHp6wvb21R2YDyqZyZVjylvJJ itYvi/T1cqse7S+w+xm97mrYi2eRsVoYpQ8KJED8=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-57lLA8Wadz; Thu, 10 Jun 2021 18:47:04 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 10 Jun 2021 18:47:04 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 10 Jun 2021 18:47:03 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 18:47:03 +0200
From: "Scharf, Michael" 
To: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAMP1VQAAEn3SAAAxek4A==
Date: Thu, 10 Jun 2021 16:47:03 +0000
Message-ID: 
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de> <3560_1623336557_60C2266D_3560_462_1_787AE7BB302AE849A7480A190F8B9330353A7B8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <14061_1623338471_60C22DE7_14061_318_1_787AE7BB302AE849A7480A190F8B9330353A7C4C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <14061_1623338471_60C22DE7_14061_318_1_787AE7BB302AE849A7480A190F8B9330353A7C4C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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, 10 Jun 2021 16:47:14 -0000

Thx. I'll use this wording.

Michael

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> 
> Sent: Thursday, June 10, 2021 5:21 PM
> To: Scharf, Michael ; tcpm@ietf.org
> Cc: tcpm-chairs 
> Subject: RE: Draft schepherd write-up for 793bis
>=20
> Re-,
>=20
> FWIW, here is a proposal for the IANA part of the write-up:
>=20
> OLD:
>=20
> The IANA Considerations in Section 5 include some editorial clean-up of t=
he
> TCP entries in the IANA registry. The modifications neither change any
> allocation nor any policy in the IANA registry. These purely editorial ch=
anges
> have been discussed in the TCPM working group for a long time and there i=
s
> unanimous consensus in TCPM that this clean-up is useful.
>=20
> NEW:
>=20
> The IANA section includes many actions:
> (1) Update the structure of the TCP flags registry to include a new colum=
n
> called "Assignment Notes"
> (2) Rename "Bit" column of the TCP flags registry to "Bit Offset"
> (3) Update the TCP flags registry to include all assigned TCP flags, not =
only
> those initially assigned in RFC 3168. 10-15 values are assigned.
> (4) Move the existing TCP flags registry to be as sub-registry of the TCP
> registry.
>=20
> There was unanimous consensus in TCPM with these changes.
>=20
> Cheers,
> Med
>=20
> > -----Message d'origine-----
> > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de
> > mohamed.boucadair@orange.com
> > Envoy=E9=A0: jeudi 10 juin 2021 16:49
> > =C0=A0: Scharf, Michael ; tcpm@ietf.org
> > Cc=A0: tcpm-chairs 
> > Objet=A0: Re: [tcpm] Draft schepherd write-up for 793bis
> >
> > Hi Michael,
> >
> > One comment about the IANA part, we have agreed to move one existing
> > IANA **registry** to be a **sub-registry** under the existing TCP
> > registry. I would update the IANA part accordingly.
> >
> > Other than that, this looks good. Thanks.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf,
> > Michael
> > > Envoy=E9=A0: jeudi 10 juin 2021 11:03 =C0=A0: tcpm@ietf.org Cc=A0: tc=
pm-
> > chairs
> > >  Objet=A0: [tcpm] Draft schepherd write-up for
> > > 793bis
> > >
> > > Dear all,
> > >
> > > As document shepherd, I have started to work on my write-up for
> > > 793bis. Given that 793bis may one of the most important
> > deliverables
> > > of TCPM, I'd like to ensure that the write-up correctly describes
> > the
> > > TCPM consensus. Therefore, I share the text before actually
> > hitting
> > > the button.
> > >
> > > If the write-up listed below is not accurate or misses important
> > > details, please let me know ASAP (on-list of off-list).
> > >
> > > I plan to forward 793bis to our AD tomorrow.
> > >
> > > Thanks
> > >
> > > Michael
> > >
> > >
> > > ***
> > >
> > > 1. Summary
> > >
> > > The document shepherd is Michael Scharf  > > esslingen.de>.
> > >
> > > The responsible Area Director is Martin Duke
> > > .
> > >
> > > This document specifies the Transmission Control Protocol (TCP) as
> > > "bis" document to RFC 793. It obsoletes RFC 793 as well as a
> > several
> > > other RFCs that specified additions to RFC 793. It also updates
> > RFC
> > > 1122, and it should be considered as a replacement for the
> > portions of
> > > that document dealing with TCP requirements.
> > >
> > > The purpose of this document is to bring together all the IETF
> > > Standards Track changes that have been made to the base TCP
> > functional
> > > specification and unify them into an update of RFC 793.
> > > The document focuses on the common basis all TCP implementations
> > must
> > > support to interoperate. With one exception, protocol
> > modifications
> > > compared to RFC 793 are limited to standards-track RFCs or
> > verified
> > > erratas, i.e., changes of TCP standards that already have IETF
> > > consensus.
> > >
> > > RFC 793 and RFC 1122 are ubiquitously implemented Internet
> > Standards.
> > > The same applies to 793bis. The TCPM working group requests
> > > publication of 793bis on Standards Track. If approved, the
> > document
> > > should replace RFC 793 as "STD 7".
> > >
> > >
> > > 2. Review and Consensus
> > >
> > > The TCPM working group has worked on this document for more than 6
> > > years, and many TCPM contributors have reviewed the specification
> > > during that time. In particular, many TCP implementers have
> > provided
> > > detailed comments based on operational experience. The document
> > was
> > > relatively stable in the latest versions. During and after WGLC,
> > > several comprehensive reviews flagged some open issues that all
> > got
> > > resolved.
> > >
> > > 793bis improves the specification of TCP but it does not modify
> > the
> > > TCP protocol. TCP is a complex protocol and even minor wording
> > details
> > > in the protocol specification can matter. Given the restriction to
> > TCP
> > > changes that already have IETF consensus, there has never been any
> > > major controversy about the main content.
> > >
> > > Nonetheless, several questions were non-trivial and triggered
> > longer
> > > discussions in TCPM. These issues can roughly be subdivided in
> > three
> > > categories:
> > >
> > > 1/ Being published in 1981, RFC 793 defines several protocol
> > > mechanisms that have become outdated and may not be implemented
> at
> > all
> > > in a modern TCP/IP stack. However, in some cases the corresponding
> > > specification in RFC 793 never got updated or obsoleted and is
> > still
> > > formally valid. Appendix A.1 summarizes some of these issues. The
> > TCPM
> > > consensus for those cases is to document the issues in 793bis, but
> > not
> > > to change the TCP standards. The required changes to the TCP
> > standards
> > > should be handled by dedicated, narrow-focused RFCs that would
> > have to
> > > reach IETF consensus first. This de-risk strategy ensures that
> > each
> > > TCP protocol change can be properly and comprehensively reviewed.
> > >
> > > 2/ There are some known issues in the standards-track
> > specification of
> > > TCP that exist but only matter in corner cases. An example is
> > > documented in Appendix A.2. In Internet usage of TCP, these
> > conditions
> > > are rarely occurring. Common operating systems include different
> > > alternative mitigations, and the standard has not been updated yet
> > to
> > > codify one of them. Also, there is no known best approach. Given
> > the
> > > lack of practical relevance, the TCPM consensus is to describe
> > these
> > > known problems, but not to change the TCP standards in 793bis.
> > Again,
> > > these problems could be solved by future, dedicated, narrow-
> > focused
> > > RFC that would have to reach IETF consensus first.
> > >
> > > 3/ There are known deviations between mandatory-to-implement
> > > requirements in the TCP standard and some widely deployed
> > > implementations. An example are some details in Section 3.8.3,
> > such as
> > > the numerical value in MUST-23. Those cases typically do not
> > affect
> > > interoperability with other implementations. The TCPM working
> > group
> > > has discussed whether to change the standard in such cases (e.g.,
> > > downgrade MUST-23 to a SHOULD), but finally refrained from going
> > down
> > > that road in 793bis, given the huge installed base with a very
> > large
> > > variety of TCP implementations. Similar like in the previous
> > cases,
> > > 793bis may get updated by narrow-focused RFCs.
> > >
> > > There is one important exception to the decision not to include
> > new
> > > guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion
> > > Control". TCP congestion control was developed after publication
> > of
> > > RFC 793 and the state-of-the-art has evolved a lot as compared to
> > RFC
> > > 1122. While there are numerous RFCs that specify TCP congestion
> > > control, there is no clear normative guidance on the required
> > minimum
> > > in all TCP implementations that would be appropriate for 793bis.
> > > However, 793bis cannot just stay silent on congestion control.
> > Given
> > > the lack of other applicable wording in existing standards,
> > Section
> > > 3.8.2 includes new text and is therefore different to the rest of
> > the
> > > document. Section 3.8.2 was comprehensively reviewed by the TCPM
> > > working group and in particular by TCP implementers. The section
> > is
> > > short and straightforward, and the wording was chosen very
> > carefully
> > > to reflect existing TCP standards and operational experience in
> > the
> > > Internet. Also, given ongoing research, TCP conge  stion control
> > will
> > > most likely further evolve in future. Section 3.8.2 enables such a
> > > further evolution while defining important base requirements.
> > >
> > > Running code exists - in billions of TCP/IP stacks. Given the very
> > > limited scope of modifications in the 793bis document, all TCP
> > > implementations that are already compliant to the TCP standards
> > before
> > > publication of 793bis should be compliant to 793bis as well.
> > >
> > > The shepherd believes that the 793bis document has unanimous
> > support
> > > from the entire TCPM working group.
> > >
> > >
> > > 3. Intellectual Property
> > >
> > > The editor has stated that his direct, personal knowledge of any
> > IPR
> > > related to this document has already been disclosed, in
> > conformance
> > > with BCPs 78 and 79. The editor is not aware of any IPR relevant
> > for
> > > the base TCP protocol. Since 793bis does not change the TCP
> > protocol,
> > > relevant IPR would have to be disclosed already for the existing
> > RFCs
> > > included in 793bis.
> > >
> > > There is a Cisco IPR disclosure from year 2004 related to the
> > > Internet-Draft that resulted in RFC 5961
> > > (https://datatracker.ietf.org/ipr/421/). RFC 5961 is one source of
> > > changes included in 793bis. In all places in 793bis where the
> > > recommendations from RFC 5961 are mentioned, 5961 is prominently
> > > referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the
> > > changes described in RFC 5961 are optional and not mandatory-to-
> > > implement.
> > >
> > > It has been suggested that the owner of the IPR disclosed in
> > > https://datatracker.ietf.org/ipr/421/ updates the IPR disclosure
> > to
> > > make clear whether it applies to 793bis, or not.
> > >
> > > The TCPM working group is aware of the IPR disclosure related to
> > RFC
> > > 5961, which is known already for a long time. The document
> > shepherd
> > > has verified on the TCPM mailing list that the TCPM working group
> > is
> > > fine with the proposed text in 793bis related to RFC 5961. In the
> > TCPM
> > > working group there are no known concerns regarding this IPR
> > > disclosure related to an optional mechanism.
> > >
> > >
> > > 4. Other Points
> > >
> > > The intended status listed in the document is "Proposed Standard".
> > > As all main TCP implementations are supposed to comply with
> > 793bis,
> > > the document may fulfill the requirements of an "Internet
> > Standard"
> > > according to RFC 2026 and RFC 7127.
> > >
> > > idnits reports some warnings, such as obsolete references. These
> > are
> > > all false positives. The document refers to some obsolete
> > documents to
> > > provide historical context.
> > >
> > > The IANA Considerations in Section 5 include some editorial clean-
> > up
> > > of the TCP entries in the IANA registry. The modifications neither
> > > change any allocation nor any policy in the IANA registry. These
> > > purely editorial changes have been discussed in the TCPM working
> > group
> > > for a long time and there is unanimous consensus in TCPM that this
> > > clean-up is useful.
> > >
> > > All errata to RFC 793 and related RFCs have been considered in
> > this
> > > "bis" document.
> > >
> > > When Wes started working on a 793bis document in 2013, the
> > document
> > > shepherd, as well as many other TCPM contributors, were pretty
> > > convinced that writing a 793bis document is an impossible
> > endeavor.
> > > Well, after many years, we are proven wrong. Many thanks to Wes as
> > > editor!
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
> __________________________________________________________
> __________
> > _____________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre
> > diffuses, exploites ou copies sans autorisation. Si vous avez recu
> > ce message par erreur, veuillez le signaler a l'expediteur et le
> > detruire ainsi que les pieces jointes. Les messages electroniques
> > etant susceptibles d'alteration, Orange decline toute responsabilite
> > si ce message a ete altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender
> > and delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that
> > have been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>=20
> __________________________________________________________
> __________________________________________________________
> _____
>=20
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u
> falsifie. Merci.
>=20
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n
> modified, changed or falsified.
> Thank you.


From nobody Thu Jun 10 18:51: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 D201D3A2329; Thu, 10 Jun 2021 18:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.794
X-Spam-Level: 
X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 5ipK-pYucdkh; Thu, 10 Jun 2021 18:51:35 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 891AA3A232B; Thu, 10 Jun 2021 18:51:35 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15B1m7E8021468; Thu, 10 Jun 2021 18:51:34 -0700
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=TpUCUVHjVxi34+XB5OmKAz/PGLVoZAmvqUDI1wvTbAk=; b=ALlcEsXRTTMuw56YcIKOarrKGQoJP6PQQN5vMXXgEM56Q+/kTqwNYYhme5aGT+6XbbxW /SduuyagH2uI5GLfoXJnPd0QbXeme5DrOs5KjPUHO2Ay9bfhIMYCX/4LAqm999YlfL8W mP5ibepoiWJqlaziqXQwE29X7pBDi6thXp/idCBZsyj+NrO9CUEnSjAmQstCN1/x6/Yw a8RmVqCv+GP5x7qQ0vq9LYEkSyI3G80+t8atLlEmgYpENE5OmQiE9KZuMmue4WNup+A+ Jg4lKzfkcx1BqRBAx5BKoZxlExXOwLHgKIEDjZpyPsWwAfXghcSPun75kbE3M2vS6Ksl Sg== 
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 393h32drws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Jun 2021 18:51:34 -0700
Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUI00P1UL5XI750@rn-mailsvcp-mta-lapp01.rno.apple.com>;  Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
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.9.20210415 64bit (built Apr 15 2021)) id <0QUI00J00KVYWV00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
X-Va-A: 
X-Va-T-CD: 27026555779e17329268b9b32e8b8690
X-Va-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-Va-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-Va-CD: 0
X-Va-ID: a87d6de0-10a9-4121-ab14-03c4131dab99
X-V-A: 
X-V-T-CD: 27026555779e17329268b9b32e8b8690
X-V-E-CD: 2e6d0a645fe3cddf8de77c8cd0c1fb6b
X-V-R-CD: 3d9c06b14119c365e7637b357762e6ee
X-V-CD: 0
X-V-ID: 66d98c57-1a27-4825-ae01-61cd197a0adf
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-10_14:2021-06-10, 2021-06-10 signatures=0
Received: from smtpclient.apple (unknown [17.11.81.219]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUI003J5L5XNW00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 10 Jun 2021 18:51:33 -0700 (PDT)
From: Vidhi Goel 
Message-id: <87F5FEC9-87CC-4B94-AF63-011CD3C6AEB1@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_2DED57FF-8B66-4DD1-BFE8-0CDFE13CDD1F"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Thu, 10 Jun 2021 18:51:33 -0700
In-reply-to: 
Cc: "tcpm@ietf.org Extensions" , Yoshifumi Nishida , draft-ietf-tcpm-rfc8312bis@ietf.org
To: Vidhi Goel 
References:    <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org> 
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-10_14:2021-06-10, 2021-06-10 signatures=0
Archived-At: 
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
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, 11 Jun 2021 01:51:40 -0000

--Apple-Mail=_2DED57FF-8B66-4DD1-BFE8-0CDFE13CDD1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello folks,

As we are in the WGLC for rfc8312bis, I would really appreciate your =
feedback on this issue (https://github.com/NTAP/rfc8312bis/issues/64 =
). Please let us know =
latest by Jun 15th if you have any input/thoughts on it. After that, the =
issue will be closed with no action.

Thanks,
Vidhi

> On Jun 8, 2021, at 12:27 AM, Vidhi Goel =
 wrote:
>=20
> Hello Yoshi and folks,
>=20
> As we are addressing the below issues raised by Yoshi, for one of the =
issues (https://github.com/NTAP/rfc8312bis/issues/64 =
), it would be great if =
you could take a look and provide opinion about whether using alpha_aimd =
as a variable and then assigning a constant value to it for Cubic in the =
draft is confusing or not.
>=20
> And, of course, you are welcome to look at other issues and provide =
your input.
>=20
> Thanks,
> Vidhi
>=20
>> On Jun 1, 2021, at 2:18 AM, Lars Eggert > wrote:
>>=20
>> Hi,
>>=20
>> many thanks for the review!
>>=20
>> On 2021-6-1, at 11:35, Yoshifumi Nishida > wrote:
>>> 1: While this draft focuses on only TCP,  CUBIC can actually be =
applied to other transport protocols
>>>    such as QUIC, SCTP. Do we want to mention it in the draft or is =
it out of scope?
>>=20
>> I've opened https://github.com/NTAP/rfc8312bis/issues/61 =
 for this.
>>=20
>> Note that we did discuss CUBIC for QUIC in =
https://github.com/NTAP/rfc8312bis/issues/45 =
.
>>=20
>>> 2: Section 3.1 "After a window reduction in response to a congestion =
event is
>>>     detected by duplicate ACKs or Explicit Congestion =
Notification-Echo
>>>     (ECN-Echo, ECE) ACKs [
>>> RFC3168], CUBIC remembers the congestion window..."
>>>=20
>>>   I think the events detected by RACK (or PTO for QUIC) can also be =
included here.
>>=20
>> I opened https://github.com/NTAP/rfc8312bis/issues/62 =

>>=20
>>> 3: Section 4.1.1
>>>    It seems that the text version of the draft uses b_cubic and =
a_aimd, while the pdf version of the
>>>    draft uses different names. But, I prefer to use the same names =
in both versions to avoid confusion.
>>=20
>> The PDF is actually corrupt, due to a Unicode bug in the datatracker =
PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46 =
.
>>=20
>>> 4: Section 4.2  I personally prefer to refer the equations in the =
draft as 'Equation' rather than 'Figure'  if there's
>>>    no strong reason for it.
>>=20
>> With kramdown-xml2rfc2629, it's unfortunately not possible to change =
this. We would need to add an RFC Editor Note instructing them to =
manually make the change. Opened =
https://github.com/NTAP/rfc8312bis/issues/63 =

>>=20
>>> 5: Section 4.3  It seems to me that there are two meanings for =
a_aimd in this section.
>>>    One is the additive factor for CUBIC and the other is a generic =
parameter for AIMD() function.
>>>    This looks a bit confusing to me.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/64 =

>>=20
>>> 6: Section 4.3  The description for P is required for Figure 3.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/65 =

>>=20
>>> 7: Section 4.3  I think The analysis in [FHP00] doesn't include =
delayed ACK factor. So, the AIMD TCP model here
>>>   can be a bit aggressive compared to a TCP that doesn't enable ABC =
and uses delayed ACK.
>>>  This is fine, but I think it might be good to clarify it.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/66 =

>>=20
>>> 8: Section 4.3  I am not very sure why segments_acked is used rather =
than byted_acked here. What is the benefit of it?
>>>    How do we calculate when the acks are split?
>>>   Also, I think it should be clarified that cwnd is expressed in =
segments here in this case.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/67 =

>>=20
>>> 9: Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, =
_W_est_ >=3D _W_max_, ..."
>>>   I might miss something, but I'm not sure why  a_aimd can be set to =
1 to be compatible with AIMD TCP.
>>>   Does this mean b_cubic is also updated? If not, why this can be =
compatible?
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/68 =

>>=20
>>> 10: Section 4.5: " The convex profile ensure that the window =
increases very slowly at the beginning.."
>>>   I am wondering how much this part is accurate. Because of =
Principal 2,  even though cwnd is increased
>>>   through convex profile, I think it will be overridden by linear =
growth by AIMD.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/69 =

>>=20
>>> 11: Section 4.7: "we update w_max as follows, before the window =
reduction as described in section 4.6"
>>>   I am wondering if reducing w_max is the right approach here. =
Because if we reduce w_max, CUBIC
>>>   can exit from convex region earlier than the case where fast =
convergence is not used.
>>>   It seems to me that keeping w_max and reducing only cwnd (using =
smaller value than b_cubic)
>>>   look more conservative.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/70 =

>>=20
>>> 12: Section 5.2 and Section 5.3. Do these results are based on the =
algorithms and the parameter values
>>>   described in the draft?  If there're differences, I think it =
should be described.
>>=20
>> Opened https://github.com/NTAP/rfc8312bis/issues/71 =

>>=20
>> Thanks,
>> Lars
>>=20
>>=20
>> _______________________________________________
>> 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=_2DED57FF-8B66-4DD1-BFE8-0CDFE13CDD1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hello=
 folks,

As we are in =
the WGLC for rfc8312bis, I would really appreciate your feedback on this =
issue (https://github.com/NTAP/rfc8312bis/issues/64). Please let =
us know latest by Jun 15th if you have any input/thoughts on it. After =
that, the issue will be closed with no action.

Thanks,
Vidhi

On Jun 8, 2021, at 12:27 AM, =
Vidhi Goel <vidhi_goel=3D40apple.com@dmarc.ietf.org> =
wrote:

Hello Yoshi and =
folks,

As we are =
addressing the below issues raised by Yoshi, for one of the issues (https://github.com/NTAP/rfc8312bis/issues/64), it would =
be great if you could take a look and provide opinion about whether =
using alpha_aimd as a variable and then assigning a constant value to it =
for Cubic in the draft is confusing or not.

And, of course, you are welcome to look =
at other issues and provide your input.

Thanks,
Vidhi

On Jun 1, 2021, at 2:18 AM, Lars Eggert =
<lars@eggert.org> =
wrote:

Hi,

many thanks for the =
review!

On 2021-6-1, at 11:35, Yoshifumi =
Nishida <nsd.ietf@gmail.com> wrote:
1: While this draft focuses on only TCP, =
 CUBIC can actually be applied to other transport protocols
    such as QUIC, SCTP. Do we want to mention =
it in the draft or is it out of scope?

I've opened https://github.com/NTAP/rfc8312bis/issues/61 for this.

Note that we did discuss CUBIC for QUIC in https://github.com/NTAP/rfc8312bis/issues/45.

2: =
Section 3.1 "After a window reduction in response to a congestion event =
is
     detected by duplicate ACKs or =
Explicit Congestion Notification-Echo
 =
    (ECN-Echo, ECE) ACKs [
RFC3168], =
CUBIC remembers the congestion window..."

 =
  I think the events detected by RACK (or PTO for QUIC) can =
also be included here.

I =
opened https://github.com/NTAP/rfc8312bis/issues/62

3: =
Section 4.1.1
    It seems that the text =
version of the draft uses b_cubic and a_aimd, while the pdf version of =
the
    draft uses different names. But, I =
prefer to use the same names in both versions to avoid confusion.

The PDF is actually corrupt, due =
to a Unicode bug in the datatracker PDF generation. See https://github.com/NTAP/rfc8312bis/issues/46.

4: =
Section 4.2  I personally prefer to refer the equations in the =
draft as 'Equation' rather than 'Figure'  if there's
 =
   no strong reason for it.

With kramdown-xml2rfc2629, it's unfortunately not possible to =
change this. We would need to add an RFC Editor Note instructing them to =
manually make the change. Opened https://github.com/NTAP/rfc8312bis/issues/63

5: =
Section 4.3  It seems to me that there are two meanings for a_aimd =
in this section.
    One is the additive =
factor for CUBIC and the other is a generic parameter for AIMD() =
function.
    This looks a bit confusing to =
me.

Opened https://github.com/NTAP/rfc8312bis/issues/64

6: =
Section 4.3  The description for P is required for Figure 3.

Opened https://github.com/NTAP/rfc8312bis/issues/65

7: =
Section 4.3  I think The analysis in [FHP00] doesn't include =
delayed ACK factor. So, the AIMD TCP model here
 =
  can be a bit aggressive compared to a TCP that doesn't =
enable ABC and uses delayed ACK.
  This is fine, but =
I think it might be good to clarify it.

Opened https://github.com/NTAP/rfc8312bis/issues/66

8: =
Section 4.3  I am not very sure why segments_acked is used rather =
than byted_acked here. What is the benefit of it?
 =
   How do we calculate when the acks are split?
   Also, I think it should be clarified that cwnd =
is expressed in segments here in this case.
Opened https://github.com/NTAP/rfc8312bis/issues/67

9: =
Section 4.3  "Note that once _W_est_ reaches _W_max_, that is, =
_W_est_ >=3D _W_max_, ..."
   I might miss =
something, but I'm not sure why  a_aimd can be set to 1 to be =
compatible with AIMD TCP.
   Does this mean =
b_cubic is also updated? If not, why this can be compatible?

Opened https://github.com/NTAP/rfc8312bis/issues/68

10: =
Section 4.5: " The convex profile ensure that the window increases very =
slowly at the beginning.."
   I am wondering how =
much this part is accurate. Because of Principal 2,  even though =
cwnd is increased
   through convex profile, I =
think it will be overridden by linear growth by AIMD.

Opened https://github.com/NTAP/rfc8312bis/issues/69

11: =
Section 4.7: "we update w_max as follows, before the window reduction as =
described in section 4.6"
   I am wondering if =
reducing w_max is the right approach here. Because if we reduce w_max, =
CUBIC
   can exit from convex region earlier =
than the case where fast convergence is not used.
 =
  It seems to me that keeping w_max and reducing only cwnd =
(using smaller value than b_cubic)
   look more =
conservative.

Opened https://github.com/NTAP/rfc8312bis/issues/70

12: =
Section 5.2 and Section 5.3. Do these results are based on the =
algorithms and the parameter values
   described =
in the draft?  If there're differences, I think it should be =
described.

Opened https://github.com/NTAP/rfc8312bis/issues/71

Thanks,
Lars


_______________________________________________
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=_2DED57FF-8B66-4DD1-BFE8-0CDFE13CDD1F--


From nobody Fri Jun 11 05:40:14 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 860F33A362C; Fri, 11 Jun 2021 05:40:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Michael Scharf via Datatracker 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.31.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: Michael Scharf , iesg-secretary@ietf.org,  michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org
Message-ID: <162341521252.24812.958260678020063190@ietfa.amsl.com>
Date: Fri, 11 Jun 2021 05:40:12 -0700
Archived-At: 
Subject: [tcpm] Publication has been requested for draft-ietf-tcpm-rfc793bis-23
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: Fri, 11 Jun 2021 12:40:13 -0000

Michael Scharf has requested publication of draft-ietf-tcpm-rfc793bis-23 as Internet Standard on behalf of the TCPM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/



From nobody Fri Jun 11 05:41: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 C72933A3633 for ; Fri, 11 Jun 2021 05:41:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.31.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <162341528980.30656.2954314928832117601@ietfa.amsl.com>
Date: Fri, 11 Jun 2021 05:41:29 -0700
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: Fri, 11 Jun 2021 12:41:30 -0000

Changed milestone "Submit RFC793bis document to the IESG for publication as
Internet Standard", resolved as "Done".

URL: https://datatracker.ietf.org/wg/tcpm/about/


From nobody Fri Jun 11 05:54:10 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 C90DC3A369C for ; Fri, 11 Jun 2021 05:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgndZHC5ftwb for ; Fri, 11 Jun 2021 05:54:03 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96713A3698 for ; Fri, 11 Jun 2021 05:54:03 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 6670A25A23 for ; Fri, 11 Jun 2021 14:54:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623416041; bh=wFdU4mu2clVsXe2Ei+HlgYxvkoTo5gU25uQGipTaFVs=; h=From:To:Subject:Date:References:In-Reply-To:From; b=oSvCTJhoVp0fXx6ya/TBz4jKd4ppDC2oKdI2llZ9ExYQZqkg0DPgIJyzITb9Lb7de niJsCwHVQSDElyLBlGJHd4qHIBtfhuhW2fGsgyX24qSfBkpHsXshn6Jb4ovmX1+ShZ R1SSxRDr2QbTFqWAKWfSBOoXP2VotaP7FVs5F1DA=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxW5GgeymzOy for ; Fri, 11 Jun 2021 14:54:00 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS for ; Fri, 11 Jun 2021 14:54:00 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 11 Jun 2021 14:54:00 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Fri, 11 Jun 2021 14:54:00 +0200
From: "Scharf, Michael" 
To: "tcpm@ietf.org" 
Thread-Topic: Publication has been requested for draft-ietf-tcpm-rfc793bis-23
Thread-Index: AQHXXr7t2IPi8NVY9EimK0V1be7hCqsOwM0w
Date: Fri, 11 Jun 2021 12:54:00 +0000
Message-ID: 
References: <162341521252.24812.958260678020063190@ietfa.amsl.com>
In-Reply-To: <162341521252.24812.958260678020063190@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [tcpm] FW: Publication has been requested for draft-ietf-tcpm-rfc793bis-23
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, 11 Jun 2021 12:54:09 -0000

Dear all,

After many years of work and discussion, I have finally requested publicati=
on of 793bis.=20

I'd like to say many thanks to Wes as editor and to all other TCPM contribu=
tors who have assisted in completing this important milestone in TCPM.

Thanks for all the excellent work!

Michael
(TCPM co-chair)


-----Original Message-----
From: Michael Scharf via Datatracker =20
Sent: Friday, June 11, 2021 2:40 PM
To: martin.h.duke@gmail.com
Cc: Scharf, Michael ; iesg-secretary@ietf.o=
rg; Scharf, Michael ; tcpm-chairs@ietf.org;=
 tcpm@ietf.org
Subject: Publication has been requested for draft-ietf-tcpm-rfc793bis-23

Michael Scharf has requested publication of draft-ietf-tcpm-rfc793bis-23 as=
 Internet Standard on behalf of the TCPM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draf=
t-ietf-tcpm-rfc793bis/



From nobody Sun Jun 13 10:24:09 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 400903A2200; Sun, 13 Jun 2021 10:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=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 Lu8XgRahL5BH; Sun, 13 Jun 2021 10:24:03 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 8D5B13A21FF; Sun, 13 Jun 2021 10:24:02 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id bn21so16814359ljb.1; Sun, 13 Jun 2021 10:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nZ7GhZOKU481ntWfnmeASI+wTntWuT3jl4aLgue2RUM=; b=RUbI2x0noA04tRMhlYYOQmfwGe8Lv49lIOP69OGsAziNUJcsrSSW3hBWA0r1LQTwzc l0T7jLiJDgN1NJIuShoeWgkGAk8ielBesepDDJSIJK0iI3glSBGf7ehXMZ/LWOtSOl3R HIUIpOwCboZEz95IETsCBPQ4ihA9diH4z96q6Dt1EvlndrAlHDJTZQYz2fSJ4Z+xNPt2 fTlTfc133PIWSUdtYXENaSHg1FSjlBoWCzbcacK9rJ994brNEQAhB4EQEMH/49lUaHz5 fGyWiWqDjET8HmAGZqa+btZYneJyCNfLz1CbjYtF7hxD6zZD6vb37SlnGQBbdKMPiYGL K5wA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nZ7GhZOKU481ntWfnmeASI+wTntWuT3jl4aLgue2RUM=; b=TSOY/pduqVDoQWOBivITBX9GvDL//NAfIbkKCKiL/hqg718193jJ3p7AIEQR21CFwW zP3U2FMog62q0BVtlhQQ0APYFriAWmxYgicDrSuNWwT2C3jBPKjGNSBVB+P+Vo1EWfSr jkRZ+e8wSD2G7VdiYeau8+LDWxK8YO5hPjVZgiNWYunKh5n20K3dOpkj41/hLNLvavvs ie1F3OA8BZfEizqOI/JTYGO8S+9GG/UU+64KUHOPVPKVZLukCO3puFLX0+y8P5bIOekA WTDtH9KNlTi2qxVMYmaBCHQh7PP9eawLlrwDAXIJ5b2NF2Gdwlr0vlcK+HdazeiIpnra Rxww==
X-Gm-Message-State: AOAM532gdoh0UZgFXdqvMKzlR7Hu8xO4dUmZscD7EqQwxPqLMZFs+V8L ou6tHd21eFms77Cu/H9p8Mo=
X-Google-Smtp-Source: ABdhPJzvxwuUy6cRLaNH5MMlI8wvrGQSnpBtx7ec0IiN1Z/vnf276x3fdzjYNFcp+a0GiFeENiJmUQ==
X-Received: by 2002:a2e:b891:: with SMTP id r17mr11173841ljp.134.1623605039884;  Sun, 13 Jun 2021 10:23:59 -0700 (PDT)
Received: from jonathartonsmbp.lan (178-55-194-130.bb.dnainternet.fi. [178.55.194.130]) by smtp.gmail.com with ESMTPSA id p11sm1234155lfr.91.2021.06.13.10.23.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jun 2021 10:23:59 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton 
In-Reply-To: <87F5FEC9-87CC-4B94-AF63-011CD3C6AEB1@apple.com>
Date: Sun, 13 Jun 2021 20:23:57 +0300
Cc: "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rfc8312bis@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <22912B93-506A-4218-86B6-559394B75DD9@gmail.com>
References:    <8DEC1E1C-B8DD-4199-AA49-F6AB7EC7C35E@eggert.org>  <87F5FEC9-87CC-4B94-AF63-011CD3C6AEB1@apple.com>
To: Vidhi Goel 
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: 
Subject: Re: [tcpm] Comments for draft-ietf-tcpm-rfc8312bis-02
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: Sun, 13 Jun 2021 17:24:07 -0000

> On 11 Jun, 2021, at 4:51 am, Vidhi Goel =
 wrote:
>=20
> As we are in the WGLC for rfc8312bis, I would really appreciate your =
feedback on this issue (https://github.com/NTAP/rfc8312bis/issues/64). =
Please let us know latest by Jun 15th if you have any input/thoughts on =
it. After that, the issue will be closed with no action.

I left a comment on the Github issue, suggesting a possible way to =
clarify the section at issue.  Currently the use of the various alpha =
and beta symbols is a bit convoluted and could cause confusion; though a =
careful reading does reveal the correct interpretation, this may be =
difficult for some readers and could result in inadvertent mistakes.

The essence of what I suggest is:

1: Where alpha and beta are used as parameters to a formula, write them =
without suffixes in the formula's definition, particularly =
AVG_AIMD(alpha,beta).

2: Use the "aimd" suffix to refer solely to the alpha and beta =
parameters from Reno.

3: Consistently use the "cubic" suffix for the alpha and beta parameters =
of CUBIC.

4: Explain the calculation of alpha_cubic in terms of equalising the =
values of AVG_AIMD(alpha_aimd, beta_aimd) and AVG_AIMD(alpha_cubic, =
beta_cubic).

I believe the above approach to will improve clarity noticeably without =
increasing the number of symbols in play.  I will leave the fine details =
of wording and formatting to the authors and editors.

 - Jonathan Morton=


From nobody Thu Jun 24 13:12:28 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 3AC873A29B0; Thu, 24 Jun 2021 13:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 zkwW-C3cDHdI; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 75D0F3A29AC; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id h2so9805865iob.11; Thu, 24 Jun 2021 13:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=JuyglivXDBdPy9XKqTc4rCF+wknMzxB79nypTTXLKgA=; b=fPEx2FYwk5BQLKn0HT95LJy3QOlxpShkaXLuLrPv5Wqi3JbD0GcQQ6hC0ifyjaw6DG jEbXkrgQ3n+X4+3IdXEKdOhtekV4HttK+6wbz7bMPFn6xTKEgu9Iw3V8/S8f0hRH7Mzf ZWJhdi7rcuw49UDTdkzUiAflsgWl0Sy/bmglHerg0hRnoxACfNNXcAZR6DRyb0wM/V+w RQYZpxo6qbGVjDHLzJerha5KAfDCICZqX2tvjzm16y0a2ensR/AIqJ/EloE/Y+epMviV 3WSI9ydJIqiMZZKjViJi8MpUlP5AKSF/JOWmmbZ9daJ3HKZHe/j/7Nz/vbLTTaxNO/e7 5WqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JuyglivXDBdPy9XKqTc4rCF+wknMzxB79nypTTXLKgA=; b=DbNzJD06F2uXAWtWxhEGhTaRwe+fvAoKncBOIu6b+wvzhUkF6RJxzYt94uaW9aAmwc feG8vZ+dPguN60tyjIXi5NhiSXpvvM6xIb0giMsOueMh2+ekTiGkqbT9ydvOUCIooHOp sJSNkKXkkIbOV584e+2ymPPX74Ce2ZfAZnYM3Sg5Z28sg+CNT0RTYDw1dOYLvDMmfYp6 xTeJvlXC/9QFSh2wIRzrE28z/W8E0SiC9rTLfr7LTA08YwX7phsMOjicBWkw2nU9EVNv KlOv4DstqxkKXeFkT1N/LBqsxTeA5RpK9XTArOM4cdgiX6TpYSN5cijS5vqOTGg16dRD LZ+A==
X-Gm-Message-State: AOAM533MvYSI4l51waqxKekFygh3CqASwv3WU63QKP/3/wbkyU6oV7sP wi6N38CPTWwVKQOD/S0r8lP1KzUoHOCDpWUS1ho6DzY2SbI=
X-Google-Smtp-Source: ABdhPJx5BVmDKu7PXDfvblACqUk7wG7HxoqiGUtxpLEOgxYlfl3QDeLFSe5RKOFMS6W9tQ8tTQo3ozRKElz9ZlT2yTw=
X-Received: by 2002:a05:6602:2595:: with SMTP id p21mr5575386ioo.51.1624565540859;  Thu, 24 Jun 2021 13:12:20 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke 
Date: Thu, 24 Jun 2021 13:12:09 -0700
Message-ID: 
To: draft-ietf-tcpm-rfc793bis.all@ietf.org,  "tcpm@ietf.org Extensions" 
Content-Type: multipart/alternative; boundary="000000000000fa32df05c588a341"
Archived-At: 
Subject: [tcpm] RFC793bis AD review
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, 24 Jun 2021 20:12:27 -0000

--000000000000fa32df05c588a341
Content-Type: text/plain; charset="UTF-8"

First of all -- wow. Thanks for your efforts on this historic document.

After a detailed reading, I have a number of minor comments that should be
addressed before IETF Last Call, and a bunch of nits.

As always, these AD review comments should be viewed as the start of
discussion rather than a series of demands. If I'm off base, please say so!

*COMMENTS:*

(Document Header) Please update the Intended Status to "Internet Standard".

(3.8.3) R1 and R2 can be measured in retransmissions or seconds; the
proposed bounds are in retransmissions for R1 and seconds for R2. So if I
have a time-based R1, should that be 3? If I have a retransmission based
R2, should I compare that to the value of RTO somehow?

(3.8.5)  This section is unclear as to whether the sender can cause the
Urgent Pointer to recede (move to the left), and if so, if that MUST be
reported to the application like a pointer advance.

(3.8.6.1)

The sending TCP peer must be prepared to accept from the user and
   send at least one octet of new data even if the send window is zero.
   The sending TCP peer must regularly retransmit to the receiving TCP
   peer even when the window is zero

Please clarify that these probes only happen when there is new data, if
that's the intent.

(3.8.6.1) the first paragraph says

Two minutes is recommended for the retransmission interval when the
   window is zero.

but the last one says

The transmitting host SHOULD send the first zero-window probe when a
   zero window has existed for the retransmission timeout period (SHLD-
   29) (Section 3.8.1
),
and SHOULD increase exponentially the interval
   between successive probes (SHLD-30).

so is it 2 min or the RTO?

(3.8.6.2.1) If I read this algorithm correctly, an un-pushed send
buffer of < MSS, if D < Fs*Max(SND.WND), will sit there indefinitely
without
being transmitted; is this intentional?

(3.8.2) and (3.8.6.3) Should RFC 5681 be a normative reference, given the
congestion control requirement? If not, (3.8.6.3) shouldn't require the
reader to go there to fully implement delayed ACKs. I suggest

s/an ACK for at least every second segment/an ACK for least every 2*MSS
bytes of data

to fully state what is in 5681.

(3.10) I understand the desire to conform to RFC 793 formatting, but this
section is very long and has quite a bit of hierarchy. Some subsections
would be very helpful for some needed cross-referencing, as described in
the nits.

(3.10, OPEN/LISTEN)

If active and the remote socket is specified, then change the
         connection from passive to active,

I think you mean "If passive"?

(3.10, SEGMENT ARRIVES/LISTEN) Step 4 mentions RST but those have already
been handled in Step 1.


*NITS:*

(3.1, data offset section) s/integral number/integer multiple

(3.1, URG and ACK) s/field significant/field is significant

(3.1, Window) It would be useful to observe here that RFC 7323 can change
the meaning of this field.

(3.1, Options) "

   Options: [TCP Option]; Options#Size == (DOffset-5)*32; present only
   when DOffset > 5.

What is this notation?

(3.4)  s/l0/10 (switch letter L with numeral 1)

(3.7.2) In the first paragraph it says

RFC 1122  recommends an
IP-layer default
   effective MTU of less than or equal to 576 for destinations not
   directly connected

In the last it says

RFC 1191  discusses
this implication of many older TCP
   implementations setting MSS to 536 for non-local destinations, rather
   than deriving it from the MTUs of connected interfaces as
   recommended.

Could we unify these comments in the same location? Implementers browsing
the spec should see the old recommendation and its drawback in the same
place.

(3.8) "push function" should include a reference to Section 3.9.1.

(3.8.2) s/endpoint may implement/endpoint MAY implement

(3.8.6.2.1) s/min(D.U)/min(D,U)

(3.9.2.2) Is "> a stray mark, or does it mean something?

(3.10) s/and it the segment/and the segment

(3.10, RECEIVE/CLOSE_WAIT) s/text/data

(3.10, SEGMENT ARRIVES/LISTEN) s/text/data

(3.10, SEGMENT ARRIVES/SYN_SENT) Step 4 directs the reader to the "sixth
step below" but the algorithm has only 5 steps! IIUC it is referring to
step 6 of the "other states" procedure, which is several pages later. This
needs to be clearer! (and is where having subsections would be helpful).

(3.11) There are redundant definitions of "Type of Service" and "TOS"

Regards,
Martin

--000000000000fa32df05c588a341
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


First of all -- wow. Thanks for your efforts on this =
historic document.

After a detailed reading, I hav=
e a number of minor comments that should be addressed before IETF Last Call=
, and a bunch of nits.

As always, these AD review =
comments should be viewed as the start of discussion rather than a series o=
f demands. If I'm off base, please say so!

=
COMMENTS:

(Document Header) Please upda=
te the Intended Status to "Internet Standard".



(3.8.3) R1 and R2 can be measured in retransmissions or seconds; the p=
roposed bounds are in retransmissions for R1 and seconds for R2. So if I ha=
ve a time-based R1, should that be 3? If I have a retransmission based R2, =
should I compare that to the value of RTO somehow?

(3.8.5)=C2=A0 This section is unclear as to whether the sender can cause t=
he Urgent Pointer to recede (move to the left), and if so, if that MUST be =
reported to the application like a pointer advance.




(3.8.6.1)


The sending TCP peer must be prepared to accept from the user and
   send at least one octet of new data even if the send window is zero.
   The sending TCP peer must regularly retransmit to the receiving TCP
   peer even when the window is zero
Please clarify that these probes =
only happen when there is new data, if that's the intent.
(3.8.6.1) the first paragraph says


Two minutes is recommended for the retransmission interval when the
   window is zero.



but the last one says


The transmitting host SHOULD send the first zero-window probe when a
   zero window has existed for the retransmission timeout period (SHLD-
   29) (Section 3.8.1), and SHOULD =
increase exponentially the interval
   between successive probes (SHLD-30).
so is it 2 min or the RTO?
(3.8.6.2.1) If I read this algorithm correctly, an un-pushe=
d send buffer of < MSS, if D < Fs*Max(SND.WND), will sit there indefi=
nitely without
being transmitted; is this intentional?
<=
div>


(3.8.2) and (3.8.6.3) Should RFC 5681 be a normative reference, given the c=
ongestion control requirement? If not, (3.8.6.3) shouldn't require the =
reader to go there to fully implement delayed ACKs. I suggest
s/an ACK for at least every second segment/an ACK for least eve=
ry 2*MSS bytes of data

to fully state what is in 5=
681.

(3.10) I understand the desire to conform to =
RFC 793 formatting, but this section is very long and has quite a bit of hi=
erarchy. Some subsections would be very helpful for some needed cross-refer=
encing, as described in the nits.












(3.10, OPEN/LISTEN) 


If active and the remote socket is specified, =
then change the
         connection from passive to active,



I think you mean "If passive"?
(3.10, SEGMENT ARRIVES/LISTEN) Step 4 mentions RST but those h=
ave already been handled in Step 1.


NITS:

(3.1, data offset section) s/=
integral number/integer multiple

(3.1, URG and ACK=
) s/field significant/field is significant

(3.1, W=
indow) It would be useful to observe here that RFC 7323 can change the mean=
ing of this field.

(3.1, Options) "

   Options: [TCP Option]; Options#Size =3D=3D (DOffset-5)*32; present =
only
   when DOffset > 5.

What is this notation?

(3.4)=C2=A0 s/l0/10 (=
switch letter L with numeral 1)



(3.7.2) In the first paragraph it says

RFC 1122 recommends an IP-layer default
   effective MTU of less than or equal to 576 for destinations not
   directly connected
In the last it says


RFC 1191 discusses this implication of many older TCP
   implementations setting MSS to 536 for non-local destinations, rather
   than deriving it from the MTUs of connected interfaces as
   recommended.



Could we unify these comments in the same location? Implementers=
 browsing the spec should see the old recommendation and its drawback in th=
e same place.

(3.8) "push function" shou=
ld include a reference to Section 3.9.1.

(3.8.2) s=
/endpoint may implement/endpoint MAY implement

(3.=
8.6.2.1) s/min(D.U)/min(D,U)

(3.9.2.2) Is "&g=
t; a stray mark, or does it mean something?

(3=
.10) s/and it the segment/and the segment

(3.1=
0, RECEIVE/CLOSE_WAIT) s/text/data

(3.10, SEGMENT =
ARRIVES/LISTEN) s/text/data

(3.10, SEGMENT ARR=
IVES/SYN_SENT) Step 4 directs the reader to the "sixth step below"=
; but the algorithm has only 5 steps! IIUC it is referring to step 6 of the=
 "other states" procedure, which is several pages later. This nee=
ds to be clearer! (and is where having subsections would be helpful).
=


(3.11) There are redundant definitions of "Type of=
 Service" and "TOS"

Regards,
<=
div>Martin



--000000000000fa32df05c588a341--


From nobody Wed Jun 30 14:50:51 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 917E03A2C6E for ; Wed, 30 Jun 2021 14:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level: 
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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=mti-systems-com.20150623.gappssmtp.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 WXp4G5hXtknf for ; Wed, 30 Jun 2021 14:50:44 -0700 (PDT)
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 C8E163A2C6D for ; Wed, 30 Jun 2021 14:50:43 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id q190so4086692qkd.2 for ; Wed, 30 Jun 2021 14:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=qzwk+WIBYODdxUQd8FQjTFhvwyPirUJbyL9+HycmBDY=; b=TcY15ueWkOXn+/p8H9uoN/czI57eiT2njIUM5siKag64UJhsc+NSKPYAPsd1opTxRs lAr1n8AbsBSeKbUfXjZiUvwEvGIeGecYw91dbwNRw43Hmr/RdkUYbE/EA04wyKODDYRm SUirckASBxE2cCAG00yRF9ILEWUWfRfp7w/x5P5DTMoZsF2KRIPss00X4l3uSEnzzkr5 WC9Cglic/5MlPLoQNhKPNOFJbM9qsbjB1IO1rmUPiKeaCp05Y9RhPFWdn+vW/KBoa3SI ko3B8KEBjwsmoMs/FT1mqEHFWX6B5+o08mJlj2iTSORaXqr5ZjhIX4U2Y0B7EtW/u6U2 5f/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=qzwk+WIBYODdxUQd8FQjTFhvwyPirUJbyL9+HycmBDY=; b=NQyEdiyOKYdbfY0CChPrLRUQMCPA7Cb5CzSFuqAx90+8oOZwzP8VhW1JxwpwWInvD5 21JHdeDpnllLsW+C5T2XCWHlkZ6gzF6b9N4FXKgxVv+cZl0CZPTnu1W5LwGN0UOj7Iot NBRQJBwP+KG55dBpdd0xmgRXiXv6QWlEIppVe1R/DaB+Q1UOE0b0JiIF4m1qgJTCyff0 ARCXMfvOAGPrqME5smbvvRLt+LtjUumwRDgmgltBOHbZvgwwkQ0u3aMNKKd1WSX3Im+Z C9FFo6YPyaUhVX3ovDSjgUXYmarKFYi/5NNKUTA9CXOLdtf9eww/KZccPkFIjSJ99qzu X4Dw==
X-Gm-Message-State: AOAM531qBlmWBh6nI+KZQsKVdCX48SqI+B8pJf3301QlzWzQR7y8AZKr AC5YVsT/p3sB3qFs1/1HdDHR6rnvMJaQphRM
X-Google-Smtp-Source: ABdhPJz4dVmN2b+/2JGIMIPpUWpK36L2r/mnyOn2Y7Ct8TGuKMYND/q50OZXkzZnITdVIkdDKrx0mw==
X-Received: by 2002:a37:8e44:: with SMTP id q65mr14217785qkd.372.1625089841311;  Wed, 30 Jun 2021 14:50:41 -0700 (PDT)
Received: from [192.168.1.114] (069-135-001-122.biz.spectrum.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id b13sm6833496qtk.30.2021.06.30.14.50.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jun 2021 14:50:40 -0700 (PDT)
To: Martin Duke , draft-ietf-tcpm-rfc793bis.all@ietf.org, "tcpm@ietf.org Extensions" 
References: 
From: Wesley Eddy 
Message-ID: <59e1d10e-542c-3f1f-7098-4f1d8932da5b@mti-systems.com>
Date: Wed, 30 Jun 2021 17:50:38 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0E5F9E8F8CDA6768F1BF6FEB"
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] RFC793bis AD review
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, 30 Jun 2021 21:50:50 -0000

This is a multi-part message in MIME format.
--------------0E5F9E8F8CDA6768F1BF6FEB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Here are my replies on each finding, with proposed changes to make sure 
you agree, before cutting another revision of the document:


On 6/24/2021 4:12 PM, Martin Duke wrote:
>
> (Document Header) Please update the Intended Status to "Internet 
> Standard".

There doesn't seem to be a way to force this in xml2rfc3; the 'category' 
attribute is set to 'std' (Standards Track) and there's no distinction 
(this looks consistent with other recent Internet Standard RFCs).

So, I think no change is needed on this.


> (3.8.3) R1 and R2 can be measured in retransmissions or seconds; the 
> proposed bounds are in retransmissions for R1 and seconds for R2. So 
> if I have a time-based R1, should that be 3? If I have a 
> retransmission based R2, should I compare that to the value of RTO 
> somehow?

This is heritage from RFC 1122.  The text on R1 mentions "at the current 
RTO", so I think RO is definitely the intended conversion factor, but 
since you asked, maybe it's not clear enough?  Do you think maybe in 
part (a) of 3.8.3 we could just change:

     R1 and R2 might be measured in time units or as a count of 
retransmissions.

to:

     R1 and R2 might be measured in time units or as a count of 
retransmissions (with the current RTO as a conversion factor, if needed).

>
> (3.8.5)  This section is unclear as to whether the sender can cause 
> the Urgent Pointer to recede (move to the left), and if so, if that 
> MUST be reported to the application like a pointer advance.

Receding looks the same as advancing so much that it wraps.  So, if not 
already in urgent mode, that would seem to cause a change to urgent 
mode, while if not already in urgent mode, that would fall under the 
existing rule of:

     If the urgent pointer is updated while the user is in "urgent 
mode", the update will be invisible to the user.

So ... also given that the use of urgent pointer is deprecated anyways 
and we don't want to cause changes to TCP in this doc, I'm proposing we 
do nothing to clarify this, if you agree?


> (3.8.6.1)
> The sending TCP peer must be prepared to accept from the user and
>     send at least one octet of new data even if the send window is zero.
>     The sending TCP peer must regularly retransmit to the receiving TCP
>     peer even when the window is zero
> Please clarify that these probes only happen when there is new data, 
> if that's the intent.

The "accept from the user" part means that new data was written already, 
right?  If the user doesn't write data into the socket, there's nothing 
to be sent.


> (3.8.6.1) the first paragraph says
> Two minutes is recommended for the retransmission interval when the
>     window is zero.
> but the last one says
> The transmitting host SHOULD send the first zero-window probe when a
>     zero window has existed for the retransmission timeout period (SHLD-
>     29) (Section 3.8.1  ), and SHOULD increase exponentially the interval
>     between successive probes (SHLD-30).
> so is it 2 min or the RTO?

Good question ... The first sentence comes from 793 and the other from 
1122.  I think we should erase the first sentence, since the 1122 intent 
seems to be updating this (replacing the hard-coded 2 minute heuristic 
with the RTO one which adapts to reality).  Do you agree?


> (3.8.6.2.1) If I read this algorithm correctly, an un-pushed send 
> buffer of < MSS, if D < Fs*Max(SND.WND), will sit there indefinitely 
> without being transmitted; is this intentional?

This comes from 1122.  I think the key to preventing what you mention is 
this part of the preceding paragraph:

   To avoid a resulting deadlock, it is necessary to have a
    timeout to force transmission of data, overriding the SWS avoidance
    algorithm.

So, SWS avoidance is not supposed to keep a sender waiting forever for 
the receiver to possibly advertise a bigger window; the sender is 
supposed to wake up and just send eventually.


> (3.8.2) and (3.8.6.3) Should RFC 5681 be a normative reference, given 
> the congestion control requirement? If not, (3.8.6.3) shouldn't 
> require the reader to go there to fully implement delayed ACKs. I suggest
>
> s/an ACK for at least every second segment/an ACK for least every 
> 2*MSS bytes of data
>
> to fully state what is in 5681.

Yeah, I think 5681 should be normative (since we also rely on the for 
descriptions of slow start, etc. that we didn't try to duplicate within 
793bis), but we should also fix the "second segment" sentence to match 
more exactly the text in 5681 about 2*RMSS.


> (3.10) I understand the desire to conform to RFC 793 formatting, but 
> this section is very long and has quite a bit of hierarchy. Some 
> subsections would be very helpful for some needed cross-referencing, 
> as described in the nits.

I completely agree.  Numbering these sounds good to me.


> (3.10, OPEN/LISTEN)
> If active and the remote socket is specified, then change the
>           connection from passive to active,
> I think you mean "If passive"?

Actually, I think to be more clear this should say:

"If the OPEN call is active ...", since it's referring to the case where 
an active OPEN is called when the socket is in LISTEN (passive).

It's technically correct currently (just not very clear), if you read 
the "If active" as referring to the OPEN call rather than the socket 
(and it must be that way since a socket in the LISTEN state is the 
result of a passive OPEN).


> (3.10, SEGMENT ARRIVES/LISTEN) Step 4 mentions RST but those have 
> already been handled in Step 1.

Yeah, you're definitely right, and in both cases the action is to ignore 
it, so this part of step 4 is irrelevant, but at least consistent.

It looks like this is an errata to file on 793; should we do that 
quickly and then fix this doc accordingly?


> _*NITS:*_
>
> (3.1, data offset section) s/integral number/integer multiple
>
> (3.1, URG and ACK) s/field significant/field is significant

Both of these are fine to change with me; they're just carry over from 793.


>
> (3.1, Window) It would be useful to observe here that RFC 7323 can 
> change the meaning of this field.

Agreed.


> (3.1, Options) "
>     Options: [TCP Option]; Options#Size == (DOffset-5)*32; present only
>     when DOffset > 5.
> What is this notation?
It is a little odd, but comes from reference [61] for 
draft-mcquistin-augmented-ascii-diagrams-08.

> (3.4)  s/l0/10 (switch letter L with numeral 1)

Good eye; that looks like it was wrong in 793!


> (3.7.2) In the first paragraph it says
> RFC 1122    recommends an IP-layer default
>     effective MTU of less than or equal to 576 for destinations not
>     directly connected
> In the last it says
> RFC 1191    discusses this implication of many older TCP
>     implementations setting MSS to 536 for non-local destinations, rather
>     than deriving it from the MTUs of connected interfaces as
>     recommended.
> Could we unify these comments in the same location? Implementers 
> browsing the spec should see the old recommendation and its drawback 
> in the same place.

Good idea; I think we can.


> (3.8) "push function" should include a reference to Section 3.9.1.
>
> (3.8.2) s/endpoint may implement/endpoint MAY implement
>
> (3.8.6.2.1) s/min(D.U)/min(D,U)
>
> (3.9.2.2) Is "> a stray mark, or does it mean something?
>
> (3.10) s/and it the segment/and the segment
>
> (3.10, RECEIVE/CLOSE_WAIT) s/text/data
>
> (3.10, SEGMENT ARRIVES/LISTEN) s/text/data
>
> (3.10, SEGMENT ARRIVES/SYN_SENT) Step 4 directs the reader to the 
> "sixth step below" but the algorithm has only 5 steps! IIUC it is 
> referring to step 6 of the "other states" procedure, which is several 
> pages later. This needs to be clearer! (and is where having 
> subsections would be helpful).
>
> (3.11) There are redundant definitions of "Type of Service" and "TOS"

I'm good with changing all of these above.

Thank you for the detailed review!


--------------0E5F9E8F8CDA6768F1BF6FEB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Here are my replies on each finding,
      with proposed changes to make sure you agree, before cutting
      another revision of the document:

    


    

    


    

    
On 6/24/2021 4:12 PM, Martin Duke
      wrote:

    

    

      
      


        
(Document Header) Please update the Intended Status to
          "Internet Standard".

      

    

    
There doesn't seem to be a way to force this in xml2rfc3; the
      'category' attribute is set to 'std' (Standards Track) and there's
      no distinction (this looks consistent with other recent Internet
      Standard RFCs).

    
So, I think no change is needed on this.

    

    


    

    

      

        

          
(3.8.3) R1 and R2 can be measured in retransmissions or
            seconds; the proposed bounds are in retransmissions for R1
            and seconds for R2. So if I have a time-based R1, should
            that be 3? If I have a retransmission based R2, should I
            compare that to the value of RTO somehow?

        

      

    

    
This is heritage from RFC 1122.  The text on R1 mentions "at the
      current RTO", so I think RO is definitely the intended conversion
      factor, but since you asked, maybe it's not clear enough?  Do you
      think maybe in part (a) of 3.8.3 we could just change:

    
    R1 and R2 might be measured in time units or as a count of
      retransmissions.

    

    
to:

    
    R1 and R2 might be measured in time units or as a count of
      retransmissions (with the current RTO as a conversion factor, if
      needed).

      

    

    

      

        

          


          

          
(3.8.5)  This section is unclear as to whether the sender
            can cause the Urgent Pointer to recede (move to the left),
            and if so, if that MUST be reported to the application like
            a pointer advance.

        

      

    

    
Receding looks the same as advancing so much that it wraps.  So,
      if not already in urgent mode, that would seem to cause a change
      to urgent mode, while if not already in urgent mode, that would
      fall under the existing rule of:

    
    If the urgent pointer is updated while the user is in "urgent
      mode", the update will be invisible to the user.

    

    
So ... also given that the use of urgent pointer is deprecated
      anyways and we don't want to cause changes to TCP in this doc, I'm
      proposing we do nothing to clarify this, if you agree?

    

    


    

    

      

        
(3.8.6.1)

        

          
The sending TCP peer must be prepared to accept from the user and
   send at least one octet of new data even if the send window is zero.
   The sending TCP peer must regularly retransmit to the receiving TCP
   peer even when the window is zero

          Please clarify that these probes only happen when there is new
          data, if that's the intent.

      

    

    
The "accept from the user" part means that new data was written
      already, right?  If the user doesn't write data into the socket,
      there's nothing to be sent.

    

    


    

    

      

        
(3.8.6.1) the first paragraph says

        

          
Two minutes is recommended for the retransmission interval when the
   window is zero.

        

        
but the last one says

        

          
The transmitting host SHOULD send the first zero-window probe when a
   zero window has existed for the retransmission timeout period (SHLD-
   29) (Section 3.8.1), and SHOULD increase exponentially the interval
   between successive probes (SHLD-30).


          
so is it 2 min or the RTO?


        

      

    

    
Good question ... The first sentence comes from 793 and the other
      from 1122.  I think we should erase the first sentence, since the
      1122 intent seems to be updating this (replacing the hard-coded 2
      minute heuristic with the RTO one which adapts to reality).  Do
      you agree?

    

    


    

    

      

        

          
(3.8.6.2.1) If I read this algorithm correctly, an un-pushed send buffer of < MSS, if D < Fs*Max(SND.WND), will sit there indefinitely without
being transmitted; is this intentional?


        

      

    

    
This comes from 1122.  I think the
        key to preventing what you mention is this part of the preceding
        paragraph:

    
  To avoid a resulting deadlock, it
        is necessary to have a

           timeout to force transmission of data, overriding the SWS
        avoidance

           algorithm.

    
So, SWS avoidance is not supposed
        to keep a sender waiting forever for the receiver to possibly
        advertise a bigger window; the sender is supposed to wake up and
        just send eventually.

      

    


      

    

      

        

          

            

              (3.8.2) and (3.8.6.3) Should RFC 5681 be a normative
              reference, given the congestion control requirement? If
              not, (3.8.6.3) shouldn't require the reader to go there to
              fully implement delayed ACKs. I suggest

            


            

            
s/an ACK for at least every second segment/an ACK for
              least every 2*MSS bytes of data

            


            

            
to fully state what is in 5681.

          

        

      

    

    
Yeah, I think 5681 should be normative (since we also rely on the
      for descriptions of slow start, etc. that we didn't try to
      duplicate within 793bis), but we should also fix the "second
      segment" sentence to match more exactly the text in 5681 about
      2*RMSS.

    

    


    

    

      

        

          

            
(3.10) I understand the desire to conform to RFC 793
              formatting, but this section is very long and has quite a
              bit of hierarchy. Some subsections would be very helpful
              for some needed cross-referencing, as described in the
              nits.

            

          

        

      

    

    
I completely agree.  Numbering these sounds good to me.

    

    


    

    

      

        

          

            

            

          

        

        

        

        
(3.10, OPEN/LISTEN) 

        

        

          
If active and the remote socket is specified, then change the
         connection from passive to active,

        

        
I think you mean "If passive"?

      

    

    
Actually, I think to be more clear this should say:

    
"If the OPEN call is active ...", since it's referring to the
      case where an active OPEN is called when the socket is in LISTEN
      (passive).

    
It's technically correct currently (just not very clear), if you
      read the "If active" as referring to the OPEN call rather than the
      socket (and it must be that way since a socket in the LISTEN state
      is the result of a passive OPEN).

    

    


    

    

      

        
(3.10, SEGMENT ARRIVES/LISTEN) Step 4 mentions RST but
          those have already been handled in Step 1.

      

    

    
Yeah, you're definitely right, and in both cases the action is to
      ignore it, so this part of step 4 is irrelevant, but at least
      consistent.

    
It looks like this is an errata to file on 793; should we do that
      quickly and then fix this doc accordingly?

    

    


    

    

      

        
NITS:

        


        

        
(3.1, data offset section) s/integral number/integer
          multiple

        


        

        
(3.1, URG and ACK) s/field significant/field is significant

      

    

    
Both of these are fine to change with me; they're just carry over
      from 793.

    


    

    

      

        


        

        
(3.1, Window) It would be useful to observe here that RFC
          7323 can change the meaning of this field.

      

    

    
Agreed.

    


    

    

      

        
(3.1, Options) "
          
   Options: [TCP Option]; Options#Size == (DOffset-5)*32; present only
   when DOffset > 5.


          What is this notation?

      

    

    It is a little odd, but comes from reference [61] for
    draft-mcquistin-augmented-ascii-diagrams-08.

    

    

      

        
(3.4)  s/l0/10 (switch letter L with numeral 1)

      

    

    
Good eye; that looks like it was wrong in 793!

    


    

    

      

        

          
(3.7.2) In the first paragraph it says
            
RFC 1122 recommends an IP-layer default
   effective MTU of less than or equal to 576 for destinations not
   directly connected

          

          
In the last it says

          

            
RFC 1191 discusses this implication of many older TCP
   implementations setting MSS to 536 for non-local destinations, rather
   than deriving it from the MTUs of connected interfaces as
   recommended.

          

        

        
Could we unify these comments in the same location?
          Implementers browsing the spec should see the old
          recommendation and its drawback in the same place.

      

    

    
Good idea; I think we can.

    


    

    

      

        
(3.8) "push function" should include a reference to Section
          3.9.1.

        


        

        
(3.8.2) s/endpoint may implement/endpoint MAY implement

        


        

        
(3.8.6.2.1) s/min(D.U)/min(D,U)

        


        

        
(3.9.2.2) Is "> a stray mark, or does it mean something?

        

        


        

        
(3.10) s/and it the segment/and the segment

        

        


        

        
(3.10, RECEIVE/CLOSE_WAIT) s/text/data

        


        

        
(3.10, SEGMENT ARRIVES/LISTEN) s/text/data

        

        


        

        
(3.10, SEGMENT ARRIVES/SYN_SENT) Step 4 directs the reader
          to the "sixth step below" but the algorithm has only 5 steps!
          IIUC it is referring to step 6 of the "other states"
          procedure, which is several pages later. This needs to be
          clearer! (and is where having subsections would be helpful).

        


        

        
(3.11) There are redundant definitions of "Type of Service"
          and "TOS"

      

    

    

    
I'm good with changing all of these above.

    
Thank you for the detailed review!

    

  


--------------0E5F9E8F8CDA6768F1BF6FEB--