From nobody Mon Jun 1 01:14:31 2020 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 726CA3A0E2F for ; Mon, 1 Jun 2020 01:14:29 -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, 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 BtSbcKOoPV4p for ; Mon, 1 Jun 2020 01:14:26 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 B5B943A0E09 for ; Mon, 1 Jun 2020 01:14:26 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id r10so5094564vsa.12 for ; Mon, 01 Jun 2020 01:14:26 -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=wnLVlkuiPTm8Y5GEo5mnSMQYrdrGCJX0WV+07FW5MFE=; b=L4eZeOBRpLlEsVR1zAp6XbJ6fFHbUoonLaP10xTq/SeENg6ARETqzXPgdRIXLflXhm myfiwvOpL75kblfeEGpMf0hLb6wT0+4X7/qxu4iA4/5KbAdU5X/BYdX7rKhviHnhXn87 bK18Ii7+UysvQh9+jr+6hD0spMIFEj6dCsD4MTi/Lm6/2cYTaCeIlt2c8K7vACb+nfol MxSIHpaSORogO853puH8WgU8rhuISuRR56IlUbjmew1/B3pClsx/EDUH3nJ+DcV4kqVA 8pHw7yXE45Es3rGCosoPOuC0uGyXLW1il2kozDdjIgHrf4e8wxruPc2IGwjBunULEe6S LJHA== 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=wnLVlkuiPTm8Y5GEo5mnSMQYrdrGCJX0WV+07FW5MFE=; b=Gzbb+Bq0/iW/VVSejeIDHoCBVSkpQk5YChXv2JJVHrHfq2lOn/RRSQ2YaQuxqB92lD 6eSNRn2YYhdmFcsLsXM9LN9L4eQ+Da95Z8cs4VPJObXoScQ38Bc4E5VLrtv2gaDwQoQ9 YH2wCEBkhnD1f2vrQXiHySnPhWR9Zch+SRUqMirnexzrQjDJkyGgHjdmOUdAPRBZKav8 1/IU5hOqHVVbVDF+maXrsbDpol70ElxqUIFfWJpMuLUpGFq+YIxcnqW3g1uc1CWOs6DA ImnxQmwr77nR2FWGMPrzaDlR8PerDduftPUKbPtgPKABxIgSkh2BudplqGR0cbaroeP9 atBQ== X-Gm-Message-State: AOAM530Mx3+rzvgqXFYj4NgO17MKF95Gvv9iqo7rcQavEk6z9Diaa3W/ 8Jqzrp8qcUaLGg/9QmMPJjeiRvM0l2zj4HHipBc= X-Google-Smtp-Source: ABdhPJxh+fAZbJLCae3oRyXxGfLCZj9dxxBewrlEfnTj7O3c2lD6nTEtcapPsPWh0MsR5lkJ6+TYZ+XPbpHSGvCr96U= X-Received: by 2002:a67:7c54:: with SMTP id x81mr3484380vsc.129.1590999265724; Mon, 01 Jun 2020 01:14:25 -0700 (PDT) MIME-Version: 1.0 References: <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net> <9FF84BB4-6AA8-4C37-8B51-D4B87228FCF6@strayalpha.com> In-Reply-To: <9FF84BB4-6AA8-4C37-8B51-D4B87228FCF6@strayalpha.com> From: Yoshifumi Nishida Date: Mon, 1 Jun 2020 01:14:14 -0700 Message-ID: To: Joseph Touch Cc: Olivier Bonaventure , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000124e6a05a70162d1" Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 01 Jun 2020 08:14:29 -0000 --000000000000124e6a05a70162d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 BTW, it seems to me that the use case for using connection ID in this thread is load balancers. But, it sounds over-engineering to me if we design it for this purpose. QUIC's connection ID may be able to be used in LB cases with some additional logic, but it was designed for more fundamental purposes. -- Yoshi On Wed, May 27, 2020 at 10:18 AM Joseph Touch wrote: > > > On May 25, 2020, at 11:51 PM, Olivier Bonaventure < > olivier.bonaventure@tessares.net> wrote: > > Another possibility would be to place the connection id in the network > layer, see doi:10.1109/TNET.2018.2799242 > > > Not unless the network layer is establishing the connection, IMO. > > In IP, connections are transport layer and above; they shouldn=E2=80=99t = be buried > elsewhere. (And no, a flow ID is not a connection ID, because one flow ma= y > represent multiple connections or one connection may use multiple flows). > > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000124e6a05a70162d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1
BTW, it seems to me that= the use case for using connection ID in this thread is load balancers. But= , it sounds over-engineering to me if we design it for this purpose.
<= div>QUIC's connection ID may be able to be used in LB cases with=C2=A0s= ome additional logic, but it was designed for more fundamental purposes.
--
Yoshi


On Wed, May 27, 2020 at 10:18 AM J= oseph Touch <touch@strayalpha.co= m> wrote:


On May 25, 2020, at 11:51 PM, Olivier Bonaventure <olivier.bona= venture@tessares.net> wrote:

Another possibility would be to place the connection= id in the network
layer, see doi:10.1109/TNET.2018.2799242

Not unless the network layer is establishing the co= nnection, IMO.

In IP, connections are transport la= yer and above; they shouldn=E2=80=99t be buried elsewhere. (And no, a flow = ID is not a connection ID, because one flow may represent multiple connecti= ons or one connection may use multiple flows).

Joe=
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000124e6a05a70162d1-- From nobody Mon Jun 1 05:14:40 2020 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 766B63A0FD5 for ; Mon, 1 Jun 2020 05:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 TxsdQirPPy7C for ; Mon, 1 Jun 2020 05:14:38 -0700 (PDT) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 5651E3A0FD1 for ; Mon, 1 Jun 2020 05:14:38 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id d67so3677193oig.6 for ; Mon, 01 Jun 2020 05:14:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=4tvhe553QT95zR3Ju7HpvoIeTFBHmpbxWREO3BZky68=; b=RgaLdC+gP32jHVELak1k1tUKIWwcEuMJtkmm52xfLNGB2TnKcI6y/tjVsAzk1TOOdY 4So5rhEtS8mXUAaXO65u+XrekgSguVFOUCgNeCECUjKctf8dFJ7M5meSYnAdneybeYZa q6DLVMymJR4bG8gLk5vlI2U3UXryJfhYyDyy/0sb91zskVn4ySMi/p86YhPHSrWOJMJe 1BlM6G7rQn6Es2FdnkuDIhJmlkFkuRKsBI6lTMBu3UF8Bn2/MaxRXLSrTG+qk3h7IZsL /Qw1LCOc9BETRNd3LfT4H5PtQGVvlJrm9cEF5BAYh8CbPeaiO5InHzFAWpWZtSHnth5i 8DlA== X-Gm-Message-State: AOAM530iquuBmVF4HKhF2qapfeMDZv9Tl0ecOgnZhmoHW7ZV1Mj9b/PN vAbUooW/UqA/d4hpZoCImy8+ZA== X-Google-Smtp-Source: ABdhPJyffn4F/AkX6rCtyYnczcbAC74JXmqGQAirlHXBPHf2+U+IJRjlPo49rOBE5JwTm7YQdu8wCQ== X-Received: by 2002:aca:190b:: with SMTP id l11mr14181366oii.102.1591013677545; Mon, 01 Jun 2020 05:14:37 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:1117:6277:b6a1:6c13]) by smtp.gmail.com with ESMTPSA id q7sm917515ool.34.2020.06.01.05.14.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 05:14:36 -0700 (PDT) From: "Mark Allman" To: "Benjamin Kaduk" Cc: "tom petch" , last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org Date: Mon, 01 Jun 2020 08:14:34 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <20200531185401.GU58497@kduck.mit.edu> References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <20200531185401.GU58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_0E63EF94-9FF9-4C60-9E45-7BBB4CA0B2B2_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 01 Jun 2020 12:14:40 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_0E63EF94-9FF9-4C60-9E45-7BBB4CA0B2B2_= Content-Type: text/plain > There was a quote from the document: "Some protocols use > keepalives, heartbeats or other messages to exchange control > information." A naive reading of this text is that it is > discussing ways to exchange control information, and giving > specific examples of keepalives and heartbeats as messages used to > exchange control information (while admitting the existence of > other such messages). This is as surprising to me as it is to Tom > -- keepalives and heartbeats do not, in my experience, contain > control information! > > Your follow-up discussion suggests that the intent is to say that > "some protocols use regular/periodically/frequently exchanged > messages, such as for keepalives, heartbeats, or > control-information exchange" and to leverage that traffic for FT > purposes. I suggest that this be clarified in the text of the > document. I tend to bin packets as either "data" or "control", which is probably why the sentence reads like it does. However, we don't have to figure out who is right here. I think the intent of the document is to say one can scrape a FT sample from a non-data exchange. That is the important part and doesn't seem to be an issue. I have made a note to say that more directly. Thanks, allman --=_MailMate_0E63EF94-9FF9-4C60-9E45-7BBB4CA0B2B2_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXtTxKhEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizq+aAJ410jk9B4q8EPinhgafviWug988JQCgi4c+ sN7vTznzz1DrzQMEENWkKSM= =HZo/ -----END PGP SIGNATURE----- --=_MailMate_0E63EF94-9FF9-4C60-9E45-7BBB4CA0B2B2_=-- From nobody Tue Jun 2 00:05:46 2020 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 6D2A03A0F9B for ; Mon, 1 Jun 2020 04:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.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 yRBTG9mhayfR for ; Mon, 1 Jun 2020 04:41:44 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 344593A0F9A for ; Mon, 1 Jun 2020 04:41:44 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id p70so3933231oic.12 for ; Mon, 01 Jun 2020 04:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=P1xlheADY5had1CsGBwtpD7XtJcqR+KvagugbRzXJxg=; b=BVOUFHwLXbcQcW7wxYa7mbfkHbaco4Jv/tvfkhEXrqYVm/NhUq8x05RFAAfCiYdA2U tCEszeQ7fHu1r1NtebB9lgbvX1fbovRCGX1OSca2ELnFUZWlF0LynwBxyDIYqTDLOVCy xIaasOJptA/9zrqcxaCoCY1QADJC4tAMaE3O1w7wDHSlm4rQUysc1QEgKoHYpM1GH7Lu 7HMLdEurw8CwGGAxPkDsQ/sDT8jfDojTM92c5zITOKWJYClHLKVWFQ1DjpZRiW2Hj9Ms 6CRsFRAL5y6ocSsUcyN0gkFtYHAfPYvZRBiD6cOPVRohBbbzh8Pp3Uoh7QIiy0rbaXtR IlFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=P1xlheADY5had1CsGBwtpD7XtJcqR+KvagugbRzXJxg=; b=kPVXEhcncFHmO9fg1u6rw0TqbUT1p4h03mB4f8s4VcznHIeQb1xia/hY/chXHWEWJH 9yryzFwEqO3UmmWSzVw0nJNZ3j44PFN+xcqZES0VzGgABmzE3EPDRppTIqdXwNNaYJYs JJVmirj99NR8pid054GuMYX8Lw5BXT3VSlAjBOaf++gJQOetvJttqGx4/EqIjMonOltq QpWt6+QmdgVl004x62LdpXeXYRmevWb9gAe/i9ACHASc+gAXqCsBmQ2GhzTYMTK31U10 7gVzseqK4heMWDo0zNAt8y4tlFLRiipvSBXlGYvFUCwG5Z2ZkhXhFQqEXtmNNXE29Dwx QsbQ== X-Gm-Message-State: AOAM533Elv/NZzoAm8UkZyBZiCsYFLzEBO8sSLED14PJo18buvJHy2/h j7LC8eUQqRBChOWrTNPf3XeVaQ== X-Google-Smtp-Source: ABdhPJz/wFyHcRTdf8xt33bvkic9RwHns3EjpxVQ8KV1ZgW/3Ii+ydU+VCCY4zd60FxDW1SkEFDNFw== X-Received: by 2002:aca:4e55:: with SMTP id c82mr1061287oib.147.1591011703359; Mon, 01 Jun 2020 04:41:43 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:1117:6277:b6a1:6c13]) by smtp.gmail.com with ESMTPSA id e203sm4479142oif.55.2020.06.01.04.41.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 04:41:42 -0700 (PDT) From: "Mark Allman" To: "Benjamin Kaduk" Cc: "tom petch" , last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org Date: Mon, 01 Jun 2020 07:41:40 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <1000D10B-8C24-48AA-8900-23B4208B8953@icsi.berkeley.edu> In-Reply-To: <20200531185401.GU58497@kduck.mit.edu> References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <20200531185401.GU58497@kduck.mit.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_78056F0C-3BE7-4198-A68F-5E9CF0CB6C81_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Tue, 02 Jun 2020 00:05:44 -0700 Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 01 Jun 2020 11:41:47 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_78056F0C-3BE7-4198-A68F-5E9CF0CB6C81_= Content-Type: text/plain > There was a quote from the document: "Some protocols use > keepalives, heartbeats or other messages to exchange control > information." A naive reading of this text is that it is > discussing ways to exchange control information, and giving > specific examples of keepalives and heartbeats as messages used to > exchange control information (while admitting the existence of > other such messages). This is as surprising to me as it is to Tom > -- keepalives and heartbeats do not, in my experience, contain > control information! > > Your follow-up discussion suggests that the intent is to say that > "some protocols use regular/periodically/frequently exchanged > messages, such as for keepalives, heartbeats, or > control-information exchange" and to leverage that traffic for FT > purposes. I suggest that this be clarified in the text of the > document. I tend to bin packets as either "data" or "control", which is probably why the sentence reads like it does. However, we don't have to figure out who is right here. I think the intent of the document is to say one can scrape a FT sample from a non-data exchange. That is the important part and doesn't seem to be an issue. I have made a note to say that more directly. Thanks, allman --=_MailMate_78056F0C-3BE7-4198-A68F-5E9CF0CB6C81_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHgEARECADgWIQR2wAGDYhexl/6SqCRbKutazjIizgUCXtTpdBocbWFsbG1hbkBp Y3NpLmJlcmtlbGV5LmVkdQAKCRBbKutazjIizgtMAJ0SmpRcAfC9ts+mecLn/2JT LwO+BQCgiLlv/bFU2nDjlLa9kaPpHTTIsfI= =GMJv -----END PGP SIGNATURE----- --=_MailMate_78056F0C-3BE7-4198-A68F-5E9CF0CB6C81_=-- From nobody Thu Jun 4 07:49:38 2020 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 C0E943A0D06 for ; Thu, 4 Jun 2020 07:49:35 -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, 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 gDtj3iAzlZq2 for ; Thu, 4 Jun 2020 07:49:34 -0700 (PDT) Received: from mail-oo1-xc2d.google.com (mail-oo1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 3CC853A0D03 for ; Thu, 4 Jun 2020 07:49:34 -0700 (PDT) Received: by mail-oo1-xc2d.google.com with SMTP id h7so1284298ooc.9 for ; Thu, 04 Jun 2020 07:49:34 -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=5nE2UGd8nAIzM9wnqnyUvj/hxdojUTm4UHej/cfyFgs=; b=ukOS1W82CNWkBQfr8ATIhEdfBTDgHDoEJ9NfnVR5BR4g/29CwpGL3dfMnTljwAg17p RQu9QgC74SAbV/v+NPGnJg4ls7j+rjCxhjZ69P2iac128ykUhhYKirMLMX4mrKPrYr/o t6N/mE1B2g1C11BZtHNtM50WNTNfAfDqS4c1LcdC41bQYfsRgHuIx1xlvTJLQ/5YOhdC wqOXSeFVfKteGsTqTZWjX7jki0H3vVUmFzQOoRMGkmqan5AigqH76slMH0SxugYsMgqV XqMpLcSBRguhc7ou3rVnCwaBhQPKuZuCpXEI+2F6rP5QDrWxVGJPvusaUOPO6ifO3q2q ES4Q== 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=5nE2UGd8nAIzM9wnqnyUvj/hxdojUTm4UHej/cfyFgs=; b=I1dTQi0XUm/9oTUJeEAv2WbHKNRsK561hkURdqtCR1zZHZq2K30w5gknnvcGYOQcHS 2ev8ncCkkTb7xDFslqcbhm8IsPSbA7pQKRgrMgF5RkZ5ENQM5uwbepyuwL2f3c3X3nvV 5E39MN9/vqgyLbg2lGfa8znVouebnKibWbm5YyEug2i7B3/AKo3ZpQYQ+IKBnEJBEEpS U0tVZ9WZ+mXYl1EQFFbYDCXKW1iUog1IRWjDigyy6SxTpqC3koujik0Tkcf6zriSa5z4 QSqSAVxjN0eEvGUc/gMUjIG5e6GwhA8JvJ53D1J395DeTOleOsmnREVP8xlWFatFicHx vkiQ== X-Gm-Message-State: AOAM531JfVtJoomWicz5VEBjEc1IZVPJaIBoeUjjnQtGlSEaZhXURN+v sMrTjSmgqoIH/oBJp/bm17eP7FFawJ9qOxECDzI= X-Google-Smtp-Source: ABdhPJwDw69jVd5SoY04Chz3ymOsLgjTwkYjCSZ72YlnIOfEWr6K1IJg4KaZ1JsbewgaezcCPZgnwZqP3V5dNG1y85Q= X-Received: by 2002:a4a:d63a:: with SMTP id n26mr3970532oon.64.1591282173385; Thu, 04 Jun 2020 07:49:33 -0700 (PDT) MIME-Version: 1.0 References: <86F47ECD-8504-4FAA-8D39-0099C203FA0C@tessares.net> <9FF84BB4-6AA8-4C37-8B51-D4B87228FCF6@strayalpha.com> In-Reply-To: From: Alexander Azimov Date: Thu, 4 Jun 2020 17:49:22 +0300 Message-ID: To: Yoshifumi Nishida Cc: Joseph Touch , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000ae9f1a05a7434066" Archived-At: Subject: Re: [tcpm] TCP Connection ID 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, 04 Jun 2020 14:49:36 -0000 --000000000000ae9f1a05a7434066 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for the feedback. I still think that it is worthy of trying even if it is applicable only for the case of load balancers. I will try to gather broader feedback from content/cloud providers to see if they are looking/working on something similar. =D0=BF=D0=BD, 1 =D0=B8=D1=8E=D0=BD. 2020 =D0=B3. =D0=B2 11:14, Yoshifumi Ni= shida : > +1 > BTW, it seems to me that the use case for using connection ID in this > thread is load balancers. But, it sounds over-engineering to me if we > design it for this purpose. > QUIC's connection ID may be able to be used in LB cases with some > additional logic, but it was designed for more fundamental purposes. > -- > Yoshi > > > On Wed, May 27, 2020 at 10:18 AM Joseph Touch > wrote: > >> >> >> On May 25, 2020, at 11:51 PM, Olivier Bonaventure < >> olivier.bonaventure@tessares.net> wrote: >> >> Another possibility would be to place the connection id in the network >> layer, see doi:10.1109/TNET.2018.2799242 >> >> >> Not unless the network layer is establishing the connection, IMO. >> >> In IP, connections are transport layer and above; they shouldn=E2=80=99t= be >> buried elsewhere. (And no, a flow ID is not a connection ID, because one >> flow may represent multiple connections or one connection may use multip= le >> flows). >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --=20 Best regards, Alexander Azimov --000000000000ae9f1a05a7434066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for the feedback.

I = still think that it is worthy of trying even if it is applicable only for t= he case of load balancers.
I will try to gather broader feedback from c= ontent/cloud providers to see if they are looking/working on something simi= lar.

=D0=BF=D0=BD, 1 =D0=B8=D1=8E=D0=BD. 2020 =D0=B3. =D0=B2 11:= 14, Yoshifumi Nishida <nsd.ietf@gmail.com>:
+1
BTW, = it seems to me that the use case for using connection ID in this thread is = load balancers. But, it sounds over-engineering to me if we design it for t= his purpose.
QUIC's connection ID may be able to be used in L= B cases with=C2=A0some additional logic, but it was designed for more funda= mental purposes.
--
Yoshi


On Wed, May 27,= 2020 at 10:18 AM Joseph Touch <touch@strayalpha.com> wrote:


On May 25, 2020, at 11:51 PM, Olivier Bonaventure <olivier.bona= venture@tessares.net> wrote:

Another possibility would be to place the connection= id in the network
layer, see doi:10.1109/TNET.2018.2799242

Not unless the network layer is establishing the co= nnection, IMO.

In IP, connections are transport la= yer and above; they shouldn=E2=80=99t be buried elsewhere. (And no, a flow = ID is not a connection ID, because one flow may represent multiple connecti= ons or one connection may use multiple flows).

Joe=
_______________________________________________
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


--
Best regards,
Alexander Azimov
--000000000000ae9f1a05a7434066-- From nobody Fri Jun 5 05:52:08 2020 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 18EB33A0A67 for ; Fri, 5 Jun 2020 05:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8FuYiY1IyMDx for ; Fri, 5 Jun 2020 05:52:00 -0700 (PDT) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 5D2383A09F6 for ; Fri, 5 Jun 2020 05:52:00 -0700 (PDT) Received: by mail-qt1-f178.google.com with SMTP id j32so8269035qte.10 for ; Fri, 05 Jun 2020 05:52:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=tqRPMG8jMS1h61GJ4AMupC8Zsv/PADKSceTEQ8K6R0o=; b=lV/RyzIKuU2JHF8JVX/ROgfxoj1FgKaG7mKc7q5AeEwX3+5As2K3y7BSEDmPYkDUWn V5bH7m6GRhk39M/xf0tvlZzFsMOiokzcbVghfRqboVU+3251W20jnKaZrxL+PyQaQwx2 Qg5OTWKFMZDTtM5mXlFdO0KcUpzwWCOrDDcsm5lXMFlmwFR4hycmlnUMPTIc3gf9e+ac opnDdxs+Mas/kwm+eBYGQjgJwChthbvZ7HRh1Tt3PeBmJxheR/SqcfXuuY1syr53bdEm YOfW2k2m/EwizApNGrZytldlOMNkkMx2zRWNfTrHesggYP8pyfNBa61i4NRMVf5lP3ic G8tw== X-Gm-Message-State: AOAM532JBc/EoiNQmdKhgE8P0LJM+H9AoD1zPvcwdcdYrzh6CwI1dzrq XF6yFDBHReRk2veZkUyLWIc+og== X-Google-Smtp-Source: ABdhPJw5kO+d4E8xmOLS4gKaNjMJ8l5eZoNG5YjS0YqW04iirZovhaD3OiChh7sc7Ld6n3kYexEQ/A== X-Received: by 2002:ac8:110:: with SMTP id e16mr9439946qtg.94.1591361519305; Fri, 05 Jun 2020 05:51:59 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:64f0:807:946d:504b]) by smtp.gmail.com with ESMTPSA id d9sm7149973qtq.56.2020.06.05.05.51.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 05:51:57 -0700 (PDT) From: "Mark Allman" To: "tom petch" Cc: "Last Call" , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org Date: Fri, 05 Jun 2020 08:51:55 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> In-Reply-To: <5ED244F7.7030307@btconnect.com> References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_124717B5-9420-469A-BA3D-353D47F40A98_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 05 Jun 2020 12:52:02 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_124717B5-9420-469A-BA3D-353D47F40A98_= Content-Type: text/plain Hi Tom! Sorry for the long RTT .... I had a deadline earlier this week and am still trying to dig out. > It is the 'packets are lost due to congestion and that is THE > problem' that I see as the unstated assumption for this and many > IETF documents. Is it correct? Well, yes, I agree with the first part of the sentence. However, I disagree that is somehow an unstated assumption. The document says: (4) Loss detected by the RTO mechanism MUST be taken as an indication of network congestion and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). That seems pretty explicit to me. And, yes, I fully understand loss happens for non-congestion reasons. But, as a default---which this document is---I think this guideline is on firm ground. > A statement up front about the assumption of unreliability would > address this. I have added a note and will note in the intro that we take the pessimistic (but realistic) assumption that the network is unreliable and/or unknown. Clearly if that is not the case one could land somewhere else. Thanks! allman --=_MailMate_124717B5-9420-469A-BA3D-353D47F40A98_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXto/6xEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizseoAKCZ81R/spcsOGCKWczc2ohR2oIQAACbBQ9R /C5I5Vbq73MNDPRacAobtSA= =Y9rg -----END PGP SIGNATURE----- --=_MailMate_124717B5-9420-469A-BA3D-353D47F40A98_=-- From nobody Fri Jun 5 08:54:06 2020 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 D07AC3A07C4; Fri, 5 Jun 2020 08:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xMsKl2otrmSI; Fri, 5 Jun 2020 08:53:45 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2135.outbound.protection.outlook.com [40.107.21.135]) (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 24C453A07C3; Fri, 5 Jun 2020 08:53:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NZsnYGa+EFC6DToeE3y6De6RH5TW4dPcSmymfK/EAOiwhe7ynuDQpBf8IX4Nv5/WPNC9qFxEb4dsgVIUyBs9k1xd3WfLN5c4QjFfWaqBgjOQ++d08l5mBYk+rjCYNQqrq50yK1szirTHv1kIvK8OjDAQui9Y7LbTaneWLE5cg06Ft1K0TkibmbwEwcDyUsusJZDgGlp4s5qTffcb4+VSJ8/uO9u0vy84UhLn97sxuyTuYTg4DaL3EDub0BjNhC2H2QNkc++uz32Y8tBUluAvLMevZ7BcO2027tg+2HnMlo/I+zeS/+Uab50OOevigbez1e8honQifVp+dci/r6xKtQ== 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=UUMQsSOCcBDcbjSFghoqVhRi3LZw1AesIcjGTtRphGM=; b=fkMQV8e6qKfqcFel77wg1pKAEvQAyBbDxTnokvvlLyQ31X7lDQJopGaBYGi6fcpeMj3DNFjidB3/nzEihPnbaUfpNXt1FARs9fy8csBjkOCtVXp9p6khdnnWUMbeE2GOTJ01/+Va2NozmOdb4n8c2GQ6OOTz6IyJvrtf8H1894LXTnbV20Hvj5OOY2R7u7NVn+l5nUgtDf20O5H3d46fu2siJe4ZA/MK2Zh9/LiEqCmefGKShESJUeOYnw5WWx6pt6lzEOICHYn7hFkhgxLZog2e2vb7B8M13cdhs1xVwDTETN5bYYML35jziAabEsXi3yXAX6rqNBnXsAA8LcY6Bw== 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=UUMQsSOCcBDcbjSFghoqVhRi3LZw1AesIcjGTtRphGM=; b=Hwjt0RWb1Zrm8TP7PI0vWPejErUjoqTKvdYz/RuV63t7jeblUIKA6CrWY8q4+zY/SLiKtLuqeGzbgdyHLDpHVL8uVijO9i3OSyPzcnq54Qb+lVZWrsaBgxaN17f7ZpIADkD7DK/hZMhN95LYGkqUjg6uDHBamuojIePhgPHgqSc= Authentication-Results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) by VI1PR0701MB7054.eurprd07.prod.outlook.com (2603:10a6:800:195::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.11; Fri, 5 Jun 2020 15:53:42 +0000 Received: from VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176]) by VI1PR0701MB2480.eurprd07.prod.outlook.com ([fe80::3474:b82e:e75a:b176%11]) with mapi id 15.20.3088.011; Fri, 5 Jun 2020 15:53:42 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> Date: Fri, 5 Jun 2020 16:53:27 +0100 Message-ID: <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> In-Reply-To: <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> From: "tom petch" To: "Mark Allman" Cc: "Last Call" , "tcpm" , "draft-ietf-tcpm-rto-consider@ietf.org" , "tcpm-chairs@ietf.org" User-Agent: OEClassic/3.0 (WinXP.2600; F; 2019-11-28) X-ClientProxiedBy: LO3P265CA0002.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:bb::7) To VI1PR0701MB2480.eurprd07.prod.outlook.com (2603:10a6:800:63::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from pc8xp (86.139.211.47) by LO3P265CA0002.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:bb::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Fri, 5 Jun 2020 15:53:41 +0000 X-Originating-IP: [86.139.211.47] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 52db7a27-7dba-4bf7-7d6d-08d809689eed X-MS-TrafficTypeDiagnostic: VI1PR0701MB7054: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0425A67DEF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SqV/iNqP6DqqVmH2TQX7MrjWDUetPe2SNgyqE17riPqD+PhTX0dfu+qRM1pg6cmqh4Xb2kgLYZJ+dJKWvU06F5QNuPP8EgLiAYtH6tg34DSf62Cibtfxealw7XWEvpj1ip9tlWS1eFFn3u3VTbXlk/pI4XBLvyWkKEq0AlUfr1YY479LviLXbT6cn+VCL6txB/ZfJhdP1m/82voP4sfpdJS53Ti+iax3qg8BiJ19dPqo3dyg/E4WMCMh8TmO6JhSlHLhHpdiQeosrS9bHrXdzD3sH/oidBnlNCRwR78Whu5/1wKNBPuXmjzipk5CBeSL7RhkiUNA+CgqeK/+RP778EEhmHPGfELRLjMNRSV9n9TD8zfCd6T1vmJxJLjW7jUlvBD2go0IgqZ7S6Q/QVJe8A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2480.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(376002)(346002)(39860400002)(366004)(2906002)(54906003)(33716001)(52116002)(6496006)(83380400001)(9686003)(16526019)(26005)(5660300002)(6916009)(186003)(45080400002)(966005)(478600001)(55016002)(6666004)(4326008)(66476007)(66556008)(8936002)(9576002)(66946007)(8676002)(956004)(86362001)(316002)(52230400001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: n7wje1fZiay7LopBIv6/1yhAlEFwS2Lh3gg0I7/6xEFN7e34rRoIUH8gyME1WGG8tPBbLZmJtaNo6sRXoi6OHgc08bZitnjCOeBMbtlRSyKxU5cLwdtBLOjiQB7ymFDX/6e6nOzl3nDc+xVHkDVg8V/lg0YLcpKXMd/lCGuYMD2yIPaXEmC8pa6IgyNiuDAoc5YzTbKWP4bCKURS3cbP+VvdDublhyQkZoqrvLxBWOssYovXvPKjQlkHYzExX2bnoVxEb7m1CLoBYueeSCXtnQ3TmdpdnEWethWpSbD7+GfJnMme4gg0FwJek6jESgoenvzB2gJ+lRLo+XWOlUfe36lpAf4wVW0nEXkFX31aVKys2OLAkp4yjwL/fgGKiiDrU+DC9tLquYSEqytbF2XzhZ1KHG9O/mU76Lh0kkogHcWSwS58Ri9dfPs6xg3i0SW5ba14Hp/MxtQy1QGNz4EnfGUnVmW8MOcZp8MWVaASpFg= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52db7a27-7dba-4bf7-7d6d-08d809689eed X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2020 15:53:42.3726 (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: WgzU75cVXCRxdJ5xujlf27KSxBpxh85/YK3RnG4xklVSB/eOjzAzGrwDjsNVAGwntO4dd3HZWXpUCEiuDsC3Wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7054 Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 05 Jun 2020 15:53:50 -0000 ---- Original Message ----- From: Mark Allman mallman@icir.org Sent: 05/06/2020 13:51:55 Hi Tom! Sorry for the long RTT .... I had a deadline earlier this week and am still trying to dig out. > It is the 'packets are lost due to congestion and that is THE > problem' that I see as the unstated assumption for this and many > IETF documents. Is it correct? Well, yes, I agree with the first part of the sentence. However, I disagree that is somehow an unstated assumption. The document says: (4) Loss detected by the RTO mechanism MUST be taken as an indication of network congestion and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). That seems pretty explicit to me. And, yes, I fully understand loss happens for non-congestion reasons. But, as a default---which this document is---I think this guideline is on firm ground. Mark, that is what I am questioning, that by default loss implies congestio= n. Historically true for the IETF but I think that there are a growing num= ber of cases where it is not true as in a post I saw on another WG list thi= s week where a document was saying that loss MUST NOT be taken as an indica= tion of congestion so the MUST in this I-D I find too strong. I am saying= that there are a number of places in the document where congestion is assu= med to be the cause. Thus 4(i) has 'when a network is already congested' which I think should be 'if the netwo= rk is already congested' or the next paragraph about 'cause congestion cont= rol ' or in s.5 'detecting loss carries a requirement to invoke a congestio= n response'; no, only if the network is of a kind where loss is due to cong= estion, not other networks. As Stewart put it better than I, this is BCP and so could be used wrongly=20 --- New Outlook Express and Windows Live Mail replacement - get it here: https://www.oeclassic.com/ against protocols where it is inappropriate because the scope of this I-D a= ppears to be so broad. Tom Petch =20 > A statement up front about the assumption of unreliability would > address this. I have added a note and will note in the intro that we take the pessimistic (but realistic) assumption that the network is unreliable and/or unknown. Clearly if that is not the case one could land somewhere else. Thanks! allman From nobody Fri Jun 5 09:17:04 2020 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 7ABC53A07E6 for ; Fri, 5 Jun 2020 09:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 McRQP1ZpmPA0 for ; Fri, 5 Jun 2020 09:17:01 -0700 (PDT) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 315993A07ED for ; Fri, 5 Jun 2020 09:17:01 -0700 (PDT) Received: by mail-qk1-f180.google.com with SMTP id c185so10215500qke.7 for ; Fri, 05 Jun 2020 09:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=qhlJCIPF2O8pdJxcwyxYXwKgTSzqr667DSA/qAoYexs=; b=nqcVL54WbhPP3LuE/JO9yeDQYiULRks7ETVqM8iuaSia6WIn9xRtOnSictBTpQCMSe 3EPYtEhEc2u9qu6Y/1g5ewKJm+vWcfMMYr9UAArPIEyPrCvKWCeDaiTrFl0jqPaBgvZ9 8nPC6QeJiXuDPGpZ95o3qiwUcfUBkvbCk92TNWDTHUY+aiE7hvd6sscur+cTQIiwCOl3 FzGlpc0wFdaqT83q+RQ++IYcj5SuzQbIohf5I9kYLlbc2retM8QjltKkEIly771uvQ3T 4LPz4hkD15HD9HhFH4nTcTYCNOo5vvMikWDkr0BOy7HTmaS9BJEZ5MxCZ6EziyirMNfV zorg== X-Gm-Message-State: AOAM533UKys0UIgZRox5cMBBcnhzqMfl4QwYG6SZrkLrkhxawF/hGMIS uD8OwC+zvV6sy4ZxRQ644ZmNFw== X-Google-Smtp-Source: ABdhPJy+S26f/MW3MF3tEqqnO0EQ7VX2tOnLISllOhe/7m7PfIMbyAbTD8gUvbp3CmxiTZ+CaF3Beg== X-Received: by 2002:ae9:df86:: with SMTP id t128mr10234056qkf.29.1591373819723; Fri, 05 Jun 2020 09:16:59 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:64f0:807:946d:504b]) by smtp.gmail.com with ESMTPSA id b185sm158333qkg.86.2020.06.05.09.16.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 09:16:58 -0700 (PDT) From: "Mark Allman" To: "tom petch" Cc: "Last Call" , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org Date: Fri, 05 Jun 2020 12:16:57 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> In-Reply-To: <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D4BDCE4C-2DD6-406D-87F6-59D73AE6161B_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 05 Jun 2020 16:17:03 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D4BDCE4C-2DD6-406D-87F6-59D73AE6161B_= Content-Type: text/plain > Mark, that is what I am questioning, well ... > that by default loss implies congestion. Historically true for > the IETF but I think that there are a growing number of cases > where it is not true as in a post I saw on another WG list this > week where a document was saying that loss MUST NOT be taken as an > indication of congestion so the MUST in this I-D I find too > strong. OK. So, I am not sure what to do here. I will say several things ... (1) I believe that as a general, default the document is quite right in specifying a congestion response and exponential backoff. (2) I believe consensus of the WGs has been the same as my notion in (1) for some time now. So, even setting aside (1), I am not sure I feel like I have carte blanche to change this. (3) I do not believe loss always means congestion and I do not believe assuming such is always correct or should always be done. I don't think I know anyone who thinks that. So, the document explicitly says that is fine, just go get consensus that some other approach is fine. (And, that should be happening regardless of this document, so I am not sure what the big deal is here.) So, basically, I am not sure what to do here. Maybe one of the ADs can help. Or, maybe we can set this aside and I can do the things I told you I'd do and a little extra framing will make this better. I am all ears for advice here. (BTW, I have a half response to Stewart, as well. I am not ignoring his review. I am just behind.) allman --=_MailMate_D4BDCE4C-2DD6-406D-87F6-59D73AE6161B_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXtpv+REcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizqXGAJoDE43sStR+bRHLC6VukV6XqEzzOgCfR55C vteFQU+MDy1+P8m/GIjO48c= =pwsb -----END PGP SIGNATURE----- --=_MailMate_D4BDCE4C-2DD6-406D-87F6-59D73AE6161B_=-- From nobody Fri Jun 5 09:29:50 2020 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 F3EFC3A0829; Fri, 5 Jun 2020 09:29:47 -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, FREEMAIL_FROM=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 3us0VMTq9dm4; Fri, 5 Jun 2020 09:29:46 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 87FCD3A081B; Fri, 5 Jun 2020 09:29:46 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id j10so10374901wrw.8; Fri, 05 Jun 2020 09:29:46 -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=U9hWm/YTjCmJ+CnMZMf6a8Pki+iiuMWSpn2AK51FAbU=; b=Zq6GJPux4k7myhXyFg50KYWAECDnngcjiNdCWqwLR3wA5VYWwjaPgbczpUTGFLOat3 dXacb8IGXI5BO1NlT0Bg+klWw1TSzq3mq0y+yYH1VgsxRSjlXbo86/joXZaoBe2cLAK0 j/ipxHZboV4QKQAxmwSowp2F0IC3uDzZmr0F9KuD3rRKwgYaOmRxy+sd2FIdEt30kIuW 7QVSKC0vmSDxv0NzvkHLp2EADjRZe4U6azhfHiKMoU46ybOBNpb1u4hXyZb7UjVGMd16 WFDyjUQGxoeTB+UlTAVPvrVvl0V0+2uKOyUuH/p2HdRn1FberfK27HL0kUSSRB2x91p4 3Eqg== 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=U9hWm/YTjCmJ+CnMZMf6a8Pki+iiuMWSpn2AK51FAbU=; b=DtvblT6BozZV6o4DlZI94UYwGK+XMH2iNXBn70v8/oAmx0P3iVuJg/hVQ7SKa6Vbci gL1tVyzqjNHgwdRkqifDC8AmG7EGIIgkDvNudZEW8tPZTP6U1+B9xvdRgu+JqA1ETGnE bE383vc0jNTe6R0Vn0SobEVg5LCz1piyuyIX4oAgxvs9YyfU3HpWEsbq1XOAMfw3uMVC xzv+GKo5rSoA5oxPX2Et8Wx5J1ZwI4XWDpyrzDqF1tvnwcVygm4mEuz2bR9YY7F1H+3N f1ssSVuYLCmocyWFgoziJe7OqinmCOnJIyDs1jJ8A2zyL8GREpddBFWVUxIxRJOcPBQJ Cbbw== X-Gm-Message-State: AOAM532GR6c0VDZsJSney5SU5vPFeXBqa/9+3UPYUZDBeE+NMRKVkohw v+WFJZf7yxCoo5PkTMtqs8Y= X-Google-Smtp-Source: ABdhPJy1B7flHKeQesAir+SgNysaBxrhpoXo4kThEy1pqYO1xM4465bL13i42rJoQ+xofWs0qXy6qg== X-Received: by 2002:a05:6000:d:: with SMTP id h13mr10090077wrx.17.1591374584896; Fri, 05 Jun 2020 09:29:44 -0700 (PDT) Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id h18sm12399821wru.7.2020.06.05.09.29.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 09:29:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Stewart Bryant In-Reply-To: <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> Date: Fri, 5 Jun 2020 17:29:13 +0100 Cc: Stewart Bryant , tom petch , Last Call , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <12B81224-2A95-48F7-8365-636C0A0E7A4D@gmail.com> References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> To: Mark Allman X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (Requirements for Time-Based Loss Detection) to Best Current Practice 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, 05 Jun 2020 16:29:48 -0000 > On 5 Jun 2020, at 17:16, Mark Allman wrote: >=20 >=20 >> Mark, that is what I am questioning, >=20 > well ... >=20 >> that by default loss implies congestion. Historically true for >> the IETF but I think that there are a growing number of cases >> where it is not true as in a post I saw on another WG list this >> week where a document was saying that loss MUST NOT be taken as an >> indication of congestion so the MUST in this I-D I find too >> strong. >=20 > OK. So, I am not sure what to do here. I will say several things ... >=20 > (1) I believe that as a general, default the document is quite right > in specifying a congestion response and exponential backoff. >=20 > (2) I believe consensus of the WGs has been the same as my notion in > (1) for some time now. So, even setting aside (1), I am not > sure I feel like I have carte blanche to change this. >=20 > (3) I do not believe loss always means congestion and I do not > believe assuming such is always correct or should always be > done. I don't think I know anyone who thinks that. So, the > document explicitly says that is fine, just go get consensus > that some other approach is fine. (And, that should be > happening regardless of this document, so I am not sure what the > big deal is here.) >=20 > So, basically, I am not sure what to do here. Maybe one of the ADs > can help. Or, maybe we can set this aside and I can do the things I > told you I'd do and a little extra framing will make this better. I > am all ears for advice here. >=20 > (BTW, I have a half response to Stewart, as well. I am not ignoring > his review. I am just behind.) >=20 > allman > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call A good example of congestion free transient loss is a link failure = repaired 50ms later by FRR. - Stewart From nobody Fri Jun 5 09:44:14 2020 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 B50A93A093C for ; Fri, 5 Jun 2020 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NlKknHLvzHzA for ; Fri, 5 Jun 2020 09:44:00 -0700 (PDT) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 399633A08F9 for ; Fri, 5 Jun 2020 09:43:55 -0700 (PDT) Received: by mail-qk1-f182.google.com with SMTP id s1so10296108qkf.9 for ; Fri, 05 Jun 2020 09:43:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=0jIv31Y1zSFQcB7iH4s3wrmImxYD2/yRQmqClp9+izI=; b=ZX5gvYSPhan0uEQrlHdFZSxYAcyCILJlgu8dlZ/Man1maaqFk6Yo8HmljA46Sgc7as 7AT+fFVEAbiwQyOSqj1krcSvAH68115XDhJSfkC9PhYTlQ8BDb1fNeFkXYsjrctNtWPi /tb69mhRVIH0wdERRiSrCki++AGIpkXfFCqv1xKHVGnXeOubvtoZ96imeialoqXZAn8T 8yFxdcYHuHAq+OLRVVSxn0PzYqduSAGkrGgCePSrayntIT+lcK7eUPukUTFn32Bj2JSo +elwUj/cgULodRGmvuJtAcCTTgY1GYKTenU6seInflD8/EQMrtlB5l5LZZtF/XTHkDyt ZWgQ== X-Gm-Message-State: AOAM530Xc/BGyOF71SgiNZp3+AQRL40LESJdC05+UzfCKPDqdgLxRFHv gNvcx4xCX2xCwSefEvzConFH3GAptf0= X-Google-Smtp-Source: ABdhPJz50aatNCzu1qNzKRE70fFoZ5CUhOUycrDXPlEK0OT4sQ8RC3vO3/flXmz5HS/Yn8mBbfJbEA== X-Received: by 2002:a37:aa44:: with SMTP id t65mr10890625qke.81.1591375433837; Fri, 05 Jun 2020 09:43:53 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:64f0:807:946d:504b]) by smtp.gmail.com with ESMTPSA id x205sm243513qka.12.2020.06.05.09.43.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 09:43:52 -0700 (PDT) From: "Mark Allman" To: "Stewart Bryant" Cc: gen-art@ietf.org, tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org Date: Fri, 05 Jun 2020 12:43:50 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <159083802039.5596.14695350463305243689@ietfa.amsl.com> References: <159083802039.5596.14695350463305243689@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_FFE56152-B5DB-4BC4-A398-62E31465C5AF_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14 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, 05 Jun 2020 16:44:09 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_FFE56152-B5DB-4BC4-A398-62E31465C5AF_= Content-Type: text/plain Hi Stewart! Thanks for the feedback. Sorry for the long RTT. I had a recent deadline and am now trying to dig out. > Major issues: > > As far as I can see this text only applies to exchanges between > applications and network support applications such as > DNS. I.e. this is targeted at layer 4 and above. Given the > religious nature of BCPs in the eyes of some reviewers, and to > prevent endless explanations by those that design routing > protocols, OAM and other lower layer sub-system I think there > needs to a scoping text in block capitals at the at the very start > of the documnet. I am not entirely sure what you're suggesting here. Per note to Tom, I am going to add a few words to the intro. Maybe that will help. I think it's unlikely I'll use block capitals! :-) > ========= > > - The requirements in this document may not be appropriate in all > cases and, therefore, inconsistent deviations may be necessary > (hence the "SHOULD" in the last bullet). However, > inconsistencies MUST be (a) explained and (b) gather consensus. > > SB> That can be quite an onerous obligation and provide scope for > SB> endless argument when reviewers are not domain experts in the > SB> protocol being designed. This was added because another reviewer thought it was for sure necessary. I guess I don't understand why you'd call this 'an onerous obligation' since presumably you'd do it anyway without this document. Are we ramming things through without consensus? If not (my assumption), (b) is no sweat. Are we ramming things through without thought? If not (my assumption), (a) is straightforward and hopefully is being done anyway. In other words, I don't understand the complaint here because if you don't want to use the guidelines then that is fine, but in going through the standard process to define a loss detector you'll end up meeting this bullet. Even if this document doesn't get published or didn't exist our documents should still be meeting this bullet. > ======= > > While there are a bevy of uses for timers in protocols---from > rate-based pacing to connection failure detection and > beyond---these are outside the scope of this document. > > SB> I am not sure what that means for the applicability of this > SB> document. This was added at some point along the way because someone thought something like rate-based pacing could be covered by the guidelines and the intent is to say it is not. I have zero love for this bit and would happily remove it, but am loathe to do so because the old comment will then come back. > ========= > > (1) As we note above, loss detection happens when a sender does not > receive delivery confirmation within an some expected period of > time. In the absence of any knowledge about the latency of a > path, the initial RTO MUST be conservatively set to no less than > 1 second. > > SB> This issue may be addressed by the scoping text, but 1s is no > SB> use when you are trying to detect sub 50ms of packet loss in > SB> the infrastructure. We have to start somewhere when we know nothing. I think in my thread with Tom we hit upon this notion that the document is really about sort of arbitrary, unknown and therefore presumed unreliable networks. I am going to add some words to this effect. Does this help? Again, for specific environments where things are more nailed down and known, deviations are fine and explicitly OK. But, as a general default I think saying "when you don't know anything < 50msec is cool" is unlikely to be appropriate. Well, no, I think it would be quite inappropriate, actually. > ============= > > (3) Each time the RTO is used to detect a loss, the value of the RTO > MUST be exponentially backed off such that the next firing > requires a longer interval. The backoff SHOULD be removed after > either (a) the subsequent successful transmission of > non-retransmitted data, or (b) an RTO passes without detecting > additional losses. The former will generally be quicker. The > latter covers cases where loss is detected, but not repaired. > > A maximum value MAY be placed on the RTO. The maximum RTO MUST > NOT be less than 60 seconds (as specified in [RFC6298]). > > This ensures network safety. > > SB> This does not work in OAM applications. Well, OK, get consensus to do something different---which is completely fine. I think retransmission timers have shown themselves to be crucial for preventing collapse and, again, as a default I think this is our best advice. > Minor issues: > > "By waiting long enough that we are unambiguously > certain a packet has been lost we cannot repair losses in a timely > manner and we risk prolonging network congestion." > > I have a concern here that the emphasis is on classical > operation. We are beginning to see application to run over the > network where the timely delivery of a packet is critical for > correct operation of even SoL. As a BCP the text needs to > recognise that the scope and purpose of IP is changing and that > classical learning and rules derived from them may not apply. > > Also if not ruled out of scope earlier we need to be clear at this > point that things like BFD have different considerations. I am going to suggest we revisit this after I hack out a little extra text for the intro. You can see if that helps. > ========== > > "- This document does not update or obsolete any existing RFC. > These previous specifications---while generally consistent with > the requirements in this document---reflect community consensus > and this document does not change that consensus." > > I think it needs to be clear that adherence to this RFC is not > required for minor updates and extensions to existing RFCs. Having > seen minor routing extension held up by security concerns related > to underlying protocols rather than the extension itself there is > a lot of sensitivity on this point in some quarters of the IETF. Um. Do you have suggested words? I am not much of a protocol lawyers (thankfully!), but I am not really conjuring the case you're concerned about. Something like ... (1) RFC XXXX was published 10 years ago and violates rto-consider. (2) We want to do a XXXXbis. (3) The bis has to then explain why it's cool to violate rto-consider. ... ? I would say if XXXX has a loss detector that had consensus and has been in use for a while it'd be pretty easy to get consensus for XXXXbis that we can still use it as it has worked fine. > It might be useful to make it clear that there are some > applications that would prefer no data to late data. This document is about loss detection, not what one does after detecting. So, we do say ... However, as discussed above, the detected loss need not be repaired I am happy to re-enforce this point. Text suggestions welcome. > Nits/editorial comments: > > The terminology section confuses ID-nits - I think it should be a > section in its own right later in the document. Yeah- id-nits as it is run when submitting doesn't flag this. It was flagged by someone else in LC. Because I am old school it's hard to renumber everything and so I was just leaving this for the rfc-ed to do something reasonable here. > The following nits issues need looking at > > == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined > > == Unused Reference: 'RFC3940' is defined on line 515, but no explicit > reference was found in the text > > == Unused Reference: 'RFC4340' is defined on line 519, but no explicit > reference was found in the text > > == Unused Reference: 'RFC6582' is defined on line 540, but no explicit > reference was found in the text I will fix all these. Again, I was trusting the id-nits when I submitted and these were not flagged (or, if they were it wasn't in a way that foisted them on my screen). But, they're easy fixes, so thanks! allman --=_MailMate_FFE56152-B5DB-4BC4-A398-62E31465C5AF_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXtp2RhEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizrccAKCEe6WVpgF568sSyQXVSUee/OMchgCgneAT 3jDl7ZJQSxrk2Qc7g3zz0Jg= =YU4b -----END PGP SIGNATURE----- --=_MailMate_FFE56152-B5DB-4BC4-A398-62E31465C5AF_=-- From nobody Sat Jun 6 00:20:16 2020 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 D8DEF3A0EBB; Sat, 6 Jun 2020 00:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9K7Tr7Zb9lm; Sat, 6 Jun 2020 00:20:02 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 08B8F3A0EBA; Sat, 6 Jun 2020 00:20:01 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 573A91B00108; Sat, 6 Jun 2020 08:19:53 +0100 (BST) To: Mark Allman , Stewart Bryant Cc: last-call@ietf.org, gen-art@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org References: <159083802039.5596.14695350463305243689@ietfa.amsl.com> From: Gorry Fairhurst Message-ID: <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk> Date: Sat, 6 Jun 2020 08:19:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8058336F3CF8F9E288A30121" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14 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: Sat, 06 Jun 2020 07:20:06 -0000 This is a multi-part message in MIME format. --------------8058336F3CF8F9E288A30121 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Please see below. On 05/06/2020 17:43, Mark Allman wrote: > Hi Stewart! > > Thanks for the feedback. Sorry for the long RTT. I had a recent > deadline and am now trying to dig out. > >> Major issues: >> >> As far as I can see this text only applies to exchanges between >> applications and network support applications such as >> DNS. I.e. this is targeted at layer 4 and above. Given the >> religious nature of BCPs in the eyes of some reviewers, and to >> prevent endless explanations by those that design routing >> protocols, OAM and other lower layer sub-system I think there >> needs to a scoping text in block capitals at the at the very start >> of the documnet. > I am not entirely sure what you're suggesting here. Per note to > Tom, I am going to add a few words to the intro. Maybe that will > help. I think it's unlikely I'll use block capitals! :-) > >> ========= >> >> - The requirements in this document may not be appropriate in all >> cases and, therefore, inconsistent deviations may be necessary >> (hence the "SHOULD" in the last bullet). However, >> inconsistencies MUST be (a) explained and (b) gather consensus. >> >> SB> That can be quite an onerous obligation and provide scope for >> SB> endless argument when reviewers are not domain experts in the >> SB> protocol being designed. > This was added because another reviewer thought it was for sure > necessary. > > I guess I don't understand why you'd call this 'an onerous > obligation' since presumably you'd do it anyway without this > document. Are we ramming things through without consensus? If not > (my assumption), (b) is no sweat. Are we ramming things through > without thought? If not (my assumption), (a) is straightforward and > hopefully is being done anyway. In other words, I don't understand > the complaint here because if you don't want to use the guidelines > then that is fine, but in going through the standard process to > define a loss detector you'll end up meeting this bullet. Even if > this document doesn't get published or didn't exist our documents > should still be meeting this bullet. > >> ======= >> >> While there are a bevy of uses for timers in protocols---from >> rate-based pacing to connection failure detection and >> beyond---these are outside the scope of this document. >> >> SB> I am not sure what that means for the applicability of this >> SB> document. > This was added at some point along the way because someone thought > something like rate-based pacing could be covered by the guidelines > and the intent is to say it is not. I have zero love for this bit > and would happily remove it, but am loathe to do so because the old > comment will then come back. I think Mark is correct, there are many transport uses of timers, and calling out a small number of other uses was important to scope this withing the transport discussions, even if it just says "timers also do other stuff". >> ========= >> >> (1) As we note above, loss detection happens when a sender does not >> receive delivery confirmation within an some expected period of >> time. In the absence of any knowledge about the latency of a >> path, the initial RTO MUST be conservatively set to no less than >> 1 second. >> >> SB> This issue may be addressed by the scoping text, but 1s is no >> SB> use when you are trying to detect sub 50ms of packet loss in >> SB> the infrastructure. > We have to start somewhere when we know nothing. > > I think in my thread with Tom we hit upon this notion that the > document is really about sort of arbitrary, unknown and therefore > presumed unreliable networks. I am going to add some words to this > effect. Does this help? > > Again, for specific environments where things are more nailed down > and known, deviations are fine and explicitly OK. But, as a general > default I think saying "when you don't know anything < 50msec is > cool" is unlikely to be appropriate. Well, no, I think it would be > quite inappropriate, actually. This is I think a natural discussion based on a different perspective. The 1 second initial starting value for a transport path has been there for a long time, and transport reviewers will frequently quote this be it for transport:  SCTP, TCP, or for UDP-based apps (BCP: 145 Sect 3.1.1). I'd expect this is about the assumed starting position for an Internet path. True if we're talking about a link between adjacent peers, this is something very different. >> ============= >> >> (3) Each time the RTO is used to detect a loss, the value of the RTO >> MUST be exponentially backed off such that the next firing >> requires a longer interval. The backoff SHOULD be removed after >> either (a) the subsequent successful transmission of >> non-retransmitted data, or (b) an RTO passes without detecting >> additional losses. The former will generally be quicker. The >> latter covers cases where loss is detected, but not repaired. >> >> A maximum value MAY be placed on the RTO. The maximum RTO MUST >> NOT be less than 60 seconds (as specified in [RFC6298]). >> >> This ensures network safety. >> >> SB> This does not work in OAM applications. > Well, OK, get consensus to do something different---which is > completely fine. I think retransmission timers have shown > themselves to be crucial for preventing collapse and, again, as a > default I think this is our best advice. > It should be applicable for OAM applications that use a path across the Internet that can change, and certainly could be bad advice for controlled environment. It's actually not new, BCP: 145 also speaks of backoff. >> Minor issues: >> >> "By waiting long enough that we are unambiguously >> certain a packet has been lost we cannot repair losses in a timely >> manner and we risk prolonging network congestion." >> >> I have a concern here that the emphasis is on classical >> operation. We are beginning to see application to run over the >> network where the timely delivery of a packet is critical for >> correct operation of even SoL. As a BCP the text needs to >> recognise that the scope and purpose of IP is changing and that >> classical learning and rules derived from them may not apply. >> >> Also if not ruled out of scope earlier we need to be clear at this >> point that things like BFD have different considerations. Isn't BFD is a link protocol between adjacent systems? > I am going to suggest we revisit this after I hack out a little > extra text for the intro. You can see if that helps. > >> ========== >> >> "- This document does not update or obsolete any existing RFC. >> These previous specifications---while generally consistent with >> the requirements in this document---reflect community consensus >> and this document does not change that consensus." >> >> I think it needs to be clear that adherence to this RFC is not >> required for minor updates and extensions to existing RFCs. Having >> seen minor routing extension held up by security concerns related >> to underlying protocols rather than the extension itself there is >> a lot of sensitivity on this point in some quarters of the IETF. > Um. Do you have suggested words? I am not much of a protocol > lawyers (thankfully!), but I am not really conjuring the case you're > concerned about. Something like ... > > (1) RFC XXXX was published 10 years ago and violates > rto-consider. > (2) We want to do a XXXXbis. > (3) The bis has to then explain why it's cool to violate > rto-consider. > > .... ? > > I would say if XXXX has a loss detector that had consensus and has > been in use for a while it'd be pretty easy to get consensus for > XXXXbis that we can still use it as it has worked fine. > >> It might be useful to make it clear that there are some >> applications that would prefer no data to late data. > This document is about loss detection, not what one does after > detecting. So, we do say ... > > However, as discussed above, the detected loss need not be > repaired > > I am happy to re-enforce this point. Text suggestions welcome. > >> Nits/editorial comments: >> >> The terminology section confuses ID-nits - I think it should be a >> section in its own right later in the document. > Yeah- id-nits as it is run when submitting doesn't flag this. It > was flagged by someone else in LC. Because I am old school it's > hard to renumber everything and so I was just leaving this for the > rfc-ed to do something reasonable here. > >> The following nits issues need looking at >> >> == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined >> >> == Unused Reference: 'RFC3940' is defined on line 515, but no explicit >> reference was found in the text >> >> == Unused Reference: 'RFC4340' is defined on line 519, but no explicit >> reference was found in the text >> >> == Unused Reference: 'RFC6582' is defined on line 540, but no explicit >> reference was found in the text > I will fix all these. Again, I was trusting the id-nits when I > submitted and these were not flagged (or, if they were it wasn't in > a way that foisted them on my screen). But, they're easy fixes, so > thanks! > > allman > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------8058336F3CF8F9E288A30121 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Please see below.

On 05/06/2020 17:43, Mark Allman wrote:
Hi Stewart!

Thanks for the feedback.  Sorry for the long RTT.  I had a recent
deadline and am now trying to dig out.


Major issues:

As far as I can see this text only applies to exchanges between
applications and network support applications such as
DNS. I.e. this is targeted at layer 4 and above. Given the
religious nature of BCPs in the eyes of some reviewers, and to
prevent endless explanations by those that design routing
protocols, OAM and other lower layer sub-system I think there
needs to a scoping text in block capitals at the at the very start
of the documnet.

I am not entirely sure what you're suggesting here.  Per note to
Tom, I am going to add a few words to the intro.  Maybe that will
help.  I think it's unlikely I'll use block capitals! :-)


=========

      - The requirements in this document may not be appropriate in all
        cases and, therefore, inconsistent deviations may be necessary
        (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather consensus.

SB> That can be quite an onerous obligation  and provide scope for
SB> endless argument when reviewers are not domain experts in the
SB> protocol being designed.

This was added because another reviewer thought it was for sure
necessary.

I guess I don't understand why you'd call this 'an onerous
obligation' since presumably you'd do it anyway without this
document.  Are we ramming things through without consensus?  If not
(my assumption), (b) is no sweat.  Are we ramming things through
without thought?  If not (my assumption), (a) is straightforward and
hopefully is being done anyway.  In other words, I don't understand
the complaint here because if you don't want to use the guidelines
then that is fine, but in going through the standard process to
define a loss detector you'll end up meeting this bullet.  Even if
this document doesn't get published or didn't exist our documents
should still be meeting this bullet.


=======

          While there are a bevy of uses for timers in protocols---from
          rate-based pacing to connection failure detection and
          beyond---these are outside the scope of this document.

SB> I am not sure what that means for the applicability of this
SB> document.

This was added at some point along the way because someone thought
something like rate-based pacing could be covered by the guidelines
and the intent is to say it is not.  I have zero love for this bit
and would happily remove it, but am loathe to do so because the old
comment will then come back.
I think Mark is correct, there are many transport uses of timers, and calling out a small number of other uses was important to scope this withing the transport discussions, even if it just says "timers also do other stuff".

      

        
=========

    (1) As we note above, loss detection happens when a sender does not
        receive delivery confirmation within an some expected period of
        time.  In the absence of any knowledge about the latency of a
        path, the initial RTO MUST be conservatively set to no less than
        1 second.

SB> This issue may be addressed by the scoping text, but 1s is no
SB> use when you are trying to detect sub 50ms of packet loss in
SB> the infrastructure.


      

      
We have to start somewhere when we know nothing.

I think in my thread with Tom we hit upon this notion that the
document is really about sort of arbitrary, unknown and therefore
presumed unreliable networks.  I am going to add some words to this
effect.  Does this help?

Again, for specific environments where things are more nailed down
and known, deviations are fine and explicitly OK.  But, as a general
default I think saying "when you don't know anything < 50msec is
cool" is unlikely to be appropriate.  Well, no, I think it would be
quite inappropriate, actually.


    

    
This is I think a natural discussion based on a different
      perspective. The 1 second initial starting value for a transport
      path has been there for a long time, and transport reviewers will
      frequently quote this be it for transport:  SCTP, TCP, or for
      UDP-based apps (BCP: 145 Sect 3.1.1). I'd expect this is about the
      assumed starting position for an Internet path.

    
True if we're talking about a link between adjacent peers, this
      is something very different. 

    

    

      

      

        
=============

    (3) Each time the RTO is used to detect a loss, the value of the RTO
        MUST be exponentially backed off such that the next firing
        requires a longer interval.  The backoff SHOULD be removed after
        either (a) the subsequent successful transmission of
        non-retransmitted data, or (b) an RTO passes without detecting
        additional losses.  The former will generally be quicker.  The
        latter covers cases where loss is detected, but not repaired.

        A maximum value MAY be placed on the RTO.  The maximum RTO MUST
        NOT be less than 60 seconds (as specified in [RFC6298]).

        This ensures network safety.

SB> This does not work in OAM applications.


      

      
Well, OK, get consensus to do something different---which is
completely fine.  I think retransmission timers have shown
themselves to be crucial for preventing collapse and, again, as a
default I think this is our best advice.



    

    It should be applicable for OAM applications that use a path across
    the Internet that can change, and certainly could be bad advice for
    controlled environment. It's actually not new, BCP: 145 also speaks
    of backoff.
    

      

        
Minor issues:

 "By waiting long enough that we are unambiguously
  certain a packet has been lost we cannot repair losses in a timely
  manner and we risk prolonging network congestion."

I have a concern here that the emphasis is on classical
operation. We are beginning to see application to run over the
network where the timely delivery of a packet is critical for
correct operation of even SoL. As a BCP the text needs to
recognise that the scope and purpose of IP is changing and that
classical learning and rules derived from them may not apply.

Also if not ruled out of scope earlier we need to be clear at this
point that things like BFD have different considerations.


      

    

    Isn't BFD is a link protocol between adjacent systems?

    

      
I am going to suggest we revisit this after I hack out a little
extra text for the intro.  You can see if that helps.



      

        
==========

      "- This document does not update or obsolete any existing RFC.
        These previous specifications---while generally consistent with
        the requirements in this document---reflect community consensus
        and this document does not change that consensus."

I think it needs to be clear that adherence to this RFC is not
required for minor updates and extensions to existing RFCs. Having
seen minor routing extension held up by security concerns related
to underlying protocols rather than the extension itself there is
a lot of sensitivity on this point in some quarters of the IETF.


      

      
Um.  Do you have suggested words?  I am not much of a protocol
lawyers (thankfully!), but I am not really conjuring the case you're
concerned about.  Something like ...

  (1) RFC XXXX was published 10 years ago and violates
      rto-consider.
  (2) We want to do a XXXXbis.
  (3) The bis has to then explain why it's cool to violate
      rto-consider.

.... ?

I would say if XXXX has a loss detector that had consensus and has
been in use for a while it'd be pretty easy to get consensus for
XXXXbis that we can still use it as it has worked fine.



      

        
It might be useful to make it clear that there are some
applications that would prefer no data to late data.


      

      
This document is about loss detection, not what one does after
detecting.  So, we do say ...

    However, as discussed above, the detected loss need not be
    repaired

I am happy to re-enforce this point.  Text suggestions welcome.



      

        
Nits/editorial comments:

The terminology section confuses ID-nits - I think it should be a
section in its own right later in the document.


      

      
Yeah- id-nits as it is run when submitting doesn't flag this.  It
was flagged by someone else in LC.  Because I am old school it's
hard to renumber everything and so I was just leaving this for the
rfc-ed to do something reasonable here.



      

        
The following nits issues need looking at

  == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined

  == Unused Reference: 'RFC3940' is defined on line 515, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4340' is defined on line 519, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6582' is defined on line 540, but no explicit
     reference was found in the text


      

      
I will fix all these.  Again, I was trusting the id-nits when I
submitted and these were not flagged (or, if they were it wasn't in
a way that foisted them on my screen).  But, they're easy fixes, so
thanks!

allman


      

      

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


    

  


--------------8058336F3CF8F9E288A30121--


From nobody Sun Jun  7 10:11:59 2020
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 065653A0A69; Sun,  7 Jun 2020 10:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 icCcqroJtYvr; Sun,  7 Jun 2020 10:11:48 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0BE173A0A49; Sun,  7 Jun 2020 10:11:47 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 057HBamr018834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Jun 2020 13:11:39 -0400
Date: Sun, 7 Jun 2020 10:11:36 -0700
From: Benjamin Kaduk 
To: Gorry Fairhurst 
Cc: Mark Allman , Stewart Bryant ,  last-call@ietf.org, gen-art@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
Message-ID: <20200607171136.GT58497@mit.edu>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 07 Jun 2020 17:11:50 -0000

On Sat, Jun 06, 2020 at 08:19:52AM +0100, Gorry Fairhurst wrote:
> Please see below.
> 
> On 05/06/2020 17:43, Mark Allman wrote:
> >> =============
> >>
> >>      (3) Each time the RTO is used to detect a loss, the value of the RTO
> >>          MUST be exponentially backed off such that the next firing
> >>          requires a longer interval.  The backoff SHOULD be removed after
> >>          either (a) the subsequent successful transmission of
> >>          non-retransmitted data, or (b) an RTO passes without detecting
> >>          additional losses.  The former will generally be quicker.  The
> >>          latter covers cases where loss is detected, but not repaired.
> >>
> >>          A maximum value MAY be placed on the RTO.  The maximum RTO MUST
> >>          NOT be less than 60 seconds (as specified in [RFC6298]).
> >>
> >>          This ensures network safety.
> >>
> >> SB> This does not work in OAM applications.
> > Well, OK, get consensus to do something different---which is
> > completely fine.  I think retransmission timers have shown
> > themselves to be crucial for preventing collapse and, again, as a
> > default I think this is our best advice.
> >
> It should be applicable for OAM applications that use a path across the 
> Internet that can change, and certainly could be bad advice for 
> controlled environment. It's actually not new, BCP: 145 also speaks of 
> backoff.
> >> Minor issues:
> >>
> >>   "By waiting long enough that we are unambiguously
> >>    certain a packet has been lost we cannot repair losses in a timely
> >>    manner and we risk prolonging network congestion."
> >>
> >> I have a concern here that the emphasis is on classical
> >> operation. We are beginning to see application to run over the
> >> network where the timely delivery of a packet is critical for
> >> correct operation of even SoL. As a BCP the text needs to
> >> recognise that the scope and purpose of IP is changing and that
> >> classical learning and rules derived from them may not apply.
> >>
> >> Also if not ruled out of scope earlier we need to be clear at this
> >> point that things like BFD have different considerations.
> Isn't BFD is a link protocol between adjacent systems?

Well, your "link" can be a virtual (tunnel) link that traverses paths that
share traffic with non-local traffic, e.g., as in draft-ietf-bfd-vxlan.

-Ben


From nobody Sun Jun  7 13:52:24 2020
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 B15D13A0958 for ; Sun,  7 Jun 2020 13:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=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 aY3K2mlvqMt4 for ; Sun,  7 Jun 2020 13:52:21 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 47BA63A0957 for ; Sun,  7 Jun 2020 13:52:21 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AuMMxemxD5X2r/kyJfChwdSQ71R4RU740QxZ69oDEUA=; b=3MJYSyAK9ePaV2L2s2PXT63n7 FEeiH4A8ZOYFEB5eAV1GkanmGmeuRyMXLwWEm7sUtPkcEHOd95zL3twShr6bfan0r5XAUL7o6G9c2 D9b1ldxcdLyWSXvKAW3aryh/MP/Yb3mmG1XhgslSAacJixXWMYMJ6rQLfcLYMLEE1GFctaWE9jHSP YEMiguXiEjbQsZOd40q4WgpBen4UcLQAJlxWEc4uDOVd/7DLAgJ61Idi+xO0TCiDNWQaiH253C7qN 6X2LL4aLoCZ1Js04QeZ+S/zrGtHqVDATpbjUEj/q617ixJkhtrzxpOJ/t4gPqTNX66fn6rTrLtPgM 4ZbIQVMQA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55173 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ji2H9-002drY-P8; Sun, 07 Jun 2020 16:52:20 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_0CA7E397-E586-4B0A-BBBD-2D8B0E0557DE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Sun, 7 Jun 2020 13:52:15 -0700
Cc: "juhamatk@gmail.com" , "tcpm@ietf.org" 
Message-Id: 
References:    <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] Test vectors for RFC5925 algorithms?
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, 07 Jun 2020 20:52:23 -0000

--Apple-Mail=_0CA7E397-E586-4B0A-BBBD-2D8B0E0557DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Michael,

The link below doesn=E2=80=99t appear to reference TCP-AO. Do you know =
of a link with a more direct reference?

Joe

> On Apr 16, 2020, at 9:31 AM, Scharf, Michael =
 wrote:
>=20
>>> Have you checked other router vendors? For instance, the public =
Cisco IOS XE
>> documentation lists TCP-AO support. And I have also heard that =
another main
>> router vendor may implement TCP-AO (well, I am not familiar with =
Juniper).
>>=20
>> I am aware that Cisco has an implementation. It is quite new, and
>> unfortunately I do have experience of it. If someone has, then that
>> may well be a very good candidate for test vectors.
>=20
> Coming back to this, as I have just found another document: According =
to reference [1], Nokia SROS implements TCP-AO as well.
>=20
> Michael
>=20
>=20
> [1] Nokia SROS documentation at =
https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE15811AAAAT=
QZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Basic%20System=
%20Configuration%20Guide%2020.2.R1.pdf =



--Apple-Mail=_0CA7E397-E586-4B0A-BBBD-2D8B0E0557DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, =
Michael,

The link =
below doesn=E2=80=99t appear to reference TCP-AO. Do you know of a link =
with a more direct reference?

Joe

On Apr =
16, 2020, at 9:31 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Have you checked other =
router vendors? For instance, the public Cisco IOS XE
documentation lists TCP-AO support. And I have =
also heard that another main
router vendor may implement =
TCP-AO (well, I am not familiar with Juniper).

I am aware that Cisco has an implementation. It is quite new, =
and
unfortunately I do have experience of it. If someone =
has, then that
may well be a very good candidate for test =
vectors.

Coming back to this, as I have just found another document: =
According to reference [1], Nokia SROS implements TCP-AO as =
well.

Michael


[1] Nokia SROS documentation at https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3H=
E15811AAAATQZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Bas=
ic%20System%20Configuration%20Guide%2020.2.R1.pdf

=

--Apple-Mail=_0CA7E397-E586-4B0A-BBBD-2D8B0E0557DE--


From nobody Mon Jun  8 00:21:43 2020
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 CB3AF3A0912 for ; Mon,  8 Jun 2020 00:21:41 -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, HTML_MESSAGE=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 3rPoL0hzd9Nc for ; Mon,  8 Jun 2020 00:21:40 -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 CB5FA3A090D for ; Mon,  8 Jun 2020 00:21:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B69B825A1C; Mon,  8 Jun 2020 09:21:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1591600897; bh=htK8E2IwXQ0wukELncf+TtqxKJ9vZG5nM+V+kkT4HIc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=TDmI3hzWmN75EGF5i0PIBr6Shm7htYQgIYj2epaozIZlnWLe1X8M87YE6W1qGtdxY m6/vXvK6V/SBAt4UzB/LRc2ypWWhqRt8F45sTvLrb5m/tgxsKdORXEmI5X/KamfzR2 4PPpsBbIr20ruLaQ2tXCifpmpxpRMGle+OAqqNTk=
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 9mivtyZu0c_7; Mon,  8 Jun 2020 09:21:35 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon,  8 Jun 2020 09:21:35 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 8 Jun 2020 09:21:35 +0200
From: "Scharf, Michael" 
To: Joseph Touch 
CC: "juhamatk@gmail.com" , "tcpm@ietf.org" 
Thread-Topic: [tcpm] Test vectors for RFC5925 algorithms?
Thread-Index: AQHWB0lfUk5cDvT0M0+o4ytgvsbwRKhi6ecAgADUtQCAACc4sIABaoiAgBa48iCAUeGkgIAAz7LA
Date: Mon, 8 Jun 2020 07:21:34 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC3B40E@rznt8114.rznt.rzdir.fht-esslingen.de>
References:    <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-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.48.165]
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DC3B40Erznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] Test vectors for RFC5925 algorithms?
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, 08 Jun 2020 07:21:42 -0000

--_000_6EC6417807D9754DA64F3087E2E2E03E2DC3B40Erznt8114rzntrzd_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSm9lLA0KDQpQYWdlIDcwMCBvZiBsaW5rIFsxXSByZWZlcmVuY2VzIFJGQyA1OTI1IGFuZCBS
RkMgNTkyNi4NCg0KSSBkb27igJl0IGhhdmUgYWNjZXNzIHRvIGEgTm9raWEgcm91dGVyIHRvIGFj
dHVhbGx5IHRlc3QgdGhlIGltcGxlbWVudGF0aW9uLiBZZXQsIGFzIGZhciBhcyBJIGtub3csIGxp
c3RpbmcgYW4gUkZDIGluIHRoZSBzdGFuZGFyZCBjb21wbGlhbmNlIGxpc3RzIG9mIGEgTm9raWEg
cHJvZHVjdCBpbXBsaWVzIHRoYXQgdGhlIHN0YW5kYXJkIGlzIGluZGVlZCBpbXBsZW1lbnRlZC4N
Cg0KTWljaGFlbA0KDQpGcm9tOiBKb3NlcGggVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPg0K
U2VudDogU3VuZGF5LCBKdW5lIDcsIDIwMjAgMTA6NTIgUE0NClRvOiBTY2hhcmYsIE1pY2hhZWwg
PE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT4NCkNjOiBqdWhhbWF0a0BnbWFpbC5jb207
IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gVGVzdCB2ZWN0b3JzIGZvciBSRkM1
OTI1IGFsZ29yaXRobXM/DQoNCkhpLCBNaWNoYWVsLA0KDQpUaGUgbGluayBiZWxvdyBkb2VzbuKA
mXQgYXBwZWFyIHRvIHJlZmVyZW5jZSBUQ1AtQU8uIERvIHlvdSBrbm93IG9mIGEgbGluayB3aXRo
IGEgbW9yZSBkaXJlY3QgcmVmZXJlbmNlPw0KDQpKb2UNCg0KDQpPbiBBcHIgMTYsIDIwMjAsIGF0
IDk6MzEgQU0sIFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRl
PG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+PiB3cm90ZToNCg0KSGF2ZSB5
b3UgY2hlY2tlZCBvdGhlciByb3V0ZXIgdmVuZG9ycz8gRm9yIGluc3RhbmNlLCB0aGUgcHVibGlj
IENpc2NvIElPUyBYRQ0KZG9jdW1lbnRhdGlvbiBsaXN0cyBUQ1AtQU8gc3VwcG9ydC4gQW5kIEkg
aGF2ZSBhbHNvIGhlYXJkIHRoYXQgYW5vdGhlciBtYWluDQpyb3V0ZXIgdmVuZG9yIG1heSBpbXBs
ZW1lbnQgVENQLUFPICh3ZWxsLCBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIEp1bmlwZXIpLg0KDQpJ
IGFtIGF3YXJlIHRoYXQgQ2lzY28gaGFzIGFuIGltcGxlbWVudGF0aW9uLiBJdCBpcyBxdWl0ZSBu
ZXcsIGFuZA0KdW5mb3J0dW5hdGVseSBJIGRvIGhhdmUgZXhwZXJpZW5jZSBvZiBpdC4gSWYgc29t
ZW9uZSBoYXMsIHRoZW4gdGhhdA0KbWF5IHdlbGwgYmUgYSB2ZXJ5IGdvb2QgY2FuZGlkYXRlIGZv
ciB0ZXN0IHZlY3RvcnMuDQoNCkNvbWluZyBiYWNrIHRvIHRoaXMsIGFzIEkgaGF2ZSBqdXN0IGZv
dW5kIGFub3RoZXIgZG9jdW1lbnQ6IEFjY29yZGluZyB0byByZWZlcmVuY2UgWzFdLCBOb2tpYSBT
Uk9TIGltcGxlbWVudHMgVENQLUFPIGFzIHdlbGwuDQoNCk1pY2hhZWwNCg0KDQpbMV0gTm9raWEg
U1JPUyBkb2N1bWVudGF0aW9uIGF0IGh0dHBzOi8vZG9jdW1lbnRhdGlvbi5ub2tpYS5jb20vY2dp
LWJpbi9kYmFjY2Vzc2ZpbGVuYW1lLmNnaS8zSEUxNTgxMUFBQUFUUVpaQTAxX1YxXzc0NTAlMjBF
U1MlMjA3NzUwJTIwU1IlMjA3OTUwJTIwWFJTJTIwYW5kJTIwVlNSJTIwQmFzaWMlMjBTeXN0ZW0l
MjBDb25maWd1cmF0aW9uJTIwR3VpZGUlMjAyMC4yLlIxLnBkZg0KDQo=

--_000_6EC6417807D9754DA64F3087E2E2E03E2DC3B40Erznt8114rzntrzd_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z
b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l
Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt
Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw
YW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRl
ZC1zcGFjZTt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw
dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgSm9lLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBhZ2UgNzAwIG9mIGxpbmsgWzFdIHJl
ZmVyZW5jZXMgUkZDIDU5MjUgYW5kIFJGQyA1OTI2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRvbuKAmXQgaGF2ZSBh
Y2Nlc3MgdG8gYSBOb2tpYSByb3V0ZXIgdG8gYWN0dWFsbHkgdGVzdCB0aGUgaW1wbGVtZW50YXRp
b24uIFlldCwgYXMgZmFyIGFzIEkga25vdywgbGlzdGluZyBhbiBSRkMgaW4gdGhlDQogc3RhbmRh
cmQgY29tcGxpYW5jZSBsaXN0cyBvZiBhIE5va2lhIHByb2R1Y3QgaW1wbGllcyB0aGF0IHRoZSBz
dGFuZGFyZCBpcyBpbmRlZWQgaW1wbGVtZW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pY2hhZWw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9zZXBoIFRvdWNoICZs
dDt0b3VjaEBzdHJheWFscGhhLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1
bmUgNywgMjAyMCAxMDo1MiBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsICZsdDtN
aWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBqdWhhbWF0
a0BnbWFpbC5jb207IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3Bt
XSBUZXN0IHZlY3RvcnMgZm9yIFJGQzU5MjUgYWxnb3JpdGhtcz88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgTWljaGFlbCw8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsaW5rIGJlbG93IGRvZXNu4oCZdCBh
cHBlYXIgdG8gcmVmZXJlbmNlIFRDUC1BTy4gRG8geW91IGtub3cgb2YgYSBsaW5rIHdpdGggYSBt
b3JlIGRpcmVjdCByZWZlcmVuY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gQXByIDE2LCAyMDIwLCBhdCA5OjMxIEFNLCBTY2hhcmYsIE1pY2hhZWwg
Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGUiPk1pY2hh
ZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGln
bjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGF2ZSB5b3UgY2hlY2tlZCBvdGhlciByb3V0
ZXIgdmVuZG9ycz8gRm9yIGluc3RhbmNlLCB0aGUgcHVibGljIENpc2NvIElPUyBYRTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPmRvY3VtZW50YXRpb24gbGlzdHMgVENQLUFPIHN1cHBvcnQuIEFuZCBJIGhh
dmUgYWxzbyBoZWFyZCB0aGF0IGFub3RoZXIgbWFpbjxicj4NCnJvdXRlciB2ZW5kb3IgbWF5IGlt
cGxlbWVudCBUQ1AtQU8gKHdlbGwsIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggSnVuaXBlcikuPGJy
Pg0KPGJyPg0KSSBhbSBhd2FyZSB0aGF0IENpc2NvIGhhcyBhbiBpbXBsZW1lbnRhdGlvbi4gSXQg
aXMgcXVpdGUgbmV3LCBhbmQ8YnI+DQp1bmZvcnR1bmF0ZWx5IEkgZG8gaGF2ZSBleHBlcmllbmNl
IG9mIGl0LiBJZiBzb21lb25lIGhhcywgdGhlbiB0aGF0PGJyPg0KbWF5IHdlbGwgYmUgYSB2ZXJ5
IGdvb2QgY2FuZGlkYXRlIGZvciB0ZXN0IHZlY3RvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy
Pg0KQ29taW5nIGJhY2sgdG8gdGhpcywgYXMgSSBoYXZlIGp1c3QgZm91bmQgYW5vdGhlciBkb2N1
bWVudDogQWNjb3JkaW5nIHRvIHJlZmVyZW5jZSBbMV0sIE5va2lhIFNST1MgaW1wbGVtZW50cyBU
Q1AtQU8gYXMgd2VsbC48YnI+DQo8YnI+DQpNaWNoYWVsPGJyPg0KPGJyPg0KPGJyPg0KWzFdIE5v
a2lhIFNST1MgZG9jdW1lbnRhdGlvbiBhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kb2N1bWVudGF0aW9uLm5v
a2lhLmNvbS9jZ2ktYmluL2RiYWNjZXNzZmlsZW5hbWUuY2dpLzNIRTE1ODExQUFBQVRRWlpBMDFf
VjFfNzQ1MCUyMEVTUyUyMDc3NTAlMjBTUiUyMDc5NTAlMjBYUlMlMjBhbmQlMjBWU1IlMjBCYXNp
YyUyMFN5c3RlbSUyMENvbmZpZ3VyYXRpb24lMjBHdWlkZSUyMDIwLjIuUjEucGRmIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5odHRwczovL2RvY3VtZW50YXRpb24ubm9raWEuY29tL2NnaS1iaW4vZGJhY2Nl
c3NmaWxlbmFtZS5jZ2kvM0hFMTU4MTFBQUFBVFFaWkEwMV9WMV83NDUwJTIwRVNTJTIwNzc1MCUy
MFNSJTIwNzk1MCUyMFhSUyUyMGFuZCUyMFZTUiUyMEJhc2ljJTIwU3lzdGVtJTIwQ29uZmlndXJh
dGlvbiUyMEd1aWRlJTIwMjAuMi5SMS5wZGY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_6EC6417807D9754DA64F3087E2E2E03E2DC3B40Erznt8114rzntrzd_--


From nobody Mon Jun  8 01:27:11 2020
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 C2EB33A09D7; Mon,  8 Jun 2020 01:27:04 -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 eilw1ebUQ3fd; Mon,  8 Jun 2020 01:27:03 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70128.outbound.protection.outlook.com [40.107.7.128]) (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 A07F93A09D5; Mon,  8 Jun 2020 01:27:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AWrg6ImjEz6pgGi1md6/0X0VNsWwcWTtPWgpvIB7xp2GLf6kUkaHFr4Fc5/pGkpWWzNPOUkj3u37Rz/zKZrvhhmpQ94mKbCHKwPRJLr/f+IJ2QNDx+s/zWYWcWgHcPGNSnUFtW+FbFE7KfGrB041WMwSX3+f5hQcDy7vylyROZnWEb8USnZzFP6CFL7OUSQJyza/liOgHD73kL6RdSQUp01y7YRqiEx2/+aysRuBIgexAQi12EI/z4qI3mNIZ9dB8mX+bXOQZ7zo070Spfr/huegLbCzHE5veEugg7fOjusO8IkHQS9+07AxVtM3Y5qeQdJ0HoCgYNBLdnqPPpGUSw==
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=gEEt7rT43BcAqrupCBN7eFfD7kZ3IPhZpSuWcB/MnJk=; b=S+jsBN/ZnMsshO3tFBTDQ2MBeNaHlJyjUpQJEGAzHdNM5U5yXTYvfL5HgGODolMgWv3hCfPr1yUFy9PPtuOOOtpPwrQ21DwyMzvGwk81SgRcaE6dh5NLRg33DrDucWbLHWzSFTBaC0JpIaHr3PwuzQZYVoGUqPb3WjBTqk0zYQuq77VuxBQtkEQnEyw/4gu6Uo3vVzkPaycSc0wlKABnOaYFzCy8yebBfTZpc4CEkwPouJJbGAmX/urKyv9uZXKuKZOBxQ6IQl6KBeJixBe3MUcSALcpFKKwrc0MhZ3J3Q0lVaJP+amAiC04mQv8Od2oQESiymUT7/CERj/U5NNIKA==
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=gEEt7rT43BcAqrupCBN7eFfD7kZ3IPhZpSuWcB/MnJk=; b=CdH1/61V2lKx1iVD4YXRq0oFmqXvISaYRcVegK9b379ITYE1g81yKmjYQoQuxnfvHaGMLLRQbOtvCn8y65vurNFyzfIh1CKE+QX1dntncdcUmQ4fVLuseKXXuK1q7sTPH0nTAEh1N2YWKd35rFHGpy8np1pVsF1VL590paEd5so=
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DBAPR07MB7015.eurprd07.prod.outlook.com (2603:10a6:10:196::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.11; Mon, 8 Jun 2020 08:26:59 +0000
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4%7]) with mapi id 15.20.3088.016; Mon, 8 Jun 2020 08:26:59 +0000
From: tom petch 
To: Mark Allman , tom petch 
CC: Last Call , tcpm , "draft-ietf-tcpm-rto-consider@ietf.org" , "tcpm-chairs@ietf.org" 
Thread-Topic: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
Thread-Index: AQHWNQ2m9gFeETvyo0Wr/I+Dg676t6i+70PggAAUpICAAX7IgIAJg2SAgAAyuICAAAaRgIAEMVRi
Date: Mon, 8 Jun 2020 08:26:59 +0000
Message-ID: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp>, <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>
In-Reply-To: <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e09de2d1-0f30-4c2e-b5ff-08d80b85b6cb
x-ms-traffictypediagnostic: DBAPR07MB7015:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: moJMy8ssBTw65YbKqOrO15EfZjB7F6pn12PQ6e4rDTymWRpralMHr86C/m9ktm/o5tdR9ONbrbkyA5zre+33QVLNe/bf3dvVS7t1UxGzPkKUkSHmgUj2nOEDexgJ2fjcy51ADMzSCVq4o2w5z+2DS2UC+jRqPNZbbfH8gXvWrf+UJueclhpn+RhxQUi0/UcgP9hW1/TnLr0JlPcEESb96jKnQJYnTFou9/InbgI1GSOQKC0CHVPNA3F/PETstwKDxsEJXLasxD4ib7gYIzbcq1z9McnTXksIrFNybMtFwcMGjZiWO2qKfVpCV52Ap0cFaPJ/rPAPj5t7VmmKGyEhtQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(136003)(366004)(39860400002)(396003)(346002)(8936002)(5660300002)(9686003)(26005)(4326008)(55016002)(478600001)(316002)(8676002)(186003)(6636002)(7696005)(91956017)(6506007)(86362001)(66946007)(54906003)(33656002)(76116006)(52536014)(64756008)(66556008)(66446008)(66476007)(66574014)(71200400001)(110136005)(2906002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: skBtAHFXjCzjEFJT2t3DxAVDDqZcdUgoEnKTGeNq7ljiQ9IVTj00AYRRnoP56CRdgbt4gG7VyEXUJxV1rINHBivCpBvOLECXS9t54lxygK8U/SqjdtoGi8yn4IsqG940Q1FFwl695b0VvrxPwFLicUWMcbB7MQklCYMM3XEfZP6lp4sQK6FSlaa9dHGZB9SlQNzMNFwkxKX2uXkkLEHT8zY0Mkxc//lvvC+UIAopl4w6OvsDEdbBAnV3xcOEStOreCoOAF8h/fbXCWSgDWrdKuFcINicZZmGkdT3TFIqdA0aBtl7vcA8T25KPYRQMdrVVr70+Kyc8i8kMp55lwYntOuzpyOYlI7xtvXteDYviCVgsZ33jlYNUTMw9QPQ7a1ZX4W33aTGKNOj7ejHQDm/uFZ+lLkX64h7Z2JrqgHlrVqz8qQurpQ+Vm17jV++m9I5FpdZjRdxc2ikTwUpCo4ygcNjUQeSXhGl5pdUeD5nqzc=
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-Network-Message-Id: e09de2d1-0f30-4c2e-b5ff-08d80b85b6cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 08:26:59.6762 (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: ExkhlELqT3SLW8AnrmV163PaE3XGqoBMPDCcdMUfqyPn49lS8otuU/V4K3ZMqgJ6GpixDayUH0lAUnSEbWNqwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR07MB7015
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 08 Jun 2020 08:27:05 -0000

From: tcpm  on behalf of Mark Allman =0A=
Sent: 05 June 2020 17:16=0A=
=0A=
> Mark, that is what I am questioning,=0A=
=0A=
well ...=0A=
=0A=
> that by default loss implies congestion.  Historically true for=0A=
> the IETF but I think that there are a growing number of cases=0A=
> where it is not true as in a post I saw on another WG list this=0A=
> week where a document was saying that loss MUST NOT be taken as an=0A=
> indication of congestion so the MUST in this I-D I find too=0A=
> strong.=0A=
=0A=
OK.  So, I am not sure what to do here.  I will say several things ...=0A=
=0A=
=0A=
Mark, what I would like to see is a statement up front, Introduction or jus=
t after, along the lines that the document (mostly?) assumes that loss is d=
ue to congestion which has historically been the case in the Internet and i=
s likely still largely the case in the Internet and the recommendations her=
e are designed to reduce that congestion .  but that there will be networks=
 where loss is not due to congestion in which case the recommendations here=
 MAY adversely affect the performance of the network.=0A=
I would not give an example but if one is needed, then it would be loss cau=
sed by a burst of interference where backing off simply slows down the rate=
 unnecessarily.=0A=
=0A=
Tom Petch=0A=
=0A=
(1) I believe that as a general, default the document is quite right=0A=
    in specifying a congestion response and exponential backoff.=0A=
=0A=
(2) I believe consensus of the WGs has been the same as my notion in=0A=
    (1) for some time now.  So, even setting aside (1), I am not=0A=
    sure I feel like I have carte blanche to change this.=0A=
=0A=
(3) I do not believe loss always means congestion and I do not=0A=
    believe assuming such is always correct or should always be=0A=
    done.  I don't think I know anyone who thinks that.  So, the=0A=
    document explicitly says that is fine, just go get consensus=0A=
    that some other approach is fine.  (And, that should be=0A=
    happening regardless of this document, so I am not sure what the=0A=
    big deal is here.)=0A=
=0A=
So, basically, I am not sure what to do here.  Maybe one of the ADs=0A=
can help.  Or, maybe we can set this aside and I can do the things I=0A=
told you I'd do and a little extra framing will make this better.  I=0A=
am all ears for advice here.=0A=
=0A=
(BTW, I have a half response to Stewart, as well.  I am not ignoring=0A=
his review.  I am just behind.)=0A=
=0A=
allman=0A=


From nobody Mon Jun  8 02:19:51 2020
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 1BEE93A07F4; Mon,  8 Jun 2020 02:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 TW4ZaaDhOl7X; Mon,  8 Jun 2020 02:19:36 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id A83AB3A07AA; Mon,  8 Jun 2020 02:19:36 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D32D11B000DF; Mon,  8 Jun 2020 10:19:18 +0100 (BST)
To: Benjamin Kaduk 
Cc: Mark Allman , Stewart Bryant , last-call@ietf.org, gen-art@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk> <20200607171136.GT58497@mit.edu>
From: Gorry Fairhurst 
Message-ID: <2993fb2a-a21c-5f61-bb1d-88c87ad95ed1@erg.abdn.ac.uk>
Date: Mon, 8 Jun 2020 10:19:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <20200607171136.GT58497@mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 08 Jun 2020 09:19:45 -0000

I agree, see below.

On 07/06/2020 18:11, Benjamin Kaduk wrote:
> On Sat, Jun 06, 2020 at 08:19:52AM +0100, Gorry Fairhurst wrote:
>> Please see below.
>>
>> On 05/06/2020 17:43, Mark Allman wrote:
>>>> =============
>>>>
>>>>       (3) Each time the RTO is used to detect a loss, the value of the RTO
>>>>           MUST be exponentially backed off such that the next firing
>>>>           requires a longer interval.  The backoff SHOULD be removed after
>>>>           either (a) the subsequent successful transmission of
>>>>           non-retransmitted data, or (b) an RTO passes without detecting
>>>>           additional losses.  The former will generally be quicker.  The
>>>>           latter covers cases where loss is detected, but not repaired.
>>>>
>>>>           A maximum value MAY be placed on the RTO.  The maximum RTO MUST
>>>>           NOT be less than 60 seconds (as specified in [RFC6298]).
>>>>
>>>>           This ensures network safety.
>>>>
>>>> SB> This does not work in OAM applications.
>>> Well, OK, get consensus to do something different---which is
>>> completely fine.  I think retransmission timers have shown
>>> themselves to be crucial for preventing collapse and, again, as a
>>> default I think this is our best advice.
>>>
>> It should be applicable for OAM applications that use a path across the
>> Internet that can change, and certainly could be bad advice for
>> controlled environment. It's actually not new, BCP: 145 also speaks of
>> backoff.
>>>> Minor issues:
>>>>
>>>>    "By waiting long enough that we are unambiguously
>>>>     certain a packet has been lost we cannot repair losses in a timely
>>>>     manner and we risk prolonging network congestion."
>>>>
>>>> I have a concern here that the emphasis is on classical
>>>> operation. We are beginning to see application to run over the
>>>> network where the timely delivery of a packet is critical for
>>>> correct operation of even SoL. As a BCP the text needs to
>>>> recognise that the scope and purpose of IP is changing and that
>>>> classical learning and rules derived from them may not apply.
>>>>
>>>> Also if not ruled out of scope earlier we need to be clear at this
>>>> point that things like BFD have different considerations.
>> Isn't BFD is a link protocol between adjacent systems?
> Well, your "link" can be a virtual (tunnel) link that traverses paths that
> share traffic with non-local traffic, e.g., as in draft-ietf-bfd-vxlan.
>
> -Ben


I agree "tunnels" are everywhere - if it's a tunnel, then the path may 
cross the Internet, and the considerations concerning path congestion 
and RTT variation should be relevant.

If it's known to be link-local or within a "controlled environment" then 
one could choose different constants.

I'll expect Mark can propose some appropriate words.

Gorry


From nobody Mon Jun  8 05:47:29 2020
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 D750D3A0A5E; Mon,  8 Jun 2020 05:47:18 -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, FREEMAIL_FROM=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 1zqjFc8NkfZc; Mon,  8 Jun 2020 05:47:13 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 561603A0A56; Mon,  8 Jun 2020 05:47:13 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id r15so16379661wmh.5; Mon, 08 Jun 2020 05:47:13 -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=JatR3z+8k3m3avU1HEU/N15ssLRgxPEt7wf37dV6TJM=; b=epseqVp7tFhODZsL1/CrNGxTzcxsyD7OjeNSbyurHdMYHhQyTK0x9nqbKtodNSM9VI S7JPP5ORbLwcJoXpHKnVBhzsT8iifBjDAvppIv8pkZWJ63sRcHI+ajwhVoJKeSCW4FtB gIXY54LNAz9xRpbnMQoc9o49bpXGqnYHZUU6dRy1AnulanISoTdWOyH+eT186iUTCdTW ev3hrAU4DrLXCGNp0oj3ZEaz5AhTxdvK7CRqjJaAvLZZUlMdQDzGgWoMS+i9BVDkQqb+ 4TDbJdsmpxkaPNoIscBOXzKHthl5OIrMzK8kT93BB8otFxB+9HjiOGPsNoHn3aTw1tvx 3MbA==
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=JatR3z+8k3m3avU1HEU/N15ssLRgxPEt7wf37dV6TJM=; b=sHbAs7ArB/tgelKHJUd444ohDp/31axye55nc0aeq52cLE0UFDBSeljSviITE+KcPS fXKbupSIn2tpCD/UFhHJQ19kHX6oDaWghNB5JO4qDu9kMNRdvXKUhNq1yPC/qQ+kYUFC c5VfMifUVf2JRiYyHdu/V6fvJIY+BgZoNstDUnMbmjOjcebpTYim2lcbWm/kY2d4KxFL GJ/BvFEQS1XmsNnQCBFSOWw8mzL8+9bgCob9rbi/F5UCfRBEmSm0OhacYLAymo5Zzg2p zuhJ9XaDfNgg4vDUWeelvejCHqSy0bfVL5SA9EFtv4C3uURsrVn/FvtODKVP+zgRLMS5 4k7A==
X-Gm-Message-State: AOAM5311cKN0bNYVtU6FrikolkE2q/s45I7cV6KsqLae09I8IFOAhE1b JlWGZBPANszM7bvHurRLkng=
X-Google-Smtp-Source: ABdhPJzH5jsAQW2dKNc8Nx/R/hJ4HQIsNPHX+P9qoSabrBloqOFmt+crD3FrLQNgAroZlx8A8dt4Jg==
X-Received: by 2002:a1c:9896:: with SMTP id a144mr15999019wme.75.1591620431510;  Mon, 08 Jun 2020 05:47:11 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id d18sm23391452wrn.34.2020.06.08.05.47.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 05:47:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant 
In-Reply-To: 
Date: Mon, 8 Jun 2020 13:46:39 +0100
Cc: Stewart Bryant , "gen-art@ietf.org Review Team" , tcpm , Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com> 
To: Mark Allman 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 08 Jun 2020 12:47:19 -0000

> On 5 Jun 2020, at 17:43, Mark Allman  wrote:
>=20
>=20
> Hi Stewart!
>=20
> Thanks for the feedback.  Sorry for the long RTT.  I had a recent
> deadline and am now trying to dig out.
>=20
>> Major issues:
>>=20
>> As far as I can see this text only applies to exchanges between
>> applications and network support applications such as
>> DNS. I.e. this is targeted at layer 4 and above. Given the
>> religious nature of BCPs in the eyes of some reviewers, and to
>> prevent endless explanations by those that design routing
>> protocols, OAM and other lower layer sub-system I think there
>> needs to a scoping text in block capitals at the at the very start
>> of the documnet.
>=20
> I am not entirely sure what you're suggesting here.  Per note to
> Tom, I am going to add a few words to the intro.  Maybe that will
> help.  I think it's unlikely I'll use block capitals! :-)


In the text the discussion and examples and base learning seem to derive
=46rom the transport layer.

RTT issues apply to other aspects of the Internet, and you either need =
to
analyse and discuss them in the same depth and apply your conclusions =
accordingly
Or you need to explicitly exclude them

What I am hoping we can do is to prevent a single focus review of the=20
Internet operations giving rise to endless discussions and argument when
Legitimate designs are proposed for other aspects.

The antithesis of the big I internet is a service provider domain where
Different considerations often apply.

>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>>      - The requirements in this document may not be appropriate in =
all
>>        cases and, therefore, inconsistent deviations may be necessary
>>        (hence the "SHOULD" in the last bullet).  However,
>>        inconsistencies MUST be (a) explained and (b) gather =
consensus.
>>=20
>> SB> That can be quite an onerous obligation  and provide scope for
>> SB> endless argument when reviewers are not domain experts in the
>> SB> protocol being designed.
>=20
> This was added because another reviewer thought it was for sure
> necessary.
>=20
> I guess I don't understand why you'd call this 'an onerous
> obligation' since presumably you'd do it anyway without this
> document. =20

Not necessarily. There is a lot of experience in how to run the layers
Below transport.


> Are we ramming things through without consensus?

Well if it impacts Int and Routing and there has not been widespread=20
Review there the answer is yes. You are getting pushback from a
GenARt reviewer that happens to be a specialist in the lower layers
So arguably the process is working, but wider review is always better,

>  If not
> (my assumption), (b) is no sweat.  Are we ramming things through
> without thought?  If not (my assumption), (a) is straightforward and
> hopefully is being done anyway.  In other words, I don't understand
> the complaint here because if you don't want to use the guidelines
> then that is fine, but in going through the standard process to
> define a loss detector you'll end up meeting this bullet.  Even if
> this document doesn't get published or didn't exist our documents
> should still be meeting this bullet.

Yes, but having seen far too many religious standoffs between the areas
Over the years, it would be nice not to create the basis for more such
Events.

>=20
>> =3D=3D=3D=3D=3D=3D=3D
>>=20
>>          While there are a bevy of uses for timers in =
protocols---from
>>          rate-based pacing to connection failure detection and
>>          beyond---these are outside the scope of this document.
>>=20
>> SB> I am not sure what that means for the applicability of this
>> SB> document.
>=20
> This was added at some point along the way because someone thought
> something like rate-based pacing could be covered by the guidelines
> and the intent is to say it is not.  I have zero love for this bit
> and would happily remove it, but am loathe to do so because the old
> comment will then come back.

Perhaps a more precise definition is required. It is rather general.

>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>>    (1) As we note above, loss detection happens when a sender does =
not
>>        receive delivery confirmation within an some expected period =
of
>>        time.  In the absence of any knowledge about the latency of a
>>        path, the initial RTO MUST be conservatively set to no less =
than
>>        1 second.
>>=20
>> SB> This issue may be addressed by the scoping text, but 1s is no
>> SB> use when you are trying to detect sub 50ms of packet loss in
>> SB> the infrastructure.
>=20
> We have to start somewhere when we know nothing.
>=20
> I think in my thread with Tom we hit upon this notion that the
> document is really about sort of arbitrary, unknown and therefore
> presumed unreliable networks.  I am going to add some words to this
> effect.  Does this help?
>=20
> Again, for specific environments where things are more nailed down
> and known, deviations are fine and explicitly OK.  But, as a general
> default I think saying "when you don't know anything < 50msec is
> cool" is unlikely to be appropriate.  Well, no, I think it would be
> quite inappropriate, actually.


As you may gather my concern is that by making this a catch all position
You catch too much and put a burden of work on too many other groups.
=20
If you are talking about L4 and above in the big I Internet I am not =
concerned,=20
But as written it has a much larger scope and that concerns me.

>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>>    (3) Each time the RTO is used to detect a loss, the value of the =
RTO
>>        MUST be exponentially backed off such that the next firing
>>        requires a longer interval.  The backoff SHOULD be removed =
after
>>        either (a) the subsequent successful transmission of
>>        non-retransmitted data, or (b) an RTO passes without detecting
>>        additional losses.  The former will generally be quicker.  The
>>        latter covers cases where loss is detected, but not repaired.
>>=20
>>        A maximum value MAY be placed on the RTO.  The maximum RTO =
MUST
>>        NOT be less than 60 seconds (as specified in [RFC6298]).
>>=20
>>        This ensures network safety.
>>=20
>> SB> This does not work in OAM applications.
>=20
> Well, OK, get consensus to do something different---which is
> completely fine.  I think retransmission timers have shown
> themselves to be crucial for preventing collapse and, again, as a
> default I think this is our best advice.

No, I think you need to show that you have discussed this with other
Groups before imposing it on them.

>=20
>> Minor issues:
>>=20
>> "By waiting long enough that we are unambiguously
>>  certain a packet has been lost we cannot repair losses in a timely
>>  manner and we risk prolonging network congestion."
>>=20
>> I have a concern here that the emphasis is on classical
>> operation. We are beginning to see application to run over the
>> network where the timely delivery of a packet is critical for
>> correct operation of even SoL. As a BCP the text needs to
>> recognise that the scope and purpose of IP is changing and that
>> classical learning and rules derived from them may not apply.
>>=20
>> Also if not ruled out of scope earlier we need to be clear at this
>> point that things like BFD have different considerations.
>=20
> I am going to suggest we revisit this after I hack out a little
> extra text for the intro.  You can see if that helps.

OK, let=E2=80=99s see the new text.

>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>>      "- This document does not update or obsolete any existing RFC.
>>        These previous specifications---while generally consistent =
with
>>        the requirements in this document---reflect community =
consensus
>>        and this document does not change that consensus."
>>=20
>> I think it needs to be clear that adherence to this RFC is not
>> required for minor updates and extensions to existing RFCs. Having
>> seen minor routing extension held up by security concerns related
>> to underlying protocols rather than the extension itself there is
>> a lot of sensitivity on this point in some quarters of the IETF.
>=20
> Um.  Do you have suggested words?  I am not much of a protocol
> lawyers (thankfully!), but I am not really conjuring the case you're
> concerned about.  Something like ...
>=20
>  (1) RFC XXXX was published 10 years ago and violates
>      rto-consider.
>  (2) We want to do a XXXXbis.
>  (3) The bis has to then explain why it's cool to violate
>      rto-consider.
>=20
> ... ?
>=20
> I would say if XXXX has a loss detector that had consensus and has
> been in use for a while it'd be pretty easy to get consensus for
> XXXXbis that we can still use it as it has worked fine.

I have seen a number of cases where minor changes to protocols became=20
Hostage to the ambitions of others to make a fundamental change=20
And I hope we can avoid this here.

>=20
>> It might be useful to make it clear that there are some
>> applications that would prefer no data to late data.
>=20
> This document is about loss detection, not what one does after
> detecting.  So, we do say ...
>=20
>    However, as discussed above, the detected loss need not be
>    repaired
>=20
> I am happy to re-enforce this point.  Text suggestions welcome.

OK

>=20
>> Nits/editorial comments:
>>=20
>> The terminology section confuses ID-nits - I think it should be a
>> section in its own right later in the document.
>=20
> Yeah- id-nits as it is run when submitting doesn't flag this.  It
> was flagged by someone else in LC.  Because I am old school it's
> hard to renumber everything and so I was just leaving this for the
> rfc-ed to do something reasonable here.

I run ID-nits in verbose mode before submission. This partially
A matter of respect for reviewers and the editors, and partly because I
Figure that the more errors you deal with the easier it is to find the=20=

Important errors that may mask.


>=20
>> The following nits issues need looking at
>>=20
>>  =3D=3D Missing Reference: 'RFC5681' is mentioned on line 377, but =
not defined
>>=20
>>  =3D=3D Unused Reference: 'RFC3940' is defined on line 515, but no =
explicit
>>     reference was found in the text
>>=20
>>  =3D=3D Unused Reference: 'RFC4340' is defined on line 519, but no =
explicit
>>     reference was found in the text
>>=20
>>  =3D=3D Unused Reference: 'RFC6582' is defined on line 540, but no =
explicit
>>     reference was found in the text
>=20
> I will fix all these.  Again, I was trusting the id-nits when I
> submitted and these were not flagged (or, if they were it wasn't in
> a way that foisted them on my screen).  But, they're easy fixes, so
> thanks!
>=20
> allman

Thanks

Stewart


From nobody Mon Jun  8 05:58:20 2020
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 771E33A0A68; Mon,  8 Jun 2020 05:58:14 -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, 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 eGzjCnDulBWt; Mon,  8 Jun 2020 05:58:11 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 7B6793A095B; Mon,  8 Jun 2020 05:58:11 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id d128so16412273wmc.1; Mon, 08 Jun 2020 05:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CIhg9wlK3UoaRsXV0THdqPusnTOKhHo1qOcB3T12de4=; b=WSLc8s+tHxXAa0R5NpIpijLx8mwIWGW+sGzLqi7Vix/vZwSt38a/AhzvM5qENWua/t 9fXQ7/QOUzMcjd00afCrpQcTDTkyA6/DJxV2/IgBuzUZW3WJjFzBMgZh7wRz3gVuwqkY X1m8fPF9fZPOuakOxYYv+zsTWNkKp352UZaxIPkue0Nve6FldeVyejwUGHV8H8eZzFyJ ecEjrZxP10L/RFtCspfDCj43ssR4H55cUW+16DfMJTNY58U3gTpjAoBCiLTHOhFU+ypp 0HVbq+EtgvXtDjdrRJCwR2MA04dk/p551FbRhdMUy2J/lBQDT9z+Kzr+5k79DbhPSOGl Y+zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CIhg9wlK3UoaRsXV0THdqPusnTOKhHo1qOcB3T12de4=; b=AIVmAZMuxEiFlUNUeAvKqIzvU56UQTHoBKFeyVq1ilJeQl1HZirhyWJDfLE0SvQoZl SuJOEp0IEMrcyczWbonbrw1x6mzMwm4Nt3NTjsE3cwsFTF75pHGLEmg9kElYh3l0vY7I wv/OBzWj5nwoF7OJe9SF4CgAq2rH8n7z53VK+u4JKzxMeQHb3ONPZUwX8dIox2Z+XGIA 2Yn0BFzCbswVjO8Sg5u55p9NU4qIEBOAsp89+EB5o3BKfJXK0lo/olByEECXoT8mmJbd pJZuHGjSXi6TcnszVbza4b3YfW47itECl4Qih2BJwvxW0VshbPNzjv+RQI4mVHme9771 bF3A==
X-Gm-Message-State: AOAM533o+8C22DQxAuZGS5KkRt9f+yyCVXPwtpYPy1u60subQL43juyN 2QX+A0atrdwlVs+nEsQS7nI=
X-Google-Smtp-Source: ABdhPJzh8aKKyMa0vOCIH2YOVgZT7hG+qNNM5Sv3VUTEeAw1UsihYlNeJq6DIbpRg41zXOty84WpQw==
X-Received: by 2002:a1c:4954:: with SMTP id w81mr16743627wma.86.1591621089755;  Mon, 08 Jun 2020 05:58:09 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id r11sm24183383wre.25.2020.06.08.05.58.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 05:58:09 -0700 (PDT)
From: Stewart Bryant 
Message-Id: <4E00DBE9-BB42-427D-B6C4-D61669C896F2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB96F57B-1C31-491A-A8A7-65C14810D05D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 8 Jun 2020 13:57:37 +0100
In-Reply-To: <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk>
Cc: Stewart Bryant , Mark Allman ,  Last Call , "gen-art@ietf.org Review Team" , tcpm , draft-ietf-tcpm-rto-consider.all@ietf.org
To: Gorry Fairhurst 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 08 Jun 2020 12:58:15 -0000

--Apple-Mail=_EB96F57B-1C31-491A-A8A7-65C14810D05D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 6 Jun 2020, at 08:19, Gorry Fairhurst  wrote:
>=20
> Please see below.
>=20
> On 05/06/2020 17:43, Mark Allman wrote:
>> Hi Stewart!
>>=20
>> Thanks for the feedback.  Sorry for the long RTT.  I had a recent
>> deadline and am now trying to dig out.
>>=20
>>> Major issues:
>>>=20
>>> As far as I can see this text only applies to exchanges between
>>> applications and network support applications such as
>>> DNS. I.e. this is targeted at layer 4 and above. Given the
>>> religious nature of BCPs in the eyes of some reviewers, and to
>>> prevent endless explanations by those that design routing
>>> protocols, OAM and other lower layer sub-system I think there
>>> needs to a scoping text in block capitals at the at the very start
>>> of the documnet.
>> I am not entirely sure what you're suggesting here.  Per note to
>> Tom, I am going to add a few words to the intro.  Maybe that will
>> help.  I think it's unlikely I'll use block capitals! :-)
>>=20
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>       - The requirements in this document may not be appropriate in =
all
>>>         cases and, therefore, inconsistent deviations may be =
necessary
>>>         (hence the "SHOULD" in the last bullet).  However,
>>>         inconsistencies MUST be (a) explained and (b) gather =
consensus.
>>>=20
>>> SB> That can be quite an onerous obligation  and provide scope for
>>> SB> endless argument when reviewers are not domain experts in the
>>> SB> protocol being designed.
>> This was added because another reviewer thought it was for sure
>> necessary.
>>=20
>> I guess I don't understand why you'd call this 'an onerous
>> obligation' since presumably you'd do it anyway without this
>> document.  Are we ramming things through without consensus?  If not
>> (my assumption), (b) is no sweat.  Are we ramming things through
>> without thought?  If not (my assumption), (a) is straightforward and
>> hopefully is being done anyway.  In other words, I don't understand
>> the complaint here because if you don't want to use the guidelines
>> then that is fine, but in going through the standard process to
>> define a loss detector you'll end up meeting this bullet.  Even if
>> this document doesn't get published or didn't exist our documents
>> should still be meeting this bullet.
>>=20
>>> =3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>           While there are a bevy of uses for timers in =
protocols---from
>>>           rate-based pacing to connection failure detection and
>>>           beyond---these are outside the scope of this document.
>>>=20
>>> SB> I am not sure what that means for the applicability of this
>>> SB> document.
>> This was added at some point along the way because someone thought
>> something like rate-based pacing could be covered by the guidelines
>> and the intent is to say it is not.  I have zero love for this bit
>> and would happily remove it, but am loathe to do so because the old
>> comment will then come back.
> I think Mark is correct, there are many transport uses of timers, and =
calling out a small number of other uses was important to scope this =
withing the transport discussions, even if it just says "timers also do =
other stuff".

If the scope of this is explicitly transport and above I have no issues.

If it has a greater scope the scope of study and recommendations really =
needs to increase accordingly.

>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>     (1) As we note above, loss detection happens when a sender does =
not
>>>         receive delivery confirmation within an some expected period =
of
>>>         time.  In the absence of any knowledge about the latency of =
a
>>>         path, the initial RTO MUST be conservatively set to no less =
than
>>>         1 second.
>>>=20
>>> SB> This issue may be addressed by the scoping text, but 1s is no
>>> SB> use when you are trying to detect sub 50ms of packet loss in
>>> SB> the infrastructure.
>> We have to start somewhere when we know nothing.
>>=20
>> I think in my thread with Tom we hit upon this notion that the
>> document is really about sort of arbitrary, unknown and therefore
>> presumed unreliable networks.  I am going to add some words to this
>> effect.  Does this help?
>>=20
>> Again, for specific environments where things are more nailed down
>> and known, deviations are fine and explicitly OK.  But, as a general
>> default I think saying "when you don't know anything < 50msec is
>> cool" is unlikely to be appropriate.  Well, no, I think it would be
>> quite inappropriate, actually.
> This is I think a natural discussion based on a different perspective. =
The 1 second initial starting value for a transport path has been there =
for a long time, and transport reviewers will frequently quote this be =
it for transport:  SCTP, TCP, or for UDP-based apps (BCP: 145 Sect =
3.1.1). I'd expect this is about the assumed starting position for an =
Internet path.
>=20
> True if we're talking about a link between adjacent peers, this is =
something very different.=20
>=20

We do multi-hop OAM in RTG to hold the infrastructure together.

Again, my point is that if the scope is L4 and above I have no issue, =
but the scope seems to be wider.


>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>     (3) Each time the RTO is used to detect a loss, the value of the =
RTO
>>>         MUST be exponentially backed off such that the next firing
>>>         requires a longer interval.  The backoff SHOULD be removed =
after
>>>         either (a) the subsequent successful transmission of
>>>         non-retransmitted data, or (b) an RTO passes without =
detecting
>>>         additional losses.  The former will generally be quicker.  =
The
>>>         latter covers cases where loss is detected, but not =
repaired.
>>>=20
>>>         A maximum value MAY be placed on the RTO.  The maximum RTO =
MUST
>>>         NOT be less than 60 seconds (as specified in [RFC6298]).
>>>=20
>>>         This ensures network safety.
>>>=20
>>> SB> This does not work in OAM applications.
>> Well, OK, get consensus to do something different---which is
>> completely fine.  I think retransmission timers have shown
>> themselves to be crucial for preventing collapse and, again, as a
>> default I think this is our best advice.
>>=20
> It should be applicable for OAM applications that use a path across =
the Internet that can change, and certainly could be bad advice for =
controlled environment. It's actually not new, BCP: 145 also speaks of =
backoff.

A common standard rule in OAM type situation is three fast packets and =
then back-off.


>>> Minor issues:
>>>=20
>>>  "By waiting long enough that we are unambiguously
>>>   certain a packet has been lost we cannot repair losses in a timely
>>>   manner and we risk prolonging network congestion."
>>>=20
>>> I have a concern here that the emphasis is on classical
>>> operation. We are beginning to see application to run over the
>>> network where the timely delivery of a packet is critical for
>>> correct operation of even SoL. As a BCP the text needs to
>>> recognise that the scope and purpose of IP is changing and that
>>> classical learning and rules derived from them may not apply.
>>>=20
>>> Also if not ruled out of scope earlier we need to be clear at this
>>> point that things like BFD have different considerations.
> Isn't BFD is a link protocol between adjacent systems?

No, not always, you can have multiple-hop BFD.

This is infrastructure and not user data and there is a school of though =
that in data planes where
The same data path is used for both control and user data, the user data =
is sacrificial to maintaining
The infrastructure. The reason that you do backoff in these cases is not =
to avoid congestion but
Instead to avoid overloading the control peer, i.e. the route processor =
in the peer router.


- Stewart
>> I am going to suggest we revisit this after I hack out a little
>> extra text for the intro.  You can see if that helps.
>>=20
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>=20
>>>       "- This document does not update or obsolete any existing RFC.
>>>         These previous specifications---while generally consistent =
with
>>>         the requirements in this document---reflect community =
consensus
>>>         and this document does not change that consensus."
>>>=20
>>> I think it needs to be clear that adherence to this RFC is not
>>> required for minor updates and extensions to existing RFCs. Having
>>> seen minor routing extension held up by security concerns related
>>> to underlying protocols rather than the extension itself there is
>>> a lot of sensitivity on this point in some quarters of the IETF.
>> Um.  Do you have suggested words?  I am not much of a protocol
>> lawyers (thankfully!), but I am not really conjuring the case you're
>> concerned about.  Something like ...
>>=20
>>   (1) RFC XXXX was published 10 years ago and violates
>>       rto-consider.
>>   (2) We want to do a XXXXbis.
>>   (3) The bis has to then explain why it's cool to violate
>>       rto-consider.
>>=20
>> .... ?
>>=20
>> I would say if XXXX has a loss detector that had consensus and has
>> been in use for a while it'd be pretty easy to get consensus for
>> XXXXbis that we can still use it as it has worked fine.
>>=20
>>> It might be useful to make it clear that there are some
>>> applications that would prefer no data to late data.
>> This document is about loss detection, not what one does after
>> detecting.  So, we do say ...
>>=20
>>     However, as discussed above, the detected loss need not be
>>     repaired
>>=20
>> I am happy to re-enforce this point.  Text suggestions welcome.
>>=20
>>> Nits/editorial comments:
>>>=20
>>> The terminology section confuses ID-nits - I think it should be a
>>> section in its own right later in the document.
>> Yeah- id-nits as it is run when submitting doesn't flag this.  It
>> was flagged by someone else in LC.  Because I am old school it's
>> hard to renumber everything and so I was just leaving this for the
>> rfc-ed to do something reasonable here.
>>=20
>>> The following nits issues need looking at
>>>=20
>>>   =3D=3D Missing Reference: 'RFC5681' is mentioned on line 377, but =
not defined
>>>=20
>>>   =3D=3D Unused Reference: 'RFC3940' is defined on line 515, but no =
explicit
>>>      reference was found in the text
>>>=20
>>>   =3D=3D Unused Reference: 'RFC4340' is defined on line 519, but no =
explicit
>>>      reference was found in the text
>>>=20
>>>   =3D=3D Unused Reference: 'RFC6582' is defined on line 540, but no =
explicit
>>>      reference was found in the text
>> I will fix all these.  Again, I was trusting the id-nits when I
>> submitted and these were not flagged (or, if they were it wasn't in
>> a way that foisted them on my screen).  But, they're easy fixes, so
>> thanks!
>>=20
>> allman
>>=20
>>=20
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org 
>> https://www.ietf.org/mailman/listinfo/tcpm =



--Apple-Mail=_EB96F57B-1C31-491A-A8A7-65C14810D05D
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



On 6 Jun 2020, at 08:19, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


  
    
  
  
Please see below.

    

    
On 05/06/2020 17:43, Mark Allman wrote:

    

    

      
Hi Stewart!

Thanks for the feedback.  Sorry for the long RTT.  I had a recent
deadline and am now trying to dig out.



      

        
Major issues:

As far as I can see this text only applies to exchanges between
applications and network support applications such as
DNS. I.e. this is targeted at layer 4 and above. Given the
religious nature of BCPs in the eyes of some reviewers, and to
prevent endless explanations by those that design routing
protocols, OAM and other lower layer sub-system I think there
needs to a scoping text in block capitals at the at the very start
of the documnet.


      

      
I am not entirely sure what you're suggesting here.  Per note to
Tom, I am going to add a few words to the intro.  Maybe that will
help.  I think it's unlikely I'll use block capitals! :-)



      

        
=========

      - The requirements in this document may not be appropriate in all
        cases and, therefore, inconsistent deviations may be necessary
        (hence the "SHOULD" in the last bullet).  However,
        inconsistencies MUST be (a) explained and (b) gather consensus.

SB> That can be quite an onerous obligation  and provide scope for
SB> endless argument when reviewers are not domain experts in the
SB> protocol being designed.


      

      
This was added because another reviewer thought it was for sure
necessary.

I guess I don't understand why you'd call this 'an onerous
obligation' since presumably you'd do it anyway without this
document.  Are we ramming things through without consensus?  If not
(my assumption), (b) is no sweat.  Are we ramming things through
without thought?  If not (my assumption), (a) is straightforward and
hopefully is being done anyway.  In other words, I don't understand
the complaint here because if you don't want to use the guidelines
then that is fine, but in going through the standard process to
define a loss detector you'll end up meeting this bullet.  Even if
this document doesn't get published or didn't exist our documents
should still be meeting this bullet.



      

        
=======

          While there are a bevy of uses for timers in protocols---from
          rate-based pacing to connection failure detection and
          beyond---these are outside the scope of this document.

SB> I am not sure what that means for the applicability of this
SB> document.


      

      
This was added at some point along the way because someone thought
something like rate-based pacing could be covered by the guidelines
and the intent is to say it is not.  I have zero love for this bit
and would happily remove it, but am loathe to do so because the old
comment will then come back.


    

    I think Mark is correct, there are many transport uses of timers,
    and calling out a small number of other uses was important to scope
    this withing the transport discussions, even if it just says "timers
    also do other stuff".

If the scope of this is explicitly transport and above I have no issues.

If it has a greater scope the scope of study and recommendations really needs to increase accordingly.


    

      

      

        
=========

    (1) As we note above, loss detection happens when a sender does not
        receive delivery confirmation within an some expected period of
        time.  In the absence of any knowledge about the latency of a
        path, the initial RTO MUST be conservatively set to no less than
        1 second.

SB> This issue may be addressed by the scoping text, but 1s is no
SB> use when you are trying to detect sub 50ms of packet loss in
SB> the infrastructure.


      

      
We have to start somewhere when we know nothing.

I think in my thread with Tom we hit upon this notion that the
document is really about sort of arbitrary, unknown and therefore
presumed unreliable networks.  I am going to add some words to this
effect.  Does this help?

Again, for specific environments where things are more nailed down
and known, deviations are fine and explicitly OK.  But, as a general
default I think saying "when you don't know anything < 50msec is
cool" is unlikely to be appropriate.  Well, no, I think it would be
quite inappropriate, actually.


    
This is I think a natural discussion based on a different
      perspective. The 1 second initial starting value for a transport
      path has been there for a long time, and transport reviewers will
      frequently quote this be it for transport:  SCTP, TCP, or for
      UDP-based apps (BCP: 145 Sect 3.1.1). I'd expect this is about the
      assumed starting position for an Internet path.
True if we're talking about a link between adjacent peers, this
      is something very different. 

We do multi-hop OAM in RTG to hold the infrastructure together.

Again, my point is that if the scope is L4 and above I have no issue, but the scope seems to be wider.



    

    

      

      

        
=============

    (3) Each time the RTO is used to detect a loss, the value of the RTO
        MUST be exponentially backed off such that the next firing
        requires a longer interval.  The backoff SHOULD be removed after
        either (a) the subsequent successful transmission of
        non-retransmitted data, or (b) an RTO passes without detecting
        additional losses.  The former will generally be quicker.  The
        latter covers cases where loss is detected, but not repaired.

        A maximum value MAY be placed on the RTO.  The maximum RTO MUST
        NOT be less than 60 seconds (as specified in [RFC6298]).

        This ensures network safety.

SB> This does not work in OAM applications.


      

      
Well, OK, get consensus to do something different---which is
completely fine.  I think retransmission timers have shown
themselves to be crucial for preventing collapse and, again, as a
default I think this is our best advice.



    

    It should be applicable for OAM applications that use a path across
    the Internet that can change, and certainly could be bad advice for
    controlled environment. It's actually not new, BCP: 145 also speaks
    of backoff.
    

A common standard rule in OAM type situation is three fast packets and then back-off.



      

        
Minor issues:

 "By waiting long enough that we are unambiguously
  certain a packet has been lost we cannot repair losses in a timely
  manner and we risk prolonging network congestion."

I have a concern here that the emphasis is on classical
operation. We are beginning to see application to run over the
network where the timely delivery of a packet is critical for
correct operation of even SoL. As a BCP the text needs to
recognise that the scope and purpose of IP is changing and that
classical learning and rules derived from them may not apply.

Also if not ruled out of scope earlier we need to be clear at this
point that things like BFD have different considerations.


      

    

    Isn't BFD is a link protocol between adjacent systems?

No, not always, you can have multiple-hop BFD.

This is infrastructure and not user data and there is a school of though that in data planes where
The same data path is used for both control and user data, the user data is sacrificial to maintaining
The infrastructure. The reason that you do backoff in these cases is not to avoid congestion but
Instead to avoid overloading the control peer, i.e. the route processor in the peer router.


- Stewart

    

      
I am going to suggest we revisit this after I hack out a little
extra text for the intro.  You can see if that helps.



      

        
==========

      "- This document does not update or obsolete any existing RFC.
        These previous specifications---while generally consistent with
        the requirements in this document---reflect community consensus
        and this document does not change that consensus."

I think it needs to be clear that adherence to this RFC is not
required for minor updates and extensions to existing RFCs. Having
seen minor routing extension held up by security concerns related
to underlying protocols rather than the extension itself there is
a lot of sensitivity on this point in some quarters of the IETF.


      

      
Um.  Do you have suggested words?  I am not much of a protocol
lawyers (thankfully!), but I am not really conjuring the case you're
concerned about.  Something like ...

  (1) RFC XXXX was published 10 years ago and violates
      rto-consider.
  (2) We want to do a XXXXbis.
  (3) The bis has to then explain why it's cool to violate
      rto-consider.

.... ?

I would say if XXXX has a loss detector that had consensus and has
been in use for a while it'd be pretty easy to get consensus for
XXXXbis that we can still use it as it has worked fine.



      

        
It might be useful to make it clear that there are some
applications that would prefer no data to late data.


      

      
This document is about loss detection, not what one does after
detecting.  So, we do say ...

    However, as discussed above, the detected loss need not be
    repaired

I am happy to re-enforce this point.  Text suggestions welcome.



      

        
Nits/editorial comments:

The terminology section confuses ID-nits - I think it should be a
section in its own right later in the document.


      

      
Yeah- id-nits as it is run when submitting doesn't flag this.  It
was flagged by someone else in LC.  Because I am old school it's
hard to renumber everything and so I was just leaving this for the
rfc-ed to do something reasonable here.



      

        
The following nits issues need looking at

  == Missing Reference: 'RFC5681' is mentioned on line 377, but not defined

  == Unused Reference: 'RFC3940' is defined on line 515, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4340' is defined on line 519, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6582' is defined on line 540, but no explicit
     reference was found in the text


      

      
I will fix all these.  Again, I was trusting the id-nits when I
submitted and these were not flagged (or, if they were it wasn't in
a way that foisted them on my screen).  But, they're easy fixes, so
thanks!

allman


      

      

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


    

  





--Apple-Mail=_EB96F57B-1C31-491A-A8A7-65C14810D05D--


From nobody Mon Jun  8 06:00:32 2020
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 135393A0A68; Mon,  8 Jun 2020 06:00:30 -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, FREEMAIL_FROM=0.001, 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=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 2LbpzyPJKEoA; Mon,  8 Jun 2020 06:00:29 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 CFD153A09C8; Mon,  8 Jun 2020 06:00:28 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id f185so16424878wmf.3; Mon, 08 Jun 2020 06:00:28 -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=PezupVxffBsn3WSRy83cfYRQCtmvm1W8iBMsC/NqOSk=; b=HwW4bHZ0d4A6aVw6riiJ6DMdk21cmZqvYI7vXsXIMlL7SdtAcQ1Xlkm2y8ogDnovoT gA/8G6GcpnvvvaePMABVq17TX5JW9FNi/OpZNYctP7zMbq4dgQQLfQq9pfVa7LmoJk65 HeNNawXlOde8xN5TqOMuYDyT/3kX+jexvDCr9Ls+hxnucKwgPv5V1Xd5J7dAuGWJGl0d 8ErkyyIwyJljgZEK+USySHET7J71I0StJ7z3TU8nEbgFL1Ooi6No1vhjdRh/vNTYcMSg kQHTksyUFNmhXkWTxjQO6kZJsmrkXwyNl+UKIEogbFII/4nMSlZn/8jj5P1du0wYFspl gveQ==
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=PezupVxffBsn3WSRy83cfYRQCtmvm1W8iBMsC/NqOSk=; b=Z+c8Rm+GeSTu2XIuKfTUcqUy/lkdGdjVcZrsbyqaziBKsqVvXodZaCv6hWYdZG78wx CrBnvnPTYa9YFQy3JsdwyyT1LA+M67PzWvLhT09ZatHfejVmCEuQ9N1ox8/y7S/uav0l TgcNfOv71l17EKil32MhcxinHn1r6kmGfs8aZFgqxL0ShMrKwpofTeQ7ZwBTGGdyb1dz t5iztN0fBNyyyXO7zfQ2iiCeahXuAWVRTcwEZsqMGK76FD2PAVCXUJf7mqfT82rgfDYV wL8wBugCgZSQAsRqI4IoQV2PGXJbaSJr9nEDjJUQ3cpxiiUbeS7q0VzW/uXLv8dZtcQW Gfyg==
X-Gm-Message-State: AOAM531/EaUPv0I4SjPowePDbo2Y0KctYq0gHVXW1a2STvLsh26PPo6G LS+jPRguEkSInurA8yNgpbI=
X-Google-Smtp-Source: ABdhPJzBsp28IBE5Vu+uvV58y9FWRRc0IV/Lgz0+danKSPDbvb3K0pKOSbGD6ATfOBs+2/Ri/adL1g==
X-Received: by 2002:a1c:98cc:: with SMTP id a195mr16242923wme.89.1591621225308;  Mon, 08 Jun 2020 06:00:25 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id t188sm18156722wmt.27.2020.06.08.06.00.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 06:00:24 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant 
In-Reply-To: <2993fb2a-a21c-5f61-bb1d-88c87ad95ed1@erg.abdn.ac.uk>
Date: Mon, 8 Jun 2020 13:59:53 +0100
Cc: Stewart Bryant , Benjamin Kaduk ,  Mark Allman , last-call@ietf.org, gen-art@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <4f52479e-1184-9277-66e5-6278eda95e0b@erg.abdn.ac.uk> <20200607171136.GT58497@mit.edu> <2993fb2a-a21c-5f61-bb1d-88c87ad95ed1@erg.abdn.ac.uk>
To: Gorry Fairhurst 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 08 Jun 2020 13:00:30 -0000

>=20
>=20
> I agree "tunnels" are everywhere - if it's a tunnel, then the path may =
cross the Internet, and the considerations concerning path congestion =
and RTT variation should be relevant.
>=20
> If it's known to be link-local or within a "controlled environment" =
then one could choose different constants.
>=20
> I'll expect Mark can propose some appropriate words.

Clarifying that would help with many of the issues that I am concerned =
about.

Stewart

>=20
> Gorry
>=20


From nobody Mon Jun  8 12:40:53 2020
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 A22D93A0F86; Mon,  8 Jun 2020 12:40:42 -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.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <159164524257.17321.13881398681709435235@ietfa.amsl.com>
Date: Mon, 08 Jun 2020 12:40:42 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-15.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, 08 Jun 2020 19:40:48 -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           : Requirements for Time-Based Loss Detection
        Author          : Mark Allman
	Filename        : draft-ietf-tcpm-rto-consider-15.txt
	Pages           : 11
	Date            : 2020-06-08

Abstract:
    Many protocols must detect packet loss for various reasons (e.g., to
    ensure reliability using retransmissions or to understand the level
    of congestion along a network path).  While many mechanisms have
    been designed to detect loss, protocols ultimately can only count on
    the passage of time without delivery confirmation to declare a
    packet "lost".  Each implementation of a time-based loss detection
    mechanism represents a balance between correctness and timeliness
    and therefore no implementation suits all situations.  This document
    provides high-level requirements for time-based loss detectors
    appropriate for general use in the Internet.  Within the
    requirements, implementations have latitude to define particulars
    that best address each situation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-15
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-15

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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



From nobody Mon Jun  8 12:52:24 2020
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 AE5373A0F75 for ; Mon,  8 Jun 2020 12:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level: 
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 fQjFeMMS62pe for ; Mon,  8 Jun 2020 12:52:21 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 63DCF3A0F72 for ; Mon,  8 Jun 2020 12:52:21 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id e5so14661631ote.11 for ; Mon, 08 Jun 2020 12:52:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=Upez9eIeT9AvHRzUK+lVGNytAgvsPj1BlLYi14tvyDg=; b=V8dsRIlh8MNdEmmbN+fwwWY+2Ko+diZGDVC/KwqQ+LBZAFkh9SWuPqZo0I/QY4Ebje x4a4MNZcQSq/PseeuNtS3KDwCXoJSpg5XniHNHfw+wqE8jQ9Lzsr7aMIuXFvQ9VRwHXC 5wle0ZPcgqvihd9ZtZLs1gsyw319bLEEzpAe93AxBE9yIa+GHxqlBIU89tJ2ghVXw0Fb nZInaw7qvBO+6vWnoLtYBvZ84H0n5ggf0YL15pe36D7Mjz7m/sJybnq7mrk57UNQREyp 0n+cOkI4BqVNSsMyD+bTI34UrQbCMglmRd/Q+oPzADe9T3H5QOrvysva3/ZPAQt72kp4 kQow==
X-Gm-Message-State: AOAM531vEUS0Hnfpmc7Y0ug9pFU5dqJrsFLFWTr6TCHCHVQOpExmN1Vq CvydQ+d+tBj+hr5Qv6WqxnDI4A==
X-Google-Smtp-Source: ABdhPJzdvhEwIKWPOGAPQfQXs0FzlbAH4HmvOjqoISdzn388k38ub0r7KIz/MS9+WN/bD+/l8y61Hg==
X-Received: by 2002:a9d:5190:: with SMTP id y16mr7800282otg.68.1591645940497;  Mon, 08 Jun 2020 12:52:20 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:fc:25c4:9d82:7cf3]) by smtp.gmail.com with ESMTPSA id g10sm1722761otn.34.2020.06.08.12.52.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 12:52:19 -0700 (PDT)
From: "Mark Allman" 
To: "Stewart Bryant" 
Cc: "Review Team" , tcpm , "Last Call" , draft-ietf-tcpm-rto-consider.all@ietf.org, "tom petch" 
Date: Mon, 08 Jun 2020 15:52:16 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>
In-Reply-To: <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_966D57F8-BB69-424D-B202-762EE2016A5E_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 08 Jun 2020 19:52:23 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_966D57F8-BB69-424D-B202-762EE2016A5E_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi Stewart, et.al.!

I just submitted a new version of rto-consider.  Please ask the
datatracker for diffs between this and rev -14.  The highlights:

  - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?=
difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-rto-consider-15.txt

  - All small comments addressed.

  - I think we all agree that this is not a one-size-fits-all
    situation.  Rather, this document is meant to be a default case.
    So, the main action of this rev is to make that point more
    clearly.  The first paragraph in the intro is new.  Also, there
    are some more words fleshing out the context more in section 2.
    In particular, more emphatically making the point that other
    loss detectors are fine for specific cases.

  - The first paragraph in the intro also makes clear we adopt the
    loss =3D=3D congestion model (as that is the conservative default,
    not because it is always true).

  - I made one other change that wasn't exactly called for, but
    seems like an oversight.

    Previously guideline (4) said loss MUST be taken as an
    indication of congestion and some standard response taken.  But,
    this guideline has an explicit exception for cases where we know
    the loss was caused by some non-congestion event.  Guideline (3)
    says you MUST backoff.  But, it did not have this exception for
    cases where we can tell the cause.  But, I think based on the
    spirit of (4), (3) should also have these words.  So, I added
    them.

    Also, I swapped (3) and (4) because it seemed more natural in
    re-reading to first think about taking congestion action and
    then dealing with backoff.  I think the ordering is a small
    thing, but folks can yell and I'll put it back if there is
    angst.

Please take a look and let me know if this helps things along or
not.

allman

--=_MailMate_966D57F8-BB69-424D-B202-762EE2016A5E_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXt6W8BEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizsTOAJ0fe++7CapKHCg4F7h6DS2KjfnPAACcCmKu
3Fwxt3YPT/KDetcqu4HBP2A=
=zBsx
-----END PGP SIGNATURE-----

--=_MailMate_966D57F8-BB69-424D-B202-762EE2016A5E_=--


From nobody Thu Jun 11 09:42:08 2020
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 BFDFE3A0AAE for ; Thu, 11 Jun 2020 09:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Level: 
X-Spam-Status: No, score=-1.317 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, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=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 IU6WI9dnB79n for ; Thu, 11 Jun 2020 09:42:04 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 914093A0AAA for ; Thu, 11 Jun 2020 09:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-Id:To:References:Subject:Date: Mime-Version:Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2P5TvnDN/78M04vMa7jbdBin1ZAZGgOvQd94zqrcJwM=; b=UY9BpPXDwyBjJnAYIOMY2GzALI ZC1DfCXzx2j2WEGPy81oY1t/V8WIFHvi33TQFvjjZhwEXmdN6HqWTTMI9Bl+N3am+OhqiL05w/v+2 BMf8YNWW6e1K8TOvIVJQmqHIjvFU3MIHJ2X/0hjRsNpbIPNoEtV5gAAHnmm7ePVGxhZbpdpc6J+HO 8aLT6JnAutx2wAgrCwicNL7++Ack/j/dbeKqi1wCXQis+SBAckkEJKArcrh390JJnQadoF+eRxuhl odrG3Q2ulNrj0vKZ6t+gkF/9swxwSyDv9q6fecGCbuxdQTUPRCqsDlF8zRXl6divaAfAKIWeW7ZWR 5JKocY0Q==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50659 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjQH9-001Txp-DY; Thu, 11 Jun 2020 12:42:04 -0400
From: Joseph Touch 
Content-Type: multipart/alternative; boundary="Apple-Mail=_5ED3B6BC-309A-4AA5-8D66-9FD1638881C3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 11 Jun 2020 09:41:58 -0700
References: <159188596290.9425.8299035963321046830@ietfa.amsl.com>
To: "tcpm@ietf.org Extensions" 
Message-Id: <5141465E-1510-40B7-8146-64C48C167DB3@strayalpha.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-ao-test-vectors-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2020 16:42:07 -0000

--Apple-Mail=_5ED3B6BC-309A-4AA5-8D66-9FD1638881C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, all,

The draft below provides test vectors for TCP-AO, as per Juhamatt=E2=80=99=
s thread that began on 3/31/2020.=20

Feedback welcome.

Joe

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-touch-tcpm-ao-test-vectors-00.txt
> Date: June 11, 2020 at 7:32:42 AM PDT
> To: "Joe Touch" , "Juhamatti Kuusisaari" =
, "Joseph Touch" 
>=20
>=20
> A new version of I-D, draft-touch-tcpm-ao-test-vectors-00.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
>=20
> Name:		draft-touch-tcpm-ao-test-vectors
> Revision:	00
> Title:		TCP-AO Test Vectors
> Document date:	2020-06-11
> Group:		Individual Submission
> Pages:		16
> URL:            =
https://www.ietf.org/internet-drafts/draft-touch-tcpm-ao-test-vectors-00.t=
xt
> Status:         =
https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vectors/
> Htmlized:       =
https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-00
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-vectors
>=20
>=20
> Abstract:
>   This document provides test vectors to validate implementations of
>   the two mandatory authentication algorithms specified for the TCP
>   Authentication Option over both IPv4 and IPv6. This includes
>   validation of the key derivation function (KDF) based on a set of
>   test connection parameters as well as validation of the message
>   authentication code (MAC). Vectors are provided for both currently
>   required pairs of KDF and MAC algorithms: one based on SHA-1 and the
>   other on AES-128. The vectors also validate both whole TCP segments
>   as well as segments whose options are excluded for NAT traversal.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20


--Apple-Mail=_5ED3B6BC-309A-4AA5-8D66-9FD1638881C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, =
all,

The draft below =
provides test vectors for TCP-AO, as per Juhamatt=E2=80=99s thread that began on =
3/31/2020. 

Feedback welcome.

Joe

Begin =
forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
New Version =
Notification for draft-touch-tcpm-ao-test-vectors-00.txt
Date: =
June 11, 2020 at 7:32:42 AM =
PDT
To: =
"Joe Touch" <touch@strayalpha.com>, "Juhamatti Kuusisaari" <jkuusisaari@infinera.com>, "Joseph Touch" <touch@strayalpha.com>


A new version =
of I-D, draft-touch-tcpm-ao-test-vectors-00.txt
has been =
successfully submitted by Joe Touch and posted to the
IETF =
repository.

Name:		=
draft-touch-tcpm-ao-test-vectors
Revision:	00
Title:=
		=
TCP-AO Test Vectors
Document date:	=
2020-06-11
Group:		Individual Submission
Pages:=
		=
16
URL: =
           https://www.ietf.org/internet-drafts/draft-touch-tcpm-ao-test-v=
ectors-00.txt
Status: =
        https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vecto=
rs/
Htmlized:       https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-00=

Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-=
vectors


Abstract:
   This document provides test vectors to validate =
implementations of
   the two mandatory =
authentication algorithms specified for the TCP
 =
  Authentication Option over both IPv4 and IPv6. This =
includes
   validation of the key derivation =
function (KDF) based on a set of
   test =
connection parameters as well as validation of the message
 =
  authentication code (MAC). Vectors are provided for both =
currently
   required pairs of KDF and MAC =
algorithms: one based on SHA-1 and the
   other =
on AES-128. The vectors also validate both whole TCP segments
   as well as segments whose options are excluded =
for NAT traversal.




Please note that it may take a couple of =
minutes from the time of submission
until the htmlized =
version and diff are available at tools.ietf.org.

The IETF =
Secretariat



=

--Apple-Mail=_5ED3B6BC-309A-4AA5-8D66-9FD1638881C3--


From nobody Thu Jun 11 09:43:06 2020
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 034073A0AB0 for ; Thu, 11 Jun 2020 09:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=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 9ZjGCy2L8u_J for ; Thu, 11 Jun 2020 09:43:03 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 4494F3A0AAA for ; Thu, 11 Jun 2020 09:43:03 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BqqKBxJ2WjWJvFuptntBOWdsgrVAe6d8MXJcmZA9RHQ=; b=CsS8mJ0drrNu+u53YUwcLfVXX Yb9NvJOTyfGyBn/SoTzem3EqUCbn8VU3Z/8t+OQm1vEXyOs3uHtXrEpw78H8bbI5qQV7SrbsldGMF mTHGPopz74Buuwlp5mehaMTHXK7/SN5KqgewyXa+7dxbtL0rciv7fDrDm3bqig1BN43dwKP4Y0uu4 kN+rFLytVVopnWzYs9IH5mhYvfriLyoddfYybvlZ8SA5VhNhtT3mA/JN1p7Yd7/N5c45/yqzn/xhr 4SUfp3zK+pGZBzbgHPysMny9hyDAy3gxzXGyypSHHiUtThsm0WSiTm9zvAQnz4mJHdiR19KSiD6an T9o54pPNg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50659 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjQI6-001Txp-CO; Thu, 11 Jun 2020 12:43:02 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_0F9E451D-3191-4C0A-AAB5-318B898AA5A6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC3B40E@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Thu, 11 Jun 2020 09:42:58 -0700
Cc: "juhamatk@gmail.com" , "tcpm@ietf.org" 
Message-Id: <60CD1EE5-99D2-4E33-BB56-A8BC0D6F0261@strayalpha.com>
References:    <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de>  <6EC6417807D9754DA64F3087E2E2E03E2DC3B40E@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] Test vectors for RFC5925 algorithms?
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, 11 Jun 2020 16:43:06 -0000

--Apple-Mail=_0F9E451D-3191-4C0A-AAB5-318B898AA5A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks. At this time, I haven=E2=80=99t included this sort of product =
reference to the draft, but it is useful to know.

Joe

> On Jun 8, 2020, at 12:21 AM, Scharf, Michael =
 wrote:
>=20
> Hi Joe,
> =20
> Page 700 of link [1] references RFC 5925 and RFC 5926.
> =20
> I don=E2=80=99t have access to a Nokia router to actually test the =
implementation. Yet, as far as I know, listing an RFC in the standard =
compliance lists of a Nokia product implies that the standard is indeed =
implemented.
> =20
> Michael
> =20
> From: Joseph Touch >=20
> Sent: Sunday, June 7, 2020 10:52 PM
> To: Scharf, Michael >
> Cc: juhamatk@gmail.com ; tcpm@ietf.org =

> Subject: Re: [tcpm] Test vectors for RFC5925 algorithms?
> =20
> Hi, Michael,
> =20
> The link below doesn=E2=80=99t appear to reference TCP-AO. Do you know =
of a link with a more direct reference?
> =20
> Joe
>=20
>=20
> On Apr 16, 2020, at 9:31 AM, Scharf, Michael =
> =
wrote:
> =20
> Have you checked other router vendors? For instance, the public Cisco =
IOS XE
> documentation lists TCP-AO support. And I have also heard that another =
main
> router vendor may implement TCP-AO (well, I am not familiar with =
Juniper).
>=20
> I am aware that Cisco has an implementation. It is quite new, and
> unfortunately I do have experience of it. If someone has, then that
> may well be a very good candidate for test vectors.
>=20
> Coming back to this, as I have just found another document: According =
to reference [1], Nokia SROS implements TCP-AO as well.
>=20
> Michael
>=20
>=20
> [1] Nokia SROS documentation at =
https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE15811AAAAT=
QZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Basic%20System=
%20Configuration%20Guide%2020.2.R1.pdf =


--Apple-Mail=_0F9E451D-3191-4C0A-AAB5-318B898AA5A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks. At this time, I haven=E2=80=99t included this sort of =
product reference to the draft, but it is useful to know.

Joe
On Jun =
8, 2020, at 12:21 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Hi Joe,
 
Page 700 of link [1] references RFC 5925 and RFC 5926.
 
I =
don=E2=80=99t have access to a Nokia router to actually test the =
implementation. Yet, as far as I know, listing an RFC in the standard =
compliance lists of a Nokia product implies that the standard is indeed =
implemented.
 
Michael
 
From: Joseph Touch <touch@strayalpha.com> 
Sent: Sunday, June 7, 2020 10:52 =
PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
Cc: juhamatk@gmail.com; tcpm@ietf.org
Subject: Re: [tcpm] Test vectors for =
RFC5925 algorithms?
 
Hi, Michael,
 
The link below doesn=E2=80=99t appear to =
reference TCP-AO. Do you know of a link with a more direct =
reference?
 
Joe


On Apr 16, =
2020, at 9:31 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
 
Have you checked other router =
vendors? For instance, the public Cisco IOS XE
documentation lists TCP-AO support. =
And I have also heard that another main
router vendor may =
implement TCP-AO (well, I am not familiar with Juniper).
I am aware that Cisco has an implementation. It is quite =
new, and
unfortunately I do have experience of it. If =
someone has, then that
may well be a very good candidate =
for test vectors.

Coming=
 back to this, as I have just found another document: According to =
reference [1], Nokia SROS implements TCP-AO as well.

Michael


[1] Nokia =
SROS documentation at https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3H=
E15811AAAATQZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Bas=
ic%20System%20Configuration%20Guide%2020.2.R1.pdf

=

--Apple-Mail=_0F9E451D-3191-4C0A-AAB5-318B898AA5A6--


From nobody Thu Jun 11 13:44:06 2020
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 D66463A084C; Thu, 11 Jun 2020 13:44:04 -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, 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 yiDBSa15bENd; Thu, 11 Jun 2020 13:44:01 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CB4713A084B; Thu, 11 Jun 2020 13:44:00 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id o5so7905706iow.8; Thu, 11 Jun 2020 13:44:00 -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=uMO52Pn+UnggQY0y7vV97/6H2hZ9d2OiqvZ/W96SppM=; b=W20x8m7+apjIUNvW4jhexGathuUlbZyNqltPytdCY7rjhJo9r3s8OT8aQFb6ne9Jzp Gv54VidSv42dGLw8uL3PkeJSfU0Nsg6FNmKNflZ6L/5orO1AXXSq14VDBtETLhVt3o0z Ho5q0JP8F/Xr4JbuSDqlt/ZKN5OIV69BdCMaw8XBSlB8m1PFocA5VM9sejwZrel3nfY1 hQOUwlpUyAW0J4nfrgiYVQYX4KRvtl++bz36+sFochdAUiHA8AAyjiHZpiVZ1CGWm9WF jxrTNPE/0LydPNPZG3Iwk6ERS4GqzlVLD9ah3SfbOSnatf7/0w0Tuj1DMcpXtkEKsrpi gXsA==
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=uMO52Pn+UnggQY0y7vV97/6H2hZ9d2OiqvZ/W96SppM=; b=fP1jEZM6cpau/6x1VuMsywAtAmu9kKNzYAhIo/K1iSFSsP+M6t/YYG5acqvzgVlbGN IAeywZev7TfMlSOu2PgP2YE60Q37naXe5Yu2C7E+jmDWWjMhvVlsyQRfYzJOYojrem57 jsiYD3AxmU+xDQLlLE666/aVKMLI/tOH5HsQq9Yjh9VjjAJF8ggGpF2mMDwEXbVuF2nf Fr8o5upHTz4ZYT7uuCMokWPWyxdnsHbJXhr3RngpMZjtD0KHIJv30mYvXYfAjp5i39N5 EKfhCyT0jvwH5Cw5FkDGV2+lh3G9GlWXyc75rA9/H4gl9QIwOoRoNT2CkFSC151YBk0j UlHA==
X-Gm-Message-State: AOAM532oprnwN0duemdzR4PTNetFUHveLPAEHOVgHrWVKMWH96B/x9J1 4B9ar7NXrOZBaYpSAOsN0x/1/omgrZPbMMPkfEifIK04M7g=
X-Google-Smtp-Source: ABdhPJwWomRFr+TXxUcd9UNmg2l3HrqXB2h6j+Uiv0Rv5w8CYi5kk8QI/tkvf+JUZDFXYW/W12uBOjh13Bc+GOjYUHM=
X-Received: by 2002:a02:37d4:: with SMTP id r203mr5045375jar.121.1591908239586;  Thu, 11 Jun 2020 13:43:59 -0700 (PDT)
MIME-Version: 1.0
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> 
In-Reply-To: 
From: Martin Duke 
Date: Thu, 11 Jun 2020 13:43:48 -0700
Message-ID: 
To: tom petch 
Cc: Mark Allman , tom petch ,  Last Call , tcpm ,  "draft-ietf-tcpm-rto-consider@ietf.org" ,  "tcpm-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000022b7da05a7d50567"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 11 Jun 2020 20:44:05 -0000

--00000000000022b7da05a7d50567
Content-Type: text/plain; charset="UTF-8"

Tom,

does draft-15 address your concerns?

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt


On Mon, Jun 8, 2020 at 1:28 AM tom petch  wrote:

> From: tcpm  on behalf of Mark Allman <
> mallman@icir.org>
> Sent: 05 June 2020 17:16
>
> > Mark, that is what I am questioning,
>
> well ...
>
> > that by default loss implies congestion.  Historically true for
> > the IETF but I think that there are a growing number of cases
> > where it is not true as in a post I saw on another WG list this
> > week where a document was saying that loss MUST NOT be taken as an
> > indication of congestion so the MUST in this I-D I find too
> > strong.
>
> OK.  So, I am not sure what to do here.  I will say several things ...
>
> 
> Mark, what I would like to see is a statement up front, Introduction or
> just after, along the lines that the document (mostly?) assumes that loss
> is due to congestion which has historically been the case in the Internet
> and is likely still largely the case in the Internet and the
> recommendations here are designed to reduce that congestion .  but that
> there will be networks where loss is not due to congestion in which case
> the recommendations here MAY adversely affect the performance of the
> network.
> I would not give an example but if one is needed, then it would be loss
> caused by a burst of interference where backing off simply slows down the
> rate unnecessarily.
>
> Tom Petch
>
> (1) I believe that as a general, default the document is quite right
>     in specifying a congestion response and exponential backoff.
>
> (2) I believe consensus of the WGs has been the same as my notion in
>     (1) for some time now.  So, even setting aside (1), I am not
>     sure I feel like I have carte blanche to change this.
>
> (3) I do not believe loss always means congestion and I do not
>     believe assuming such is always correct or should always be
>     done.  I don't think I know anyone who thinks that.  So, the
>     document explicitly says that is fine, just go get consensus
>     that some other approach is fine.  (And, that should be
>     happening regardless of this document, so I am not sure what the
>     big deal is here.)
>
> So, basically, I am not sure what to do here.  Maybe one of the ADs
> can help.  Or, maybe we can set this aside and I can do the things I
> told you I'd do and a little extra framing will make this better.  I
> am all ears for advice here.
>
> (BTW, I have a half response to Stewart, as well.  I am not ignoring
> his review.  I am just behind.)
>
> allman
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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


On Mon, Jun 8, 2020 at 1:28 AM tom petch <ietfa@btconnect.com> wrote:
From: tcpm <tcpm-bounces@ietf.org> on beh=
alf of Mark Allman <mallman@icir.org>

Sent: 05 June 2020 17:16



> Mark, that is what I am questioning,



well ...



> that by default loss implies congestion.=C2=A0 Historically true for
> the IETF but I think that there are a growing number of cases

> where it is not true as in a post I saw on another WG list this

> week where a document was saying that loss MUST NOT be taken as an

> indication of congestion so the MUST in this I-D I find too

> strong.



OK.=C2=A0 So, I am not sure what to do here.=C2=A0 I will say several thing=
s ...



<tp>

Mark, what I would like to see is a statement up front, Introduction or jus=
t after, along the lines that the document (mostly?) assumes that loss is d=
ue to congestion which has historically been the case in the Internet and i=
s likely still largely the case in the Internet and the recommendations her=
e are designed to reduce that congestion .=C2=A0 but that there will be net=
works where loss is not due to congestion in which case the recommendations=
 here MAY adversely affect the performance of the network.

I would not give an example but if one is needed, then it would be loss cau=
sed by a burst of interference where backing off simply slows down the rate=
 unnecessarily.



Tom Petch



(1) I believe that as a general, default the document is quite right

=C2=A0 =C2=A0 in specifying a congestion response and exponential backoff.<=
br>


(2) I believe consensus of the WGs has been the same as my notion in

=C2=A0 =C2=A0 (1) for some time now.=C2=A0 So, even setting aside (1), I am=
 not

=C2=A0 =C2=A0 sure I feel like I have carte blanche to change this.



(3) I do not believe loss always means congestion and I do not

=C2=A0 =C2=A0 believe assuming such is always correct or should always be
=C2=A0 =C2=A0 done.=C2=A0 I don't think I know anyone who thinks that.=
=C2=A0 So, the

=C2=A0 =C2=A0 document explicitly says that is fine, just go get consensus<=
br>
=C2=A0 =C2=A0 that some other approach is fine.=C2=A0 (And, that should be<=
br>
=C2=A0 =C2=A0 happening regardless of this document, so I am not sure what =
the

=C2=A0 =C2=A0 big deal is here.)



So, basically, I am not sure what to do here.=C2=A0 Maybe one of the ADs
can help.=C2=A0 Or, maybe we can set this aside and I can do the things I
told you I'd do and a little extra framing will make this better.=C2=A0=
 I

am all ears for advice here.



(BTW, I have a half response to Stewart, as well.=C2=A0 I am not ignoring
his review.=C2=A0 I am just behind.)



allman



_______________________________________________

tcpm mailing list

tcpm@ietf.org

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




--00000000000022b7da05a7d50567--


From nobody Thu Jun 11 13:45:53 2020
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 626603A0853; Thu, 11 Jun 2020 13:45:45 -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, 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 rBVRAGqv60yJ; Thu, 11 Jun 2020 13:45:41 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 AA8133A085C; Thu, 11 Jun 2020 13:45:26 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id p20so7889582iop.11; Thu, 11 Jun 2020 13:45:26 -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=jea2grN09+/ALKqYsy8z/eaYmdg9j1nRozhXIz1Xg1k=; b=KM6W9s1UuDr88MNs4/dcx0ymo4D2/rkmMillX5+LDbQcTKmJJUCFdxX0MwplFoafmB aBnORUKxsVIQFifoz0PHl+Th10kxZUAJnUe7bm1Nfg0DSlKbriLhZbWHYJn0b8VYf3aH UpTRKZ7ohG41sP59iUtTlxe8S87f6WlEfCeEm6Yx4zdIuaSUd/WN+jINZYjV7OcsxcPr w0SlfDeQwK8CgwL3XfgKpm8emlVydAX09b3+E9cvctacTh3GLGu1+UhKZXOp1zYie/0A VGBzw1vS15SFC0O14E8+d2CbeJDoeQSrOIwd0fA1Rmt5LhNTAMgWb0k5GY7nLuNdVnj1 pD3g==
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=jea2grN09+/ALKqYsy8z/eaYmdg9j1nRozhXIz1Xg1k=; b=QNTZe/B2ATrJjTJF8q9/dCwZ0+S7XYsDXK/IzrW2ZgOaZ5TwzlMkyw3ci/mwyVt7Xu IirQaa8abGeB7rVve2qQn+19x9ZgCrP8l1Vj29eUx8k9fP8j3OCivihdJ6tkNumU81xZ f/S6v3vAi1pkhS5v7y6ElX6AoLlOI/tnC8wEkFLU+ECPgKd2/M3vc27HouCp9lXR8g4u WGzfpBUEWv3X6vFZu8FkiPvmsen5CuAVRBE2orTicDgf7i7fNkSBg2IaflyryqPIjKq4 ZfQGrZXWLis1yLiO0XLKSBa987UvcM/DvrpFKhGD/3EmbB876lSObOri9m+dvyipjYtZ AN+A==
X-Gm-Message-State: AOAM531SI1DKg6VoOkHCg9Zmd40MHqyQBTCZv9TM+RYueaKLs2XMdL6E 5NY1q5DMoLDfddCOEb+C9GU5PTMnWfz/gdXsyRU=
X-Google-Smtp-Source: ABdhPJx2PgI594rQ1l83l/S1KST91gyli0kdMSb4uMbj4dMrZIGMXrj4u5Pb3iw3SmkM0rGb13tXtpLnn4e/UBoj0qM=
X-Received: by 2002:a02:cc56:: with SMTP id i22mr4992527jaq.31.1591908325869;  Thu, 11 Jun 2020 13:45:25 -0700 (PDT)
MIME-Version: 1.0
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>
In-Reply-To: <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>
From: Martin Duke 
Date: Thu, 11 Jun 2020 13:45:14 -0700
Message-ID: 
To: Mark Allman 
Cc: Stewart Bryant , Review Team ,  tcpm ,  Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org,  tom petch 
Content-Type: multipart/alternative; boundary="000000000000474f6905a7d50af4"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 11 Jun 2020 20:45:45 -0000

--000000000000474f6905a7d50af4
Content-Type: text/plain; charset="UTF-8"

Stewart,

do we need more cycles for this, or is draft-15 sufficient to address your
concerns?

On Mon, Jun 8, 2020 at 12:52 PM Mark Allman  wrote:

>
> Hi Stewart, et.al.!
>
> I just submitted a new version of rto-consider.  Please ask the
> datatracker for diffs between this and rev -14.  The highlights:
>
>   - The diffs with the last rev are here:
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>
>   - All small comments addressed.
>
>   - I think we all agree that this is not a one-size-fits-all
>     situation.  Rather, this document is meant to be a default case.
>     So, the main action of this rev is to make that point more
>     clearly.  The first paragraph in the intro is new.  Also, there
>     are some more words fleshing out the context more in section 2.
>     In particular, more emphatically making the point that other
>     loss detectors are fine for specific cases.
>
>   - The first paragraph in the intro also makes clear we adopt the
>     loss == congestion model (as that is the conservative default,
>     not because it is always true).
>
>   - I made one other change that wasn't exactly called for, but
>     seems like an oversight.
>
>     Previously guideline (4) said loss MUST be taken as an
>     indication of congestion and some standard response taken.  But,
>     this guideline has an explicit exception for cases where we know
>     the loss was caused by some non-congestion event.  Guideline (3)
>     says you MUST backoff.  But, it did not have this exception for
>     cases where we can tell the cause.  But, I think based on the
>     spirit of (4), (3) should also have these words.  So, I added
>     them.
>
>     Also, I swapped (3) and (4) because it seemed more natural in
>     re-reading to first think about taking congestion action and
>     then dealing with backoff.  I think the ordering is a small
>     thing, but folks can yell and I'll put it back if there is
>     angst.
>
> Please take a look and let me know if this helps things along or
> not.
>
> allman
>

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


Stewart,

do we need more cycles for thi=
s, or is draft-15 sufficient to address your concerns?

On Mon, Jun 8, =
2020 at 12:52 PM Mark Allman <mallma=
n@icir.org> wrote:


Hi Stewart, e=
t.al.!



I just submitted a new version of rto-consider.=C2=A0 Please ask the

datatracker for diffs between this and rev -14.=C2=A0 The highlights:



=C2=A0 - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?=
difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-rto-consider-15.txt



=C2=A0 - All small comments addressed.



=C2=A0 - I think we all agree that this is not a one-size-fits-all

=C2=A0 =C2=A0 situation.=C2=A0 Rather, this document is meant to be a defau=
lt case.

=C2=A0 =C2=A0 So, the main action of this rev is to make that point more
=C2=A0 =C2=A0 clearly.=C2=A0 The first paragraph in the intro is new.=C2=A0=
 Also, there

=C2=A0 =C2=A0 are some more words fleshing out the context more in section =
2.

=C2=A0 =C2=A0 In particular, more emphatically making the point that other<=
br>
=C2=A0 =C2=A0 loss detectors are fine for specific cases.



=C2=A0 - The first paragraph in the intro also makes clear we adopt the

=C2=A0 =C2=A0 loss =3D=3D congestion model (as that is the conservative def=
ault,

=C2=A0 =C2=A0 not because it is always true).



=C2=A0 - I made one other change that wasn't exactly called for, but
=C2=A0 =C2=A0 seems like an oversight.



=C2=A0 =C2=A0 Previously guideline (4) said loss MUST be taken as an

=C2=A0 =C2=A0 indication of congestion and some standard response taken.=C2=
=A0 But,

=C2=A0 =C2=A0 this guideline has an explicit exception for cases where we k=
now

=C2=A0 =C2=A0 the loss was caused by some non-congestion event.=C2=A0 Guide=
line (3)

=C2=A0 =C2=A0 says you MUST backoff.=C2=A0 But, it did not have this except=
ion for

=C2=A0 =C2=A0 cases where we can tell the cause.=C2=A0 But, I think based o=
n the

=C2=A0 =C2=A0 spirit of (4), (3) should also have these words.=C2=A0 So, I =
added

=C2=A0 =C2=A0 them.



=C2=A0 =C2=A0 Also, I swapped (3) and (4) because it seemed more natural in=


=C2=A0 =C2=A0 re-reading to first think about taking congestion action and<=
br>
=C2=A0 =C2=A0 then dealing with backoff.=C2=A0 I think the ordering is a sm=
all

=C2=A0 =C2=A0 thing, but folks can yell and I'll put it back if there i=
s

=C2=A0 =C2=A0 angst.



Please take a look and let me know if this helps things along or

not.



allman




--000000000000474f6905a7d50af4--


From nobody Fri Jun 12 02:48:03 2020
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 633043A0ED0; Fri, 12 Jun 2020 02:47:56 -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 6QKvVJqNsVqO; Fri, 12 Jun 2020 02:47:52 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80102.outbound.protection.outlook.com [40.107.8.102]) (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 C6D373A0A9D; Fri, 12 Jun 2020 02:47:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEvZ4O91Oc/ybg2ADQ5AsVeM7ZziNiId41BiDjaz4suwApP54SGwo518VrT7Tbv6ObTzEFHpVaE2HySGT1e7/5nic8Z1xHz+VQunbSy4xFCBM+J9fkRnhDttAZmD5sSTO9lHdGfV0P5KA0grNICDySBR6DDkmyAsuilVIMa0Qfb+7Y8V8KJ/G0kKfVBxKr1GTdgKLNLcTlUKo8DMgM68McaEeaEpzamRSiAYgOAZX5ZFsg/919qRPNrZp9GFJqMI9CLhyjPfQrj7Zf1TJFsuahJF0Yl3/bFYynGav8exVsI8APFfx8pq08/1oWtfb7f07Pc0Kp4RcM9wYbHiSzS83A==
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=hgCFBLiiPOUxNsn5gHnHRgHOc3y2ESYcL0L70xsvEZ0=; b=Yx724NkTxqXimIlxDgPaielmfDKKbUcFjQJ3phPAO+3N8XOEKFSf2MkLVbIPWMD3ozvfpvN4taycPpnKZnkP0QeJt9YOzLmtXIRfbAafOw2fzzo4gOl4QJ5+iubyb9SnJn/u7M1WPwKmfebRKi6bvmr4jVWFwmOsD/uYtLwitmBD1rqfdeKRkulrPqTaP3oyCB9FV9hNRYJCq9t2OwMOf2X/i6L+hXY6MqzBYq4XyB1KAJG4fz5k7qH17lFpDjdLFrG3ORLpmlp7abBCWAwY6AKF3RS+stR8hpZBxIN4k4McGkQgvC+Q6vTw+dE45mMZeNYt4WJL5o0T0hcDyQXelg==
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=hgCFBLiiPOUxNsn5gHnHRgHOc3y2ESYcL0L70xsvEZ0=; b=wFJhM5pIzurVFd6f3LQ6D9roag4tR2DpMD8tknTqcVSQrvdPznSeZhqSqq/wLAnT3t1JM11dkUb0x1uSdWo59R+C4JKSEV6+4kzKukZx55Ofxuzs17xSAawonwLssaUYJV57HkBnwGah6xWOT0pWvnYKle1EaZir3WSdSu0qg5s=
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB4537.eurprd07.prod.outlook.com (2603:10a6:5:2c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Fri, 12 Jun 2020 09:47:48 +0000
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4%7]) with mapi id 15.20.3088.019; Fri, 12 Jun 2020 09:47:48 +0000
From: tom petch 
To: Martin Duke 
CC: Mark Allman , Last Call , tcpm , "draft-ietf-tcpm-rto-consider@ietf.org" , "tcpm-chairs@ietf.org" 
Thread-Topic: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
Thread-Index: AQHWNQ2m9gFeETvyo0Wr/I+Dg676t6i+70PggAAUpICAAX7IgIAJg2SAgAAyuICAAAaRgIAEMVRigAWHOACAANi/hA==
Date: Fri, 12 Jun 2020 09:47:48 +0000
Message-ID: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> , 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5decd967-5d08-455d-737c-08d80eb5aa80
x-ms-traffictypediagnostic: DB7PR07MB4537:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ICQqosQiS4QTrDCp2aCd12VbDbXgY6QTokyzP1PBjzCgFkfrOC0TmmTJ42BL+4OQ9WDqVtqw4TDD2Go7iXd+nRCuGHjMryzZbjqhtX5QaQV4Ng6oAnhE3FV+HSsa8Lah+WQRf0yXB1PDi8mgE4IfvG77xRSFO2wBwBRFcw+nIwub61xeK6BSP2MT9tX4u6w7nAynQELORCyGp3qa1nqUN88ie4LEx9d97OWN+CQjz3ckXhHxI1R1ASsS2vP30bfuj51u+DrSK1+JCcJUbg5i7NcpaxeJ1bb5P3ruv8Kg7QxzuD4e/TdT3upiHUGWENj3VlyiX9b2W8GVVS22lYlVTaRZKS0GyJ5xQ0/B6rkZQw9p6WciGmQLhmVOehwr73467gE4GGxS+nHwXQGx52Qmsg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(376002)(366004)(396003)(346002)(136003)(8676002)(6916009)(66476007)(66556008)(66446008)(86362001)(64756008)(71200400001)(26005)(55016002)(966005)(83380400001)(53546011)(478600001)(66574014)(91956017)(4326008)(8936002)(6506007)(76116006)(186003)(66946007)(33656002)(2906002)(52536014)(5660300002)(316002)(54906003)(9686003)(7696005); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: OExnP2+1HfiQAtvjJpnwjz0xUyvqmwI5zTeSHIP7M969r1SBD90T6DjFJ1ksB+sTCrpGGXJEfwmmeYpsXdsLKr+I4HSaLhwf/TB1kY8ma4P9te7dG8u1G1XfsH5W8J3doZDYFdOqZajT8p0lHQKT1MtGXATJFADPABS1rS2pFKYYIGBD/fjb4hNY7naewVpfEfMAsh+oR74OHAeMzOcOspeqopF9Gu3bjA07YJQaRs5ut/TbjCe8kqiqmJFnFlU7NpqbozIAiVmLbKSjZSQv2DG6rpbVn8k9DLJOcFAnZrK3d7wKcW4vWZRe7ueYrG+1ZZYewGJePn1UHpcXDnwGbUlZsGU9sQnH6pvO4Qd1yL5aJQp3xer7K9Sefj/z19BX0HMuK5+bFkvcMpARddb/F+d6vy6pYwKWaOf0ZxX7AcSnLkr4sVsSh3VWc4v0yFYDi7FP7PTXRGqM+SMX3qQyVVLTnhB9dddu9FXa2SkO2/o=
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-Network-Message-Id: 5decd967-5d08-455d-737c-08d80eb5aa80
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 09:47:48.2789 (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: U9RC5T7ihYp+nJwtuD64LPjozVnvOBjO3e8JHteTDobUvndzs/4GViBdLD+xGostI+AfX7gWW8iQ7vjZUUUGmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4537
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 09:47:57 -0000

From: Martin Duke =0A=
Sent: 11 June 2020 21:43=0A=
=0A=
Tom,=0A=
=0A=
does draft-15 address your concerns?=0A=
=0A=
Martin=0A=
=0A=
yes it does.  The new first paragraph makes a world of difference to me.=0A=
I omitted to mention some editorial issues before.=0A=
=0A=
Terminology the boiler plate is out of date=0A=
=0A=
s,2=0A=
This document is different from from ...=0A=
=0A=
Requirements=0A=
would be easier to refer to if they were R1, R2a or some such=0A=
=0A=
a reference for DNS recursive resolver would be good=0A=
=0A=
EWMA needs  expanding on first use=0A=
=0A=
Tom Petch=0A=
=0A=
https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-r=
to-consider-15.txt=0A=
=0A=
=0A=
=0A=
On Mon, Jun 8, 2020 at 1:28 AM tom petch > wrote:=0A=
From: tcpm > on behalf =
of Mark Allman >=0A=
Sent: 05 June 2020 17:16=0A=
=0A=
> Mark, that is what I am questioning,=0A=
=0A=
well ...=0A=
=0A=
> that by default loss implies congestion.  Historically true for=0A=
> the IETF but I think that there are a growing number of cases=0A=
> where it is not true as in a post I saw on another WG list this=0A=
> week where a document was saying that loss MUST NOT be taken as an=0A=
> indication of congestion so the MUST in this I-D I find too=0A=
> strong.=0A=
=0A=
OK.  So, I am not sure what to do here.  I will say several things ...=0A=
=0A=
=0A=
Mark, what I would like to see is a statement up front, Introduction or jus=
t after, along the lines that the document (mostly?) assumes that loss is d=
ue to congestion which has historically been the case in the Internet and i=
s likely still largely the case in the Internet and the recommendations her=
e are designed to reduce that congestion .  but that there will be networks=
 where loss is not due to congestion in which case the recommendations here=
 MAY adversely affect the performance of the network.=0A=
I would not give an example but if one is needed, then it would be loss cau=
sed by a burst of interference where backing off simply slows down the rate=
 unnecessarily.=0A=
=0A=
Tom Petch=0A=
=0A=
(1) I believe that as a general, default the document is quite right=0A=
    in specifying a congestion response and exponential backoff.=0A=
=0A=
(2) I believe consensus of the WGs has been the same as my notion in=0A=
    (1) for some time now.  So, even setting aside (1), I am not=0A=
    sure I feel like I have carte blanche to change this.=0A=
=0A=
(3) I do not believe loss always means congestion and I do not=0A=
    believe assuming such is always correct or should always be=0A=
    done.  I don't think I know anyone who thinks that.  So, the=0A=
    document explicitly says that is fine, just go get consensus=0A=
    that some other approach is fine.  (And, that should be=0A=
    happening regardless of this document, so I am not sure what the=0A=
    big deal is here.)=0A=
=0A=
So, basically, I am not sure what to do here.  Maybe one of the ADs=0A=
can help.  Or, maybe we can set this aside and I can do the things I=0A=
told you I'd do and a little extra framing will make this better.  I=0A=
am all ears for advice here.=0A=
=0A=
(BTW, I have a half response to Stewart, as well.  I am not ignoring=0A=
his review.  I am just behind.)=0A=
=0A=
allman=0A=
=0A=
_______________________________________________=0A=
tcpm mailing list=0A=
tcpm@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tcpm=0A=


From nobody Fri Jun 12 02:56:47 2020
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 DDB113A0EE1; Fri, 12 Jun 2020 02:56:44 -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, 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 LyzSkhrZol73; Fri, 12 Jun 2020 02:56: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 DCD0F3A0ED9; Fri, 12 Jun 2020 02:56:42 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 18A9B25A12; Fri, 12 Jun 2020 11:56:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1591955801; bh=cpOvTPeEvIEdmQ6bz675dWCKbKsrAZQAD2/jdQ/a9U8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=GyNOPt1IMK311qTs6e/Z119qUgtX+hQLWdgkZ25YVuzSJd77REOBjaIifllD1KQsq QJIK9nqldP2MK9swHqGtP0B+U/b2Q3wO8jAJ/VhNxcW0YcCTc1NKFgHXFWQ38PF5Vm 0rRXWCc2IEJEGv/H/QOCdDgFxBRhaG65Oq+tmi28=
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 qcsY5i5isEqZ; Fri, 12 Jun 2020 11:56:39 +0200 (CEST)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 12 Jun 2020 11:56:39 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 12 Jun 2020 11:56:39 +0200
From: "Scharf, Michael" 
To: "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: WGLC for draft-ietf-tcpm-2140bis
Thread-Index: AdY2q5V4X+rIUW7ARceWWppze0a72wJ8zu+Q
Date: Fri, 12 Jun 2020 09:56:39 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de>
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-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.48.165]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 12 Jun 2020 09:56:45 -0000

Hi all,

I haven't seen any reply so far. Lack of _any_ feedback is not a particular=
ly good sign.

Anyway, no feedback implies that the document is ready to move forward. How=
ever, even in that case explicit support for publication  would be _really_=
 useful. A simple "+1" could be enough...

I'll extend the WGLC by one week until June 21 to give the community some a=
dditional time to comment.

Thanks

Michael


> -----Original Message-----
> From: Scharf, Michael 
> Sent: Saturday, May 30, 2020 8:06 PM
> To: tcpm@ietf.org
> Cc: tcpm-chairs 
> Subject: WGLC for draft-ietf-tcpm-2140bis
>=20
> Hi all,
>=20
> The document "TCP Control Block Interdependence" (draft-ietf-tcpm-
> 2140bis) is out there for a quite some time already. Given that there has
> been a bit less activity on the list after the interim, let's use this op=
portunity
> to finish one of our milestones...
>=20
> This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis. The
> WGLC will run until ***June 14***.
>=20
> The intended status is an informational RFC. The current version of the
> document can be found at:
>=20
> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
>=20
> Please review the latest version and please let us know any comments or
> suggestions. TCPM needs reviews to ensure that the content is ready to
> move forward. Feedback supporting publication ("+1") is also very welcome=
.
>=20
> Thanks
>=20
> Michael, on behalf of the TCPM chairs


From nobody Fri Jun 12 05:59:36 2020
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 7ABD33A07CB for ; Fri, 12 Jun 2020 05:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 fifORs4oPwBo for ; Fri, 12 Jun 2020 05:59:32 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 4396D3A0FBC for ; Fri, 12 Jun 2020 05:59:32 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id m2so7223560otr.12 for ; Fri, 12 Jun 2020 05:59:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=tDntGEKf3j8S9kl3SR6L/xs1+v3LtkVEK0bCRdzwltU=; b=LoengktzGPfZDDlKP0hTUsk/a5/Vk5WW1VHy/anOPjDAJ2RijXObfKOr8D4+NhBJyj WljcqnGDTa7xk9bXZ/HRxaVn2hv0fbLUhnJRWdPwi7zpBdQlZY8p1UYtuZ9Th8vdw1TO xfksrltuoCpoPKNq2RtHn1FODNNRkE6GmBRGX0YNn3ZSeoDbroPmRLJv8ZHGUGH8f3x+ R+6sFIS5PiqFoUGUE7aWD8pO16wvxBcMGvHg6CWwX6tthHTkuTqbYpUcA1hDda5d1EkA Ib0nLNWHg2Xkw/Ct9BccKjzSxa36aeyFWxX0X/ULYYvz18gN5DjR96fmU+T1qG4r57Ix 1tEw==
X-Gm-Message-State: AOAM530CFk6okZ13ksdO73l7FR3z/1HKs8vju2VaJ/aOGzaYg0knB9sj fFkb4sShCJDtOq5io3UK47a+aQ==
X-Google-Smtp-Source: ABdhPJz8RW+pGfU9I5dBFid3FroxNc1q4O9Glw0+KXe7zGDKsRlHjvrHd3qh2iHIt4WzVDtdZR2qKg==
X-Received: by 2002:a9d:aaa:: with SMTP id 39mr10144048otq.269.1591966771578;  Fri, 12 Jun 2020 05:59:31 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:45e2:3047:889f:766b]) by smtp.gmail.com with ESMTPSA id y68sm1343591oia.37.2020.06.12.05.59.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 05:59:30 -0700 (PDT)
From: "Mark Allman" 
To: "tom petch" 
Cc: "Martin Duke" , "Last Call" ,  tcpm , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Date: Fri, 12 Jun 2020 08:59:28 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org>
In-Reply-To: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>   
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_CE6BAB3A-4A82-4E9C-991C-E3C068E0C3B2_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 12:59:36 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_CE6BAB3A-4A82-4E9C-991C-E3C068E0C3B2_=
Content-Type: text/plain


> Terminology the boiler plate is out of date

???

> s,2
> This document is different from from ...

fixed

> Requirements
> would be easier to refer to if they were R1, R2a or some such

i didn't make a change here; editorial discretion, i guess

> a reference for DNS recursive resolver would be good

fixed

> EWMA needs  expanding on first use

fixed

i can push these to a new version whenever.  i'll wait to hear
stewart's response to martin before doing so, however.

thanks,
allman

--=_MailMate_CE6BAB3A-4A82-4E9C-991C-E3C068E0C3B2_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuN8MBEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizsd3AJ9OExmu6fLFHrVBBXJZQEQErAkCfgCfU1hV
3tsGnKQ2Ggp9bNB/KgnAioY=
=Ex7R
-----END PGP SIGNATURE-----

--=_MailMate_CE6BAB3A-4A82-4E9C-991C-E3C068E0C3B2_=--


From nobody Fri Jun 12 08:46:55 2020
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 1A62C3A0C75; Fri, 12 Jun 2020 08:46:49 -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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 3Kh0Ov9WTfgf; Fri, 12 Jun 2020 08:46:47 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2127.outbound.protection.outlook.com [40.107.20.127]) (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 3143A3A0C3D; Fri, 12 Jun 2020 08:46:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M1Se9q2uwYjqMnJ4+Ut1FCqL8yGJv/xvAVXr6V8+0NgGzKSB70x5yhWGQ4O6Z7/WydFHuQrPT6Fj55EvddNBlDZiUb4cqKnrShlThDYXW8hpqiaGk8vv7ZQvwkgAexiBG5VkSRz9IGW3PB6lWfDCPfxN7dioLF3gSf7la9FLV59sG969dxysx1dXYCuPRYOreXFSa319aR3ZCamyOhp0x0+gcv5VScipjwLjLrm6mcpRtyJ3JyKcbefeTHj9RelhBHh23eZsPxotlvFJj0eoRkTdq7MBXEZiJmki7uw/54OLJpGqjdfsZCxinT4DbsEYUSfsjLJntQGe28B52LxF3w==
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=ff/oKhlSjQMC4qjbplpW0axIECavBYOopesMrOBAuHI=; b=BKTk9K47rhj3i9jy1KPmB9sRhoAFRlLOQaBBDCofgvBR2o44Q0BofSc0xy6YICtq1CtW98bn6vJ//S3ILXJYMTCoSXAPdsZU+WDDH1YzC2zql/otIqgERMDn+XFiwLbApUexKNwV9oHJTnR7wbntLs5bTa4J3n7vbYHo54DR/eBahkE8N/+/l+/kvZv6QnyOT2PUgmCNNnpAQ6gHGI3qW84Dx5FgdO7hnlZ3SZMZf2gNn/rLDdiWsiHJ2z2vZZ4qh4gVMuG5FBP0YE5qh+XJl4tev7LfkxoKw8gNHdQR9NiXDn6I449NqRQ/boJ99sMTEm7JtHLVDXiqzXqs329ROQ==
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=ff/oKhlSjQMC4qjbplpW0axIECavBYOopesMrOBAuHI=; b=qMOGL8hA7lqtn8KrJ/Lumo+vx+IiCxF3Yya/HXG5OAD4ArOD2vVGS3+PSVBvWHwnt7W/oxXa/sZefjGwzbTvREPLv8zYFZV7dshGmBtrfP892+mlYCUd14D1eIQEA9UocrSXwGP9Q1hlAUEEy0MbGoZl3n+BgRKyfGNUNoQHuvk=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB6PR0701MB2184.eurprd07.prod.outlook.com (2603:10a6:4:50::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Fri, 12 Jun 2020 15:46:44 +0000
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4%7]) with mapi id 15.20.3088.019; Fri, 12 Jun 2020 15:46:44 +0000
To: Mark Allman 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org>
Cc: Last Call , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, Martin Duke , tcpm-chairs@ietf.org
From: t petch 
Message-ID: <5EE3A35B.6000108@btconnect.com>
Date: Fri, 12 Jun 2020 16:46:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LNXP265CA0008.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::20) To DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (86.139.211.47) by LNXP265CA0008.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3088.21 via Frontend Transport; Fri, 12 Jun 2020 15:46:43 +0000
X-Originating-IP: [86.139.211.47]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 06155486-7142-48dc-9cbe-08d80ee7ceb3
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2184:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:983;
X-Forefront-PRVS: 0432A04947
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: om/M+LTx1CN3i04FQSK1355W58XtUSalPV3It7dAfuggJiyZ2XXKZr9+YaWRKyiZ0+KLMwErS1fVwOKxhjaMABKbipiKLg4txINSIX129b698Kz8YzF5e/cEQN8dhIgEGFD0bT29s4eijFkBa4TucapZdsKcRBh1A4xyWpi8ssUa72zc5Pma5f3ZV3F+/6XmNCUe0ikGtk8CuETRBzdHVmZxgs6JYT030PenQ4g2rBxA4+EcfE/4HAwbL6yTrJ9F71pnMsgKeQt8cs6rdDs2FG0ci/jLvxCGYoM5oPXyhdCJ3gHV5m5s0ecYYGhhd1rLVg09HfAj4Z7KQgNhVkv9qA==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(346002)(39860400002)(366004)(396003)(136003)(16576012)(316002)(478600001)(16526019)(8676002)(36756003)(6486002)(8936002)(26005)(6916009)(52116002)(54906003)(186003)(2616005)(83380400001)(87266011)(956004)(4326008)(53546011)(33656002)(66556008)(5660300002)(66476007)(6666004)(4744005)(2906002)(66946007)(86362001); DIR:OUT; SFP:1102; 
X-MS-Exchange-AntiSpam-MessageData: uRWCCDg779O/iiliBsXtgG15y2CAZOabynfDEw62KVz20LnEK9+3Hl+0OH/oO1inLxnD2b9co7y8kcWjR65orXgrvNJGPo14YWu5Leur/6nELDSthHPOZJKevyab5RqNDnQAamweLId20ZrnqKidZX6xNfTxz3vZZE7nJswtwnNjgFiKP1O9uhWLINtykNnihTQzXVRnp+vtXlYpQc31nr3RfEwrxXaHwWoUjMd5FATQPxmxJ5fC4q2Tr+IMnuATjWHYAoNDDA88uO9+r2Zog2YkZ4DguiMBa/3gboVher63h3LFGhYQu8mi/ihZ5WStOGaKDZbcC1OhltVl/bTumyeaMn3xcu2bnp81OBQ095/1U3cloGhm3KFMXmjD7ZtQMEmaTViDz96ijOZq5XtGiJCqII5hVbKsCqNlNbGCUh8Ky6Wuv6xF+7WSmwg6e3sv+Duy6vxoCvrcMJ+Lj/Dvx54/9nHk13vB3iKlkDRSTPM=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06155486-7142-48dc-9cbe-08d80ee7ceb3
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 15:46:44.3387 (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: Mnblb3RuN2tpxNwnyc/oSk0a+vwCz1x/ya5Oz+H6ZYVuV8dgmVtnjCdd0dPR1xDVyfaISapmZV0dgRiL+crFxg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2184
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 15:46:49 -0000

On 12/06/2020 13:59, Mark Allman wrote:
>
>> Terminology the boiler plate is out of date
>
> ???



try  2140bis s.2 para 1
793bis needs updating too

Tom Petch

>> s,2
>> This document is different from from ...
>
> fixed
>
>> Requirements
>> would be easier to refer to if they were R1, R2a or some such
>
> i didn't make a change here; editorial discretion, i guess
>
>> a reference for DNS recursive resolver would be good
>
> fixed
>
>> EWMA needs  expanding on first use
>
> fixed
>
> i can push these to a new version whenever.  i'll wait to hear
> stewart's response to martin before doing so, however.
>
> thanks,
> allman
>
>
>


From nobody Fri Jun 12 10:40:09 2020
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 D8D2B3A1167 for ; Fri, 12 Jun 2020 10:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level: 
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VbWafLUFnSBN for ; Fri, 12 Jun 2020 10:40:04 -0700 (PDT)
Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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 AEAC93A104C for ; Fri, 12 Jun 2020 10:40:04 -0700 (PDT)
Received: by mail-oi1-f174.google.com with SMTP id p70so9382957oic.12 for ; Fri, 12 Jun 2020 10:40:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=AlDq3De8O2B2Z8U6WSppAltt7TcSGwt9UHDV/LFiClA=; b=VC7y1dCZqe9v+0Gmc2fHjL1QBdkMtG8WRKcU4DUK5v3a3RjC7bxFjaSMMHiScmv3tN TpfWXdM9oSK43FVGR+GLEn7Dt69JOCAESh50nWNU/xh1v1iaWfAOwwWd0qbz0BQDmb5W rppHVgrZyZPR+mcjk+RoHBCuGRDFkerHXfIFR2ngfuyVQMvMwOJzGaFPS9CKpLua/oKo vAtIgqndV1T2oIpE5UnshTALyswvgWJUxzGbNbzn2UL1WgSmOX3qroFNqB7oTc7SiCeO N03jl2mO9WEUFDGrOPkI4QXpET0CyxQryjyp16DXW5UdL+TNxX5XFBVwdVRL9PCt7GPm qJHQ==
X-Gm-Message-State: AOAM531rmEd4LJwkdqe0YOhpKV9SbaldJWlNM8Lj+Uvh/gXclJaxg74n QRVhkLpH5G6llMWBJ+pYYQZJtA==
X-Google-Smtp-Source: ABdhPJwgADot63Ms0V0G620BmB9Ve/2BiNJiubev5Lq8j/G3G6bq89y/sdoKhjn1lEaOge/M9mGL0w==
X-Received: by 2002:aca:470d:: with SMTP id u13mr13133oia.157.1591983604052; Fri, 12 Jun 2020 10:40:04 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:45e2:3047:889f:766b]) by smtp.gmail.com with ESMTPSA id l20sm1481138otp.35.2020.06.12.10.40.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 10:40:03 -0700 (PDT)
From: "Mark Allman" 
To: "t petch" 
Cc: "Last Call" , tcpm , draft-ietf-tcpm-rto-consider@ietf.org, "Martin Duke" , tcpm-chairs@ietf.org
Date: Fri, 12 Jun 2020 13:40:00 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org>
In-Reply-To: <5EE3A35B.6000108@btconnect.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_14452FAA-D4ED-401E-9B7B-BFDA15FFE32F_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 17:40:08 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_14452FAA-D4ED-401E-9B7B-BFDA15FFE32F_=
Content-Type: text/plain


(i was confused because i wouldn't call these 'terminology' or
'boilerplate' ... ugh ...)

> try  2140bis s.2 para 1

yeah, i guess i can add an additional cite to draft

> 793bis needs updating too

???

793 nor 793bis is cited, so nothing to update here

allman

--=_MailMate_14452FAA-D4ED-401E-9B7B-BFDA15FFE32F_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuO98BEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizj1SAJ9osISLuX4ltkR/0v7yWuemNd1AhACcD0f3
/xzVRtKqeXIPaXFJtl0OrHQ=
=YYC+
-----END PGP SIGNATURE-----

--=_MailMate_14452FAA-D4ED-401E-9B7B-BFDA15FFE32F_=--


From nobody Fri Jun 12 10:59:05 2020
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 5A9733A05A4; Fri, 12 Jun 2020 10:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 psMyuxnvZjgO; Fri, 12 Jun 2020 10:58:59 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150DD3A0766; Fri, 12 Jun 2020 10:58:59 -0700 (PDT)
Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49k7l41z7rzyWB; Fri, 12 Jun 2020 19:58:56 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org>
Date: Fri, 12 Jun 2020 19:58:55 +0200
Cc: t petch , Last Call , tcpm , Martin Duke , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
X-Mao-Original-Outgoing-Id: 613677535.7776819-9ca6cc438644a9853727f4cd073ace2a
Content-Transfer-Encoding: quoted-printable
Message-Id: <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org>
To: Mark Allman 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 17:59:04 -0000

On 2020-06-12, at 19:40, Mark Allman  wrote:
>=20
> Signed PGP part
>=20
> (i was confused because i wouldn't call these 'terminology' or
> 'boilerplate' ... ugh ...)
>=20
>> try  2140bis s.2 para 1
>=20
> yeah, i guess i can add an additional cite to draft

The text you want to use is on page 3 of RFC 8174, which now is BCP 14 =
together with RFC 2119.

>> 793bis needs updating too
>=20
> ???
>=20
> 793 nor 793bis is cited, so nothing to update here

No, but 793bis also uses the old boilerplate (totally unrelated =
comment).

(Tom: When making comments to a draft, it helps to do those in a way =
that can be understood by the authors.)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Fri Jun 12 11:06:12 2020
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 3A9F93A08EC for ; Fri, 12 Jun 2020 11:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 O9Ne4-C3-pqs for ; Fri, 12 Jun 2020 11:06:05 -0700 (PDT)
Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 C09933A08F9 for ; Fri, 12 Jun 2020 11:06:03 -0700 (PDT)
Received: by mail-ot1-f51.google.com with SMTP id v13so8032013otp.4 for ; Fri, 12 Jun 2020 11:06:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=8bgCi8D6NEYDs7rrLHLwPUyP2QnimTDRvLW3+nikRnY=; b=AZa3eyVsGHnPDdQFE+P2C2QvK7s4Nrjx4siD0T2/A6H/NE7Q7e9NmpJX0uMEwbxlWP FCyjxEVhp9rjy++KsrT/Sqd8lwFyWyc/cARilIO6nPfmCloav9SSvKyOxK2KaDTTDNFk Dht29Mt4feMT3MA/F4kBlQrfMUAO6hcQp5U7PXsXgu1LEFMIbjeTrDfBufQvQRR4Hhrf zOZqoPWTgg3occG3JoCrMHOnDPb8iGy2zkkjSnRvzeyHr16YxcUc7iVeh/cnNEQ4Ibnj FWXeQ3IENpDIWV980my3HNVNaPKOm76j96pyZ45N7OJTuJbC+P+hOIF/q9Xt+1Dy7LWi cYNw==
X-Gm-Message-State: AOAM531f3BsHswF5VMKcBsK4ONMe95rqDEY44BuZgBw+d/Bsd7QgBOPc bKwka9cRnsAay8wVfAo19UWKEw==
X-Google-Smtp-Source: ABdhPJzwaKWvDLtM4hcHfdu9gq2QiiKLywdQQXU71kcT3DiChlJ/Aw+9eKtbWi05ooHAfP7kNz54UQ==
X-Received: by 2002:a9d:7f93:: with SMTP id t19mr11914441otp.347.1591985163065;  Fri, 12 Jun 2020 11:06:03 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:45e2:3047:889f:766b]) by smtp.gmail.com with ESMTPSA id e11sm1512561oou.31.2020.06.12.11.06.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 11:06:02 -0700 (PDT)
From: "Mark Allman" 
To: "Carsten Bormann" 
Cc: "t petch" , "Last Call" , tcpm , "Martin Duke" , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Date: Fri, 12 Jun 2020 14:05:55 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: 
In-Reply-To: <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org> <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_5FAB56DE-7A68-4F84-86B8-6B165CA3033E_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 18:06:08 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_5FAB56DE-7A68-4F84-86B8-6B165CA3033E_=
Content-Type: text/plain


> The text you want to use is on page 3 of RFC 8174, which now is
> BCP 14 together with RFC 2119.

oh.  thank you for clearing that up.

> (Tom: When making comments to a draft, it helps to do those in a
> way that can be understood by the authors.)

+1

--=_MailMate_5FAB56DE-7A68-4F84-86B8-6B165CA3033E_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuPEAxEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizkJbAJ4t2qnVOWIOT45GQmcwpAfC5Sd61QCgiZgf
OPiacLy5lwxoqeTXXfQ7jJQ=
=Z6hb
-----END PGP SIGNATURE-----

--=_MailMate_5FAB56DE-7A68-4F84-86B8-6B165CA3033E_=--


From nobody Fri Jun 12 12:38:16 2020
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 A8F9E3A0C90; Fri, 12 Jun 2020 12:38:11 -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, 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 x4obwOJtZlOI; Fri, 12 Jun 2020 12:38:10 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 765503A0C8E; Fri, 12 Jun 2020 12:38:10 -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=XRAgTSWzRmXD30jgzLSGWHS29/0awNXPE2CyXgi9ZN4=; b=VbCwTeh0O902MM9So6d9xg0fp OU9rIIbVh3y0Xj9Av+w2C/nZXrCUCTX9fyL6RhlLo6skXMnBUJLygamLBBea6DjqtBG7BqIy11uLw jnYQ4lyFk5QSOrual/Ab3dqg5EzN6hz9T8FhFXgLZ5OFMgsy3jsad5j7rVnBgvw9nJau/Yt6GKCBM G/ksmhLIct7R82uGvvFyzoDis2Gb+Q9tkWNj8kcTWze/SL1M+4UbDmDSDjrw4fZSOxAEvOoZKew4D bsJwq9cfHu9JN9IHMao8BQmqIe7XUdzMnPKaJsWQ9hJ6wSMJvxzQasGTildlwrPx3BsuvnKQA7TJX M4qfj4hew==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53709 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjpV5-002Tbr-Vd; Fri, 12 Jun 2020 15:38:08 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>
Date: Fri, 12 Jun 2020 12:38:03 -0700
Cc: Mark Allman , tcpm , Last Call , t petch , Martin Duke , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <57A18915-E1DC-4652-942E-4287BABB9C71@strayalpha.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org> <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>
To: Carsten Bormann 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 12 Jun 2020 19:38:12 -0000

> On Jun 12, 2020, at 10:58 AM, Carsten Bormann  wrote:
>=20
> On 2020-06-12, at 19:40, Mark Allman  wrote:
>>=20
>> Signed PGP part
>>=20
>> (i was confused because i wouldn't call these 'terminology' or
>> 'boilerplate' ... ugh ...)
>>=20
>>> try  2140bis s.2 para 1
>>=20
>> yeah, i guess i can add an additional cite to draft
>=20
> The text you want to use is on page 3 of RFC 8174, which now is BCP 14 =
together with RFC 2119.

Agreed; I think the comment about 2140bis is a suggestion to copy the =
text out of that draft - not to cite the draft. But the text in our =
draft IS just the one verbatim from RFC 8174 as indicated.

Joe=


From nobody Fri Jun 12 12:39:33 2020
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 84AC83A0C92; Fri, 12 Jun 2020 12:39:31 -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, 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 92LBjkRWuq0V; Fri, 12 Jun 2020 12:39:30 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 B25AD3A0C8E; Fri, 12 Jun 2020 12:39:22 -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=Tp4hlzD1aUQplEs2ii5YPGoVMFHlqbwAJQf0ixCVJT4=; b=N/be3a/4mbCGXe8NFTDFcyICe bouEM8FB1Ah5ieCi/uZnEUP9vrc1s+hBsDqM3fM9snppxfEnSFNFheqK2aqzER/CY7T3mPNOyYP1j lp+zJAWw5L5r2cEET+Gguhah6Z8oL/BRyzaXxOtMkITrE24wba5v7r5FU6CNvD+9hVMiT7bSs7UxM +HBD9BqIiwAgO0ZFtmQVsqe+7g/t0PIiEjMczK9KCtU7QGUgKrGpB3+TxfBWvGjFlYpf5pCD2aon/ r44OtFc1ORF0jBXbYBh+wB4IfmfCI3Br9Hiw6CjNGUA1XtWHePRwdp+qWXAen3+jCw6Eq7a5+WqnD TWi9H2L+w==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53746 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jjpWH-002UgR-1E; Fri, 12 Jun 2020 15:39:22 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de>
Date: Fri, 12 Jun 2020 12:39:16 -0700
Cc: "tcpm@ietf.org" , tcpm-chairs 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de>
To: "Scharf, Michael" 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] WGLC for draft-ietf-tcpm-2140bis
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, 12 Jun 2020 19:39:32 -0000

I=E2=80=99m guessing the views of the authors is gratuitous, but to at =
least be explicit:

+1

Joe

> On Jun 12, 2020, at 2:56 AM, Scharf, Michael =
 wrote:
>=20
> Hi all,
>=20
> I haven't seen any reply so far. Lack of _any_ feedback is not a =
particularly good sign.
>=20
> Anyway, no feedback implies that the document is ready to move =
forward. However, even in that case explicit support for publication  =
would be _really_ useful. A simple "+1" could be enough...
>=20
> I'll extend the WGLC by one week until June 21 to give the community =
some additional time to comment.
>=20
> Thanks
>=20
> Michael
>=20
>=20
>> -----Original Message-----
>> From: Scharf, Michael 
>> Sent: Saturday, May 30, 2020 8:06 PM
>> To: tcpm@ietf.org
>> Cc: tcpm-chairs 
>> Subject: WGLC for draft-ietf-tcpm-2140bis
>>=20
>> Hi all,
>>=20
>> The document "TCP Control Block Interdependence" (draft-ietf-tcpm-
>> 2140bis) is out there for a quite some time already. Given that there =
has
>> been a bit less activity on the list after the interim, let's use =
this opportunity
>> to finish one of our milestones...
>>=20
>> This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis. =
The
>> WGLC will run until ***June 14***.
>>=20
>> The intended status is an informational RFC. The current version of =
the
>> document can be found at:
>>=20
>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
>>=20
>> Please review the latest version and please let us know any comments =
or
>> suggestions. TCPM needs reviews to ensure that the content is ready =
to
>> move forward. Feedback supporting publication ("+1") is also very =
welcome.
>>=20
>> Thanks
>>=20
>> Michael, on behalf of the TCPM chairs
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Sat Jun 13 04:05:52 2020
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 60EBE3A07C7; Sat, 13 Jun 2020 04:05:50 -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 4-m_lroKA73Z; Sat, 13 Jun 2020 04:05:48 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2113.outbound.protection.outlook.com [40.107.22.113]) (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 6EE323A07C2; Sat, 13 Jun 2020 04:05:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b3jR0Z8SXHcp95Pn7JXKi3ER7rfwT6kpMlwgGRsK+z24QxSG1JH1e1Owzq9MmrNz0FDEJ4htYNQXaguuXLTzYRe4ImK0xw0jIhhlo9AfahfDAbb3E4MkHfcykN95ib9knjww4rAaFzjALadhvd9KkDhil1cYWUzYrgMbR6aSAa6KUUUc8/4KrKy3aGPNQEFQ8mPUEc4EVVpURP3RSio+oQWNfwKF2Ze+tmIpnaIzu+oOMnBuTAXcXXa9jwXI2R87DjXUWsPQU13PnYy5NcAehLQ7l2LTjJNoFAz8ijKn9KkC42ANFpxNTYTU5eM0vGGjD3T3Sq086+uQL2REfb6j1g==
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=Lo9//IFwa0hGaUJ2er65d3k3Zh8tt1efiGA4KE73/IA=; b=JSOmjs0syqzoMfgJTyLOSxyEu7jaxW3t3flvevHlbmtb0UyY4M9IyhtssPEpeV2Je4OLKCXp6pK2QWcHkmYxH8OmHT3a+MfjXNiirqbSgnKAPOaoDFVhXSk7YHBoFNYWt/ucGHlpsONfaL1WWV7ZFkmMZXJbVc28afUXUypPW/zOfQSNRaKnAB66rM1UzWfeiUf6/Rjl0C/FhWxiXfy/VFhLrsraHHzczNVahHQ9/+f+w9dl6erKP3GfFcNOIdHdVhfW3+EsGY7VuBL5/P3LAJAKS6bHc21M0jm9VfDV12wpNVjd3qckESUXnGNDMXcj0HVD0YcpOTMHNfd2tABCUQ==
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=Lo9//IFwa0hGaUJ2er65d3k3Zh8tt1efiGA4KE73/IA=; b=wK65eCFmdJryKyk3OiTah4BcPKZJBYp93UzayvmlbnTBrXRayae2m9sV1qDujsefBboa+xR6Pv1v3BDPueNNnmhecZbOJgnh7hAKEWyNAYm7oKYAde9izHz+mupdPbaEe8kfppoZgbv+LHURzYw0bs/qjxw2rP+c1Qn8vhDEwT4=
Received: from AM0PR07MB5329.eurprd07.prod.outlook.com (2603:10a6:208:f5::20) by AM0PR07MB4098.eurprd07.prod.outlook.com (2603:10a6:208:49::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.14; Sat, 13 Jun 2020 11:05:45 +0000
Received: from AM0PR07MB5329.eurprd07.prod.outlook.com ([fe80::cc71:7b84:1b4d:9cf0]) by AM0PR07MB5329.eurprd07.prod.outlook.com ([fe80::cc71:7b84:1b4d:9cf0%6]) with mapi id 15.20.3109.008; Sat, 13 Jun 2020 11:05:45 +0000
From: tom petch 
To: Joseph Touch 
CC: tcpm , "tcpm-chairs@ietf.org" 
Thread-Topic: [Last-Call] [tcpm] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
Thread-Index: AQHWQOCDVOx4GHEjjkS6y6RIrMhULKjVRIWAgAAbs4CAAQEEjw==
Date: Sat, 13 Jun 2020 11:05:44 +0000
Message-ID: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org> <53272B96-995D-4092-B671-4E507F41CC03@tzi.org>, <57A18915-E1DC-4652-942E-4287BABB9C71@strayalpha.com>
In-Reply-To: <57A18915-E1DC-4652-942E-4287BABB9C71@strayalpha.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f3661080-9cbc-4ccc-9079-08d80f89b86c
x-ms-traffictypediagnostic: AM0PR07MB4098:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0433DB2766
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SViq2Vk03I4335I/mrmPQ11zifJ5V0yqcft0a0BcYrWnAcWwHuVQgj7A1DHvdFfTuLsg56Q2TAoAdBUPwWWxV+JNK+vbb3+Qx3EBpgdi73PsjOOe05ZT1n1Va9zOik+bZiliFFknLbQTXVrDpWS9Di7GOLzEf28CPuInBoO1pj0oY4KInJoHJAsfG1YPqarXhpnG69s6a0FP+EDPowIsDV82gaCF9TkmDmaZzGfKAKno4A010+TW3Xr/qlkaDlZdqqGdd5xZ6BRU+sEna7Z5XFDEcJGboDFjAM7Zddx63qvTiIp6VCdWsndQiC6Zrta5VLXH/NSyMRH5C0L9f5EFWw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM0PR07MB5329.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(366004)(376002)(346002)(136003)(39860400002)(396003)(71200400001)(478600001)(8936002)(52536014)(9686003)(91956017)(186003)(4744005)(66946007)(7696005)(53546011)(6506007)(26005)(5660300002)(76116006)(54906003)(2906002)(316002)(55016002)(83380400001)(86362001)(66556008)(4326008)(8676002)(6916009)(66476007)(33656002)(64756008)(66446008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: xJBzDdaJGxiw+V7KbdZx0heiVM0o8zWgibi2abBc/fBgbuLJoeUIHBFZZ8RAg8zxzOIjdbbxpDlXt2ayUGpgvr/X1GiViIWZqA9pLQrWt50mGvJxldba5y0N+uO9SgjkEIR/dxtR+QPdwr0MRN3JfSEK9e2OsSzupoHZksqakULrI76Tj7pxXqNGk4G0sgvB4CQjrpWO/NcCvs4Jv4GfFHkz/Qj2DCNrFL7nCKDfnlHLHU0BvWizxVCv7chSZDQpzIr4n0wvTNPmha5oVnTtCXRmt9doaM1lQDMsRZQ2/qPsDIRsd2nR8BTWUBow5xbCr79X0Ulj0oOyBxojVe3rTxAq5iDfUkPDbLDeBo6rHr+Do8Tbm8KuXFKe/CYQcvdUq4kFMr2NGoSuH2c7QC8hCt71MFOv/0JiWrPiMqc9frA0qgG1fgpYnB+KNSe+a+M+DSaGxPqVrFuMSo8GMyV/CCJBu3dvl0/wYLG7bqlTWf0=
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-Network-Message-Id: f3661080-9cbc-4ccc-9079-08d80f89b86c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 11:05:44.9775 (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: iBVbf4naCOkKXVsf5KNWUBIGbqckhLi79jYN6PjH8HUW+CSV9z1PrMQMpnSjR1yl42t+wXeuAeEQkjKfc2N83Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4098
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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: Sat, 13 Jun 2020 11:05:51 -0000

From: Joseph Touch =0A=
Sent: 12 June 2020 20:38=0A=
=0A=
> On Jun 12, 2020, at 10:58 AM, Carsten Bormann  wrote:=0A=
>=0A=
> On 2020-06-12, at 19:40, Mark Allman  wrote:=0A=
>>=0A=
>> Signed PGP part=0A=
>>=0A=
>> (i was confused because i wouldn't call these 'terminology' or=0A=
>> 'boilerplate' ... ugh ...)=0A=
>>=0A=
>>> try  2140bis s.2 para 1=0A=
>>=0A=
>> yeah, i guess i can add an additional cite to draft=0A=
>=0A=
> The text you want to use is on page 3 of RFC 8174, which now is BCP 14 to=
gether with RFC 2119.=0A=
=0A=
Agreed; I think the comment about 2140bis is a suggestion to copy the text =
out of that draft - not to cite the draft. But the text in our draft IS jus=
t the one verbatim from RFC 8174 as indicated.=0A=
=0A=
=0A=
Joe=0A=
Taking 'our draft' as 2140bis then yes that aspect of it is correct - if it=
 were not then I would not have cited it as an example of the text that sho=
uld be there.  But 793bis has the out of date boilerplate so since this goi=
ng to the TCPM list I was hoping Wesley would notice it and act on it:-)  =
=0A=
Tom Petch=0A=
=0A=
Joe=0A=


From nobody Sat Jun 13 06:02:47 2020
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 8847D3A0872 for ; Sat, 13 Jun 2020 06:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZykJSJVcX79a for ; Sat, 13 Jun 2020 06:02:43 -0700 (PDT)
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 54D2A3A0850 for ; Sat, 13 Jun 2020 06:02:43 -0700 (PDT)
Received: by mail-ot1-f44.google.com with SMTP id 97so9546966otg.3 for ; Sat, 13 Jun 2020 06:02:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=duzn6wgx+24dOqoG85bxDaUuaIvI9MjIequUH7dNvZs=; b=eaZNsLYs3ZdbqiWDQIalPibqKR/r6uY7LvheeTvTYSdWpR3JQ0TNAPDA41uDhyjG/v +SFO0dwiCqLmh6zuDUQ5dKJzjXNo5MvlDnoswwjs3P8Ie9ltAduFexSpwwsuWaHK2p+x 575mAe/cVSXTXBnZkrJn82JGmP1HTw14eE55cvpjbqRKwJo2pPHz17VUUCJc8Xf3VOvc wjSnc+xERPxkqUbflgMfRuzRS7IjyxTyMa/jJfaTGs8b2HWE+MNxwFIl4zU2HoDe+nV8 1qMYIlCwIfcFJzRegDdDYQ+6pbxkXILJLPj28h51e/hxd/svoNpe2bRQghCmXdE/jxba Kxag==
X-Gm-Message-State: AOAM533s9ET6Y7680WzDVuhE3WlsOVnUMilTT2Gv2gZSN/eh/MEcw9C0 Gqc/x1kfVn64wMqnhiGailj/Cg==
X-Google-Smtp-Source: ABdhPJz5QC+m+EQ/2xFY6dqhBzU9GGeDJjgfaKxmXq+MujD76Z4Amj2FGL5Di6TMBtrg0qT+zB5qyA==
X-Received: by 2002:a9d:2ca:: with SMTP id 68mr14040644otl.298.1592053362537;  Sat, 13 Jun 2020 06:02:42 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:3165:85:27da:c1db]) by smtp.gmail.com with ESMTPSA id g126sm2087470oia.41.2020.06.13.06.02.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2020 06:02:41 -0700 (PDT)
From: "Mark Allman" 
To: "tom petch" 
Cc: "Joseph Touch" , tcpm , tcpm-chairs@ietf.org
Date: Sat, 13 Jun 2020 09:02:40 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <249D22CE-8D2F-483B-839D-6C2B0C627E30@icir.org>
In-Reply-To: 
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com>  <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org> <53272B96-995D-4092-B671-4E507F41CC03@tzi.org> <57A18915-E1DC-4652-942E-4287BABB9C71@strayalpha.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_2968757D-108B-4E22-87C5-0A863DC992CC_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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: Sat, 13 Jun 2020 13:02:47 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_2968757D-108B-4E22-87C5-0A863DC992CC_=
Content-Type: text/plain


> Taking 'our draft' as 2140bis then yes that aspect of it is
> correct - if it were not then I would not have cited it as an
> example of the text that should be there.  But 793bis has the out
> of date boilerplate so since this going to the TCPM list I was
> hoping Wesley would notice it and act on it:-)

oh my.

it'd be way helpful if i could stop reading this thread.  i have
known joe & wes a long time and can pretty confidently say that none
of us are mind readers.  if you have something to say, say it.  if
you don't, please stop saying stuff.

NITS that take a friggin' thread to untangle are NOT WORTH IT.
seriously.

allman

--=_MailMate_2968757D-108B-4E22-87C5-0A863DC992CC_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuTOcBEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIiziQoAJ9ZuxD3qBtEFxNGEeou5gihGN9yqQCffMKj
iiv+mognAxw/yrMMREpDKiw=
=t/Mv
-----END PGP SIGNATURE-----

--=_MailMate_2968757D-108B-4E22-87C5-0A863DC992CC_=--


From nobody Sun Jun 14 19:19:20 2020
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 A80663A09AF for ; Sun, 14 Jun 2020 19:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 BYQD7VN9e7bI for ; Sun, 14 Jun 2020 19:19:14 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 6C9D93A099F for ; Sun, 14 Jun 2020 19:19:05 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id i16so11471648qtr.7 for ; Sun, 14 Jun 2020 19:19:05 -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-transfer-encoding:content-language; bh=mLNwC8zcjfF0QbCYntYICvxL8/Q+yCFyyICeamixfrs=; b=twqK+9lV3SToJLeiZ8f/3K//SOxZw6M1JxEVfEppTmGI6DWEUIzIPNnWVIK6fwcfk4 5NN170GCf2MVWUXze/cxkw++vIsygdDlEYUftzQMOb8hXJ85u5zNkeJZzIOkrin4ZlVc NM1Q2Sz1QYqgcfSF3qz4E7Xmj7dYZsrY8y0mR5wTOadAnZlckz8m3x9N4I9CwWaPSp1d XH/0o1XEjk5hHVIGitZp1nf42UPEhRJlhL941ACHWULffw7+QbVMX8Z3cy5AZkBTsUWt ZHY+ly35mi94yNGWtRCHHEagGDmcAcjJuVyuT2CmLMBtpw+8Cy7A1YkaAuq8Z/AkXg8O eMqA==
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-transfer-encoding :content-language; bh=mLNwC8zcjfF0QbCYntYICvxL8/Q+yCFyyICeamixfrs=; b=CseewqiZpfnvBJGI0nKfzcRXVg6KnaS11cHACG3XdvKNIMXDiN38wqVcgM8BdbhvOO 0vu4/1+8MqqrMpmmpejkwNARGPw7HUXpQZPBMFTJVpGN2L9gRA1tyj1wvJKLdUwSdZ1v /eOcGeq/PmMkW5h+YtZfkmDQsxDrVkl6GZNXM5kvJ1vFyAuNJ9TwCXbfBKoA5ApzP40s cxEPqQk3Bz6TtQck9fDZHoCH3vUVRi5nvnkK25Ns4lNAnwOdIKHLbg6ZzmHrzOskat91 7pV7i7hOz7WewMnvOqwyMaSOu3CRe0nMKadF/UlHnPu0F9WBZK5Q/W/O+eP4oz+rDYy/ 2J+w==
X-Gm-Message-State: AOAM531hOz203DeI2GOwCgLk20qg3+DKKSpAxzrY4GKlpBOf0Endzwyz mJjIFz9cN5liOhawWVuUhFUjpPd8Ow8swA==
X-Google-Smtp-Source: ABdhPJx7eoZPl0SwvFO+9AFESHEA0xAbNM+pJuYnmSgjCoWtj1lwFjQQ9g6NsmsKJ/8loMVkfBLuJw==
X-Received: by 2002:ac8:1b58:: with SMTP id p24mr13044303qtk.320.1592187544276;  Sun, 14 Jun 2020 19:19:04 -0700 (PDT)
Received: from [192.168.1.12] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id v2sm10345973qtq.8.2020.06.14.19.19.03 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2020 19:19:03 -0700 (PDT)
To: tcpm@ietf.org
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org>    <4D84E94A-7535-4090-BE39-FB2ED242C9CA@icir.org> <5EE3A35B.6000108@btconnect.com> <31294BB6-351B-4C6A-8B9F-9F2C0F81BD08@icir.org> <53272B96-995D-4092-B671-4E507F41CC03@tzi.org> <57A18915-E1DC-4652-942E-4287BABB9C71@strayalpha.com>  <249D22CE-8D2F-483B-839D-6C2B0C627E30@icir.org>
From: Wesley Eddy 
Message-ID: 
Date: Sun, 14 Jun 2020 22:19:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <249D22CE-8D2F-483B-839D-6C2B0C627E30@icir.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [tcpm] [Last-Call] Last Call:  (Requirements for Time-Based Loss Detection) to Best Current Practice
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, 15 Jun 2020 02:19:19 -0000

On 6/13/2020 9:02 AM, Mark Allman wrote:
>> Taking 'our draft' as 2140bis then yes that aspect of it is
>> correct - if it were not then I would not have cited it as an
>> example of the text that should be there.  But 793bis has the out
>> of date boilerplate so since this going to the TCPM list I was
>> hoping Wesley would notice it and act on it:-)
> oh my.
>
> it'd be way helpful if i could stop reading this thread.  i have
> known joe & wes a long time and can pretty confidently say that none
> of us are mind readers.  if you have something to say, say it.  if
> you don't, please stop saying stuff.
>
> NITS that take a friggin' thread to untangle are NOT WORTH IT.
> seriously.


Now that I've had time to read this thread and catch up, I see what 
needs to be done for 793bis and will take care of it.



From nobody Wed Jun 17 10:21:22 2020
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 CAC943A0AA2; Wed, 17 Jun 2020 10:21:10 -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, 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 ouThygbpX5Ax; Wed, 17 Jun 2020 10:21:06 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 3EE513A0A9C; Wed, 17 Jun 2020 10:21:06 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id i4so659072iov.11; Wed, 17 Jun 2020 10:21:06 -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=Ieix0otep0Pryj066lfXA+VNML5YvyE5vSQRvKyNbMk=; b=k17Z6Tq9EzKzKwtJFYb0GR3XwsqG0xx0oawsS8n6bvi6xOZ9N5srgJpovxeqHdBGeV 44FGSbMgstxDAQus5v++JglyIrKKmZyEhn3lErD+QMP76Tc5Wb6bB0eMpWRZYZ1Zmd7L wMeg9EgDtVNe2rDhr1syNP1GI2cEGS++WWehe+w97Z+z3TUNZJM8f/6DFji+t7I4A3sF 6dIjqHD2MFcbyVp4l49tmQOoEsRFaJK64EkEvdfDWI5hZgpOkvaXwDiY3dq2X+X4ZQPx Z5fs2RAH6LVs2jdb5NuSjd9Y7XElkn0pJUz7MIdGptksJpARreY6GqBg3+w8M2EnQgQE c3cg==
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=Ieix0otep0Pryj066lfXA+VNML5YvyE5vSQRvKyNbMk=; b=EKQYirn8My3sUsAaoOqDAqRv2f0AIkrBqFJ44n+YFZskBATQJgwQWoRfnTM7v+yYUi eS1mBfMyAdAVEdJq65K8cjaUYRP0JrswqhuFDu7aBcYMrVNvrF53ZCEzXBDUlXd4FNL2 evcHXJqckqJT7Mzw0dWGYLSMbdPeSwraH/6DJpc1cNEtCaJWHUsuzmSFT6aMbSFqJgj2 iBLXZbm3moMDMCMX9/cC6Jr2QbIXgSHK2Hy09Rv7ibjoXE8ZnWzhL5TeVCCy0rgfMHq2 uo90YdluT6h3BRoxyEEbSkLCA0yvEZ6DGM/T2Juqy5qgUuJ5WmsxSphsSILBPvSOf5jv 4DCA==
X-Gm-Message-State: AOAM532b0CjN6NJ6cAUl7I3D5/Vjq95uvGiRd1SG6UWEb7FzJCyflG/n vv0SCP4Ypf21p2xuiTETbOj/iIoMTjTM8UrG6tk=
X-Google-Smtp-Source: ABdhPJwu8OABmROZgHSPiBTJ15fYJB3uVUs3Vu6AKMr0HPWRm+VxY4LEW2HF1kuecHSffLdAqO0EH/yK4bXGaV5OjRQ=
X-Received: by 2002:a6b:e311:: with SMTP id u17mr428648ioc.51.1592414464640; Wed, 17 Jun 2020 10:21:04 -0700 (PDT)
MIME-Version: 1.0
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org> 
In-Reply-To: 
From: Martin Duke 
Date: Wed, 17 Jun 2020 10:20:53 -0700
Message-ID: 
To: Mark Allman 
Cc: Stewart Bryant , Review Team ,  tcpm ,  Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org,  tom petch 
Content-Type: multipart/alternative; boundary="000000000000800f4505a84ae213"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 17 Jun 2020 17:21:11 -0000

--000000000000800f4505a84ae213
Content-Type: text/plain; charset="UTF-8"

Hi Stewart,

If there are no further objections, I'm going to declare consensus.

On Thu, Jun 11, 2020 at 1:45 PM Martin Duke  wrote:

> Stewart,
>
> do we need more cycles for this, or is draft-15 sufficient to address your
> concerns?
>
> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman  wrote:
>
>>
>> Hi Stewart, et.al.!
>>
>> I just submitted a new version of rto-consider.  Please ask the
>> datatracker for diffs between this and rev -14.  The highlights:
>>
>>   - The diffs with the last rev are here:
>> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>>
>>   - All small comments addressed.
>>
>>   - I think we all agree that this is not a one-size-fits-all
>>     situation.  Rather, this document is meant to be a default case.
>>     So, the main action of this rev is to make that point more
>>     clearly.  The first paragraph in the intro is new.  Also, there
>>     are some more words fleshing out the context more in section 2.
>>     In particular, more emphatically making the point that other
>>     loss detectors are fine for specific cases.
>>
>>   - The first paragraph in the intro also makes clear we adopt the
>>     loss == congestion model (as that is the conservative default,
>>     not because it is always true).
>>
>>   - I made one other change that wasn't exactly called for, but
>>     seems like an oversight.
>>
>>     Previously guideline (4) said loss MUST be taken as an
>>     indication of congestion and some standard response taken.  But,
>>     this guideline has an explicit exception for cases where we know
>>     the loss was caused by some non-congestion event.  Guideline (3)
>>     says you MUST backoff.  But, it did not have this exception for
>>     cases where we can tell the cause.  But, I think based on the
>>     spirit of (4), (3) should also have these words.  So, I added
>>     them.
>>
>>     Also, I swapped (3) and (4) because it seemed more natural in
>>     re-reading to first think about taking congestion action and
>>     then dealing with backoff.  I think the ordering is a small
>>     thing, but folks can yell and I'll put it back if there is
>>     angst.
>>
>> Please take a look and let me know if this helps things along or
>> not.
>>
>> allman
>>
>

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


Hi Stewart,

If there are no further obj=
ections, I'm going to declare consensus.

On Thu, Jun 11, 2020 at 1=
:45 PM Martin Duke <martin.h.=
duke@gmail.com> wrote:
Stewart,

do we need more =
cycles for this, or is draft-15 sufficient to address your concerns?
<=
/div>
O=
n Mon, Jun 8, 2020 at 12:52 PM Mark Allman <mallman@icir.org> wrote:


Hi Stewart, e=
t.al.!



I just submitted a new version of rto-consider.=C2=A0 Please ask the

datatracker for diffs between this and rev -14.=C2=A0 The highlights:



=C2=A0 - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?=
difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-rto-consider-15.txt



=C2=A0 - All small comments addressed.



=C2=A0 - I think we all agree that this is not a one-size-fits-all

=C2=A0 =C2=A0 situation.=C2=A0 Rather, this document is meant to be a defau=
lt case.

=C2=A0 =C2=A0 So, the main action of this rev is to make that point more
=C2=A0 =C2=A0 clearly.=C2=A0 The first paragraph in the intro is new.=C2=A0=
 Also, there

=C2=A0 =C2=A0 are some more words fleshing out the context more in section =
2.

=C2=A0 =C2=A0 In particular, more emphatically making the point that other<=
br>
=C2=A0 =C2=A0 loss detectors are fine for specific cases.



=C2=A0 - The first paragraph in the intro also makes clear we adopt the

=C2=A0 =C2=A0 loss =3D=3D congestion model (as that is the conservative def=
ault,

=C2=A0 =C2=A0 not because it is always true).



=C2=A0 - I made one other change that wasn't exactly called for, but
=C2=A0 =C2=A0 seems like an oversight.



=C2=A0 =C2=A0 Previously guideline (4) said loss MUST be taken as an

=C2=A0 =C2=A0 indication of congestion and some standard response taken.=C2=
=A0 But,

=C2=A0 =C2=A0 this guideline has an explicit exception for cases where we k=
now

=C2=A0 =C2=A0 the loss was caused by some non-congestion event.=C2=A0 Guide=
line (3)

=C2=A0 =C2=A0 says you MUST backoff.=C2=A0 But, it did not have this except=
ion for

=C2=A0 =C2=A0 cases where we can tell the cause.=C2=A0 But, I think based o=
n the

=C2=A0 =C2=A0 spirit of (4), (3) should also have these words.=C2=A0 So, I =
added

=C2=A0 =C2=A0 them.



=C2=A0 =C2=A0 Also, I swapped (3) and (4) because it seemed more natural in=


=C2=A0 =C2=A0 re-reading to first think about taking congestion action and<=
br>
=C2=A0 =C2=A0 then dealing with backoff.=C2=A0 I think the ordering is a sm=
all

=C2=A0 =C2=A0 thing, but folks can yell and I'll put it back if there i=
s

=C2=A0 =C2=A0 angst.



Please take a look and let me know if this helps things along or

not.



allman






--000000000000800f4505a84ae213--


From nobody Wed Jun 17 10:46:32 2020
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 4958D3A096B; Wed, 17 Jun 2020 10:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 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, MIME_HTML_ONLY=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 (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 ReDO1ixoCUZP; Wed, 17 Jun 2020 10:46:23 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 5ECF73A0933; Wed, 17 Jun 2020 10:46:23 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id t194so2936767wmt.4; Wed, 17 Jun 2020 10:46:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UIhNOEHf/ZVwKI9vq2wTIGJcA+JHbHdU34ZVRdSKVOs=; b=cRgJc76qvnJrURlUg3Mv4/wLFjUg/AAr3QAVlQI6TgJu1zGn/WI9UkcT5lmmJ2c1Uc SnNlsTxZotBosa57MzC9ZxAAEiyqU0MyDVrDCkvhv46ofiApfaGWKbMcXnEbuq8B7Twy BMNJ+Itp2+cRL5nRphdnSUig5lbeu5WUp4jS3ZW3Yl/dw9iUozgJo1F31wF0lB0uQv9O I77FYKhJyhV/4WPDrtXMKGZ5JIl1uMfpKr3EU0GmBO3WIyp3ivCMvZlLma08kE10xysS 4oxPvHF5H1qME0oHTBAZnCXXFczwnryyZTtwC1+sFBgdV95yp+Ie+RWoQhoAF7acFYxl pKig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UIhNOEHf/ZVwKI9vq2wTIGJcA+JHbHdU34ZVRdSKVOs=; b=WgonED5/ABVrA0DQLq0+g9n7nVTc2FZpZHTvlAqayrZNwZAJbMreqPuYW7QyhI14Jy 8I7eaRDcwt7+cIOE5TZXe93aX7Uc0i+mLjEiAx8AXtCpdfIi3ToaENUaaAyGZ1ivZBWS 5cJIR62x/Cmpwwx+XSolKjLOS9kPg08eqhpn/eAN5WJjxCRQkOspT5fVIBJdrX44gU71 IXxjYTqAm0Bsb/j10HUGSK5WTFJy+98f5cdmGiDjXxlGg7DUkspT1Affhjachdpt1M0t 9GrCQtxa/z3Lk0IBFSZ+6/ZeRcRduWp8OhgGBVJOFetY2ZpHhN6JZy4zZC1FrbDBZEug nJlQ==
X-Gm-Message-State: AOAM531YxP20k4CENgZI8VTyRpOsuBp4UgASCsZYGo+hXBKgDKtVHVeT 8pYd4H1P4XTRXLgtkhuV9Cs=
X-Google-Smtp-Source: ABdhPJzRlOEhcEOHvmdfPjSufK6bHHC5GU4tqoj+YkazkAqeunpDhHB0+N3DVyUfIudfyfd5NZUeNw==
X-Received: by 2002:a7b:c7d8:: with SMTP id z24mr9353744wmk.28.1592415981693;  Wed, 17 Jun 2020 10:46:21 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id n7sm341613wrx.82.2020.06.17.10.46.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 10:46:20 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Content-Type: text/html; charset=us-ascii
X-Apple-Auto-Saved: 1
X-Apple-Mail-Remote-Attachments: YES
From: Stewart Bryant 
X-Apple-Base-Url: x-msg://20/
In-Reply-To: 
X-Apple-Windows-Friendly: 1
Date: Wed, 17 Jun 2020 18:46:08 +0100
Cc: Stewart Bryant , Mark Allman ,  Review Team , tcpm , Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org, tom petch 
X-Apple-Mail-Signature: SKIP_SIGNATURE
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D7ADB34-2D66-4AA2-9F03-77CB688B1EB4@gmail.com>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>  
X-Uniform-Type-Identifier: com.apple.mail-draft
To: Martin Duke 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 17 Jun 2020 17:46:29 -0000


Please give me until tomorrow and I will =
take a look.

Life =
has been a bit busy here,

Stewart

On 17 =
Jun 2020, at 18:20, Martin Duke <martin.h.duke@gmail.com> wrote:

Hi Stewart,

If there are no further objections, I'm going to declare =
consensus.

On Thu, Jun 11, 2020 at 1:45 PM Martin =
Duke <martin.h.duke@gmail.com> wrote:
Stewart,

do=
 we need more cycles for this, or is draft-15 sufficient to address your =
concerns?

On Mon, Jun 8, 2020 at 12:52 PM Mark =
Allman <mallman@icir.org> wrote:


Hi Stewart, et.al.!



I just submitted a new version of rto-consider.  Please ask the

datatracker for diffs between this and rev -14.  The highlights:



  - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd=
raft-ietf-tcpm-rto-consider-15.txt



  - All small comments addressed.



  - I think we all agree that this is not a one-size-fits-all

    situation.  Rather, this document is meant to be a =
default case.

    So, the main action of this rev is to make that point =
more

    clearly.  The first paragraph in the intro is =
new.  Also, there

    are some more words fleshing out the context more in =
section 2.

    In particular, more emphatically making the point that =
other

    loss detectors are fine for specific cases.



  - The first paragraph in the intro also makes clear we adopt =
the

    loss =3D=3D congestion model (as that is the conservative =
default,

    not because it is always true).



  - I made one other change that wasn't exactly called for, but

    seems like an oversight.



    Previously guideline (4) said loss MUST be taken as an

    indication of congestion and some standard response =
taken.  But,

    this guideline has an explicit exception for cases where =
we know

    the loss was caused by some non-congestion event.  =
Guideline (3)

    says you MUST backoff.  But, it did not have this =
exception for

    cases where we can tell the cause.  But, I think =
based on the

    spirit of (4), (3) should also have these words.  So, =
I added

    them.



    Also, I swapped (3) and (4) because it seemed more natural =
in

    re-reading to first think about taking congestion action =
and

    then dealing with backoff.  I think the ordering is a =
small

    thing, but folks can yell and I'll put it back if there =
is

    angst.



Please take a look and let me know if this helps things along or

not.



allman







=


From nobody Thu Jun 18 01:29:12 2020
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 729183A0FB8; Thu, 18 Jun 2020 01:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=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
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 uELmrmlM9GuW; Thu, 18 Jun 2020 01:29:10 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 595973A0FB6; Thu, 18 Jun 2020 01:29:05 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 05I8T0C8034945; Thu, 18 Jun 2020 10:29:00 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 4620A1D53C1; Thu, 18 Jun 2020 10:28:59 +0200 (CEST)
Received: from 79.152.3.25 by webmail.entel.upc.edu with HTTP; Thu, 18 Jun 2020 10:29:00 +0200
Message-ID: 
In-Reply-To: <4B1DC848-32F1-4BAF-9835-CC931C1F938C@strayalpha.com>
References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at>  <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu>   <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu>  <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de>    <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> <4B1DC848-32F1-4BAF-9835-CC931C1F938C@strayalpha.com>
Date: Thu, 18 Jun 2020 10:29:00 +0200
From: "Carles Gomez Montenegro" 
To: "Joseph Touch" 
Cc: "Praveen Balasubramanian" , "Neal Cardwell" , "Matt Mathis" , "tcpm@ietf.org" , "Jon Crowcroft" , "Michael Tuexen" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 18 Jun 2020 10:29:01 +0200 (CEST)
Archived-At: 
Subject: Re: [tcpm] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP
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, 18 Jun 2020 08:29:11 -0000

Hi Joe,

First of all, sorry for the late reply.

Please find below my inline response.

>> On May 13, 2020, at 5:00 AM, Carles Gomez Montenegro
>>  wrote:
>>
>> In this thread, several WG participants expressed a positive opinion
>> about
>> defining a new TCP option. (Although, as you mentioned, this approach
>> also
>> has drawbacks.)
>
> Why not start as defining an Experimental Option (with a corresponding
> code point)?
>
> Joe

Thanks for your suggestion.

(I understand that you mean an Experimental-category specification
defining a TCP Option using a dedicated kind number different from 253 or
254.)

Yes, this sounds as a very good approach!

Cheers,

Carles


From nobody Thu Jun 18 03:00:31 2020
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 D60363A1210; Thu, 18 Jun 2020 03:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 b56W0FW8irLs; Thu, 18 Jun 2020 03:00:21 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 76E923A120F; Thu, 18 Jun 2020 03:00:20 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id t194so4988303wmt.4; Thu, 18 Jun 2020 03:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2PLwJuG8aGMk/YUGqVj4UUKbjuHJVa1VGEUp7TNBpac=; b=SNm56eCgL5I9Os/96KliObYCSIDG2YiUDgHvu9Bt6HgXJBRX1BsrO9hCkqpq4jcbIC ZGfwp9hxEi/NpPr13LyI0Ya6icCLecGM/PmLKOChRcZFghiYyDZJfTem8+pvk/lZ39sl 2Aozxcue0wDot2/sp+18Kj/jlMXxq1l3bVSb1SGBOFLy98HhDrN43RUzAJlxAL4iJc5y 7JlV4Cc9bofG94hNwpCmp70JPjhM+XR/XrgLwyejs2sh3C/rjqsd0ytcK0goxWcEg93X BNG1bQ9JTLmfka695QguebIMxqp1+z+PTtoZNybavIcUYlPz8HIK35aM9jda8qysP9Ny bCiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2PLwJuG8aGMk/YUGqVj4UUKbjuHJVa1VGEUp7TNBpac=; b=XQitODHM+vUWRqybD7qsOx72NJ3mRGmYJk6zAp9XxsptFNUW8A+aOpTgw6biEOGRy2 bX2prkJnLspBre3AVol0TYRQ65eXwirC/HCj0NvY6m4AAB6XiSq/zWZiNCbkxYQZUeAN QU0tUx8yRfEzp55IV9XFoS2Hclrxz/hkI+5i0ude0poNavzAmyApkncxJwHwLGPaFzKM tBQNj3pic5s2jG16I15AbinfkJ4OKKqVI5BwlLjEQilBiEm40LVK2ojrpmXu/bP+P7Rd RC1m971yEjM5/AEHTE20lp9uw4DoFZJ/P5yM8MM7GgoYc6cqIZvjbmbqDMW27qIq9mrD ogmQ==
X-Gm-Message-State: AOAM5310LhafKba3IfcUmp0dGN519Cr48vY7CBafeiW7S2F+OmMekbcH ZR6yt4DMid52UlXufpN3eFo=
X-Google-Smtp-Source: ABdhPJxB3/kTZV/yceXsP9doCOAygkXp3dfbFsC5+ubvAvUbnmoy8UWtTEGe2RYmQZMjHLd/Nv7bhQ==
X-Received: by 2002:a1c:22d7:: with SMTP id i206mr3109660wmi.186.1592474418713;  Thu, 18 Jun 2020 03:00:18 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id 63sm3217865wra.86.2020.06.18.03.00.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 03:00:17 -0700 (PDT)
From: Stewart Bryant 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_A5C02A65-5A88-4912-9016-3591927F0E08"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 18 Jun 2020 11:00:15 +0100
In-Reply-To: 
Cc: Stewart Bryant , Mark Allman ,  Review Team , tcpm , Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org, tom petch 
To: Martin Duke 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 10:00:27 -0000

--Apple-Mail=_A5C02A65-5A88-4912-9016-3591927F0E08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 17 Jun 2020, at 18:20, Martin Duke  wrote:
>=20
> Hi Stewart,
>=20
> If there are no further objections, I'm going to declare consensus.
>=20
> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke > wrote:
> Stewart,
>=20
> do we need more cycles for this, or is draft-15 sufficient to address =
your concerns?
>=20
> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman > wrote:
>=20
> Hi Stewart, et.al .!
>=20
> I just submitted a new version of rto-consider.  Please ask the
> datatracker for diffs between this and rev -14.  The highlights:
>=20
>   - The diffs with the last rev are here: =
https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-=
rto-consider-15.txt =


In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

Its is more the contending/conflicting traffic rather than the =
buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffering=E2=80=
=9D is a link a transport colloquial term.


Since our wide-area network paths are best
    effort, packet loss is a regular occurrence.=20

No the best effort Internet experiences this. There ate many well =
engineered WAN that do not.

What I am not seeing is clearer text that distinguishes between user =
traffic and =E2=80=9Cengineering=E2=80=9D traffic that is used to make =
the network work, and between the end to end traffic and traffic within =
an AS that may be there for other purposes (high value service also =
offered by the provider) and WANs that are well engineered.

Perhaps we could include a clearer disclaimer regarding the =
non-best-effort-internet-end-to-end traffic?

You have some text on this down in section 2 but it is a bit buried.

Perhaps something early on of the form: This document is specially =
concerned with end to end behaviour over the best effort Internet. As =
noted in section 2 it may not me applicable to other types of WAN, or to =
the  traffic used in affecting the operation of the Internet itself.


 An exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption). =20

That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there =
than an IETF standardarized mechanism. The IETF does not have a monopoly =
on pre-blessing protocols before they are deployed.



>=20
>   - All small comments addressed.
>=20
>   - I think we all agree that this is not a one-size-fits-all
>     situation.  Rather, this document is meant to be a default case.
>     So, the main action of this rev is to make that point more
>     clearly.  The first paragraph in the intro is new.  Also, there
>     are some more words fleshing out the context more in section 2.
>     In particular, more emphatically making the point that other
>     loss detectors are fine for specific cases.


As I note above from a routing and packet transport (as opposed to the =
transport layer) perspective I think we should more clearly recognise at =
the beginning the fact that this is for the worst case network, not for =
well engineered (WAN and DC) networks  and the mechanisms fundamental to =
the operation of the network itself.

>=20
>   - The first paragraph in the intro also makes clear we adopt the
>     loss =3D=3D congestion model (as that is the conservative default,
>     not because it is always true).
>=20
>   - I made one other change that wasn't exactly called for, but
>     seems like an oversight.
>=20
>     Previously guideline (4) said loss MUST be taken as an
>     indication of congestion and some standard response taken.  But,
>     this guideline has an explicit exception for cases where we know
>     the loss was caused by some non-congestion event.  Guideline (3)
>     says you MUST backoff.  But, it did not have this exception for
>     cases where we can tell the cause.  But, I think based on the
>     spirit of (4), (3) should also have these words.  So, I added
>     them.

In some cases you cannot tell the cause, but it is more important to =
ignore the loss. OAM being a particularly good example.

>=20
>     Also, I swapped (3) and (4) because it seemed more natural in
>     re-reading to first think about taking congestion action and
>     then dealing with backoff.  I think the ordering is a small
>     thing, but folks can yell and I'll put it back if there is
>     angst.
>=20
> Please take a look and let me know if this helps things along or
> not.
>=20
> allman

We are getting there, but I would ask that you take the transport hat =
off and look again from an infrastructure and packet transport =
perspective.

Best regards

Stewart



--Apple-Mail=_A5C02A65-5A88-4912-9016-3591927F0E08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 17 Jun 2020, at 18:20, Martin Duke <martin.h.duke@gmail.com> wrote:

Hi Stewart,

If there are no further objections, I'm going to declare =
consensus.

On Thu, Jun 11, 2020 at 1:45 PM Martin =
Duke <martin.h.duke@gmail.com> wrote:
Stewart,

do=
 we need more cycles for this, or is draft-15 sufficient to address your =
concerns?

On Mon, Jun 8, 2020 at 12:52 PM Mark =
Allman <mallman@icir.org> wrote:


Hi Stewart, et.al.!



I just submitted a new version of rto-consider.  Please ask the

datatracker for diffs between this and rev -14.  The highlights:



  - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd=
raft-ietf-tcpm-rto-consider-15.txt
<=
br class=3D"">
In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

Its is more the contending/conflicting =
traffic rather than the buffering, or perhaps the time spent in queues, =
but =E2=80=9Cbuffering=E2=80=9D is a link a transport colloquial =
term.


Since our wide-area network paths are best
    effort, packet loss is a regular occurrence. =


No the best effort Internet experiences this. There ate many =
well engineered WAN that do not.

What I am not seeing is clearer text =
that distinguishes between user traffic and =E2=80=9Cengineering=E2=80=9D =
traffic that is used to make the network work, and between the end to =
end traffic and traffic within an AS that may be there for other =
purposes (high value service also offered by the provider) and WANs that =
are well engineered.

Perhaps we could include a clearer disclaimer regarding the =
non-best-effort-internet-end-to-end traffic?

You have some text on this down in =
section 2 but it is a bit buried.

Perhaps something early on of the form: =
This document is specially concerned with end to end behaviour over the =
best effort Internet. As noted in section 2 it may not me applicable to =
other types of WAN, or to the  traffic used in affecting the =
operation of the Internet itself.


 An =
exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  

That is a bit =
heavy. It should be =E2=80=9Ca protocol=E2=80=9D there than an IETF =
standardarized mechanism. The IETF does not have a monopoly on =
pre-blessing protocols before they are deployed.






  - All small comments addressed.



  - I think we all agree that this is not a one-size-fits-all

    situation.  Rather, this document is meant to be a =
default case.

    So, the main action of this rev is to make that point =
more

    clearly.  The first paragraph in the intro is =
new.  Also, there

    are some more words fleshing out the context more in =
section 2.

    In particular, more emphatically making the point that =
other

    loss detectors are fine for specific cases.
<=
br class=3D"">

As I note above from =
a routing and packet transport (as opposed to the transport layer) =
perspective I think we should more clearly recognise at the beginning =
the fact that this is for the worst case network, not for well =
engineered (WAN and DC) networks  and the mechanisms fundamental to =
the operation of the network itself.




  - The first paragraph in the intro also makes clear we adopt =
the

    loss =3D=3D congestion model (as that is the conservative =
default,

    not because it is always true).



  - I made one other change that wasn't exactly called for, but

    seems like an oversight.



    Previously guideline (4) said loss MUST be taken as an

    indication of congestion and some standard response =
taken.  But,

    this guideline has an explicit exception for cases where =
we know

    the loss was caused by some non-congestion event.  =
Guideline (3)

    says you MUST backoff.  But, it did not have this =
exception for

    cases where we can tell the cause.  But, I think =
based on the

    spirit of (4), (3) should also have these words.  So, =
I added

    them.
<=
br class=3D"">
In some cases you cannot tell the cause, but it =
is more important to ignore the loss. OAM being a particularly good =
example.




    Also, I swapped (3) and (4) because it seemed more natural =
in

    re-reading to first think about taking congestion action =
and

    then dealing with backoff.  I think the ordering is a =
small

    thing, but folks can yell and I'll put it back if there =
is

    angst.



Please take a look and let me know if this helps things along or

not.



allman







We are getting there, but I =
would ask that you take the transport hat off and look again from an =
infrastructure and packet transport perspective.

Best regards

Stewart


=

--Apple-Mail=_A5C02A65-5A88-4912-9016-3591927F0E08--


From nobody Thu Jun 18 04:01:30 2020
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 466C73A0AF8; Thu, 18 Jun 2020 04:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6-jG0J6eGCz; Thu, 18 Jun 2020 04:01:23 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2E3A0AEB; Thu, 18 Jun 2020 04:01:22 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9421C1B00158; Thu, 18 Jun 2020 12:01:12 +0100 (BST)
To: Stewart Bryant , Martin Duke 
Cc: tcpm , Review Team , Mark Allman , Last Call , tom petch , draft-ietf-tcpm-rto-consider.all@ietf.org
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>   
From: Gorry Fairhurst 
Message-ID: <522d1439-a24f-490a-6a5b-6544e024c969@erg.abdn.ac.uk>
Date: Thu, 18 Jun 2020 12:01:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------73D7C32980E67CE265FBA7DB"
Content-Language: en-GB
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 11:01:28 -0000

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


See a few comments (marked GF) from the perspective of other transport 
RFCs, in case this helps you find text...

-------- Forwarded Message --------
Subject: 	Re: [tcpm] Genart last call review of 
draft-ietf-tcpm-rto-consider-14
Date: 	Thu, 18 Jun 2020 11:00:15 +0100
From: 	Stewart Bryant 
To: 	Martin Duke 
CC: 	tcpm , Review Team , Mark Allman 
, Last Call , Stewart Bryant 
, tom petch , 
draft-ietf-tcpm-rto-consider.all@ietf.org





> On 17 Jun 2020, at 18:20, Martin Duke  > wrote:
>
> Hi Stewart,
>
> If there are no further objections, I'm going to declare consensus.
>
> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke  > wrote:
>
>     Stewart,
>
>     do we need more cycles for this, or is draft-15 sufficient to
>     address your concerns?
>
>     On Mon, Jun 8, 2020 at 12:52 PM Mark Allman      > wrote:
>
>
>         Hi Stewart, et.al .!
>
>         I just submitted a new version of rto-consider. Please ask the
>         datatracker for diffs between this and rev -14.  The highlights:
>
>           - The diffs with the last rev are here:
>         https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>

*In the general case, delay across a network path depends not only on 
distance, but also a number of variable components such as the route and 
the level of buffering in intermediate devices.*


Its is more the contending/conflicting traffic rather than the 
buffering, or perhaps the time spent in queues, but “buffering” is a 
link a transport colloquial term.

GF: The word being sought might be "queueing" (I think that buffering is 
thought of as memory- and hence max queue).

*Since our wide-area network paths are best effort, packet loss is a 
regular occurrence. *


No the best effort Internet experiences this. There ate many well 
engineered WAN that do not.

What I am not seeing is clearer text that distinguishes between user 
traffic and “engineering” traffic that is used to make the network work, 
and between the end to end traffic and traffic within an AS that may be 
there for other purposes (high value service also offered by the 
provider) and WANs that are well engineered.

Perhaps we could include a clearer disclaimer regarding the 
non-best-effort-internet-end-to-end traffic?

You have some text on this down in section 2 but it is a bit buried.

Perhaps something early on of the form: This document is specially 
concerned with end to end behaviour over the best effort Internet. As 
noted in section 2 it may not me applicable to other types of WAN, or to 
the  traffic used in affecting the operation of the Internet itself.

GF: Actually, I do think a well-engineering WAN can be in scope of your 
spec. The two wrods I was expecting were "controlled environment" or 
"pre-provisioned" capacity, these might not see the same oath 
properties. A DC is typically regarded in transport specs as a 
"controlled environment".

*An exception to this rule is if an IETF standardized mechanism 
determines that a particular loss is due to a non-congestion event 
(e.g., packet corruption). *


That is a bit heavy. It should be “a protocol” there than an IETF 
standardarized mechanism. The IETF does not have a monopoly on 
pre-blessing protocols before they are deployed.

GF: Unsure myself what is needed - isn't this guidance for design of 
protocol mechansims?

>
>           - All small comments addressed.
>
>           - I think we all agree that this is not a one-size-fits-all
>             situation.  Rather, this document is meant to be a default
>         case.
>             So, the main action of this rev is to make that point more
>             clearly.  The first paragraph in the intro is new.  Also,
>         there
>             are some more words fleshing out the context more in
>         section 2.
>             In particular, more emphatically making the point that other
>             loss detectors are fine for specific cases.
>


As I note above from a routing and packet transport (as opposed to the 
transport layer) perspective I think we should more clearly recognise at 
the beginning the fact that this is for the worst case network, not for 
well engineered (WAN and DC) networks  and the mechanisms fundamental to 
the operation of the network itself.

>
>           - The first paragraph in the intro also makes clear we adopt the
>             loss == congestion model (as that is the conservative default,
>             not because it is always true).
>
>           - I made one other change that wasn't exactly called for, but
>             seems like an oversight.
>
>             Previously guideline (4) said loss MUST be taken as an
>             indication of congestion and some standard response
>         taken.  But,
>             this guideline has an explicit exception for cases where
>         we know
>             the loss was caused by some non-congestion event. 
>         Guideline (3)
>             says you MUST backoff.  But, it did not have this
>         exception for
>             cases where we can tell the cause.  But, I think based on the
>             spirit of (4), (3) should also have these words.  So, I added
>             them.
>

In some cases you cannot tell the cause, but it is more important to 
ignore the loss. OAM being a particularly good example.

>
>             Also, I swapped (3) and (4) because it seemed more natural in
>             re-reading to first think about taking congestion action and
>             then dealing with backoff.  I think the ordering is a small
>             thing, but folks can yell and I'll put it back if there is
>             angst.
>
>         Please take a look and let me know if this helps things along or
>         not.
>
>         allman
>

We are getting there, but I would ask that you take the transport hat 
off and look again from an infrastructure and packet transport perspective.

Best regards

Stewart


On 18/06/2020 11:00, Stewart Bryant wrote:
>
>
>> On 17 Jun 2020, at 18:20, Martin Duke > > wrote:
>>
>> Hi Stewart,
>>
>> If there are no further objections, I'm going to declare consensus.
>>
>> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke > > wrote:
>>
>>     Stewart,
>>
>>     do we need more cycles for this, or is draft-15 sufficient to
>>     address your concerns?
>>
>>     On Mon, Jun 8, 2020 at 12:52 PM Mark Allman >     > wrote:
>>
>>
>>         Hi Stewart, et.al .!
>>
>>         I just submitted a new version of rto-consider. Please ask the
>>         datatracker for diffs between this and rev -14.  The highlights:
>>
>>           - The diffs with the last rev are here:
>>         https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt
>>
>
> *In the general case, delay across a network path depends not only on 
> distance, but also a number of variable components such as the route 
> and the level of buffering in intermediate devices.*
>
> Its is more the contending/conflicting traffic rather than the 
> buffering, or perhaps the time spent in queues, but “buffering” is a 
> link a transport colloquial term.
>
>
> *Since our wide-area network paths are best effort, packet loss is a 
> regular occurrence. *
>
> No the best effort Internet experiences this. There ate many well 
> engineered WAN that do not.
>
> What I am not seeing is clearer text that distinguishes between user 
> traffic and “engineering” traffic that is used to make the network 
> work, and between the end to end traffic and traffic within an AS that 
> may be there for other purposes (high value service also offered by 
> the provider) and WANs that are well engineered.
>
> Perhaps we could include a clearer disclaimer regarding the 
> non-best-effort-internet-end-to-end traffic?
>
> You have some text on this down in section 2 but it is a bit buried.
>
> Perhaps something early on of the form: This document is specially 
> concerned with end to end behaviour over the best effort Internet. As 
> noted in section 2 it may not me applicable to other types of WAN, or 
> to the  traffic used in affecting the operation of the Internet itself.
>
>
> *An exception to this rule is if an IETF standardized mechanism 
> determines that a particular loss is due to a non-congestion event 
> (e.g., packet corruption). *
>
> That is a bit heavy. It should be “a protocol” there than an IETF 
> standardarized mechanism. The IETF does not have a monopoly on 
> pre-blessing protocols before they are deployed.
>
>
>
>>
>>           - All small comments addressed.
>>
>>           - I think we all agree that this is not a one-size-fits-all
>>             situation.  Rather, this document is meant to be a
>>         default case.
>>             So, the main action of this rev is to make that point more
>>             clearly.  The first paragraph in the intro is new.  Also,
>>         there
>>             are some more words fleshing out the context more in
>>         section 2.
>>             In particular, more emphatically making the point that other
>>             loss detectors are fine for specific cases.
>>
>
>
> As I note above from a routing and packet transport (as opposed to the 
> transport layer) perspective I think we should more clearly recognise 
> at the beginning the fact that this is for the worst case network, not 
> for well engineered (WAN and DC) networks  and the mechanisms 
> fundamental to the operation of the network itself.
>
>>
>>           - The first paragraph in the intro also makes clear we
>>         adopt the
>>             loss == congestion model (as that is the conservative
>>         default,
>>             not because it is always true).
>>
>>           - I made one other change that wasn't exactly called for, but
>>             seems like an oversight.
>>
>>             Previously guideline (4) said loss MUST be taken as an
>>             indication of congestion and some standard response
>>         taken.  But,
>>             this guideline has an explicit exception for cases where
>>         we know
>>             the loss was caused by some non-congestion event. 
>>         Guideline (3)
>>             says you MUST backoff.  But, it did not have this
>>         exception for
>>             cases where we can tell the cause.  But, I think based on the
>>             spirit of (4), (3) should also have these words.  So, I added
>>             them.
>>
>
> In some cases you cannot tell the cause, but it is more important to 
> ignore the loss. OAM being a particularly good example.
>
>>
>>             Also, I swapped (3) and (4) because it seemed more natural in
>>             re-reading to first think about taking congestion action and
>>             then dealing with backoff.  I think the ordering is a small
>>             thing, but folks can yell and I'll put it back if there is
>>             angst.
>>
>>         Please take a look and let me know if this helps things along or
>>         not.
>>
>>         allman
>>
>
> We are getting there, but I would ask that you take the transport hat 
> off and look again from an infrastructure and packet transport 
> perspective.
>
> Best regards
>
> Stewart
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--------------73D7C32980E67CE265FBA7DB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
See a few comments (marked GF)
      from the perspective of other transport RFCs, in case this helps
      you find text...

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Re: [tcpm] Genart last call review of
              draft-ietf-tcpm-rto-consider-14
          

          

            Date: 
            Thu, 18 Jun 2020 11:00:15 +0100
          

          

            From: 
            Stewart Bryant <stewart.bryant@gmail.com>
          

          

            To: 
            Martin Duke <martin.h.duke@gmail.com>
          

          

            CC: 
            tcpm <tcpm@ietf.org>, Review Team
              <gen-art@ietf.org>, Mark Allman
              <mallman@icir.org>, Last Call
              <last-call@ietf.org>, Stewart Bryant
              <stewart.bryant@gmail.com>, tom petch
              <daedulus@btconnect.com>,
              draft-ietf-tcpm-rto-consider.all@ietf.org
          

        
      

      

      

      

      


        

          
On 17 Jun 2020, at 18:20, Martin Duke <martin.h.duke@gmail.com>
            wrote:

          

          

            
Hi Stewart,
              


              

              
If there are no further objections, I'm
                going to declare consensus.

            

            

            

              
On Thu, Jun 11, 2020 at
                1:45 PM Martin Duke <martin.h.duke@gmail.com>
                wrote:

              

              

                
Stewart,
                  


                  

                  
do we need more cycles for this, or is
                    draft-15 sufficient to address your concerns?

                

                

                

                  
On Mon, Jun 8, 2020
                    at 12:52 PM Mark Allman <mallman@icir.org> wrote:

                  

                  


                    Hi Stewart, et.al.!

                    

                    I just submitted a new version of rto-consider. 
                    Please ask the

                    datatracker for diffs between this and rev -14.  The
                    highlights:

                    

                      - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

                  

                

              

            

          

        

        


        

        

          
In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

          


          

          
Its is more the contending/conflicting traffic
            rather than the buffering, or perhaps the time spent in
            queues, but “buffering” is a link a transport colloquial
            term.

          


          

          
GF: The word being sought might be "queueing" (I
            think that buffering is thought of as memory- and hence max
            queue).

          

          

            
Since our wide-area network paths are best
    effort, packet loss is a regular occurrence. 

            


            

          

          
No the best effort Internet experiences this.
            There ate many well engineered WAN that do not.

          


          

          
What I am not seeing is clearer text that
            distinguishes between user traffic and “engineering” traffic
            that is used to make the network work, and between the end
            to end traffic and traffic within an AS that may be there
            for other purposes (high value service also offered by the
            provider) and WANs that are well engineered.

          


          

          
Perhaps we could include a clearer disclaimer
            regarding the non-best-effort-internet-end-to-end traffic?

          


          

          
You have some text on this down in section 2 but
            it is a bit buried.

          


          

          
Perhaps something early on of the form: This
            document is specially concerned with end to end behaviour
            over the best effort Internet. As noted in section 2 it may
            not me applicable to other types of WAN, or to the  traffic
            used in affecting the operation of the Internet itself.

          


          

          

            
GF: Actually, I do think a well-engineering
              WAN can be in scope of your spec. The two wrods I was
              expecting were "controlled environment" or
              "pre-provisioned" capacity, these might not see the same
              oath properties. A DC is typically regarded in transport
              specs as a "controlled environment".

          

          

            
 An exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  

            


            

          

          
That is a bit heavy. It should be “a protocol”
            there than an IETF standardarized mechanism. The IETF does
            not have a monopoly on pre-blessing protocols before they
            are deployed.

          


          

        

        
GF: Unsure myself what is needed - isn't this guidance for
          design of protocol mechansims?

        

        

        

          

            

              

                

                  

                    

                      - All small comments addressed.

                    

                      - I think we all agree that this is not a
                    one-size-fits-all

                        situation.  Rather, this document is meant to be
                    a default case.

                        So, the main action of this rev is to make that
                    point more

                        clearly.  The first paragraph in the intro is
                    new.  Also, there

                        are some more words fleshing out the context
                    more in section 2.

                        In particular, more emphatically making the
                    point that other

                        loss detectors are fine for specific cases.

                  

                

              

            

          

        

        


        

        


        

        
As I note above from a routing and packet transport (as
          opposed to the transport layer) perspective I think we should
          more clearly recognise at the beginning the fact that this is
          for the worst case network, not for well engineered (WAN and
          DC) networks  and the mechanisms fundamental to the operation
          of the network itself.

        

        

          

            

              

                

                  

                    

                      - The first paragraph in the intro also makes
                    clear we adopt the

                        loss == congestion model (as that is the
                    conservative default,

                        not because it is always true).

                    

                      - I made one other change that wasn't exactly
                    called for, but

                        seems like an oversight.

                    

                        Previously guideline (4) said loss MUST be taken
                    as an

                        indication of congestion and some standard
                    response taken.  But,

                        this guideline has an explicit exception for
                    cases where we know

                        the loss was caused by some non-congestion
                    event.  Guideline (3)

                        says you MUST backoff.  But, it did not have
                    this exception for

                        cases where we can tell the cause.  But, I think
                    based on the

                        spirit of (4), (3) should also have these
                    words.  So, I added

                        them.

                  

                

              

            

          

        

        


        

        
In some cases you cannot tell the cause, but it is more
          important to ignore the loss. OAM being a particularly good
          example.

        

        

          

            

              

                

                  

                    

                        Also, I swapped (3) and (4) because it seemed
                    more natural in

                        re-reading to first think about taking
                    congestion action and

                        then dealing with backoff.  I think the ordering
                    is a small

                        thing, but folks can yell and I'll put it back
                    if there is

                        angst.

                    

                    Please take a look and let me know if this helps
                    things along or

                    not.

                    

                    allman

                  

                

              

            

          

        

        

      

      
We are getting there, but I would ask that you take the
        transport hat off and look again from an infrastructure and
        packet transport perspective.

      


      

      
Best regards

      


      

      
Stewart

      


      

      

    

    
On 18/06/2020 11:00, Stewart Bryant
      wrote:

    

    

      
      

      


        

          
On 17 Jun 2020, at 18:20, Martin Duke <martin.h.duke@gmail.com>
            wrote:

          

          

            
Hi Stewart,
              


              

              
If there are no further objections, I'm
                going to declare consensus.

            

            

            

              
On Thu, Jun 11, 2020 at
                1:45 PM Martin Duke <martin.h.duke@gmail.com>
                wrote:

              

              

                
Stewart,
                  


                  

                  
do we need more cycles for this, or is
                    draft-15 sufficient to address your concerns?

                

                

                

                  
On Mon, Jun 8, 2020
                    at 12:52 PM Mark Allman <mallman@icir.org>
                    wrote:

                  

                  


                    Hi Stewart, et.al.!

                    

                    I just submitted a new version of rto-consider. 
                    Please ask the

                    datatracker for diffs between this and rev -14.  The
                    highlights:

                    

                      - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt

                  

                

              

            

          

        

        


        

        

          
In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

          


          

          
Its is more the contending/conflicting traffic
            rather than the buffering, or perhaps the time spent in
            queues, but “buffering” is a link a transport colloquial
            term.

          


          

          


          

          

            
Since our wide-area network paths are best
    effort, packet loss is a regular occurrence. 

            


            

          

          
No the best effort Internet experiences this.
            There ate many well engineered WAN that do not.

          


          

          
What I am not seeing is clearer text that
            distinguishes between user traffic and “engineering” traffic
            that is used to make the network work, and between the end
            to end traffic and traffic within an AS that may be there
            for other purposes (high value service also offered by the
            provider) and WANs that are well engineered.

          


          

          
Perhaps we could include a clearer disclaimer
            regarding the non-best-effort-internet-end-to-end traffic?

          


          

          
You have some text on this down in section 2 but
            it is a bit buried.

          


          

          
Perhaps something early on of the form: This
            document is specially concerned with end to end behaviour
            over the best effort Internet. As noted in section 2 it may
            not me applicable to other types of WAN, or to the  traffic
            used in affecting the operation of the Internet itself.

          


          

          


          

          

            
 An exception to this rule is if an IETF standardized mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  

            


            

          

          
That is a bit heavy. It should be “a protocol”
            there than an IETF standardarized mechanism. The IETF does
            not have a monopoly on pre-blessing protocols before they
            are deployed.

          


          

        

        


        

        

        

          

            

              

                

                  

                    

                      - All small comments addressed.

                    

                      - I think we all agree that this is not a
                    one-size-fits-all

                        situation.  Rather, this document is meant to be
                    a default case.

                        So, the main action of this rev is to make that
                    point more

                        clearly.  The first paragraph in the intro is
                    new.  Also, there

                        are some more words fleshing out the context
                    more in section 2.

                        In particular, more emphatically making the
                    point that other

                        loss detectors are fine for specific cases.

                  

                

              

            

          

        

        


        

        


        

        
As I note above from a routing and packet transport (as
          opposed to the transport layer) perspective I think we should
          more clearly recognise at the beginning the fact that this is
          for the worst case network, not for well engineered (WAN and
          DC) networks  and the mechanisms fundamental to the operation
          of the network itself.

        

        

          

            

              

                

                  

                    

                      - The first paragraph in the intro also makes
                    clear we adopt the

                        loss == congestion model (as that is the
                    conservative default,

                        not because it is always true).

                    

                      - I made one other change that wasn't exactly
                    called for, but

                        seems like an oversight.

                    

                        Previously guideline (4) said loss MUST be taken
                    as an

                        indication of congestion and some standard
                    response taken.  But,

                        this guideline has an explicit exception for
                    cases where we know

                        the loss was caused by some non-congestion
                    event.  Guideline (3)

                        says you MUST backoff.  But, it did not have
                    this exception for

                        cases where we can tell the cause.  But, I think
                    based on the

                        spirit of (4), (3) should also have these
                    words.  So, I added

                        them.

                  

                

              

            

          

        

        


        

        
In some cases you cannot tell the cause, but it is more
          important to ignore the loss. OAM being a particularly good
          example.

        

        

          

            

              

                

                  

                    

                        Also, I swapped (3) and (4) because it seemed
                    more natural in

                        re-reading to first think about taking
                    congestion action and

                        then dealing with backoff.  I think the ordering
                    is a small

                        thing, but folks can yell and I'll put it back
                    if there is

                        angst.

                    

                    Please take a look and let me know if this helps
                    things along or

                    not.

                    

                    allman

                  

                

              

            

          

        

        

      

      
We are getting there, but I would ask that you take the
        transport hat off and look again from an infrastructure and
        packet transport perspective.

      


      

      
Best regards

      


      

      
Stewart

      


      

      

      

      

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


    

  


--------------73D7C32980E67CE265FBA7DB--


From nobody Thu Jun 18 05:57:01 2020
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 C5C343A0D4A; Thu, 18 Jun 2020 05:56:59 -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, 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 baEGECpwOmjZ; Thu, 18 Jun 2020 05:56:55 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 34F063A09BD; Thu, 18 Jun 2020 05:56:55 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id r15so5530886wmh.5; Thu, 18 Jun 2020 05:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mP7BES5J1vHlYpN1QNWT2rj1p3G9i/RafJXHqAyhlRw=; b=AJNGPYH8Olwurl6+Vahn7/fF/p6PW/dadPX2wqGbBtjRSPN874Z03ZrSTJDtXYYsOL hDX8d0yOnBmvoScpoVzlMQv5QV3vMq8bSeRKCrynIj7bfG/HLGeVQhIplbDqyBQawyfO FLKOZRbjZM8hiXgJWrTccIrkMe+dCToIiATcA5obg/ebP4fjYm5AzWtNJ+hZL/+gdweO Yi9WVp2SK8zAzPQgoDyjXSnLT0QFLGKkx/TUv4NHDRM9LtiYJLnC/o7GeY6MAFbABXJK 9wsGe2LlwY9GxbYTxAqcWOQ2DqTWf0ldS24gleO2tTmt9X3tn6XgjtwEW/18AQz+42RS MQqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mP7BES5J1vHlYpN1QNWT2rj1p3G9i/RafJXHqAyhlRw=; b=Q9MqrRZPfRGfMCEZ79YJMecCUPirg08PgoZIUmMurmQu2lHOSQfvvVl3kTFAJ8Vh60 6UxfHQUAsvPiKZ0P86pyerSOdcPnzSAX5bi0zpyQMVC0rl788E4qgbBcEBF8zI9n89rk qADjMx5Nnf3KpTMancwhHhjtCRo+WxE2FPuxfCx6wtSu20+76OdaOKqIYcXnBAd85L7S PkDSJC9gPmvUct7Gys+MK+oNDEUhY/SQn7DP5HcDaiQePZnPEHSUcoJ3JMGhYa/0t1OE I0xCjCoiTdWwCjLJ4P647jYhxmPY2emx39GV5mNNT2fVcAR3wxsFL0anD56RVeaX+Jbw wLmw==
X-Gm-Message-State: AOAM533YuzsyaATnglYpdUWwcNr4NhlHSRBn245evE9vDkMxl5eijIAV cHsnbL6C+EG8W9T+TjIQIqk=
X-Google-Smtp-Source: ABdhPJyeaB9GinOT6owG7Ku+nPdWm8OXyRq4+nPkrXhLikXAcQcxoV7YuoYXRWMGemBqPrTTqWF/Qw==
X-Received: by 2002:a1c:3c08:: with SMTP id j8mr3750244wma.23.1592485013286; Thu, 18 Jun 2020 05:56:53 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id q4sm3561049wma.47.2020.06.18.05.56.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 05:56:52 -0700 (PDT)
From: Stewart Bryant 
Message-Id: <8C4B7C4D-7658-4219-856B-95D99473770B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C1EB3E47-AD7C-4517-8ABE-0C81CFA8A7C6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 18 Jun 2020 13:56:51 +0100
In-Reply-To: <522d1439-a24f-490a-6a5b-6544e024c969@erg.abdn.ac.uk>
Cc: Stewart Bryant , Martin Duke , tcpm , Review Team , Mark Allman , Last Call , tom petch , draft-ietf-tcpm-rto-consider.all@ietf.org
To: Gorry Fairhurst 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>    <522d1439-a24f-490a-6a5b-6544e024c969@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 12:57:00 -0000

--Apple-Mail=_C1EB3E47-AD7C-4517-8ABE-0C81CFA8A7C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 18 Jun 2020, at 12:01, Gorry Fairhurst  =
wrote:
>=20
>=20
>=20
> See a few comments (marked GF) from the perspective of other transport =
RFCs, in case this helps you find text...
>=20
> -------- Forwarded Message --------
> Subject:	Re: [tcpm] Genart last call review of =
draft-ietf-tcpm-rto-consider-14
> Date:	Thu, 18 Jun 2020 11:00:15 +0100
> From:	Stewart Bryant  =

> To:	Martin Duke  =

> CC:	tcpm  , Review Team =
 , Mark Allman =
 , Last Call =
 , Stewart Bryant =
 , tom petch =
 , =
draft-ietf-tcpm-rto-consider.all@ietf.org =

>=20
>=20
>=20
>> On 17 Jun 2020, at 18:20, Martin Duke > wrote:
>>=20
>> Hi Stewart,
>>=20
>> If there are no further objections, I'm going to declare consensus.
>>=20
>> On Thu, Jun 11, 2020 at 1:45 PM Martin Duke > wrote:
>> Stewart,
>>=20
>> do we need more cycles for this, or is draft-15 sufficient to address =
your concerns?
>>=20
>> On Mon, Jun 8, 2020 at 12:52 PM Mark Allman > wrote:
>>=20
>> Hi Stewart, et.al .!
>>=20
>> I just submitted a new version of rto-consider.  Please ask the
>> datatracker for diffs between this and rev -14.  The highlights:
>>=20
>>   - The diffs with the last rev are here: =
https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tcpm-=
rto-consider-15.txt =

>=20
> In the general case, delay across a
>     network path depends not only on distance, but also a number of
>     variable components such as the route and the level of buffering =
in
>     intermediate devices.
>=20
> Its is more the contending/conflicting traffic rather than the =
buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffering=E2=80=
=9D is a link a transport colloquial term.
>=20
> GF: The word being sought might be "queueing" (I think that buffering =
is thought of as memory- and hence max queue).

SB> Queuing ins the word, thank you.
> Since our wide-area network paths are best
>     effort, packet loss is a regular occurrence.=20
>=20
> No the best effort Internet experiences this. There ate many well =
engineered WAN that do not.
>=20
> What I am not seeing is clearer text that distinguishes between user =
traffic and =E2=80=9Cengineering=E2=80=9D traffic that is used to make =
the network work, and between the end to end traffic and traffic within =
an AS that may be there for other purposes (high value service also =
offered by the provider) and WANs that are well engineered.
>=20
> Perhaps we could include a clearer disclaimer regarding the =
non-best-effort-internet-end-to-end traffic?
>=20
> You have some text on this down in section 2 but it is a bit buried.
>=20
> Perhaps something early on of the form: This document is specially =
concerned with end to end behaviour over the best effort Internet. As =
noted in section 2 it may not me applicable to other types of WAN, or to =
the  traffic used in affecting the operation of the Internet itself.
>=20
> GF: Actually, I do think a well-engineering WAN can be in scope of =
your spec. The two wrods I was expecting were "controlled environment" =
or "pre-provisioned" capacity, these might not see the same oath =
properties. A DC is typically regarded in transport specs as a =
"controlled environment".

SB> That works for me as well.

>  An exception to this rule is if an IETF standardized mechanism
>         determines that a particular loss is due to a non-congestion
>         event (e.g., packet corruption). =20
>=20
> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there =
than an IETF standardarized mechanism. The IETF does not have a monopoly =
on pre-blessing protocols before they are deployed.
>=20
> GF: Unsure myself what is needed - isn't this guidance for design of =
protocol mechansims?

SB> .. and if that is the case the words used in the text are way over =
the top, and may actually cause harm to innocent protocols.
SB> There is a bunch of concern in the industry that the IETF is now too =
illiberal and such words fuel that concern.

Best regards

Stewart



--Apple-Mail=_C1EB3E47-AD7C-4517-8ABE-0C81CFA8A7C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 18 Jun 2020, at 12:01, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:


 =20
    
 =20
  


    

    
See a few comments (marked GF)
      from the perspective of other transport RFCs, in case this helps
      you find text...

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Re: [tcpm] Genart last call review of
              draft-ietf-tcpm-rto-consider-14
          

          

            Date: 
            Thu, 18 Jun 2020 11:00:15 +0100
          

          

            From: 
            Stewart Bryant <stewart.bryant@gmail.com><=
/a>
          

          

            To: 
            Martin Duke <martin.h.duke@gmail.com>
          

          

            CC: 
            tcpm <tcpm@ietf.org>, Review Team
              <gen-art@ietf.org>, Mark =
Allman
              <mallman@icir.org>, Last Call
              <last-call@ietf.org>, =
Stewart Bryant
              <stewart.bryant@gmail.com><=
/a>, tom petch
              <daedulus@btconnect.com>,=

              draft-ietf-tcpm-=
rto-consider.all@ietf.org
          

        
      

      

      

      

      


        

          
On 17 Jun 2020, at 18:20, Martin Duke <martin.h.duke@gmail.com>
            wrote:

          

          

            
Hi Stewart,
              


              

              
If there are no further objections, I'm
                going to declare consensus.

            

            

            

              
On Thu, Jun 11, 2020 =
at
                1:45 PM Martin Duke <martin.h.duke@gmail.com>
                wrote:

              

              

                
Stewart,
                  


                  

                  
do we need more cycles for this, or is
                    draft-15 sufficient to address your concerns?

                

                

                

                  
On Mon, Jun 8, =
2020
                    at 12:52 PM Mark Allman <mallman@icir.org> wrote:

                  

                  


                    Hi Stewart, et.al.!
=

                    

                    I just submitted a new version of =
rto-consider. 
                    Please ask the

                    datatracker for diffs between this and rev =
-14.  The
                    highlights:

                    

                      - The diffs with the last rev are here: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd=
raft-ietf-tcpm-rto-consider-15.txt

                  

                

              

            

          

        

        


        

        

          
In the general case, delay across a
    network path depends not only on distance, but also a number of
    variable components such as the route and the level of buffering in
    intermediate devices.

          


          

          
Its is more the contending/conflicting traffic
            rather than the buffering, or perhaps the time spent in
            queues, but =E2=80=9Cbuffering=E2=80=9D is a link a =
transport colloquial
            term.

          


          

          
GF: The word being sought might be "queueing" =
(I
            think that buffering is thought of as memory- and hence max
            queue).

SB> Queuing ins the word, thank you.

          

          

            
Since our wide-area network paths are best
    effort, packet loss is a regular occurrence. 

            


            

          

          
No the best effort Internet experiences this.
            There ate many well engineered WAN that do not.

          


          

          
What I am not seeing is clearer text that
            distinguishes between user traffic and =E2=80=9Cengineering=E2=
=80=9D traffic
            that is used to make the network work, and between the end
            to end traffic and traffic within an AS that may be there
            for other purposes (high value service also offered by the
            provider) and WANs that are well engineered.

          


          

          
Perhaps we could include a clearer disclaimer
            regarding the non-best-effort-internet-end-to-end =
traffic?

          


          

          
You have some text on this down in section 2 =
but
            it is a bit buried.

          


          

          
Perhaps something early on of the form: This
            document is specially concerned with end to end behaviour
            over the best effort Internet. As noted in section 2 it may
            not me applicable to other types of WAN, or to the =
 traffic
            used in affecting the operation of the Internet =
itself.

          


          

          

            
GF: Actually, I do think a well-engineering
              WAN can be in scope of your spec. The two wrods I was
              expecting were "controlled environment" or
              "pre-provisioned" capacity, these might not see the same
              oath properties. A DC is typically regarded in transport
              specs as a "controlled =
environment".
<=
br class=3D"">
SB> That works for me as well.


          

          

            
 An exception to this rule is if an IETF standardized =
mechanism
        determines that a particular loss is due to a non-congestion
        event (e.g., packet corruption).  

            


            

          

          
That is a bit heavy. It should be =E2=80=9Ca =
protocol=E2=80=9D
            there than an IETF standardarized mechanism. The IETF does
            not have a monopoly on pre-blessing protocols before they
            are deployed.

          


          

        

        
GF: Unsure myself what is needed - isn't this =
guidance for
          design of protocol =
mechansims?

SB> .. and if that is the case the words used =
in the text are way over the top, and may actually cause harm to =
innocent protocols.
SB> There is a bunch of concern in the =
industry that the IETF is now too illiberal and such words fuel that =
concern.

Best regards

Stewart


=

--Apple-Mail=_C1EB3E47-AD7C-4517-8ABE-0C81CFA8A7C6--


From nobody Thu Jun 18 06:33:00 2020
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 196C83A1129 for ; Thu, 18 Jun 2020 06:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level: 
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 a0V009cDg_tB for ; Thu, 18 Jun 2020 06:32:43 -0700 (PDT)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 7BB813A1030 for ; Thu, 18 Jun 2020 06:32:20 -0700 (PDT)
Received: by mail-oi1-f179.google.com with SMTP id k4so5081660oik.2 for ; Thu, 18 Jun 2020 06:32:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=KJY7iMMlO4vmvVjOeOugeRmi49K0C3+CD6AiJ1YaH8A=; b=hGni1i732LRkvingbE7BInvdUnIU6tQRMuDri9SbsaVGHxRuMG+44RNsZu83KX4+sB 1SE2Af/xBSxEpPKSCiy9PbaOvS/q4ELp3AgMV0wfqi25q2SSL/UihT3HrjezBHi6UmE+ KSks+uGNjR7qhiweZjqnHlCSAdxo+o90T5xv5UvbE5b7/HBdkARp5W9WDfUosE0XyWN/ XkpSWdciw12bXyK+E0v+0wZmIdRWABm6K21ixSnT2dKDab3EGRmIyHnBeZqXBtFiosv0 95moSbrLD/YRoVS8CxK5KwvDOfLfPvDiIBMQoFSDiu4FqfjTIdSnggdp/NNxBtRF0BRg 2INQ==
X-Gm-Message-State: AOAM532lcXUi6m6FwZPFkw/KwRAGf0SwbK+1vC4nz/VdTh2h84scKv0e BGhgRGlxA0K1xA0PHK4subGQKw==
X-Google-Smtp-Source: ABdhPJyluxM77vPwzbRaKgQnYS9aeaYncowsZJcetgseCJgsGRFJ0h8FfPtzfGLGZEAFJic5FE4tEA==
X-Received: by 2002:aca:cf4c:: with SMTP id f73mr2756309oig.165.1592487139672;  Thu, 18 Jun 2020 06:32:19 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:7c97:4043:1622:ee65]) by smtp.gmail.com with ESMTPSA id c23sm699752otd.7.2020.06.18.06.32.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 06:32:18 -0700 (PDT)
From: "Mark Allman" 
To: "Stewart Bryant" 
Cc: "Martin Duke" , "Review Team" ,  tcpm , "Last Call" , draft-ietf-tcpm-rto-consider.all@ietf.org, "tom petch" 
Date: Thu, 18 Jun 2020 09:32:15 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: 
In-Reply-To: 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>   
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_DE62FB0B-1C9C-45FB-BCA3-776933061004_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 13:32:52 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_DE62FB0B-1C9C-45FB-BCA3-776933061004_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Last comment first ...

> We are getting there, but I would ask that you take the transport
> hat off and look again from an infrastructure and packet transport
> perspective.

I don't view this as looking at it from a transport
vs. infrastructure perspective.

And, I am not disagreeing with your perspective.  My take is that
the nub of what you're saying is that there are cases where we know
something about the network.  And, that something let's us design a
more savvy loss detection and response scheme.  E.g., because the
link / path is known to be short and so using an initial RTO of 1sec
is too long.  E.g., because the cause of loss is known or can be
safely assumed to not be congestion.  And, I think that view is both
correct and reasonable.

However, ...

(0) I do not view that view as inconsistent with this document at
    all.

(1) Because there are cases where we know more doesn't make a set of
    default requirements for the general case when we don't
    understand the path any less valid.

(2) The document explicitly says alternates are fine modulo the
    usual consensus.  I.e., in cases where we have more information
    we can do things differently.  And, the cost of that is no
    different than the cost today (i.e., specifying it and gaining
    consensus).

So, my view is that this all boils down to making it clear that this
is not somehow THE (best) way to do time-based loss detection for
all cases.  Rather, following the guidelines with result in a
safe-for-general-use loss detector.

> In the general case, delay across a
>     network path depends not only on distance, but also a number of
>     variable components such as the route and the level of buffering in=

>     intermediate devices.
>
> Its is more the contending/conflicting traffic rather than the
> buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffering=E2=
=80=9D is
> a link a transport colloquial term.

Per this and Gorry's note, I will tweak this to use queuing, as that
is what I meant.

> Perhaps we could include a clearer disclaimer regarding the
> non-best-effort-internet-end-to-end traffic?
> You have some text on this down in section 2 but it is a bit buried.

OK, let me see if I can foreshadow this a bit more and/or pull some
from section 2 to earlier.

>  An exception to this rule is if an IETF standardized mechanism
>         determines that a particular loss is due to a non-congestion
>         event (e.g., packet corruption).
>
> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there th=
an an IETF
> standardarized mechanism. The IETF does not have a monopoly on
> pre-blessing protocols before they are deployed.
> [...]
>
> In some cases you cannot tell the cause, but it is more important
> to ignore the loss. OAM being a particularly good example.

First, I don't think I can readily change this without going against
the consensus the document has already gathered.  (I.e., this is not
about the intro, framing, context, etc. bits, but the actual meat of
the technical stuff.)

Second, you are right that the IETF does not have a monopoly, but
that doesn't make the statement in the document the wrong thing to
say.

Third, I doubt I should change it.  The problem here from the
standpoint of a set of default guidelines is that we'd like a
mechanism to determine the cause of loss to **actually work** before
it's OK to avoid a congestion control response.  If a standardized
mechanism is used then we have some confidence that the mechanism
has been vetted as reasonable.  If the mechanism is not standardized
then we have no idea if it actually works or if it is some
ill-conceived scheme that is badly broken.  In this latter case, I
don't think we want to bless this approach as OK within the default.
It may be OK, but it should get some consensus that it is OK.

allman

--=_MailMate_DE62FB0B-1C9C-45FB-BCA3-776933061004_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuts3xEcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizvgeAKCDV/dBo2ug0kxPTa8Uc65JXn70iwCeKJke
VtwTcmEGTfsM+l3YL5lPqrw=
=Hl+5
-----END PGP SIGNATURE-----

--=_MailMate_DE62FB0B-1C9C-45FB-BCA3-776933061004_=--


From nobody Thu Jun 18 07:18:25 2020
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 ED2FE3A1104; Thu, 18 Jun 2020 07:18:14 -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, FREEMAIL_FROM=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 fWdE7I8CJkKF; Thu, 18 Jun 2020 07:18:10 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 B58E83A1101; Thu, 18 Jun 2020 07:18:09 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id l11so6270354wru.0; Thu, 18 Jun 2020 07:18:09 -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=3x/Zjix9accJqMLPNYOKYwsXjg54s4StSOFmpsKa4CE=; b=jldGAANlWpqZZZ8nuQ5Cdi54riguuSU8Xu+4wz0dAF5oR4fOjs/xNqXSFGT9WJcyZJ o2W8Up2aaPGl3vhprayBlapGvy7Q97vr6fHNFxTsNbAIXagnptqXBzU72A0SLocN+TSR cB158/a0ItY9eocrxg55LD8KB7dKoHRy+bUfeCM6OuZzg9edPhBWSQ7rJRt3WC6PJpIn jzJXwt9OPniP3pDTlZgCgNKDEsSfykSddV0l7TP+erbXZvzJCc3SJCPop/OyWkNsB+4U hJB2ePWlGZbkeJ3Mmz+3GRlnAmlXcbR6vbxnwM2vu8/QwFlKW51CvgM5V/P17Ji+cInB A2cQ==
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=3x/Zjix9accJqMLPNYOKYwsXjg54s4StSOFmpsKa4CE=; b=QrPf4DXDG33aILfvrXuLYM4bJcD4i5p955Q72T0Qwkm0H0XGU6LPAKn4jXi83ZaFQd z7MJ1z/yMC0H02FpMFCTDLq70ejJ9WJU6dNuiJ9uZ89E4w0P2pslsE/qaM6QK62k7vwy sX2p3P6/5+P8iKdkvLrycJstFLfklK2/e/Nsfwv6YYPuNn+PN51mBwEpLbohXHBpwFL5 US0yQjWcNIPaji8idhVUIMoZlWHWSDci+D1UmU0gDHNwVgmgvIbln/RFZ6rfOVMF9Bsx LeMsqN27rZMbR96+SO+u5UfVIPQFvprarO2leAZc+qjO3Hdenoma2j576J2n0ewKraL5 Kqzg==
X-Gm-Message-State: AOAM5319kGsgub6CSP9IZLVoWlufNpTazAtufXiqx/3XsP3Cg9gx73dH TmTAA5vz90kxYxxjn7Zk8cM=
X-Google-Smtp-Source: ABdhPJwiW8GiV7ofxc4zQo7whQF1JnaJ+mEmF8VKh3vB65D5iM1m9WjTr5oL+hSkW96crFSZyYmHwQ==
X-Received: by 2002:adf:a306:: with SMTP id c6mr4903767wrb.122.1592489887938;  Thu, 18 Jun 2020 07:18:07 -0700 (PDT)
Received: from appleton.fritz.box ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id b201sm3778150wmb.36.2020.06.18.07.18.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 07:18:07 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant 
In-Reply-To: 
Date: Thu, 18 Jun 2020 15:18:05 +0100
Cc: Stewart Bryant , Martin Duke , Review Team , tcpm , Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org, tom petch 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>    
To: Mark Allman 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 14:18:15 -0000

Here is how we should proceed.

We make as much progress as we can agree on which will clear some of the =
issue below.

For any remaining issues for which you have wider consensus but where we =
cannot agree, I modify my review and the IESG decides how they wish to =
proceed.

I am prepared to be in the rough but I have a duty to draw attention to =
concerns.

Best regards

Stewart


> On 18 Jun 2020, at 14:32, Mark Allman  wrote:
>=20
>=20
> Last comment first ...
>=20
>> We are getting there, but I would ask that you take the transport
>> hat off and look again from an infrastructure and packet transport
>> perspective.
>=20
> I don't view this as looking at it from a transport
> vs. infrastructure perspective.
>=20
> And, I am not disagreeing with your perspective.  My take is that
> the nub of what you're saying is that there are cases where we know
> something about the network.  And, that something let's us design a
> more savvy loss detection and response scheme.  E.g., because the
> link / path is known to be short and so using an initial RTO of 1sec
> is too long.  E.g., because the cause of loss is known or can be
> safely assumed to not be congestion.  And, I think that view is both
> correct and reasonable.
>=20
> However, ...
>=20
> (0) I do not view that view as inconsistent with this document at
>    all.
>=20
> (1) Because there are cases where we know more doesn't make a set of
>    default requirements for the general case when we don't
>    understand the path any less valid.
>=20
> (2) The document explicitly says alternates are fine modulo the
>    usual consensus.  I.e., in cases where we have more information
>    we can do things differently.  And, the cost of that is no
>    different than the cost today (i.e., specifying it and gaining
>    consensus).
>=20
> So, my view is that this all boils down to making it clear that this
> is not somehow THE (best) way to do time-based loss detection for
> all cases.  Rather, following the guidelines with result in a
> safe-for-general-use loss detector.
>=20
>> In the general case, delay across a
>>    network path depends not only on distance, but also a number of
>>    variable components such as the route and the level of buffering =
in
>>    intermediate devices.
>>=20
>> Its is more the contending/conflicting traffic rather than the
>> buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffering=E2=
=80=9D is
>> a link a transport colloquial term.
>=20
> Per this and Gorry's note, I will tweak this to use queuing, as that
> is what I meant.
>=20
>> Perhaps we could include a clearer disclaimer regarding the
>> non-best-effort-internet-end-to-end traffic?
>> You have some text on this down in section 2 but it is a bit buried.
>=20
> OK, let me see if I can foreshadow this a bit more and/or pull some
> from section 2 to earlier.
>=20
>> An exception to this rule is if an IETF standardized mechanism
>>        determines that a particular loss is due to a non-congestion
>>        event (e.g., packet corruption).
>>=20
>> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there =
than an IETF
>> standardarized mechanism. The IETF does not have a monopoly on
>> pre-blessing protocols before they are deployed.
>> [...]
>>=20
>> In some cases you cannot tell the cause, but it is more important
>> to ignore the loss. OAM being a particularly good example.
>=20
> First, I don't think I can readily change this without going against
> the consensus the document has already gathered.  (I.e., this is not
> about the intro, framing, context, etc. bits, but the actual meat of
> the technical stuff.)
>=20
> Second, you are right that the IETF does not have a monopoly, but
> that doesn't make the statement in the document the wrong thing to
> say.
>=20
> Third, I doubt I should change it.  The problem here from the
> standpoint of a set of default guidelines is that we'd like a
> mechanism to determine the cause of loss to **actually work** before
> it's OK to avoid a congestion control response.  If a standardized
> mechanism is used then we have some confidence that the mechanism
> has been vetted as reasonable.  If the mechanism is not standardized
> then we have no idea if it actually works or if it is some
> ill-conceived scheme that is badly broken.  In this latter case, I
> don't think we want to bless this approach as OK within the default.
> It may be OK, but it should get some consensus that it is OK.
>=20
> allman


From nobody Thu Jun 18 07:27:14 2020
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 A4C4B3A113A for ; Thu, 18 Jun 2020 07:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=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 g_1jrgXpBFFf for ; Thu, 18 Jun 2020 07:27:11 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 2DC7B3A1133 for ; Thu, 18 Jun 2020 07:27:04 -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:Cc:Date:In-Reply-To: From:Content-Type:Mime-Version:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WQ38oDvfh7Zj7mCVnG9L4BaaYOLJZGUu7jJuQYdvu44=; b=ZzS5shxMtplA/PhfLW8FfSut5 IR11bwUFVl8sbwFpn+mYazXb1tgLnVnVoNKwOghIqoM0Pc5Wmi1sa4aVr5721b0fK688e5d8cQtCQ qL/CJX+rl2HUqDNLDT1EMxvW35/YRNYXrpbi2EztVTwSFoYqj+9W1c0lnX198qw8059ubVnoxUgam /yiD1vAfj830xbEo+qyQc0HgbwwSDHmv9cUW4hpZzEeMpLUa3/OapmTwxUrhEJUiTzTAJPHGGfKCJ IemEvCWe4SBg1XIvjGsVbI/iPdqF4S3coj+yGqCstZnJkkIENbS1KIqCX3jpkEw1SLlD6TDnicDuF /iSUuoGSQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:58798 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jlvVG-001bPp-Sh; Thu, 18 Jun 2020 10:26:59 -0400
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_20A4AB57-EFC0-4FD6-93CC-480B5F8F8877"
From: Joseph Touch 
X-Priority: 3 (Normal)
In-Reply-To: 
Date: Thu, 18 Jun 2020 07:26:53 -0700
Cc: Praveen Balasubramanian , Neal Cardwell , Matt Mathis , "tcpm@ietf.org" , Jon Crowcroft , Michael Tuexen 
Message-Id: 
References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at>  <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu>   <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu>  <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de>    <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> <4B1DC848-32F1-4BAF-9835-CC931C1F938C@strayalpha.com> 
To: Carles Gomez Montenegro 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP
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, 18 Jun 2020 14:27:13 -0000

--Apple-Mail=_20A4AB57-EFC0-4FD6-93CC-480B5F8F8877
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Carles,

> On Jun 18, 2020, at 1:29 AM, Carles Gomez Montenegro =
 wrote:
>=20
>> Why not start as defining an Experimental Option (with a =
corresponding
>> code point)?
>>=20
>> Joe
>=20
> Thanks for your suggestion.
>=20
> (I understand that you mean an Experimental-category specification
> defining a TCP Option using a dedicated kind number different from 253 =
or
> 254.)


That=E2=80=99s definitely NOT what I meant.

Please review RFC 6994. There should NEVER be a need to assign new TCP =
Option kind codepoints to experiments.

To be explicit, I mean to follow 6994 and request an Experimental code =
point that can be used together with TCP Option kinds of 253 and/or 254.

Joe


--Apple-Mail=_20A4AB57-EFC0-4FD6-93CC-480B5F8F8877
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Carles,

On Jun 18, 2020, at 1:29 AM, =
Carles Gomez Montenegro <carlesgo@entel.upc.edu> wrote:

Why =
not start as defining an Experimental Option (with a corresponding
code point)?

Joe

Thanks for your suggestion.

(I understand that you mean an Experimental-category =
specification
defining a =
TCP Option using a dedicated kind number different from 253 or
254.)

That=E2=80=99s definitely NOT what I =
meant.

Please review RFC 6994. There =
should NEVER be a need to assign new TCP Option kind codepoints to =
experiments.

To be explicit, I mean =
to follow 6994 and request an Experimental code point that can be used =
together with TCP Option kinds of 253 and/or 254.

Joe

=

--Apple-Mail=_20A4AB57-EFC0-4FD6-93CC-480B5F8F8877--


From nobody Thu Jun 18 09:08:02 2020
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 054313A0A09; Thu, 18 Jun 2020 09:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=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
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 ECS-iGyoThX3; Thu, 18 Jun 2020 09:07:59 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 3DC4A3A0A06; Thu, 18 Jun 2020 09:07:58 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 05IG7pmO045096; Thu, 18 Jun 2020 18:07:52 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id CFF621D53C1; Thu, 18 Jun 2020 18:07:50 +0200 (CEST)
Received: from 79.152.3.25 by webmail.entel.upc.edu with HTTP; Thu, 18 Jun 2020 18:07:51 +0200
Message-ID: <4b180b7da139de4c31c7ace9a380af8d.squirrel@webmail.entel.upc.edu>
In-Reply-To: 
References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at>  <7d145f1203f6344b92f6f8aa11a78239.squirrel@webmail.entel.upc.edu>   <909de4172e46712f543f723d0ae2d638.squirrel@webmail.entel.upc.edu>  <9B5D12AC-248F-4E61-B6C5-1DA9529C7A42@lurchi.franken.de>    <92538abd26cf9394cfc3e4b8f08a1f7e.squirrel@webmail.entel.upc.edu> <4B1DC848-32F1-4BAF-9835-CC931C1F938C@strayalpha.com>  
Date: Thu, 18 Jun 2020 18:07:51 +0200
From: "Carles Gomez Montenegro" 
To: "Joseph Touch" 
Cc: "Praveen Balasubramanian" , "Neal Cardwell" , "Matt Mathis" , "tcpm@ietf.org" , "Jon Crowcroft" , "Michael Tuexen" 
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 07:38:54 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Thu, 18 Jun 2020 18:07:55 +0200 (CEST)
Archived-At: 
Subject: Re: [tcpm] [EXTERNAL] Re: On Sender Control of Delayed Acks in TCP
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, 18 Jun 2020 16:08:01 -0000

Hi Joe,

> Carles,
>
>> On Jun 18, 2020, at 1:29 AM, Carles Gomez Montenegro
>>  wrote:
>>
>>> Why not start as defining an Experimental Option (with a corresponding
>>> code point)?
>>>
>>> Joe
>>
>> Thanks for your suggestion.
>>
>> (I understand that you mean an Experimental-category specification
>> defining a TCP Option using a dedicated kind number different from 253
>> or
>> 254.)
>
>
> That's definitely NOT what I meant.
>
> Please review RFC 6994. There should NEVER be a need to assign new TCP
> Option kind codepoints to experiments.
>
> To be explicit, I mean to follow 6994 and request an Experimental code
> point that can be used together with TCP Option kinds of 253 and/or 254.

Oops, I see!

(I see that it was right to include what I understood above...)

Thank you very much for the clarification.

Cheers,

Carles


> Joe
>
>



From nobody Thu Jun 18 10:43:25 2020
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 A14E53A0D86 for ; Thu, 18 Jun 2020 10:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 V_9Ymnp1EM4H for ; Thu, 18 Jun 2020 10:43:23 -0700 (PDT)
Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) (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 6235F3A0D7C for ; Thu, 18 Jun 2020 10:43:23 -0700 (PDT)
Received: by mail-oo1-f54.google.com with SMTP id 18so1347688ooy.3 for ; Thu, 18 Jun 2020 10:43:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=6q9+8/2rypfLr0jTUOLO/H0/+/xrmmbQfdm9XxtUiek=; b=dXZ+BdTxkVw+AODx4w0+UqxSAstXaaqZJC9Vc/28PD4+aJCt3JHrc5ivz9Z/O3vrrN FeqW8kJ7N+/qbZ28rcZReOSqoyeiiQJHgq1E+EHt+aeCDuQ6iQe+lRptOHQhTfu41Q5K iBF74YvmDvtuD83DodkSdFYK+QKXU0CZer0/j6G73R1qSw/32BcBSsKB+HJ1IkeyF2rl Xino8p//REve4xzBF2hNR2T3yUHktYj18cXHTbD2G3q+9PuV5sTCspGeB+HCOt3R6JRU FbhZ6krhPKzdkf36IXrqup9TMpQoMn1wNZTHxyRh5GMItpsmydVAeP9tELmRp2jSLgSZ W40A==
X-Gm-Message-State: AOAM5316lqZcAe5+UsdEPtJBz/G+OiqV19FGxMkegefWiyjDTKiK6SIC zwnacPQ6IVTESW4xkZE9ipKSDQ==
X-Google-Smtp-Source: ABdhPJx3hG1AEl279cgu3gmXriQd9/OaYMzx45JYqAZZjAPBDotwT/JXABvSh9OZpkBOuBHtANg+oA==
X-Received: by 2002:a4a:8908:: with SMTP id f8mr5201934ooi.7.1592502202505; Thu, 18 Jun 2020 10:43:22 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:7c97:4043:1622:ee65]) by smtp.gmail.com with ESMTPSA id f11sm773397oib.43.2020.06.18.10.43.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 10:43:21 -0700 (PDT)
From: "Mark Allman" 
To: "Stewart Bryant" 
Cc: "Martin Duke" , "Review Team" ,  tcpm , "Last Call" , draft-ietf-tcpm-rto-consider.all@ietf.org, "tom petch" 
Date: Thu, 18 Jun 2020 13:43:17 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <0C26BF3F-6056-4274-8555-A3C8689F9108@icir.org>
In-Reply-To: 
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>     
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_595025AE-8DC0-4FA3-A9F7-928BA50953D4_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 18 Jun 2020 17:43:25 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_595025AE-8DC0-4FA3-A9F7-928BA50953D4_=
Content-Type: text/plain


> We make as much progress as we can agree on which will clear some
> of the issue below.
> For any remaining issues for which you have wider consensus but
> where we cannot agree, I modify my review and the IESG decides how
> they wish to proceed.
> I am prepared to be in the rough but I have a duty to draw
> attention to concerns.

yep - sounds good.  i am going to try to flesh out the intro
paragraph a little more with some of the stuff from section 2.  but,
outside that i am not sure what to do.  i'll get a new version sent
out in a day or a few.

thanks,
allman

--=_MailMate_595025AE-8DC0-4FA3-A9F7-928BA50953D4_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuuntREcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizlOhAJ9glQBOJP4X2v2xHKAg+htqxM70WQCfZNAx
u6fvEo6GZHR5OsYI2ojFSpQ=
=5aYO
-----END PGP SIGNATURE-----

--=_MailMate_595025AE-8DC0-4FA3-A9F7-928BA50953D4_=--


From nobody Fri Jun 19 07:35:46 2020
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 6ACFF3A0A4A; Fri, 19 Jun 2020 07:35:40 -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.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: tcpm@ietf.org
Message-ID: <159257734039.31013.5095228081280714424@ietfa.amsl.com>
Date: Fri, 19 Jun 2020 07:35:40 -0700
Archived-At: 
Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-16.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: Fri, 19 Jun 2020 14:35:41 -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           : Requirements for Time-Based Loss Detection
        Author          : Mark Allman
	Filename        : draft-ietf-tcpm-rto-consider-16.txt
	Pages           : 12
	Date            : 2020-06-19

Abstract:
    Many protocols must detect packet loss for various reasons (e.g., to
    ensure reliability using retransmissions or to understand the level
    of congestion along a network path).  While many mechanisms have
    been designed to detect loss, protocols ultimately can only count on
    the passage of time without delivery confirmation to declare a
    packet "lost".  Each implementation of a time-based loss detection
    mechanism represents a balance between correctness and timeliness
    and therefore no implementation suits all situations.  This document
    provides high-level requirements for time-based loss detectors
    appropriate for general use in the Internet.  Within the
    requirements, implementations have latitude to define particulars
    that best address each situation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-16
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-16

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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



From nobody Fri Jun 19 08:03:03 2020
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 3629B3A0AAD for ; Fri, 19 Jun 2020 08:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level: 
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 PgIbwVC91jRk for ; Fri, 19 Jun 2020 08:02:55 -0700 (PDT)
Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (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 4604E3A0AC8 for ; Fri, 19 Jun 2020 08:02:55 -0700 (PDT)
Received: by mail-qk1-f179.google.com with SMTP id l6so5558894qkc.6 for ; Fri, 19 Jun 2020 08:02:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=HvAQIra3/V0puHkJENGRZ5KxL3XayGwoA3uWafCkHhY=; b=qHmj5GpMNCXFsObxhXVxMT1Qiu/U+KwN4pAv7EQkB/IPm+H2JakaP+UfHg0HVDp4gd sM8g2rLXAgTzpr7avrjwg1a/OSrEUMddgY+OmFnxG7Jc7qK8iNZ7B8Qtm/6wG/c+Gq6F OgRz8v4+U5NUSPLi7P513g0NzWw5mYELbZoK44IeYS/v/sS4Ouf32Gv4xFmuo44HdKNd zkzGxpIxJRdhW1Z7o0vV8z3YsNDo7KdoXqfA8rfyaoNWX9rTXRNaYE2SqWcqrSMQU6vG 90+c/nBEBYF4JJmMC3H/uv4Hhx3de6RxSc8L0lJeX5tWg3nm+AxbGmw95KzxmlAb5E6s PHtQ==
X-Gm-Message-State: AOAM532sVM/vyJfpPgjTcBgrqnzWiv/VHWsrUTqjcOMB0xpn8vbiahrw 37HytOHwxi4X0BgJ9RGfPRunFw==
X-Google-Smtp-Source: ABdhPJx0moR3ApoRq900XHsdK5oxaTUkbc0QyRJMBpZ9BEWx5N1JDpop/5fllOup/syBlqTWlGUvgg==
X-Received: by 2002:a37:7cc7:: with SMTP id x190mr4072967qkc.189.1592578974205;  Fri, 19 Jun 2020 08:02:54 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:d901:6b54:439d:ae8d]) by smtp.gmail.com with ESMTPSA id g64sm6481194qtd.39.2020.06.19.08.02.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 08:02:51 -0700 (PDT)
From: "Mark Allman" 
To: "Stewart Bryant" 
Cc: "Gorry Fairhurst" , "Martin Duke" , tcpm , "Review Team" , "Last Call" , draft-ietf-tcpm-rto-consider.all@ietf.org
Date: Fri, 19 Jun 2020 11:02:49 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <3C4FA33A-DD97-4DA4-898E-8C6A6E38BA88@icir.org>
In-Reply-To: <8C4B7C4D-7658-4219-856B-95D99473770B@gmail.com>
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>    <522d1439-a24f-490a-6a5b-6544e024c969@erg.abdn.ac.uk> <8C4B7C4D-7658-4219-856B-95D99473770B@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_1F1C435D-BBC3-4FAF-BA46-A029903C9C23_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 19 Jun 2020 15:02:58 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_1F1C435D-BBC3-4FAF-BA46-A029903C9C23_=
Content-Type: text/plain


I just posted a new version of rto-consider (-16).  The document,
diffs, etc. can be found here:

  https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

I fixed a few nits that had been pointed out throughout the
document.

The main work in this rev is in the first two paragraphs of the
intro.  I honed these based on the discussion with Stewart and
Gorry.  Well, "honed" might ultimately look like "rewrote" even if
that wasn't the process or exactly my intention. :) I tried to pull
some of the notions from later in the document up here to the front
of the document, as requested.  In particular, I brought forward the
notion of this document as a default and not as a one-size-fits-all.
I hope this addresses the concerns to a large extent.

I also want to make a meta point here, which is clearly about this
document, but also I think much more widely applicable.  I continue
to believe that the Internet has grown to what it is in no small
part because at many crucial points we chose generality over
optimality.  I do not believe we should shun generality---either in
terms of protocol development or the lessons we have learned.  That
doesn't mean we cannot acknowledge places where more pointed
solutions may be appropriate.  It doesn't mean we can't accommodate
different and non-general approaches in things like guidelines and
requirements.  But, I think it'd be a pity if we couldn't write
general documents because there are cases where they will be
suboptimal or not applicable.  There are always such cases.  And, if
that is the gate, we're going to design a network we won't much care
for, I think.  IMHO.  FWIW.

allman

--=_MailMate_1F1C435D-BBC3-4FAF-BA46-A029903C9C23_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXuzTmREcbWFsbG1hbkBp
Y2lyLm9yZwAKCRBbKutazjIizsVzAJ4oWH+l0GBu4Dajjj5It9VExl5JbQCeKz6N
+Ic0OMhkC0Ltg4DsL1UbSNc=
=+1fx
-----END PGP SIGNATURE-----

--=_MailMate_1F1C435D-BBC3-4FAF-BA46-A029903C9C23_=--


From nobody Fri Jun 19 08:59:58 2020
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 09EF53A00D6; Fri, 19 Jun 2020 08:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TZNMkSI7TwN; Fri, 19 Jun 2020 08:59:46 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 986F63A00D3; Fri, 19 Jun 2020 08:59:44 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CA3011B00223; Fri, 19 Jun 2020 16:59:34 +0100 (BST)
To: Mark Allman , Stewart Bryant 
Cc: Martin Duke , tcpm , Review Team , Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>    <522d1439-a24f-490a-6a5b-6544e024c969@erg.abdn.ac.uk> <8C4B7C4D-7658-4219-856B-95D99473770B@gmail.com> <3C4FA33A-DD97-4DA4-898E-8C6A6E38BA88@icir.org>
From: Gorry Fairhurst 
Message-ID: 
Date: Fri, 19 Jun 2020 16:59:34 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <3C4FA33A-DD97-4DA4-898E-8C6A6E38BA88@icir.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 19 Jun 2020 15:59:48 -0000

One minor nit on the new text, the term "controlled environment" is used 
elsewhere in the RFC series in transport-related documents to describe 
what you name "constrained environment".

Gorry

On 19/06/2020 16:02, Mark Allman wrote:
> I just posted a new version of rto-consider (-16).  The document,
> diffs, etc. can be found here:
>
>    https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/
>
> I fixed a few nits that had been pointed out throughout the
> document.
>
> The main work in this rev is in the first two paragraphs of the
> intro.  I honed these based on the discussion with Stewart and
> Gorry.  Well, "honed" might ultimately look like "rewrote" even if
> that wasn't the process or exactly my intention. :) I tried to pull
> some of the notions from later in the document up here to the front
> of the document, as requested.  In particular, I brought forward the
> notion of this document as a default and not as a one-size-fits-all.
> I hope this addresses the concerns to a large extent.
>
> I also want to make a meta point here, which is clearly about this
> document, but also I think much more widely applicable.  I continue
> to believe that the Internet has grown to what it is in no small
> part because at many crucial points we chose generality over
> optimality.  I do not believe we should shun generality---either in
> terms of protocol development or the lessons we have learned.  That
> doesn't mean we cannot acknowledge places where more pointed
> solutions may be appropriate.  It doesn't mean we can't accommodate
> different and non-general approaches in things like guidelines and
> requirements.  But, I think it'd be a pity if we couldn't write
> general documents because there are cases where they will be
> suboptimal or not applicable.  There are always such cases.  And, if
> that is the gate, we're going to design a network we won't much care
> for, I think.  IMHO.  FWIW.
>
> allman


From nobody Fri Jun 19 11:32:03 2020
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 A997C3A0CD8; Fri, 19 Jun 2020 11:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0pnFb7_wzFVq; Fri, 19 Jun 2020 11:32:00 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60041.outbound.protection.outlook.com [40.107.6.41]) (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 0609A3A0CB5; Fri, 19 Jun 2020 11:31:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZzoaPUy93gpVlGpOPn1YDEEBuTzik6YrnieXr2Ro+BjP5DGLhj6JacvNnysHi0L1QKN/mKjniuL29b0NKTAgMaG3sAn4noG9L8KoAI2DplOG7ldo0bzo1B8WsgI78r7X4bkMye/M5qzDhJ0Cvqd7tDTmacuwjPxWXAvys+HIWgJtXJtRUn7vPATO7XALFGZCmTBum/T9n1RrFLU29eqHVux+lllN2CeZtDTlmiHyVCqv/L51WJuZYZowxVW+UIOAIHKFJlJeT/p75ioad62E4ev9lCilPIrIIQfU/BKkJuW50cB/GUMCr8GdrLUI2mW4PLgXJEbPY0ThwzEl/F9cnw==
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=jI35CdfxQ9emezHwi/Y3wLXPjlL4TAw8skUJYGgOgB4=; b=fzxkXRB76kNBuIx3/CE8pxlqsmMP3OuvasGjY5As7x6V4ql5jIo/GizGDnpqPCKFChU1QIZDI+5vRjTRW7YYYQbUjWrlQBniRQT5oGCzwzUE3UNui+2pe1VrnIxdgmKCa4kzHuo86jkpuL5WAO9Zl+byPsZJXuHWu2bbL6F1IxkSxpTdE1cdzs4vlVdL3fSsZx41xKwQ0FYyVpmOU/S/FbzQ9wE7E3N8vKgn1DBExDKyMmNaCaYu2kwUSBzXZ6efrGhDy/iESTwp2xNj94XKotYM0/3iYsVdVnKTacAFbvj+m0ZfBvlM2JAtt4Hbd5Yy+KlXsvCeukl7ZdJP2Z/sCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jI35CdfxQ9emezHwi/Y3wLXPjlL4TAw8skUJYGgOgB4=; b=F0X5Zj5YPsDPzFzrnagr+pYa5adfR4DJf7CHX81zkBoTktPGd59bCXwiDDaZQZiOzE/TCNldj51yoYk0Qh4rZ+maLH+K/0zCy4NJp/Pqqd2OkFPMPNoISB4S3aIHuY5fFpwO21mbeykalWI4MpCAqdGVCFbTeM5glzFZjshYxS4=
Received: from VI1PR0702MB3552.eurprd07.prod.outlook.com (2603:10a6:803:12::32) by VI1PR07MB3263.eurprd07.prod.outlook.com (2603:10a6:802:21::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.18; Fri, 19 Jun 2020 18:31:57 +0000
Received: from VI1PR0702MB3552.eurprd07.prod.outlook.com ([fe80::8552:bb78:c172:951f]) by VI1PR0702MB3552.eurprd07.prod.outlook.com ([fe80::8552:bb78:c172:951f%6]) with mapi id 15.20.3109.018; Fri, 19 Jun 2020 18:31:57 +0000
From: Mirja Kuehlewind 
To: "Scharf, Michael" , "tcpm@ietf.org" 
CC: tcpm-chairs 
Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-2140bis
Thread-Index: AQHWRmfqKbJ4UHStAUergHNr/f0rSQ==
Date: Fri, 19 Jun 2020 18:31:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none;hs-esslingen.de; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [2003:de:e700:7a00:f586:bff0:254f:cdf6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4450e333-78f9-4631-9896-08d8147f0ca4
x-ms-traffictypediagnostic: VI1PR07MB3263:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0439571D1D
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LMDVDu0TdVoGi8lSXhVVea7MY1m7TKQTXrQLpzMCZdfmBSrY2WLj0M4y0bncWfFq+Dzr2D4/AqcV/n8d6AQ2wvnQ4B9zGgnCJ/6bGfytnoUAN7dPEZCr0m7uhogrt+KLVKpJlwgWZnt2xIgt++LFXpVcdJd+MANNfGRgyGAeJvUuJNr3NEgyOhb5i/ViG4qg9BiUvCldoOdf8oGZygeChkVZ7Mr7QdVPfIA1DDUvX9TgpH6kaz5iTX/Acad2qxY1yuTKrloEEmweTJfNOVqRzHl++y8oIYu4zIOOGH2QLgBhVnBefW6Gfv9bUGph4dBSwvonntFUrOk6ZyqUMCvLFp7SqH/YPRieCod8KAqj1pON+RGX4yPHUUXaMMpoFwaxutBw/FitpzF8dhwGy5P8LA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:VI1PR0702MB3552.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(136003)(376002)(39860400002)(396003)(346002)(186003)(86362001)(478600001)(76116006)(53546011)(66946007)(6506007)(33656002)(2906002)(8676002)(966005)(83380400001)(91956017)(2616005)(36756003)(6512007)(6486002)(44832011)(66446008)(66556008)(66476007)(71200400001)(110136005)(316002)(4326008)(8936002)(64756008)(5660300002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: 4OeovTx+/k6MAk6utF3/QK9V1b44xukCAHqkJVNaW7Rss/9/FXhFBGECmzm1uEcz1mWs0F3T5V90TAdw5hKxzq5r7dRV3mAR2TebvaP8V2MkIoOZDN0ZkDn6org905ngOG6a3YD2GiG3CO+7TAcPZBV9ou3XkC8eleuGF3u155Sgdx6sAOVEECY0GhhZocMOiXNdBAb4ZI9I94zNR61p5hVdAfaswpzjYJ0LZmv8mi7QvwEtsvseFViG8yVDldM8NpbBKkRYQidPRDO8nhlpm8VNPRkdYmqsjBuKLNdi/imINAVTElxWDKM54Hpi/RPrNMe+U03E+0Yu4Hmy35Gs/cFYVUscVruNW37ISzlLO9H+vgn+FJ9Q5DxLb0CitHSgchRqIhhRdYyBCjj4au5AkaaXd0vZItdMOhlUY+N/q7VGFu9mA/5FXs9T8de/q6kENyURm3h00+VH9ATPKbxGOFdMTjdL1r20Z4xqAj0NN8s3MhaLoBLsR50soEDm53ewWZOV7Sn0P1D4ASz3miqkLDtWeHTzENc968hhVfgjgTw=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4EAD3B4F93222F4AA846B6D318CE7918@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4450e333-78f9-4631-9896-08d8147f0ca4
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 18:31:57.7637 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UtyXVKs4XBQiqVUmNtQWA/zry/vpT/t2dagJdpfMEFyJO87y5ZslhZGA8qfkZa/sqW0ymYIJgpBq7Xpp/6TMbqQ2lnFmYtt60cQkpwKYdQU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3263
Archived-At: 
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 19 Jun 2020 18:32:02 -0000

SGkgTWljaGFlbCwgaGkgYWxsLA0KDQpzb3JyeSBmb3IgYmVpbmcgbGF0ZSBoZXJlIGJ1dCB0aW1l
cyBhcmUgYnVzeS4uLiBzbyB0aGFua3MgZm9yIHRoZSBleHRlbnNpb24uDQoNClRoYW5rcyB0byB0
aGUgYXV0aG9ycyBmb3IgYWxsIHRoZSB3b3JrIG9uIHRoaXMgYmlzIGRvYy4gSSBvbmx5IG1hbmFn
ZWQgdG8gaGF2ZSBhIGJyaWVmIHJldmlldyBvZiB0aGUgZHJhZnQgYnV0IEkgdGhpbmsgaXQgYW4g
aW50ZXJlc3RpbmcgcmVhZCB3aXRoIGEgbG90IG9mIGdvb2QgdXBkYXRlcy4gSSB0aGluayB0aGUg
ZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgaG93ZXZlciwgSSBo
YXZlIHR3byBjb21tZW50cy9xdWVzdGlvbnMuIHRUaGUgZmlyc3Qgb25lIGlzIG1vcmUgYSBzdWdn
ZXN0aW9uIGJ1dCB0aGUgc2Vjb25kIHBvaW50IGlzIHNvbWV0aGluZyBJIHRoaW5rIHdlIHNob3Vs
ZCBiZSBzaG91bGQgd2UgaGF2ZSBzdXBwb3J0IGZvciBpbiB0aGUgZ3JvdXAgYmVmb3JlIHdlIG1v
dmUgYWhlYWQuDQoNCjEpIFRoZSBzZWN1cml0eSBzZWN0aW9uIGNvdWxkIG1heWJlIGFsc28gZGlz
Y3VzcyBpZiB0aGVyZSBhcmUgYW55IGltcGxpY2F0aW9ucyBmb3IgbGlrYWJpbGl0eSB3aGVuIGNh
Y2hpbmcgYW55IG9mIHRoZXNlIGluZm9ybWF0aW9uIGFuZCBob3cgdG8gaGFuZGxlIHRoYXQuIExv
b2tpbmcgYXQgdGhlIGRpZmYsIHRoZXJlIHdhcyBhIHNlY3Rpb24gaW4gdGhlIHNlY3VyaXR5IGNv
bnNpZGVyYXRpb24gYWJvdXQgaW5mb3JtYXRpb24gc2hhcmluZyBvZiBhcHBsaWNhdGlvbi1zcGVj
aWZpYyBzZXR0aW5ncy4gU28gd2h5IHdhcyB0aGF0IHJlbW92ZWQ/IEhvd2V2ZXIsIEkgdGhpbmsg
dGhlIGRvY3VtZW50IGNvdWxkIGV2ZW4gc2F5IG1vcmUhDQoNCjIpIEkgd2FzIHF1aXRlIHN1cnBy
aXNlZCB0byBzZWUgYXBwZW5kaXggQyBhbmQgdGhhdCBpdCBpcyBhIEZVTEwgY29weSBvZiBkcmFm
dC10b3VjaC10Y3BtLWF1dG9tYXRpYy1pdy0wMy4gSSdtIG9rYXkgdG8gZGlzY3VzcyBtb3JlIGNv
bnNpZGVyYXRpb25zIG9uIHRoZSBJVyBlLmcuIG9uIHRoZSBkZXNpZ24gcHJpbmNpcGxlIGxldmVs
IGFuZCBtb3N0IGltcG9ydGFudGx5IG1heWJlIHRoYXQgYSBsb3NzIHdpdGhpbiB0aGUgSVcgY2Fu
L3Nob3VsZCBpbXBhY3RpbmcgdGhlIGNhY2hlZCB2YWx1ZSwgYW5kIHRvIGRvIHNvIGV2ZW4gaW4g
dGhlIGJvZHkgb2YgdGhlIGRvYywgaG93ZXZlciwgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkgdGhl
cmUgd2FzIGEgbG90IG9mIGRpc2N1c3Npb24gYWJvdXQgdGhlIGF1dG9tYXRlZCBzZXR0aW5nIG9m
IElXIGluIHRjcG0gd2hlbiB0aGUgSVcxMCBSRkMgd2FzIHVuZGVyIGRpc2N1c3Npb24gYW5kIG5v
IGFncmVlbWVudCByZWFjaGVkIGluIHRoZSBncm91cCwgc28gd291bGQgcmF0aGVyIGp1c3QgbGlr
ZSB0byBzZWUgYSByZWZlcmVuY2UgdG8gdGhlIGV4cGlyZWQgZHJhZnQgdGhhbiBjb3B5IGFuZCBw
YXN0aW5nIHRoZSB3aG9sZSBhbGdvcml0aG0gaW4gdGhlIGFwcGVuZGl4IG9mIHRoaXMgZHJhZnQu
DQoNCk1pcmphDQogDQpQLlMuOiBJIHdpbGwgYmUgb24gaG9saWRheXMgdGhlIG5leHQgdHdvIHdl
ZWtzIGFuZCB0aGVyZWZvcmUgcHJvYmFibHkgbm90IHJlcGx5IGJlZm9yZSBJJ20gYmFjay4NCg0K
DQrvu79PbiAxMi4wNi4yMCwgMTE6NTcsICJ0Y3BtIG9uIGJlaGFsZiBvZiBTY2hhcmYsIE1pY2hh
ZWwiIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIE1pY2hhZWwuU2NoYXJmQGhz
LWVzc2xpbmdlbi5kZT4gd3JvdGU6DQoNCiAgICBIaSBhbGwsDQoNCiAgICBJIGhhdmVuJ3Qgc2Vl
biBhbnkgcmVwbHkgc28gZmFyLiBMYWNrIG9mIF9hbnlfIGZlZWRiYWNrIGlzIG5vdCBhIHBhcnRp
Y3VsYXJseSBnb29kIHNpZ24uDQoNCiAgICBBbnl3YXksIG5vIGZlZWRiYWNrIGltcGxpZXMgdGhh
dCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLiBIb3dldmVyLCBldmVuIGlu
IHRoYXQgY2FzZSBleHBsaWNpdCBzdXBwb3J0IGZvciBwdWJsaWNhdGlvbiAgd291bGQgYmUgX3Jl
YWxseV8gdXNlZnVsLiBBIHNpbXBsZSAiKzEiIGNvdWxkIGJlIGVub3VnaC4uLg0KDQogICAgSSds
bCBleHRlbmQgdGhlIFdHTEMgYnkgb25lIHdlZWsgdW50aWwgSnVuZSAyMSB0byBnaXZlIHRoZSBj
b21tdW5pdHkgc29tZSBhZGRpdGlvbmFsIHRpbWUgdG8gY29tbWVudC4NCg0KICAgIFRoYW5rcw0K
DQogICAgTWljaGFlbA0KDQoNCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAg
PiBGcm9tOiBTY2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT4N
CiAgICA+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMzAsIDIwMjAgODowNiBQTQ0KICAgID4gVG86IHRj
cG1AaWV0Zi5vcmcNCiAgICA+IENjOiB0Y3BtLWNoYWlycyA8dGNwbS1jaGFpcnNAaWV0Zi5vcmc+
DQogICAgPiBTdWJqZWN0OiBXR0xDIGZvciBkcmFmdC1pZXRmLXRjcG0tMjE0MGJpcw0KICAgID4g
DQogICAgPiBIaSBhbGwsDQogICAgPiANCiAgICA+IFRoZSBkb2N1bWVudCAiVENQIENvbnRyb2wg
QmxvY2sgSW50ZXJkZXBlbmRlbmNlIiAoZHJhZnQtaWV0Zi10Y3BtLQ0KICAgID4gMjE0MGJpcykg
aXMgb3V0IHRoZXJlIGZvciBhIHF1aXRlIHNvbWUgdGltZSBhbHJlYWR5LiBHaXZlbiB0aGF0IHRo
ZXJlIGhhcw0KICAgID4gYmVlbiBhIGJpdCBsZXNzIGFjdGl2aXR5IG9uIHRoZSBsaXN0IGFmdGVy
IHRoZSBpbnRlcmltLCBsZXQncyB1c2UgdGhpcyBvcHBvcnR1bml0eQ0KICAgID4gdG8gZmluaXNo
IG9uZSBvZiBvdXIgbWlsZXN0b25lcy4uLg0KICAgID4gDQogICAgPiBUaGlzIGUtbWFpbCBzdGFy
dHMgYSBXR0xHIGZvciB0aGUgZG9jdW1lbnQgZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMuIFRoZQ0K
ICAgID4gV0dMQyB3aWxsIHJ1biB1bnRpbCAqKipKdW5lIDE0KioqLg0KICAgID4gDQogICAgPiBU
aGUgaW50ZW5kZWQgc3RhdHVzIGlzIGFuIGluZm9ybWF0aW9uYWwgUkZDLiBUaGUgY3VycmVudCB2
ZXJzaW9uIG9mIHRoZQ0KICAgID4gZG9jdW1lbnQgY2FuIGJlIGZvdW5kIGF0Og0KICAgID4gDQog
ICAgPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMt
MDUNCiAgICA+IA0KICAgID4gUGxlYXNlIHJldmlldyB0aGUgbGF0ZXN0IHZlcnNpb24gYW5kIHBs
ZWFzZSBsZXQgdXMga25vdyBhbnkgY29tbWVudHMgb3INCiAgICA+IHN1Z2dlc3Rpb25zLiBUQ1BN
IG5lZWRzIHJldmlld3MgdG8gZW5zdXJlIHRoYXQgdGhlIGNvbnRlbnQgaXMgcmVhZHkgdG8NCiAg
ICA+IG1vdmUgZm9yd2FyZC4gRmVlZGJhY2sgc3VwcG9ydGluZyBwdWJsaWNhdGlvbiAoIisxIikg
aXMgYWxzbyB2ZXJ5IHdlbGNvbWUuDQogICAgPiANCiAgICA+IFRoYW5rcw0KICAgID4gDQogICAg
PiBNaWNoYWVsLCBvbiBiZWhhbGYgb2YgdGhlIFRDUE0gY2hhaXJzDQoNCiAgICBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHRjcG0gbWFpbGluZyBs
aXN0DQogICAgdGNwbUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGNwbQ0KDQo=


From nobody Fri Jun 19 11:40:36 2020
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 F34E93A0D7C; Fri, 19 Jun 2020 11:40:22 -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, 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 Cqm5Mq5-Jadc; Fri, 19 Jun 2020 11:40:21 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3EF193A0D41; Fri, 19 Jun 2020 11:40:21 -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=58lj725iKwg4nLxZVIleC/sor3aZUdrhGZNVF1BeAJg=; b=Ox/Wjh68u0997nF7bAhNaJBPa t+l/A/quWwa/6WIfuea9ZQy4ZHN2fKHcQWmc+25k6beuFUfGhuXNnkhS9jkr0SpfFPSV8DDPr28L6 CZaQL5SYqnxu/Hsb8iMecp9AKwt7fxMWxaP4nDnHQqEtysD4XB3rqQQ81RO27Kf3Bvc3oskh0LCeB J2ZGyHWQqtBYfdt8pxDF6fMfwly4wwTfU5CE/932gmfR25EzY3CpJslh3iF1j65rlPIfYCJhwl1p2 XlrWalqbwOUvwQ03EkSjXyx0K6JovXX6tGKdtj7duVbUlowbUtP7TxPQUlHhEnouNeE0YPT1GvUgt Urx2GFJ+g==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57357 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jmLw0-002Ams-6p; Fri, 19 Jun 2020 14:40:20 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 19 Jun 2020 11:40:15 -0700
Cc: "Scharf, Michael" , "tcpm@ietf.org" , tcpm-chairs 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7840A9F4-48C7-4C41-8464-DB92A086F7A5@strayalpha.com>
References: 
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] WGLC for draft-ietf-tcpm-2140bis
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, 19 Jun 2020 18:40:34 -0000

Hi, Mirja,

> On Jun 19, 2020, at 11:31 AM, Mirja Kuehlewind =
 wrote:
>=20
> Hi Michael, hi all,
>=20
> sorry for being late here but times are busy... so thanks for the =
extension.
>=20
> Thanks to the authors for all the work on this bis doc. I only managed =
to have a brief review of the draft but I think it an interesting read =
with a lot of good updates. I think the document is basically ready for =
publication, however, I have two comments/questions. tThe first one is =
more a suggestion but the second point is something I think we should be =
should we have support for in the group before we move ahead.
>=20
> 1) The security section could maybe also discuss if there are any =
implications for likability when caching any of these information and =
how to handle that. Looking at the diff, there was a section in the =
security consideration about information sharing of application-specific =
settings. So why was that removed? However, I think the document could =
even say more!
>=20
> 2) I was quite surprised to see appendix C and that it is a FULL copy =
of draft-touch-tcpm-automatic-iw-03. I'm okay to discuss more =
considerations on the IW e.g. on the design principle level and most =
importantly maybe that a loss within the IW can/should impacting the =
cached value, and to do so even in the body of the doc, however, if I =
remember correctly there was a lot of discussion about the automated =
setting of IW in tcpm when the IW10 RFC was under discussion and no =
agreement reached in the group, so would rather just like to see a =
reference to the expired draft than copy and pasting the whole algorithm =
in the appendix of this draft.

The discussion was only whether there were specific settings that had =
been implemented. If we cite an expired draft, we need to basically add =
some info to explain what=E2=80=99s in the other doc (which we are =
supposed to treat as non-existent). I.e., if we=E2=80=99re citing an old =
draft for credit, it=E2=80=99s just a citation, but in this case we=E2=80=99=
re saying that the techniques in that draft *are* just a variant of what =
2140 already suggests, only on a different timescale.

I.e., =E2=80=9Cdiscussing more considerations=E2=80=9D is basically what =
that text already does. All the issues that are in the original doc were =
relevant for this one=E2=80=99s discussion on that issue.

Joe=


From nobody Fri Jun 19 11:58:25 2020
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 CB6D73A0D9B; Fri, 19 Jun 2020 11:58:14 -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, 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 QIDYmO708fkk; Fri, 19 Jun 2020 11:58:12 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 4373A3A0D7C; Fri, 19 Jun 2020 11:58:12 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id r2so12557695ioo.4; Fri, 19 Jun 2020 11:58:12 -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=8Cgp+v3g4iO/D+r/hmIHw63Xf/nb37jsC5MX/EKpzSk=; b=rkhkgjXgHtO7ox3I4FNkTaKb8DlMK02Olchx8mUL/JSOTP30kCAh23rkrNolGLMVUH F/29S2Sr+DIpEbxvax0XN1dOz1n2Kahhfk3t6/SJmxjIHQFxoGyfIkCQJp/Hszgl81yM zwF4ed5nFhO5AiVO5mLYzaBjmIOQsapFaRJRHidwt48uAj0AKZsrKib2saC77Fw4yXE/ wAcWAbP2iuly1qPkaBhU5Z6S0JaTBmxKEoBhMUF77OcmYsL9O5OBDnBUz5Ji82GDRCys LJxFc7FbZk5NttqKN0TYpK1IC+NX+b1LxubN93DZV0CFRbNhUNcmFThyr90Nw+qZZAqU tp4w==
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=8Cgp+v3g4iO/D+r/hmIHw63Xf/nb37jsC5MX/EKpzSk=; b=bRL0Ule2i/dUEXNPx8q0StmShPF4v3zOZql3pojKIslU89mpL12lSWqwhqkuLUQMif QswEKgyGWXwbw29HX1K/La+3xe51N911+Fn2ZOgDToqPMEzj8RvXod6P0NqyPM2Oa0c7 P7q3aYIYqb0pHocY00gP8KT8vuvcDOAWj4+DbCNECEAJy1lSnor28lwJUoNR4TJqmpfG Fvg+0wVoT8NaNGeGCA38r9AerHDBSRT+iBfwQ4Z9VpPsdtcABzcSsUaQpuIh5e28303n oF31ouu66qEAYh1NIQ8UXxGkNkDbr4VnxGakpEG/vnpVDrI+L88jUUdPsvmhV2NjkoMd 0DNg==
X-Gm-Message-State: AOAM530weSLZoQKWai7MuxW01O94lcC2nbc8XQa5IJaBrYczDtlhAr+1 fRskUpYdMnQEw9CQSXyyX4GzHuG64CiPjc3YZAM=
X-Google-Smtp-Source: ABdhPJyV1SE0w6cxyFZv/aFpoNeesjQKYrTAzdACrpYabdhSXYTomC62jgdh90f9kpZfZoxq37fM690ivAOpobPvxMQ=
X-Received: by 2002:a6b:440d:: with SMTP id r13mr5557119ioa.95.1592593091489;  Fri, 19 Jun 2020 11:58:11 -0700 (PDT)
MIME-Version: 1.0
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>     
In-Reply-To: 
From: Martin Duke 
Date: Fri, 19 Jun 2020 11:58:00 -0700
Message-ID: 
To: Stewart Bryant 
Cc: Mark Allman , Review Team , tcpm ,  Last Call , draft-ietf-tcpm-rto-consider.all@ietf.org,  tom petch 
Content-Type: multipart/alternative; boundary="0000000000007d763e05a8747947"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 19 Jun 2020 18:58:15 -0000

--0000000000007d763e05a8747947
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Stewart,

I'm going to ship draft-16 to the IESG today. Any last concerns beyond the
stated differences from WG consensus?

Yoshi, please update the shepherd writeup to cover the flavor of this
discussion.

On Thu, Jun 18, 2020 at 7:18 AM Stewart Bryant 
wrote:

> Here is how we should proceed.
>
> We make as much progress as we can agree on which will clear some of the
> issue below.
>
> For any remaining issues for which you have wider consensus but where we
> cannot agree, I modify my review and the IESG decides how they wish to
> proceed.
>
> I am prepared to be in the rough but I have a duty to draw attention to
> concerns.
>
> Best regards
>
> Stewart
>
>
> > On 18 Jun 2020, at 14:32, Mark Allman  wrote:
> >
> >
> > Last comment first ...
> >
> >> We are getting there, but I would ask that you take the transport
> >> hat off and look again from an infrastructure and packet transport
> >> perspective.
> >
> > I don't view this as looking at it from a transport
> > vs. infrastructure perspective.
> >
> > And, I am not disagreeing with your perspective.  My take is that
> > the nub of what you're saying is that there are cases where we know
> > something about the network.  And, that something let's us design a
> > more savvy loss detection and response scheme.  E.g., because the
> > link / path is known to be short and so using an initial RTO of 1sec
> > is too long.  E.g., because the cause of loss is known or can be
> > safely assumed to not be congestion.  And, I think that view is both
> > correct and reasonable.
> >
> > However, ...
> >
> > (0) I do not view that view as inconsistent with this document at
> >    all.
> >
> > (1) Because there are cases where we know more doesn't make a set of
> >    default requirements for the general case when we don't
> >    understand the path any less valid.
> >
> > (2) The document explicitly says alternates are fine modulo the
> >    usual consensus.  I.e., in cases where we have more information
> >    we can do things differently.  And, the cost of that is no
> >    different than the cost today (i.e., specifying it and gaining
> >    consensus).
> >
> > So, my view is that this all boils down to making it clear that this
> > is not somehow THE (best) way to do time-based loss detection for
> > all cases.  Rather, following the guidelines with result in a
> > safe-for-general-use loss detector.
> >
> >> In the general case, delay across a
> >>    network path depends not only on distance, but also a number of
> >>    variable components such as the route and the level of buffering in
> >>    intermediate devices.
> >>
> >> Its is more the contending/conflicting traffic rather than the
> >> buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffering=
=E2=80=9D is
> >> a link a transport colloquial term.
> >
> > Per this and Gorry's note, I will tweak this to use queuing, as that
> > is what I meant.
> >
> >> Perhaps we could include a clearer disclaimer regarding the
> >> non-best-effort-internet-end-to-end traffic?
> >> You have some text on this down in section 2 but it is a bit buried.
> >
> > OK, let me see if I can foreshadow this a bit more and/or pull some
> > from section 2 to earlier.
> >
> >> An exception to this rule is if an IETF standardized mechanism
> >>        determines that a particular loss is due to a non-congestion
> >>        event (e.g., packet corruption).
> >>
> >> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there t=
han an IETF
> >> standardarized mechanism. The IETF does not have a monopoly on
> >> pre-blessing protocols before they are deployed.
> >> [...]
> >>
> >> In some cases you cannot tell the cause, but it is more important
> >> to ignore the loss. OAM being a particularly good example.
> >
> > First, I don't think I can readily change this without going against
> > the consensus the document has already gathered.  (I.e., this is not
> > about the intro, framing, context, etc. bits, but the actual meat of
> > the technical stuff.)
> >
> > Second, you are right that the IETF does not have a monopoly, but
> > that doesn't make the statement in the document the wrong thing to
> > say.
> >
> > Third, I doubt I should change it.  The problem here from the
> > standpoint of a set of default guidelines is that we'd like a
> > mechanism to determine the cause of loss to **actually work** before
> > it's OK to avoid a congestion control response.  If a standardized
> > mechanism is used then we have some confidence that the mechanism
> > has been vetted as reasonable.  If the mechanism is not standardized
> > then we have no idea if it actually works or if it is some
> > ill-conceived scheme that is badly broken.  In this latter case, I
> > don't think we want to bless this approach as OK within the default.
> > It may be OK, but it should get some consensus that it is OK.
> >
> > allman
>
>

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


Hi Stewart,

I'm going to ship draft=
-16 to the IESG today. Any last concerns beyond the stated differences from=
 WG consensus?

Yoshi, please update the shepherd w=
riteup to cover the flavor of this discussion.

On Thu, Jun 18, 2020 at=
 7:18 AM Stewart Bryant <ste=
wart.bryant@gmail.com> wrote:
Here is how we should proceed.



We make as much progress as we can agree on which will clear some of the is=
sue below.



For any remaining issues for which you have wider consensus but where we ca=
nnot agree, I modify my review and the IESG decides how they wish to procee=
d.



I am prepared to be in the rough but I have a duty to draw attention to con=
cerns.



Best regards



Stewart





> On 18 Jun 2020, at 14:32, Mark Allman <mallman@icir.org> wrote:

> 

> 

> Last comment first ...

> 

>> We are getting there, but I would ask that you take the transport<=
br>
>> hat off and look again from an infrastructure and packet transport=


>> perspective.

> 

> I don't view this as looking at it from a transport

> vs. infrastructure perspective.

> 

> And, I am not disagreeing with your perspective.=C2=A0 My take is that=


> the nub of what you're saying is that there are cases where we kno=
w

> something about the network.=C2=A0 And, that something let's us de=
sign a

> more savvy loss detection and response scheme.=C2=A0 E.g., because the=


> link / path is known to be short and so using an initial RTO of 1sec
> is too long.=C2=A0 E.g., because the cause of loss is known or can be<=
br>
> safely assumed to not be congestion.=C2=A0 And, I think that view is b=
oth

> correct and reasonable.

> 

> However, ...

> 

> (0) I do not view that view as inconsistent with this document at

>=C2=A0 =C2=A0 all.

> 

> (1) Because there are cases where we know more doesn't make a set =
of

>=C2=A0 =C2=A0 default requirements for the general case when we don'=
;t

>=C2=A0 =C2=A0 understand the path any less valid.

> 

> (2) The document explicitly says alternates are fine modulo the

>=C2=A0 =C2=A0 usual consensus.=C2=A0 I.e., in cases where we have more =
information

>=C2=A0 =C2=A0 we can do things differently.=C2=A0 And, the cost of that=
 is no

>=C2=A0 =C2=A0 different than the cost today (i.e., specifying it and ga=
ining

>=C2=A0 =C2=A0 consensus).

> 

> So, my view is that this all boils down to making it clear that this
> is not somehow THE (best) way to do time-based loss detection for

> all cases.=C2=A0 Rather, following the guidelines with result in a

> safe-for-general-use loss detector.

> 

>> In the general case, delay across a

>>=C2=A0 =C2=A0 network path depends not only on distance, but also a=
 number of

>>=C2=A0 =C2=A0 variable components such as the route and the level o=
f buffering in

>>=C2=A0 =C2=A0 intermediate devices.

>> 

>> Its is more the contending/conflicting traffic rather than the

>> buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffe=
ring=E2=80=9D is

>> a link a transport colloquial term.

> 

> Per this and Gorry's note, I will tweak this to use queuing, as th=
at

> is what I meant.

> 

>> Perhaps we could include a clearer disclaimer regarding the

>> non-best-effort-internet-end-to-end traffic?

>> You have some text on this down in section 2 but it is a bit burie=
d.

> 

> OK, let me see if I can foreshadow this a bit more and/or pull some
> from section 2 to earlier.

> 

>> An exception to this rule is if an IETF standardized mechanism

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 determines that a particular loss is du=
e to a non-congestion

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 event (e.g., packet corruption).

>> 

>> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D the=
re than an IETF

>> standardarized mechanism. The IETF does not have a monopoly on

>> pre-blessing protocols before they are deployed.

>> [...]

>> 

>> In some cases you cannot tell the cause, but it is more important<=
br>
>> to ignore the loss. OAM being a particularly good example.

> 

> First, I don't think I can readily change this without going again=
st

> the consensus the document has already gathered.=C2=A0 (I.e., this is =
not

> about the intro, framing, context, etc. bits, but the actual meat of
> the technical stuff.)

> 

> Second, you are right that the IETF does not have a monopoly, but

> that doesn't make the statement in the document the wrong thing to=


> say.

> 

> Third, I doubt I should change it.=C2=A0 The problem here from the

> standpoint of a set of default guidelines is that we'd like a

> mechanism to determine the cause of loss to **actually work** before
> it's OK to avoid a congestion control response.=C2=A0 If a standar=
dized

> mechanism is used then we have some confidence that the mechanism

> has been vetted as reasonable.=C2=A0 If the mechanism is not standardi=
zed

> then we have no idea if it actually works or if it is some

> ill-conceived scheme that is badly broken.=C2=A0 In this latter case, =
I

> don't think we want to bless this approach as OK within the defaul=
t.

> It may be OK, but it should get some consensus that it is OK.

> 

> allman






--0000000000007d763e05a8747947--


From nobody Fri Jun 19 14:22:17 2020
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 F2D653A0E95; Fri, 19 Jun 2020 14:22:07 -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, 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 GfHG-dcGZJ8a; Fri, 19 Jun 2020 14:22:03 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 0B1F53A0E96; Fri, 19 Jun 2020 14:22:03 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id o15so6355790vsp.12; Fri, 19 Jun 2020 14:22:02 -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=DVLRVL4UilKSMFVqbapVgkVJ/NxYVkvkZud5Gyh3zAw=; b=rWu8MLQ5X/KlXjjg1DUh9gfgAqm9V6GC4zcoJZkIlXSrvtRcOA57G3EEzV8MN8a+uh zxCBqnfq9o1bYLUpM2WDT13REK5sGNleYaHMtstsMzMAWjuMH+8UMDJJkFgu2ryd4yQd Vr4pByWKS4/NgxG4okcCW5U1K9RauhGAaFrk5GamgW0OFhfj1ak1H0ruozXYl59+d5L+ TX0GtnqVKdXYxSwGkcM95Phjx4OQmKZ+dToY2nGKaxiMQnLl2IE3Bv/6VuTOhHNrKPtd +HT4INFOj08NExndSGmU5Xrn2LZI/r3R3Bccwo2rbHtLeFVp7mK0H3MYLRfCUxC4qEGr xcmg==
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=DVLRVL4UilKSMFVqbapVgkVJ/NxYVkvkZud5Gyh3zAw=; b=TSYkb1CfQKOQvJ7epsKdDbIr8CY7JOhNXt/U8SoEluW53jMsjyECjVl4YuMdyn/MGy aiRFBoj7R99WS2AP6nlW6XroAzh77Smg3hF7/8a1juKeNqCDPX7/V2DY2ogANmcvH0gO 9iixVmhq+Ki31/p9mAZbbq527i6+RfoXLnA1yTV/LNW8I7qpdHiQrvBOYgwaYZff0nal baxQ5pC3CRbm7W/UZAFa1pmxBOxVDRc35LF2BUjZZXNF7O8kMS/aL+oHLi/caiFABrGD w2TjpuhF/+ssft9LtPNf6ZfkygLC5VRzhH2NtwF1Ohz95keH4EUFYzeIi05ZBY2L6jVs fWdw==
X-Gm-Message-State: AOAM531vdOfKmiBWyAyun8LcurPVpbi22QBpolKQvOowG8mUqd7PDGe3 9WJ7GjkbOgW5D9AGwh1KPLrwtHykByO0mwOAoX8=
X-Google-Smtp-Source: ABdhPJyfg3PqaX/1BzwxSrlJeYmaaCCF88D3fr1RuNDmpcgpZyV5VePgSIo+lZCfANIM+kQKnVr4KxTiB86XDgOOOMk=
X-Received: by 2002:a05:6102:3098:: with SMTP id l24mr8795056vsb.86.1592601721984;  Fri, 19 Jun 2020 14:22:01 -0700 (PDT)
MIME-Version: 1.0
References: <159083802039.5596.14695350463305243689@ietfa.amsl.com>  <9A0DBDC4-2E39-4D09-80A6-FEDE72ED205B@gmail.com> <0F4B56B1-C8B9-493E-B3CD-AC2FBA9E62E4@icir.org>      
In-Reply-To: 
From: Yoshifumi Nishida 
Date: Fri, 19 Jun 2020 14:21:51 -0700
Message-ID: 
To: Martin Duke 
Cc: Stewart Bryant , Mark Allman ,  Review Team , tcpm , Last Call ,  draft-ietf-tcpm-rto-consider.all@ietf.org, tom petch 
Content-Type: multipart/alternative; boundary="000000000000e85ec805a8767b99"
Archived-At: 
Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rto-consider-14
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, 19 Jun 2020 21:22:08 -0000

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

OK. if there're no further opinions, I will do it.
--
Yoshi


On Fri, Jun 19, 2020 at 11:58 AM Martin Duke 
wrote:

> Hi Stewart,
>
> I'm going to ship draft-16 to the IESG today. Any last concerns beyond th=
e
> stated differences from WG consensus?
>
> Yoshi, please update the shepherd writeup to cover the flavor of this
> discussion.
>
> On Thu, Jun 18, 2020 at 7:18 AM Stewart Bryant 
> wrote:
>
>> Here is how we should proceed.
>>
>> We make as much progress as we can agree on which will clear some of the
>> issue below.
>>
>> For any remaining issues for which you have wider consensus but where we
>> cannot agree, I modify my review and the IESG decides how they wish to
>> proceed.
>>
>> I am prepared to be in the rough but I have a duty to draw attention to
>> concerns.
>>
>> Best regards
>>
>> Stewart
>>
>>
>> > On 18 Jun 2020, at 14:32, Mark Allman  wrote:
>> >
>> >
>> > Last comment first ...
>> >
>> >> We are getting there, but I would ask that you take the transport
>> >> hat off and look again from an infrastructure and packet transport
>> >> perspective.
>> >
>> > I don't view this as looking at it from a transport
>> > vs. infrastructure perspective.
>> >
>> > And, I am not disagreeing with your perspective.  My take is that
>> > the nub of what you're saying is that there are cases where we know
>> > something about the network.  And, that something let's us design a
>> > more savvy loss detection and response scheme.  E.g., because the
>> > link / path is known to be short and so using an initial RTO of 1sec
>> > is too long.  E.g., because the cause of loss is known or can be
>> > safely assumed to not be congestion.  And, I think that view is both
>> > correct and reasonable.
>> >
>> > However, ...
>> >
>> > (0) I do not view that view as inconsistent with this document at
>> >    all.
>> >
>> > (1) Because there are cases where we know more doesn't make a set of
>> >    default requirements for the general case when we don't
>> >    understand the path any less valid.
>> >
>> > (2) The document explicitly says alternates are fine modulo the
>> >    usual consensus.  I.e., in cases where we have more information
>> >    we can do things differently.  And, the cost of that is no
>> >    different than the cost today (i.e., specifying it and gaining
>> >    consensus).
>> >
>> > So, my view is that this all boils down to making it clear that this
>> > is not somehow THE (best) way to do time-based loss detection for
>> > all cases.  Rather, following the guidelines with result in a
>> > safe-for-general-use loss detector.
>> >
>> >> In the general case, delay across a
>> >>    network path depends not only on distance, but also a number of
>> >>    variable components such as the route and the level of buffering i=
n
>> >>    intermediate devices.
>> >>
>> >> Its is more the contending/conflicting traffic rather than the
>> >> buffering, or perhaps the time spent in queues, but =E2=80=9Cbufferin=
g=E2=80=9D is
>> >> a link a transport colloquial term.
>> >
>> > Per this and Gorry's note, I will tweak this to use queuing, as that
>> > is what I meant.
>> >
>> >> Perhaps we could include a clearer disclaimer regarding the
>> >> non-best-effort-internet-end-to-end traffic?
>> >> You have some text on this down in section 2 but it is a bit buried.
>> >
>> > OK, let me see if I can foreshadow this a bit more and/or pull some
>> > from section 2 to earlier.
>> >
>> >> An exception to this rule is if an IETF standardized mechanism
>> >>        determines that a particular loss is due to a non-congestion
>> >>        event (e.g., packet corruption).
>> >>
>> >> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D there =
than an IETF
>> >> standardarized mechanism. The IETF does not have a monopoly on
>> >> pre-blessing protocols before they are deployed.
>> >> [...]
>> >>
>> >> In some cases you cannot tell the cause, but it is more important
>> >> to ignore the loss. OAM being a particularly good example.
>> >
>> > First, I don't think I can readily change this without going against
>> > the consensus the document has already gathered.  (I.e., this is not
>> > about the intro, framing, context, etc. bits, but the actual meat of
>> > the technical stuff.)
>> >
>> > Second, you are right that the IETF does not have a monopoly, but
>> > that doesn't make the statement in the document the wrong thing to
>> > say.
>> >
>> > Third, I doubt I should change it.  The problem here from the
>> > standpoint of a set of default guidelines is that we'd like a
>> > mechanism to determine the cause of loss to **actually work** before
>> > it's OK to avoid a congestion control response.  If a standardized
>> > mechanism is used then we have some confidence that the mechanism
>> > has been vetted as reasonable.  If the mechanism is not standardized
>> > then we have no idea if it actually works or if it is some
>> > ill-conceived scheme that is badly broken.  In this latter case, I
>> > don't think we want to bless this approach as OK within the default.
>> > It may be OK, but it should get some consensus that it is OK.
>> >
>> > allman
>>
>>

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


OK. if there're no further opinions, I will=C2=A0do it=
.
--
Yoshi

<=
/div>
O=
n Fri, Jun 19, 2020 at 11:58 AM Martin Duke <martin.h.duke@gmail.com> wrote:
H=
i Stewart,

I'm going to ship draft-16 to the IESG to=
day. Any last concerns beyond the stated differences from WG consensus?

Yoshi, please update the shepherd writeup to cover th=
e flavor of this discussion.

On Thu, Jun 18, 2020 at 7:18 AM Stewart B=
ryant <ste=
wart.bryant@gmail.com> wrote:
Here is how we should proceed.



We make as much progress as we can agree on which will clear some of the is=
sue below.



For any remaining issues for which you have wider consensus but where we ca=
nnot agree, I modify my review and the IESG decides how they wish to procee=
d.



I am prepared to be in the rough but I have a duty to draw attention to con=
cerns.



Best regards



Stewart





> On 18 Jun 2020, at 14:32, Mark Allman <mallman@icir.org> wrote:

> 

> 

> Last comment first ...

> 

>> We are getting there, but I would ask that you take the transport<=
br>
>> hat off and look again from an infrastructure and packet transport=


>> perspective.

> 

> I don't view this as looking at it from a transport

> vs. infrastructure perspective.

> 

> And, I am not disagreeing with your perspective.=C2=A0 My take is that=


> the nub of what you're saying is that there are cases where we kno=
w

> something about the network.=C2=A0 And, that something let's us de=
sign a

> more savvy loss detection and response scheme.=C2=A0 E.g., because the=


> link / path is known to be short and so using an initial RTO of 1sec
> is too long.=C2=A0 E.g., because the cause of loss is known or can be<=
br>
> safely assumed to not be congestion.=C2=A0 And, I think that view is b=
oth

> correct and reasonable.

> 

> However, ...

> 

> (0) I do not view that view as inconsistent with this document at

>=C2=A0 =C2=A0 all.

> 

> (1) Because there are cases where we know more doesn't make a set =
of

>=C2=A0 =C2=A0 default requirements for the general case when we don'=
;t

>=C2=A0 =C2=A0 understand the path any less valid.

> 

> (2) The document explicitly says alternates are fine modulo the

>=C2=A0 =C2=A0 usual consensus.=C2=A0 I.e., in cases where we have more =
information

>=C2=A0 =C2=A0 we can do things differently.=C2=A0 And, the cost of that=
 is no

>=C2=A0 =C2=A0 different than the cost today (i.e., specifying it and ga=
ining

>=C2=A0 =C2=A0 consensus).

> 

> So, my view is that this all boils down to making it clear that this
> is not somehow THE (best) way to do time-based loss detection for

> all cases.=C2=A0 Rather, following the guidelines with result in a

> safe-for-general-use loss detector.

> 

>> In the general case, delay across a

>>=C2=A0 =C2=A0 network path depends not only on distance, but also a=
 number of

>>=C2=A0 =C2=A0 variable components such as the route and the level o=
f buffering in

>>=C2=A0 =C2=A0 intermediate devices.

>> 

>> Its is more the contending/conflicting traffic rather than the

>> buffering, or perhaps the time spent in queues, but =E2=80=9Cbuffe=
ring=E2=80=9D is

>> a link a transport colloquial term.

> 

> Per this and Gorry's note, I will tweak this to use queuing, as th=
at

> is what I meant.

> 

>> Perhaps we could include a clearer disclaimer regarding the

>> non-best-effort-internet-end-to-end traffic?

>> You have some text on this down in section 2 but it is a bit burie=
d.

> 

> OK, let me see if I can foreshadow this a bit more and/or pull some
> from section 2 to earlier.

> 

>> An exception to this rule is if an IETF standardized mechanism

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 determines that a particular loss is du=
e to a non-congestion

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 event (e.g., packet corruption).

>> 

>> That is a bit heavy. It should be =E2=80=9Ca protocol=E2=80=9D the=
re than an IETF

>> standardarized mechanism. The IETF does not have a monopoly on

>> pre-blessing protocols before they are deployed.

>> [...]

>> 

>> In some cases you cannot tell the cause, but it is more important<=
br>
>> to ignore the loss. OAM being a particularly good example.

> 

> First, I don't think I can readily change this without going again=
st

> the consensus the document has already gathered.=C2=A0 (I.e., this is =
not

> about the intro, framing, context, etc. bits, but the actual meat of
> the technical stuff.)

> 

> Second, you are right that the IETF does not have a monopoly, but

> that doesn't make the statement in the document the wrong thing to=


> say.

> 

> Third, I doubt I should change it.=C2=A0 The problem here from the

> standpoint of a set of default guidelines is that we'd like a

> mechanism to determine the cause of loss to **actually work** before
> it's OK to avoid a congestion control response.=C2=A0 If a standar=
dized

> mechanism is used then we have some confidence that the mechanism

> has been vetted as reasonable.=C2=A0 If the mechanism is not standardi=
zed

> then we have no idea if it actually works or if it is some

> ill-conceived scheme that is badly broken.=C2=A0 In this latter case, =
I

> don't think we want to bless this approach as OK within the defaul=
t.

> It may be OK, but it should get some consensus that it is OK.

> 

> allman








--000000000000e85ec805a8767b99--


From nobody Tue Jun 23 20:46:25 2020
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 5D2283A078C for ; Tue, 23 Jun 2020 20:46:24 -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, 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 fyjOZh6MJh8A for ; Tue, 23 Jun 2020 20:46:22 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 B24413A078A for ; Tue, 23 Jun 2020 20:46:21 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id b15so423977edy.7 for ; Tue, 23 Jun 2020 20:46:21 -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=X/+9akknEyZIZ8k6agRVvpLiTopnE+MstTop3qRqnic=; b=mRzLULkaVerva+h5UQrXEwEc4TVmPIXBPBTKf6NzBDApVrm+cfaGVxz0aKMfbga6J8 WCWvLAvNVxV8/BgmJuvxloD5Tk6WGq01riwrro3R6rr/e0joOuSR+oDBAK8ArwqHVu06 dtgfqN4pM4BlBjw8obFhjolV9zKVMBWEjHcI/ToThmAzrlxHBcU//VqyRorvR43bu3ml 9WOqDeJxxIgTC8gRsLjcBDtNOsk2qyIIpqTkzBO/QRIBGbbDCnOifTshnlmV8pX+JKNL HRShY0vHYV90uHxWCGJS2O3w2/Yic3awjxRDWhT/ALMIVi+FLRRqeA6o4kCM9V7Swuh/ bPIg==
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=X/+9akknEyZIZ8k6agRVvpLiTopnE+MstTop3qRqnic=; b=nrUPQpbFPkbNVCjDjzilWNmt7SFHAVnhoEu0LQQeqqu1LUYEFhiQU1RZrYUeFCNAG8 9sFLPp//9SnC/pOmtQM0Z6GWSIiK92JPSPQskWia+h4K0+x48l/uXBj+FG+M0brzzdYy ikcLUmrIN/ZO+P19YpD8VApIUDTU7CeEQu4C43zqDW6ECOvtIYVYx20Q5XfgbFcqBYnP 0QK4pJVaTt7k6dgDbpwaPh/Jo8DSqbmKhXHRWe5UqI1g5YwUxgWZV8CpyOaIexYjcaxc AISYVANwah5ZzrL7uejWLl6b7cumAxIGKvhgmtBmWZQemm4cnZcSEVdPrQ7QfqQCTNzo RwbQ==
X-Gm-Message-State: AOAM533cGg8VmrSFPAY6GSHT8fVhnHH/+MVo6fSAq/9D7gxIwrSs/4f1 232nYcdPi+MD8UVXK0v9KN1UwHRrgbjnXleUDLl1ITX7
X-Google-Smtp-Source: ABdhPJzowm79BNOb+8zTa0FxJbrHLqaV7rBVvFgUTUFE3+ifVqevDo2qYypC85mUVM1YIggXtkF8pOOyWK/XBhwkiWw=
X-Received: by 2002:aa7:d297:: with SMTP id w23mr14250792edq.49.1592970380077;  Tue, 23 Jun 2020 20:46:20 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Rahul Jadhav 
Date: Wed, 24 Jun 2020 11:46:08 +0800
Message-ID: 
To: Gorry Fairhurst 
Cc: tcpm@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a46fc405a8cc5193"
Archived-At: 
Subject: Re: [tcpm] Some comments on draft-li-tcpm-advancing-ack-for-wireless-00
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, 24 Jun 2020 03:46:24 -0000

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

Thanks Gorry for the feedback and for providing the refs of work in the
context. Sorry for the late reply. It took me some time to get a handle on
the refs you provided.
Please find my [RJ] comments inline.

Best,
Rahul

On Wed, 29 Apr 2020 at 21:30, Gorry Fairhurst  wrote:

>
> This email contains comments on comments on
> draft-li-tcpm-advancing-ack-for-wireless-00
>
> I think this draft touches on a specific topic, but I am unsure of the
> maturity of the current proposal with respect to the TCPM working group.
>
> I suggest you refer to RFC3449, it still contains a list of different
> in-network modifications to ACKs, which I think remain widely deployed
> in this type of network.
>

[RJ] RFC 3449 provides great ref points and it solidly sets the context.
However, it does not attempt to provide any solution space beyond the
constraints of TCP. Section 5 provides leads to enhancing TCP performance
using transparent modifications. I find that section 5 of RFC 3449 tries to
tackle issues such as Traffic burst, releasing CWND etc but it does not
look into the impact of RTT estimation because of ACK reduction.
Our attempt is different in the following ways:
a) Relook at protocol extensions to alleviating the impact of ACK
reduction. One example is alleviating the error in RTT estimation by using
protocol extensions and a one-way delay factor.
b) Not necessarily all the primitives can be applied generically and across
all apps. Don=E2=80=99t intend to be a generic solution but provide primiti=
ves for
specific scenarios.
c) Attempt for drastic ACK reduction (not just by a factor of 2x or 10x but
may be > 100x)
I agree that such a proposal may be beyond the scope of TCPM, but this may
be a good place to have this discussion.


>
> The draft says:
> =E2=80=9CAn upper bound of L can also be derived according
>     to the loss rate on the data path (plr_data) and the ack path
>     (plr_ack), i.e., L <=3D feedback_info/(plr_data*plr_ack), where
>     feedback_info denotes the amount of information carried by an ACK.=E2=
=80=9D
> - which reads a little like the mechanisms in TCP NCR/ACK-CC/RFC4341. If
> L is computed from feedback loss information, it can not be set to
> appropriately compensate for radio resource cost - the ACK rate can grow
> to fill the available return  bottleneck capacity.
>

[RJ] RFC4341 was a refreshing read. Sections 6.1.x provide an explanation
about increasing/decreasing ACK ratio based on congestion feedback and that
is something to get inspired from. However (surprisingly) there is no
mention of any handling of side-effects resulting from ACK reduction in
this RFC. Also handling app-limited traffic is something that is not
considered by any of these designs (including ours). ACK-CC uses CCID-2
(RFC 4341) as the basis and explains the possible complications but also
does not give any indication of how to handle the impact. RTT estimation is
greatly impacted because of ACK reduction and either of these works does
not provide any possible solution towards this. We found that
rate-based/delay-based CC (especially BBR, Copa) has a big impact because
of this.
Btw, I am not sure if I understand what TCP NCR refers to? Can you please
provide a link? Thanks


> - In contrast, an L that is based on target asymmetry, e.g. L=3D10 does
> not have this drawback, although in our work we argue that this is also
> important for a large BDP.
>
> I agree the value beta =3D 4 is probably a suitable general update
> interval, but expect that my thoughts on this are based on sender pacing
> of the transmission. Have you thought about the pacing requirements of
> your method? It seems that mitigating bursts is going to be an important
> design for a stretch-ack proposal, but there are downsides to excessive
> pacing likely in a wireless case. Have you considering the implications
> of pacing?
>

[RJ] In our use-case, pacing was degrading the performance because of the
impact on wireless link-layer aggregation. What we tried is applying
rate-based pacing on a bunch/burst of data packets released on receiving an
ACK. We haven=E2=80=99t tried many experiments with pacing in general and i=
t is an
important aspect to cover. I find that RFC 3449 provides a good context for
handling the pacing aspects.


>
> Once the cwnd, rwnd >> flow=E2=80=99s required BDP, the effect of L on th=
e
> growth of cwnd becomes rather small. Of course there can be
> considerations also in the case of loss for thin flows, where the time
> to detect a tail loss would be increased by rtt/beta.
> What do you mean by:
> =E2=80=9CLatency-sensitive transport usually has a small BDP,
>     in the case of application limitation, the latency of thin flows
>     might be enlarged due to a large L.=E2=80=9D?
>

[RJ] This is a misleading statement. What we wanted to say is,
"Latency-sensitive flows (such as RPCs) and application-limited flows
having a relatively low-throughput suffer more from ACK-reduction as L
grows."

>
> When I read this, I did not understand how the two endpoints agreed on
> the input values that would be needed to perform the mitigation to ACK
> rate.
>

[RJ] There are set of TCP extensions on which it relies namely, to
handshake one-way-delay from (data) receiver and ACK rate (as defined in
ACK-CC). We haven=E2=80=99t talked about the extensions in the draft as of =
now.


>
> Changing the ACK frequency dynamically implies the need for signalling,
> and flows that change between application-limited and cwnd-limited would
> then need to be considered. Does anything need to be done to avoid
> oscillation in the ACK policy?
>

[RJ] Imo, avoiding oscillations is needed. Again RFC 4341 section 6.1.2
provides good handling (a function of RTT and configurable threshold) for
avoiding such oscillations and mostly I see that the same mechanism fits
generically for any dynamic ACK reduction mechanism.
Quoting verbatim:
"The sender need not keep Ack Ratio completely up to date.  For
   instance, it MAY rate-limit Ack Ratio renegotiations to once every
   four or five round-trip times, or to once every second or two.  The
   sender SHOULD NOT attempt to renegotiate the Ack Ratio more than once
   per round-trip time.  Additionally, it MAY enforce a minimum Ack
   Ratio of two, or it MAY set Ack Ratio to one for half-connections
   with persistent congestion windows of 1 or 2 packets."


>
> One last thing I am curious about is how your proposal will interact
> with methods such as ACK Thinning at the network layer, I=E2=80=99d hope =
there
> are only positive benefits when both schemes are used. Do you have
> experience of this?
>

[RJ] The ACK reduction impact handling primitives worked in favor of
alleviating the impact of ACK thinning either by transport or
network/link-layer. We do not have numbers showing the difference though.
It would have been nice to document these results.


>
> Best wishes,
>
> Gorry Fairhurst
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

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


Thanks Gorry for the feedback and for pro=
viding the refs of work in the context. Sorry for the late reply. It took m=
e some time to get a handle on the refs you provided.
Please find my [RJ=
] comments inline.

Best,
Rahul

On Wed, 29 Apr 2020 at 21:30, G=
orry Fairhurst <gorry@erg.abdn.a=
c.uk> wrote:


This email contains comments on comments on 

draft-li-tcpm-advancing-ack-for-wireless-00



I think this draft touches on a specific topic, but I am unsure of the 

maturity of the current proposal with respect to the TCPM working group.


I suggest you refer to RFC3449, it still contains a list of different 

in-network modifications to ACKs, which I think remain widely deployed 

in this type of network.

[RJ] RFC 3449 provi=
des great ref points and it solidly sets the context. However, it does not =
attempt to provide any solution space beyond the constraints of TCP. Sectio=
n 5 provides leads to enhancing TCP performance using transparent modificat=
ions. I find that section 5 of RFC 3449 tries to tackle issues such as Traf=
fic burst, releasing CWND etc but it does not look into the impact of RTT e=
stimation because of ACK reduction.
Our attempt is different in the foll=
owing ways:
a) Relook at protocol extensions to alleviating the impact o=
f ACK reduction. One example is alleviating the error in RTT estimation by =
using protocol extensions and a one-way delay factor.
b) Not necessarily=
 all the primitives can be applied generically and across all apps. Don=E2=
=80=99t intend to be a generic solution but provide primitives for specific=
 scenarios.
c) Attempt for drastic ACK reduction (not just by a factor o=
f 2x or 10x but may be > 100x)
I agree that such a proposal may =
be beyond the scope of TCPM, but this may be a good place to have this disc=
ussion.
=C2=A0



The draft says:

=E2=80=9CAn upper bound of L can also be derived according

=C2=A0=C2=A0=C2=A0 to the loss rate on the data path (plr_data) and the ack=
 path

=C2=A0=C2=A0=C2=A0 (plr_ack), i.e., L <=3D feedback_info/(plr_data*plr_a=
ck), where

=C2=A0=C2=A0=C2=A0 feedback_info denotes the amount of information carried =
by an ACK.=E2=80=9D

- which reads a little like the mechanisms in TCP NCR/ACK-CC/RFC4341. If 
L is computed from feedback loss information, it can not be set to 

appropriately compensate for radio resource cost - the ACK rate can grow 
to fill the available return=C2=A0 bottleneck capacity.

[RJ] RFC4341 was a refreshing read. Sections 6.1.x provide an e=
xplanation about increasing/decreasing ACK ratio based on congestion feedba=
ck and that is something to get inspired from. However (surprisingly) there=
 is no mention of any handling of side-effects resulting from ACK reduction=
 in this RFC. Also handling app-limited traffic is something that is not co=
nsidered by any of these designs (including ours). ACK-CC uses CCID-2 (RFC =
4341) as the basis and explains the possible complications but also does no=
t give any indication of how to handle the impact. RTT estimation is greatl=
y impacted because of ACK reduction and either of these works does not prov=
ide any possible solution towards this. We found that rate-based/delay-base=
d CC (especially BBR, Copa) has a big impact because of this.
Btw, =
I am not sure if I understand what TCP NCR refers to? Can you please provid=
e a link? Thanks
=C2=A0

- In contrast, an L that is based on target asymmetry, e.g. L=3D10 does 
not have this drawback, although in our work we argue that this is also 
important for a large BDP.



I agree the value beta =3D 4 is probably a suitable general update 

interval, but expect that my thoughts on this are based on sender pacing 
of the transmission. Have you thought about the pacing requirements of 

your method? It seems that mitigating bursts is going to be an important 
design for a stretch-ack proposal, but there are downsides to excessive 
pacing likely in a wireless case. Have you considering the implications 
of pacing?

[RJ] In our use-case, pacing=
 was degrading the performance because of the impact on wireless link-layer=
 aggregation. What we tried is applying rate-based pacing on a bunch/burst =
of data packets released on receiving an ACK. We haven=E2=80=99t tried many=
 experiments with pacing in general and it is an important aspect to cover.=
 I find that RFC 3449 provides a good context for handling the pacing aspec=
ts.
=C2=A0



Once the cwnd, rwnd >> flow=E2=80=99s required BDP, the effect of L o=
n the 

growth of cwnd becomes rather small. Of course there can be 

considerations also in the case of loss for thin flows, where the time 

to detect a tail loss would be increased by rtt/beta.

What do you mean by:

=E2=80=9CLatency-sensitive transport usually has a small BDP,

=C2=A0=C2=A0=C2=A0 in the case of application limitation, the latency of th=
in flows

=C2=A0=C2=A0=C2=A0 might be enlarged due to a large L.=E2=80=9D?

[RJ] This is a misleading statement. What we want=
ed to say is, "Latency-sensitive flows (such as RPCs) and application-=
limited flows having a relatively low-throughput suffer more from ACK-reduc=
tion as L grows."



When I read this, I did not understand how the two endpoints agreed on 

the input values that would be needed to perform the mitigation to ACK rate=
.

[RJ] There are set of TCP extensions =
on which it relies namely, to handshake one-way-delay from (data) receiver =
and ACK rate (as defined in ACK-CC). We haven=E2=80=99t talked about the ex=
tensions in the draft as of now.
=C2=A0



Changing the ACK frequency dynamically implies the need for signalling, 
and flows that change between application-limited and cwnd-limited would 
then need to be considered. Does anything need to be done to avoid 

oscillation in the ACK policy?

[RJ] Imo=
, avoiding oscillations is needed. Again RFC 4341 section 6.1.2 provides go=
od handling (a function of RTT and configurable threshold) for avoiding suc=
h oscillations and mostly I see that the same mechanism fits generically fo=
r any dynamic ACK reduction mechanism.
Quoting verbatim:
"The sender need not keep Ack Ratio completely up to date.=C2=A0 For=

=C2=A0 =C2=A0instance, it MAY rate-limit Ack Ratio renegotiations to =
once every
=C2=A0 =C2=A0four or five round-trip times, or to once every =
second or two.=C2=A0 The
=C2=A0 =C2=A0sender SHOULD NOT attempt to reneg=
otiate the Ack Ratio more than once
=C2=A0 =C2=A0per round-trip time.=C2=
=A0 Additionally, it MAY enforce a minimum Ack
=C2=A0 =C2=A0Ratio of two=
, or it MAY set Ack Ratio to one for half-connections
=C2=A0 =C2=A0with =
persistent congestion windows of 1 or 2 packets."
=C2=A0



One last thing I am curious about is how your proposal will interact 

with methods such as ACK Thinning at the network layer, I=E2=80=99d hope th=
ere 

are only positive benefits when both schemes are used. Do you have 

experience of this?

[RJ] The ACK reduct=
ion impact handling primitives worked in favor of alleviating the impact of=
 ACK thinning either by transport or network/link-layer. We do not have num=
bers showing the difference though. It would have been nice to document the=
se results.
=C2=A0



Best wishes,



Gorry Fairhurst



_______________________________________________

tcpm mailing list

tcpm@ietf.org

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




--000000000000a46fc405a8cc5193--


From nobody Thu Jun 25 14:03:31 2020
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 269693A1037 for ; Thu, 25 Jun 2020 14:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level: 
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 XzqwS580tLOb for ; Thu, 25 Jun 2020 14:03:15 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 7EF5D3A104C for ; Thu, 25 Jun 2020 14:03:15 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id q15so2142948uap.4 for ; Thu, 25 Jun 2020 14:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3bVC8R5dbqWSe3tZiyxANKqsxl5tdWLWFKmDjCWwaNY=; b=BuYR0lknm2ArGECbRhHYMHTYfGTPQ5fM156PczXKSZmTsrSUPGSoRjCXEYvENmWNBJ PLGe3CeLTWiaDv2zTA2XsGBrBM/6v27i4Sff6e587PoP3+91q6ezrnSmMPo2EgGUh2dg i3zfEOksPsYxuh+zv3INnMSsh3rYlwLL7MCEQBnj0ExaBhiM2nBaXuE7e661ved2yVMz WM6cWoYmPzSwy8t0+rFFblRnHHzplEFM/EjaTrLvUQDHdsLCbdwrZozgSgQc8RvxWnyo W+aO817FN+7XOi/4meIDAGZW7aLDS1FZfVBhG3rOX2j5yl2cDG90sAWZdowf/AX2gbGF VF/g==
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:content-transfer-encoding; bh=3bVC8R5dbqWSe3tZiyxANKqsxl5tdWLWFKmDjCWwaNY=; b=iCAzCbHJyn9yMpqTpeBCR7VnjxSUZDmikYlqMxTP6bfjDX4AuNWGMnWJ7V2g6GM31Z PyzJNdbY2+ptfC91ZZjZYzTQTMU96iwROq1x/PdXwHVzVkBtzReAFRlpYRfnaKkd9y9C Ad8jReshfKJv8Yr+72WCXuD9TjrsIfQgyG2KOVSVo09yrrqM0mqpO3D1Yz+wMNEyZlLa 6T+/1QceB4VzA8xC0yYiOY4G6FL7LHSALdvQDMCDQY0bpv8Wk8hP2bsAsMPCuroIeZCD nwFKA8y+mmnW+tdEqwKzzq+fesB8tmsmr++i9GdrvKXNBs/c60UJw9pxYiRDekMy9+ls Gfxw==
X-Gm-Message-State: AOAM531IiT8UKVGak9m/N/xWNQ3pJzT1p/KqO42vEpkn3xsmKGEH/YGi d79MiTFQIAFf4HRrrz2n4iXv3Zor4WhbqU1l5QGc6Q==
X-Google-Smtp-Source: ABdhPJwAV6EbszmCkBy++cUMeA3yUXsZXKb1fezSCunoDCoAUmfn5dDctPTFxxfnfCBxIx6/69H3Ze7FuC2dSBFs4JM=
X-Received: by 2002:a9f:2407:: with SMTP id 7mr3141896uaq.80.1593118994184; Thu, 25 Jun 2020 14:03:14 -0700 (PDT)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de> <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com>
In-Reply-To: <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com>
From: Yuchung Cheng 
Date: Thu, 25 Jun 2020 14:02:38 -0700
Message-ID: 
To: Joseph Touch 
Cc: "Scharf, Michael" , "tcpm@ietf.org" , tcpm-chairs 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 25 Jun 2020 21:03:30 -0000

On
"Because this is similar to the case
   when a connection becomes idle, mechanisms that address idle TCP
   connections (e.g., [RFC7661]) could also be applied to TCB cache
   management, especially when TCP Fast Open is used [RFC7413]"

Why do TFO-started idle connections benefit this particularly?


On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch  wrote:
>
> I=E2=80=99m guessing the views of the authors is gratuitous, but to at le=
ast be explicit:
>
> +1
>
> Joe
>
> > On Jun 12, 2020, at 2:56 AM, Scharf, Michael  wrote:
> >
> > Hi all,
> >
> > I haven't seen any reply so far. Lack of _any_ feedback is not a partic=
ularly good sign.
> >
> > Anyway, no feedback implies that the document is ready to move forward.=
 However, even in that case explicit support for publication  would be _rea=
lly_ useful. A simple "+1" could be enough...
> >
> > I'll extend the WGLC by one week until June 21 to give the community so=
me additional time to comment.
> >
> > Thanks
> >
> > Michael
> >
> >
> >> -----Original Message-----
> >> From: Scharf, Michael 
> >> Sent: Saturday, May 30, 2020 8:06 PM
> >> To: tcpm@ietf.org
> >> Cc: tcpm-chairs 
> >> Subject: WGLC for draft-ietf-tcpm-2140bis
> >>
> >> Hi all,
> >>
> >> The document "TCP Control Block Interdependence" (draft-ietf-tcpm-
> >> 2140bis) is out there for a quite some time already. Given that there =
has
> >> been a bit less activity on the list after the interim, let's use this=
 opportunity
> >> to finish one of our milestones...
> >>
> >> This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis. Th=
e
> >> WGLC will run until ***June 14***.
> >>
> >> The intended status is an informational RFC. The current version of th=
e
> >> document can be found at:
> >>
> >> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
> >>
> >> Please review the latest version and please let us know any comments o=
r
> >> suggestions. TCPM needs reviews to ensure that the content is ready to
> >> move forward. Feedback supporting publication ("+1") is also very welc=
ome.
> >>
> >> Thanks
> >>
> >> Michael, on behalf of the TCPM chairs
> >
> > _______________________________________________
> > 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


From nobody Fri Jun 26 08:03:55 2020
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 9B6D63A0835; Fri, 26 Jun 2020 08:03:45 -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, 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 YHFjm8XPn5Qr; Fri, 26 Jun 2020 08:03:44 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 E8C293A083C; Fri, 26 Jun 2020 08:03:43 -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=TsRxkdNsS3J7YBDrJJ2niN3wY6WsHI5GNyry+gWZWEg=; b=ALL/YinZRY9Zs72C9wETbGIHe 467aE+7f4OuQSe1M2AVcXURRsb8Tw7/5QGP65S0KE91HdfMYRPdcihh4GCon4i9qC58B70saRJAPf 9VYYFJWUrqLKkYSlkA2LeYdy7r0D+TjjD/CxAkqGwJiVU5UnBWCuAtXgjBBWhusy0mRFOv+H8TLc5 R7/jpLhbd3u903uZmOJ4Ksikqabv3KtqDBIC2ANCXPOYwjbV3LcY++y2nkXyAb1w6QoJlrmerrpGP h9TuVNNR60EOjKxaCSboYs3KwVQR5eG0TB41XGz6ec3eIRlXGGUoYwACSdULtKTpxYRz37VJx8nW7 dvDOPBZNQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56668 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1joptB-00025a-B8; Fri, 26 Jun 2020 11:03:41 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 26 Jun 2020 08:03:36 -0700
Cc: "tcpm@ietf.org" , tcpm-chairs 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de> <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com> 
To: Yuchung Cheng 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 26 Jun 2020 15:03:54 -0000

Yi, Yuchung,

The text was introduced in the draft-touch-tcpm-2140bis-05 version in =
Sept 2018.

It relates to the way in which 2140 would handle the effect of idle =
connections and how that information becomes invalid over time as long =
as the connection is idle.

I.e., the idea is that 2140 could help TFP avoid bursting into the net =
more aggressively rather than backing down, as discussed in Sec 7.2 of =
RFC 7413.=20

If our interpretation or the text would benefit from revision, please =
suggest alternate text.

Joe

> On Jun 25, 2020, at 2:02 PM, Yuchung Cheng =
 wrote:
>=20
> On
> "Because this is similar to the case
>   when a connection becomes idle, mechanisms that address idle TCP
>   connections (e.g., [RFC7661]) could also be applied to TCB cache
>   management, especially when TCP Fast Open is used [RFC7413]"
>=20
> Why do TFO-started idle connections benefit this particularly?
>=20
>=20
> On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch  =
wrote:
>>=20
>> I=E2=80=99m guessing the views of the authors is gratuitous, but to =
at least be explicit:
>>=20
>> +1
>>=20
>> Joe
>>=20
>>> On Jun 12, 2020, at 2:56 AM, Scharf, Michael =
 wrote:
>>>=20
>>> Hi all,
>>>=20
>>> I haven't seen any reply so far. Lack of _any_ feedback is not a =
particularly good sign.
>>>=20
>>> Anyway, no feedback implies that the document is ready to move =
forward. However, even in that case explicit support for publication  =
would be _really_ useful. A simple "+1" could be enough...
>>>=20
>>> I'll extend the WGLC by one week until June 21 to give the community =
some additional time to comment.
>>>=20
>>> Thanks
>>>=20
>>> Michael
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Scharf, Michael 
>>>> Sent: Saturday, May 30, 2020 8:06 PM
>>>> To: tcpm@ietf.org
>>>> Cc: tcpm-chairs 
>>>> Subject: WGLC for draft-ietf-tcpm-2140bis
>>>>=20
>>>> Hi all,
>>>>=20
>>>> The document "TCP Control Block Interdependence" (draft-ietf-tcpm-
>>>> 2140bis) is out there for a quite some time already. Given that =
there has
>>>> been a bit less activity on the list after the interim, let's use =
this opportunity
>>>> to finish one of our milestones...
>>>>=20
>>>> This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis. =
The
>>>> WGLC will run until ***June 14***.
>>>>=20
>>>> The intended status is an informational RFC. The current version of =
the
>>>> document can be found at:
>>>>=20
>>>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
>>>>=20
>>>> Please review the latest version and please let us know any =
comments or
>>>> suggestions. TCPM needs reviews to ensure that the content is ready =
to
>>>> move forward. Feedback supporting publication ("+1") is also very =
welcome.
>>>>=20
>>>> Thanks
>>>>=20
>>>> Michael, on behalf of the TCPM chairs
>>>=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
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Fri Jun 26 09:26:34 2020
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 88ED53A0997 for ; Fri, 26 Jun 2020 09:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level: 
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 U9v6cbyqBYpO for ; Fri, 26 Jun 2020 09:26:30 -0700 (PDT)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 C63463A0983 for ; Fri, 26 Jun 2020 09:26:29 -0700 (PDT)
Received: by mail-vs1-xe2c.google.com with SMTP id f24so5819995vsg.1 for ; Fri, 26 Jun 2020 09:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f4/dEyTPTVCI4K9hpnm6F38Bc7SfHYysIyRjrih7HCU=; b=SEUMyz3S2BSh1H7sQNYkuibwCuZoVGjDOPmJ/bxfQVlyVRLD4Gw8ZR6Ff2x6xA3QWf 2fwjbj0ZpZwao+s/MOIYWt2YSn7grED8/G/YsN9dwY+ypKCwFXNRWVGYS5vEd+OCPQ0k sZ/Q3e+yLwieB21qB9tizNeiUYmdFE+Gha3HSJlOoqJUMlyngtEJ+yxePnsPlRBRucMp BxvZoDag96KlqnBm72R1s8ntx6chkX8MJB2LUC7qcTzcxUSpfwgZd8X/Xz1okWPbdClT XIcWeecTLi4PKTFlK6nqqJCv6KgMAiWO9MLTB67nWcMhA86fV77S/w+Rng8bmUlRIwbw MRBg==
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=f4/dEyTPTVCI4K9hpnm6F38Bc7SfHYysIyRjrih7HCU=; b=Ox8t2ZnYy9rTaCs7/qQEhOFscKL7hirRtJaudv0S2uBT6CtLrMnSurjZGODlErqLc1 lXyJLRwpXs5vyoOZ1nZE6xC4fLLDJ5sD3LjuNZxj690Dq3YSMAiUMrk+eHPXnnSaMPUT szmKCY3S1SEh4qMhBIzsV2xchugGrhVSip7RPnMf3I0OBNMLPGlMU4GE02qPS5Nd+7/c T/7729qzT0S1n7Z/hsSPc9M85RTIiSdkjVhDDJXPyZWLhrQrzixVa9DC+46hIlcJUnKy uhLfleGtWpua1rZWZ4j+7PuIKH+351/hr3WxzYlpVNqJwyV6X8DQxQ4+dJFkcm4Eh/7s 3icA==
X-Gm-Message-State: AOAM533Ihve0AtqFT1+GWMs0tfs7KxV7RYfNNv3RzTWUSS5ADdQ545FK mK93uJVhKseVNtaUGkj2d8hiJkig7TDG2n16g/UUgSJsQ0A=
X-Google-Smtp-Source: ABdhPJxFOo9h4Svn96Tqy4BHet41GGvLEi5pdr/+IFANk1a6glKevnwC2qsK41O2o1XRXf713PyRQEd+bThxXdgg0L4=
X-Received: by 2002:a67:c011:: with SMTP id v17mr3520531vsi.56.1593188788419;  Fri, 26 Jun 2020 09:26:28 -0700 (PDT)
MIME-Version: 1.0
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de> <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com>  
In-Reply-To: 
From: Yuchung Cheng 
Date: Fri, 26 Jun 2020 09:25:52 -0700
Message-ID: 
To: Joseph Touch 
Cc: "tcpm@ietf.org" , tcpm-chairs 
Content-Type: multipart/alternative; boundary="000000000000cbba4705a8ff2b87"
Archived-At: 
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis
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, 26 Jun 2020 16:26:33 -0000

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

Thanks. How about

"Because this is similar to the case
   when a connection becomes idle, mechanisms that address idle TCP
   connections (e.g., [RFC7661]) could also be applied to TCB cache
   management such as TCP Fast Open [RFC7413] (Section 7.2)"

I think it'll help readers find the context quicker by citing the section
directly.


On Fri, Jun 26, 2020 at 8:04 AM Joseph Touch  wrote:

> Yi, Yuchung,
>
> The text was introduced in the draft-touch-tcpm-2140bis-05 version in Sep=
t
> 2018.
>
> It relates to the way in which 2140 would handle the effect of idle
> connections and how that information becomes invalid over time as long as
> the connection is idle.
>
> I.e., the idea is that 2140 could help TFP avoid bursting into the net
> more aggressively rather than backing down, as discussed in Sec 7.2 of RF=
C
> 7413.
>
> If our interpretation or the text would benefit from revision, please
> suggest alternate text.
>
> Joe
>
> > On Jun 25, 2020, at 2:02 PM, Yuchung Cheng  40google.com@dmarc.ietf.org> wrote:
> >
> > On
> > "Because this is similar to the case
> >   when a connection becomes idle, mechanisms that address idle TCP
> >   connections (e.g., [RFC7661]) could also be applied to TCB cache
> >   management, especially when TCP Fast Open is used [RFC7413]"
> >
> > Why do TFO-started idle connections benefit this particularly?
> >
> >
> > On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch 
> wrote:
> >>
> >> I=E2=80=99m guessing the views of the authors is gratuitous, but to at=
 least be
> explicit:
> >>
> >> +1
> >>
> >> Joe
> >>
> >>> On Jun 12, 2020, at 2:56 AM, Scharf, Michael <
> Michael.Scharf@hs-esslingen.de> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I haven't seen any reply so far. Lack of _any_ feedback is not a
> particularly good sign.
> >>>
> >>> Anyway, no feedback implies that the document is ready to move
> forward. However, even in that case explicit support for publication  wou=
ld
> be _really_ useful. A simple "+1" could be enough...
> >>>
> >>> I'll extend the WGLC by one week until June 21 to give the community
> some additional time to comment.
> >>>
> >>> Thanks
> >>>
> >>> Michael
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Scharf, Michael 
> >>>> Sent: Saturday, May 30, 2020 8:06 PM
> >>>> To: tcpm@ietf.org
> >>>> Cc: tcpm-chairs 
> >>>> Subject: WGLC for draft-ietf-tcpm-2140bis
> >>>>
> >>>> Hi all,
> >>>>
> >>>> The document "TCP Control Block Interdependence" (draft-ietf-tcpm-
> >>>> 2140bis) is out there for a quite some time already. Given that ther=
e
> has
> >>>> been a bit less activity on the list after the interim, let's use
> this opportunity
> >>>> to finish one of our milestones...
> >>>>
> >>>> This e-mail starts a WGLG for the document draft-ietf-tcpm-2140bis.
> The
> >>>> WGLC will run until ***June 14***.
> >>>>
> >>>> The intended status is an informational RFC. The current version of
> the
> >>>> document can be found at:
> >>>>
> >>>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05
> >>>>
> >>>> Please review the latest version and please let us know any comments
> or
> >>>> suggestions. TCPM needs reviews to ensure that the content is ready =
to
> >>>> move forward. Feedback supporting publication ("+1") is also very
> welcome.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Michael, on behalf of the TCPM chairs
> >>>
> >>> _______________________________________________
> >>> tcpm mailing list
> >>> tcpm@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >>
> >> _______________________________________________
> >> tcpm mailing list
> >> tcpm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tcpm
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>
>

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


Thanks. How about=C2=A0

"Because t=
his is similar to the case
=C2=A0 =C2=A0when a connection becomes idle=
, mechanisms that address idle TCP
=C2=A0 =C2=A0connections (e.g., [RFC7=
661]) could also be applied to TCB cache
=C2=A0 =C2=A0management such as=
 TCP Fast Open [RFC7413] (Section 7.2)"

I think it&=
#39;ll help readers find the context quicker by citing the section directly=
.


On Fri, Jun 26, 2020 at 8:04 AM Joseph Touch <touch@strayalpha.com> wrote:
=

Yi, Yuchung,



The text was introduced in the draft-touch-tcpm-2140bis-05 version in Sept =
2018.



It relates to the way in which 2140 would handle the effect of idle connect=
ions and how that information becomes invalid over time as long as the conn=
ection is idle.



I.e., the idea is that 2140 could help TFP avoid bursting into the net more=
 aggressively rather than backing down, as discussed in Sec 7.2 of RFC 7413=
. 



If our interpretation or the text would benefit from revision, please sugge=
st alternate text.



Joe



> On Jun 25, 2020, at 2:02 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.=
org> wrote:

> 

> On

> "Because this is similar to the case

>=C2=A0 =C2=A0when a connection becomes idle, mechanisms that address id=
le TCP

>=C2=A0 =C2=A0connections (e.g., [RFC7661]) could also be applied to TCB=
 cache

>=C2=A0 =C2=A0management, especially when TCP Fast Open is used [RFC7413=
]"

> 

> Why do TFO-started idle connections benefit this particularly?

> 

> 

> On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch <touch@strayalpha.com> wrote:
>> 

>> I=E2=80=99m guessing the views of the authors is gratuitous, but t=
o at least be explicit:

>> 

>> +1

>> 

>> Joe

>> 

>>> On Jun 12, 2020, at 2:56 AM, Scharf, Michael <Michael.Scharf@hs-es=
slingen.de> wrote:

>>> 

>>> Hi all,

>>> 

>>> I haven't seen any reply so far. Lack of _any_ feedback is=
 not a particularly good sign.

>>> 

>>> Anyway, no feedback implies that the document is ready to move=
 forward. However, even in that case explicit support for publication=C2=A0=
 would be _really_ useful. A simple "+1" could be enough...

>>> 

>>> I'll extend the WGLC by one week until June 21 to give the=
 community some additional time to comment.

>>> 

>>> Thanks

>>> 

>>> Michael

>>> 

>>> 

>>>> -----Original Message-----

>>>> From: Scharf, Michael <Michael.Scharf@hs-esslingen.de><=
br>
>>>> Sent: Saturday, May 30, 2020 8:06 PM

>>>> To: tcp=
m@ietf.org

>>>> Cc: tcpm-chairs <tcpm-chairs@ietf.org>

>>>> Subject: WGLC for draft-ietf-tcpm-2140bis

>>>> 

>>>> Hi all,

>>>> 

>>>> The document "TCP Control Block Interdependence"=
 (draft-ietf-tcpm-

>>>> 2140bis) is out there for a quite some time already. Given=
 that there has

>>>> been a bit less activity on the list after the interim, le=
t's use this opportunity

>>>> to finish one of our milestones...

>>>> 

>>>> This e-mail starts a WGLG for the document draft-ietf-tcpm=
-2140bis. The

>>>> WGLC will run until ***June 14***.

>>>> 

>>>> The intended status is an informational RFC. The current v=
ersion of the

>>>> document can be found at:

>>>> 

>>>> https://tools.ietf.org/html/d=
raft-ietf-tcpm-2140bis-05

>>>> 

>>>> Please review the latest version and please let us know an=
y comments or

>>>> suggestions. TCPM needs reviews to ensure that the content=
 is ready to

>>>> move forward. Feedback supporting publication ("+1&qu=
ot;) is also very welcome.

>>>> 

>>>> Thanks

>>>> 

>>>> Michael, on behalf of the TCPM chairs

>>> 

>>> _______________________________________________

>>> tcpm mailing list

>>> tcpm@ietf.o=
rg

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

>> 

>> _______________________________________________

>> tcpm mailing list

>> tcpm@ietf.org

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

> _______________________________________________

> tcpm mailing list

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






--000000000000cbba4705a8ff2b87--


From nobody Fri Jun 26 18:01:01 2020
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 CDF143A07D1; Fri, 26 Jun 2020 18:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=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 0PaMLakvX8ku; Fri, 26 Jun 2020 18:00:58 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.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 123203A07C0; Fri, 26 Jun 2020 18:00:57 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gfw1p+zZz7hu9A8EeVctbg9K6Wz9KxRfG3N2Ay+ijdM=; b=4eBLk5QDdJYF7/O/yzdD/VXgt glPcjaxdobx/i8xTcxpeMlw+4TH+QpAAo4EA/tKBNXWUzP12MoJPXdhmbKaagWrZkZd9Q6jHTYZId v+fsyMnmWcMN9lJCNnRCmkqPpkIIrgU6cU2cnZKPdGM1/+apz7f/mG3xcc1vXQlTMkcXi2HOZsR1p b/E7MDKo1oFMJrDYFvG0cdXZf8WJEGy5qhM+JcCdR2LSAHedJz4MZKWbxh0x2bot5+AwNqcYdEGLw G+t9SMfZUbOef3jU+oDUb6SLioy57OraZH4nxwkUs6xLU7iaXH4HCqLFIyIG2+IkRQhWpaRakgVmt 9PJgEgYxw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57330 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jozDB-002149-4a; Fri, 26 Jun 2020 21:00:57 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_09DCFD2B-8E8C-4BED-943C-566353FDE908"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joseph Touch 
In-Reply-To: 
Date: Fri, 26 Jun 2020 18:00:49 -0700
Cc: "tcpm@ietf.org" , tcpm-chairs 
Message-Id: <38FD8238-3AC2-4AF3-AA1E-598C44732647@strayalpha.com>
References: <6EC6417807D9754DA64F3087E2E2E03E2DC2102A@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DC42F0C@rznt8114.rznt.rzdir.fht-esslingen.de> <0571E11B-0983-4E56-A044-9F6A8F9F94B8@strayalpha.com>   
To: Yuchung Cheng 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
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] WGLC for draft-ietf-tcpm-2140bis
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: Sat, 27 Jun 2020 01:01:00 -0000

--Apple-Mail=_09DCFD2B-8E8C-4BED-943C-566353FDE908
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

AOK - thanks, will do.

Joe

> On Jun 26, 2020, at 9:25 AM, Yuchung Cheng  wrote:
>=20
> Thanks. How about=20
>=20
> "Because this is similar to the case
>    when a connection becomes idle, mechanisms that address idle TCP
>    connections (e.g., [RFC7661]) could also be applied to TCB cache
>    management such as TCP Fast Open [RFC7413] (Section 7.2)"
>=20
> I think it'll help readers find the context quicker by citing the =
section directly.
>=20
>=20
> On Fri, Jun 26, 2020 at 8:04 AM Joseph Touch > wrote:
> Yi, Yuchung,
>=20
> The text was introduced in the draft-touch-tcpm-2140bis-05 version in =
Sept 2018.
>=20
> It relates to the way in which 2140 would handle the effect of idle =
connections and how that information becomes invalid over time as long =
as the connection is idle.
>=20
> I.e., the idea is that 2140 could help TFP avoid bursting into the net =
more aggressively rather than backing down, as discussed in Sec 7.2 of =
RFC 7413.=20
>=20
> If our interpretation or the text would benefit from revision, please =
suggest alternate text.
>=20
> Joe
>=20
> > On Jun 25, 2020, at 2:02 PM, Yuchung Cheng =
> wrote:
> >=20
> > On
> > "Because this is similar to the case
> >   when a connection becomes idle, mechanisms that address idle TCP
> >   connections (e.g., [RFC7661]) could also be applied to TCB cache
> >   management, especially when TCP Fast Open is used [RFC7413]"
> >=20
> > Why do TFO-started idle connections benefit this particularly?
> >=20
> >=20
> > On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch > wrote:
> >>=20
> >> I=E2=80=99m guessing the views of the authors is gratuitous, but to =
at least be explicit:
> >>=20
> >> +1
> >>=20
> >> Joe
> >>=20
> >>> On Jun 12, 2020, at 2:56 AM, Scharf, Michael =
> =
wrote:
> >>>=20
> >>> Hi all,
> >>>=20
> >>> I haven't seen any reply so far. Lack of _any_ feedback is not a =
particularly good sign.
> >>>=20
> >>> Anyway, no feedback implies that the document is ready to move =
forward. However, even in that case explicit support for publication  =
would be _really_ useful. A simple "+1" could be enough...
> >>>=20
> >>> I'll extend the WGLC by one week until June 21 to give the =
community some additional time to comment.
> >>>=20
> >>> Thanks
> >>>=20
> >>> Michael
> >>>=20
> >>>=20
> >>>> -----Original Message-----
> >>>> From: Scharf, Michael >
> >>>> Sent: Saturday, May 30, 2020 8:06 PM
> >>>> To: tcpm@ietf.org 
> >>>> Cc: tcpm-chairs >
> >>>> Subject: WGLC for draft-ietf-tcpm-2140bis
> >>>>=20
> >>>> Hi all,
> >>>>=20
> >>>> The document "TCP Control Block Interdependence" =
(draft-ietf-tcpm-
> >>>> 2140bis) is out there for a quite some time already. Given that =
there has
> >>>> been a bit less activity on the list after the interim, let's use =
this opportunity
> >>>> to finish one of our milestones...
> >>>>=20
> >>>> This e-mail starts a WGLG for the document =
draft-ietf-tcpm-2140bis. The
> >>>> WGLC will run until ***June 14***.
> >>>>=20
> >>>> The intended status is an informational RFC. The current version =
of the
> >>>> document can be found at:
> >>>>=20
> >>>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05 =

> >>>>=20
> >>>> Please review the latest version and please let us know any =
comments or
> >>>> suggestions. TCPM needs reviews to ensure that the content is =
ready to
> >>>> move forward. Feedback supporting publication ("+1") is also very =
welcome.
> >>>>=20
> >>>> Thanks
> >>>>=20
> >>>> Michael, on behalf of the TCPM chairs
> >>>=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 =

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

>=20


--Apple-Mail=_09DCFD2B-8E8C-4BED-943C-566353FDE908
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

AOK =
- thanks, will do.

Joe

On Jun 26, 2020, at 9:25 AM, Yuchung Cheng =
<ycheng@google.com> wrote:

Thanks. How about 

"Because this is similar to the =
case
   when a connection becomes idle, mechanisms that =
address idle TCP
   connections (e.g., =
[RFC7661]) could also be applied to TCB cache
  =
 management such as TCP Fast Open [RFC7413] (Section 7.2)"

I think it'll help =
readers find the context quicker by citing the section =
directly.


On Fri, Jun 26, 2020 at 8:04 AM Joseph Touch <touch@strayalpha.com> wrote:
Yi, Yuchung,



The text was introduced in the draft-touch-tcpm-2140bis-05 version in =
Sept 2018.



It relates to the way in which 2140 would handle the effect of idle =
connections and how that information becomes invalid over time as long =
as the connection is idle.



I.e., the idea is that 2140 could help TFP avoid bursting into the net =
more aggressively rather than backing down, as discussed in Sec 7.2 of =
RFC 7413. 



If our interpretation or the text would benefit from revision, please =
suggest alternate text.



Joe



> On Jun 25, 2020, at 2:02 PM, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:

> 

> On

> "Because this is similar to the case

>   when a connection becomes idle, mechanisms that address =
idle TCP

>   connections (e.g., [RFC7661]) could also be applied to =
TCB cache

>   management, especially when TCP Fast Open is used =
[RFC7413]"

> 

> Why do TFO-started idle connections benefit this particularly?

> 

> 

> On Fri, Jun 12, 2020 at 12:40 PM Joseph Touch <touch@strayalpha.com> wrote:

>> 

>> I=E2=80=99m guessing the views of the authors is gratuitous, =
but to at least be explicit:

>> 

>> +1

>> 

>> Joe

>> 

>>> On Jun 12, 2020, at 2:56 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

>>> 

>>> Hi all,

>>> 

>>> I haven't seen any reply so far. Lack of _any_ feedback is =
not a particularly good sign.

>>> 

>>> Anyway, no feedback implies that the document is ready to =
move forward. However, even in that case explicit support for =
publication  would be _really_ useful. A simple "+1" could be =
enough...

>>> 

>>> I'll extend the WGLC by one week until June 21 to give the =
community some additional time to comment.

>>> 

>>> Thanks

>>> 

>>> Michael

>>> 

>>> 

>>>> -----Original Message-----

>>>> From: Scharf, Michael <Michael.Scharf@hs-esslingen.de>

>>>> Sent: Saturday, May 30, 2020 8:06 PM

>>>> To: tcpm@ietf.org

>>>> Cc: tcpm-chairs <tcpm-chairs@ietf.org>

>>>> Subject: WGLC for draft-ietf-tcpm-2140bis

>>>> 

>>>> Hi all,

>>>> 

>>>> The document "TCP Control Block Interdependence" =
(draft-ietf-tcpm-

>>>> 2140bis) is out there for a quite some time already. =
Given that there has

>>>> been a bit less activity on the list after the interim, =
let's use this opportunity

>>>> to finish one of our milestones...

>>>> 

>>>> This e-mail starts a WGLG for the document =
draft-ietf-tcpm-2140bis. The

>>>> WGLC will run until ***June 14***.

>>>> 

>>>> The intended status is an informational RFC. The =
current version of the

>>>> document can be found at:

>>>> 

>>>> https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05

>>>> 

>>>> Please review the latest version and please let us know =
any comments or

>>>> suggestions. TCPM needs reviews to ensure that the =
content is ready to

>>>> move forward. Feedback supporting publication ("+1") is =
also very welcome.

>>>> 

>>>> Thanks

>>>> 

>>>> Michael, on behalf of the TCPM chairs

>>> 

>>> _______________________________________________

>>> tcpm mailing list

>>> tcpm@ietf.org

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

>> 

>> _______________________________________________

>> tcpm mailing list

>> tcpm@ietf.org

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

> 

> _______________________________________________

> tcpm mailing list

> tcpm@ietf.org

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







=

--Apple-Mail=_09DCFD2B-8E8C-4BED-943C-566353FDE908--


From nobody Tue Jun 30 06:48:18 2020
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 0F7813A0879; Tue, 30 Jun 2020 06:48:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Wesley Eddy via Datatracker 
To: 
Cc: tcpm@ietf.org, last-call@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159352488802.13614.9978604383483503310@ietfa.amsl.com>
Reply-To: Wesley Eddy 
Date: Tue, 30 Jun 2020 06:48:08 -0700
Archived-At: 
Subject: [tcpm] Iotdir telechat review of draft-ietf-tcpm-rto-consider-16
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Jun 2020 13:48:08 -0000

Reviewer: Wesley Eddy
Review result: Ready

This document is clear and easy to understand.

>From an IoT perspective, I don't have any specific concerns with it.  The CoAP
spec (RFC 7522) was written referencing an early version of this I-D, so it has
already been applied for designing IoT protocols.

There are a couple of small typos:
- In Section 4 part (1), there is a typo "an some" should just be one of those
words. - In Section 4 part (2), there is a typo "is is".