From nobody Wed Apr 1 00:30:19 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 B8BCF3A0ED3 for ; Wed, 1 Apr 2020 00:30:17 -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 hm66sztt9e4r for ; Wed, 1 Apr 2020 00:30:16 -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 215973A0ED1 for ; Wed, 1 Apr 2020 00:30:16 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id b12so5407418wmj.3 for ; Wed, 01 Apr 2020 00:30:16 -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=g8SdbobSAB7re0MG2OL+qOcb4GKFfzNhsoeHjv+cOqA=; b=lGWeMsbGO/EA626If+5+LLwHMEpmYmaW1tkpR9xC3IOMvGR5GGejoJdRRnhyrjJ/BX zwcVLk5buBOd3nwTIrd8VkurXUWvsyRe/FxBKCN0m2vxbRMrFc9fgRRs9yJDrRmDaNiP fA0pWuqvdVuWA6qG9ierYvWiOsJ8Ii4OJKf3sRiflSM9+VaWDRh58IsCSrb+hdpARDbl iuiBPXP3yoaq+K9S8ZZb+VUBVFI9ggmL+Urknhkjv2bMeJdGp1xjeIUZN0uKbGz7GU3B zI7WhTR5iwHSLHKEPdfuABjX2Wl53Ao73ejs05T8rCaZM3yNw9vtHPT0UvD5v0VD/QWl hMjg== 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=g8SdbobSAB7re0MG2OL+qOcb4GKFfzNhsoeHjv+cOqA=; b=Gj+BjLG+wxWzhn5Afy0GDTOfL5ePN+ZyiWBoOlHo9OxAUKu+DzAMH7cgnacSogfH5R g7Y21NeZ9xR8xvrn1kf5Awq9KFtFjxFt3+/1Isat7GWfWv5W49Tp1E24tBX0XC+i3zYs fjG8wmGp96MRJ0vfsxFzM47+ERqwKc2WTIweesiwO5Nl7mvrvjH4ijJKXTDawdnCfOVZ 3F8pS+ehxPyDtX2tsX6yaUK7d1GWHwZvCAeSWYLPlZ7q4EdhTL73g5rBnNOAsiqudYki 5jFBpiLp3Ig91AxgDq/wCFYiPKETDYI6Gp0qgYWuHrUp1We6Lm/MxwH+Ct45xU7MvU32 PowA== X-Gm-Message-State: AGi0Pua/wNgsA7vEzisQAdNtOcGs+MvBrPbdTDv1keZ/VBPBh31bAS8O 1srZPqDKmIDRbkacQvUW41TCu7bpV4Lj5atSJJZUdLel X-Google-Smtp-Source: APiQypIhUE2fbekljXA43/z5ygnKq+GRkaSK2md+Yslh2LoXdpeKjSACkEkSTIPPIXYylGYiNQ2H+qBTbtJHmVMzRsM= X-Received: by 2002:a7b:c18e:: with SMTP id y14mr2689150wmi.99.1585726214543; Wed, 01 Apr 2020 00:30:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: juhamatk@gmail.com Date: Wed, 1 Apr 2020 10:30:02 +0300 Message-ID: To: Joseph Touch Cc: tcpm@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Wed, 01 Apr 2020 07:30:18 -0000 Hello Joe, > At best, those might be an addendum to RFC 5926. RFC 5925 deliberately does not specify any algorithms. Thanks for your reply. Addendum to RFC 5926 sounds really good to me. > However, TCP MD5 was widely deployed without any such test vectors in the RFC series (or elsewhere I could find, FWIW). True. Still, RFC 2385 is only 4 pages long and implementation is very simple. It had wide deployment from the beginning, I believe, so it was easy to make implementations match. I am currently working on a proprietary implementation of RFC 5925/5926. Even though the RFCs are ten years old, they have only a few existing implementations. Test equipment vendors (IXIA, Spirent) do not support it. Juniper does not use it, they seem to use their own proprietary version. One fuzzing vendor seems to have HMAC-SHA1 implemented, but it is unclear is it according to the RFCs. Guaranteeing interop looks quite difficult at the moment. So if test vectors already exist somewhere (maybe unpublished), or someone is willing to create them for the addendum draft referenced above, I am certainly willing to verify them against my implementation and report back. > Joe Thanks, -- Juhamatti > > > On Mar 31, 2020, at 3:44 AM, juhamatk@gmail.com wrote: > > > > Hello, > > > > I have been searching for test vectors for RFC5925/5926 algorithms for > > TCP AO and to my surprise it seems that such do not exist. Am I > > correct here? > > > > Even though test vectors for HMAC SHA1 (RFC2202) and AES CMAC > > (RFC4493) are available, it would be useful to have example test > > vectors for frames using TCP AO - otherwise implementations end up > > easily not to match. As RFC5925 is 47 pages, there is a room for error > > and only one mismatch is needed for MACs not to match. > > > > I think publishing a new RFC for them would be good, but probably > > takes some time. Even unofficial, but verified, test vectors on some > > specified example frames (with and without TCP options), e.g. on this > > mailing list or otherwise, would be a very good start to get TCP AO > > more widely implemented. If such already are available somewhere, > > please do let me know. > > > > Thanks, > > -- > > Juhamatti > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Apr 1 00:43: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 CFC2A3A0F1B for ; Wed, 1 Apr 2020 00:43: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 M5xuL4TK57Bo for ; Wed, 1 Apr 2020 00:43:03 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 831C83A0F0D for ; Wed, 1 Apr 2020 00:43:03 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id o15so8720060ual.3 for ; Wed, 01 Apr 2020 00:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=v6YeJke6jVR6LdqJLdN7Y+/x/tX8SROCRu+LnDqP0EU=; b=SWVs0hbIydYJ4NpH+G/3Pl4JAhz4Ou1FXjHXKj37/Z0daSUCPDSolU9ePYSmPqBU3Q 3bFNtEhUn08/LDPkazZV3TWBnHSCzir55+noxlQrSBEbBt0gX44bBHe6h0vGzePidiIn UrLOE797vqZXlanmp0+eZrEqjkDzKhRnMTViF9yV3S/FPmScwwgUNcOk2AppEXidN87e Fb5l5lLe+sj7cLnYrddiEB50RKCkb109NEcre7k5yimVaH/IwmJxLpkEmZVg5EXX998N peJ8qFF82kr0mvOf8PYL1iBlN1yTOK1JIrmHWdg0I9gafM4xx7NaSGS0Cpd/S11CYTMp 3iBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=v6YeJke6jVR6LdqJLdN7Y+/x/tX8SROCRu+LnDqP0EU=; b=b23jZ9LaXYsi8DlJRwkK4IFElrN+vZYZnk/GHbq1wZZPyfyK/68i+x77UHEYmbfDtv 5GHH8BoUh30WECtBYJfvam/n1KIZGhnJGzrogQXblg4dW9Ten9dcqJ5Ysf9W5m+7efM0 u1dkGaV2zzT9LVWv2GEkjaSrK4OLSTVoMlHkJEUGlRoxL4+XP2KcsREckGg8X6XlycJF A6PX5ce03pENT5UZg84VPnUEPzhmB80P+vEnIHGz06bV5IDgFsGpN0oo2hRfgG5nsCzI heIaA2wqig8TxyPFOUDduMXvNm96l8gh2GdMDN6I6ahTMKqSxwq63nXxt8PrgmOvj5mb MojQ== X-Gm-Message-State: AGi0PuaOTPSUsmV6kYghm3Fm1NsbJhGIszPNTY180ZrHoNVQ9cHvAtPM K2yP0Ak5Q9mhGyxfHxkfNILRsMkdoUkBL5jBr9IQZvJz X-Google-Smtp-Source: APiQypLLKnQlOJJE+XQrwWmuUKusVsQhnVW0unI1Xf2bD7JGh182Gw4Q22PTyLTDAm9DbD8PvVNi0jXW0c+iCy5RbDk= X-Received: by 2002:ab0:2e:: with SMTP id 43mr6530771uai.36.1585726982139; Wed, 01 Apr 2020 00:43:02 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Wed, 1 Apr 2020 00:42:51 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000007b56c405a235d5ed" Archived-At: Subject: [tcpm] WGLC for draft-ietf-tcpm-rto-consider 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, 01 Apr 2020 07:43:05 -0000 --0000000000007b56c405a235d5ed Content-Type: text/plain; charset="UTF-8" Hello folks, This email initiates the WGLC for https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10 Please send your feedback to the ML. The WGLC for this draft runs until * Wednesday April 22 *. For your information, the intended status of the draft is BCP. We appreciate your cooperation! Thanks, -- tcpm-chairs --0000000000007b56c405a235d5ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello folks,

T= his email initiates the WGLC for=C2=A0https://tools.ietf.org/html/draft-ietf-t= cpm-rto-consider-10
Please send your feedback to the ML.
<= div>
The=C2=A0WGLC=C2=A0for this = draft runs until * Wednesday April 22 *.=C2=A0

For your information, the intended status of the draft is BCP.
<= div>We appreciate your cooperation!

Thanks,<= /div>
--
tcpm-chairs



--0000000000007b56c405a235d5ed-- From nobody Wed Apr 1 01:03: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 0A2493A0F75 for ; Wed, 1 Apr 2020 01:03:50 -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 Kfg1o96dNCK7 for ; Wed, 1 Apr 2020 01:03:48 -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 EDBDC3A0F7F for ; Wed, 1 Apr 2020 01:03:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 15AAE25A1C; Wed, 1 Apr 2020 10:03:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1585728226; bh=ERqLwRZQ4n+IhaqLbFada2dRKXETcH/bF6vSXmyaeF0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=TBA5cmwnLR8o9TvTVOQ6xSrVi7a7SdJ77qdLF+QYdV40GutxndcMVpxrzeUuwdEqZ pepfgSm/5fXoxCij6/MT8zcQDQ/iMwBaMZwV+txf53anXrHvTHlRA5FYUXQiI/465U k2RojlhfXyg0pWjv6qJJBE5EuDjE6F49c4kC5cFk= 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 wd8AZlnRcQMN; Wed, 1 Apr 2020 10:03:44 +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; Wed, 1 Apr 2020 10:03:44 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 1 Apr 2020 10:03:44 +0200 From: "Scharf, Michael" To: "juhamatk@gmail.com" , Joseph Touch CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Test vectors for RFC5925 algorithms? Thread-Index: AQHWB0lfUk5cDvT0M0+o4ytgvsbwRKhi6ecAgADUtQCAACc4sA== Date: Wed, 1 Apr 2020 08:03:43 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Wed, 01 Apr 2020 08:03:50 -0000 Have you checked other router vendors? For instance, the public Cisco IOS X= E documentation lists TCP-AO support. And I have also heard that another ma= in router vendor may implement TCP-AO (well, I am not familiar with Juniper= ).=20 BTW, if there is some gap in the RFC series, the usual IETF process is just= starting a new Internet-Draft, instead of waiting for somebody else to wri= te something. It is not complex to write an Internet Draft. And TCPM is usu= ally quite open to new work. Michael > -----Original Message----- > From: tcpm On Behalf Of juhamatk@gmail.com > Sent: Wednesday, April 1, 2020 9:30 AM > To: Joseph Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Test vectors for RFC5925 algorithms? >=20 > Hello Joe, >=20 > > At best, those might be an addendum to RFC 5926. RFC 5925 deliberately > does not specify any algorithms. >=20 > Thanks for your reply. Addendum to RFC 5926 sounds really good to me. >=20 > > However, TCP MD5 was widely deployed without any such test vectors in t= he > RFC series (or elsewhere I could find, FWIW). >=20 > True. Still, RFC 2385 is only 4 pages long and implementation is very > simple. It had wide deployment from the beginning, I believe, so it > was easy to make implementations match. >=20 > I am currently working on a proprietary implementation of RFC > 5925/5926. Even though the RFCs are ten years old, they have only a > few existing implementations. Test equipment vendors (IXIA, Spirent) > do not support it. Juniper does not use it, they seem to use their own > proprietary version. One fuzzing vendor seems to have HMAC-SHA1 > implemented, but it is unclear is it according to the RFCs. > Guaranteeing interop looks quite difficult at the moment. >=20 > So if test vectors already exist somewhere (maybe unpublished), or > someone is willing to create them for the addendum draft referenced > above, I am certainly willing to verify them against my implementation > and report back. >=20 > > Joe >=20 > Thanks, > -- > Juhamatti >=20 > > > > > On Mar 31, 2020, at 3:44 AM, juhamatk@gmail.com wrote: > > > > > > Hello, > > > > > > I have been searching for test vectors for RFC5925/5926 algorithms fo= r > > > TCP AO and to my surprise it seems that such do not exist. Am I > > > correct here? > > > > > > Even though test vectors for HMAC SHA1 (RFC2202) and AES CMAC > > > (RFC4493) are available, it would be useful to have example test > > > vectors for frames using TCP AO - otherwise implementations end up > > > easily not to match. As RFC5925 is 47 pages, there is a room for erro= r > > > and only one mismatch is needed for MACs not to match. > > > > > > I think publishing a new RFC for them would be good, but probably > > > takes some time. Even unofficial, but verified, test vectors on some > > > specified example frames (with and without TCP options), e.g. on this > > > mailing list or otherwise, would be a very good start to get TCP AO > > > more widely implemented. If such already are available somewhere, > > > please do let me know. > > > > > > Thanks, > > > -- > > > Juhamatti > > > > > > _______________________________________________ > > > 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 Wed Apr 1 16:15: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 324D73A12E9 for ; Wed, 1 Apr 2020 16:15:51 -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, HTML_MESSAGE=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 9g7T_1TMs40J for ; Wed, 1 Apr 2020 16:15:45 -0700 (PDT) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 EE77B3A12FB for ; Wed, 1 Apr 2020 16:15:44 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id s194so372762vkb.11 for ; Wed, 01 Apr 2020 16:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=pGCSqSnKDXViiaMQXz2ueINcEmF0cCtjWau7/Gfy1xI=; b=Y8iJJADZzChT0alJ8J+FR0jj6urqV029BhxlWQ+UnPj1r/Hrp/+78+3/zFlOE6uQaK fSkMvzlu5isPi1WJsGQQOx4vmBaakiE3oWeNNXm7X1WifNxwydSVymVtiBIOMrh+692A LWifQBw5xY54yKjsUMY6yP+NzRCc3b+9OxCPVUdN/qDuufyCu6UD2NxB9Fbyc+WAJFg4 SfymMuUTaWcaI/Io8eEAWokvl0O95AY79/VE8Psmalr+qImvNQdan4BZdCMooqo1Pclz Omk6nc3NNJKXl7X4mbDxzKpMuj/pquvsTDt/YBMIGQExacvCaBXtY41BwAYej0STyxEc Kx/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pGCSqSnKDXViiaMQXz2ueINcEmF0cCtjWau7/Gfy1xI=; b=UvwP7qQ3i+E3ARtSsRqmXadQ7M9hq0CdCuFIS2wozRWo6SiNiLDaKyIRggw1tKgkR8 CNbli0pJtpE3OUYRnwNW07gIx0U5j3zeR4OvG0mjh0R+rcUf4GAjJEshBSjMZzBouSNk mVZx6y15c0t5jup6rIg5TqR6/qyNFqcOHlPnPTy0E9ZP9FOPgLssC10u+Ac3BRLfcRsM fzpk5DxwBMGmT/lG1VhGT/q0zpc7Lx3EWlXpe6sXIr6196HFavin//1S7JRRkztsAmhc ++ffMZf9yyVMDqi8xb8bJloVo+OaZzwVvCD9KZEw5dYE05nAd/ZkmIy7PUULhMcxw4Is Hczw== X-Gm-Message-State: AGi0PubmesyjSUeU0XIjvRVk7rpIlgionu0+a5srmilwh5cntGVndhD1 nKSCE1tF5c+N70CDhijPbarukJsQY7ostEd8qZk= X-Google-Smtp-Source: APiQypLAYgx5/rxxWkLM/2lxiGidNscHKPB8vAhW3pnjk2EuuaY3EYtR/zzi0fm2VRElUuoDf9RGk6ghX24jvNE45x8= X-Received: by 2002:a1f:1786:: with SMTP id 128mr260652vkx.26.1585782943729; Wed, 01 Apr 2020 16:15:43 -0700 (PDT) MIME-Version: 1.0 From: Junho Choi Date: Wed, 1 Apr 2020 16:15:07 -0700 Message-ID: To: pravb@microsoft.com, huanyi@microsoft.com Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d4efe05a242dd60" Archived-At: Subject: [tcpm] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 23:15:51 -0000 --0000000000000d4efe05a242dd60 Content-Type: text/plain; charset="UTF-8" Hi, I am working on QUIC implementation (https://github.com/cloudflare/quiche) at Cloudflare. While I am researching on hystart, I came across HyStart++ recently and I think this is a reasonable replacement of original hystart, so I started the work based on the hystartplusplus draft 02. This is about quic implementation but it's more general questions, so I am posting here. While I am implementing it, I have a few questions: 1. Section 4.2 -- each round is initialized as lastRoundMinRTT = currentRoundMinRTT currentRoundMinRTT = infinity rttSampleCount = 0 In the very beginning of the connection, what is "currentRoundMinRTT" when there is no previous value? I am using current rtt (or initial rtt value) and is it ok? 2. Section 4.2 -- When used with cubic, CA_cwnd() is based on cubic algorithm I think. This means I need to do cubic variables calculation during slow start such as K and W_cubic. When is considered as a start of congestion avoidance and what W_max will be? Currently I use a start of limited slow start as a beginning of congestion recovery and use cwnd at the time for W_max. Is my understanding correct? Best, -- Junho Choi --0000000000000d4efe05a242dd60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




In the very beginning of the connection, what is "= ;currentRoundMinRTT" when
there is no previous value?
<= div>
I am using current rtt (or initial rtt value) and is it = ok?

2. Section 4.2 -- When used with cubic, CA_cwn= d() is based on cubic algorithm I think.
=C2=A0This means I need = to do cubic variables calculation during slow start
=C2=A0such as= K and W_cubic. When is considered as a start of
=C2=A0congestion= avoidance and what W_max will be?

=C2=A0Currently= I use a start of limited slow start as a beginning of congestion recovery<= /div>
=C2=A0and use cwnd at the time for W_max. Is my understanding cor= rect?

Best,

--
--0000000000000d4efe05a242dd60-- From nobody Wed Apr 1 17:04:41 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 E12A63A14A8 for ; Wed, 1 Apr 2020 17:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=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=microsoft.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 gJOgcX2mQAyJ for ; Wed, 1 Apr 2020 17:04:37 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650132.outbound.protection.outlook.com [40.107.65.132]) (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 C349A3A14A6 for ; Wed, 1 Apr 2020 17:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWVruidcVHvTIcPKh2zypCQN76P6iID2mo7r77GqJGJSyUxpnE5brkJeKn+v2Ty2pHaa8wB1gMBx7DHsiEetqF6PcGAIDzXEzz/VOyL9ChmZztq7XwGHL7ezGQo8LHhU9R/jP+ty9jD3sxMF5uWctOXGjEc0VF7pIESWwCmFNA2v+wOe7lbEDmyR7xpcAX0AP1wEMpfO8jX6JkXU539UqU2HywPxDkryHfBUyfYFecgFS4csx6+aNiBmsUNP/dhLwMbb+9YtCbE6Sf05nRkqDgE+yVPIHwWUlpb6HacsybwR+yIfnYPian+DZEIkcuF/QW+7nXhzjTEiot/LGs4DLw== 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=mzr6nP3Q7RSC2MN4sofK7CWSdBLnTWXOe1kvaXPm704=; b=D3nTN72z6lZYujFH+2u5H2vHz8ptn1hrsvPVMfQVfm8r4+sVZ/fFRYLHBcaXhpRBezL9XynTBE1wKvaL0CbQHF3nEL16U/fJfk7Z5aIHUiEEmSW9mOuWjy1+4suk0CayDhNE3sy0boLjd/PHLFNwvkXdd4CZBkf0hxiwclQeUbpgf2/R6QXtV3sBCmme9Ak7wxGunILNKOsDf9KvWg0+UA5Z5iYoelA+fORMjX7knvtpgpZ9pmOPjucicazOLGUbymFgOXiXBd9IXZBGHP/9QXwZVHuikQthUL97/38Yo52U0lDUnuU9mpRTJn58kG9cGys/Chmqwqvx9jcttAUWvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mzr6nP3Q7RSC2MN4sofK7CWSdBLnTWXOe1kvaXPm704=; b=EtLj7zRngkwfEVFp+/FB+C/TqgqejrjEU1XKleuhYkk/v9o0ro/U3X7D65EZgxIphyorq1Nw2XQHqP/6lVFvMKeI27lxzZdS6QufwBzczhjBjP4YLP3eqcmZewTE3uVV5VynOXDz3MJvLH6VHXez07qCpySz//znEf3sJHGQZKk= Received: from SN2PR00MB0077.namprd00.prod.outlook.com (2603:10b6:804:18::21) by SN6PR00MB0448.namprd00.prod.outlook.com (2603:10b6:805:d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2912.0; Thu, 2 Apr 2020 00:04:33 +0000 Received: from SN2PR00MB0077.namprd00.prod.outlook.com ([fe80::4453:8dfd:2003:1482]) by SN2PR00MB0077.namprd00.prod.outlook.com ([fe80::4453:8dfd:2003:1482%8]) with mapi id 15.20.2918.000; Thu, 2 Apr 2020 00:04:33 +0000 From: Yi Huang To: Junho Choi , Praveen Balasubramanian CC: "tcpm@ietf.org" Thread-Topic: [EXTERNAL] Questions on HyStart++ draft 02 Thread-Index: AQHWCHuVjeyKxI/TR0GdAjicR50BCqhk60fw Date: Thu, 2 Apr 2020 00:04:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-02T00:04:31.5387818Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=74b96d98-bd77-427a-8f1a-a1f9958b76a9; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2601:600:877f:ac89:a428:b855:ae0b:b40e] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4c0d1ce1-ddd9-402d-2049-08d7d6996cb7 x-ms-traffictypediagnostic: SN6PR00MB0448:|SN6PR00MB0448: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN2PR00MB0077.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(6029001)(4636009)(366004)(346002)(136003)(376002)(396003)(39860400002)(33656002)(76116006)(110136005)(478600001)(10290500003)(8990500004)(316002)(53546011)(7696005)(186003)(6506007)(86362001)(55016002)(52536014)(81156014)(66946007)(66476007)(66556008)(9686003)(64756008)(66446008)(6636002)(5660300002)(8676002)(4326008)(9326002)(82950400001)(82960400001)(8936002)(71200400001)(81166006)(2906002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0N7uppLf3KESBCpcNSmE0MH726/YWoXdPAofqGpnx6PmGPX1dAWKWdUk8+ERMMNCes5UOGEg+8uLofVJfz2QKNBB0xBVXm3zhszL17PFatLiINIdFjgk/wbwlspOqDzQ7Xznp5NbcJJu1LODn/xYvJjoGVDIz9TdUw8FCVa5Kv7K/LII14AdqT8Q4oxBu8pPwIHl4D0+APekhDMpJEi733G0FQRuNWpm5THlsJ46eBuk6mv+LizoTIDV4G77tX8GpiRvcEverZhDG7g/KZN2eEwx2KlJaHQdL3lfJLO4LlGel9LrzVimmJAY4+Wlupvnl/x+UlDR/ssN67s0kdP4B55d68H47l4KQOIs4ki1+5POcpNFXQpsLLSGjHWthjhFwprW4SqwSMsBxTwNu3oVR2RzzE7p4cBICpfBKtT5prKC8OjWGpaoF5VoZpyVL6bvYUdJFs+fD5PWUrqHz+9xdUKq55VB59lmj5vlt4wwHDgxXnQ4celUDSLd5zKRZ3QG7sdb4GWv0/2WVPTDdEHjfw== x-ms-exchange-antispam-messagedata: IDx6cehcst+vBQ2CCEZU66t65IEVAWALCiGmLFFL44jzYFbL9XoPTrlUvDRfBHABxhV+Asq+//9Ce5KTl6qlHob40TYzUPH+WFD0RdZLW71I5VEQLrNnys+mGdXjJnZJAJr3zwdPaVKEx0XIzNpnYSTx6Ln2LwiPycUj0LQmY6sfWa07Cm7rGNZ3SF59HixN7sBO8QiAA0iOBaCTwDGBLQ== Content-Type: multipart/alternative; boundary="_000_SN2PR00MB00778599FB58D63C89C88BCCC3C60SN2PR00MB0077namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c0d1ce1-ddd9-402d-2049-08d7d6996cb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 00:04:33.6456 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: B88Lji40i4VqMvNvKw2QA+YPILujG9IGptsg4HqO2H/lR/L1ONwXKBUNAA9U7qODvk+B5HNFEt9IxhRZN/Ipfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0448 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 00:04:40 -0000 --_000_SN2PR00MB00778599FB58D63C89C88BCCC3C60SN2PR00MB0077namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVuaG8sDQoNCkkgaGF2ZSBhbnN3ZXJlZCB5b3VyIHF1ZXN0aW9ucyBpbmxpbmUuIFRoYW5r cyBmb3IgY29uc2lkZXJpbmcgSHlzdGFydCsrIGluIHlvdXIgUVVJQyBpbXBsZW1lbnRhdGlvbi4N Cg0KVGhhbmtzLA0KDQpZaQ0KDQpGcm9tOiBKdW5obyBDaG9pIDxqdW5oby5jaG9pQGdtYWlsLmNv bT4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAyMCA0OjE1IFBNDQpUbzogUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBZaSBIdWFuZyA8aHVhbnlpQG1p Y3Jvc29mdC5jb20+DQpDYzogdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBRdWVz dGlvbnMgb24gSHlTdGFydCsrIGRyYWZ0IDAyDQoNCkhpLA0KDQpJIGFtIHdvcmtpbmcgb24gUVVJ QyBpbXBsZW1lbnRhdGlvbiAoaHR0cHM6Ly9naXRodWIuY29tL2Nsb3VkZmxhcmUvcXVpY2hlPGh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRmdpdGh1Yi5jb20lMkZjbG91ZGZsYXJlJTJGcXVpY2hlJmRhdGE9MDIlN0MwMSU3Q2h1 YW55aSU0MG1pY3Jvc29mdC5jb20lN0NmOGU5Y2QxNWYwOWE0NGI3YjQ4NDA4ZDdkNjkyOWFiMiU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMTM3OTc5MDY0 NzUzMDQmc2RhdGE9R1dxTFZXTUdRalNEV0lRNFNNUmlsNk1QYXVCd1NnU2RYQzE1Wmx3biUyRjJz JTNEJnJlc2VydmVkPTA+KSBhdCBDbG91ZGZsYXJlLiBXaGlsZSBJIGFtIHJlc2VhcmNoaW5nIG9u IGh5c3RhcnQsIEkgY2FtZSBhY3Jvc3MgSHlTdGFydCsrIHJlY2VudGx5IGFuZCBJIHRoaW5rIHRo aXMgaXMgYSByZWFzb25hYmxlIHJlcGxhY2VtZW50IG9mIG9yaWdpbmFsIGh5c3RhcnQsIHNvIEkg c3RhcnRlZCB0aGUgd29yayBiYXNlZCBvbiB0aGUgaHlzdGFydHBsdXNwbHVzIGRyYWZ0IDAyLg0K DQpUaGlzIGlzIGFib3V0IHF1aWMgaW1wbGVtZW50YXRpb24gYnV0IGl0J3MgbW9yZSBnZW5lcmFs IHF1ZXN0aW9ucywgc28gSSBhbSBwb3N0aW5nIGhlcmUuDQoNCldoaWxlIEkgYW0gaW1wbGVtZW50 aW5nIGl0LCBJIGhhdmUgYSBmZXcgcXVlc3Rpb25zOg0KDQoxLiBTZWN0aW9uIDQuMiAtLSBlYWNo IHJvdW5kIGlzIGluaXRpYWxpemVkIGFzDQoNCiAgIGxhc3RSb3VuZE1pblJUVCA9IGN1cnJlbnRS b3VuZE1pblJUVA0KICAgY3VycmVudFJvdW5kTWluUlRUID0gaW5maW5pdHkNCiAgIHJ0dFNhbXBs ZUNvdW50ID0gMA0KDQpJbiB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhlIGNvbm5lY3Rpb24sIHdo YXQgaXMgImN1cnJlbnRSb3VuZE1pblJUVCIgd2hlbg0KdGhlcmUgaXMgbm8gcHJldmlvdXMgdmFs dWU/DQoNCkkgYW0gdXNpbmcgY3VycmVudCBydHQgKG9yIGluaXRpYWwgcnR0IHZhbHVlKSBhbmQg aXMgaXQgb2s/DQoNCltZaV06IEluIG91ciBpbXBsZW1lbnRhdGlvbiwgbGFzdFJvdW5kTWluUlRU IGFuZCBjdXJyZW50Um91bmRNaW5SVFQgYXJlIGluaXRpYWxpemVkIHRvIDB4ZmZmZmZmZmYgYXMg c2VudGluZWwgdmFsdWVzLiBXZSBvbmx5IGNvbXBhcmUgbGFzdFJvdW5kTWluUlRUIHdpdGggY3Vy cmVudFJvdW5kTWluUlRUIHdoZW4gYm90aCBvZiB0aGVtIGFyZSB2YWxpZCB2YWx1ZXMuIFVzaW5n IGN1cnJSVFQgc2VlbXMgdG8gZXNzZW50aWFsbHkgYmVoYXZlIHRoZSBzYW1lIGFzIGFzc2lnbmlu ZyBhIHNlbnRpbmVsIHZhbHVlLg0KDQoyLiBTZWN0aW9uIDQuMiAtLSBXaGVuIHVzZWQgd2l0aCBj dWJpYywgQ0FfY3duZCgpIGlzIGJhc2VkIG9uIGN1YmljIGFsZ29yaXRobSBJIHRoaW5rLg0KIFRo aXMgbWVhbnMgSSBuZWVkIHRvIGRvIGN1YmljIHZhcmlhYmxlcyBjYWxjdWxhdGlvbiBkdXJpbmcg c2xvdyBzdGFydA0KIHN1Y2ggYXMgSyBhbmQgV19jdWJpYy4gV2hlbiBpcyBjb25zaWRlcmVkIGFz IGEgc3RhcnQgb2YNCiBjb25nZXN0aW9uIGF2b2lkYW5jZSBhbmQgd2hhdCBXX21heCB3aWxsIGJl Pw0KDQogQ3VycmVudGx5IEkgdXNlIGEgc3RhcnQgb2YgbGltaXRlZCBzbG93IHN0YXJ0IGFzIGEg YmVnaW5uaW5nIG9mIGNvbmdlc3Rpb24gcmVjb3ZlcnkNCiBhbmQgdXNlIGN3bmQgYXQgdGhlIHRp bWUgZm9yIFdfbWF4LiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNCltZaV06IFllcywg dGhhdOKAmXMgZXhhY3RseSB3aGF0IHdlIGRvIGluIFdpbmRvd3MuDQoNCkJlc3QsDQoNCi0tDQpK dW5obyBDaG9pIDxqdW5obyBkb3QgY2hvaSBhdCBnbWFpbC5jb208aHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZnbWFpbC5jb20l MkYmZGF0YT0wMiU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2Y4ZTljZDE1ZjA5YTQ0 YjdiNDg0MDhkN2Q2OTI5YWIyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNzIxMzc5NzkwNjQ4NTMwNCZzZGF0YT1HcVclMkJ5RGRHY2tlJTJGa2lzUzR2YSUy RnglMkYlMkZUMmI3SGxYcXJiSHdVSnltVHM1OCUzRCZyZXNlcnZlZD0wPj4NCg== --_000_SN2PR00MB00778599FB58D63C89C88BCCC3C60SN2PR00MB0077namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBKdW5obyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGFuc3dlcmVkIHlvdXIgcXVl c3Rpb25zIGlubGluZS4gVGhhbmtzIGZvciBjb25zaWRlcmluZyBIeXN0YXJ0JiM0MzsmIzQzOyBp biB5b3VyIFFVSUMgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEp1bmhvIENob2kgJmx0O2p1bmhv LmNob2lAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAx LCAyMDIwIDQ6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZs dDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgWWkgSHVhbmcgJmx0O2h1YW55aUBtaWNyb3NvZnQu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBbRVhURVJOQUxdIFF1ZXN0aW9ucyBvbiBIeVN0YXJ0JiM0MzsmIzQzOyBkcmFmdCAwMjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gd29ya2luZyBv biBRVUlDIGltcGxlbWVudGF0aW9uICg8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGY2xv dWRmbGFyZSUyRnF1aWNoZSZhbXA7ZGF0YT0wMiU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNv bSU3Q2Y4ZTljZDE1ZjA5YTQ0YjdiNDg0MDhkN2Q2OTI5YWIyJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIxMzc5NzkwNjQ3NTMwNCZhbXA7c2RhdGE9R1dx TFZXTUdRalNEV0lRNFNNUmlsNk1QYXVCd1NnU2RYQzE1Wmx3biUyRjJzJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPmh0dHBzOi8v Z2l0aHViLmNvbS9jbG91ZGZsYXJlL3F1aWNoZTwvc3Bhbj48L2E+KQ0KIGF0IENsb3VkZmxhcmUu IFdoaWxlIEkgYW0gcmVzZWFyY2hpbmcgb24gaHlzdGFydCwgSSBjYW1lIGFjcm9zcyBIeVN0YXJ0 JiM0MzsmIzQzOyZuYnNwO3JlY2VudGx5IGFuZCBJIHRoaW5rIHRoaXMgaXMgYSByZWFzb25hYmxl IHJlcGxhY2VtZW50IG9mIG9yaWdpbmFsIGh5c3RhcnQsIHNvIEkgc3RhcnRlZCB0aGUgd29yayBi YXNlZCBvbiB0aGUgaHlzdGFydHBsdXNwbHVzIGRyYWZ0IDAyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFib3V0IHF1aWMgaW1w bGVtZW50YXRpb24gYnV0IGl0J3MgbW9yZSBnZW5lcmFsIHF1ZXN0aW9ucywgc28gSSBhbSBwb3N0 aW5nIGhlcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoaWxlIEkgYW0gaW1wbGVtZW50aW5nIGl0LCBJIGhhdmUgYSBmZXcgcXVlc3Rpb25z OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4x LiBTZWN0aW9uIDQuMiAtLSBlYWNoIHJvdW5kIGlzIGluaXRpYWxpemVkIGFzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDts YXN0Um91bmRNaW5SVFQgPSBjdXJyZW50Um91bmRNaW5SVFQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjdXJyZW50Um91bmRN aW5SVFQgPSBpbmZpbml0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3J0dFNhbXBsZUNvdW50ID0gMDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIHZl cnkgYmVnaW5uaW5nIG9mIHRoZSBjb25uZWN0aW9uLCB3aGF0IGlzICZxdW90O2N1cnJlbnRSb3Vu ZE1pblJUVCZxdW90OyB3aGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50aGVyZSBpcyBubyBwcmV2aW91cyB2YWx1ZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSB1c2luZyBjdXJyZW50 IHJ0dCAob3IgaW5pdGlhbCBydHQgdmFsdWUpIGFuZCBpcyBpdCBvaz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W1lpXTogSW4gb3VyIGltcGxlbWVudGF0aW9uLCBsYXN0Um91bmRNaW5SVFQgYW5k IGN1cnJlbnRSb3VuZE1pblJUVCBhcmUgaW5pdGlhbGl6ZWQgdG8gMHhmZmZmZmZmZiBhcyBzZW50 aW5lbCB2YWx1ZXMuIFdlIG9ubHkgY29tcGFyZSBsYXN0Um91bmRNaW5SVFQgd2l0aCBjdXJyZW50 Um91bmRNaW5SVFQgd2hlbiBib3RoIG9mIHRoZW0gYXJlIHZhbGlkIHZhbHVlcy4gVXNpbmcgY3Vy clJUVCBzZWVtcyB0byBlc3NlbnRpYWxseQ0KIGJlaGF2ZSB0aGUgc2FtZSBhcyBhc3NpZ25pbmcg YSBzZW50aW5lbCB2YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4gU2VjdGlvbiA0LjIgLS0gV2hlbiB1c2VkIHdpdGggY3ViaWMsIENB X2N3bmQoKSBpcyBiYXNlZCBvbiBjdWJpYyBhbGdvcml0aG0gSSB0aGluay48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1RoaXMgbWVhbnMg SSBuZWVkIHRvIGRvIGN1YmljIHZhcmlhYmxlcyBjYWxjdWxhdGlvbiBkdXJpbmcgc2xvdyBzdGFy dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7c3VjaCBhcyBLIGFuZCBXX2N1YmljLiBXaGVuIGlzIGNvbnNpZGVyZWQgYXMgYSBzdGFydCBv ZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Y29uZ2VzdGlvbiBhdm9pZGFuY2UgYW5kIHdoYXQgV19tYXggd2lsbCBiZT88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Q3VycmVudGx5IEkgdXNlIGEgc3Rh cnQgb2YgbGltaXRlZCBzbG93IHN0YXJ0IGFzIGEgYmVnaW5uaW5nIG9mIGNvbmdlc3Rpb24gcmVj b3Zlcnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwO2FuZCB1c2UgY3duZCBhdCB0aGUgdGltZSBmb3IgV19tYXguIElzIG15IHVuZGVyc3Rh bmRpbmcgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1lpXTogWWVzLCB0aGF04oCZ cyBleGFjdGx5IHdoYXQgd2UgZG8gaW4gV2luZG93cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdW5obyBDaG9pICZsdDtqdW5obyBk b3QgY2hvaSBhdCA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmdtYWlsLmNvbSUyRiZhbXA7ZGF0YT0wMiU3QzAx JTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2Y4ZTljZDE1ZjA5YTQ0YjdiNDg0MDhkN2Q2OTI5 YWIyJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIxMzc5 NzkwNjQ4NTMwNCZhbXA7c2RhdGE9R3FXJTJCeURkR2NrZSUyRmtpc1M0dmElMkZ4JTJGJTJGVDJi N0hsWHFyYkh3VUp5bVRzNTglM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmdt YWlsLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR00MB00778599FB58D63C89C88BCCC3C60SN2PR00MB0077namp_-- From nobody Thu Apr 2 00:28:15 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 ECF013A0BFE for ; Thu, 2 Apr 2020 00:28:13 -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 OpnMv7aUmhgR for ; Thu, 2 Apr 2020 00:28:12 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3A1513A0BFF for ; Thu, 2 Apr 2020 00:28:12 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id 31so2916720wrs.3 for ; Thu, 02 Apr 2020 00:28: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=kmSZQgJ55mC357Cj4xMk1lDcUXk7X+ZNGT5phyo5VzA=; b=BoXWkxzc12e9DRGfqFICg0daquMQTHwPN6p40wnMsI3Em85+Eix8thft6nzKeKWbY4 Nd/6FbDmzyT/lqpWLsm4jlUgEQGNIbxSt4tFacuQOzQCR/VHAjFOoT6fXY3VJYUG7iVf B3FbjbOJ8Kexdo1kO/gPw4VcWzsV8XlWC8VEhQC/XC6hsV6mt5y8jSKymsUkgTK26G3M SHzZSV1O2Z6il4TU37H+jSRyEf6PBQ+ldgFQCh/Fwqc6qs14yX0Fcm5v+segSNs4Bp0l luGtKrRpN/BCeDoE6qqqA7Au9mdAmgGP0eSo6jwTgx4l6k2CvmjWz0b6zj2XCVX3x110 uc/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; bh=kmSZQgJ55mC357Cj4xMk1lDcUXk7X+ZNGT5phyo5VzA=; b=Inaik3Wvazd7hAYRid1TbwoozroCzTmObFDLvwXYbveLePlUnt2wqVNCmR2RMvkV/8 S7DwSxE3Lx+z8mTSTgCIyIpGJUxvIJ8Fs8PLlhXw2DHYKFE9FzF0mQfYp5M7wQnLW6RG 7oxtszkzO6OqJTwxEMdNSsODwwsaBWYvS8NmdXC/oazJAT64HLJ/SrBigpanfVYrA+c8 0bItH6vw7KcQeW7wX3AJRwyJulIOYaT2syC77IVgwEUWBc2hJ1846Gv0+CLNYfurv3Zk /auQ1UMVst/noRcxvbPCrYG5eZLSjCDNBmCvvSWVL1XLUz7woRbFAaVxThZBmUCIhJPf Tikw== X-Gm-Message-State: AGi0PuaA5Cnqn81ouTg4Y7ROrjlbm3jHil3KNa4KyTmWM5T9BHqlefz6 d34oEKaHXkd+fLvPEnhdvFYTG3AavhRPm5aTgLM= X-Google-Smtp-Source: APiQypLoF+GOmKbH3x2/W1OHOprK5LkiNi0HpJNzhBWhfoOfLewx1lSqKDw6+rxjbBFOIaJ+1AWVRF5i4pd7Km4VnRM= X-Received: by 2002:a5d:4bc1:: with SMTP id l1mr2153932wrt.103.1585812489549; Thu, 02 Apr 2020 00:28:09 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de> From: juhamatk@gmail.com Date: Thu, 2 Apr 2020 10:27:57 +0300 Message-ID: To: "Scharf, Michael" Cc: Joseph Touch , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" 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, 02 Apr 2020 07:28:14 -0000 Hello Michael, > 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. > BTW, if there is some gap in the RFC series, the usual IETF process is just starting a new Internet-Draft, instead of waiting for somebody else to write something. It is not complex to write an Internet Draft. And TCPM is usually quite open to new work. I am not that familiar with the draft process. I agree that if test vectors do not already exist, that may be the best path to go forward. Here below is a draft outline that perhaps provides the information needed to ensure compatible implementations. If there is some consensus that proceeding with this would be useful, perhaps we can use it as a starting point. We need to fill the verified test vectors there eventually. Test Vectors for Cryptographic Algorithms of the TCP Authentication Option (TCP-AO) - Introduction Key Derivation Functions Test Vectors * KDF_HMAC_SHA1 - A test TCP/IP frame: syn snd key output - A test TCP/IP frame: syn rcv key output - A test TCP/IP frame: other snd key output - A test TCP/IP frame: other rcv key output * KDF_AES_128_CMAC - A test TCP/IP frame: syn snd key output - A test TCP/IP frame: syn rcv key output - A test TCP/IP frame: other snd key output - A test TCP/IP frame: other rcv key output MAC Algorithms Test Vectors * HMAC-SHA-1-96 - A test key with test TCP/IP frame: MAC output, MAC output without options * AES-128-CMAC-96 - A test key with test TCP/IP frame: MAC output, MAC output without options Security Considerations Acknowledgements References > Michael Thanks, -- Juhamatti > > -----Original Message----- > > From: tcpm On Behalf Of juhamatk@gmail.com > > Sent: Wednesday, April 1, 2020 9:30 AM > > To: Joseph Touch > > Cc: tcpm@ietf.org > > Subject: Re: [tcpm] Test vectors for RFC5925 algorithms? > > > > Hello Joe, > > > > > At best, those might be an addendum to RFC 5926. RFC 5925 deliberately > > does not specify any algorithms. > > > > Thanks for your reply. Addendum to RFC 5926 sounds really good to me. > > > > > However, TCP MD5 was widely deployed without any such test vectors in the > > RFC series (or elsewhere I could find, FWIW). > > > > True. Still, RFC 2385 is only 4 pages long and implementation is very > > simple. It had wide deployment from the beginning, I believe, so it > > was easy to make implementations match. > > > > I am currently working on a proprietary implementation of RFC > > 5925/5926. Even though the RFCs are ten years old, they have only a > > few existing implementations. Test equipment vendors (IXIA, Spirent) > > do not support it. Juniper does not use it, they seem to use their own > > proprietary version. One fuzzing vendor seems to have HMAC-SHA1 > > implemented, but it is unclear is it according to the RFCs. > > Guaranteeing interop looks quite difficult at the moment. > > > > So if test vectors already exist somewhere (maybe unpublished), or > > someone is willing to create them for the addendum draft referenced > > above, I am certainly willing to verify them against my implementation > > and report back. > > > > > Joe > > > > Thanks, > > -- > > Juhamatti > > > > > > > > > On Mar 31, 2020, at 3:44 AM, juhamatk@gmail.com wrote: > > > > > > > > Hello, > > > > > > > > I have been searching for test vectors for RFC5925/5926 algorithms for > > > > TCP AO and to my surprise it seems that such do not exist. Am I > > > > correct here? > > > > > > > > Even though test vectors for HMAC SHA1 (RFC2202) and AES CMAC > > > > (RFC4493) are available, it would be useful to have example test > > > > vectors for frames using TCP AO - otherwise implementations end up > > > > easily not to match. As RFC5925 is 47 pages, there is a room for error > > > > and only one mismatch is needed for MACs not to match. > > > > > > > > I think publishing a new RFC for them would be good, but probably > > > > takes some time. Even unofficial, but verified, test vectors on some > > > > specified example frames (with and without TCP options), e.g. on this > > > > mailing list or otherwise, would be a very good start to get TCP AO > > > > more widely implemented. If such already are available somewhere, > > > > please do let me know. > > > > > > > > Thanks, > > > > -- > > > > Juhamatti > > > > > > > > _______________________________________________ > > > > 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 Thu Apr 2 00:55:49 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 4E9643A0CFA for ; Thu, 2 Apr 2020 00:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 b_byVayM1wuh for ; Thu, 2 Apr 2020 00:55:46 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 8F7953A0CF9 for ; Thu, 2 Apr 2020 00:55:46 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id w185so1687873vsw.10 for ; Thu, 02 Apr 2020 00:55:46 -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=pkVL/5XVk1kFcmfSJAeSsXSsbBvutA5zgPfEWd08IwM=; b=WIXo6liRUIlAeg5QcZb6GgPJ27ijCFEyNU5of8Tm6zPyZteiUUxgfQeqrM2lmWpPLb FzCvkh1ADYnUD+CH9fXGmrMyyrfoLbN1CilH+5G3t/cAS6ecc9HSyhv0dsirdGrG5ES0 4dICdCgj4kfuIhIORP2AM9t3fG31tiOfX7933iuN1aFSAKPjNjYtL+r5Fjn2cVkbJeTk 9dKsSgN0YtWb8JmetL7ByL7ti9Fgj+3xWrrQFyudiDbl2dvhC4a7Ylbv2CclCkDeEbV2 KTjZ1OuuGTk2GIctxoUlIuA16Vk/bprQaCNz7GpHfaezcyITTTcKnVZJ+CBuU7/P/IKX 71Dg== 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=pkVL/5XVk1kFcmfSJAeSsXSsbBvutA5zgPfEWd08IwM=; b=rxpmalufmOjWVPPxj55ZyNE4hwadAn4k3YN6jWVj4NgGl2RH5422pswVFlQVrLUHDG 4nMJO451uzHTc2N9nrmFt+HeR1jY4T3U0cIWtCAfetdVyaSl+oKnlobD+N57OPNSZ5DR ATxhGk+Bmnfm14o5kurCykW7NilQbtChvnc+/MCVZJUhLfRETgMmpRkD9p41es9bZvjj +ADWszUwCj9J1s+4lx41ilN3F16qu/2ClHzjEGee2HyiJhVahTu/gK5aq1tqCI2BWcKg EqAi+VB9fX1VUPPsDQgniWl7ltB+cz3KYKjUjUR6l0XvctR+1I05jhmlBx+u0nnyvPtU FDPA== X-Gm-Message-State: AGi0PuYr1KYuE1ZStlbD6rzgNylSWV1iuK/PjJ/0WQD5G1aLXddpq4wd p3K5HAcdQMfXNntgVjKfTTIE7CikbH3BfTbzmsYA9vHv+rYAig== X-Google-Smtp-Source: APiQypKzZ6xTuNUU9oonLci4EvzYBYfsLNH8lV2EVK5S7bY1SZPpiVDcCzdA8+3cAN+hQqM9uqGysVPGfo3ssTCLIi0= X-Received: by 2002:a67:5e85:: with SMTP id s127mr1355370vsb.204.1585814145219; Thu, 02 Apr 2020 00:55:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junho Choi Date: Thu, 2 Apr 2020 00:55:08 -0700 Message-ID: To: Yi Huang Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ce443a05a24a206a" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 07:55:49 -0000 --000000000000ce443a05a24a206a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yi, Thanks. See inline for my following question. On Wed, Apr 1, 2020 at 5:04 PM Yi Huang wrote: > 1. Section 4.2 -- each round is initialized as > > > > lastRoundMinRTT =3D currentRoundMinRTT > > currentRoundMinRTT =3D infinity > > rttSampleCount =3D 0 > > > > In the very beginning of the connection, what is "currentRoundMinRTT" whe= n > > there is no previous value? > > > > I am using current rtt (or initial rtt value) and is it ok? > > > > [Yi]: In our implementation, lastRoundMinRTT and currentRoundMinRTT are > initialized to 0xffffffff as sentinel values. We only compare > lastRoundMinRTT with currentRoundMinRTT when both of them are valid value= s. > Using currRTT seems to essentially behave the same as assigning a sentine= l > value. > So in the beginning of the connection lastRoundMinRTT is . When ack is received currentRoundMinRTT =3D min_rtt but lastRoundMinRTT is still . When the 1st round ends, it looks always doing nothing because the following if() is always false? if (currentRoundMinRTT >=3D (lastRoundMinRTT + RttThresh)) > > > 2. Section 4.2 -- When used with cubic, CA_cwnd() is based on cubic > algorithm I think. > > This means I need to do cubic variables calculation during slow start > > such as K and W_cubic. When is considered as a start of > > congestion avoidance and what W_max will be? > > > > Currently I use a start of limited slow start as a beginning of > congestion recovery > > and use cwnd at the time for W_max. Is my understanding correct? > > > > [Yi]: Yes, that=E2=80=99s exactly what we do in Windows. > Sound great. Thanks. Best, --=20 Junho Choi --000000000000ce443a05a24a206a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yi,

Thanks. See inline fo= r my following question.

On Wed, Apr 1, 2020 at 5:04 PM Yi Huang <<= a href=3D"mailto:huanyi@microsoft.com">huanyi@microsoft.com> wrote:<= br>
1. Section 4.2 -- each round is initialized as

=C2=A0

=C2=A0 =C2=A0lastRoundMinRTT =3D currentRoundMinRTT<= u>

=C2=A0 =C2=A0currentRoundMinRTT =3D infinity<= u>

=C2=A0 =C2=A0rttSampleCount =3D 0

=C2=A0

In the very beginning of the connection, what is &qu= ot;currentRoundMinRTT" when

there is no previous value?

=C2=A0

I am using current rtt (or initial rtt value) and is= it ok?

=C2=A0

[Yi]: In our implementation, lastRoundMinRTT and cur= rentRoundMinRTT are initialized to 0xffffffff as sentinel values. We only c= ompare lastRoundMinRTT with currentRoundMinRTT when both of them are valid = values. Using currRTT seems to essentially behave the same as assigning a sentinel value.

=

So in the beginning of the connectio= n lastRoundMinRTT is <inf>. When ack is received currentRoundMinRTT = =3D min_rtt but
lastRoundMinRTT is still <inf>. When the 1s= t round ends, it looks always doing nothing because the following if() is a= lways false?

=C2=A0 if (currentRoundMinRTT >= ;=3D (lastRoundMinRTT + RttThresh))

=C2=A0

=C2=A0

2. Section 4.2 -- When used with cubic, CA_cwnd() is= based on cubic algorithm I think.

=C2=A0This means I need to do cubic variables calcul= ation during slow start

=C2=A0such as K and W_cubic. When is considered as a= start of

=C2=A0congestion avoidance and what W_max will be?

=C2=A0

=C2=A0Currently I use a start of limited slow start = as a beginning of congestion recovery

=C2=A0and use cwnd at the time for W_max. Is my unde= rstanding correct?

=C2=A0

[Yi]: Yes, that=E2=80=99s exactly what we do in Wind= ows.


Soun= d great. Thanks.

Best,
=

--
Junho Choi <junho dot choi at gmail.com>
--000000000000ce443a05a24a206a-- From nobody Thu Apr 2 04: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 3E00B3A107F; Thu, 2 Apr 2020 04:45:29 -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 TfvJ-kd92N5W; Thu, 2 Apr 2020 04:45:23 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80125.outbound.protection.outlook.com [40.107.8.125]) (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 6D7303A1079; Thu, 2 Apr 2020 04:45:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W6QU/bdTvsd0qHdnRGTZ7VNm74B49GItC5du191h1ajqUiAr2rYStYz2onssPNTjMbG34IZi9zVKwjxxGe6fC/eA5235pG4/wMybxCfSze/P7xNkXTiESKg3G7ejG01FpokS06uAOrOj6utRFResY3rbTZC4bCdBkx6VVHtkZcqbqpienqWS4fsEGPXCFtTtk9QRjFljeb1JgxjwJNqPAKydGN5sI0oVz9BJs4Nt6ZL+DM7Hvk9XI/biVqfj0dvO7DpFw7a1YwUNjwtN2OpZCivGFkY3tD/FBm3/OVG9xKoSKZ/SIpEbETZLrGzOSUXnrqNcOGFBx+bjR/kmDUvkog== 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=WPDBIfnB9UqXnKtCKvjwQr0KRCBhAd+pJr1PoriLRY4=; b=ZB5oWa1AjN/8AWO2Hje/9OiDeduPye6PWrsVYgcrUF6NIGZ2McW6j4s7yGg7Yf5EjX7fU9CumCDYZov3J99q/8lvh/4KKx9kWpX8G3UjnRqkJb2EQQNNo1ykdt6K6c22ZdK9GyXA/Rb0pgE1PZiVICqoLG/kgtAcXPHlCpK0wzu8yWjlwp+ziEqO7scsRMAnMDDI37zLVRpUD9VCRctVdeBnABrf5dRbUrTMY/LuZsj7KGuDXms1GwZ1ihq15IbMV+rYnQTzTjJt/i+zszdMaaznTTXu+4ZiBxgJV+HNH8EzABN+jJZ6tWvFk2gONLMRZfT1SumUaQ3Lu8ecr2Y5+g== 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=WPDBIfnB9UqXnKtCKvjwQr0KRCBhAd+pJr1PoriLRY4=; b=Q6dO0uVJtpRoLKcE6RMVKIF63xF04/MHuLsIFzklewoG/zCpAAXMzvNJpQ90pOcQkJqmwbhdoPA0NY5CPxjeZDqZr48zpybcllDMJNpZVEh7+OzmZIccQncGYEw8vCnpWA++Gg9UPcvC9AOBD6swmtSdW7LmTLbQ4OcXVjt7P2k= Received: from DB7PR07MB5657.eurprd07.prod.outlook.com (20.178.85.222) by DB7PR07MB4667.eurprd07.prod.outlook.com (52.135.135.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.11; Thu, 2 Apr 2020 11:45:21 +0000 Received: from DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee]) by DB7PR07MB5657.eurprd07.prod.outlook.com ([fe80::a438:bbc9:2ffe:33ee%5]) with mapi id 15.20.2878.013; Thu, 2 Apr 2020 11:45:21 +0000 From: tom petch To: "Scharf, Michael" , "idr@ietf.org" CC: tcpm IETF list Thread-Topic: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 Thread-Index: AdX9YZybm8xvduWhO0ywtFiDNCmPqgFQZ2TYAAS+u+ABizF/AA== Date: Thu, 2 Apr 2020 11:45:20 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D9F11D2@rznt8114.rznt.rzdir.fht-esslingen.de> , <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-originating-ip: [81.131.229.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f75e123c-5298-4126-8116-08d7d6fb52c9 x-ms-traffictypediagnostic: DB7PR07MB4667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5657.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(396003)(366004)(39860400002)(346002)(136003)(376002)(71200400001)(91956017)(81156014)(66446008)(76116006)(66946007)(5660300002)(8936002)(64756008)(66476007)(8676002)(52536014)(81166006)(966005)(66556008)(186003)(110136005)(6506007)(316002)(55016002)(9686003)(478600001)(66574012)(2906002)(26005)(7696005)(4326008)(86362001)(33656002); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZZRNoKPVvN9ZEYQPereJxBRvWXqa54h9RwQHURHbNklOXO189ec1mmZTjCS6Y9pfObgFR/XyyeaQIn3Rkbkk/iQbcVB+TFpGEypo34uZQhvYuiVXipUQHBb4c6LAogu+ew+whCusnl1OjEEVDtYO4qOGxoS/6W2vTiJ9CkzbwC2ocp8Mfe8SS3OeXmz1azJoN8EO9OPbR8Miti8zP8nRl3pzdI3EnZUEvwme03mFNayA/q9i+Kr60uCyswzqwuTCmFan3CCfRACoMLy/Q9WJy7BXma215odrem1ILMNjVEmNSfsOJ99yWhIwvMg3NMfaQTYPSILkprQzvezubUTBix0uFUMfvgs+WE8imqdvpjD3fjr6jR26/qXqCAx9x1ishXmHdriFTssmZNooe85oZQEErhFW1Ok/dc8u/PV1C8tM5gwKwbvlYaAkb5dHZBclPnp3zWWiCDLfMG4JBbYoMPL8K4LfDMV1PeGFikYCjTZM0Qm5hpBbvXmMOK5DCXHzbBBwIT9bJNUvmo1Gk0dZ4A== x-ms-exchange-antispam-messagedata: ksxkZUZ7rBl9Q7WjGLXQmibnq3zUUTeUwz35RifmNAMN52sH6OqRv29Beuou8Ql0th8tT52YGKgbSmpxttfnSapVc3QM1oAhGiGUz1269Y6rFEIE/j4EWXcPbGDWP+hnS8tlQMcJt2BXoVAbVt1yYQ== 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: f75e123c-5298-4126-8116-08d7d6fb52c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 11:45:20.8198 (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: eafUr0ePkuzggerqmmQOypE4BSSh6UnhLg+o1Fr1cRDP8ydhnFfRbuJ5zmBYBc2OUKXAUYoUfyVugxA0C+j+6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4667 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 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, 02 Apr 2020 11:45:30 -0000 Michael,=0A= apologies, this got lost - inline=0A= =0A= From: Scharf, Michael =0A= Sent: 25 March 2020 16:39=0A= =0A= Hi Tom,=0A= =0A= > -----Original Message-----=0A= > From: tom petch =0A= > Sent: Wednesday, March 25, 2020 1:53 PM=0A= >=0A= > From: Idr on behalf of Scharf, Michael=0A= > =0A= > Sent: 18 March 2020 20:12=0A= >=0A= > Hi all,=0A= >=0A= > This is a heads-up regarding the ongoing adoption call for draft-scharf-t= cpm-=0A= > yang-tcp-04 in TCPM.=0A= >=0A= > =0A= > Michael=0A= >=0A= > I note that you have also sent this to Netconf and that you import groupi= ngs=0A= > from the netconf-tcp draft which makes the netconf draft a Normative=0A= > Reference except that this I-D does not mention that fact.=0A= =0A= [I-D.ietf-netconf-tcp-client-server] is listed as first normative reference= in draft-scharf-tcpm-yang-tcp and that dependency is also mentioned in the= abstract. With the current structure of the models, it is not clear to me = why a reference in the reverse direction would be needed.=0A= =0A= =0A= RFC8407 says that YANG import must have a reference which must be a Normati= ve Reference for the I-D.=0A= =0A= So far, the feedback from the NETCONF chairs was that draft-ietf-netconf-tc= p-client-server would most likely finish before a TCPM document. The work i= n the NETCONF WG started much earlier.=0A= =0A= =0A= I note that the chair is also the author:-)=0A= =0A= > I think this is problematic. Progress on the netconf I-D has been slow f= or some=0A= > years and so your I-D could have to wait a while. The solution would be = to=0A= > progress the netconf draft but I do not know how this can be expedited.= =0A= =0A= That is an interesting line of thought. Actually, when I wear the hat of a = co-chair of TCPM, I get told again and again that TCPM is too slow... We cu= rrently try our best to speed up a bit. However, due to the complexity of T= CP, the heterogeneity of implementations, and the scale of deployment of th= e protocol, TCPM needs some time to process documents. This would almost ce= rtainly also apply to a YANG model. In addition, TCPM has not dealt with YA= NG so far, i.e., it is a new topic for the working group.=0A= =0A= Realistically, even if we as authors try our best, the normative reference = to the netconf I-D would only become a problem if that document does not pr= ogress at all for a longer time.=0A= =0A= Would you prefer a TCPM document without that normative reference? In any c= ase, I doubt that timing should be the main motivation for that. Would ther= e be other reasons?=0A= =0A= =0A= I see TCPM as the best of source of information about TCP in the IETF and s= o best qualified to produce an accurate YANG module which other WG then imp= ort. The downside is that TCP has so many facets that the temptation will = be to produce the kitchen sink which is never complete; but with ruthless c= ontrol from Chairs and AD to keep a limit on the scope then I think that th= e TCPM WG is the place for it.=0A= =0A= Tom Petch=0A= =0A= > There are a lot of details in this I-D that I think of as admin which nee= d fixing to=0A= > conform to YANG Guidelines but would not see that as a bar to adoption=0A= > whereas dependency on netconf is more debatable IMHO.=0A= =0A= Indeed, many details require further work. That is well understood.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= > Tom Petch=0A= >=0A= >=0A= > You may want to pay attention. For instance, this document defines groupi= ngs=0A= > for TCP-AO and MD5, which are used by draft-ietf-idr-bgp-model.=0A= >=0A= > If you support work of this document in TCPM, or if you have any comments= ,=0A= > please free to provide feedback on the TCPM list (tcpm@ietf.org).=0A= >=0A= > Thanks=0A= >=0A= > Michael (TCPM chair hat off)=0A= >=0A= >=0A= > Von: Michael Tuexen=0A= > Gesendet: Montag, 16. M=E4rz 2020 21:44=0A= > An: tcpm IETF list=0A= > Cc: draft-scharf-tcpm-yang-tcp@ietf.org tcp@ietf.org>=0A= > Betreff: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tc= p-04=0A= >=0A= > Dear all,=0A= >=0A= > this mail starts a WG adoption call for=0A= > https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04=0A= >=0A= > So I would like to solicit feedback regarding support for or objections a= gainst=0A= > the=0A= > adoption of the document as a WG document in TCPM.=0A= >=0A= > Please provide feedback before March 31st.=0A= >=0A= > For the context and current state of the document, see the presentation s= ent=0A= > yesterday=0A= > to the mailing list by Mahesh.=0A= >=0A= > Best regards=0A= > Michael=0A= >=0A= >=0A= =0A= From nobody Thu Apr 2 08:18: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 D62003A13E3 for ; Thu, 2 Apr 2020 08:18:49 -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 52oC-1nn9iNY for ; Thu, 2 Apr 2020 08:18:48 -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 F23C73A13E1 for ; Thu, 2 Apr 2020 08:18:47 -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=PZtHKr6nZa5n7fQ2Jt4Ve9Ov4pZnU2xX1IoBfsMQx9g=; b=mm1vRyZTXlIz5Ko0xDDPiArLt Zv59yT19Kr4IwtvLw5KUUQuZesQkOPhCB9+nGEH1zh62MtRiZABzNvOBLw4CKlJRVaiGmvDC0rJ2g A2GpagglIfH9KjNeI3DBM774wC8LZaSXssZL/3sowDXuderZXSItn01KIxG4hE1jrFj6HRZdLyZ+1 8Mlu0bCss/VJJFkk1sBELvKEnV7iCn2pdmvOqZ8HBLoDyY/Eu7Ep4HIoJQ4ZLJq4JfbkhfKf1aodU wvjcaV9KxW3Vy71tARlpY823l/fiVEjHIEDbL6m09bJcZN4Su76XZ2FP7TWJD1by7Pi22gc5dwQT+ Vl/ZOCb2A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64380 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jK1c8-003dmQ-GW; Thu, 02 Apr 2020 11:18:45 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Joseph Touch In-Reply-To: Date: Thu, 2 Apr 2020 08:18:39 -0700 Cc: "Scharf, Michael" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de> To: juhamatk@gmail.com X-Mailer: Apple Mail (2.3445.9.5) 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] 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, 02 Apr 2020 15:18:50 -0000 Hi, Juhamatti, If you can provide the test vectors, I can prepare them into an Internet = Draft with you. But let=E2=80=99s start with the first step and make = sure all the pieces are in place first. If you want to proceed that way, please contact me directly and we can = go from there. Joe > On Apr 2, 2020, at 12:27 AM, juhamatk@gmail.com wrote: >=20 > Hello Michael, >=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 >> BTW, if there is some gap in the RFC series, the usual IETF process = is just starting a new Internet-Draft, instead of waiting for somebody = else to write something. It is not complex to write an Internet Draft. = And TCPM is usually quite open to new work. >=20 > I am not that familiar with the draft process. I agree that if test > vectors do not already exist, that may be the best path to go forward. > Here below is a draft outline that perhaps provides the information > needed to ensure compatible implementations. If there is some > consensus that proceeding with this would be useful, perhaps we can > use it as a starting point. We need to fill the verified test vectors > there eventually. >=20 > Test Vectors for Cryptographic Algorithms of the TCP Authentication > Option (TCP-AO) > - > Introduction > Key Derivation Functions Test Vectors > * KDF_HMAC_SHA1 > - A test TCP/IP frame: syn snd key output > - A test TCP/IP frame: syn rcv key output > - A test TCP/IP frame: other snd key output > - A test TCP/IP frame: other rcv key output > * KDF_AES_128_CMAC > - A test TCP/IP frame: syn snd key output > - A test TCP/IP frame: syn rcv key output > - A test TCP/IP frame: other snd key output > - A test TCP/IP frame: other rcv key output > MAC Algorithms Test Vectors > * HMAC-SHA-1-96 > - A test key with test TCP/IP frame: MAC output, MAC output without = options > * AES-128-CMAC-96 > - A test key with test TCP/IP frame: MAC output, MAC output without = options > Security Considerations > Acknowledgements > References >=20 >> Michael >=20 > Thanks, > -- > Juhamatti >=20 >>> -----Original Message----- >>> From: tcpm On Behalf Of juhamatk@gmail.com >>> Sent: Wednesday, April 1, 2020 9:30 AM >>> To: Joseph Touch >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] Test vectors for RFC5925 algorithms? >>>=20 >>> Hello Joe, >>>=20 >>>> At best, those might be an addendum to RFC 5926. RFC 5925 = deliberately >>> does not specify any algorithms. >>>=20 >>> Thanks for your reply. Addendum to RFC 5926 sounds really good to = me. >>>=20 >>>> However, TCP MD5 was widely deployed without any such test vectors = in the >>> RFC series (or elsewhere I could find, FWIW). >>>=20 >>> True. Still, RFC 2385 is only 4 pages long and implementation is = very >>> simple. It had wide deployment from the beginning, I believe, so it >>> was easy to make implementations match. >>>=20 >>> I am currently working on a proprietary implementation of RFC >>> 5925/5926. Even though the RFCs are ten years old, they have only a >>> few existing implementations. Test equipment vendors (IXIA, Spirent) >>> do not support it. Juniper does not use it, they seem to use their = own >>> proprietary version. One fuzzing vendor seems to have HMAC-SHA1 >>> implemented, but it is unclear is it according to the RFCs. >>> Guaranteeing interop looks quite difficult at the moment. >>>=20 >>> So if test vectors already exist somewhere (maybe unpublished), or >>> someone is willing to create them for the addendum draft referenced >>> above, I am certainly willing to verify them against my = implementation >>> and report back. >>>=20 >>>> Joe >>>=20 >>> Thanks, >>> -- >>> Juhamatti >>>=20 >>>>=20 >>>>> On Mar 31, 2020, at 3:44 AM, juhamatk@gmail.com wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I have been searching for test vectors for RFC5925/5926 algorithms = for >>>>> TCP AO and to my surprise it seems that such do not exist. Am I >>>>> correct here? >>>>>=20 >>>>> Even though test vectors for HMAC SHA1 (RFC2202) and AES CMAC >>>>> (RFC4493) are available, it would be useful to have example test >>>>> vectors for frames using TCP AO - otherwise implementations end up >>>>> easily not to match. As RFC5925 is 47 pages, there is a room for = error >>>>> and only one mismatch is needed for MACs not to match. >>>>>=20 >>>>> I think publishing a new RFC for them would be good, but probably >>>>> takes some time. Even unofficial, but verified, test vectors on = some >>>>> specified example frames (with and without TCP options), e.g. on = this >>>>> mailing list or otherwise, would be a very good start to get TCP = AO >>>>> more widely implemented. If such already are available somewhere, >>>>> please do let me know. >>>>>=20 >>>>> Thanks, >>>>> -- >>>>> Juhamatti >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Apr 3 02:54: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 9D4E03A162F for ; Fri, 3 Apr 2020 02:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 tJ7SHh3wgjTK for ; Fri, 3 Apr 2020 02:54:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7DAB83A162C for ; Fri, 3 Apr 2020 02:54:08 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 28FF7BC9553FE3446D3D; Fri, 3 Apr 2020 10:54:07 +0100 (IST) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 3 Apr 2020 10:54:06 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.162]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0487.000; Fri, 3 Apr 2020 15:23:52 +0530 From: Rahul Arvind Jadhav To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-rto-consider Thread-Index: AQHWB/k8ECjDWSKVpkm5PeuOc+61pKhnIqUQ Date: Fri, 3 Apr 2020 09:53:52 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5E277914@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.88.138] Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5E277914BLREML503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rto-consider 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, 03 Apr 2020 09:54:11 -0000 --_000_982B626E107E334DBE601D979F31785C5E277914BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2ZSBqdXN0IG9uZSBjb21tZW50IHRvd2FyZHMgU2VjdGlvbiA0LCBidWxsZXQgcG9pbnQgKDMp Lg0KQ3VycmVudGx5IGl0IHNheXMsIOKAnFRoZSBiYWNrb2ZmIFNIT1VMRCBiZSByZW1vdmVkIGFm dGVyIHRoZSBzdWJzZXF1ZW50IHRyYW5zbWlzc2lvbiBvZiBub24tcmV0cmFuc21pdHRlZCBkYXRh LuKAnQ0KSSBndWVzcyBpdCBzaG91bGQgc2F5LCDigJxUaGUgYmFja29mZiBTSE9VTEQgYmUgcmVt b3ZlZCBhZnRlciB0aGUgc3Vic2VxdWVudCBfX3N1Y2Nlc3NmdWxseSBhY2tlZF9fIHRyYW5zbWlz c2lvbiBvZiBub24tcmV0cmFuc21pdHRlZCBkYXRhLuKAnQ0KDQpUaGUgZHJhZnQgaXMgY3Jpc3Ag YW5kIGNsZWFyIGFuZCBwbGVhc3VyZSB0byByZWFkLg0KDQpUaGFua3MsDQpSYWh1bA0KDQpGcm9t OiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9zaGlm dW1pIE5pc2hpZGENClNlbnQ6IDAxIEFwcmlsIDIwMjAgMTU6NDMNClRvOiB0Y3BtQGlldGYub3Jn IEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdGNwbV0gV0dMQyBmb3IgZHJh ZnQtaWV0Zi10Y3BtLXJ0by1jb25zaWRlcg0KDQpIZWxsbyBmb2xrcywNCg0KVGhpcyBlbWFpbCBp bml0aWF0ZXMgdGhlIFdHTEMgZm9yIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRjcG0tcnRvLWNvbnNpZGVyLTEwDQpQbGVhc2Ugc2VuZCB5b3VyIGZlZWRiYWNrIHRvIHRo ZSBNTC4NClRoZSBXR0xDIGZvciB0aGlzIGRyYWZ0IHJ1bnMgdW50aWwgKiBXZWRuZXNkYXkgQXBy aWwgMjIgKi4NCg0KRm9yIHlvdXIgaW5mb3JtYXRpb24sIHRoZSBpbnRlbmRlZCBzdGF0dXMgb2Yg dGhlIGRyYWZ0IGlzIEJDUC4NCldlIGFwcHJlY2lhdGUgeW91ciBjb29wZXJhdGlvbiENCg0KVGhh bmtzLA0KLS0NCnRjcG0tY2hhaXJzDQoNCg0KDQo= --_000_982B626E107E334DBE601D979F31785C5E277914BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uZ21haWwtaWwNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtaWw7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IYXZlIGp1c3Qgb25lIGNvbW1lbnQgdG93YXJkcyBTZWN0aW9u IDQsIGJ1bGxldCBwb2ludCAoMykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCBzYXlz LCDigJxUaGUgYmFja29mZiBTSE9VTEQgYmUgcmVtb3ZlZCBhZnRlciB0aGUgc3Vic2VxdWVudCB0 cmFuc21pc3Npb24gb2Ygbm9uLXJldHJhbnNtaXR0ZWQgZGF0YS7igJ08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSBndWVzcyBpdCBzaG91bGQgc2F5LCDigJxUaGUgYmFja29mZiBTSE9VTEQgYmUgcmVtb3Zl ZCBhZnRlciB0aGUgc3Vic2VxdWVudCBfX3N1Y2Nlc3NmdWxseSBhY2tlZF9fIHRyYW5zbWlzc2lv biBvZiBub24tcmV0cmFuc21pdHRlZCBkYXRhLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IGlzIGNyaXNwIGFuZCBjbGVhciBhbmQgcGxlYXN1 cmUgdG8gcmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmFodWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdGNwbSBbbWFpbHRvOnRjcG0t Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WW9zaGlmdW1pIE5pc2hpZGE8 YnI+DQo8Yj5TZW50OjwvYj4gMDEgQXByaWwgMjAyMCAxNTo0Mzxicj4NCjxiPlRvOjwvYj4gdGNw bUBpZXRmLm9yZyBFeHRlbnNpb25zICZsdDt0Y3BtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbdGNwbV0gV0dMQyBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJ0by1jb25zaWRlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdDtm b250LXNpemU6MC44NzVyZW0iIGlkPSJnbWFpbC06Mm1pIj4NCjxkaXYgaWQ9ImdtYWlsLToybnAi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SGVsbG8gZm9sa3MsPGJyPg0KPGJy Pg0KVGhpcyBlbWFpbCBpbml0aWF0ZXMgdGhlIFdHTEMgZm9yJm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcnRvLWNvbnNpZGVy LTEwIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1ydG8tY29uc2lk ZXItMTA8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPlBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgdG8gdGhlIE1MLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUmbmJzcDs8c3Bh biBjbGFzcz0iZ21haWwtaWwiPldHTEM8L3NwYW4+Jm5ic3A7Zm9yIHRoaXMgZHJhZnQgcnVucyB1 bnRpbCAqIFdlZG5lc2RheSBBcHJpbCAyMiAqLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciB5b3Vy IGluZm9ybWF0aW9uLCB0aGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRoZSBkcmFmdCBpcyBCQ1AuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldl IGFwcHJlY2lhdGUgeW91ciBjb29wZXJhdGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj50 Y3BtLWNoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_982B626E107E334DBE601D979F31785C5E277914BLREML503MBXchi_-- From nobody Sat Apr 4 09:28: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 952383A0F9C for ; Sat, 4 Apr 2020 09:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net 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 y_2TTju5mNgc for ; Sat, 4 Apr 2020 09:28:06 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB043A0F9A for ; Sat, 4 Apr 2020 09:28:06 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id D0395C5 for ; Sat, 4 Apr 2020 18:28:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1586017684; bh=JgfXnEn8WrPVGdkLQvzq8GnezV03p1F7vzTMgGps4WI=; h=Date:From:To:Subject:In-Reply-To:References:From; b=MnSNgS5Yw8qRRpaB53H1mInw9g00qaMg5vmyP+dLgCheNscpsNz6tfm/MBCkXw5ER RyE7G4/IHog9FO8Me933pEavuav2J9fZgPGOIzcEfdyXPwM8R0DTHFfXSLA/NEE54Y rOkFovsijGQORg8ebtiqtD7P6zgju1gG1oDptmP1G0zmA+jDmtBTwCNyNsFwzJiARS K2QmHpTBMgA61aLz+t3k/EAk3C5Mx70So6w5abkTYr5Xo5kRqYN7kn8ibvRgzdDcUd bsVD7whO1xHym1LAcXb0ZSBUL8Vs35e66MOeqU/frOtxavtT4DC5ZiHZd1dpvTeT9H WG1PcFzMGbupw== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 04 Apr 2020 18:28:04 +0200 From: Theresa Enghardt To: tcpm IETF list In-Reply-To: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> Message-ID: <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> X-Sender: ietf@tenghardt.net User-Agent: Roundcube Webmail/1.3.10 Archived-At: Subject: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) 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, 04 Apr 2020 16:28:10 -0000 Dear TCPM, I reviewed draft-ietf-tcpm-rack-08 focusing on whether it is clear and easy to follow when seeking to understand how one would implement this and/or how an existing implementation works. As a secondary concern, I noted some editorial comments and suggestions of how one could make the document more accessible. Overall, I think the document explains the scope and idea of the algorithms really well and the algorithm details that are provided are already quite useful. So thank you for this draft. However, I did find a couple of points where some more clarification would help, and a few consistency as well as editorial issues. I would appreciate it if these were fixed before this document is published as a Proposed Standard RFC. Please find my review below: Section 2, Introduction: “In recent years we have been observing several increasingly common loss and reordering patterns in the Internet: …” As far as I can tell, this list actually combines the description of the loss patterns with the limitations that existing loss recovery mechanisms have, rather than describe limitations that are inherent to the patterns or to TCP. So I think it makes sense to add something like the following to this introductory sentence: “Given these patterns, existing loss recovery mechanisms have the following limitations:” Alternatively, you could move the paragraph starting with “Despite TCP stacks …” above the list, so the list would already be in the context of limitations of existing loss recovery mechanisms. Please consider adding a half-sentence here explaining what a tail drop is to make the document more accessible. “Also, these algorithms, including RFCs, rarely address the interactions with other algorithms.” I think it’s worth clarifying the scope of the problem: Is this about using multiple different algorithms at the same time on the same sender? Or is this about interaction between different senders using different algorithms? “The goal of RACK is to solve all the problems above …” Perhaps this paragraph should mention that RACK has limitations, too. For example, this paragraph could already touch upon the problem of reordering and spurious retransmissions, or it could briefly summarize some of the disadvantages discussed in Section 8.2. The introduction, as well as the abstract, need to mention that this document actually introduces two algorithms, RACK and TLP, and what their relationship is. For example, while they can be implemented separately, are there any dependencies between them? Why is it beneficial to use them together? Note that Section 8.5.1 has wording that suggests that using RACK implies TLP and Section 9 implies that it’s possible to use TLP without RACK. Please consider adding some of these points to the introduction and make sure they’re consistent in the document. Moreover, Section 8.4 discusses the relationship between RACK and TLP at the very end. Please consider moving (some of) this discussion to Section 2 or include a reference to the discussion here. Section 3, Overview: "RACK can be applied to both fast recovery and timeout recovery ..." Timeout recovery refers to recovery after an RTO, correct? Does RACK work the same way for both fast recovery and timeout recovery? This reads a bit confusing to me, because the whole point of RACK seems to be to avoid RTOs, and if an RTO happens, we already know that there has been a packet loss. Section 4, Design Rationale for Reordering Tolerance: "TCP congestion control implicitly assumes the feedback from ACKs are from the same bottleneck" Please consider making the wording a bit clearer: ”... feedback from all ACKs in a connection are from the same bottleneck” - unless I’m missing something here. "How long the sender waits for such potential reordering events to settle is determined by the current reordering window." In this paragraph, it seems to me like the document jumps from general considerations on the impact of RACK on packet reordering to specific design considerations for RACK to mitigate these potential impacts. I think it’s a good idea to make this transition clearer, e.g., by adding text like: "RACK deals with reordering by estimating a reordering window. The way RACK deals with reordering disincentivizes excessive reordering because of the following constraints on the reordering window: ..." If the reordering window is a new concept that RACK introduces, or a concept that was not widely known before, it might be worth explicitly introducing it as a concept. “If no reordering has been observed, then RACK SHOULD honor the classic 3-DUPACK rule for initiating fast recovery. One simple way to implement this is to temporarily override the reorder window to 0.” Just to make sure I understand correctly: Honoring the classic 3-DUPACK rule means detecting a packet lost after receiving 3 dup acks, in addition to detecting packets lost based on timestamps, basically whichever occurs first? It’s not obvious to me how this can be implemented by overriding the reorder window to 0. So perhaps I’m misunderstanding something here and some clarification would help. "...to adaptively estimate the duration of reordering events."  Perhaps it makes sense to add “and adjust the reordering window accordingly” to this sentence, as this part talks about mandates on the reordering window. "As a flow starts, either condition 1 or condition 2 or both would trigger RACK to start the recovery process quickly."  Prior to this sentence, I assumed that the above points were mandates, i.e., all of these criteria must be satisfied by the implementation. But now the text says they are in fact conditions when to declare a packet lost? Are 3 and 4 also conditions? “It also relaxes ordering constraints to allow sending flights of TCP packets on different paths dynamically for better load-balancing (e.g. flowlets).” Please consider adding a reference for “flowlets”. As you discuss design rationale for the reordering window in this section, perhaps it’s worth adding a reference to Section 8.3, which contains more discussion of the reordering window and its default values. Section 6.1, Definitions of variables: (Editorial) This appears to be the only subsection of Section 6. Can this subsection be collapsed into Section 6? As you’re discussing packets and sequence numbers, I think it’s worth adding a few words on how to map TCP segments to packets, e.g., that an implementation might want to store the first and last sequence number of each TCP segment and consider this a packet. This might also be helpful to make the connection between definitions that are based on sequence numbers and others that are based on packets. Please add a definition of Packet.end_seq here, as this variable is used in later sections, but not defined here. For better overview, it might make sense to group variables, e.g., all RTTs, all variables directly related to reordering, all sequence numbers. “The RACK.xmit_ts, RACK.end_seq, RACK.rtt, RACK.reo_wnd, and RACK.min_RTT variables are kept in the per-connection TCP control block. RACK.packet and RACK.ack_ts are used as local variables in the algorithm.” Aren’t RACK.packet and RACK.ack_ts also per-connection? If so, shouldn’t the choice of whether to put these in the per-connection TCP control block or to use them as local variables up to the implementer? (Unless I’m missing something here, in which case please clarify what the difference is between these variables.) Section 7.2, Upon receiving an ACK: Step 1:  "Use the RTT measurements obtained via [RFC6298] or [RFC7323] to update the estimated minimum RTT in RACK.min_RTT." Does this document mandate how to collect individual RTT samples, in which case maybe it’s worth highlighting this with a MUST or SHOULD? Especially as one of the following sentences says "This document does not specify an exact approach", but this might only refer to how to derive the minimum RTT, not the individual RTT samples. Please clarify. Do you perform Step 1 even for packets that you later find to be a spurious retransmission, as this step occurs before the check for spurious retransmissions? Text in later sections reads as if RACK.min_RTT is not updated for spurious retransmissions. In this case, it might be worth merging this step with Step 2 and updating all stats after the check for spurious retransmissions. Step 2: The document first says to record the most recent Packet.xmit_ts if it is ahead of RACK.xmit_ts. Again this is before the check for spurious retransmissions, at least in the text. The pseudocode performs the check first, which makes more sense to me. I think the text should be changed to reflect the pseudocode, if this is indeed the intended order of steps. "... the sender would not be able to update its RACK.min_rtt using the (ambiguous) RTT samples from retransmissions" Possibly this whole example is intended as an exercise for the reader, but just to be clear: Here the point is that the sender is unable to tell whether an ACK for M is from the original transmission or the retransmission, right? And therefore it can’t update the RTT? Please consider making this example a bit more explicit to make it easier to understand. Step 3: Maybe consider substituting “false retransmission” with “spurious retransmission”, as these terms seem to refer to the same concept. Step 4: “RACK starts initially with a conservative window of min_RTT/4" This is RACK.min_RTT, right? Please use the variable name. What is the design rationale for increasing reo_wnd by min_RTT/4, and not more or less, and for persisting for 16 loss recoveries, and not more or less? SRTT refers to the connection's SRTT, defined similarly as in Section 7.5 for TLP, right? Maybe it’s worth adding this as a definition in Section 6 already. "Note that extensions that require additional TCP features (e.g. DSACK) would work if the feature functions simply return false." I’m taking this to basically mean “If you don't implement DSACK or if you don't get DSACK, just return false from these functions and the algorithm below still works”, but I’m unsure if this is correct. Does “extensions that require additional TCP features” refer to the DSACK-based increases of the reordering window? Because “extensions” to me sounds like something that would be defined in another section or another RFC, and that would be explicitly marked as an extension. If the meaning above is correct, please consider making this sentence specific to the example of the DSACK-based increase in reordering window. The pseudocode says that RACK.min_RTT is updated here - but wasn't this step 1 already? Or is RACK.min_RTT updated twice? "If SND.UNA < RACK.rtt_seq: RACK.dsack = false /* React to DSACK once per round trip */" It seems like step 4 is the only part that uses RACK.rtt_seq, but the definition in Section 6.1 says “SND.NXT when RACK.rtt is updated.” Isn’t RACK.rtt updated in Step 2 already? Is this definition (still) correct? Another question about the above pseudocode: Why does this mean that the algorithm reacts once per round trip? What does the round trip have to do with SND.UNA moving above RACK.rtt_seq? Why do you set RACK.reo_wnd_persist to -1 here, and not to 0? Step 5: "the sender MAY install a "reordering settling" timer set to fire at the earliest moment at which it is safe to conclude that some packet is lost" This sounds like a really good idea, so why not make this a SHOULD? "To be more robust to reordering, RACK uses a more conservative RTT value to decide if an unacknowledged packet should be considered lost, RACK.rtt" Is it a SHOULD or a MUST to be this conservative? Or are implementations also free to use RACK.min_RTT? s/RACK.time_ts/RACK.xmit_ts/ For the implementation optimization, maybe just briefly say explicitly that the outcome of your optimization is that you only check packets that have been sent after RACK.xmit_ts, so the advantage is immediately obvious to the reader. Section 7.3, Tail Loss Probe (editorial) Should this be its own section? After all, it is its own separate algorithm? Please consider substituting "Common causes of RTOs include:" with "Common causes of RTOs, which TLP is intended to mitigate, include:" to make the purpose of this section more clear. Section 7.4, Tail Loss Probe: An Example Please consider substituting "Following is an example of TLP" with "Following is an example of TLP used with RACK". Section 7.5, Tail Loss Probe Algorithm Details TLPRxtOut, TLPHighRxt and WCDelAckT seem very different from the variable names used otherwise the document, i.e., they are CamelCase, while underscores are used in most other variables of the document. Also these variable names are really hard to read and pronounce. Unless there’s a good reason to call them exactly that (have they been defined and used in other documents, in which case maybe it’s worth adding a reference?), maybe consider making these variable names more similar. (editorial) The PTO definition should go on a new line, otherwise it's easy to overlook. Section 7.5.1, Phase 1: Scheduling a loss probe: (editorial) There is a lot of nesting here, i.e., “phase 1”, “step 1”, point 1., 2., 3.. Maybe consider restructuring this part, e.g., let phases be different subsections, not subsubsections. (editorial) In the RACK algorithm, you put the description first and then the pseudocode. Here, it's reversed. Maybe it's worth unifying your approach? FWIW, I prefer putting the description first because it makes the pseudocode easier to follow. "A sender should schedule a PTO only if all of the following conditions are met" Is this a “SHOULD NOT schedule a PTO unless all of the following conditions are met”? "2. The connection has no SACKed sequences in the SACK scoreboard" What is the reason for this constraint? "The RECOMMENDED value for WCDelAckT is 200ms." Why this value and not another? s/If FlightSize = 1/If FlightSize == 1/ Section 7.5.2, Phase 2: Sending a loss probe: SMSS is used here, but not defined. Please expand and add a definition. Please clarify here already that while you allow only one TLP retransmission to be in flight at a time, you allow multiple TLP new data to be in flight. This is said later, but it is already relevant for understanding this part. As you don't allow multiple TLP retransmits to be in flight: Does this mean the PTO could fire but then you do not send any data, because there is no new data available but there is already a TLP retransmit in flight? "the sender MUST arm the RTO timer, not the PTO timer, at the end of TLP_send_probe() if FlightSize is not zero." Please add this to the pseudocode. "Checking TLPRxtOut prior to sending the loss probe is also critical to avoid TLP loops if an application writes periodically at an interval less than PTO." What is a TLP loop? And why would it occur if an application writes periodically at an interval less than PTO? Please consider adding a definition. Section 7.5.3: Phase 3: ACK processing Isn’t this phase a special case of phase 1? “Phase” implies that these occur one after the other. Section 7.6: TLP recovery detection Is this still part of the TLP algorithm? If so, why is it a new subsection and not in the “TLP algorithm details” section, and not referenced from it? Or is this an optional addition/extension? To make the purpose of this algorithm clearer early on, please consider briefly stating in the first paragraph that this introduces an algorithm to detect whether a packet loss occurred or not, i.e., whether both the original packet and the TLP arrived, or whether one of them got lost, therefore, it's a loss, therefore, you have to reduce cwnd. Section 7.6.3, Detecting recoveries accomplished by loss probes: What is the relationship between this Step 1, 2, 3, and Phase 1, 2, 3 above? Consider rethinking your structure to make clear what happens when. If “Step” and “Phase” refer to the same concept, please consider unifying your terminology. For condition 1: Why does this include "the segment contains no data" and "the segment is not a window update"? (Why) Is it not possible to detect recovery if either of these is true? Condition 1 refers to a dup ack for the TLP retransmission, right? And receiving this dup ack implies the TLP retransmission was spurious? (I’m just trying to make sure I understand correctly, but maybe it's worth adding this to the draft to make it easier to follow.) Condition 2 uses DSACK, but you previously say "Since a significant fraction of the hosts that support SACK do not support duplicate selective acknowledgments (D-SACKs) [RFC2883] the TLP algorithm for detecting such lost segments relies only on basic SACK support [RFC2018]." This seems to be at odds. Isn't it rather "with DSACK you can make this detection more accurate, if you don't have it you have to rely on condition 1 only"? Please consider rephrasing the sentence starting with “Since a significant fraction…” The last sentence of step 1 says:  "... so the sender considers the TLP episode to be done, and records that fact by setting TLPRxtOut to false."  Isn't this already part of step 2, "Mark the end of a TLP retransmission episode and detect losses"? Should this part be moved to step 2? "...it SHOULD invoke a congestion control response equivalent to fast recovery." Is this really a SHOULD or is this a MUST? Because the document also says, "If the TLP sender does not receive such an indication before the end of the TLP retransmission episode, then it MUST estimate that either the original data segment or the TLP retransmission were lost, and congestion control MUST react appropriately to that loss as it would any other loss." Section 8.1, Advantages: "Suppose the transmission of each packet is at least RACK.reo_wnd (1 millisecond by default)" Isn't the window RTT_min/4 by default? I think this is what it says above. I am not seeing the 1 millisecond mentioned in any other part of the document. "This example illustrates how RACK is able to repair certain drops at the tail of a transaction without any timer." What do you mean by “without any timer”? RACK does potentially use timers, doesn't it? Did you mean a specific timer here, like "without PTO" or "without RTO"? Section 8.3, Adjusting the reordering window: "... the Performance evaluation section ..." Maybe consider adding a reference to this section. Section 8.4, Relationships with other loss recovery algorithms At the very end, this section discusses the relationship between RACK and TLP. As this document introduces both algorithms, consider moving this discussion somewhere further up in the document. Alternatively, please at least mention the existence of this discussion earlier in the document and add a reference to the section of this discussion. Section 8.5, Interaction with congestion control "RACK may detect losses faster or slower than the conventional duplicate ACK threshold approach does. RACK can detect losses faster by not requiring three DUPACKs, so congestion control may reduce the congestion window earlier." Does this text imply that RACK can be used without the three dup ack threshold? This seems to be at odds with other parts of the document, which clearly state that RACK implies reacting to three dup acks. If RACK indeed implies using the three dup ack threshold, is this paragraph still true? Similar to my comment on Section 2, please consider briefly clarifying whether “interaction” means using two algorithms within the same sender, or whether this is about coexistence of different senders. Section 8.5.1, Example: interactions with congestion control "With RACK, a sender would send the TLP after 2*RTT" This reads as if RACK does imply TLP? Section 8.7, RACK for other transport protocols "The algorithm can be simplified by skipping step 3 " Please consider just briefly clarifying if you mean step 3 of RACK, "Detect packet reordering". In fact, why does it mean that? Even if you have unique transmission or packet identifiers, reordering might still occur, right? So don’t we still have to detect packet reordering? Section 9, Experiments and Performance Evaluations “We plan to expand our experiments to regions with worse connectivity, in particular on networks with strong traffic policing."  Just curious: Have these experiments actually taken place? Section 10, Security Considerations "An interesting scenario is ACK-splitting attacks" Maybe start the paragraph with something saying "In fact, RACK lowers the risk profile because it prevents the following attack"? But then it does change the risk profile, which seems to be at odds with the first sentence of this section. This concludes my review. Again, thank you for this draft. Best, Theresa Enghardt From nobody Mon Apr 6 05:41: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 C11B83A07AA for ; Mon, 6 Apr 2020 05:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, 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 9lrPmEROUmvB for ; Mon, 6 Apr 2020 05:40:52 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2073.outbound.protection.outlook.com [40.107.22.73]) (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 C0AD83A07A9 for ; Mon, 6 Apr 2020 05:40:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8gdKaDxjGlwY0pDKDZEBJpiYcwZQYerqk5FMaVdBLVvD4RIkI2I2b6YdbHIcwM0IhBtYFYlDMykIiWsLXax2+2WexwKdp2N0PAsyTzS+4agTSXqiJn87+fDNL92hJVFaiVZe86ryvdn2+eEpczs611X2ZShwBuFlABXdUTupXyiR0j8nC1WKxRV2/hY7faVinfXvg5WtqCnHqnw0z6d3LcRYndgx8v1iT+abaWDf9qlPf4buRb/psVKDcktXdXEMZznFXz1jAXHpQjuZwRBO4oHj/cP5jK0E2bMf+xCVVjJGen4dGapDEswHzXmiw8vHVXE+xTfQrrDJ2gEeI5kgA== 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=VLwsO8RNILe3F4/kBoXdNybga+g63zZkzhGZRhqfhO4=; b=hQlg3VhftJgPwlCTm/LXIcwK7xWAgcFsPZv9mlk8qHArKHf4VbFUpCl794B7UF/r4qLF9xZKN+NEb9OjgAnrmiWPhbQIuYbINTpScdp97PBT4UVphHerHgElEZKOPPwrFu/NR5OJYX7vriy7us62zZrqLwfdwlQYz2hhVRE4nufLBpm22zOsw55V4BLRo06vI2jagmmGjumxR/MrOki6MDle5OAAJ/EqKCMhSKA1Bpo8rjt6zzbU42q0CM214jxjQMKjfgAy/2pqlRF8fOTcFgM/jxhgzMexQ15uXVRMr8OcolGpR+sATzXDPlg5zKo1bkR6EigR+MSQuzY+4YroVQ== 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=VLwsO8RNILe3F4/kBoXdNybga+g63zZkzhGZRhqfhO4=; b=Q3k5Cs76OMYHM+DNpM3zDuTpfNrB9FA2PsLhcTli5fl1BZCrY4Xdn9ttJakxWf6aXfbw1Q5PKC9jfphC1O4IRujQgxwo80IdIGUhi+5RpvV4thLktr/vkJcpVKIwlNeOrpxj3mYpVAzRkB2NAaQgrFgWKnO6/QQpV84w38iq9CA= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4084.eurprd07.prod.outlook.com (52.134.81.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Mon, 6 Apr 2020 12:40:45 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::298a:36c6:fff4:f8f8]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::298a:36c6:fff4:f8f8%3]) with mapi id 15.20.2900.012; Mon, 6 Apr 2020 12:40:45 +0000 From: Mirja Kuehlewind To: Michael Tuexen , tcpm IETF list Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-rack-08 Thread-Index: AQHWBuKWELjW9re2QEma+q+W/mNu5qhsNO8A Date: Mon, 6 Apr 2020 12:40:44 +0000 Message-ID: References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> In-Reply-To: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2003:de:e727:100:38a5:2983:a284:b7fb] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5cb6d51-13cb-4516-acac-08d7da27b9b4 x-ms-traffictypediagnostic: AM0PR07MB4084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(71200400001)(316002)(110136005)(6486002)(6506007)(2616005)(6512007)(186003)(44832011)(478600001)(5660300002)(81156014)(966005)(8936002)(81166006)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(8676002)(36756003)(2906002)(33656002)(86362001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XMydj+rJtfEvWstmFVMxMHxdOmsTBs5n4uFbvty05pVj5I8SgnfUSL4tGDg/+kJekcAs4s1LkRLPL1uQB1fpUa1At9Qrq17hi7y1kk4Hq+Yju+v2pstuqeySoXVvlwQwdcxrlY4V76ZzRZLXfL+FmzNqM7ajxEIxvdMZ+jQQS4f4xn2/9HnJAmLqYeIIwvg2fmnXivjtmgxkZjBQGkitL8WeCPE+eWQ+uISctVhj9bTQxCnSX/VWmCDGgTmKUbvUIpVkxF2eqTK1tFFHljzSrL7j4Nj5dZO049gufJT1tso5cJNohq+Gfjxt2Q1ICGUy/qHmTDiqFwjJVEmS+wySxrN5A2BCsEXNMeLW+rSl9uy2gtk/zbdvyfFKra3ehi8mvw3SyxiApGfsur17mvH0F4zJFrh7+isfzvItfGYN1QA0teoXCvkcy5Vs10Fjb3chEukEW+VnJpXgm5MzZ+4gquGot4k/JMBT9WQ2UrphqHMynGrxB1vI8QlJbjVIfCLzL/CocRnl83zg3HZKbjWerw== x-ms-exchange-antispam-messagedata: 2NVhJWPPrmiphWa1r+Z9hk9924rr8nrWsfpUVsn1i/7jOrJAlZswDJCBximu1cWPev3AIBHGU1ttxZ4zVoSgW3ymKN4Ye2qXTihxU+HvdDPtnicUiAKgYzehVhh2jGka2snBB4k7OhVlZ9JAnYHHZl1dYkwCx4yrG257tjXIK2L/6IoaHNx758JVVGCO2qAoHkf2yaqaWhZ1Midq9W2weA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6380D66793771542923CE5063B42E3B2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5cb6d51-13cb-4516-acac-08d7da27b9b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 12:40:44.9850 (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: 177WlGXC6HZpihwV6zybC+7xwBFk/NlIAO5xMZTmvykgBIN2iH+g1sFZUvNrd0Q4X/mE0hseev77eqWTdVKsqnUPKml77DcSBIGYu6d94zU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4084 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 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, 06 Apr 2020 12:40:58 -0000 SGkgYWxsLA0KDQpJIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIEkgdGhpbmsgY29udGVudC13 aXNlIHRoaXMgaXMgcmVhZHkgdG8gbW92ZSBvbiAoanVzdCBzb21lIHNtYWxsIHF1ZXN0aW9ucyBi ZWxvdykuDQoNCkkgd291bGQgbGlrZSB0byBzZWUgYW5vdGhlciBlZGl0b3JpYWwgcGFzcyBvbiB0 aGUgZG9jdW1lbnQuIFRoZXJlIGFyZSBtb3JlIGRldGFpbCBjb21tZW50cyBiZWxvdyBidXQgSSB0 aGluayB0aGUgbWFpbiBwb2ludHMgYXJlIGEpIHByb3ZpZGUgYSBtb3JlIGRldGFpbGVkIGFsZ29y aXRobSBvdmVydmlldyBzZWN0aW9uIChlaXRoZXIgaW4gc2VjdGlvbiAzIG9yIGJlZ2lubmluZyBv ZiBzZWN0aW9uIDcgdG8gbWFrZSBpdCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB0aGUgc3RlcHMgaW4g dGhlIHN1YnNlY3Rpb25zIGluIDcgYW5kIGIpIGhhdmUgYW4gb3duIG1haW4gc2VjdGlvbiBmb3Ig VExQIGFuZCBpbnRyb2R1Y2UgcGFyYW1ldGVycyB1c2VkIGZvciBUTFAgYWxzbyBpbiBzZWN0aW9u IDYgYW5kIG1lbnRpb24gVExQIGluIHRoZSBpbnRybyBhbHJlYWR5LiBJdCdzIHN0aWxsIG9idmlv dXMgdGhhdCBUTFAgd2FzIHNxdWVlemVkIGluIGxhdGVyIG9uLi4uLg0KDQpGdXJ0aGVyIEkgdGhp bmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGNvdWxkIGJlIG1vcmUgZXh0ZW5zaXZlOiBp dCBjb3VsZCBhKSBtZW50aW9uIGFnYWluIHNvbWUgb2YgdGhlIHJlb3JkZXJpbmcgY29uc2lkZXJh dGlvbiBpbiBzZWN0aW9uIDQgKG9yIG1heWJlIHNvbWUgb2YgdGhlIHRleHQgY2FuIGJlIG1vdmVk IHRoZXJlIGVudGlyZWx5IHRvIG5vdCBicmVhayB0aGUgcmVhZGluZyBmbG93IHNvIG11Y2ggYXQg dGhlIGJlZ2lubmluZyBvZiB0aGUgZG9jKSBhbmQgYikgc2F5IG1vcmUgYWJvdXQgdGhlIGltcGFj dCBvZiB0aGlzIGFsZ29yaXRobSBvbiBzcHVyaW91cyByZXRyYW5zbWlzc2lvbiAoSSBndWVzcyBp dCBjYW4gYm90aCBpbmNyZWFzZSBvciBkZWNyZWFzZSB0aGUgbnVtYmVyIG9mIHNwdXJpb3VzIHJl dHJhbnNtaXNzaW9ucyBpbiBjZXJ0YWluIHNjZW5hcmlvcykgYW5kIGMpIG1lbnRpb24gYWdhaW4g dGhlIGltcGFjdCBvbiBjb25nZXN0aW9uIGNvbnRyb2wgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24g OC41IHRoYXQgYSB3aW5kb3cgcmVkdWN0aW9uIGNhbiBoYXBwZW4gYm90aCBlYXJsaWVyIG9yIGxh dGVyIGluIGRpZmZlcmVudCBzY2VuYXJpb3MuDQoNCkhlcmUgYXJlIG15IHRlY2huaWNhbCBxdWVz dGlvbnMvY29tbWVudHMgb24gc2VjdGlvbiA3LjI6DQoNCkZvciB0aGlzIHNlbnRlbmNlOg0KIklm IG5vIHJlb3JkZXJpbmcgaGFzIGJlZW4gb2JzZXJ2ZWQsIFJBQ0sgdXNlcw0KICAgUkFDSy5yZW9f d25kIG9mIDAgZHVyaW5nIGxvc3MgcmVjb3ZlcnksIGluIG9yZGVyIHRvIHJldHJhbnNtaXQNCiAg IHF1aWNrbHksIG9yIHdoZW4gdGhlIG51bWJlciBvZiBEVVBBQ0tzIGV4Y2VlZHMgdGhlIGNsYXNz aWMgRFVQQUNLDQogICB0aHJlc2hvbGQuIg0KDQpBbmQgdGhlIHJlc3BlY3RpdmUgcHNldWRvIGNv ZGUgaGVyZToNCiAgICAgICBJZiBSQUNLLnJlb3JkIGlzIEZBTFNFOg0KICAgICAgICAgICBJZiBp biBsb3NzIHJlY292ZXJ5OiAgLyogSWYgaW4gZmFzdCBvciB0aW1lb3V0IHJlY292ZXJ5ICovDQog ICAgICAgICAgICAgICBSQUNLLnJlb193bmQgPSAwDQogICAgICAgICAgICAgICBSZXR1cm4NCiAg ICAgICAgICAgRWxzZSBpZiBSQUNLLnBrdHNfc2Fja2VkID49IFJBQ0suZHVwdGhyZXNoOg0KICAg ICAgICAgICAgICAgUkFDSy5yZW9fd25kID0gMA0KICAgICAgICAgICAgICAgUmV0dXJuDQoNCk15 IHVuZGVyc3RhbmRpbmcgaGVyZSBpcyB0aGF0IHRoZSBSQUNLLWJhc2VkIHRpbWUgdGhyZXNob2xk IHNob3VsZCBub3QgYmUgdXNlZCBpZiBpbiByZWNvdmVyeSBvciBpZiBubyByZW9yZGVyaW5nIGlz IGRldGVjdGVkLCByaWdodD8NCg0KV2h5IGlzIHRoYXQgcmVhbGl6ZWQgYnkgc2V0dGluZyB0aGUg UkFDSy5yZW9fd25kIHRvIHplcm8gcmF0aGVyIHRoYW4gaW1wbGVtZW50aW5nIHRoaXMgbG9naWMg aW4gUkFDS19kZXRlY3RfbG9zcygpPyBJIHRoaW5rIHRoZSBkaWZmZXJlbmNlIHdvdWxkIGJlIHRo YXQgeW91IGRvbid0IHJlc2V0IFJBQ0sucmVvX3duZCBidXQga2VlcCB0aGUgcHJldmlvdXMgc3Rh dGUgYWJvdXQgYWRqdXN0bWVudHMuIEJ1dCB3b3VsZG4ndCB0aGF0IGJlIGdvb2QvYmV0dGVyPw0K DQpNeSBwb2ludCBpdCB0aGF0IHRoZSB3YXkgaXQgaXMgZGVzY3JpYmVkIG5vdyBjb25mdXNlZCBt ZSBhIGJpdCBhbmQgSSdtIGxvb2tpbmcgZm9yIGEgd2F5IHRvIGJldHRlciBkZXNjcmliZSB0aGF0 IHBhcnQuLi4NCg0KQWxzbyB3aHkgaXMgUkFDSy5kdXB0aHJlc2ggYSBzZXBhcmF0ZSBwYXJhbWV0 ZXIgaW4gdGhlIFJBQ0sgbmFtZSBzcGFjZSBpbnN0ZWFkIG9mIHVzaW5nIHRoZSAiZXhpc3Rpbmci IG9uZSAoYXMgeW91IGRvIHdpdGggUGFja2V0LiB4bWl0X3RzKT8gRnVydGhlciB0aGlzIGlzIGFj dHVhbGx5IG5vdCBhIHBhcmFtZXRlciB0aGF0IGlzIGFkanVzdGVkIGJ5IHRoZSBhbGdvcml0aG0g YnV0IGEgY29uZmlndXJlZCBjb25zdGFudC4gSXQgYmUgaGVscGZ1bCBmb3IgdGhlIHJlYWRlciB0 byBpbmRpY2F0ZSB0aGlzIGluIHRoZSBuYW1pbmcsIGUuZy4gY2FsbCBpdCBEVVBUSFJFU0ggaW5z dGVhZC4gSW4gZ2VuZXJhbCBJJ20gYWN0dWFsbHkgbm90IHN1cmUgdGhhdCB1c2luZyB0aGUgUkFD SyBuYW1lIHNwYWNlIGluIHRoaXMgZG9jdW1lbnQgaXMgcmVhbGx5IGhlbHBmdWwuDQoNCkFuZCBh bm90aGVyIHVucmVsYXRlZCBxdWVzdGlvbiBidXQgb24gdGhlIHNhbWUgcGFydCBvZiB0aGUgYWxn b3JpdGhtOiB3aGVyZSBkb2VzIHRoZSBudW1iZXIgMTYgY29tZSBmcm9tIGZvciB0aGUgbnVtYmVy IG9mIHJlY292ZXJ5IGN5Y2xlcyB0byBrZWVwIGFueSBhZGFwdGF0aW9uPw0KDQpUaGVuIG15IG1v cmUgZGV0YWlsZWQgKHNtYWxsIGFuZCBsYXJnZXIpIGVkaXRvcmlhbCBjb21tZW50czoNCg0KMSkg SW4gdGhlIGludHJvIHlvdSB1c2UgIGEgY291cGxlIG9mIHRpbWVzICJ3ZSIgd2hpY2ggaXMgbWF5 YmUgbGVzcyBjb21tb24gaW4gUkZDcyBhcyBhbiBSRkMgaXMgYSBwcm9kdWN0IG9mIGEgd2cgbm90 IG9ubHkgb2YgdGhlIGF1dGhvciBncm91cC4gTWF5YmUgeW91IGNhbiByZXBocmFzZSB0aGlzLg0K DQoyKSBhbHNvIGluIHRoZSBpbnRybzoNCiJUaGUgZ29hbCBvZiBSQUNLIGlzIHRvIHNvbHZlIGFs bCB0aGUgcHJvYmxlbXMuLi4iDQpNYXliZQ0KIlRoZSBnb2FsIG9mIFJBQ0sgaXMgdG8gYWRkcmVz cyBhbGwgdGhlIHByb2JsZW1zLi4uIg0KDQozKSBTZWN0aW9uIDMgcHJvdmlkZXMgcmF0aGVyIGEg aGlnaCBsZXZlbCBvdmVydmlldy4gSXQgd291bGQgYmUgbmljZSB0byBnZXQgbW9yZSBvZiBhbiBv dmVydmlldyBhYm91dCB0aGUgYWxnb3JpdGhtIGl0c2VsZiwgZS5nLiBleHBsYWluaW5nIHRoZSBk aWZmZXJlbnQgc3RlcCBkZXNjcmliZWQgaW4gc2VjdGlvbiA3IG9uIGEgaGlnaCBsZXZlbC4gT3Ig bWF5YmUgeW91IGNvdWxkIGFkZCBhbHRlcm5hdGl2ZWx5IG1vcmUgdGV4dCBhdCB0aGUgYmVnaW5u aW5nIG9mIHNlY3Rpb24gNyBleHBsYWluaW5nIGhvdyB0aGUgZGlmZmVyZW50IHN1YnNlY3Rpb25z ICJmaXQgdG9nZXRoZXIiLiBBY3R1YWxseSBkb2luZyBib3RoIHdvdWxkIGFsc28gbm90IGh1cnQg YXMgc29tZSByZWR1bmRhbmN5IHdoZXJlIHlvdSBnbyBzdGVwIGJ5IHN0ZXAgaW4gbW9yZSBkZXRh aWxzIGlzIG9mdGVuIHJlYWxseSBoZWxwZnVsIGZvciB0aGUgcmVhZGVyLg0KDQo0KSBTZWN0aW9u IDQgSSBmaXJzdCB0aG91Z2h0IHRoYXQgc29tZSBvZiB0aGlzIHRleHQgY291bGQgYWN0dWFsbHkg Z28gaW50byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIGhvd2V2ZXIsIEkgZ3Vlc3MgdGhl cmUgYXJlIGFsc28gc29tZSByZXF1aXJlbWVudCBoZXJlLCBzbyBub3Qgc3VyZSBpZiB0aGF0IGNv dWxkIGJlIHNwbGl0dGVkIHVwIHNvbWVob3cuIEkgdGhpbmsgdGhlIHByb2JsZW0gSSBoYXZlIGhl cmUgaXMgdGhhdCBpcyBicmVha3MgcXVpdGUgYSBiaXQgdGhlIHJlYWRpbmcgZmxvdyBiZXR3ZWVu IHRoZSBvdmVydmlldyBzZWN0aW9uIGFuZCB0aGUgYWN0dWFsIGFsZ29yaXRobSBwYXJ0LiANCg0K NSkgSSBmaW5kIHRoZSBuYW1pbmcgb2YgYm90aCBSQUNLLnJlb193bmQgYW5kIFJBQ0sucmVvX3du ZF9pbmNyIGEgYml0IGNvbmZ1c2luZywgYXMgUkFDSy5yZW9fd25kIGlzIGEgdGltZSAgZnJhbWUg KGFuZCBJIHdvdWxkIGV4cGVjdCBhIHBhY2tldCB3aW5kb3cgYmFzZWQgb24gdGhlIG5hbWluZywg Z2l2ZW4gd2UgaGF2ZSB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgb3IgdGhlIHJlY2VpdmVkIHdpbmRv dykgYW5kIFJBQ0sucmVvX3duZF9pbmNyIGlzIGEgbXVsdGlwbGllciAoYW5kIEkgd291bGQgZXhw ZWN0IHNvbWUgdmFsdWUgdGhhdCB3b3VsZCBiZSBhZGRlZCB3aGVuICJpbmNyIiBpcyB1c2VkKQ0K DQo2KSA3LjI6DQoiICAgU29tZXRpbWVzIHRoZSB0aW1lc3RhbXBzIG9mIFJBQ0suUGFja2V0IGFu ZCBQYWNrZXQgY291bGQgY2FycnkgdGhlDQogICBzYW1lIHRyYW5zbWl0IHRpbWVzdGFtcHMgZHVl IHRvIGNsb2NrIGdyYW51bGFyaXR5IG9yIHNlZ21lbnRhdGlvbg0KICAgb2ZmbG9hZGluZyAoaS5l LiB0aGUgdHdvIHBhY2tldHMgd2VyZSBoYW5kZWQgdG8gdGhlIE5JQyBhcyBhIHNpbmdsZQ0KICAg dW5pdCkuICBJbiB0aGF0IGNhc2UgdGhlIHNlcXVlbmNlIG51bWJlcnMgb2YgUkFDSy5lbmRfc2Vx IGFuZA0KICAgUGFja2V0LmVuZF9zZXEgYXJlIGNvbXBhcmVkIHRvIGJyZWFrIHRoZSB0aWUuIg0K VGhlIHRleHR1YWwgZGVzY3JpcHRpb24gaXMgbm90IGZ1bGx5IGNsZWFyIHRvIG1lIChwc2V1ZG8g Y29kZSBpcyBmaW5lKS4gSSBndWVzcyB0aGlzIHRleHQgaXMgaW4gdGhlIGNvbnRleHQgb2YgdXBk YXRlIFJBQ0suUGFja2V0IGl0c2VsZiwgcmlnaHQ/IE1heWJlIHRoYXQgdGhlIG1pc3NpbmcgcGFy dCB0aGF0IHNob3VsZCBiZSBzcGVsbGVkIG91dC4NCg0KNykgSSB3b3VsZCByZWNvbW1lbmQgdG8g aGF2ZSBzZWN0aW9uIDcuMy4gdG8gNy42IGluIHRoZWlyIG93biBuZXcgbWFpbiBzZWN0aW9uIGFz IGl0IGlzIGFuIHN1cHBsZW1lbnRhbCBidXQgc2VwYXJhdGUgYWxnb3JpdGhtLiBGdXJ0aGVyIEkg d291bGQgYWxzbyByZWNvbW1lbmQgdG8gbWVudGlvbiBUYWlsIExvc3MgUHJvYmUgYWxzbyBpbiB0 aGUgYWJzdHJhY3QgYW5kIGludHJvLg0KDQo4KSBTZWN0aW9uIDcuNTogQXQgbGVhc3QgU1JUVCB3 YXMgYWxyZWFkeSB1c2VkIGVhcmxpZXIgb24gaW4gdGhlIGRvYywgc28gbWF5YmUganVzdCBhZGQg YWxsIHRoZXNlIGRlZmluaXRpb25zIHRvIHNlY3Rpb24gNi4xPw0KDQo5KSBTZWN0aW9uICA4LjE6 DQoiIFRoZSBleGFtcGxlcyBhYm92ZSBzaG93IHRoYXQgUkFDSyBpcyBwYXJ0aWN1bGFybHkgdXNl ZnVsIHdoZW4gdGhlDQogICBzZW5kZXIgaXMgbGltaXRlZCBieSB0aGUgYXBwbGljYXRpb24sIHdo aWNoIGlzIGNvbW1vbiBmb3INCiAgIGludGVyYWN0aXZlLCByZXF1ZXN0L3Jlc3BvbnNlIHRyYWZm aWMuIg0KSSB0aGluayB0aGF0IGlzIGFjdHVhbGx5IGFuIGltcG9ydGFudCBwb2ludCB0byBtYWtl IGluIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIGRvY3VtZW50Lg0KDQoxMCkgQWxzbyBzZWN0aW9u IDguMjoNCiIgICBSQUNLIGNhbiBlYXNpbHkgYW5kIG9wdGlvbmFsbHkgc3VwcG9ydCB0aGUgY29u dmVudGlvbmFsIGFwcHJvYWNoIGluDQogICBbUkZDNjY3NV1bUkZDNTY4MV0gYnkgcmVzZXR0aW5n IHRoZSByZW9yZGVyaW5nIHdpbmRvdyB0byB6ZXJvIHdoZW4NCiAgIHRoZSB0aHJlc2hvbGQgaXMg bWV0LiAgTm90ZSB0aGF0IHRoaXMgYXBwcm9hY2ggZGlmZmVycyBzbGlnaHRseSBmcm9tDQogICBb UkZDNjY3NV0gd2hpY2ggY29uc2lkZXJzIGEgcGFja2V0IGxvc3Qgd2hlbiBhdCBsZWFzdCBEdXBU aHJlc2gNCiAgIGhpZ2hlci1zZXF1ZW5jZSBwYWNrZXRzIGFyZSBTQUNLZWQuIC4uLiINCkFsc28g dGhpcyBpbmZvcm1hdGlvbiB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bCBpbiB0aGUgb3ZlcnZpZXcg c2VjdGlvbiBhbHJlYWR5Lg0KDQoxMSkgQWxzbyBvbiBib3RoIHNlY3Rpb25zIDguMS4gYW5kIDgu MiwgSSBmaW5kIHRoZSBzZWN0aW9uIHRpdGxlcyBub3QgdmVyeSB3ZWxsIHN1aXRhYmxlLiBJIHdv dWxkIG1heWJlIHN1Z2dlc3QgdG8gcmVhcnJhbmdlIHRoZSBjb250ZW50IGEgYml0IGFuZCBoYXZl IGEgc2VjdGlvbiAiRXhhbXBsZXMgd2hlcmUgUkFDSyAoYW5kIFRMUCkgaXMgYmVuZWZpY2lhbCIg YW5kIGFub3RoZXIgc2VjdGlvbiBvbiAiSW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlvbnMiLiBB dCBsZWFzdCBmb3IgIHRoZSBleGFtcGxlcyBzZWN0aW9uIEkgd291bGQgcmVjb21tZW5kIHRvIHVz ZSBhbiBvd24gc3Vic2VjdGlvbi4NCg0KMTIpIE1heWJlIHJlbmFtZSBzZWN0aW9uIDguMyB0byAi UmVhc29uaW5nIGZvciBiYXNpYyByZW9yZGVyaW5nIHdpbmRvdyBzaXplIiAoaW5zdGVhZCBvZiAi IEFkanVzdGluZyB0aGUgcmVvcmRlcmluZyB3aW5kb3ciLi4uPw0KDQoxMykgU2VjdGlvbiA4LjQ6 DQoiIEZ1cnRoZXJtb3JlLCBSQUNLIG5hdHVyYWxseSB3b3JrcyB3ZWxsIHdpdGggVGFpbCBMb3Nz IFByb2JlIFtUTFBdIg0KVGhpcyByZWZlcmVuY2Ugc2hvdWxkIGJlIHJlbW92ZWQgYXMgY29udGVu dCB3YXMgaW50ZWdyYXRlZCBpbnRvIHRoaXMgZG9jdW1lbnQuIE1heWJlIHRoZSB3aG9sZSBwYXJh Z3JhcGggc2hvdWxkIGJlIHJlcGhyYXNlZCwgcmVtb3ZlZCBlbnRpcmVseSwgb3IgbW92ZWQgaW50 byB0aGUgVExQIHNlY3Rpb24uDQoNCjE0KSBTZWN0aW9uIDguNS4xOg0KIiBXaXRob3V0IFJBQ0ss IHRoZSBzZW5kZXIgd291bGQgdGltZSBvdXQsIC4uLiINCkkgc3VnZ2VzdCB0byBzYXkgIldpdGhv dXQgUkFDSyBhbmQgVExQLC4uLiIgYXMgVExQIGlzIGRlc2NyaWJlZCBhcyBhIHNlcGFyYXRlIG9w dGlvbmFsIGFsZ29yaXRobSBidXQgVExQIGlzIHRoZSBpbXBvcnRhbnQgYml0IGhlcmUuIEFsc28g SWYgeW91IGRlY2lkZSB0byBoYXZlIGEgc2VwYXJhdGUgZXhhbXBsZSBzZWN0aW9uLCBJIHdvdWxk IHN1Z2dlc3QgdG8gbW92ZSB0aGlzIGV4YW1wbGUgdGhlcmUgYXMgd2VsbC4NCg0KMTUpIFNob3Vs ZCBzZWN0aW9uIDkgc3RheSBpbiB0aGUgZmluYWwgUkZDPyBJZiBzbywgSSByZWNvbW1lbmQgdG8g bW92ZSBpdCBpbnRvIHRoZSBhcHBlbmRpeC4gSG93ZXZlciwgaXQgd291bGQgYWxzbyBiZSBuaWNl IHRvIGFsc28gcHJvdmlkZSByZXN1bHRzIG9uIHRoZSBudW1iZXIgb2YgcmV0cmFuc21pc3Npb25z IChoYXZlIHRoZXkgaW5jcmVhc2VkIHdpdGggUkFDSyBhbmQgVExQPykuIEFsdGVybmF0aXZlbHkg SSBzdWdnZXN0IHJlbW92aW5nIHRoaXMgc2VjdGlvbiBhbmQgcG9pbnQgdG8gc29tZSBwYXBlciBt YXliZT8NCg0KMTYpIEkgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGNvdWxkIGJl IG1vcmUgZXh0ZW5zaXZlLCBjb3ZlcmluZyBpbXBhY3Qgb24gcmVvcmRlcmluZywgc3B1cmlvdXMg cmV0cmFuc21pc3Npb24sIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wsIGFzIEkgc2FpZCBhdCB0aGUg dG9wIG9mIHRoaXMgbWFpbC4NCg0KVGhhbmtzIQ0KTWlyamENCg0KDQoNCu+7v09uIDMxLjAzLjIw LCAwMDoyOCwgInRjcG0gb24gYmVoYWxmIG9mIE1pY2hhZWwgVHVleGVuIiA8dGNwbS1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiB0dWV4ZW5AZmgtbXVlbnN0ZXIuZGU+IHdyb3RlOg0KDQog ICAgRGVhciBhbGwsDQogICAgDQogICAganVzdCBhIHF1aWNrIHJlbWluZGVyOg0KICAgIA0KICAg IFdlIGFyZSBjdXJyZW50bHkgcnVubmluZyBhIFdHTEMgZm9yIFRDUCBSQUNLIHVudGlsIFR1ZXNk YXksIEFwcmlsIDd0aCAyMDIwLg0KICAgIA0KICAgIFBsZWFzZSBzZW5kIGFueSBjb21tZW50cywg aW5jbHVkaW5nIGluZGljYXRpb25zIHRvIHN1cHBvcnQgdGhpcyBkb2N1bWVudCwNCiAgICB0byB0 aGUgVENNUCBtYWlsaW5nIGxpc3QgYnkgdGhlbi4NCiAgICANCiAgICBUaGUgSUQgaXMgYXZhaWxh YmxlIGF0DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1y YWNrLTA4DQogICAgDQogICAgQmVzdCByZWdhcmRzDQogICAgTWljaGFlbA0KICAgIA0KICAgIA0K ICAgIA0KDQo= From nobody Mon Apr 6 08:24:41 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 A8B293A0A2F for ; Mon, 6 Apr 2020 08:24:23 -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 oMtq7dygGzNT for ; Mon, 6 Apr 2020 08:24:21 -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 D991C3A0AFA for ; Mon, 6 Apr 2020 08:22:37 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 89AD11B0012D; Mon, 6 Apr 2020 16:22:33 +0100 (BST) To: tcpm IETF list References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> Cc: Michael Tuexen From: Gorry Fairhurst Message-ID: <7e9fb383-15d8-b613-2fcb-ea7de9c46ef2@erg.abdn.ac.uk> Date: Mon, 6 Apr 2020 16:22:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 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, 06 Apr 2020 15:24:24 -0000 I reviewed the latest version of RACK as a part of the TCPM WGLC. I do not think this is ready. I think the specification is important, but the document has many editorial issues. These issues seem to be very important and I do not think the current document is ready to proceed without a revision being prepared that can be properly reviewed. Overall I am concerned that this draft provides little evidence or justification for the proposed change to an existing PS. I do not argue against the proposal, but  I do suggest the justification and trade-offs involved needs to be clear before the IETF should publish such a specification. Some of the comments below could be fixed by editorial work, but as currently written this makes many bold statements about IETF consensus that I would not agree with. Many of these could be easily rephrased too focus only on the topics being standardised, or by providing appropriate evidence for the claims. Specific comments follow - some issues I will highlight in a separate mail. Gorry Section 2: — I do not see a reference that offers data for this: In recent years we have been observing several increasingly common loss and reordering patterns in the Internet. - Can you explain who “we” are and where this has been published or presented? I’d be quite comfortable if this said “in recent tears there is an increasing concern about the implications of loss or reordering” - but the present set asserts this is common, so I ask for evidence please? — This is not explained: “ Structured request-response traffic turns more losses into tail drops.” - I don’t think the losses are turned into tail drops, maybe the losses are observed at the tails of transmission? — This is not justified: “ Despite TCP stacks (e.g.  Linux) that implement many of the standard    and proposed loss detection algorithms [RFC4653][RFC5827][RFC5681][RFC6675][RFC7765][FACK][THIN-STREAM], we've found that together they do not perform well. “ - Can you explain who “we” are and where this has been published/presented? — This sentence doesn’t read well: “They can either detect loss    quickly or accurately, but not both, especially when the sender is    application-limited or under reordering that is unpredictable. “ - /They/A sender/ …. /or under reordering that is unpredictable/or when the reordering is unpredictable/. - What does unpredictable mean in this sentence? Is it about the pattern or reordering, the variation in the pattern, the presence or not within an RTT or something else? — This is not explained or justified: “And    under these conditions none of them can detect lost retransmissions    well.” - None of them can doe well? Can you explain this better, saying this is not “well” seems a very poor justification for changing a standard — This is confusing: “Also, these algorithms, including RFCs, rarely address the    interactions with other algorithms.  “ - Which? and why this this important? — Since section 2 seems mainly set out to provide the reason for the change, would it not be more normal to precede the RFC2119 terminology declaration? This could also apply to section 3, which introduces the method, but does not appear normative. —— Section 3. “The main idea behind RACK is that if a packet has been delivered out    of order, then the packets sent chronologically before that were    either lost or reordered.” - This is put forward as a TCP specification, and yet it describes things in network-layer “packets”. If the IP layer were to fragment, does this still work on IP packets?  I think this should be in terms of transport segments, or the relationship between packets and segments explained. — “Using a threshold for counting duplicate acknowledgments (i.e.,    DupThresh) alone is no longer reliable because of today's prevalent    reordering patterns. “ - To me this is quite an annoying statement to make without reference to a source of this consensus. Saying the method is robust to reodering seems good, saying the current Internet has "prevalent reordering patterns" makes me ask where? what evidence? how important? etc. I suggest this document should not be making these claims. —— “A common type of reordering is that the last    "runt" packet of a window's worth of packet bursts gets delivered    first, then the rest arrive shortly after in order. “ - Cite data please and explain the cases, or please do not claim this is “common”! — “Today's prevalent lost retransmissions also cause problems with    packet-counting approaches “ - Cite data please, or please do not claim this is “prevalent”. —— “are often unable to infer and quickly repair losses” - “often” is being used here in a way that implies this is frequent? Is this strictly necessary to define the algorithm. I think it would be enough to explain these events can happen, and that the algorithm can detect these cases and appropriately respond. I do not see the need to make a statement of how common this is. — This isn’t clear text, I had to read several times to be sure: “On each ACK, RACK marks any already-expired packets lost,    and for any packets that have not yet expired it waits until the    reordering window passes and then marks those lost as well” - I think this could be explained more simply. — “hurts” performance. Could be better phrased. —  “TCP congestion control implicitly assumes the        feedback from ACKs are from the same bottleneck. “ - I don’t think this is true. There is no assumption. The design was based on a single bottleneck at any one time along the path. However that does not imply that more than one bottleneck can not be present. — “Therefore it        cannot handle well scenarios where packets are traversing largely        disjoint paths.” - I don’t know what “handle well” means, not do I understand “largely disjoint” really means in this context. Can this be explained? — “Having an excessively large reordering window to        accommodate widely different latencies from different paths would        increase the latency of loss recovery.” - This needs better phrasing. Why does this have to be “excessively” large and why does a TCP transport care about “different paths” irrespective of being “widely different” - I could not understand what was intended at all. - — “An end-to-end transport protocol cannot tell immediately whether a    hole is reordering or loss. “ - Please explain hole before using. — “How long the sender waits for such    potential reordering events to settle is determined by the current    reordering window.” - NiT; except one is measured in packets, and “how long” is in units of seconds. — “The initial RACK reordering window SHOULD be set to a small        fraction of the round-trip time.” - Sounds good, is this after connection setup, or before? How does the sender know the RTT? — “ To accomplish this RACK places the    following mandates on the reordering window:” - The discussion ‘mandates’ appears to be different to the discussion of requirements. I don’t see the difference explained. I wonder whether the document should place all requirements in section 5, but if not, then the purpose should be better explained. — “   RACK does not need any change on the receiver.” - OK. However, there is a requirement that the receiver reports loss using SACK. — “ RACK.dsack" indicates if a DSACK option .” - DSACK not mentioned until here. Should you cite DSACK [RFC3708] ? --- “The RECOMMENDED value for  WCDelAckT is 200ms.” -Why this value? is this linked to TCP Delayed ACK value? — “We have evaluated using the smoothed RTT” …. where is the data? — “They do not make any significant difference in terms of total recovery latency.” - Is this true of **ALL** cases? I strongly dislike such conclusions in RFCs. The document can only make conclusions based on available data, and claiming this for arbitrary paths is dangerous and unnecessary. - “While RACK can be a supplemental loss    detection mechanism on top of these algorithms, this is not    necessary, because RACK implicitly subsumes most of them.” - what is not necessary RACK? or one of them? why does it say “most”, please be specific. - I think sections 8 and 9 are both informative. Is this the case? I like this information, but I would prefer the sections to explain that they are informative, if that is the case --- “"Common causes of RTOs include:" - This seems unnecessary, can’t you scope this to the ones that you think TLP will address, instead of making this very general statement. The current text seems to need a reference, whereas saying this is what TLP addresses would not. — “"A sender should schedule a PTO only if all of the following conditions are met" - what is the actual requirement here? I’m searching to understand what is actually needed or recommended. --- NiTs: “eg.” should be “e.g.,” “is the easiest way to get a network to go faster.” - This needs to be explained better. --- “Therefore their main    constraint on speed is reordering, and there is pressure to relax    that constraint.  “ - I object to this statement within a TCPM document. This is not related to the TCPM Charter which is about maintaining transport protocols and not changing network-layer forwarding behaviour. I similarly think  the following sentence is entirely inappropriate: “If RACK becomes widely deployed, the underlying    networks may introduce more reordering for higher throughput. “ - albeit with a lower case “may”, this is still something that tsvwg has spent many meetings discussing and one that has significant pushback and therefore a need for careful choice of words! From nobody Mon Apr 6 08:46: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 6AB443A0ADA for ; Mon, 6 Apr 2020 08:46:18 -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 wyI-zI_RsgU5 for ; Mon, 6 Apr 2020 08:46:15 -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 18BF13A0A92 for ; Mon, 6 Apr 2020 08:46:14 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2C2881B001FE; Mon, 6 Apr 2020 16:46:10 +0100 (BST) To: Michael Tuexen , tcpm IETF list References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> From: Gorry Fairhurst Cc: David Black Message-ID: <70b26bc9-bd29-0712-e189-14a9f556902d@erg.abdn.ac.uk> Date: Mon, 6 Apr 2020 16:46:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AB6CD13AB3E9449DD1F2B917" Content-Language: en-GB Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 - 3 issues 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, 06 Apr 2020 15:46:19 -0000 This is a multi-part message in MIME format. --------------AB6CD13AB3E9449DD1F2B917 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I reviewed the latest version of RACK as a part of the TCPM WGLC and this email contains 3 points I think are more important for the WG to consider. (1) Why re-specify the DupACK Thresold? I have a question why does RACK need to say this, effectively over-riding any future change to the DupACK threshold: “then RACK SHOULD honor the classic 3-DUPACK rule for initiating fast recovery.”. I suggest:
“then RACK SHOULD honor the        classic DUPACK rule for fast recovery as specified in [RFC5681].” and later: “and use of the 3-DUPACK rule” rather than “DUPACK Rule [RFC5681]”. - If that spec changes, I think RACK should also. I do not see the reason to restrict this to the constant three for the purpose of RACK. — (2) Can the document be clearer about how RTTs are used and what happens on paths where the RTT varies significantly? “The RACK reordering window MUST be bounded and this bound SHOULD        be one round trip.” - Which round trip estimate? Is the smoothed RTT, the RTO? the last measured RTT? I think this needs to be explained, because it also appears later “  Since an ACK can also acknowledge retransmitted data packets, and    retransmissions can be spurious, the sender must take care to avoid    spurious inferences.  For example, if the sender were to use timing    information from a spurious retransmission, the RACK.rtt could be    vastly underestimated.” - ‘must take care’? is that “needs” or if not, what does “take care” really mean? - Why ‘vastly’ - I would have thought that was possible,  but doesn’t the problem emerge when any underestimate is present. Please clarify by removing “vastly” or explaining this. —    “Use the RTT measurements obtained via [RFC6298] or [RFC7323] to    update the estimated minimum RTT in RACK.min_RTT.” - I don’t see either of these specifications define a minimum RTT. I understand that QUIC doesn’t have a way to maintain an accurate minimum RTT,  how does a sender determine the minimum RTT? - Considering robustness to path changes, how does the minimum RTT take into account the variation of the path RTT? - How does this relate to RTO Consider (https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10), which appears to place strong demands on timers tracking variance and path changes? — ** “In such cases RACK may not detect losses from    ACK events and the recovery would then resort to the (slower) TLP or    RTO timer-based recovery.  However, such events should be rare and    the connection would pick up the new minimum RTT when the recovery    ends, so the sender can avoid repeated similar failures.” - I’d strongly suggest changing that “may” to “could” to be really clear this is not permitting something. - I’m also not sure how a sender would know that “such events should be rare” - isn’t that dependent on path characteristics? — “"To be more robust to reordering, RACK uses a more conservative RTT value to decide if an unacknowledged packet should be considered lost, RACK.rtt" - - Why is this not normative? I think this is either a SHOULD or a MUST? There's suggestions that much of this may be covered in various places, and that could just need editorial work? As I noted before in the working group, I do like the idea of RACK, but I do have concerns about what happens on paths where there is a large variation in the RTT. With a DUPACK-based recovery the variability extends the recovery time, and RTO inflates - both are safe. I do not have any feeling that a sender would not be overly aggressive when used over a widely varying path RTT. This seems like it is not safe unless you include a variance term in the RTT, or as an enabling function to using the method. I really do think this has to be explained and addressed. — (3) There are places where the text explcitly motivates a change to the network forwarding behaviour, saying almost that this is an allowed outcome of deploying RACK for TCP. Section 4 in particular is a concern: " The reordering behavior of networks can evolve (over years) in response to the behavior of transport protocols and applications, as well as the needs of network designers and operators. From a network or link designer's viewpoint, parallelization (eg. link bonding) is the easiest way to get a network to go faster. Therefore their main constraint on speed is reordering, and there is pressure to relax that constraint. If RACK becomes widely deployed, the underlying networks may introduce more reordering for higher throughput. " and later: " This handles reordering caused by path divergence in small time scales (reordering within the round-trip time of the shortest path), which should tolerate much of the reordering from link bonding, multipath routing, or link-layer out-of-order delivery." As explained in TSVWG (within the context of L4S), my own opinion is that it would be good to have greater tolerance to reordering and that the presence of paths with significant reordering is a motivation for that work. Beyond that, I would urge much caution: Writing anything that could suggest RACK enables greater reordering has implications on a wide range of IETF protocols and would represent a very significant change in advice for the network. I would even suggest that such advice is wrong, until methods such as RACK have been deployed in transports as a whole, not just TCP. I also think this sort of advice and reasoning does not belong within the specification of a protocol mechanism. Gorry --------------AB6CD13AB3E9449DD1F2B917 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I reviewed the latest version of RACK as a part of the TCPM WGLC and this email contains 3 points I think are more important for the WG to consider.

(1) Why re-specify the DupACK Thresold?

I have a question why does RACK need to say this, effectively over-riding any future change to the DupACK threshold:
“then RACK SHOULD honor the classic 3-DUPACK rule for initiating fast recovery.”.
I suggest:
“then RACK SHOULD honor the
       classic DUPACK rule for fast recovery as specified in [RFC5681].”
and later:
“and use of the 3-DUPACK rule” rather than “DUPACK Rule [RFC5681]”.
- If that spec changes, I think RACK should also. I do not see the reason to restrict this to the constant three for the purpose of RACK.

—
(2) Can the document be clearer about how RTTs are used and what happens on paths where the RTT varies significantly?

“The RACK reordering window MUST be bounded and this bound SHOULD
       be one round trip.”
- Which round trip estimate? Is the smoothed RTT, the RTO? the last measured RTT? I think this needs to be explained, because it also appears later

“  Since an ACK can also acknowledge retransmitted data packets, and
   retransmissions can be spurious, the sender must take care to avoid
   spurious inferences.  For example, if the sender were to use timing
   information from a spurious retransmission, the RACK.rtt could be
   vastly underestimated.”
- ‘must take care’? is that “needs” or if not, what does “take care” really mean?
- Why ‘vastly’ - I would have thought that was possible,  but doesn’t the problem emerge when any underestimate is present. Please clarify by removing “vastly” or explaining this.
—
   “Use the RTT measurements obtained via [RFC6298] or [RFC7323] to
   update the estimated minimum RTT in RACK.min_RTT.”
- I don’t see either of these specifications define a minimum RTT. I understand that QUIC doesn’t have a way to maintain an accurate minimum RTT,  how does a sender determine the minimum RTT?
- Considering robustness to path changes, how does the minimum RTT take into account the variation of the path RTT?
- How does this relate to RTO Consider (https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10), which appears to place strong demands on timers tracking variance and path changes?
—
** “In such cases RACK may not detect losses from
   ACK events and the recovery would then resort to the (slower) TLP or
   RTO timer-based recovery.  However, such events should be rare and
   the connection would pick up the new minimum RTT when the recovery
   ends, so the sender can avoid repeated similar failures.”
- I’d strongly suggest changing that “may” to “could” to be really clear this is not permitting something.
- I’m also not sure how a sender would know that “such events should be rare” - isn’t that dependent on path characteristics?
—
“"To be more robust to reordering, RACK uses a more conservative RTT value to decide if an unacknowledged packet should be considered lost, RACK.rtt"
-
- Why is this not normative? I think this is either a SHOULD or a MUST?  

There's suggestions that much of this may be covered in various places, and that could just need editorial work? As I noted before in the working group, I do like the idea of RACK, but I do have concerns about what happens on paths where there is a large variation in the RTT. With a DUPACK-based recovery the variability extends the recovery time, and RTO inflates - both are safe. I do not have any feeling that a sender would not be overly aggressive when used over a widely varying path RTT.

This seems like it is not safe unless you include a variance term in the RTT, or as an enabling function to using the method.

I really do think this has to be explained and addressed.

—
(3)

There are places where the text explcitly motivates a change to the network forwarding behaviour, saying almost that this is an allowed outcome of deploying RACK for TCP.

Section 4 in particular is a concern:

" The reordering behavior of networks can evolve (over years) in 

   response to the behavior of transport protocols and applications, as
   well as the needs of network designers and operators.  From a network
   or link designer's viewpoint, parallelization (eg. link bonding) is
   the easiest way to get a network to go faster.  Therefore their main
   constraint on speed is reordering, and there is pressure to relax
   that constraint.  If RACK becomes widely deployed, the underlying
   networks may introduce more reordering for higher throughput. "
and later:
"  This handles reordering caused by path divergence in small time
   scales (reordering within the round-trip time of the shortest path),
   which should tolerate much of the reordering from link bonding,
   multipath routing, or link-layer out-of-order delivery."

As explained in TSVWG (within the context of L4S), my own opinion is that it would be good to have greater tolerance to reordering and that the presence of paths with significant reordering is a motivation for that work.

Beyond that, I would urge much caution: Writing anything that could suggest RACK enables greater reordering has implications on a wide range of IETF protocols and would represent a very significant change in advice for the network. I would even suggest that such advice is wrong, until methods such as RACK have been deployed in transports as a whole, not just TCP. I also think this sort of advice and reasoning does not belong within the specification of a protocol mechanism.

Gorry

--------------AB6CD13AB3E9449DD1F2B917-- From nobody Mon Apr 6 14:02: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 3FB693A0D7D for ; Mon, 6 Apr 2020 14:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.helsinki.fi 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 Q5SZIbhdQ7yq for ; Mon, 6 Apr 2020 14:02:09 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE763A0CB6 for ; Mon, 6 Apr 2020 14:01:54 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Tue, 07 Apr 2020 00:01:46 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=HRvbP3gBVSFXnuZaf 5k6QDURlLo2vO5IAayDPs6w9l0=; b=WY4fYfNumU3pzVALdg7DQ3KoLcVUPYrJh 4ZEi8YVOqC46F4JV0J+1DyU+k94+JZPT1NJzdJUXWEORXWenXQ5knbrMhaQoHjIL Oai05VrdtHCUWpbEvbN1p4LSbsUTDtTiIq2Ywb0rvhlgmHpDAgvEI6Q5f4V26Y9c Iqa+SSdciU= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Tue, 07 Apr 2020 00:01:46 +0300 id 00000000005A014E.000000005E8B98BA.00003315 Date: Tue, 7 Apr 2020 00:01:46 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Yuchung Cheng cc: "tcpm@ietf.org Extensions" , Neal Cardwell , Nandita Dukkipati , Priyaranjan Jha In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-13103-1586206906-0001-2" Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-07 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, 06 Apr 2020 21:02:16 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-13103-1586206906-0001-2 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi Yuchung, Certainly improved on many things, however, I'm surprised that the lost=20 rexmit comment was not addressed at all. Aren't the rexmit losses=20 supposed to be detected by RACK or have I misunderstood something? I don't understand how lost rexmits are detected by the algorithms in the draft. I think the algorithms are either flawed or lack something=20 (mainly RACK_detect_loss is relevant I think). My original comment from below. Is RACK_detect_loss() supposed to detect also lost rexmits? How? The rexmit code itself is not in the draft so it's hard to evaluat= e how the Packet booleans are supposed to work in the first place. I'm not saying the rexmit code should be included but currently it surely looks like any rexmitted packet just remains .lost =3D TRUE and .retransmitted =3D TRUE state until RTO? Also my timeout "some" vs "all" internal inconsistency comment relates to=20 this same algorithm: =A0 "For timely loss detection, the sender MAY =A0 =A0install a "reordering settling" timer set to fire at the ea= rliest =A0 =A0moment at which it is safe to conclude that some packet is = lost. The =A0 =A0earliest moment is the time it takes to expire the reorderi= ng window =A0 =A0of the earliest unacked packet in flight." vs =A0 =A0RACK_detect_loss(): =A0 =A0 =A0 ... =A0 =A0 =A0 =A0 =A0 timeout =3D max(remaining, timeout) Which way it is, "some" or "all"? The use of max() in RACK_detect_= loss() seems to indicate that the timeout will be set according to the lo= ngest time, that is, the latest moment rather than earliest moments. Whi= ch is the intented behavior here? (I can there might be merits in bot= h approaches). Then there are some other comments I made which seem also unaddressed but=20 I'll not duplicate them all here. --=20 i. On Mon, 9 Mar 2020, Yuchung Cheng wrote: > Hi Ilpo, > Thanks for a detailed review and the great suggestions. Here's all the = edits > we made. > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-08 >=20 > =A0We defined the missing terms and addressed the nits, removed the les= s > critical parts like recommending PRR, and edited TLP algorithms (sectio= ns > 7.4 to 7.6). I hope you find it's better now and would be happy to hear = any > improvements you'd=A0like to make. >=20 > Yuchung >=20 > On Fri, Feb 14, 2020 at 4:22 AM Ilpo J=E4rvinen > wrote: > In general, I find the draft quite good shape already, it's > quite easy > to read and follow (that is, except the TLP sections that are > specifically > mentioned below). >=20 > Here's the list of issues I came across: >=20 > Sect 6.1 >=20 > "RACK.pkts_sacked" lacks the empty line separator. >=20 > Sect 7.2 >=20 > =A0 "This > =A0 =A0heuristic would fail to update RACK stats if the packet is > spuriously > =A0 =A0retransmitted because of a recent minimum RTT decrease (e.= g. > path > =A0 =A0change)." > This defies my logic as RTT decrease should not result in > spurious > retransmissions but help to avoid them. >=20 >=20 > =A0 "Note that > =A0 =A0extensions that require additional TCP features (e.g.=A0 D= SACK) > would > =A0 =A0work if the feature functions simply return false." > Please rephrase this. I suspect you meant that if some functions > relate > to TCP features that are not available, the given code still > works > as long as the functions related to such features return false > when > the TCP feature is not available but that surely isn't what the > sentence currently says. >=20 > Sect 7.2 Step 5 >=20 > =A0 "For timely loss detection, the sender MAY > =A0 =A0install a "reordering settling" timer set to fire at the > earliest > =A0 =A0moment at which it is safe to conclude that some packet is > lost.=A0 The > =A0 =A0earliest moment is the time it takes to expire the reorder= ing > window > =A0 =A0of the earliest unacked packet in flight." > vs > =A0 =A0RACK_detect_loss(): > =A0 =A0 =A0 ... > =A0 =A0 =A0 =A0 =A0 timeout =3D max(remaining, timeout) > Which way it is, "some" or "all"? The use of max() in > RACK_detect_lost() > seems to indicate that the timeout will be set according to the > longest > time, that is, the latest moment rather than earliest moments. > Which > is the intented behavior here? (I can there might be merits in > both > approaches). >=20 >=20 > In general, I didn't like the presentation order here as this > form looks > the most obvious to me: > =A0 =A0now >=3D Packet.xmit_ts + RACK.reo_wnd + (RACK.ack_ts - > RACK.xmit_ts) > ...and I find the derivation of it just complicating things > rather > than helping but that's perhaps just my opinion. >=20 >=20 > =A0 =A0"It is also useful when the timestamp clock granularity is > close to > =A0 =A0 or longer than the actual round trip time." > Given that some things based on timestamps will obviously stop > working > if the clock is slower than one tick per RTT I found this > fragment a bit > odd. RFC 7323 says "the clock SHOULD tick at least once per > window's worth > of data". I can understand though that a host might find clock > tick > granularity challenging due to extensive RTT range but on the > same > I'd not want such a "too slow clock" behavior to be endorsed as > if > it would be just normal. That is, I'm not against RACK handling > also this case nicely but it would be nice to somehow downplay > the > normalness tone in it with something along the lines of "This > check is > also useful if the recommended one tick per RTT cannot be > achieved due > to timestamp clock granularity." >=20 > Is RACK_detect_lost() supposed to detect also lost rexmits? How? > The rexmit code itself is not in the draft so it's hard to > evaluate > how the Packet booleans are supposed to work in the first place. > I'm not saying the rexmit code should be included but currently > it > surely looks like any rexmitted packet just remains .lost =3D TRU= E > and > .retransmitted =3D TRUE state until RTO? >=20 >=20 > Sect 7.4 >=20 > "PTO" just appears out of nowhere (and is not even written open > in the first instance). >=20 > =A0 =A0"2. ... in step (2) of the algorithm." > "step (2)" is forward-refing, it would naturally refer back to > "Step 2: Update RACK stats" so it makes very little sense as is. >=20 > Sect 7.5 >=20 > Separator missing for PTO: and TLPRxtOut: >=20 > Sect 7.5.1 >=20 > =A0 "3.=A0 Upon receiving a SACK that selectively acknowledges da= ta > that was > =A0 =A0 =A0 =A0last sent before the segment with SEG.SEQ=3DSND.UN= A was > last > =A0 =A0 =A0 =A0(re)transmitted" > This is hard to understand, perhaps rephrase it somehow? >=20 >=20 > =A0 "But choosing PTO to be > =A0 =A0exactly an SRTT is likely to generate spurious probes give= n > that > =A0 =A0network delay variance and even end-system timings can eas= ily > push an > =A0 =A0ACK to be above an SRTT.=A0 We chose PTO to be the next > integral > =A0 =A0multiple of SRTT. >=20 > =A0 =A0Similarly, network delay variations and end-system process= ing > =A0 =A0latencies and timer granularities can easily delay ACKs > beyond > =A0 =A02*SRTT, so senders SHOULD add at least 2ms to a computed P= TO > value > =A0 =A0(and MAY add more if the sending host OS timer granularity = is > more > =A0 =A0coarse than 1ms)." > Does this later paragraph depend on some assumptions (such as > very > low RTT?) as I don't otherwise understand why you say what you > say > in the given order. First you said x & y can push ACK over SRTT > so > we pick 2* but then you say the same things can push over 2*SRTT > too? >=20 > WCDelAckT to terminology? >=20 > Sect 7.5.2 >=20 > TLP_send_probe(): > =A0 =A0 =A0 =A0 - Perhaps set TLPRxtOut somewhere? > =A0 =A0 =A0 =A0 - Add "Arm RTO" to the end? >=20 > =A0 "In the case where > =A0 =A0there is only one original outstanding segment of data (N=3D= 1), > the > =A0 =A0same logic (trivially) applies: an ACK for a single > outstanding > =A0 =A0segment tells the sender the N-1=3D0 segments preceding th= at > segment > =A0 =A0were lost.=A0 Furthermore, whether there are N>1 or N=3D1 > outstanding > =A0 =A0segments," > If this distinction is useful to make at all, maybe just simply > say: > "Applies also in case N=3D1." >=20 > Sect 7.6 >=20 > =A0 "SND.NXT at the time the episode started." > Isn't this TLPHighRxt, why not use it here? >=20 > Sect 7.6.2 >=20 > =A0 "Upon sending a TLP probe that is a retransmission, the sende= r > sets > =A0 =A0TLPRxtOut to true and TLPHighRxt to SND.NXT." > This should appear in TLP_send_probe(). >=20 > "Detecting recoveries accomplished by loss probes" > Did you want to start another section here? >=20 > "Step 1: Track ACKs ..." until what point? (It's told on later > but > this question comes into mind when reading the draft in order). >=20 >=20 > Sect 7.4 - 7.6.2 >=20 > In general, this particular part of the draft seems to require > some > further editing. After reading it all through, I feel most bits > are > present but the text is very hard to follow. I think the > presentation > order needs significant work. There are random bits here and > there > that are explained only later. Also, algorithm lacks some parts > discussed only in the text but variable like items should > definitely > be included to the algorithm. >=20 >=20 > Sect 8.4 >=20 > =A0 "RACK is compatible with and does not interfere with the the > standard > =A0 =A0RTO [RFC6298], RTO-restart [RFC7765], F-RTO [RFC5682] and > Eifel > =A0 =A0algorithms [RFC3522]. ... > =A0 =A0It neither changes the RTO timer calculation nor detects > spurious > =A0 =A0timeouts." > For F-RTO, also send order is significant. >=20 > Sect 8.5 >=20 > SHOULDs PRR (and also placed to normative references) that is > only > experimental and RACK aims to standards track. I feel that PRR > is > disjoint enough anyway, which I think was also your intention > when > maintaining the decoupling CC and RACK, that it's bit odd to > take > this strong stance on PRR (indepedent of the stds track vs > experimental thing). >=20 > =A0 "due to congestion window validation." > Does this refer to CWV as in RFC? Or some other mechanism in > which > case you shouldn't use the same term here. >=20 > I find the described scenario somewhat unconvincing becase > the description ends with: > =A0 "... > =A0 =A0The ending congestion window after recovery also impacts > =A0 =A0subsequent data transfer." > ...First there wasn't enough data to fill cwnd of 20 packets and > then suddenly transferring that non-existing data is impacted. >=20 > References >=20 > QUIC-LR is very old ref and even the filename has changed a few > times from draft-tsvwg-... >=20 >=20 > Nits >=20 > "runt" made the sentence incomprehendable for me, I had to look > up > that word (and only second source was descriptive enough that I > think I could understand the meaning, and I'd guessed wrong > because > I thought there was some special intent here because of the > quotes). >=20 > is dicussed -> is discussed > RACT.RTT -> RACK.rtt > First "TSO" -> TCP Segmentation Offload (TSO) > grainularity -> granularity > higher-sequenc -> higher-sequence >=20 >=20 > -- > =A0i. >=20 >=20 > --=_script-13103-1586206906-0001-2-- From nobody Mon Apr 6 15:54: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 198EE3A0E22 for ; Mon, 6 Apr 2020 15:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=microsoft.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 SjR2PbFMfZva for ; Mon, 6 Apr 2020 15:54:47 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650116.outbound.protection.outlook.com [40.107.65.116]) (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 4F46E3A0E21 for ; Mon, 6 Apr 2020 15:54:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gVTsjLE1O+FOI1RTWZCj8j8P960I5XhFyM3YuQ6JUhzbLth89sVZvv5QnFVhdhjIcEoohYdWZurtdKsl8Y67a8UBgMc0uje5D18Cy+s8ftAd1SJhH3yIy6LIWehxua5kFQcFDXNpRySgpiIsiO6IrBCQIJL2MIybgQAycTz4QCeKbeyoVkkvpHNAn9t38hDM8bVuhz8FhJLV5kODmePxaemcTjuuu9WMfRQYxfhoTk1Gsl6PMNZYksDzBbvjlcTSGjI6vHfNXhMLEQsJWyyIMNjFnFE0MaS1BzWG1D5TQCQdPcExng3GG7Mn8Mc4znUdLpsok+iaoqZvFsvqt8ePng== 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=serDD2O4k5A8+6XGIuRn10b8gU+BVAATXFPMnL8+Q9A=; b=ajpuUjGVvdKCoPhYvbqfE0B3sD/B+SpSJV9eX4AoRizH+vJzrqUHBIC8OCA3NVfxqN03kwKGofaic+X4tQbQtkpbB5Iezei8xPaRnvpxaqKALJlRpEdEFpXo1Qh/K9CG6+EKblftJF6eDugxPHmzF9rE7ekVRD16RidGcuw47Sh25MlWBFDTChP1H8q4EK8dnxtU/zbo4FmdPkMy88PGRwWq9zFPoVRe07uwFFG57uMxvC4r5HycsG87Jyc6O95SX4lb2oIWYz3IvJojGbzmRz49oACt5LHoAi1f+ggmqzeGfXxVgTDxVLeH5R365UVwdCdpbmt7mRgtIuC2/Z2Mzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=serDD2O4k5A8+6XGIuRn10b8gU+BVAATXFPMnL8+Q9A=; b=Oay5h+7TC6cqHJn5uDdHtjYKAJIha62Q4vHAFfHWNHCw+jLut5m/YKmSPNsdmuArHDOm1G/j58fc4mQKlWFSfSxGeLylqKgdY9caFCkO2WXnvTPV3afZYNFTWVpceOXm2Nx2a7HSMR4ZJZZvZwjqUByTtcsFPm9szqb9XPrwqV0= Received: from CO2PR00MB0181.namprd00.prod.outlook.com (2603:10b6:102:15::22) by MW2PR00MB0299.namprd00.prod.outlook.com (2603:10b6:302:8::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2923.0; Mon, 6 Apr 2020 22:54:45 +0000 Received: from CO2PR00MB0181.namprd00.prod.outlook.com ([fe80::41b0:e003:becf:c63]) by CO2PR00MB0181.namprd00.prod.outlook.com ([fe80::41b0:e003:becf:c63%4]) with mapi id 15.20.2928.000; Mon, 6 Apr 2020 22:54:45 +0000 From: Praveen Balasubramanian To: Michael Tuexen , tcpm IETF list Thread-Topic: [EXTERNAL] [tcpm] WGLC for draft-ietf-tcpm-rack-08 Thread-Index: AQHWBuKUegmSdEwkOUCkCzJgctSQTqhsulqg Date: Mon, 6 Apr 2020 22:54:44 +0000 Message-ID: References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> In-Reply-To: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-06T22:53:38.3152583Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=1cad61a8-76c7-4549-828f-401dc3a2b3d2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:0:95d8:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4a194db8-1199-4689-672c-08d7da7d8010 x-ms-traffictypediagnostic: MW2PR00MB0299:|MW2PR00MB0299: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO2PR00MB0181.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(376002)(366004)(136003)(396003)(39860400002)(10290500003)(966005)(82960400001)(82950400001)(478600001)(110136005)(8990500004)(54906003)(81166006)(53546011)(7696005)(86362001)(6506007)(8936002)(81156014)(2906002)(8676002)(66446008)(66556008)(66476007)(316002)(52536014)(66946007)(64756008)(107886003)(186003)(33656002)(4326008)(9686003)(5660300002)(71200400001)(55016002)(76116006); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V6Jj09t94qM+//UvsPv8s7uO1Yia+LAsWJ6PAlLwMA+arKpKwlaQYTJnjiE/Ky2ikfMuWEXOLUsAGx9EiWcAo5IgzEMTbuydr/mr3fSYTu1bPv3LUwicLh4IGM8Rhtis7w6RKZ8agGL1p3/K6EMBjC3CFcv19E1qcibY5ekplxOkYXwaYf+7gVKgSUvx69Cjy4BwRnpWMYzJQvkSAw09toCqIHOONQS/L807c/rAdVfFyDRPaJHmm914jNaSDRc7gal1/UW3eIV+KT2wLX6u+k+pDIFoJqC7OKpozFlQm6xGepKM7nXgqZSmTCwlp+pH3FdefwKbmzx4MpS3wVPpVYU2nNyVBsoSS2/woBwiGZd2Uzl5mhDSfx8qEvzX58H/1wn/j6MID+r6mAbFVeFd9YSzn8uJL62f0fYvJwYTvtOd2V8ZJnMcob7YKd3zM8srqHK3HIIJTjnpWgu3z0vKj3lqFEV2bi/FPVpEUkBUwmj8EFw3oXS4VGt3KWr5dO7mefdvYQZfm7fN3bv84jGLEA== x-ms-exchange-antispam-messagedata: qW1IFsdmJA5k2QYSPIMMv35mzDlOpQlMUDttybqmuEN2BcZXRJaz8niKAtcU15CHzGO3YLzrrrnJ7+73U1ONI8XefhosfpZdJGmh24QZc9nHvhSJ2koiTn1GsUSotX5yWu9SeWB3SvaYLjda0HoM8KBB2dDg03mluLHLQCWfBkHg/Dp/b5DsrxVlUsVRHHYmuV8/7Zejgw4pmtJzRoCm9Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a194db8-1199-4689-672c-08d7da7d8010 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 22:54:44.9820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vs2rQQ2g6IR2xmuuSqEXev6XXzEgxZhq9AdlUJI/aJs2zoms02Iz0lFWcZUXRZ6vrkZItl5jtWluBK0TOMJCvr/EjpHY48M9aCmmYHYUAyg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0299 Archived-At: Subject: Re: [tcpm] [EXTERNAL] WGLC for draft-ietf-tcpm-rack-08 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, 06 Apr 2020 22:54:49 -0000 We reviewed the latest version of RACK as a part of the TCPM WGLC and this = is some feedback:=20 Section 5 Requirements >> For each packet sent, the sender MUST store its most recent transmissio= n time=20 It is important to call out that in practice for sends that are batched tog= ether in time, an implementation may choose to keep per-send transmission t= imestamps instead of per-packet. This improves memory efficiency. The way t= he RFC requirement is worded it seems to exclude such an optimization.=20 Section 4 Design Rationale for Reordering Tolerance >>If RACK becomes widely deployed, the underlying networks may introduce mo= re reordering for higher throughput. A better word here would be universally deployed because otherwise networks= would be unfairly harming TCP stacks that have not deployed RACK. Plus as = pointed out, reordering puts other strains on the network including ECMP, R= SS, hardware offloads etc. Consider removing any recommendations for networ= ks from this draft to prevent any unintentional relaxing of requirements on= networks. This section should ideally only focus on why RACK chooses to re= lax reordering requirements as they pertain to loss detection and recovery.= =20 >>temporarily override the reorder window Nit: Let's consistently call this reordering window throughout the draft. Section 7.2 Upon receiving an ACK Step 5. >>For timely loss detection, the sender MAY install a "reordering settling"= timer set to fire at the earliest moment at which it is safe to conclude t= hat some packet is lost. At least in lab tests this timer seems to make a big difference. Recommend = changing this to a SHOULD instead of MAY. >>This can be implemented by using a seperate doubly-linked list sorted in = time order. Typo separate. We shouldn't recommend a specific data structure.=20 Some questions that need more explanation:=20 1. What about TLP and its relationship to Limited Transmit? Both of them ar= e techniques trying to solve the same problem. Its important to clarify whe= ther Limited Transmit is left unchanged from RFC 6675. It is also unclear w= hether Limited Transmit should be upgraded from a MAY to a SHOULD. The non-= SACK case might benefit from Limited Transmit?=20 2. Why does TLP require SACK? In the case SACK negotiation fails, or SACK b= locks are stripped in the network, TLP may still recover faster than an RTO= when FlightSize is 1. -----Original Message----- From: tcpm On Behalf Of Michael Tuexen Sent: Monday, March 30, 2020 3:28 PM To: tcpm IETF list Subject: [EXTERNAL] [tcpm] WGLC for draft-ietf-tcpm-rack-08 Dear all, just a quick reminder: We are currently running a WGLC for TCP RACK until Tuesday, April 7th 2020. Please send any comments, including indications to support this document, t= o the TCMP mailing list by then. The ID is available at https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-08&data=3D02%7C01%7Cpravb%40micro= soft.com%7C0f4389073900466c89c408d7d4f9b460%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637212041259507026&sdata=3DnQghPe61ph4EBThh4xRYp9LTmfisCp= 6LZAj96leSpOI%3D&reserved=3D0 Best regards Michael From nobody Mon Apr 6 20:46: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 A96E83A14AB; Mon, 6 Apr 2020 20:46: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 j1Ua4uTJO9rD; Mon, 6 Apr 2020 20:46:34 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 1816C3A14A4; Mon, 6 Apr 2020 20:46:34 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id c5so1076610pgi.7; Mon, 06 Apr 2020 20:46:34 -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=rmyFQMPBJs3hnhtpJhpjNGntLBQK/gpnEdg1ErWXysM=; b=oC0NUYfj4ekqzcC/XfzvxqEFnF2I67Y3PoegYSes5d5XiKdKeUAb/wjRoYbBt1uegA FB1RT7VtwntgsJEXikJoL5PxTMC5UjDwG/Gps1hYO7dPE0k2CgaIMpaSkW8EDjGHhpEk bQjXJXbFSam8SxcXRlFrW+oiAjNGyEBrNcs1we+KP7/lUKxwcMGfihq0cQUqsNjTqEKv UUxcVcrCrS3IduWItTdYivIENrDUDgbHh6V9gao1q76YShbDp8mjEerCTBIWLt9r+rAs bw7otnlZezwNwAc00RXx07C+LA4Gft5f59GIVtuYkqI+g3E+8ToHhCNteKU1kZdORuO6 iT2w== 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=rmyFQMPBJs3hnhtpJhpjNGntLBQK/gpnEdg1ErWXysM=; b=XIz+YZnGiEmaiz7z576HvNAGL/MMsMuSuc+SHDpn6wExOqojx9hWqdhlme0RpXR5yJ 0Q3EK7AFMRgXv6DIkqan9SSt0q2rqcNU/4LDJ26BcotBhWo1f7jbP4sOis3H6uqn1VEo 3fWo4gev/PpwI0atHucDlHjIHkN0BuY8qigt/VyGQbheQ5hYdq5r2QdNF+I5DUwurlHj dXgoJAG84aAq9tZ3Ealu/kb0V3RAMWbRSbazQ0ZbeJ4Rna878cb19e3UEsKRMP72Gzsu UtloY1MGs+P/+J6ouWIitncboD+a1T+1n0HxplNtxGrYqgpifwdex5MpUJe9QxEJ8vsW L3vg== X-Gm-Message-State: AGi0PuZ2gs6BfAc/PdW/l6KT0B4vtAnjM6mM9Z0gKq9jqkzVzL/3mA29 6h2kJ/un6SaLFk+JhmfEd30= X-Google-Smtp-Source: APiQypIx/ciWDq7XVDNPyU2m6xqt8CpW1R/fCgbG9JH/ZadeuRlmpAmXXKDolFdSexMtqHlu6ZvhUA== X-Received: by 2002:a63:330c:: with SMTP id z12mr32603pgz.415.1586231193431; Mon, 06 Apr 2020 20:46:33 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:28f4:f75f:dbc6:cd22? ([2601:647:5600:5020:28f4:f75f:dbc6:cd22]) by smtp.gmail.com with ESMTPSA id f15sm12972019pfq.100.2020.04.06.20.46.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2020 20:46:32 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AC3A04CB-D128-4FE0-B9EE-5A094B21ECAE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Mon, 6 Apr 2020 20:46:30 -0700 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA3F971@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: Lars Eggert , Michael Tuexen , tcpm IETF list , "draft-scharf-tcpm-yang-tcp@ietf.org" To: Michael SCHARF References: <6EC6417807D9754DA64F3087E2E2E03E2DA3F971@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 03:46:36 -0000 --Apple-Mail=_AC3A04CB-D128-4FE0-B9EE-5A094B21ECAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Michael here. > On Mar 27, 2020, at 7:49 AM, Scharf, Michael = wrote: >=20 > Regarding MD5, I get told that there is still running code and = operational deployment, even if TCP-AO is getting traction. As users = seem to ask for it, my proposal would be to add big warning signs that = it is deprecated, i.e., TCP-AO should be used instead. On that aspect, = the other authors could maybe also chime in. The requirement to support MD5 stems from existing deployments of BGP = that still use MD5 to secure the session. That is why the support for = MD5 has been added to the BGP YANG model = , using = groupings defined by the YANG model in draft-scarf-tcpm-yang-tcp. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_AC3A04CB-D128-4FE0-B9EE-5A094B21ECAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree with Michael here.

On Mar 27, 2020, at 7:49 AM, = Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Regarding = MD5, I get told that there is still running code and operational = deployment, even if TCP-AO is getting traction. As users seem to ask for = it, my proposal would be to add big warning signs that it is deprecated, = i.e., TCP-AO should be used instead. On that aspect, the other authors = could maybe also chime in.

The requirement to support MD5 stems from = existing deployments of BGP that still use MD5 to secure the session. = That is why the support for MD5 has been added to the BGP YANG model, using groupings defined by the YANG model = in draft-scarf-tcpm-yang-tcp.

Cheers.

Mahesh Jethanandani



= --Apple-Mail=_AC3A04CB-D128-4FE0-B9EE-5A094B21ECAE-- From nobody Mon Apr 6 20:52:19 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 6C8A03A14BA; Mon, 6 Apr 2020 20:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 j-qCeDDC9Kos; Mon, 6 Apr 2020 20:52:12 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 2AE543A14B9; Mon, 6 Apr 2020 20:52:11 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id g32so1085874pgb.6; Mon, 06 Apr 2020 20:52: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=ZKaoDFKGGEVQtQge7R8e5ASzoyqt8Bi3xSiBJtpEg9o=; b=HIvSastDZPQt2ENSHnwb3wFvv+tlQML7oGqAz2v8uIwoARbckV9NZe3J58XVXlAfua Z4wvVBOkgxF2ARhsFrppKkxQ41BdHwXamyF3UUJrhUP4z3xz6HBfTz4X7YXF6+iTzhKZ mZBAQDdhhQfccdcvrN9KurKWI2uXkqVJnM2V6DZXHalrVfAZkCFIfdWpayZkPoCLusHJ RvyaSDr9O5lXYFMBQhMBMN04U6HSbYsPAh2z/5/5gkyvKnHKT8lOxscY7Bais00HC54L NAsaEQn3VA0GgLwzcTuOyFyaYd9bXl8iGKpkH2l/65nR8xs9qN7nueL4yLljl7p8V9xz /FgA== 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=ZKaoDFKGGEVQtQge7R8e5ASzoyqt8Bi3xSiBJtpEg9o=; b=heKdmFujLuM8M2QlkySZZ+YW6slc7hjhfDtj3285FP/6aIwJSmJ8jyi2W6JYOI/4v+ JMi/h4mYB+cgckrSZz2d9aAQZYWW2FsjbQv/F3RjKlnTYX8s7w8Bm1ghNUtNCICHWkPi UHgVRwM3pQ/0JP7OPnlS1XDGQwUl+F+aOfOPt6xrf05DgztO143rDXeiYX65QZtbG61E saKG+oansw2zJZkiQBhf8Eckr5eN3adexWueUSSLge/jOJnNsRs5etfRLFWT+LSKTCU1 uGgfdJOP6rTblTy4QJyeC88D9oSr4GsxD80SFFLbj2SreBhpsuytubunXUl/cCtIvc6h A1zQ== X-Gm-Message-State: AGi0PubUogYxLIj3NWNypL0fkWQoXWvhbxXEN5vQSPJwQtOxdOPq+gZS dkIpxEK8jsw6a7dYXVu8y8k= X-Google-Smtp-Source: APiQypJYaqUEpIdvSLRc7q7BptWwCyMKI8CqwVlvTZ/7olOQ1VOMPxJtcIC5q2mnKY4fNMd8F6fuQw== X-Received: by 2002:a62:6103:: with SMTP id v3mr640936pfb.279.1586231531430; Mon, 06 Apr 2020 20:52:11 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:28f4:f75f:dbc6:cd22? ([2601:647:5600:5020:28f4:f75f:dbc6:cd22]) by smtp.gmail.com with ESMTPSA id k4sm13120713pfh.0.2020.04.06.20.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2020 20:52:10 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0D60B755-4CB3-4E5A-A45B-3018FB90452D@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4AAAB67A-8A5B-42A2-9338-2E351E0B1750" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Mon, 6 Apr 2020 20:52:09 -0700 In-Reply-To: Cc: Michael SCHARF , "idr@ietf.org" , tcpm IETF list To: tom petch References: <6EC6417807D9754DA64F3087E2E2E03E2D9F11D2@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] [Idr] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 03:52:13 -0000 --Apple-Mail=_4AAAB67A-8A5B-42A2-9338-2E351E0B1750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tom, > On Apr 2, 2020, at 4:45 AM, tom petch wrote: >=20 >>=20 >> I note that you have also sent this to Netconf and that you import = groupings >> from the netconf-tcp draft which makes the netconf draft a Normative >> Reference except that this I-D does not mention that fact. >=20 > [I-D.ietf-netconf-tcp-client-server] is listed as first normative = reference in draft-scharf-tcpm-yang-tcp and that dependency is also = mentioned in the abstract. With the current structure of the models, it = is not clear to me why a reference in the reverse direction would be = needed. >=20 > > RFC8407 says that YANG import must have a reference which must be a = Normative Reference for the I-D. I will take care of adding a normative reference to = [I-D.ietf-netconf-tcp-client-server] both in Section 4 and in the model, = in the next version of the draft. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_4AAAB67A-8A5B-42A2-9338-2E351E0B1750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Tom,

On Apr 2, 2020, at 4:45 AM, tom petch <ietfc@btconnect.com>= wrote:


I note that you have also sent this to Netconf and that you = import groupings
from the netconf-tcp draft which makes = the netconf draft a Normative
Reference except that this = I-D does not mention that fact.

[I-D.ietf-netconf-tcp-client-server] is listed as first = normative reference in draft-scharf-tcpm-yang-tcp and that dependency is = also mentioned in the abstract. With the current structure of the = models, it is not clear to me why a reference in the reverse direction = would be needed.

<tp>
RFC8407 says that YANG import must have a reference which = must be a Normative Reference for the = I-D.

I will = take care of adding a normative reference to = [I-D.ietf-netconf-tcp-client-server] both in Section 4 and in the model, = in the next version of the draft.

Cheers.

Mahesh Jethanandani



= --Apple-Mail=_4AAAB67A-8A5B-42A2-9338-2E351E0B1750-- From nobody Tue Apr 7 09:09: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 A10D33A0DD0; Tue, 7 Apr 2020 09:09:00 -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, HTML_MESSAGE=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 XRsCYWsERoKJ; Tue, 7 Apr 2020 09:08:59 -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 833983A0DCE; Tue, 7 Apr 2020 09:08:56 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id m4so3933262ioq.6; Tue, 07 Apr 2020 09:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vPlppCELP5pFXKnWaIhSOQucnNEPlBCk8rxn7oEloKc=; b=QttQMzavkdQwCRHlae+aPQiJw6O2csEhmT+7PFh+pDtJjrwZHlrpyqLObCh1wevCIx UR6eouJnurI7cith64+bUbNrKVzjYEF3V3XhtFPiXItno8bcvBFhfZganJLwysx187j3 mDh2jy96M7Cy2t2pNlQ4+iVnGBVcgeBhx9HaPZ2ROHlOfOufBqrPk/HeCPORdXCzzgiJ yiQjE9soBB1dzgna0xjhGXqOa8Np59xUUypBflki4FSdQE3lT+T1RNKzwQuq+8P1n65N MPoQOgNswcjxW2Itp3+YhED/PlvOZTHj00q5BLHJXs2ziyQ4h1xGkrdwx+RIQ78yCprt FVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vPlppCELP5pFXKnWaIhSOQucnNEPlBCk8rxn7oEloKc=; b=QHJUuPCI/asBRinJZg1kwcxeT1oPmRLOW/seVrqghB4hvxCZ39UFRtahIHlQdmaqZU gsweB+Tuxnc+4PYRhAJRhfH5SxisW8Rs4MHzYDyn5/IQ7RA1vpa6x8t4ZTSikTOZFcfC zJ31Yr1b9Oh7dLYXbH7MaIxLe2+L+zkN75+6NXqhnPZVtp+ZSHCxnZy3pAD1XlOnMlFs aLUsPM1w91jrex/XXv9Uc9pXGUUIHVOjnrfi3E8UlTuCO3Ztsb2JCJ31Y3vXDJECjPQh 3xbCgHWfAv+7JxOXt/xoNI6XP67EwnCeotI7Sl9b1TC5j9hQweGBLi2tkRiF4akV087G XXrg== X-Gm-Message-State: AGi0PubVGr/cTusweyl+4//oiUuDwloHuqXGbFuU/uuUyFaLfsCdXqN3 QoO0nAqOSV49X6MIQA5VP/tNn+biPuLG7blOoMI5sOFlaGk= X-Google-Smtp-Source: APiQypIKm6xwKqDI41fojY+rD24JVZzIybjq3NEemHpBBbOltmSGtj8dW/nROYmot3il9bbjzX29N7C/4mIWM5yVw94= X-Received: by 2002:a5e:d919:: with SMTP id n25mr2771015iop.205.1586275735140; Tue, 07 Apr 2020 09:08:55 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Tue, 7 Apr 2020 09:08:44 -0700 Message-ID: To: draft-ietf-tcpm-rack.authors@ietf.org Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000b5800105a2b59908" Archived-At: Subject: [tcpm] Comment on draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 16:09:01 -0000 --000000000000b5800105a2b59908 Content-Type: text/plain; charset="UTF-8" Not a full review, but I may be missing something in this paragraph in Section 3: Using a threshold for counting duplicate acknowledgments (i.e., DupThresh) alone is no longer reliable because of today's prevalent reordering patterns. A common type of reordering is that the last "runt" packet of a window's worth of packet bursts gets delivered first, then the rest arrive shortly after in order. To handle this effectively, a sender would need to constantly adjust the DupThresh to the burst size; but this would risk increasing the frequency of RTOs on real losses. In the "runt" pattern you describe, would not the returning sequence be Dupack, Ack, Ack, Ack ... So that any threshold > 1 would handle this with no problems? Martin --000000000000b5800105a2b59908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not a full review, but I may be missing something in = this paragraph in Section 3:

   Using a threshold for counting duplicate acknowled=
gments (i.e.,
   DupThresh) alone is no longer reliable because of today's prevalent
   reordering patterns.  A common type of reordering is that the last
   "runt" packet of a window's worth of packet bursts gets de=
livered
   first, then the rest arrive shortly after in order.  To handle this
   effectively, a sender would need to constantly adjust the DupThresh
   to the burst size; but this would risk increasing the frequency of
   RTOs on real losses.
In the "runt" pattern you describe, would not the retu= rning sequence be

Dupack, Ack, Ack, Ack ...
<= div>
So that any threshold > 1 would handle this with no p= roblems?

Martin


<= /div>
--000000000000b5800105a2b59908-- From nobody Tue Apr 7 11:50: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 86C433A0D42 for ; Tue, 7 Apr 2020 11:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.601 X-Spam-Level: X-Spam-Status: No, score=-17.601 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 SAznXqdk426t for ; Tue, 7 Apr 2020 11:49:58 -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 63C063A1027 for ; Tue, 7 Apr 2020 11:49:37 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id g24so1677144uan.10 for ; Tue, 07 Apr 2020 11:49:37 -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=aex/GJTQibrlu51RD4Yu/1MoAcJoajmGK9wwIDnVwGc=; b=Wmuwlq4VVS58w8tCSSBumSapZWlVQg16HHWO/RKFLlsFmRpJxNqEisP04D+2D5ogtI KHwfydwYtWpcKxFnpb5KM6cAZ+ZhVNEU6ME62m++CThGGL0ZzvafTJctLbCqZd1a/eBV xJAzlk5fWCwNM1rc0ivsTYzU52lkU9T5ne+RFTxStFg8RNKwWcVPDZONWCO8tpL+xBhM rATIPi7NBDrRuOjvQ/uV9VwUxzIHB4ZfFgMkUA7dHlSLGU0n17oceT5ip16Z1l2PP8od IGzW+IF7K9nGoBJlDRtfIUPTC4sCKHR61vQfGeEB+MzI0OGf9D+d7k21VG37xLyHxpPd zglQ== 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=aex/GJTQibrlu51RD4Yu/1MoAcJoajmGK9wwIDnVwGc=; b=uKTyZTeEuWoPTQIEDciT5GjrRhVgoVIHDE6qeVDHiX9Rr9vckrw85fEwpRmT+KEn62 Xbr7bNTjugCLtCFukWQYXHw5xpHatCUxWA4lc6zQvY8Hj09uu50bfMXxyKmHCgeVHGjz k+LQ+AMjTVqSJnII9C0lTtHqQ5z2yHMlSGs6Q5uyy53tM+ZA7rSW402yH0/uNacTGqPS UNZBPHx4cUhZycSoyUQsnw7bsBKyS1xk4wLievV2kYpNw/YaEZVj8APG3SxblrV9e9Pd KdMHHW9zCvUyPStFxF7/g+kBytoMkNv4/ctC9le5W286qOipv1CRtJjaRaKfj23xZ5Qa Zt4A== X-Gm-Message-State: AGi0PuYAsvEidexiop9X1XGeG1NkPfkxAXnYD1F7Zv6rFQvtc6UpqdSu qUaYReB+F6Q+iop3LWNAqGqhqIewql9GcuYAN5k0mg== X-Google-Smtp-Source: APiQypIucvogc7GyLDWKG4mFTtp3SwMHs7MIkgwnfPVLFPW02Bhx8uawbM7chi9elMPVt75OTrYXxiR7pX/NB4VamHE= X-Received: by 2002:ab0:69d4:: with SMTP id u20mr2627837uaq.33.1586285375846; Tue, 07 Apr 2020 11:49:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Tue, 7 Apr 2020 14:49:18 -0400 Message-ID: To: Martin Duke Cc: draft-ietf-tcpm-rack.authors@ietf.org, "tcpm@ietf.org Extensions" , Yuchung Cheng , Priyaranjan Jha Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Comment on draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 18:50:00 -0000 On Tue, Apr 7, 2020 at 12:09 PM Martin Duke wrote: > > Not a full review, but I may be missing something in this paragraph in Section 3: > > Using a threshold for counting duplicate acknowledgments (i.e., > DupThresh) alone is no longer reliable because of today's prevalent > reordering patterns. A common type of reordering is that the last > "runt" packet of a window's worth of packet bursts gets delivered > first, then the rest arrive shortly after in order. To handle this > effectively, a sender would need to constantly adjust the DupThresh > to the burst size; but this would risk increasing the frequency of > RTOs on real losses. > > In the "runt" pattern you describe, would not the returning sequence be > > Dupack, Ack, Ack, Ack ... > > So that any threshold > 1 would handle this with no problems? > > Martin Thanks, I think this point about the threshold is a good point. AFAICT the "final runt packet" case was a real problem for the FACK loss recovery algorithm used by Linux for many years until RACK, but this case was probably not a problem for implementations that used RFC6675 (since RFC6675 basically requires 3 packets SACKed above a hole to mark it lost). To address this, what do you think about the following more general text as a replacement for that paragraph: "Using a threshold for counting duplicate acknowledgments (i.e., DupThresh) alone is no longer reliable because of today's prevalent reordering. Any time at least DupThresh packets in a flight arrive out of order, traditional packet-counting approaches [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To avoid such problems, some implementations have dynamically increased the DupThresh packet count based on the measured degree of reordering in sequence space; but this increases the frequency of RTOs upon real losses in the common case of small flights of data." Thanks, neal From nobody Tue Apr 7 12:16:21 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 9A12A3A0C4E; Tue, 7 Apr 2020 12:16:18 -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 58h9dQFcq7UU; Tue, 7 Apr 2020 12:16:16 -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 D4FE43A0C3C; Tue, 7 Apr 2020 12:16:15 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DFF951B00331; Tue, 7 Apr 2020 20:16:08 +0100 (BST) To: Neal Cardwell , Martin Duke Cc: Priyaranjan Jha , draft-ietf-tcpm-rack.authors@ietf.org, "tcpm@ietf.org Extensions" References: From: Gorry Fairhurst Message-ID: <35cbdaef-77b9-7d7d-0b73-012288f017db@erg.abdn.ac.uk> Date: Tue, 7 Apr 2020 20:16:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Comment on draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 19:16:19 -0000 On 07/04/2020 19:49, Neal Cardwell wrote: > On Tue, Apr 7, 2020 at 12:09 PM Martin Duke wrote: >> Not a full review, but I may be missing something in this paragraph in Section 3: >> >> Using a threshold for counting duplicate acknowledgments (i.e., >> DupThresh) alone is no longer reliable because of today's prevalent >> reordering patterns. A common type of reordering is that the last >> "runt" packet of a window's worth of packet bursts gets delivered >> first, then the rest arrive shortly after in order. To handle this >> effectively, a sender would need to constantly adjust the DupThresh >> to the burst size; but this would risk increasing the frequency of >> RTOs on real losses. >> >> In the "runt" pattern you describe, would not the returning sequence be >> >> Dupack, Ack, Ack, Ack ... >> >> So that any threshold > 1 would handle this with no problems? >> >> Martin > Thanks, I think this point about the threshold is a good point. AFAICT > the "final runt packet" case was a real problem for the FACK loss > recovery algorithm used by Linux for many years until RACK, but this > case was probably not a problem for implementations that used RFC6675 > (since RFC6675 basically requires 3 packets SACKed above a hole to > mark it lost). > > To address this, what do you think about the following more general > text as a replacement for that paragraph: > > "Using a threshold for counting duplicate acknowledgments (i.e., > DupThresh) alone is no longer reliable because of today's prevalent > reordering. Any time at least DupThresh packets in a flight arrive out > of order, traditional packet-counting approaches > [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To > avoid such problems, some implementations have dynamically increased > the DupThresh packet count based on the measured degree of reordering > in sequence space; but this increases the frequency of RTOs upon real > losses in the common case of small flights of data." > > Thanks, > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Neil, would you accept something that doesn't inflame a discussion of what is prevalent and where? Such as: "Using a threshold for counting duplicate acknowledgments (i.e., DupThresh) alone is not reliable in the presence of significant packet reordering. Any time at least DupThresh packets in a flight arrive out of order, traditional packet-counting approaches [RFC5681][RFC6675][FACK] can incur spurious retransmissions. To avoid such problems, some implementations have dynamically increased the DupThresh packet count based on the measured degree of reordering in sequence space; but this increases the frequency of RTOs upon actual losses in the common case of small flights of data." - and would you allow "dynamically increased the DupThresh packet count (e.g., methods based on RFC5960)"? Gorry From nobody Tue Apr 7 13:39: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 023CD3A111A; Tue, 7 Apr 2020 13:39:54 -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 FIwtf0GfSloe; Tue, 7 Apr 2020 13:39:52 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 3F3173A1117; Tue, 7 Apr 2020 13:39:52 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id g15so4586051ilj.10; Tue, 07 Apr 2020 13:39:52 -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=X4QD4RvKiNv37e+m4sTvSRauSMZNM0DUywjZyl1LvZ4=; b=Gi9phkorrGDTJcR6/nlx0EQqIQhHZTrFZ50r9mi+cd/qQhEWz6o7wUdtLgAONQHH+/ BVm2Eqe4t1ckQajoilB9+4lH+AIu617MlKO8lVnmhA5mqdmxG4ZaZU180AxQc5doz74u Ko0O/PxT1BQg0iBPaaRVdRJ8Hv26c0dWK3n0/R/k7jJqogO+1ObXiKlNF4615oYJp3SK 0wIUK2eCSGCLKyB8RTX0EAQ0RaVOXtbkYOx2gzXNmARvFfFWM5XdyIwR7HZYzBHIxiXf /DTq6wq6kd2ncr462DBt+uEpBryNTw7EuM9uB2bhTyEaZA1Gx8WiX2hDtLOj0gfSOK8h 4LHQ== 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=X4QD4RvKiNv37e+m4sTvSRauSMZNM0DUywjZyl1LvZ4=; b=FZwJNSD2R+fCT3+kNrjKUP4JSMJ10soOw+Gt4woCdANES+C4K7tx92PDM/hM3uAZ3b P5dRxUHDLBPvAN+Gk69R2/n9t8N2iBAgBaE+EFdGt/GN2Toxt42j83GKq3AVEMp3h6nE FLzEDIeoN5IFMfdW7i1GMq3azhOVRqAyYRI8lDwdeNWsWI6cpLetpUyI8lpqHThuDMqF bAMQECC34RpPnsGIK3hpJ8WP6bPbWt/L46henxt96AP9+dhmAIhWbS9hjvqRv3TyMrkM cp1tIsqlOX3HCVQm5XIirveDuX+Y15gC7cIYxyEyBNkNyqO6FKOecqh9tunec1giL7S4 X6hA== X-Gm-Message-State: AGi0PubKOCJ7g+GVnDn5Nvr1/EkxNK+xXQViPfXwHomqCS1/fZ+lgR7f lQvcglK2O5HbAVxSRu1c8EBZC9RHLonmOXlY02g= X-Google-Smtp-Source: APiQypIRcFF1sDlLWFA2Mot4WISVPL7PSce8pjAN9jSSmK3RWed1J+vyYtZBnZ1Mhrc0aid/KtqWyztUUqlsYtwvNcE= X-Received: by 2002:a92:ba51:: with SMTP id o78mr4506790ili.290.1586291991290; Tue, 07 Apr 2020 13:39:51 -0700 (PDT) MIME-Version: 1.0 References: <35cbdaef-77b9-7d7d-0b73-012288f017db@erg.abdn.ac.uk> In-Reply-To: <35cbdaef-77b9-7d7d-0b73-012288f017db@erg.abdn.ac.uk> From: Martin Duke Date: Tue, 7 Apr 2020 13:39:41 -0700 Message-ID: To: Gorry Fairhurst Cc: Neal Cardwell , Priyaranjan Jha , draft-ietf-tcpm-rack.authors@ietf.org, "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000a6aa1f05a2b9626d" Archived-At: Subject: Re: [tcpm] Comment on draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 20:39:54 -0000 --000000000000a6aa1f05a2b9626d Content-Type: text/plain; charset="UTF-8" Either is fine with me. BTW there's no Table of Contents in the draft either. On Tue, Apr 7, 2020 at 12:16 PM Gorry Fairhurst wrote: > > On 07/04/2020 19:49, Neal Cardwell wrote: > > On Tue, Apr 7, 2020 at 12:09 PM Martin Duke > wrote: > >> Not a full review, but I may be missing something in this paragraph in > Section 3: > >> > >> Using a threshold for counting duplicate acknowledgments (i.e., > >> DupThresh) alone is no longer reliable because of today's prevalent > >> reordering patterns. A common type of reordering is that the last > >> "runt" packet of a window's worth of packet bursts gets delivered > >> first, then the rest arrive shortly after in order. To handle this > >> effectively, a sender would need to constantly adjust the DupThresh > >> to the burst size; but this would risk increasing the frequency of > >> RTOs on real losses. > >> > >> In the "runt" pattern you describe, would not the returning sequence be > >> > >> Dupack, Ack, Ack, Ack ... > >> > >> So that any threshold > 1 would handle this with no problems? > >> > >> Martin > > Thanks, I think this point about the threshold is a good point. AFAICT > > the "final runt packet" case was a real problem for the FACK loss > > recovery algorithm used by Linux for many years until RACK, but this > > case was probably not a problem for implementations that used RFC6675 > > (since RFC6675 basically requires 3 packets SACKed above a hole to > > mark it lost). > > > > To address this, what do you think about the following more general > > text as a replacement for that paragraph: > > > > "Using a threshold for counting duplicate acknowledgments (i.e., > > DupThresh) alone is no longer reliable because of today's prevalent > > reordering. Any time at least DupThresh packets in a flight arrive out > > of order, traditional packet-counting approaches > > [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To > > avoid such problems, some implementations have dynamically increased > > the DupThresh packet count based on the measured degree of reordering > > in sequence space; but this increases the frequency of RTOs upon real > > losses in the common case of small flights of data." > > > > Thanks, > > neal > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > Neil, would you accept something that doesn't inflame a discussion of > what is prevalent and where? > > Such as: > > "Using a threshold for counting duplicate acknowledgments (i.e., > DupThresh) alone is not reliable in the presence of significant packet > reordering. Any time at least DupThresh packets in a flight arrive out > of order, traditional packet-counting approaches > [RFC5681][RFC6675][FACK] can incur spurious retransmissions. To > avoid such problems, some implementations have dynamically increased > the DupThresh packet count based on the measured degree of reordering > in sequence space; but this increases the frequency of RTOs upon actual > losses in the common case of small flights of data." > > - and would you allow "dynamically increased > the DupThresh packet count (e.g., methods based on RFC5960)"? > > Gorry > --000000000000a6aa1f05a2b9626d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Either is fine with me.

BTW = there's no Table of Contents in the draft either.

On Tue, Apr = 7, 2020 at 12:16 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

On 07/04/2020 19:49, Neal Cardwell wrote:
> On Tue, Apr 7, 2020 at 12:09 PM Martin Duke <martin.h.duke@gmail.com> wrot= e:
>> Not a full review, but I may be missing something in this paragrap= h in Section 3:
>>
>>=C2=A0 =C2=A0 =C2=A0Using a threshold for counting duplicate acknow= ledgments (i.e.,
>>=C2=A0 =C2=A0 =C2=A0DupThresh) alone is no longer reliable because = of today's prevalent
>>=C2=A0 =C2=A0 =C2=A0reordering patterns.=C2=A0 A common type of reo= rdering is that the last
>>=C2=A0 =C2=A0 =C2=A0"runt" packet of a window's worth= of packet bursts gets delivered
>>=C2=A0 =C2=A0 =C2=A0first, then the rest arrive shortly after in or= der.=C2=A0 To handle this
>>=C2=A0 =C2=A0 =C2=A0effectively, a sender would need to constantly = adjust the DupThresh
>>=C2=A0 =C2=A0 =C2=A0to the burst size; but this would risk increasi= ng the frequency of
>>=C2=A0 =C2=A0 =C2=A0RTOs on real losses.
>>
>> In the "runt" pattern you describe, would not the return= ing sequence be
>>
>> Dupack, Ack, Ack, Ack ...
>>
>> So that any threshold > 1 would handle this with no problems? >>
>> Martin
> Thanks, I think this point about the threshold is a good point. AFAICT=
> the "final runt packet" case was a real problem for the FACK= loss
> recovery algorithm used by Linux for many years until RACK, but this > case was probably not a problem for implementations that used RFC6675<= br> > (since RFC6675 basically requires 3 packets SACKed above a hole to
> mark it lost).
>
> To address this, what do you think about the following more general > text as a replacement for that paragraph:
>
> "Using a threshold for counting duplicate acknowledgments (i.e.,<= br> > DupThresh) alone is no longer reliable because of today's prevalen= t
> reordering. Any time at least DupThresh packets in a flight arrive out=
> of order, traditional packet-counting approaches
> [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To > avoid such problems, some implementations have dynamically increased > the DupThresh packet count based on the measured degree of reordering<= br> > in sequence space; but this increases the frequency of RTOs upon real<= br> > losses in the common case of small flights of data."
>
> Thanks,
> neal
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

Neil, would you accept something that doesn't inflame a discussion of <= br> what is prevalent and where?

Such as:

"Using a threshold for counting duplicate acknowledgments (i.e.,
DupThresh) alone is not reliable in the presence of significant packet
reordering. Any time at least DupThresh packets in a flight arrive out
of order, traditional packet-counting approaches
[RFC5681][RFC6675][FACK] can incur spurious retransmissions. To
avoid such problems, some implementations have dynamically increased
the DupThresh packet count based on the measured degree of reordering
in sequence space; but this increases the frequency of RTOs upon actual
losses in the common case of small flights of data."

- and would you allow "dynamically increased
the DupThresh packet count (e.g., methods based on RFC5960)"?

Gorry
--000000000000a6aa1f05a2b9626d-- From nobody Tue Apr 7 14:33: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 8180E3A044D for ; Tue, 7 Apr 2020 14:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 239i6lltXnMD for ; Tue, 7 Apr 2020 14:33:52 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (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 C54D93A043A for ; Tue, 7 Apr 2020 14:33:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nRKniNQGwXH8y9WvMLx+SAZyvl/5QxsxWY7/qInKp3Y4eC8XgWuMFUCEUwWFQPDLsM9BafBRJMQpAC8LtKllsTvWIXEisxF6rEx+eZyKkIEBd0RjQfwPZQrCV+IbTJ0SH/46en6y+BoRqcWmz3wvlprXizlgC3kJ4ronIIqVyHgJJaZxyDPgQ2fO0ggyWds8HvXLHVIMvSRaB69DnNIrBHzVVUCT9reswdpJPHhO+VG476xznx9UNRlxTME+9oglV55u+CvDNdKRPaZIIWXlLornH9xSzQcoa+mOf9M6yZrvAYRY4et6xuKXr2dgcDSAjSYnEcZr0Q16oU2P+LEznw== 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=5WARGvVs3+dKelwxG3AEQN89OnQiwbVbY9lEjn9Q598=; b=jeXZCjelDkFJp5+4e/sDApmmlMq/1RrGJ4T4qUMbYVpjBaEd6q2YARwiEmEgEGetEjMwUSi4QBjqqVijkGYo5zXPmWBu5adAKM/gxBbarRZ9Mmvb4a2Ih3rfOO9EdXdGV65nL9qv0nnmQwnZqcsiirUhii9K4FUHckGN/dc/YQf4cWf2wSE2PApBAGifa0BqkmP/xMttInNw1/p+XpDDfRSgKbjJbcNa0eV9/eVeCsjhXGO8mVZxCnU7FM2++CR8/V7j90f6MVDIEoet8ekPfGg0UBiGKddFTmbEYJJTguNlyy9ANSEVeQHOaP6CPvPozRKMvK1CYBz9LMg4FbSReQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5WARGvVs3+dKelwxG3AEQN89OnQiwbVbY9lEjn9Q598=; b=fKoD1oCAHiWvlqwt8d9DyEAyWlvLjLRzFj4aS8Y3I//fuX30URph1Qja1Q9cx29XN5tYlsHVMB0M0F8cHzOFe+lhQwSdohDW+KuFi7X7r1daSZjwxKwBbHp74OuNDof8G5e65FCofqeEybhFL2enjtjVxeCSBvKD9r3cTjn3I5s= Received: from CY1PR00MB0073.namprd00.prod.outlook.com (2a01:111:e400:c619::6) by CY1PR00MB0172.namprd00.prod.outlook.com (2a01:111:e400:c639::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2927.0; Tue, 7 Apr 2020 21:33:50 +0000 Received: from CY1PR00MB0073.namprd00.prod.outlook.com ([fe80::41ba:7011:6759:30fb]) by CY1PR00MB0073.namprd00.prod.outlook.com ([fe80::41ba:7011:6759:30fb%3]) with mapi id 15.20.2933.000; Tue, 7 Apr 2020 21:33:50 +0000 From: Yi Huang To: "tcpm@ietf.org" Thread-Topic: Review of draft-ietf-tcpm-rack-08 Thread-Index: AdYMcYeKU5D6wIVsRbC1mO/lVnSLwA== Date: Tue, 7 Apr 2020 21:33:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-07T21:33:48.7833191Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f25c7c87-c7cc-47e2-ae0d-4b2f4ed88b0d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2601:600:877f:ac89:89b5:6d38:d3e3:9333] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: aba8312c-530c-4beb-0c01-08d7db3b5cd1 x-ms-traffictypediagnostic: CY1PR00MB0172:|CY1PR00MB0172: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY1PR00MB0073.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(478600001)(71200400001)(66556008)(76116006)(8990500004)(82960400001)(8936002)(66476007)(66446008)(64756008)(82950400001)(81166006)(33656002)(81156014)(5660300002)(52536014)(8676002)(66946007)(9686003)(2906002)(4744005)(7696005)(107886003)(54906003)(316002)(6916009)(186003)(86362001)(6506007)(4326008)(55016002)(10290500003); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YKNR3reTf8c99Y9/Aa3W+mLQwUvteBDGXgb2h49L6Y01UYyIqtFxytOWUNpjKHavxwIDKfr8WgD/l2zokpBkplF2fWFAO9vd6F80RMSxnuLEyEUBk1yTCeyz5D9kIfl8JpGiWbEjpxZ3kovqh1c+ny3nX0QzFOPjlSkQFecRnH67ZmzMygZQbdyNxxs3PAL7YuZmWPOnFs8AX6kmPsAIKo9EQgMdE7TmG0LqdyWsRTcGFZbHjx8ktv33x8J6K9M4/iR0qGLeZ4cXJffU9d8zKMV/+XKqPc0tzu5psmecM3kCOceGcNjTL7uECIRb2nqfCUiIpTShbBhZCOvGrciTAETF0s2jNwwr4vGQXMj8jauB9qkTzPPbDRz6JFmknP2puUkMB+LwmW336LJb9ciXUzxttXOvaQDgbcQODHwB4P1ryDdsImmdHxOaZ5tW8yLl x-ms-exchange-antispam-messagedata: ZmE34zdKibvM5/TlzD7xhbpNcV3rlImYoy53Jr+L2KhiXWFYLKteaQbm2VblF2NYTzoZEmTopHyUGUr4wfSaURqFcBhI3WxT4hd5owE+gY62kxC03eR+H77YVxGUbbTnMRPVblvqJ31S4E2r5rGy0Zgaxj7+3Jf22wgNvwuWmyxWaqLDHH4bq0XDaZvrBDwwckNFikhikp1TSm+F1eeKhQ== Content-Type: multipart/alternative; boundary="_000_CY1PR00MB00730D6D03F31E39E4780EEEC3C30CY1PR00MB0073namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: aba8312c-530c-4beb-0c01-08d7db3b5cd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 21:33:50.1432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Flf8iW0Q7umuRuZrLwJmrhVM+AQ2G3UdQZh9dqU+L0APUP6itBOh1wjfCfmHWklZ3h0mUBhoqzeveEVQlX3DwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0172 Archived-At: Subject: [tcpm] Review of draft-ietf-tcpm-rack-08 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 21:33:54 -0000 --_000_CY1PR00MB00730D6D03F31E39E4780EEEC3C30CY1PR00MB0073namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I reviewed the latest version of RACK and I have a few questions about the = RACK timer. 1. In Section 7.2, Step 5: Detect losses, the draft states how/when the = RACK timer is armed. However, it's not very clear that how/when it is cance= led. I suppose when a cumulative ACK arrives and RACK_detect_loss() returns= with timeout =3D 0, it should be canceled? Are the RACK timer and the RTO = timer mutually exclusive? 1. When the RACK timer fires and calls RACK_detect_loss(), due to clock = granularity, the packets, for which the timer was scheduled for, might have= not expired yet. Thus, the RACK timer might be scheduled several times for= the same set of packets even when there is no new (S)ACK coming back. I t= hink it would be helpful to implementers if this is addressed/discussed in = the spec. Thanks, Yi --_000_CY1PR00MB00730D6D03F31E39E4780EEEC3C30CY1PR00MB0073namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I reviewed the latest version of RACK and I have a f= ew questions about the RACK timer.

 

  1. In Section 7.2, Step 5: Detect losses, the draft states how/when the = RACK timer is armed. However, it’s not very clear that how/when it is= canceled. I suppose when a cumulative ACK arrives and RACK_detect_loss() returns with timeout =3D 0, it should be ca= nceled? Are the RACK timer and the RTO timer mutually exclusive?=

 

  1. When the RACK timer fires and calls RACK_detect_loss(), due to clock = granularity, the packets, for which the timer was scheduled for, might have= not expired yet. Thus, the RACK timer might be scheduled several times for the same set of packets  even wh= en there is no new (S)ACK coming back. I think it would be helpful to imple= menters if this is addressed/discussed in the spec.

 

Thanks,

 

Yi

 

 

--_000_CY1PR00MB00730D6D03F31E39E4780EEEC3C30CY1PR00MB0073namp_-- From nobody Tue Apr 7 17:14: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 C68063A0D0A for ; Tue, 7 Apr 2020 17:14:36 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 kbd8M2yLsoZ2 for ; Tue, 7 Apr 2020 17:14:35 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 9E5393A0D07 for ; Tue, 7 Apr 2020 17:14:35 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id x82so3609243vsc.12 for ; Tue, 07 Apr 2020 17:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=0liOA1j6nvyxx+2WOG+I8hLYu9bfPsPU5l7dlXcrvcY=; b=tAJ/TfIH6V3sadit37UQCJBszxO9I3WKRHmv81kEbYZ1/g1LPsJVB3OwXmxj7dIwzZ 4+d7Y3joYjIP2lU4F8X6e/6Sbepb5O8d6/7OA40V6mFZhkDsnr27s7/s2OXXdsBaRzMy VefPprusCDwAc8Pslr9d4dVroin+8AlGvq7mfRjuJi8imwEgE71ztQ389lAXaaj/KSa2 QE7WyHQtHKIObAFvLyqomi7mRL8gclQU970BbkaelYoWcNIKzkmqTmINcH7DmBA6R8K7 SM40qOxmRfQfTUMZF30fqpFggXhooYCT79ef00ChmMvQVf4CWOrkT9LejbwbfJIw+9lj 8KMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0liOA1j6nvyxx+2WOG+I8hLYu9bfPsPU5l7dlXcrvcY=; b=FoWTDuveSGs1HfObfqm/chpjhouir2Mn/H5Qt6ezv0Hwr4NUf3Q7HgVW315TJb2K9V 1LbtN9hsMlCVlgZZwFJpSp04WAuYrQTJnBkRYjGE4pO6HIUwph9BywpGjErY4+ewNpra I7yaRiNEZrOWvhFMw2zTZLOFH+YAYkUVKpX8QaOI4rGbgsUgw9neADijNejPXBNrg/E7 3t4yIyZRkl/x240LPPmbyxcHFlLlrNCXQ509mmefRz609RpXKAWx2UFe3DkjVEa48JbK z9qPHZxYyJNgON1Sicz2dmcheZ4EPnvN3R+ksvThKh4tvjwKIPjGpvsHK6hhWwGtShdz KldA== X-Gm-Message-State: AGi0Pub4OJeJTghrbW+UfgYph/NI0Yh4VH0Qyzr4GGzbYDooM+/Pkmxx VCvr+xzQE3M5AEgfEOK9iLSNpKYQ54QhnG94BAZ1mpOP X-Google-Smtp-Source: APiQypLqF+pjg0bntK+OSPAcasdARgPepjJAj0vkwRhHj/YrXMWCGhNGPN6a5YnZ5CHPNPGO/wwSiujnmZ4YWJMafjs= X-Received: by 2002:a67:70c2:: with SMTP id l185mr3959284vsc.123.1586304873813; Tue, 07 Apr 2020 17:14:33 -0700 (PDT) MIME-Version: 1.0 From: Yuchung Cheng Date: Tue, 7 Apr 2020 17:13:57 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000082bb7b05a2bc6263" Archived-At: Subject: [tcpm] RACK WGLC reviews 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, 08 Apr 2020 00:14:37 -0000 --00000000000082bb7b05a2bc6263 Content-Type: text/plain; charset="UTF-8" Hi all, Thank you all for reviewing RACK -- the comments are great! We've been discussing internally but some of us are on Spring break. It may take a few days to review all the comments together to address them consistently. Yuchung on behalf RACK authors --00000000000082bb7b05a2bc6263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thank you all for reviewing RAC= K -- the comments are great!=C2=A0 We've been discussing internally but= some of us are on Spring break. It may take a few days to review all the c= omments together to address them consistently.

Yuc= hung on behalf RACK authors
--00000000000082bb7b05a2bc6263-- From nobody Tue Apr 7 17:24:42 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 4D8B23A0DFA for ; Tue, 7 Apr 2020 17:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=microsoft.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 OH6vuynI9Our for ; Tue, 7 Apr 2020 17:24:39 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640132.outbound.protection.outlook.com [40.107.64.132]) (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 1305D3A0DFD for ; Tue, 7 Apr 2020 17:24:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mPWXO3OSLChBSHi0m4jqoK6a84M42V9GL1mMyYpAtkiFyKzkrSL854iXI+k5HBzh6O2ZlUKESErUnnP0HmBHasY0OgY4pgEZtzkQXPezGD9iwO7f/k/jwUhVOJmGNr01Jcfr9wgYoySVFgqlAsUhIzn8BcSKq2jodDHS+9kKUSRNZbWIrmpOU80U2RApf8DbtkYFZrY6HetsF8bPT4DBkm/ab3gSAZfJML1wXUzivhQeVO4iCJN/dbZfDL7IsWG7DNSZKEyHRyUNkj0/m/MskJ7I/d1GE2DzQaRoKq6DK1uungL+gY+IN8Tc7JttUNBNang2op4Pr0yCJHsMymm40w== 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=4AaCYgXDWVL3Qz7yLYtfyPL3/yYNSAT5wQ1rXftnUQg=; b=mb3Nn9OJiJ5BgFEhqkH0aLhJ9KEVkLUG/oG28nTzta3njE12GR3OnL5g4WmIkBYnljP21V0LLqaKxvXeW2REaksvYF6T29QetyyTVCb94ppUCK6vCjDiIt4VuVkyIKz7NPxREVXa/L+k1LS2QkEcaXN5tu52++19ogBD+gQBRcJ1w+v77H7E+tgA64bbkzjeyLXNhujBYuIOr9zPlpWJV5ZRVh2mC6UbKp2KUfh9JocioC3Y/jB8jICSkQpBtfBDiEKbbp7vSjc0dIPDsyEWJ7nFmjiQJDkdZKBqzsDyr8UjxKLMa+q8ziPQDqJomifB2kYyti+zvsfjCCpmS+3GPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4AaCYgXDWVL3Qz7yLYtfyPL3/yYNSAT5wQ1rXftnUQg=; b=F3pEJSCKhmYFM6wPff6Kd2J+gzicm6Stj76OecMj5t5EAu43hI0nqwYlsmcdGUyAiIKuYaJE3cSH0mm4X3zXBx43WgFVq9wBpY6fI10M+gReTYArv/zDW7w/BebCCEqQgT2KXsWDJVBV1C85cc/MgazQlDNUw4N6l1C/0EWP9NE= Received: from CY1PR00MB0073.namprd00.prod.outlook.com (2a01:111:e400:c619::6) by CY1PR00MB0156.namprd00.prod.outlook.com (2a01:111:e400:c638::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2927.0; Wed, 8 Apr 2020 00:24:37 +0000 Received: from CY1PR00MB0073.namprd00.prod.outlook.com ([fe80::41ba:7011:6759:30fb]) by CY1PR00MB0073.namprd00.prod.outlook.com ([fe80::41ba:7011:6759:30fb%3]) with mapi id 15.20.2933.000; Wed, 8 Apr 2020 00:24:37 +0000 From: Yi Huang To: Junho Choi CC: Praveen Balasubramanian , "tcpm@ietf.org" Thread-Topic: [EXTERNAL] Questions on HyStart++ draft 02 Thread-Index: AQHWCHuVjeyKxI/TR0GdAjicR50BCqhk60fwgACL0ACACO+DgA== Date: Wed, 8 Apr 2020 00:24:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-08T00:24:34.9945618Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=702f9177-2dde-4550-92f8-568a8f3bc65b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2601:600:877f:ac89:a0ef:dbfe:63ba:132d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 99277976-1012-49bd-c448-08d7db533872 x-ms-traffictypediagnostic: CY1PR00MB0156:|CY1PR00MB0156: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY1PR00MB0073.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(6029001)(4636009)(346002)(366004)(39860400002)(396003)(376002)(136003)(33656002)(54906003)(7696005)(4326008)(478600001)(316002)(10290500003)(52536014)(86362001)(6506007)(8990500004)(5660300002)(8936002)(2906002)(71200400001)(9686003)(66946007)(186003)(82950400001)(82960400001)(6916009)(66476007)(64756008)(8676002)(81156014)(66556008)(55016002)(81166006)(66446008)(76116006)(53546011); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6BEp1zhhvG8CAHZ4OPMZBpIc4QUVxd7tV6IQ2tcgftnBS6/mhGiGRZPY7UfK4S1qTGGgSBOQUz/3Z8U7WLSw306dLRj2JfOQ35ayugHgyptwPVPisB+mtDRKAYZE+BJnCHoCyodnQvEUiUCUaf3o6KdkNTgZIEDsbZntI8fgm1CP5ewHbcDHHOpE9oD6SRU0tuLzokicxf441yGV1S9i3te6PldbYtpbDYCXRFbu4+k+rFZAANnrTBTZ9yHRarlPg8Htc51TdojOeCl4OrXHUFVrz9sOyyvnWIDleLIARWL9hKUR60iw8IUkidvRL/oXyAxoXmSRYc10YdLT99dZvxAv9WttGsdL2nQZuwEJkc8pRLSAcrTjJgxQ4SzoJcJ47pTzVgFZBXnqk5cLh0NM6Z6+2MZQEaGpEjyDH8Q0uiwOy/jNZLA/kmOyE2YgWlM8rJuarBTOSc4W5QAAUPDn0zgsksL96zh1ifcjlds3LTd8PKJMtvfmEQEUQw34qwXaKZWUuId1vNGBWyAxeTWkbg== x-ms-exchange-antispam-messagedata: FYRB3FykkK1ncta2YC5XWBLeJPX5P0nVMKjWmGmJ0WcgK6GDnuHEEMZQiIgPttPfUIg+Z0mXRI5jBRRU/l16qdnTlV2/fiY0cC+Mc395izwbXIYNAQTq8kHmGtBEAvefuifp8Jv4NIy9hpGYSskQOWnRUfZI185UFpC7o3mCv8BFjT9hwDwswf9gZxxnokXxRNCvLI/jtLtaNcjOCdGhgA== Content-Type: multipart/alternative; boundary="_000_CY1PR00MB007307864A3675BE240369BDC3C00CY1PR00MB0073namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99277976-1012-49bd-c448-08d7db533872 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 00:24:36.9909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4D/kZEt0x/44FqpiQd542JRGKDcRhimsqJBylAYSrVSK5g13OSQl0ve2QIbE2NtQrjpE2bDezlY7ZYKU20H/IQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0156 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 00:24:41 -0000 --_000_CY1PR00MB007307864A3675BE240369BDC3C00CY1PR00MB0073namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVhaCwgaXQgZG9lcyBub3RoaW5nIGZvciB0aGUgZmlyc3Qgcm91bmQuDQoNCkZyb206IEp1bmhv IENob2kgPGp1bmhvLmNob2lAZ21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIsIDIw MjAgMTI6NTUgQU0NClRvOiBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29mdC5jb20+DQpDYzogUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyB0Y3BtQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBRdWVzdGlvbnMgb24gSHlTdGFydCsrIGRyYWZ0IDAy DQoNCkhpIFlpLA0KDQpUaGFua3MuIFNlZSBpbmxpbmUgZm9yIG15IGZvbGxvd2luZyBxdWVzdGlv bi4NCg0KT24gV2VkLCBBcHIgMSwgMjAyMCBhdCA1OjA0IFBNIFlpIEh1YW5nIDxodWFueWlAbWlj cm9zb2Z0LmNvbTxtYWlsdG86aHVhbnlpQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCjEuIFNlY3Rp b24gNC4yIC0tIGVhY2ggcm91bmQgaXMgaW5pdGlhbGl6ZWQgYXMNCg0KICAgbGFzdFJvdW5kTWlu UlRUID0gY3VycmVudFJvdW5kTWluUlRUDQogICBjdXJyZW50Um91bmRNaW5SVFQgPSBpbmZpbml0 eQ0KICAgcnR0U2FtcGxlQ291bnQgPSAwDQoNCkluIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiB0aGUg Y29ubmVjdGlvbiwgd2hhdCBpcyAiY3VycmVudFJvdW5kTWluUlRUIiB3aGVuDQp0aGVyZSBpcyBu byBwcmV2aW91cyB2YWx1ZT8NCg0KSSBhbSB1c2luZyBjdXJyZW50IHJ0dCAob3IgaW5pdGlhbCBy dHQgdmFsdWUpIGFuZCBpcyBpdCBvaz8NCg0KW1lpXTogSW4gb3VyIGltcGxlbWVudGF0aW9uLCBs YXN0Um91bmRNaW5SVFQgYW5kIGN1cnJlbnRSb3VuZE1pblJUVCBhcmUgaW5pdGlhbGl6ZWQgdG8g MHhmZmZmZmZmZiBhcyBzZW50aW5lbCB2YWx1ZXMuIFdlIG9ubHkgY29tcGFyZSBsYXN0Um91bmRN aW5SVFQgd2l0aCBjdXJyZW50Um91bmRNaW5SVFQgd2hlbiBib3RoIG9mIHRoZW0gYXJlIHZhbGlk IHZhbHVlcy4gVXNpbmcgY3VyclJUVCBzZWVtcyB0byBlc3NlbnRpYWxseSBiZWhhdmUgdGhlIHNh bWUgYXMgYXNzaWduaW5nIGEgc2VudGluZWwgdmFsdWUuDQoNClNvIGluIHRoZSBiZWdpbm5pbmcg b2YgdGhlIGNvbm5lY3Rpb24gbGFzdFJvdW5kTWluUlRUIGlzIDxpbmY+LiBXaGVuIGFjayBpcyBy ZWNlaXZlZCBjdXJyZW50Um91bmRNaW5SVFQgPSBtaW5fcnR0IGJ1dA0KbGFzdFJvdW5kTWluUlRU IGlzIHN0aWxsIDxpbmY+LiBXaGVuIHRoZSAxc3Qgcm91bmQgZW5kcywgaXQgbG9va3MgYWx3YXlz IGRvaW5nIG5vdGhpbmcgYmVjYXVzZSB0aGUgZm9sbG93aW5nIGlmKCkgaXMgYWx3YXlzIGZhbHNl Pw0KDQogIGlmIChjdXJyZW50Um91bmRNaW5SVFQgPj0gKGxhc3RSb3VuZE1pblJUVCArIFJ0dFRo cmVzaCkpDQoNCg0KDQoyLiBTZWN0aW9uIDQuMiAtLSBXaGVuIHVzZWQgd2l0aCBjdWJpYywgQ0Ff Y3duZCgpIGlzIGJhc2VkIG9uIGN1YmljIGFsZ29yaXRobSBJIHRoaW5rLg0KIFRoaXMgbWVhbnMg SSBuZWVkIHRvIGRvIGN1YmljIHZhcmlhYmxlcyBjYWxjdWxhdGlvbiBkdXJpbmcgc2xvdyBzdGFy dA0KIHN1Y2ggYXMgSyBhbmQgV19jdWJpYy4gV2hlbiBpcyBjb25zaWRlcmVkIGFzIGEgc3RhcnQg b2YNCiBjb25nZXN0aW9uIGF2b2lkYW5jZSBhbmQgd2hhdCBXX21heCB3aWxsIGJlPw0KDQogQ3Vy cmVudGx5IEkgdXNlIGEgc3RhcnQgb2YgbGltaXRlZCBzbG93IHN0YXJ0IGFzIGEgYmVnaW5uaW5n IG9mIGNvbmdlc3Rpb24gcmVjb3ZlcnkNCiBhbmQgdXNlIGN3bmQgYXQgdGhlIHRpbWUgZm9yIFdf bWF4LiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQoNCltZaV06IFllcywgdGhhdOKAmXMg ZXhhY3RseSB3aGF0IHdlIGRvIGluIFdpbmRvd3MuDQoNClNvdW5kIGdyZWF0LiBUaGFua3MuDQoN CkJlc3QsDQoNCi0tDQpKdW5obyBDaG9pIDxqdW5obyBkb3QgY2hvaSBhdCBnbWFpbC5jb208aHR0 cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0El MkYlMkZnbWFpbC5jb20lMkYmZGF0YT0wMiU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3 QzVlZDQyZGUwYjM4ZTQ5N2Q1MDJhMDhkN2Q2ZGI0MDU1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIxNDEwOTQ2OTg1NjczNyZzZGF0YT0lMkZBMmZ2b1JP MDQ1Mkk1UDJDbldSeW9ET2hPMzh3SER5T0FGNm41OFVETFklM0QmcmVzZXJ2ZWQ9MD4+DQo= --_000_CY1PR00MB007307864A3675BE240369BDC3C00CY1PR00MB0073namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCBpdCBkb2VzIG5vdGhp bmcgZm9yIHRoZSBmaXJzdCByb3VuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEp1bmhvIENob2kgJmx0O2p1bmhvLmNob2lA Z21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDIsIDIwMjAg MTI6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IFlpIEh1YW5nICZsdDtodWFueWlAbWljcm9zb2Z0LmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBt aWNyb3NvZnQuY29tJmd0OzsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0VYVEVSTkFMXSBRdWVzdGlvbnMgb24gSHlTdGFydCYjNDM7JiM0MzsgZHJhZnQgMDI8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFlpLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuIFNlZSBp bmxpbmUgZm9yIG15IGZvbGxvd2luZyBxdWVzdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDEsIDIwMjAgYXQgNTowNCBQTSBZaSBI dWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1YW55aUBtaWNyb3NvZnQuY29tIj5odWFueWlAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIFNlY3Rpb24gNC4yIC0tIGVhY2gg cm91bmQgaXMgaW5pdGlhbGl6ZWQgYXM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtsYXN0Um91bmRNaW5S VFQgPSBjdXJyZW50Um91bmRNaW5SVFQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO2N1cnJlbnRSb3VuZE1pblJUVCA9IGlu ZmluaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyAmbmJzcDtydHRTYW1wbGVDb3VudCA9IDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiB0aGUgdmVyeSBi ZWdpbm5pbmcgb2YgdGhlIGNvbm5lY3Rpb24sIHdoYXQgaXMgJnF1b3Q7Y3VycmVudFJvdW5kTWlu UlRUJnF1b3Q7IHdoZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+dGhlcmUgaXMgbm8gcHJldmlvdXMgdmFsdWU/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIHVzaW5nIGN1cnJl bnQgcnR0IChvciBpbml0aWFsIHJ0dCB2YWx1ZSkgYW5kIGlzIGl0IG9rPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+W1lpXTogSW4gb3VyIGltcGxlbWVudGF0aW9uLCBsYXN0Um91bmRNaW5S VFQgYW5kIGN1cnJlbnRSb3VuZE1pblJUVCBhcmUgaW5pdGlhbGl6ZWQgdG8gMHhmZmZmZmZmZiBh cyBzZW50aW5lbCB2YWx1ZXMuIFdlIG9ubHkgY29tcGFyZSBsYXN0Um91bmRNaW5SVFQgd2l0aCBj dXJyZW50Um91bmRNaW5SVFQgd2hlbg0KIGJvdGggb2YgdGhlbSBhcmUgdmFsaWQgdmFsdWVzLiBV c2luZyBjdXJyUlRUIHNlZW1zIHRvIGVzc2VudGlhbGx5IGJlaGF2ZSB0aGUgc2FtZSBhcyBhc3Np Z25pbmcgYSBzZW50aW5lbCB2YWx1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TbyBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBjb25uZWN0aW9uIGxhc3RSb3Vu ZE1pblJUVCBpcyAmbHQ7aW5mJmd0Oy4gV2hlbiBhY2sgaXMgcmVjZWl2ZWQgY3VycmVudFJvdW5k TWluUlRUID0gbWluX3J0dCBidXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmxhc3RSb3VuZE1pblJUVCBpcyBzdGlsbCAmbHQ7aW5mJmd0Oy4gV2hl biB0aGUgMXN0IHJvdW5kIGVuZHMsIGl0IGxvb2tzIGFsd2F5cyBkb2luZyBub3RoaW5nIGJlY2F1 c2UgdGhlIGZvbGxvd2luZyBpZigpIGlzIGFsd2F5cyBmYWxzZT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGlmIChjdXJyZW50Um91 bmRNaW5SVFQgJmd0Oz0gKGxhc3RSb3VuZE1pblJUVCAmIzQzOyBSdHRUaHJlc2gpKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4gU2VjdGlvbiA0LjIgLS0g V2hlbiB1c2VkIHdpdGggY3ViaWMsIENBX2N3bmQoKSBpcyBiYXNlZCBvbiBjdWJpYyBhbGdvcml0 aG0gSSB0aGluay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7VGhpcyBtZWFucyBJIG5lZWQgdG8gZG8gY3ViaWMgdmFyaWFibGVzIGNh bGN1bGF0aW9uIGR1cmluZyBzbG93IHN0YXJ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO3N1Y2ggYXMgSyBhbmQgV19jdWJpYy4gV2hl biBpcyBjb25zaWRlcmVkIGFzIGEgc3RhcnQgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Y29uZ2VzdGlvbiBhdm9pZGFuY2UgYW5k IHdoYXQgV19tYXggd2lsbCBiZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwO0N1cnJlbnRseSBJIHVzZSBhIHN0YXJ0IG9mIGxpbWl0ZWQgc2xvdyBzdGFy dCBhcyBhIGJlZ2lubmluZyBvZiBjb25nZXN0aW9uIHJlY292ZXJ5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO2FuZCB1c2UgY3duZCBh dCB0aGUgdGltZSBmb3IgV19tYXguIElzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPltZaV06IFllcywgdGhhdOKAmXMgZXhhY3RseSB3aGF0IHdl IGRvIGluIFdpbmRvd3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U291bmQgZ3JlYXQuIFRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLSA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5KdW5obyBDaG9pICZsdDtqdW5obyBkb3QgY2hvaSBhdCA8YSBocmVmPSJodHRwczovL25hbTA2 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmdtYWls LmNvbSUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3QzVlZDQy ZGUwYjM4ZTQ5N2Q1MDJhMDhkN2Q2ZGI0MDU1JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU3QzYzNzIxNDEwOTQ2OTg1NjczNyZhbXA7c2RhdGE9JTJGQTJmdm9STzA0 NTJJNVAyQ25XUnlvRE9oTzM4d0hEeU9BRjZuNThVRExZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJn ZXQ9Il9ibGFuayI+DQpnbWFpbC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR00MB007307864A3675BE240369BDC3C00CY1PR00MB0073namp_-- From nobody Tue Apr 7 17:33: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 162F13A0FC5 for ; Tue, 7 Apr 2020 17:33:00 -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 h2erfBcG1UAE for ; Tue, 7 Apr 2020 17:32:58 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 682543A0E90 for ; Tue, 7 Apr 2020 17:32:58 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id p123so1433983vkg.1 for ; Tue, 07 Apr 2020 17:32:58 -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=bu6jG+wjOUlAQdPMFsIa/+TLrJ/havRomyBCa7gJLeY=; b=tB9JRuK6RHZdXbqW2rUwmgFsccJGGGy/i3PdmXf1BC3/MHfilt1mzF7AUBPkH88Wac Kuo8k1vinWpy1dvQbQ+4DbmAiB7kMNAHoN4jK360oAw7QwoL75bCIeFI69hwOJwYMuU0 bKUX5C69mMBbDVfk24TPXERqx1leDh/mgCayyVLKwXb7efY2eRnPGfNymhJxko4IrK5E friIbJtN2F+U9AEMktkIhRozZz2No5kRtcd0F8eE3rqHLkxoi0kcd6yltroVgT1gfndM 9Bq/PkOJwVXALkdXrQJqf6T4fnZCcFlXZM9AYr1q6BU/4TUKoG2Xw0hjJ91qfJDdE4Wi tXIg== 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=bu6jG+wjOUlAQdPMFsIa/+TLrJ/havRomyBCa7gJLeY=; b=OdGOebqJ+MuyHALARo0Yg3XavJTzqAUS8y7Q5VX3UNe9xESgfYwcS8qCOaNVO9JzUO +lS8Iah8lAc78478UKkRlO1CENepBrSnLwbaN6oSamWwTf/rUAz/MR/vBwrG1hMUlnsO rZythYUhrJRJMZq0B0EkxPs2tkCUuc+PlHqZc8GAP/hecv4dF7CFtmvN3dzcSDcOQlCn 2ZB97Nme9lAKDs10Ne5jhfdds3Hg/rf9kRX35tF1NKE/76mEbPFVChQh0fpLAPi6jxRr Gcn9rw9M7hwle7GT3EMzPPdb3hkYLAS8O2hGjebXqwnglh7zqCd2qhzDP7M7u37yQj4g mWjg== X-Gm-Message-State: AGi0PubgsuwNdOS1gI497JzT2CImRCWQHByRxX/oz3GvS6NjYFykis2V 9dZlJi436bX6bZn17lkzGeatVeRTTux1ERK7Gu8= X-Google-Smtp-Source: APiQypLkBJ7AdloLgUyS8VhRIailhDxDCa4OiRJmt1+gHshpb8N2/oHg0CMf3YfZQi5b9IpuRFMv/Mg+sOveeonWFiA= X-Received: by 2002:a1f:7dc1:: with SMTP id y184mr3652380vkc.21.1586305977019; Tue, 07 Apr 2020 17:32:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junho Choi Date: Tue, 7 Apr 2020 17:32:19 -0700 Message-ID: To: Yi Huang Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000043efd005a2bca42a" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 00:33:00 -0000 --00000000000043efd005a2bca42a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, thanks for clarifying! On Tue, Apr 7, 2020 at 5:24 PM Yi Huang wrote: > Yeah, it does nothing for the first round. > > > > *From:* Junho Choi > *Sent:* Thursday, April 2, 2020 12:55 AM > *To:* Yi Huang > *Cc:* Praveen Balasubramanian ; tcpm@ietf.org > *Subject:* Re: [EXTERNAL] Questions on HyStart++ draft 02 > > > > Hi Yi, > > > > Thanks. See inline for my following question. > > > > On Wed, Apr 1, 2020 at 5:04 PM Yi Huang wrote: > > 1. Section 4.2 -- each round is initialized as > > > > lastRoundMinRTT =3D currentRoundMinRTT > > currentRoundMinRTT =3D infinity > > rttSampleCount =3D 0 > > > > In the very beginning of the connection, what is "currentRoundMinRTT" whe= n > > there is no previous value? > > > > I am using current rtt (or initial rtt value) and is it ok? > > > > [Yi]: In our implementation, lastRoundMinRTT and currentRoundMinRTT are > initialized to 0xffffffff as sentinel values. We only compare > lastRoundMinRTT with currentRoundMinRTT when both of them are valid value= s. > Using currRTT seems to essentially behave the same as assigning a sentine= l > value. > > > > So in the beginning of the connection lastRoundMinRTT is . When ack > is received currentRoundMinRTT =3D min_rtt but > > lastRoundMinRTT is still . When the 1st round ends, it looks always > doing nothing because the following if() is always false? > > > > if (currentRoundMinRTT >=3D (lastRoundMinRTT + RttThresh)) > > > > > > > > 2. Section 4.2 -- When used with cubic, CA_cwnd() is based on cubic > algorithm I think. > > This means I need to do cubic variables calculation during slow start > > such as K and W_cubic. When is considered as a start of > > congestion avoidance and what W_max will be? > > > > Currently I use a start of limited slow start as a beginning of > congestion recovery > > and use cwnd at the time for W_max. Is my understanding correct? > > > > [Yi]: Yes, that=E2=80=99s exactly what we do in Windows. > > > > Sound great. Thanks. > > > > Best, > > > -- > > Junho Choi > > > --=20 Junho Choi --00000000000043efd005a2bca42a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ok, thanks for clarifying!

On Tue, Apr 7, 2020 at 5:24 = PM Yi Huang <huanyi@microsoft.co= m> wrote:

Yeah, it does nothing for the first round.=

=C2=A0

From: Junho Choi <junho.choi@gmail.com>
Sent: Thursday, April 2, 2020 12:55 AM
To: Yi Huang <huanyi@microsoft.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; tcpm@ietf.org
Subject: Re: [EXTERNAL] Questions on HyStart++ draft 02

=C2=A0

Hi Yi,

=C2=A0

Thanks. See inline for my following question.=

=C2=A0

On Wed, Apr 1, 2020 at 5:04 PM Yi Huang <huanyi@microsoft.com= > wrote:

1. Section 4.2 -- each round is initialized as

=C2=A0

=C2=A0 =C2=A0lastRoundMinRTT =3D currentRoundMinRTT<= u>

=C2=A0 =C2=A0currentRoundMinRTT =3D infinity<= u>

=C2=A0 =C2=A0rttSampleCount =3D 0

=C2=A0

In the very beginning of the connection, what is &qu= ot;currentRoundMinRTT" when

there is no previous value?

=C2=A0

I am using current rtt (or initial rtt value) and is= it ok?

=C2=A0

[Yi]: In our implementation, lastRoundMinRTT and cur= rentRoundMinRTT are initialized to 0xffffffff as sentinel values. We only c= ompare lastRoundMinRTT with currentRoundMinRTT when both of them are valid values. Using currRTT seems to essentially behave t= he same as assigning a sentinel value.

=C2=A0

So in the beginning of the connection lastRoundMinRT= T is <inf>. When ack is received currentRoundMinRTT =3D min_rtt but

lastRoundMinRTT is still <inf>. When the 1st r= ound ends, it looks always doing nothing because the following if() is alwa= ys false?

=C2=A0

=C2=A0 if (currentRoundMinRTT >=3D (lastRoundMinR= TT + RttThresh))

=C2=A0

=C2=A0

=C2=A0

2. Section 4.2 -- When used with cubic, CA_cwnd() is= based on cubic algorithm I think.

=C2=A0This means I need to do cubic variables calcul= ation during slow start

=C2=A0such as K and W_cubic. When is considered as a= start of

=C2=A0congestion avoidance and what W_max will be?

=C2=A0

=C2=A0Currently I use a start of limited slow start = as a beginning of congestion recovery

=C2=A0and use cwnd at the time for W_max. Is my unde= rstanding correct?

=C2=A0

[Yi]: Yes, that=E2=80=99s exactly what we do in Wind= ows.

=C2=A0

Sound great. Thanks.

=C2=A0

Best,


--

Junho Choi <junho dot choi at gmail.com>



--
Junho Choi <junho= dot choi at gmail.com&g= t;
--00000000000043efd005a2bca42a-- From nobody Wed Apr 8 08:08: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 9C7933A0FA9 for ; Tue, 7 Apr 2020 12:19:25 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 plQUDXJzAQ_s for ; Tue, 7 Apr 2020 12:19:23 -0700 (PDT) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 879F13A0FAA for ; Tue, 7 Apr 2020 12:19:23 -0700 (PDT) Received: by mail-vk1-xa32.google.com with SMTP id i5so1171175vkk.8 for ; Tue, 07 Apr 2020 12:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=j3bx/ju/cUwgS7PUJWG59eKOzCbfmmLetEbhHwTYEHc=; b=kO4qe8cLu5UMK+F/bdZlFJO4vj+I6/5U+fyenOciIoxRfNemFZHDXV4udLdQ7kSrQ1 M+A5IC3jGR77KdJH6/7qtJuwAX2JfOvSZqodTlgXa3lyWZFX++Q+GFelDOiJ+nrQi11b T832nJw0ArvW1g+ikjPiav5JndcqgnQdKWteEHN82Rdedyu53jj98COVuzEp+KNANf4S NabGEe3eKwkp/YmqvP8S7XHU8MXrLc8+5XMlqdnYUgsCVKKNv+tUEmJ6npqHqpijrwmT 7OWjebYaKCzKskZyp9Cmgx7+LooT+XiwZ7zSdMxLYfEKxvTrt2/44u8UQQoX7sQ2GIWs BWHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=j3bx/ju/cUwgS7PUJWG59eKOzCbfmmLetEbhHwTYEHc=; b=pNaxnYpcRCJo+Rfv1g2Yv5zAWK2UeOztpes3yvaOPtmzMVFfN+ouqOrEq6ETePmctI CPWRPORyyDjYcCPf4N9TuKI/2w45DRdtNrQib0mMPV63Mjtpe4OvmcIFS8HRx2ujL1ns gGMZRqc0QgNZznhrN+7rhZgIusosRAh4yYTCe4C3ZlmDbJ4Rasr2K8Y4g2ij6BxBWXfg nDrzWo7haBzDeDPTRGNCkZov9nlPIrzkdM1TH5oLUf7ytlZCUDWIL7NYzbrXbFk4fCTW kkfgdYYEJxBVCfFimo0qrObRsmNbyfm0phpFWE80gs8m8K+0EfMGZKbBO4DZaBJAMshE bMfA== X-Gm-Message-State: AGi0PuYc6wUAujt/Mkc3O3ajuySAQjnKif+kyTljQIU4C48o6j3fN+35 0ULIzxHwMAchhok9QL1nOVNVCfli3aiE3FyIvb1wKg== X-Google-Smtp-Source: APiQypK7JFUPlZ6s4dwvk5OPXAFcM8SY8dqa3PnoOMZYIGJl2m1lUvmoI7oKjOsgeF15EaHgG+VAsirpSmNT5AWj8sc= X-Received: by 2002:a1f:6046:: with SMTP id u67mr2799245vkb.68.1586287162090; Tue, 07 Apr 2020 12:19:22 -0700 (PDT) MIME-Version: 1.0 From: Yuchung Cheng Date: Tue, 7 Apr 2020 12:18:45 -0700 Message-ID: To: Martin Duke , Gorry Fairhurst , Praveen Balasubramanian , mirja.kuehlewind=40ericsson.com@dmarc.ietf.org, Ilpo Jarvinen , ietf@tenghardt.net Cc: Neal Cardwell , Priyaranjan Jha , Nandita Dukkipati , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000cf737f05a2b84295" Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2020 08:08:05 -0700 Subject: [tcpm] rack draft WGLC reviews X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 19:19:26 -0000 --000000000000cf737f05a2b84295 Content-Type: text/plain; charset="UTF-8" Hi all, Thank you all for reviewing RACK -- they are great! We've been discussing internally. It may take a few days to review all the comments together to address them consistently. Yuchung on behalf RACK authors --000000000000cf737f05a2b84295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thank you all for reviewing RAC= K -- they are great!=C2=A0 We've been discussing internally. It may tak= e a few days to review all the comments together to address them consistent= ly.=C2=A0

Yuchung on behalf RACK authors

=C2=A0 =C2=A0 =C2=A0
--000000000000cf737f05a2b84295-- From nobody Wed Apr 8 09:10: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 30C623A1016; Wed, 8 Apr 2020 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 FrP3VxcLacC5; Wed, 8 Apr 2020 09:10:14 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 A34253A0FE9; Wed, 8 Apr 2020 09:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sA4rIVDn75niNCulvpwmeRCFFEnSqg0LpD+gNPSKUl8=; b=6I5SJTMyA95+PuJQxZcLbIx6Kv fkjdwzyrjHLouykqS4AJwM2PnEaR2O6JJLWuUCKMTWVT8eJ956d6HcdHoT9QsBVNCkaj2uyGB77NU dn2r2UxIcJZH2aVngOA/Gy0SPSGTuJL8emVIzsmNfl4d6FoHfUop4EEH1hD4CpniQJ1538vuhxDJF J74AVJFC2Wj5SUrCCQusV8Tz3FseYfRnuTs5c7ar9YzBlB/NaC/d1g9pGW/ywuuRP/LQEaAG64xdL BmslUuLieTKQCjGdNthnEDeWbfHI5oBsyy7jOE6Jgf/TFpSXLHLCiYgA/vQ1DqJXo0BSXlqSml8r8 IIPE0llA==; Received: from 94.197.120.166.threembb.co.uk ([94.197.120.166]:13146 helo=[172.20.10.2]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jMDHE-003x07-T5; Wed, 08 Apr 2020 16:10:08 +0000 To: "tcpm-chairs@ietf.org" Cc: tcpm IETF list From: Bob Briscoe Message-ID: <45f69d6c-6ba3-0233-9eea-1c696b022ad5@bobbriscoe.net> Date: Wed, 8 Apr 2020 17:10:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [tcpm] Is a tcpm interim planned? 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, 08 Apr 2020 16:10:22 -0000 tcpm chairs, To replace the cancelled ietf-107 tcpm session, Is a tcpm interim intended? I don't see one (yet) in the upcoming interims on the datatracker. https://datatracker.ietf.org/meeting/upcoming Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Apr 8 11:31:07 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 C04A03A154B; Wed, 8 Apr 2020 11:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_NONE=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 BI6Zf9crNI3M; Wed, 8 Apr 2020 11:31:03 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC8E3A1548; Wed, 8 Apr 2020 11:31:02 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:50ac:915a:99ab:c743] (unknown [IPv6:2a02:8109:1140:c3d:50ac:915a:99ab:c743]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id DB3B3722D2F87; Wed, 8 Apr 2020 20:30:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Tuexen In-Reply-To: <45f69d6c-6ba3-0233-9eea-1c696b022ad5@bobbriscoe.net> Date: Wed, 8 Apr 2020 20:30:57 +0200 Cc: "tcpm-chairs@ietf.org" , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <45f69d6c-6ba3-0233-9eea-1c696b022ad5@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] Is a tcpm interim planned? 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, 08 Apr 2020 18:31:06 -0000 > On 8. Apr 2020, at 18:10, Bob Briscoe wrote: >=20 > tcpm chairs, >=20 > To replace the cancelled ietf-107 tcpm session, Is a tcpm interim = intended? I don't see one (yet) in the upcoming interims on the = datatracker. > https://datatracker.ietf.org/meeting/upcoming We are working on it. Planned for end of April... Best regards Michael >=20 >=20 > Bob >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Apr 9 09:08:45 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 B95243A0B4D for ; Thu, 9 Apr 2020 09:08:44 -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_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 QiOooigaPll3 for ; Thu, 9 Apr 2020 09:08:43 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2111.outbound.protection.outlook.com [40.107.22.111]) (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 AE72D3A0B4C for ; Thu, 9 Apr 2020 09:08:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TXsSaaNxI+ZahkdGlXAa/TbiMJ8HJkRYmrXQCV4OwMPnyNlk9KrvYCXP2yGRZwIshqnjRDbz/0YgXXlUQHiChHSbevfe+NF+YMvlIXdvoPn5IKDIus6av/kD6TWluqF9g6MQXL+sCfDuduw+8NVQpfmFnmwB4ENFpjoKKmBfSTbyQqDlFqw972XevCQpcM+RTs2BSx+DcQSeN7iau5HyHnrp2GHjkzcczBpEVmDk2a70QE/tioKmdvrWD6P1HzKk8PtLYfBr4Be/+jcTvDrVlPZfu2MLCu+TEqxorKsrGXP01RblFvdMVlRRM3wDhONfeIp6z8TRPEfOi3XZQk5HNQ== 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=2y67utaqz07NikMSv840o1TxhQhbUpev+TlZ28s+ihk=; b=TZpl0mIJ65YoJ1x4uLvKHeirliFUxQ4f49Jk5dg+fJ/GkhNHIP9WtghSq10dyhV/imjqR409Q7NqtCY8Lq0a9Q3kalrB+Um2Gr4tlL/FYErJ+C5OeaNbWJeaJFgqtyCk3XLj4DMZAkm5DhDSRjjcD8Vzk2M5hMTyCHFTrlfMwyE8DqA/bF6aR2ou8oEWn/a0E7SxxzIw95YzrTiEtgjFlzwPL/QJWaET1knFMoDRKs2OAyXZrAvu2/9H59wU1M7ht+iSu0Pk8BLRCRaFRCjrdx3CrSwGFWGnzzxVr4WY6VZbsgKejQ/GEKIAl1F2Z+8WpPh+Pu+Ge90ehZ59gYMh/A== 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=2y67utaqz07NikMSv840o1TxhQhbUpev+TlZ28s+ihk=; b=VoxdT3sCsjCIQjvzJdKJc9f2W9QcNs6Pu56XP/MiC6nzIoqRBLqIX5QqO5elVXAzSkoLjmJJsx6H7Fpp5tNsB5jBOw9wZCTQkTFCCGpfzpVttOfIcveEA9M2ZxVLye5vdE4UVdt1KfsuZnw0Ovf7SeDGBRZqyGkX2oh5eScL/c8= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB4635.eurprd07.prod.outlook.com (2603:10a6:5:38::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.14; Thu, 9 Apr 2020 16:08:40 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::502d:bb99:4144:f636]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::502d:bb99:4144:f636%6]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 16:08:40 +0000 From: To: tom petch , "Scharf, Michael" CC: tcpm IETF list Thread-Topic: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 Thread-Index: AdX9YZybm8xvduWhO0ywtFiDNCmPqgFQZ2TYAAS+u+ABizF/AAFpRfqx Date: Thu, 9 Apr 2020 16:08:40 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D9F11D2@rznt8114.rznt.rzdir.fht-esslingen.de> , <6EC6417807D9754DA64F3087E2E2E03E2DA3BAFD@rznt8114.rznt.rzdir.fht-esslingen.de>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfa@btconnect.com; x-originating-ip: [81.131.229.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63bcc872-fe91-438b-4995-08d7dca044df x-ms-traffictypediagnostic: DB7PR07MB4635: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B 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:(10019020)(346002)(396003)(376002)(39860400002)(136003)(366004)(296002)(316002)(7696005)(66574012)(110136005)(4326008)(55016002)(9686003)(186003)(53546011)(6506007)(71200400001)(26005)(2906002)(81156014)(5660300002)(8676002)(64756008)(66446008)(66556008)(66476007)(76116006)(66946007)(86362001)(91956017)(33656002)(81166007)(8936002)(478600001)(52536014)(966005); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZCdxgubp43zCLxhrcWb/fS4VhzPTctd9gEEVVm4Ihmo2ayrOWdQE+Cpze0rutr3lEpXb6XXiuxpUXYltIW2BmQxezkhfVKuPd4WDoya8xyf9QoAYr/hLfJ4iLB9N2YXn482b1znqIzVqdlYoiausGRg+y46wfKtXQySKMhHr5NOJzwEgQST8kY0nl9/SiDHMTXOx/LgQf/i5Qf64dVidlE3gXxzbFpiDKO5bVsACp8tou8MOOov1YraM6O7Va+4vnpcMLhjj4N6GIp7MnyJu4aYHP9sYteA1y2t57dNfUKVoZOJXlBUqStEGzpHwiL0oQ2FgyY9tGIJtErP7/7ff0uLEc3G1N33UoejP2UeCHDm9UR2PVy1VLdIshZOP/ZrVUgXPZK4TIk0wSBxTufy60WUJ83PMj0mqC+jbkALPjq5xwu1LuiZW+MWswQ6zaLeT8IYWgBgmCkc4HL6vbOp1KemKcY+5zfR7PCh2lKJrw/1tlVW0htYHXSpuLWon+GTLao9nYgG68SNrw1vyykQlJA== x-ms-exchange-antispam-messagedata: JCx27KXcRrWtcB3GWsE5/kMKdVlwmaMRhj/Q4CwjxieiHDB6nzfsrQmw0azjs7WN0Uj8avCxdBjL+nuJ749VNt6k0bcc8W+rGoW3EZL3ufThWbMsSEHCLPQ5gaAs5f5t9Y7jB8o728aQf+DkpXQUgw== 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: 63bcc872-fe91-438b-4995-08d7dca044df X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 16:08:40.3367 (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: AnvIkZPrZUriNreA3nDpD11gld9+bS7jAJHj/CVTUclvUqj/SkJV5DHFWfqU+zOXDMXOD4zjvpOH5Kz35BiD9A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4635 Archived-At: Subject: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04 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, 09 Apr 2020 16:08:45 -0000 From: tcpm on behalf of tom petch =0A= Sent: 02 April 2020 12:45=0A= To: Scharf, Michael; idr@ietf.org=0A= =0A= Michael=0A= =0A= A further thought on the netconf chairs advice that the Netconf I-D would = complete first so that the tcpm draft would not be delayed.=0A= =0A= I worked on the syslog yang draft which the IESG approved. It has two Norm= ative references to that cluster of Netconf I-D that I have referred to. I= t has now been waiting for MISSREF for 755 days - seven hundred and fifty f= ive. You seem to think that progress in tcpm is slower than that:-) I ca= nnot see any MISSREF on the tcpm datatracker pages.=0A= =0A= Tom Petch=0A= =0A= Michael,=0A= apologies, this got lost - inline=0A= =0A= From: Scharf, Michael =0A= Sent: 25 March 2020 16:39=0A= =0A= Hi Tom,=0A= =0A= > -----Original Message-----=0A= > From: tom petch =0A= > Sent: Wednesday, March 25, 2020 1:53 PM=0A= >=0A= > From: Idr on behalf of Scharf, Michael=0A= > =0A= > Sent: 18 March 2020 20:12=0A= >=0A= > Hi all,=0A= >=0A= > This is a heads-up regarding the ongoing adoption call for draft-scharf-t= cpm-=0A= > yang-tcp-04 in TCPM.=0A= >=0A= > =0A= > Michael=0A= >=0A= > I note that you have also sent this to Netconf and that you import groupi= ngs=0A= > from the netconf-tcp draft which makes the netconf draft a Normative=0A= > Reference except that this I-D does not mention that fact.=0A= =0A= [I-D.ietf-netconf-tcp-client-server] is listed as first normative reference= in draft-scharf-tcpm-yang-tcp and that dependency is also mentioned in the= abstract. With the current structure of the models, it is not clear to me = why a reference in the reverse direction would be needed.=0A= =0A= =0A= RFC8407 says that YANG import must have a reference which must be a Normati= ve Reference for the I-D.=0A= =0A= So far, the feedback from the NETCONF chairs was that draft-ietf-netconf-tc= p-client-server would most likely finish before a TCPM document. The work i= n the NETCONF WG started much earlier.=0A= =0A= =0A= I note that the chair is also the author:-)=0A= =0A= > I think this is problematic. Progress on the netconf I-D has been slow f= or some=0A= > years and so your I-D could have to wait a while. The solution would be = to=0A= > progress the netconf draft but I do not know how this can be expedited.= =0A= =0A= That is an interesting line of thought. Actually, when I wear the hat of a = co-chair of TCPM, I get told again and again that TCPM is too slow... We cu= rrently try our best to speed up a bit. However, due to the complexity of T= CP, the heterogeneity of implementations, and the scale of deployment of th= e protocol, TCPM needs some time to process documents. This would almost ce= rtainly also apply to a YANG model. In addition, TCPM has not dealt with YA= NG so far, i.e., it is a new topic for the working group.=0A= =0A= Realistically, even if we as authors try our best, the normative reference = to the netconf I-D would only become a problem if that document does not pr= ogress at all for a longer time.=0A= =0A= Would you prefer a TCPM document without that normative reference? In any c= ase, I doubt that timing should be the main motivation for that. Would ther= e be other reasons?=0A= =0A= =0A= I see TCPM as the best of source of information about TCP in the IETF and s= o best qualified to produce an accurate YANG module which other WG then imp= ort. The downside is that TCP has so many facets that the temptation will = be to produce the kitchen sink which is never complete; but with ruthless c= ontrol from Chairs and AD to keep a limit on the scope then I think that th= e TCPM WG is the place for it.=0A= =0A= Tom Petch=0A= =0A= > There are a lot of details in this I-D that I think of as admin which nee= d fixing to=0A= > conform to YANG Guidelines but would not see that as a bar to adoption=0A= > whereas dependency on netconf is more debatable IMHO.=0A= =0A= Indeed, many details require further work. That is well understood.=0A= =0A= Thanks=0A= =0A= Michael=0A= =0A= =0A= > Tom Petch=0A= >=0A= >=0A= > You may want to pay attention. For instance, this document defines groupi= ngs=0A= > for TCP-AO and MD5, which are used by draft-ietf-idr-bgp-model.=0A= >=0A= > If you support work of this document in TCPM, or if you have any comments= ,=0A= > please free to provide feedback on the TCPM list (tcpm@ietf.org).=0A= >=0A= > Thanks=0A= >=0A= > Michael (TCPM chair hat off)=0A= >=0A= >=0A= > Von: Michael Tuexen=0A= > Gesendet: Montag, 16. M=E4rz 2020 21:44=0A= > An: tcpm IETF list=0A= > Cc: draft-scharf-tcpm-yang-tcp@ietf.org tcp@ietf.org>=0A= > Betreff: Request for feedback on WG adoption of draft-scharf-tcpm-yang-tc= p-04=0A= >=0A= > Dear all,=0A= >=0A= > this mail starts a WG adoption call for=0A= > https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04=0A= >=0A= > So I would like to solicit feedback regarding support for or objections a= gainst=0A= > the=0A= > adoption of the document as a WG document in TCPM.=0A= >=0A= > Please provide feedback before March 31st.=0A= >=0A= > For the context and current state of the document, see the presentation s= ent=0A= > yesterday=0A= > to the mailing list by Mahesh.=0A= >=0A= > Best regards=0A= > Michael=0A= >=0A= >=0A= =0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Tue Apr 14 04:05:56 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 8D93C3A0B86; Tue, 14 Apr 2020 04:05:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Meeting Session Request Tool To: Cc: tcpm-chairs@ietf.org, tcpm@ietf.org, tuexen@fh-muenster.de, martin.h.duke@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158686234800.11557.13908205631007422924@ietfa.amsl.com> Date: Tue, 14 Apr 2020 04:05:48 -0700 Archived-At: Subject: [tcpm] tcpm - New Interim Meeting Request 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, 14 Apr 2020 11:05:54 -0000 A new interim meeting request has just been submitted by Michael Tüxen. This request requires approval by the Area Director of the Transport Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-tcpm-01 --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Tüxen Meeting Type: Virtual Meeting Session 1: Date: 2020-04-29 Start Time: 16:00 Europe/Berlin Duration: 02:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=ma838311f033ebe35fefacc0d50658988 Agenda Note: --------------------------------------------------------- From nobody Tue Apr 14 09:06:00 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 415FF3A0A2F; Tue, 14 Apr 2020 09:05:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158688034364.3938.4661029772922806680@ietfa.amsl.com> Date: Tue, 14 Apr 2020 09:05:43 -0700 Archived-At: Subject: [tcpm] TCP Maintenance and Minor Extensions (tcpm) WG Virtual Meeting: 2020-04-29 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, 14 Apr 2020 16:05:45 -0000 The TCP Maintenance and Minor Extensions (tcpm) Working Group will hold a virtual interim meeting on 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=ma838311f033ebe35fefacc0d50658988 From nobody Tue Apr 14 13:27: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 C54163A0EC3; Tue, 14 Apr 2020 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01] 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 6Lb-NrMQ85KF; Tue, 14 Apr 2020 13:27:20 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9D33A0EC1; Tue, 14 Apr 2020 13:27:19 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:edf2:1646:2c98:76da] (unknown [IPv6:2a02:8109:1140:c3d:edf2:1646:2c98:76da]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AC65C75152FDB; Tue, 14 Apr 2020 22:27:16 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_1B1ECC14-6B2A-49E6-9A64-9FA1CADB8625"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Tue, 14 Apr 2020 22:27:15 +0200 Cc: tcpm-chairs@ietf.org To: tcpm IETF list X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [tcpm] Agenda requests for TCPM interim meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 20:27:23 -0000 --Apple-Mail=_1B1ECC14-6B2A-49E6-9A64-9FA1CADB8625 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, TCPM has a 2.5 hour virtual interim meeting, scheduled for 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). If you would like to present during this meeting, please provide by the end of Friday, April 17th: * Title of the presentation * Name of the presenter * Name of the Internet Draft * Time required (including Q/A) Please send us the slides for your presentations by Friday, April 24th, = latest. Best regards Michael --Apple-Mail=_1B1ECC14-6B2A-49E6-9A64-9FA1CADB8625 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MTQyMDI3MTVaMC8GCSqGSIb3DQEJBDEiBCDC+zrqznt3amvtXvcESIzcG+lmVuipBDDyoMWvhab3 /zCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAo0IylFRrYU/XHbco+EsqjS/m7w/0 JaqEsYUWgWN7IWPyN3kYq1/yHvtSmgNuTZibctUnmYPJnO2M0T0ABVtEHmGdqhlatum9Cqih1oPS RTB5t6SyR8FtvFo4nHij74x2U7X4hwIAG3QqZtXK25awBqkC2xJiOOSphwPUuci+Ctf0SrbbfgaI xExoOgKD2sI8VyT4nPblQqg+s9JU2HgB5gq8FjExEFQ9G2wKLxDGMSkamKi7H65QUY53cgb+5SlX pVmhodEx/dwI7BdPpaGMSfaMWZvVy0VjtbgGe7ITmMARQzdmtCuj5SS+XYccGYY17RS52jIFi+Wd BGlPQbBdQAAAAAAAAA== --Apple-Mail=_1B1ECC14-6B2A-49E6-9A64-9FA1CADB8625-- From nobody Thu Apr 16 09:31:49 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 7ACBB3A0DBD for ; Thu, 16 Apr 2020 09:31:47 -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 1uMeeKXavB4T for ; Thu, 16 Apr 2020 09:31:45 -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 026BD3A0DB6 for ; Thu, 16 Apr 2020 09:31:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 07ED025A12; Thu, 16 Apr 2020 18:31:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1587054703; bh=yaNmpEFTnaKATuEcwvrTPNeMff5eE3lbwSx2q5CN/8s=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bzIL8A/JU1ymr3Ny3x9DyoZLe8ubxuQPY+eksBHZ7OC+cpTEOwBvoxvW9MynX8rQS fFsofjRPD6qJMLCKpFIpSvabQuuWU7MRXUesz1h1jZGMoMtekf66g9bw6fqK6sf0j3 Y9dcT+v4TDbSxp2Nq7TH/ujNyp5p+zdtA3o0pE3U= 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 4y4EXJhV681Z; Thu, 16 Apr 2020 18:31:41 +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; Thu, 16 Apr 2020 18:31:41 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 16 Apr 2020 18:31:41 +0200 From: "Scharf, Michael" To: "juhamatk@gmail.com" CC: Joseph Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] Test vectors for RFC5925 algorithms? Thread-Index: AQHWB0lfUk5cDvT0M0+o4ytgvsbwRKhi6ecAgADUtQCAACc4sIABaoiAgBa48iA= Date: Thu, 16 Apr 2020 16:31:41 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Thu, 16 Apr 2020 16:31:48 -0000 SGkgSnVoYW1hdHRpLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGp1 aGFtYXRrQGdtYWlsLmNvbSA8anVoYW1hdGtAZ21haWwuY29tPg0KPiBTZW50OiBUaHVyc2RheSwg QXByaWwgMiwgMjAyMCA5OjI4IEFNDQo+IFRvOiBTY2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2No YXJmQGhzLWVzc2xpbmdlbi5kZT4NCj4gQ2M6IEpvc2VwaCBUb3VjaCA8dG91Y2hAc3RyYXlhbHBo YS5jb20+OyB0Y3BtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gVGVzdCB2ZWN0b3Jz IGZvciBSRkM1OTI1IGFsZ29yaXRobXM/DQo+IA0KPiBIZWxsbyBNaWNoYWVsLA0KPiANCj4gPiBI YXZlIHlvdSBjaGVja2VkIG90aGVyIHJvdXRlciB2ZW5kb3JzPyBGb3IgaW5zdGFuY2UsIHRoZSBw dWJsaWMgQ2lzY28gSU9TIFhFDQo+IGRvY3VtZW50YXRpb24gbGlzdHMgVENQLUFPIHN1cHBvcnQu IEFuZCBJIGhhdmUgYWxzbyBoZWFyZCB0aGF0IGFub3RoZXIgbWFpbg0KPiByb3V0ZXIgdmVuZG9y IG1heSBpbXBsZW1lbnQgVENQLUFPICh3ZWxsLCBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIEp1bmlw ZXIpLg0KPiANCj4gSSBhbSBhd2FyZSB0aGF0IENpc2NvIGhhcyBhbiBpbXBsZW1lbnRhdGlvbi4g SXQgaXMgcXVpdGUgbmV3LCBhbmQNCj4gdW5mb3J0dW5hdGVseSBJIGRvIGhhdmUgZXhwZXJpZW5j ZSBvZiBpdC4gSWYgc29tZW9uZSBoYXMsIHRoZW4gdGhhdA0KPiBtYXkgd2VsbCBiZSBhIHZlcnkg Z29vZCBjYW5kaWRhdGUgZm9yIHRlc3QgdmVjdG9ycy4NCg0KQ29taW5nIGJhY2sgdG8gdGhpcywg YXMgSSBoYXZlIGp1c3QgZm91bmQgYW5vdGhlciBkb2N1bWVudDogQWNjb3JkaW5nIHRvIHJlZmVy ZW5jZSBbMV0sIE5va2lhIFNST1MgaW1wbGVtZW50cyBUQ1AtQU8gYXMgd2VsbC4NCg0KTWljaGFl bA0KDQoNClsxXSBOb2tpYSBTUk9TIGRvY3VtZW50YXRpb24gYXQgaHR0cHM6Ly9kb2N1bWVudGF0 aW9uLm5va2lhLmNvbS9jZ2ktYmluL2RiYWNjZXNzZmlsZW5hbWUuY2dpLzNIRTE1ODExQUFBQVRR WlpBMDFfVjFfNzQ1MCUyMEVTUyUyMDc3NTAlMjBTUiUyMDc5NTAlMjBYUlMlMjBhbmQlMjBWU1Il MjBCYXNpYyUyMFN5c3RlbSUyMENvbmZpZ3VyYXRpb24lMjBHdWlkZSUyMDIwLjIuUjEucGRmDQoN Cg0KDQo+IA0KPiA+IEJUVywgaWYgdGhlcmUgaXMgc29tZSBnYXAgaW4gdGhlIFJGQyBzZXJpZXMs IHRoZSB1c3VhbCBJRVRGIHByb2Nlc3MgaXMganVzdA0KPiBzdGFydGluZyBhIG5ldyBJbnRlcm5l dC1EcmFmdCwgaW5zdGVhZCBvZiB3YWl0aW5nIGZvciBzb21lYm9keSBlbHNlIHRvIHdyaXRlDQo+ IHNvbWV0aGluZy4gSXQgaXMgbm90IGNvbXBsZXggdG8gd3JpdGUgYW4gSW50ZXJuZXQgRHJhZnQu IEFuZCBUQ1BNIGlzIHVzdWFsbHkNCj4gcXVpdGUgb3BlbiB0byBuZXcgd29yay4NCj4gDQo+IEkg YW0gbm90IHRoYXQgZmFtaWxpYXIgd2l0aCB0aGUgZHJhZnQgcHJvY2Vzcy4gSSBhZ3JlZSB0aGF0 IGlmIHRlc3QNCj4gdmVjdG9ycyBkbyBub3QgYWxyZWFkeSBleGlzdCwgdGhhdCBtYXkgYmUgdGhl IGJlc3QgcGF0aCB0byBnbyBmb3J3YXJkLg0KPiBIZXJlIGJlbG93IGlzIGEgZHJhZnQgb3V0bGlu ZSB0aGF0IHBlcmhhcHMgcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uDQo+IG5lZWRlZCB0byBlbnN1 cmUgY29tcGF0aWJsZSBpbXBsZW1lbnRhdGlvbnMuIElmIHRoZXJlIGlzIHNvbWUNCj4gY29uc2Vu c3VzIHRoYXQgcHJvY2VlZGluZyB3aXRoIHRoaXMgd291bGQgYmUgdXNlZnVsLCBwZXJoYXBzIHdl IGNhbg0KPiB1c2UgaXQgYXMgYSBzdGFydGluZyBwb2ludC4gV2UgbmVlZCB0byBmaWxsIHRoZSB2 ZXJpZmllZCB0ZXN0IHZlY3RvcnMNCj4gdGhlcmUgZXZlbnR1YWxseS4NCj4gDQo+IFRlc3QgVmVj dG9ycyBmb3IgQ3J5cHRvZ3JhcGhpYyBBbGdvcml0aG1zIG9mIHRoZSBUQ1AgQXV0aGVudGljYXRp b24NCj4gT3B0aW9uIChUQ1AtQU8pDQo+IC0NCj4gSW50cm9kdWN0aW9uDQo+IEtleSBEZXJpdmF0 aW9uIEZ1bmN0aW9ucyBUZXN0IFZlY3RvcnMNCj4gICogS0RGX0hNQUNfU0hBMQ0KPiAgICAtIEEg dGVzdCBUQ1AvSVAgZnJhbWU6IHN5biBzbmQga2V5IG91dHB1dA0KPiAgICAtIEEgdGVzdCBUQ1Av SVAgZnJhbWU6IHN5biByY3Yga2V5IG91dHB1dA0KPiAgICAtIEEgdGVzdCBUQ1AvSVAgZnJhbWU6 IG90aGVyIHNuZCBrZXkgb3V0cHV0DQo+ICAgIC0gQSB0ZXN0IFRDUC9JUCBmcmFtZTogb3RoZXIg cmN2IGtleSBvdXRwdXQNCj4gICogS0RGX0FFU18xMjhfQ01BQw0KPiAgICAtIEEgdGVzdCBUQ1Av SVAgZnJhbWU6IHN5biBzbmQga2V5IG91dHB1dA0KPiAgICAtIEEgdGVzdCBUQ1AvSVAgZnJhbWU6 IHN5biByY3Yga2V5IG91dHB1dA0KPiAgICAtIEEgdGVzdCBUQ1AvSVAgZnJhbWU6IG90aGVyIHNu ZCBrZXkgb3V0cHV0DQo+ICAgIC0gQSB0ZXN0IFRDUC9JUCBmcmFtZTogb3RoZXIgcmN2IGtleSBv dXRwdXQNCj4gTUFDIEFsZ29yaXRobXMgVGVzdCBWZWN0b3JzDQo+ICAqIEhNQUMtU0hBLTEtOTYN Cj4gICAgLSBBIHRlc3Qga2V5IHdpdGggdGVzdCBUQ1AvSVAgZnJhbWU6IE1BQyBvdXRwdXQsIE1B QyBvdXRwdXQgd2l0aG91dCBvcHRpb25zDQo+ICAqIEFFUy0xMjgtQ01BQy05Ng0KPiAgICAtIEEg dGVzdCBrZXkgd2l0aCB0ZXN0IFRDUC9JUCBmcmFtZTogTUFDIG91dHB1dCwgTUFDIG91dHB1dCB3 aXRob3V0IG9wdGlvbnMNCj4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gQWNrbm93bGVkZ2Vt ZW50cw0KPiBSZWZlcmVuY2VzDQo+IA0KPiA+IE1pY2hhZWwNCj4gDQo+IFRoYW5rcywNCj4gLS0N Cj4gIEp1aGFtYXR0aQ0KPiANCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBqdWhhbWF0 a0BnbWFpbC5jb20NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMSwgMjAyMCA5OjMwIEFN DQo+ID4gPiBUbzogSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4NCj4gPiA+IENj OiB0Y3BtQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RjcG1dIFRlc3QgdmVjdG9ycyBm b3IgUkZDNTkyNSBhbGdvcml0aG1zPw0KPiA+ID4NCj4gPiA+IEhlbGxvIEpvZSwNCj4gPiA+DQo+ ID4gPiA+IEF0IGJlc3QsIHRob3NlIG1pZ2h0IGJlIGFuIGFkZGVuZHVtIHRvIFJGQyA1OTI2LiBS RkMgNTkyNSBkZWxpYmVyYXRlbHkNCj4gPiA+IGRvZXMgbm90IHNwZWNpZnkgYW55IGFsZ29yaXRo bXMuDQo+ID4gPg0KPiA+ID4gVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBBZGRlbmR1bSB0byBSRkMg NTkyNiBzb3VuZHMgcmVhbGx5IGdvb2QgdG8gbWUuDQo+ID4gPg0KPiA+ID4gPiBIb3dldmVyLCBU Q1AgTUQ1IHdhcyB3aWRlbHkgZGVwbG95ZWQgd2l0aG91dCBhbnkgc3VjaCB0ZXN0IHZlY3RvcnMg aW4NCj4gdGhlDQo+ID4gPiBSRkMgc2VyaWVzIChvciBlbHNld2hlcmUgSSBjb3VsZCBmaW5kLCBG V0lXKS4NCj4gPiA+DQo+ID4gPiBUcnVlLiBTdGlsbCwgUkZDIDIzODUgaXMgb25seSA0IHBhZ2Vz IGxvbmcgYW5kIGltcGxlbWVudGF0aW9uIGlzIHZlcnkNCj4gPiA+IHNpbXBsZS4gSXQgaGFkIHdp ZGUgZGVwbG95bWVudCBmcm9tIHRoZSBiZWdpbm5pbmcsIEkgYmVsaWV2ZSwgc28gaXQNCj4gPiA+ IHdhcyBlYXN5IHRvIG1ha2UgaW1wbGVtZW50YXRpb25zIG1hdGNoLg0KPiA+ID4NCj4gPiA+IEkg YW0gY3VycmVudGx5IHdvcmtpbmcgb24gYSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbiBvZiBS RkMNCj4gPiA+IDU5MjUvNTkyNi4gRXZlbiB0aG91Z2ggdGhlIFJGQ3MgYXJlIHRlbiB5ZWFycyBv bGQsIHRoZXkgaGF2ZSBvbmx5IGENCj4gPiA+IGZldyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMu IFRlc3QgZXF1aXBtZW50IHZlbmRvcnMgKElYSUEsIFNwaXJlbnQpDQo+ID4gPiBkbyBub3Qgc3Vw cG9ydCBpdC4gSnVuaXBlciBkb2VzIG5vdCB1c2UgaXQsIHRoZXkgc2VlbSB0byB1c2UgdGhlaXIg b3duDQo+ID4gPiBwcm9wcmlldGFyeSB2ZXJzaW9uLiBPbmUgZnV6emluZyB2ZW5kb3Igc2VlbXMg dG8gaGF2ZSBITUFDLVNIQTENCj4gPiA+IGltcGxlbWVudGVkLCBidXQgaXQgaXMgdW5jbGVhciBp cyBpdCBhY2NvcmRpbmcgdG8gdGhlIFJGQ3MuDQo+ID4gPiBHdWFyYW50ZWVpbmcgaW50ZXJvcCBs b29rcyBxdWl0ZSBkaWZmaWN1bHQgYXQgdGhlIG1vbWVudC4NCj4gPiA+DQo+ID4gPiBTbyBpZiB0 ZXN0IHZlY3RvcnMgYWxyZWFkeSBleGlzdCBzb21ld2hlcmUgKG1heWJlIHVucHVibGlzaGVkKSwg b3INCj4gPiA+IHNvbWVvbmUgaXMgd2lsbGluZyB0byBjcmVhdGUgdGhlbSBmb3IgdGhlIGFkZGVu ZHVtIGRyYWZ0IHJlZmVyZW5jZWQNCj4gPiA+IGFib3ZlLCBJIGFtIGNlcnRhaW5seSB3aWxsaW5n IHRvIHZlcmlmeSB0aGVtIGFnYWluc3QgbXkgaW1wbGVtZW50YXRpb24NCj4gPiA+IGFuZCByZXBv cnQgYmFjay4NCj4gPiA+DQo+ID4gPiA+IEpvZQ0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+ IC0tDQo+ID4gPiAgSnVoYW1hdHRpDQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IE9uIE1hciAz MSwgMjAyMCwgYXQgMzo0NCBBTSwganVoYW1hdGtAZ21haWwuY29tIHdyb3RlOg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gSGVsbG8sDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGhhdmUgYmVlbiBzZWFy Y2hpbmcgZm9yIHRlc3QgdmVjdG9ycyBmb3IgUkZDNTkyNS81OTI2IGFsZ29yaXRobXMgZm9yDQo+ ID4gPiA+ID4gVENQIEFPIGFuZCB0byBteSBzdXJwcmlzZSBpdCBzZWVtcyB0aGF0IHN1Y2ggZG8g bm90IGV4aXN0LiBBbSBJDQo+ID4gPiA+ID4gY29ycmVjdCBoZXJlPw0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gRXZlbiB0aG91Z2ggdGVzdCB2ZWN0b3JzIGZvciBITUFDIFNIQTEgKFJGQzIyMDIpIGFu ZCBBRVMgQ01BQw0KPiA+ID4gPiA+IChSRkM0NDkzKSBhcmUgYXZhaWxhYmxlLCBpdCB3b3VsZCBi ZSB1c2VmdWwgdG8gaGF2ZSBleGFtcGxlIHRlc3QNCj4gPiA+ID4gPiB2ZWN0b3JzIGZvciBmcmFt ZXMgdXNpbmcgVENQIEFPIC0gb3RoZXJ3aXNlIGltcGxlbWVudGF0aW9ucyBlbmQgdXANCj4gPiA+ ID4gPiBlYXNpbHkgbm90IHRvIG1hdGNoLiBBcyBSRkM1OTI1IGlzIDQ3IHBhZ2VzLCB0aGVyZSBp cyBhIHJvb20gZm9yIGVycm9yDQo+ID4gPiA+ID4gYW5kIG9ubHkgb25lIG1pc21hdGNoIGlzIG5l ZWRlZCBmb3IgTUFDcyBub3QgdG8gbWF0Y2guDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIHRoaW5r IHB1Ymxpc2hpbmcgYSBuZXcgUkZDIGZvciB0aGVtIHdvdWxkIGJlIGdvb2QsIGJ1dCBwcm9iYWJs eQ0KPiA+ID4gPiA+IHRha2VzIHNvbWUgdGltZS4gRXZlbiB1bm9mZmljaWFsLCBidXQgdmVyaWZp ZWQsIHRlc3QgdmVjdG9ycyBvbiBzb21lDQo+ID4gPiA+ID4gc3BlY2lmaWVkIGV4YW1wbGUgZnJh bWVzICh3aXRoIGFuZCB3aXRob3V0IFRDUCBvcHRpb25zKSwgZS5nLiBvbiB0aGlzDQo+ID4gPiA+ ID4gbWFpbGluZyBsaXN0IG9yIG90aGVyd2lzZSwgd291bGQgYmUgYSB2ZXJ5IGdvb2Qgc3RhcnQg dG8gZ2V0IFRDUCBBTw0KPiA+ID4gPiA+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkLiBJZiBzdWNo IGFscmVhZHkgYXJlIGF2YWlsYWJsZSBzb21ld2hlcmUsDQo+ID4gPiA+ID4gcGxlYXNlIGRvIGxl dCBtZSBrbm93Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiA+IC0tDQo+ ID4gPiA+ID4gSnVoYW1hdHRpDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IHRjcG0gbWFpbGluZyBs aXN0DQo+ID4gPiA+ID4gdGNwbUBpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiB0Y3BtIG1haWxp bmcgbGlzdA0KPiA+ID4gdGNwbUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90Y3BtDQo= From nobody Thu Apr 16 09:45: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 7279F3A0E83; Thu, 16 Apr 2020 09:44:49 -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 TyPRjt4OCEJ8; Thu, 16 Apr 2020 09:44:47 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0: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 CBFD83A0E9D; Thu, 16 Apr 2020 09:44:47 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id i3so1909525pgk.1; Thu, 16 Apr 2020 09:44:47 -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=fICeRqrbf+z91QG/6UotyH5Dybay361WfHajb49I3Sg=; b=SR7yGbzLrAYhDCfBVa10d7qdDjcD/UlFMjr0L2Xew8hCpRrzEGU3qpE0iFUfZSoo/0 dEkFwz1ezUaRegDFIOf6/z7H25RVaKkXM3PCmCJd7SRLoxdrbbgj4GcJ3fOdLNjAZkqT Qe+bQaKqzLGyEF2MPSl84s5FsAigeACjPklE20lSEZtjXWxZlc0a3FUIlFnAa3P11ENy op30gc/XdWGlNePYxmiyXH+WFbbh7mwKT49IVDjNMlX9/n59yWLF0QeMW4oJMYRMR0+/ FCsiOmatYu4YYEbrqP0Xlfk2jkbpjtfmqrCHCzN+vl1jqb0dpV7gGHYLGj8ftJ6WDmZX TxnA== 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=fICeRqrbf+z91QG/6UotyH5Dybay361WfHajb49I3Sg=; b=mAGhqmgX6BmjWbdPZ1eQdCuPrGYtm5x29K6l7ZrnuLFhrmEMA03KYulQJVJo33fXRh tjwu0DPAG/RMZO5TUvEK5Ehh3U5QtpGb3HJuuIDQV2iS5cu+qi91BuwYYvnfRNDAXFb9 JNYGQ5VKmrzBfyyjwKtqxYF4eh/qWZ7sMo/YgljK6rJWq9mj58AhtRM7HGOEHBOdZbar Y80IeJZNX4WFu5tEzB7maoDSG7zMIKhfrOh+kruErFCsAfQtJ0vHkm55jJS5XJccMFSt QYFEPHeZi/JlEdmICRjpG3HCnqi/1Z8HvhNVPsPiqOikXjKz9lsHZAiBiYAXmY/WyGI4 wYyg== X-Gm-Message-State: AGi0PuailTxJweIRufwkAULjiFucD7DRkF/oyDDtyg7cq0bAqA7XVPIf NGSHTEG3uNa3oZJEdZqaFhQ= X-Google-Smtp-Source: APiQypLeFC/g7u1+pRCa7tUwPeJhlKjVD906XiiZYaNWvZsddzXDiaMQDeRpeK3jIDwFgD272ZMfyA== X-Received: by 2002:a62:3146:: with SMTP id x67mr33815528pfx.72.1587055487142; Thu, 16 Apr 2020 09:44:47 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:c5e4:5da5:e674:e66b? ([2601:647:5600:5020:c5e4:5da5:e674:e66b]) by smtp.gmail.com with ESMTPSA id 18sm17417282pfv.118.2020.04.16.09.44.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 09:44:46 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <1C8D19D3-4800-4F8C-83A4-7EC150407266@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_43ACC12F-EACB-413C-85B4-66784FA753B7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Thu, 16 Apr 2020 09:44:45 -0700 In-Reply-To: Cc: tcpm IETF list , tcpm-chairs@ietf.org To: Michael Tuexen References: X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 16 Apr 2020 16:44:56 -0000 --Apple-Mail=_43ACC12F-EACB-413C-85B4-66784FA753B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, Here is a agenda request. Thanks. * Title of the presentation: YANG Model for TCP Configuration * Name of the presenter: Mahesh Jethanandani * Name of the Internet Draft: draft-scarf-tcpm-yang-tcp * Time required (including Q/A): 15 min > On Apr 14, 2020, at 1:27 PM, Michael Tuexen = wrote: >=20 > Dear all, >=20 > TCPM has a 2.5 hour virtual interim meeting, scheduled for > 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). >=20 > If you would like to present during this meeting, please provide by = the > end of Friday, April 17th: >=20 > * Title of the presentation > * Name of the presenter > * Name of the Internet Draft > * Time required (including Q/A) >=20 > Please send us the slides for your presentations by Friday, April = 24th, latest. >=20 > Best regards > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_43ACC12F-EACB-413C-85B4-66784FA753B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Michael,

Here is a = agenda request. Thanks.

* Title of the presentation: YANG Model = for TCP Configuration
* Name of the presenter: Mahesh = Jethanandani
* Name of the Internet Draft: = draft-scarf-tcpm-yang-tcp
* Time required (including Q/A): = 15 min

On Apr 14, 2020, at 1:27 PM, Michael Tuexen = <tuexen@fh-muenster.de> wrote:

Dear = all,

TCPM has a 2.5 hour virtual interim = meeting, scheduled for
2020-04-29 from 16:00 to 18:30 = Europe/Berlin (14:00 to 16:30 UTC).

If you = would like to present during this meeting, please provide by the
end of Friday, April 17th:

* = Title of the presentation
* Name of the presenter
* Name of the Internet Draft
* Time required = (including Q/A)

Please send us the slides = for your presentations by Friday, April 24th, latest.

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



Mahesh Jethanandani



= --Apple-Mail=_43ACC12F-EACB-413C-85B4-66784FA753B7-- From nobody Thu Apr 16 10:19: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 617F33A0791; Thu, 16 Apr 2020 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_NONE=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 JLWVKrbO97MD; Thu, 16 Apr 2020 10:18:58 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F22E3A077C; Thu, 16 Apr 2020 10:18:57 -0700 (PDT) Received: from mb.fritz.box (unknown [IPv6:2a02:8109:1140:c3d:62:f411:d2b2:8008]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 293F875D6CB78; Thu, 16 Apr 2020 19:18:54 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_374C5EAA-FBD3-48D9-A227-EBFEF24016F0"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 16 Apr 2020 19:18:53 +0200 In-Reply-To: <1C8D19D3-4800-4F8C-83A4-7EC150407266@gmail.com> Cc: tcpm IETF list , tcpm-chairs@ietf.org To: Mahesh Jethanandani References: <1C8D19D3-4800-4F8C-83A4-7EC150407266@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 16 Apr 2020 17:19:01 -0000 --Apple-Mail=_374C5EAA-FBD3-48D9-A227-EBFEF24016F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16. Apr 2020, at 18:44, Mahesh Jethanandani = wrote: >=20 > Hi Michael, >=20 > Here is a agenda request. Thanks. >=20 > * Title of the presentation: YANG Model for TCP Configuration > * Name of the presenter: Mahesh Jethanandani > * Name of the Internet Draft: draft-scarf-tcpm-yang-tcp > * Time required (including Q/A): 15 min Hi Mahesh, thanks for sending the request. Best regards Michael >=20 >> On Apr 14, 2020, at 1:27 PM, Michael Tuexen = wrote: >>=20 >> Dear all, >>=20 >> TCPM has a 2.5 hour virtual interim meeting, scheduled for >> 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). >>=20 >> If you would like to present during this meeting, please provide by = the >> end of Friday, April 17th: >>=20 >> * Title of the presentation >> * Name of the presenter >> * Name of the Internet Draft >> * Time required (including Q/A) >>=20 >> Please send us the slides for your presentations by Friday, April = 24th, latest. >>=20 >> Best regards >> Michael >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 --Apple-Mail=_374C5EAA-FBD3-48D9-A227-EBFEF24016F0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MTYxNzE4NTNaMC8GCSqGSIb3DQEJBDEiBCDUXZC5TC3rf0+ek5BdaVvA1FVplLY5ksZhqcMiRZX1 nDCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAIneaKchB5HVFGju+tDE2cAs7K+HE 4LNFPpX2YSs9q1PTTlac1ExmmMpIX2RElCSthr5WhLuANqRvKvZdnv21Fmbb27GZrbAqrdlMU2cO gDUTnLhSS7+OPseYa5qlRAhzhrVfdhtufQokgmj4/jp67It9PPheRHk3oS6HFPE2zjTwEzuQerge JrrMFHI1wtnM21CfT6JpI4PXzao0ljSOBMNIMiCIQCDEZIs6J8aXz8ZildqSydCoZMC2FlQiCMk9 i0cMDcBIJhCjHegc4yZl3RphPLK9hZ3HSzfkwMS7RxI5zwXE5YowSQTG4DQTWc6sVdNefCTctA66 KiJtnI5IywAAAAAAAA== --Apple-Mail=_374C5EAA-FBD3-48D9-A227-EBFEF24016F0-- From nobody Thu Apr 16 23:20:49 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 6BCF73A0D83 for ; Thu, 16 Apr 2020 23:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 QB6ThEptz-rX for ; Thu, 16 Apr 2020 23:20:47 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 BE00C3A0D80 for ; Thu, 16 Apr 2020 23:20:46 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id u127so594924wmg.1 for ; Thu, 16 Apr 2020 23:20:46 -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=uM5hUQvHcCUuBT3AcL9OKkSa8/05tLYg+u1eJc10YIY=; b=lq8CM3uDW+6T+R0LiamlW//YAqhxxffqj+PaF2UfTBrWNnFigP9oaeLHpr+BtQaMxe LeziFQKnQo9AlcTOklnRMq8CbZAzCNZ2Y/MivFZOfRFPmcK7HJtfOx9+72xMebphUv9n sq572dHctgtiXDPsEuPsTPDIki9E0dvUzfFFMZUfAG+mj7fRm+mwlrJTknnB9oyqklHe aKBifJDBq2JUNje6FNvWuANBh9rL0GVtVd505xeqxPP7PVuwSBPyZ5RrM8j/7Hr5TxXq LY0yzgrmzLEQNnUQpDzmOGugSg79KbrNdouQtG2lN2yN7Fb7+8iOqm+QpUXvfKmmCAO2 8opw== 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=uM5hUQvHcCUuBT3AcL9OKkSa8/05tLYg+u1eJc10YIY=; b=EdNhR++LrYB0MtVjOdVeO4fNJMXzLTEz0nFY1kOBAcFzSUsV8zNmLUjBMEqKiqBioa xFLyPwos/w9Qz166lPmixLfYJkVp45Vd3wFbel9ejVvQ1zgAOC1vfI1C90Ml2G/wol3b EEe9XqrACWTz3s7VEDppP0C7WEA10w5UDpsGI8x9rche+nHjepdOGp4q/qEPeedR8drn WDdsq+1rJf5A5BqkV88VfEPzXUWStCE0YMwkzCE/+HKqpkxt1gKZ3WF4xY/Rj8jjvwpD 0TGKCtw+k0Nm6PxW5y9HAu+Qx7L0fCgo0MO/M+x9YhDHWBq/OxsdNbdSNjRoK8ElFmFX NpHw== X-Gm-Message-State: AGi0PubTO9GyKuMqx1x5FzABo6HOzboz8M1SH3Hy+qzwhDYFK3xfH74s mim/iwiAFGhu8zwjr54F9UTnCS/YhHTmkPtYmfiA+BNjROA= X-Google-Smtp-Source: APiQypKEdflUjJSOklKMgHfJZ6SMZl2mEX+mg4AmJ0woZukSl5rUGMaB4jRu+UHu7aQ23uXXrGWWKxS+KQDuA11r36k= X-Received: by 2002:a1c:6741:: with SMTP id b62mr838396wmc.22.1587104439929; Thu, 16 Apr 2020 23:20:39 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2DA4B5C7@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DA73D5B@rznt8114.rznt.rzdir.fht-esslingen.de> From: juhamatk@gmail.com Date: Fri, 17 Apr 2020 09:20:22 +0300 Message-ID: To: "Scharf, Michael" Cc: Joseph Touch , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" 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: Fri, 17 Apr 2020 06:20:49 -0000 Hello Michael, On Thu, 16 Apr 2020 at 19:31, Scharf, Michael 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. Thanks! RFC 5925 and RFC 5926 are indeed listed as supported. Not many configuration examples, though. As with Cisco, I do not personally have experience of Nokia products. As Nokia SROS seems to have support at some level, it may well be another candidate for test vectors. > Michael > > > [1] Nokia SROS documentation at https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE15811AAAATQZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Basic%20System%20Configuration%20Guide%2020.2.R1.pdf -- Juhamatti From nobody Fri Apr 17 12:01:57 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 19A443A0E50; Fri, 17 Apr 2020 12:01:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_FAIL=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=bobbriscoe.net 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 bZxIvinT8Xv7; Fri, 17 Apr 2020 12:01:45 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 96CDE3A0ADE; Fri, 17 Apr 2020 12:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To: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=do0q7UmZu055Rm8Dl3IqeoNM39NRSP71+Vsn5kKBrS4=; b=7ddl0AZ9S0g1VbipijWylJYb4 5HhUjpgWMmifbBDc2wJ6QwVjxQwE2lYtbDz+9oKClWjzJB+CA8QpU5EdOAxZUdbVRC7diRoRbsVVK ZxfevTaO0lxIPpiahXzIphOJEV75B7QN21zlOtE53zjqe3aiT4jTHUXekwF9NTPVX5AMi7VeXN6Q2 kZD5x999atCKZm5Z2LZcOVEL8JNZgze9UmAwTwIUi1UdZAIfTruG3bjSbjh4uUq/r7Xv0P6a0oGjb Jnct9EICuIlDaIa05P7duCjZUKZDwAvs9CANKuUEuxXHCa39IgwTzMVwEr2wWLBh71jYTGdanRbzg /yHqaV0Bg==; Received: from [31.185.128.106] (port=55168 helo=[192.168.0.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jPWEi-00HVsX-8M; Fri, 17 Apr 2020 20:01:12 +0100 To: Michael Tuexen , tcpm IETF list , =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= Cc: tcpm-chairs@ietf.org, Mirja Kuehlewind , Richard Scheffenegger References: From: Bob Briscoe Message-ID: Date: Fri, 17 Apr 2020 20:01:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BC6BBF74CC82F49F871BC0EB" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 17 Apr 2020 19:01:54 -0000 This is a multi-part message in MIME format. --------------BC6BBF74CC82F49F871BC0EB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Michael, * Accurate ECN TCP Feedback: Changes & Status * Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't discussed between us yet!) * draft-ietf-tcpm-accurate-ecn-11 * 15-20mins. Are you carrying over requests from the Cancelled Vancouver mtg as well? Cos I think Ilpo was going to give a talk on his AccECN implementation that I'd like to hear. Might be best to have the one below first, to give context for Ilpo's talk. Cheers Bob On 14/04/2020 21:27, Michael Tuexen wrote: > Dear all, > > TCPM has a 2.5 hour virtual interim meeting, scheduled for > 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). > > If you would like to present during this meeting, please provide by the > end of Friday, April 17th: > > * Title of the presentation > * Name of the presenter > * Name of the Internet Draft > * Time required (including Q/A) > Please send us the slides for your presentations by Friday, April 24th, latest. > > Best regards > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------BC6BBF74CC82F49F871BC0EB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Michael,

* Accurate ECN TCP Feedback: Changes & Status
* Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't discussed between us yet!)
* draft-ietf-tcpm-accurate-ecn-11
* 15-20mins.

Are you carrying over requests from the Cancelled Vancouver mtg as well?
Cos I think Ilpo was going to give a talk on his AccECN implementation that I'd like to hear.
Might be best to have the one below first, to give context for Ilpo's talk.


Cheers



Bob


On 14/04/2020 21:27, Michael Tuexen wrote:
Dear all,

TCPM has a 2.5 hour virtual interim meeting, scheduled for
2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC).

If you would like to present during this meeting, please provide by the
end of Friday, April 17th:

* Title of the presentation
* Name of the presenter
* Name of the Internet Draft
* Time required (including Q/A)
Please send us the slides for your presentations by Friday, April 24th, latest.

Best regards
Michael


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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------BC6BBF74CC82F49F871BC0EB-- From nobody Fri Apr 17 12:50:41 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 DAC763A087B; Fri, 17 Apr 2020 12:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_NONE=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 2uQs1KiQlpV8; Fri, 17 Apr 2020 12:50:37 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4F43A1304; Fri, 17 Apr 2020 12:50:36 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:130:c88f:d2f2:47df] (unknown [IPv6:2a02:8109:1140:c3d:130:c88f:d2f2:47df]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 4D4F773AA246B; Fri, 17 Apr 2020 21:50:33 +0200 (CEST) From: Michael Tuexen Message-Id: <1ACE7676-8A2C-4A64-AF20-39A1C07A77ED@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_1525791A-AD53-4E31-9E9C-A6C9CD7EBEC6"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 17 Apr 2020 21:50:32 +0200 In-Reply-To: Cc: tcpm IETF list , =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , tcpm-chairs@ietf.org, Mirja Kuehlewind , Richard Scheffenegger To: Bob Briscoe References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 17 Apr 2020 19:50:40 -0000 --Apple-Mail=_1525791A-AD53-4E31-9E9C-A6C9CD7EBEC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17. Apr 2020, at 21:01, Bob Briscoe wrote: >=20 > Michael, >=20 > * Accurate ECN TCP Feedback: Changes & Status > * Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't = discussed between us yet!) > * draft-ietf-tcpm-accurate-ecn-11 > * 15-20mins. >=20 > Are you carrying over requests from the Cancelled Vancouver mtg as = well? No, since things might have changed in between. > Cos I think Ilpo was going to give a talk on his AccECN implementation = that I'd like to hear. Ilpo, In case you want to give that presentation, please send a = request... > Might be best to have the one below first, to give context for Ilpo's = talk. You mean the one above, right? First you presentation, then Ilpo's, if = he want to give it. Best regards Michael >=20 >=20 > Cheers >=20 >=20 >=20 > Bob >=20 >=20 > On 14/04/2020 21:27, Michael Tuexen wrote: >> Dear all, >>=20 >> TCPM has a 2.5 hour virtual interim meeting, scheduled for >> 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). >>=20 >> If you would like to present during this meeting, please provide by = the >> end of Friday, April 17th: >>=20 >> * Title of the presentation >> * Name of the presenter >> * Name of the Internet Draft >> * Time required (including Q/A) >> Please send us the slides for your presentations by Friday, April = 24th, latest. >>=20 >> Best regards >> Michael >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >>=20 >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > --=20 > ________________________________________________________________ > Bob Briscoe =20 > http://bobbriscoe.net/ --Apple-Mail=_1525791A-AD53-4E31-9E9C-A6C9CD7EBEC6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MTcxOTUwMzJaMC8GCSqGSIb3DQEJBDEiBCCn2ic7fr+ylo4jfq4LU3xFFc0yYviVhD8AJLPJvmg2 ozCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAkj4e66GJTZDlYCOB6jyGt4Ir0Tf0 ofE1iJoA3zrLTi5X+gsq7nS/UufG7Xdr893q4/nq6KxVgGxcXVL80Vrgc3jFCYyd5HrfTCp2mNaV u9qcKjJ3DZxCtB91genb4X8dhkvux24WfX29TrO9BqhgdwB8m7pFCixCPRk+7r4n+BnXVzMBC4K0 YBVmWKPNS21AAQoy5xE9eVMdp+xsMrWyZKzmjGnZC8nmQIVlbVo1SjaPhHC6247wfm7wXnYsxGt/ kmbA9shw0oEZRvyIXZ3TgR8BtSJJa2FmMQ+3tOZZ+iLTc2gUHPt6gnP5rRuftonRXkZbhFXEcMJH bFLzOFUxQwAAAAAAAA== --Apple-Mail=_1525791A-AD53-4E31-9E9C-A6C9CD7EBEC6-- From nobody Fri Apr 17 16:26: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 E91E23A09C4 for ; Fri, 17 Apr 2020 16:26:28 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 iekSgTx1eqop for ; Fri, 17 Apr 2020 16:26:16 -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 D44833A09C0 for ; Fri, 17 Apr 2020 16:25:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id F103625A16; Sat, 18 Apr 2020 01:25:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1587165948; bh=Np9q283y9xCRCONOY4YPRoL5m8z8WQLfzaBOxOtYfUE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=UQXWOer7PUx4BgqEH0V0d8VZzpUN8HXkXnox793B1L9X6fqS2uKZ8MWZigqhD0OHU W1exo2isZzgFjVIRW7L+OuzQNwEJftHOk4msSvy2K6A/Jj6giD0ubvbsU0EaityBMo bC/qV1BVoxtg0OMJ9una4pw+vPiurBhJE9QRmkzo= 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 qjIak88VMDUR; Sat, 18 Apr 2020 01:25:46 +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; Sat, 18 Apr 2020 01:25:46 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sat, 18 Apr 2020 01:25:46 +0200 From: "Scharf, Michael" To: Wesley Eddy , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.txt Thread-Index: AQHWAeQDVOPAwP3wcE+cSz2/l6gpBKhXtwMAgCZdwmA= Date: Fri, 17 Apr 2020 23:25:45 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA7768E@rznt8114.rznt.rzdir.fht-esslingen.de> References: <158505800923.11744.10324863157807137499@ietfa.amsl.com> <58154b27-7a38-1ec3-9ab3-8a1acd25f952@mti-systems.com> In-Reply-To: <58154b27-7a38-1ec3-9ab3-8a1acd25f952@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DA7768Erznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-16.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: Fri, 17 Apr 2020 23:26:29 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2DA7768Erznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29taW5nIGJhY2sgdG8gaXNzdWUgMiksIGdpdmVuIHRoZSBsYWNrIG9mIGZvbGxvdy11cHMgb24g dGhhdCBzcGVjaWZpYyBkZXRhaWwuDQoNCkkgaGF2ZSBjaGVja2VkIHRoZSBMaW51eCBrZXJuZWwg ZG9jdW1lbnRhdGlvbi4gUjEgYW5kIFIyIHNlZW0gdG8gY29ycmVzcG9uZCB0byB0aGUgTGludXgg c3lzY3RsIHZhcmlhYmxlcyB0Y3BfcmV0cmllczEgYW5kIHRjcF9yZXRyaWVzMiwgd2hpY2ggYXJl IGRvY3VtZW50ZWQgYXMgZm9sbG93czoNCg0KdGNwX3JldHJpZXMxIC0gSU5URUdFUg0KICAgICAg ICAgICAgICAgIFRoaXMgdmFsdWUgaW5mbHVlbmNlcyB0aGUgdGltZSwgYWZ0ZXIgd2hpY2ggVENQ IGRlY2lkZXMsIHRoYXQNCiAgICAgICAgICAgICAgICBzb21ldGhpbmcgaXMgd3JvbmcgZHVlIHRv IHVuYWNrbm93bGVkZ2VkIFJUTyByZXRyYW5zbWlzc2lvbnMsDQogICAgICAgICAgICAgICAgYW5k IHJlcG9ydHMgdGhpcyBzdXNwaWNpb24gdG8gdGhlIG5ldHdvcmsgbGF5ZXIuDQogICAgICAgICAg ICAgICAgU2VlIHRjcF9yZXRyaWVzMiBmb3IgbW9yZSBkZXRhaWxzLg0KDQogICAgICAgICAgICAg ICAgUkZDIDExMjIgcmVjb21tZW5kcyBhdCBsZWFzdCAzIHJldHJhbnNtaXNzaW9ucywgd2hpY2gg aXMgdGhlDQogICAgICAgICAgICAgICAgZGVmYXVsdC4NCg0KdGNwX3JldHJpZXMyIC0gSU5URUdF Ug0KICAgICAgICAgICAgICAgIFRoaXMgdmFsdWUgaW5mbHVlbmNlcyB0aGUgdGltZW91dCBvZiBh biBhbGl2ZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgICAgICB3aGVuIFJUTyByZXRyYW5z bWlzc2lvbnMgcmVtYWluIHVuYWNrbm93bGVkZ2VkLg0KICAgICAgICAgICAgICAgIEdpdmVuIGEg dmFsdWUgb2YgTiwgYSBoeXBvdGhldGljYWwgVENQIGNvbm5lY3Rpb24gZm9sbG93aW5nDQogICAg ICAgICAgICAgICAgZXhwb25lbnRpYWwgYmFja29mZiB3aXRoIGFuIGluaXRpYWwgUlRPIG9mIFRD UF9SVE9fTUlOIHdvdWxkDQogICAgICAgICAgICAgICAgcmV0cmFuc21pdCBOIHRpbWVzIGJlZm9y ZSBraWxsaW5nIHRoZSBjb25uZWN0aW9uIGF0IHRoZSAoTisxKXRoIFJUTy4NCg0KICAgICAgICAg ICAgICAgIFRoZSBkZWZhdWx0IHZhbHVlIG9mIDE1IHlpZWxkcyBhIGh5cG90aGV0aWNhbCB0aW1l b3V0IG9mIDkyNC42DQogICAgICAgICAgICAgICAgc2Vjb25kcyBhbmQgaXMgYSBsb3dlciBib3Vu ZCBmb3IgdGhlIGVmZmVjdGl2ZSB0aW1lb3V0Lg0KICAgICAgICAgICAgICAgIFRDUCB3aWxsIGVm ZmVjdGl2ZWx5IHRpbWUgb3V0IGF0IHRoZSBmaXJzdCBSVE8gd2hpY2ggZXhjZWVkcyB0aGUNCiAg ICAgICAgICAgICAgICBoeXBvdGhldGljYWwgdGltZW91dC4NCg0KICAgICAgICAgICAgICAgIFJG QyAxMTIyIHJlY29tbWVuZHMgYXQgbGVhc3QgMTAwIHNlY29uZHMgZm9yIHRoZSB0aW1lb3V0LA0K ICAgICAgICAgICAgICAgIHdoaWNoIGNvcnJlc3BvbmRzIHRvIGEgdmFsdWUgb2YgYXQgbGVhc3Qg OC4NCg0KQXMgZmFyIGFzIEkgY2FuIHNlZSwgTGludXggaW1wbGVtZW50cyBmb3IgUjEgdGhlIFNI T1VMRCB0aGF0IGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTYgaW5oZXJpdHMgZnJvbSBSRkMg MTEyMi4NCg0KVGhlIExpbnV4IGRlZmF1bHQgZm9yIFIyIGlzIGxhcmdlciB0aGFuIHRoZSBTSE9V TEQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNiwgYnV0IHRoYXQgaXMgYWxsb3dlZCBi eSB0aGUgd29yZGluZyBpbiBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2Lg0KDQpHaXZlbiB0 aGlzIHJlZmVyZW5jZSB0byBSRkMgMTEyMiwgSSBhbHNvIGhhdmUgdGhlIGltcHJlc3Npb24gdGhh dCBkcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2IGNhbiBzdGF5IGFzIGlzIHJlZ2FyZGluZyBS MSBhbmQgUjIuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBXZXNsZXkgRWRkeQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMjQsIDIw MjAgMzowOSBQTQ0KVG86IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNi50eHQNCg0KDQpJbiB0aGlzIHVwZGF0 ZSwgSSB0aGluayBldmVyeXRoaW5nIGlzIGFkZHJlc3NlZCBleGNlcHQgZm9yIDQgdG9waWNzOg0K DQoxKSBSZXNlcnZlZCBiaXRzIGRlc2NyaXB0aW9uIC0gSSBtYWRlIG5vIGNoYW5nZXMgeWV0LiAg RGlzY3Vzc2lvbiBzcGFubmVkIGEgZmV3IHRocmVhZHMsIGJ1dCBkaWRuJ3QgbG9vayB0byBtZSBs aWtlIGl0IGNvbnZlcmdlZC4gIE1pY2hhZWwncyBzdW1tYXJ5IHRocmVhZCBjb3ZlcnMgYSBudW1i ZXIgb2Ygb3B0aW9ucyBhbmQgcmVsZXZhbnQgcXVlc3Rpb25zOiBodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL3RjcG0vVU9IbzR0WFFQcEJWOTBVLXBSbWR0X0xmalJBLw0KDQoy KSBSMSBhbmQgUjIgdmFsdWVzIC0gR29ycnkgcXVlc3Rpb25lZCB3aGV0aGVyIChBKSBhcHBsaWNh dGlvbnMgc2hvdWxkIHN0aWxsIGJlIG5vdGlmaWVkIHdpdGggUjEgaXMgcmVhY2hlZCwgYW5kIChC KSB3aGV0aGVyIFIxID0gMyBSVE9zIGFuZCBSMiA+PSAxMDBzIGFyZSBzdGlsbCByZWNvbW1lbmRl ZCB2YWx1ZXMuICBJIGRvbid0IHRoaW5rIGFueSBvdGhlciBSRkMgb3IgZXJyYXRhIGhhcyByZXZp c2VkIHRoZXNlLCBzbyBhbSBpbmNsaW5lZCB0byBsZWF2ZSBpdCBhbG9uZSBmb3Igbm93IGluIHRo aXMgZG9jLCBidXQgbWF5YmUgYm9va21hcmsgaXQgYXMgYSB0b3BpYyBmb3IgZnV0dXJlIGNvbnNp ZGVyYXRpb24gaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNCjMpIERlYWQgZ2F0ZXdheSBkZXRlY3Rp b24gLSBJIG1hZGUgbm8gY2hhbmdlcyB5ZXQ7IHRoaXMgbWF5IGJlIGFub3RoZXIgdG9waWMgZm9y IHBvdGVudGlhbCBmdXR1cmUgY29uc2lkZXJhdGlvbi4gIFRoZSBxdWVzdGlvbiBpcyBwb3NlZCBo ZXJlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RjcG0vSUdoSFlVT0N3 RVM3SS1EanNnSG5Gc2EtelZZLw0KDQo0KSBPUEVOK0xJU1RFTiB3aGlsZSBzYW1lIGxvY2FsIHBv cnQgaXMgaW4gU1lOLVNFTlQvUkVDRUlWRUQgLSBJIG1hZGUgbm8gY2hhbmdlcyB5ZXQsIGJ1dCBH b3JyeSBzdWdnZXN0ZWQgdGhhdCB0aGUgdGV4dCBiZWxvdyBtYXkgbmVlZCB1cGRhdGluZyB3aXRo IHJlZ2FyZCB0byBtb2Rlcm4gc3lzdGVtcyAoSSdsbCBiZSBncmF0ZWZ1bCBmb3Igc3BlY2lmaWMg c3VnZ2VzdGVkIGNoYW5nZXMgb24gdGhpcyk6DQoNCkEgVENQIHRoYXQgc3VwcG9ydHMgbXVsdGlw bGUgY29uY3VycmVudCB1c2VycyBNVVNUIHByb3ZpZGUgYW4NCk9QRU4gY2FsbCB0aGF0IHdpbGwg ZnVuY3Rpb25hbGx5IGFsbG93IGFuIGFwcGxpY2F0aW9uIHRvIExJU1RFTg0Kb24gYSBwb3J0IHdo aWxlIGEgY29ubmVjdGlvbiBibG9jayB3aXRoIHRoZSBzYW1lIGxvY2FsIHBvcnQgaXMNCmluIFNZ Ti1TRU5UIG9yIFNZTi1SRUNFSVZFRCBzdGF0ZSAoTVVTVC00MikuDQoNCg0KDQpPbiAzLzI0LzIw MjAgOTo1MyBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQpUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUQ1AgTWFpbnRlbmFuY2UgYW5kIE1pbm9yIEV4 dGVuc2lvbnMgV0cgb2YgdGhlIElFVEYuDQoNCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6 IFRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIFNwZWNpZmljYXRpb24NCg0KICAgICAgICBB dXRob3IgICAgICAgICAgOiBXZXNsZXkgTS4gRWRkeQ0KDQogRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNi50eHQNCg0KIFBhZ2VzICAgICAgICAgICA6IDEwNg0K DQogRGF0ZSAgICAgICAgICAgIDogMjAyMC0wMy0yNA0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRo aXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBJbnRlcm5ldCdzIFRyYW5zbWlzc2lvbiBDb250cm9s IFByb3RvY29sDQoNCiAgIChUQ1ApLiAgVENQIGlzIGFuIGltcG9ydGFudCB0cmFuc3BvcnQgbGF5 ZXIgcHJvdG9jb2wgaW4gdGhlIEludGVybmV0DQoNCiAgIHN0YWNrLCBhbmQgaGFzIGNvbnRpbnVv dXNseSBldm9sdmVkIG92ZXIgZGVjYWRlcyBvZiB1c2UgYW5kIGdyb3d0aCBvZg0KDQogICB0aGUg SW50ZXJuZXQuICBPdmVyIHRoaXMgdGltZSwgYSBudW1iZXIgb2YgY2hhbmdlcyBoYXZlIGJlZW4g bWFkZSB0bw0KDQogICBUQ1AgYXMgaXQgd2FzIHNwZWNpZmllZCBpbiBSRkMgNzkzLCB0aG91Z2gg dGhlc2UgaGF2ZSBvbmx5IGJlZW4NCg0KICAgZG9jdW1lbnRlZCBpbiBhIHBpZWNlbWVhbCBmYXNo aW9uLiAgVGhpcyBkb2N1bWVudCBjb2xsZWN0cyBhbmQgYnJpbmdzDQoNCiAgIHRob3NlIGNoYW5n ZXMgdG9nZXRoZXIgd2l0aCB0aGUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBmcm9tIFJGQyA3OTMu DQoNCiAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xldGVzIFJGQyA3OTMsIGFzIHdlbGwgYXMgODc5LCAy ODczLCA2MDkzLCA2NDI5LA0KDQogICA2NTI4LCBhbmQgNjY5MSB0aGF0IHVwZGF0ZWQgcGFydHMg b2YgUkZDIDc5My4gIEl0IHVwZGF0ZXMgUkZDIDExMjIsDQoNCiAgIGFuZCBzaG91bGQgYmUgY29u c2lkZXJlZCBhcyBhIHJlcGxhY2VtZW50IGZvciB0aGUgcG9ydGlvbnMgb2YgdGhhdA0KDQogICBk b2N1bWVudCBkZWFsaW5nIHdpdGggVENQIHJlcXVpcmVtZW50cy4gIEl0IHVwZGF0ZXMgUkZDIDU5 NjEgZHVlIHRvIGENCg0KICAgc21hbGwgY2xhcmlmaWNhdGlvbiBpbiByZXNldCBoYW5kbGluZyB3 aGlsZSBpbiB0aGUgU1lOLVJFQ0VJVkVEDQoNCiAgIHN0YXRlLg0KDQoNCg0KICAgUkZDIEVESVRP UiBOT1RFOiBJZiBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24gYXMgYW4gUkZDLCB0aGlzIHNob3Vs ZA0KDQogICBiZSBtYXJrZWQgYWRkaXRpb25hbGx5IGFzICJTVEQ6IDciIGFuZCByZXBsYWNlIFJG QyA3OTMgaW4gdGhhdCByb2xlLg0KDQoNCg0KDQoNCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy8NCg0KDQoNClRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTYNCg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2DQoNCg0KDQpB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2 DQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoNCg0KSW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KDQpm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCnRjcG0gbWFpbGluZyBsaXN0 DQoNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0K --_000_6EC6417807D9754DA64F3087E2E2E03E2DA7768Erznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUg MiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uSFRNTFZvcmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZv cm1hdGllcnQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRS1N YWlsRm9ybWF0dm9ybGFnZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29taW5nIGJhY2sgdG8gaXNzdWUgMiksIGdpdmVuIHRo ZSBsYWNrIG9mIGZvbGxvdy11cHMgb24gdGhhdCBzcGVjaWZpYyBkZXRhaWwuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkg aGF2ZSBjaGVja2VkIHRoZSBMaW51eCBrZXJuZWwgZG9jdW1lbnRhdGlvbi4gUjEgYW5kIFIyIHNl ZW0gdG8gY29ycmVzcG9uZCB0byB0aGUgTGludXggc3lzY3RsIHZhcmlhYmxlcyB0Y3BfcmV0cmll czENCiBhbmQgdGNwX3JldHJpZXMyLCB3aGljaCBhcmUgZG9jdW1lbnRlZCBhcyBmb2xsb3dzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj50Y3BfcmV0cmllczEgLSBJTlRFR0VSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVGhpcyB2YWx1ZSBpbmZsdWVuY2VzIHRoZSB0aW1lLCBhZnRlciB3aGljaCBUQ1Ag ZGVjaWRlcywgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvbWV0aGlu ZyBpcyB3cm9uZyBkdWUgdG8gdW5hY2tub3dsZWRnZWQgUlRPIHJldHJhbnNtaXNzaW9ucyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgcmVwb3J0cyB0aGlzIHN1c3BpY2lv biB0byB0aGUgbmV0d29yayBsYXllci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBTZWUgdGNwX3JldHJpZXMyIGZvciBtb3JlIGRldGFpbHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSRkMgMTEyMiByZWNvbW1lbmRzIGF0IGxlYXN0IDMgcmV0 cmFuc21pc3Npb25zLCB3aGljaCBpcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkZWZhdWx0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50Y3BfcmV0cmllczIgLSBJTlRFR0VSPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyB2YWx1ZSBpbmZsdWVuY2VzIHRoZSB0aW1lb3V0 IG9mIGFuIGFsaXZlIFRDUCBjb25uZWN0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHdoZW4gUlRPIHJldHJhbnNtaXNzaW9ucyByZW1haW4gdW5hY2tub3dsZWRnZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR2l2ZW4gYSB2YWx1ZSBvZiBOLCBhIGh5 cG90aGV0aWNhbCBUQ1AgY29ubmVjdGlvbiBmb2xsb3dpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBleHBvbmVudGlhbCBiYWNrb2ZmIHdpdGggYW4gaW5pdGlhbCBSVE8gb2Yg VENQX1JUT19NSU4gd291bGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXRy YW5zbWl0IE4gdGltZXMgYmVmb3JlIGtpbGxpbmcgdGhlIGNvbm5lY3Rpb24gYXQgdGhlIChOJiM0 MzsxKXRoIFJUTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBkZWZhdWx0IHZhbHVlIG9mIDE1IHlpZWxkcyBhIGh5cG90aGV0aWNhbCB0aW1lb3V0IG9mIDky NC42PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vjb25kcyBhbmQgaXMgYSBs b3dlciBib3VuZCBmb3IgdGhlIGVmZmVjdGl2ZSB0aW1lb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRDUCB3aWxsIGVmZmVjdGl2ZWx5IHRpbWUgb3V0IGF0IHRoZSBmaXJz dCBSVE8gd2hpY2ggZXhjZWVkcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBoeXBvdGhldGljYWwgdGltZW91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJGQyAxMTIyIHJlY29tbWVuZHMgYXQgbGVhc3QgMTAwIHNlY29uZHMgZm9yIHRo ZSB0aW1lb3V0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGNvcnJl c3BvbmRzIHRvIGEgdmFsdWUgb2YgYXQgbGVhc3QgOC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgZmFyIGFzIEkgY2Fu IHNlZSwgTGludXggaW1wbGVtZW50cyBmb3IgUjEgdGhlIFNIT1VMRCB0aGF0IGRyYWZ0LWlldGYt dGNwbS1yZmM3OTNiaXMtMTYgaW5oZXJpdHMgZnJvbSBSRkMgMTEyMi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIExp bnV4IGRlZmF1bHQgZm9yIFIyIGlzIGxhcmdlciB0aGFuIHRoZSBTSE9VTEQgaW4gZHJhZnQtaWV0 Zi10Y3BtLXJmYzc5M2Jpcy0xNiwgYnV0IHRoYXQgaXMgYWxsb3dlZCBieSB0aGUgd29yZGluZw0K IGluIGRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTYuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkdpdmVuIHRoaXMgcmVm ZXJlbmNlIHRvIFJGQyAxMTIyLCBJIGFsc28gaGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IGRyYWZ0 LWlldGYtdGNwbS1yZmM3OTNiaXMtMTYgY2FuIHN0YXkgYXMgaXMgcmVnYXJkaW5nDQogUjEgYW5k IFIyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdGNwbSAmbHQ7dGNwbS1ib3VuY2VzQGlldGYub3JnJmd0 Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5XZXNsZXkgRWRkeTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBNYXJjaCAyNCwgMjAyMCAzOjA5IFBNPGJyPg0KPGI+VG86PC9iPiB0Y3BtQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10 Y3BtLXJmYzc5M2Jpcy0xNi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JbiB0aGlz IHVwZGF0ZSwgSSB0aGluayBldmVyeXRoaW5nIGlzIGFkZHJlc3NlZCBleGNlcHQgZm9yIDQgdG9w aWNzOjxvOnA+PC9vOnA+PC9wPg0KPHA+MSkgUmVzZXJ2ZWQgYml0cyBkZXNjcmlwdGlvbiAtIEkg bWFkZSBubyBjaGFuZ2VzIHlldC4mbmJzcDsgRGlzY3Vzc2lvbiBzcGFubmVkIGEgZmV3IHRocmVh ZHMsIGJ1dCBkaWRuJ3QgbG9vayB0byBtZSBsaWtlIGl0IGNvbnZlcmdlZC4mbmJzcDsgTWljaGFl bCdzIHN1bW1hcnkgdGhyZWFkIGNvdmVycyBhIG51bWJlciBvZiBvcHRpb25zIGFuZCByZWxldmFu dCBxdWVzdGlvbnM6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL3RjcG0vVU9IbzR0WFFQcEJWOTBVLXBSbWR0X0xmalJBLyI+DQpodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3RjcG0vVU9IbzR0WFFQcEJWOTBVLXBSbWR0X0xmalJBLzwv YT48bzpwPjwvbzpwPjwvcD4NCjxwPjIpIFIxIGFuZCBSMiB2YWx1ZXMgLSBHb3JyeSBxdWVzdGlv bmVkIHdoZXRoZXIgKEEpIGFwcGxpY2F0aW9ucyBzaG91bGQgc3RpbGwgYmUgbm90aWZpZWQgd2l0 aCBSMSBpcyByZWFjaGVkLCBhbmQgKEIpIHdoZXRoZXIgUjEgPSAzIFJUT3MgYW5kIFIyICZndDs9 IDEwMHMgYXJlIHN0aWxsIHJlY29tbWVuZGVkIHZhbHVlcy4mbmJzcDsgSSBkb24ndCB0aGluayBh bnkgb3RoZXIgUkZDIG9yIGVycmF0YSBoYXMgcmV2aXNlZCB0aGVzZSwgc28gYW0gaW5jbGluZWQN CiB0byBsZWF2ZSBpdCBhbG9uZSBmb3Igbm93IGluIHRoaXMgZG9jLCBidXQgbWF5YmUgYm9va21h cmsgaXQgYXMgYSB0b3BpYyBmb3IgZnV0dXJlIGNvbnNpZGVyYXRpb24gaW4gdGhlIHdvcmtpbmcg Z3JvdXAuPG86cD48L286cD48L3A+DQo8cD4zKSBEZWFkIGdhdGV3YXkgZGV0ZWN0aW9uIC0gSSBt YWRlIG5vIGNoYW5nZXMgeWV0OyB0aGlzIG1heSBiZSBhbm90aGVyIHRvcGljIGZvciBwb3RlbnRp YWwgZnV0dXJlIGNvbnNpZGVyYXRpb24uJm5ic3A7IFRoZSBxdWVzdGlvbiBpcyBwb3NlZCBoZXJl Og0KPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90Y3BtL0lH aEhZVU9Dd0VTN0ktRGpzZ0huRnNhLXpWWS8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy90Y3BtL0lHaEhZVU9Dd0VTN0ktRGpzZ0huRnNhLXpWWS88L2E+PG86cD48L286 cD48L3A+DQo8cD40KSBPUEVOJiM0MztMSVNURU4gd2hpbGUgc2FtZSBsb2NhbCBwb3J0IGlzIGlu IFNZTi1TRU5UL1JFQ0VJVkVEIC0gSSBtYWRlIG5vIGNoYW5nZXMgeWV0LCBidXQgR29ycnkgc3Vn Z2VzdGVkIHRoYXQgdGhlIHRleHQgYmVsb3cgbWF5IG5lZWQgdXBkYXRpbmcgd2l0aCByZWdhcmQg dG8gbW9kZXJuIHN5c3RlbXMgKEknbGwgYmUgZ3JhdGVmdWwgZm9yIHNwZWNpZmljIHN1Z2dlc3Rl ZCBjaGFuZ2VzIG9uIHRoaXMpOjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMTcyQjREO2JhY2tncm91bmQ6d2hpdGUiPkEgVENQIHRoYXQgc3VwcG9ydHMgbXVsdGlw bGUgY29uY3VycmVudCB1c2VycyBNVVNUIHByb3ZpZGUgYW48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJp ZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxNzJCNEQ7YmFja2dyb3VuZDp3aGl0ZSI+T1BF TiBjYWxsIHRoYXQgd2lsbCBmdW5jdGlvbmFsbHkgYWxsb3cgYW4gYXBwbGljYXRpb24gdG8gTElT VEVOPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMTcyQjREO2JhY2tncm91bmQ6d2hpdGUiPm9uIGEgcG9ydCB3aGlsZSBhIGNv bm5lY3Rpb24gYmxvY2sgd2l0aCB0aGUgc2FtZSBsb2NhbCBwb3J0IGlzPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxNzJCNEQ7YmFja2dy b3VuZDp3aGl0ZSI+aW4gU1lOLVNFTlQgb3IgU1lOLVJFQ0VJVkVEIHN0YXRlIChNVVNULTQyKS48 L3NwYW4+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzI0LzIwMjAgOTo1MyBBTSwgPGEg aHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRDUCBNYWludGVu YW5jZSBhbmQgTWlub3IgRXh0ZW5zaW9ucyBXRyBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7VGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBUcmFuc21pc3Npb24gQ29udHJvbCBQ cm90b2NvbCBTcGVjaWZpY2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF1dGhvciZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFdlc2xleSBNLiBFZGR5PG86cD48 L286cD48L3ByZT4NCjxwcmU+IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNi50eHQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4gUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAxMDY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gRGF0 ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6IDIwMjAtMDMtMjQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIEludGVybmV0J3MgVHJhbnNtaXNz aW9uIENvbnRyb2wgUHJvdG9jb2w8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg KFRDUCkuJm5ic3A7IFRDUCBpcyBhbiBpbXBvcnRhbnQgdHJhbnNwb3J0IGxheWVyIHByb3RvY29s IGluIHRoZSBJbnRlcm5ldDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzdGFj aywgYW5kIGhhcyBjb250aW51b3VzbHkgZXZvbHZlZCBvdmVyIGRlY2FkZXMgb2YgdXNlIGFuZCBn cm93dGggb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIEludGVybmV0 LiZuYnNwOyBPdmVyIHRoaXMgdGltZSwgYSBudW1iZXIgb2YgY2hhbmdlcyBoYXZlIGJlZW4gbWFk ZSB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUQ1AgYXMgaXQgd2FzIHNw ZWNpZmllZCBpbiBSRkMgNzkzLCB0aG91Z2ggdGhlc2UgaGF2ZSBvbmx5IGJlZW48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZG9jdW1lbnRlZCBpbiBhIHBpZWNlbWVhbCBmYXNo aW9uLiZuYnNwOyBUaGlzIGRvY3VtZW50IGNvbGxlY3RzIGFuZCBicmluZ3M8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhvc2UgY2hhbmdlcyB0b2dldGhlciB3aXRoIHRoZSBw cm90b2NvbCBzcGVjaWZpY2F0aW9uIGZyb20gUkZDIDc5My48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDc5MywgYXMgd2VsbCBh cyA4NzksIDI4NzMsIDYwOTMsIDY0MjksPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IDY1MjgsIGFuZCA2NjkxIHRoYXQgdXBkYXRlZCBwYXJ0cyBvZiBSRkMgNzkzLiZuYnNwOyBJ dCB1cGRhdGVzIFJGQyAxMTIyLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBh bmQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgYSByZXBsYWNlbWVudCBmb3IgdGhlIHBvcnRpb25z IG9mIHRoYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZG9jdW1lbnQgZGVh bGluZyB3aXRoIFRDUCByZXF1aXJlbWVudHMuJm5ic3A7IEl0IHVwZGF0ZXMgUkZDIDU5NjEgZHVl IHRvIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc21hbGwgY2xhcmlmaWNh dGlvbiBpbiByZXNldCBoYW5kbGluZyB3aGlsZSBpbiB0aGUgU1lOLVJFQ0VJVkVEPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHN0YXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBSRkMgRURJVE9SIE5P VEU6IElmIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBSRkMsIHRoaXMgc2hvdWxkPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGJlIG1hcmtlZCBhZGRpdGlvbmFsbHkg YXMgJnF1b3Q7U1REOiA3JnF1b3Q7IGFuZCByZXBsYWNlIFJGQyA3OTMgaW4gdGhhdCByb2xlLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTYiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2PC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNiI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmZjNzkzYmlzLTE2PC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi10Y3BtLXJmYzc5M2Jpcy0xNiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtdGNwbS1yZmM3OTNiaXMtMTY8L2E+PG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRjcG0gbWFpbGluZyBsaXN0PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1A aWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2DA7768Erznt8114rzntrzd_-- From nobody Fri Apr 17 16:43: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 CDE643A09EC; Fri, 17 Apr 2020 16:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=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=bobbriscoe.net 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 aT4Lmct2Z13s; Fri, 17 Apr 2020 16:43:24 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 3A3B33A077E; Fri, 17 Apr 2020 16:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=0jLfdtLniBEQypoyKjwGPLgWZpnd4hZx8QQA8/2BV9I=; b=LpooYnc9JHgHO5gr5O+SWYL2Cr h6zb5kbsax0ollwedBjRsmGKQoDIcYXzNygSbBM7J3OI52Ta+5duCKHRbo+hPAbpETBrFJdu30PqW zw6seMGKp3COEyJU83CyHX7LHU8fw7od+SGfsAJq+lPnARAA/ks0n2jUpq+DVKru0yKiD9MK8yYFy S+HbLcrBte3u4tQ06JeyAgGLgWd05InflfP99mktOHCuNKtLmaX9admpjO+4er27e8UNSezfQoeMg 5KxDyIcdCcoQTV3R6rRFpHaboGxFnC80HMyiYtTzvGAxlt/71PiJyAcFqVaqqALTX+wS1AMJn43go fbHvyYHg==; Received: from [31.185.128.106] (port=55614 helo=[192.168.0.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jPadm-000RGV-DR; Sat, 18 Apr 2020 00:43:22 +0100 To: Michael Tuexen Cc: tcpm IETF list , =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= , tcpm-chairs@ietf.org, Mirja Kuehlewind , Richard Scheffenegger References: <1ACE7676-8A2C-4A64-AF20-39A1C07A77ED@fh-muenster.de> From: Bob Briscoe X-Remindit: Sat Apr 18 2020 01:00:00 GMT+0100 (BST) Message-ID: Date: Sat, 18 Apr 2020 00:43:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1ACE7676-8A2C-4A64-AF20-39A1C07A77ED@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 17 Apr 2020 23:43:29 -0000 Michael, On 17/04/2020 20:50, Michael Tuexen wrote: >> On 17. Apr 2020, at 21:01, Bob Briscoe wrote: >> >> Michael, >> >> * Accurate ECN TCP Feedback: Changes & Status >> * Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't discussed between us yet!) >> * draft-ietf-tcpm-accurate-ecn-11 >> * 15-20mins. >> >> Are you carrying over requests from the Cancelled Vancouver mtg as well? > No, since things might have changed in between. >> Cos I think Ilpo was going to give a talk on his AccECN implementation that I'd like to hear. > Ilpo, In case you want to give that presentation, please send a request... May I ask on Ilpo's behalf, just to ensure he meets the deadline? It's possible he's missed your email, but I'm pretty sure he'll want to present, 'cos I know he prepared his slides some time ago (he showed them to me), and they are still relevant. >> Might be best to have the one below first, to give context for Ilpo's talk. > You mean the one above, right? First you presentation, then Ilpo's, if he want to give it. Yeah sorry, I meant 'above' I moved my email around before sending. Cheers Bob > Best regards > Michael >> >> Cheers >> >> >> >> Bob >> >> >> On 14/04/2020 21:27, Michael Tuexen wrote: >>> Dear all, >>> >>> TCPM has a 2.5 hour virtual interim meeting, scheduled for >>> 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). >>> >>> If you would like to present during this meeting, please provide by the >>> end of Friday, April 17th: >>> >>> * Title of the presentation >>> * Name of the presenter >>> * Name of the Internet Draft >>> * Time required (including Q/A) >>> Please send us the slides for your presentations by Friday, April 24th, latest. >>> >>> Best regards >>> Michael >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> -- >> ________________________________________________________________ >> Bob Briscoe >> http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Apr 17 22:21: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 6B8AE3A1014; Fri, 17 Apr 2020 22:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.helsinki.fi 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 91Q_pHUfujw5; Fri, 17 Apr 2020 22:20:55 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CA63A1015; Fri, 17 Apr 2020 22:20:54 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sat, 18 Apr 2020 08:20:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=2inurPFgtgMo8JJp7 xM7PvlWIXHAx7aOkblFWtJXNtA=; b=PFqyXF1dBDJysu7F+l5qYOkMcur41nO/v vJ5YlzuA04lfnH4OITgRAxdPq6zedU80PJyopjhYFwQTbWiJuP0MST9ap7aExnSd RoASJTMKsticn3jYVF9YhQUzYM/PYDNZKY7VaEYlhTDviWu+CMfsRdqmGwVqZHPs f+seEFfoOA= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Sat, 18 Apr 2020 08:20:23 +0300 id 00000000005A014E.000000005E9A8E17.0000612E Date: Sat, 18 Apr 2020 08:20:23 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Bob Briscoe cc: Michael Tuexen , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind , tcpm-chairs@ietf.org In-Reply-To: Message-ID: References: <1ACE7676-8A2C-4A64-AF20-39A1C07A77ED@fh-muenster.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 18 Apr 2020 05:21:01 -0000 Hi, Yes, I'll be presenting. I think I'll need at least 25min. -- i. On Sat, 18 Apr 2020, Bob Briscoe wrote: > Michael, > > On 17/04/2020 20:50, Michael Tuexen wrote: > > > On 17. Apr 2020, at 21:01, Bob Briscoe wrote: > > > > > > Michael, > > > > > > * Accurate ECN TCP Feedback: Changes & Status > > > * Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't discussed > > > between us yet!) > > > * draft-ietf-tcpm-accurate-ecn-11 > > > * 15-20mins. > > > > > > Are you carrying over requests from the Cancelled Vancouver mtg as well? > > No, since things might have changed in between. > > > Cos I think Ilpo was going to give a talk on his AccECN implementation > > > that I'd like to hear. > > Ilpo, In case you want to give that presentation, please send a request... > > May I ask on Ilpo's behalf, just to ensure he meets the deadline? > It's possible he's missed your email, but I'm pretty sure he'll want to > present, 'cos I know he prepared his slides some time ago (he showed them to > me), and they are still relevant. > > > > > Might be best to have the one below first, to give context for Ilpo's > > > talk. > > You mean the one above, right? First you presentation, then Ilpo's, if he > > want to give it. > > Yeah sorry, I meant 'above' I moved my email around before sending. > > Cheers > > > > Bob > > > Best regards > > Michael > > > > > > Cheers > > > > > > > > > > > > Bob > > > > > > > > > On 14/04/2020 21:27, Michael Tuexen wrote: > > > > Dear all, > > > > > > > > TCPM has a 2.5 hour virtual interim meeting, scheduled for > > > > 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). > > > > > > > > If you would like to present during this meeting, please provide by the > > > > end of Friday, April 17th: > > > > > > > > * Title of the presentation > > > > * Name of the presenter > > > > * Name of the Internet Draft > > > > * Time required (including Q/A) > > > > Please send us the slides for your presentations by Friday, April 24th, > > > > latest. > > > > > > > > Best regards > > > > Michael > > > > > > > > > > > > > > > > _______________________________________________ > > > > tcpm mailing list > > > > > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > -- > > > ________________________________________________________________ > > > Bob Briscoe > > > http://bobbriscoe.net/ > > From nobody Sat Apr 18 02:08: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 596443A03EF; Sat, 18 Apr 2020 02:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoOAPbCl4P_I; Sat, 18 Apr 2020 02:08:28 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45883A03ED; Sat, 18 Apr 2020 02:08:27 -0700 (PDT) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 80A7C71FE5702; Sat, 18 Apr 2020 11:08:21 +0200 (CEST) From: Michael Tuexen Message-Id: <784F564C-0B53-4533-B1BE-1BEB48F95DAA@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_0D380C4B-80AC-4340-81F7-81DCEB337687"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 18 Apr 2020 11:08:20 +0200 In-Reply-To: Cc: Bob Briscoe , Richard Scheffenegger , tcpm IETF list , Mirja Kuehlewind , tcpm-chairs@ietf.org To: =?utf-8?Q?Ilpo_J=C3=A4rvinen?= References: <1ACE7676-8A2C-4A64-AF20-39A1C07A77ED@fh-muenster.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] Agenda requests for TCPM interim meeting 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, 18 Apr 2020 09:08:30 -0000 --Apple-Mail=_0D380C4B-80AC-4340-81F7-81DCEB337687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18. Apr 2020, at 07:20, Ilpo J=C3=A4rvinen = wrote: >=20 > Hi, >=20 > Yes, I'll be presenting. I think I'll need at least 25min. OK, thank for the information. Best regards Michael >=20 > --=20 > i. >=20 >=20 > On Sat, 18 Apr 2020, Bob Briscoe wrote: >=20 >> Michael, >>=20 >> On 17/04/2020 20:50, Michael Tuexen wrote: >>>> On 17. Apr 2020, at 21:01, Bob Briscoe wrote: >>>>=20 >>>> Michael, >>>>=20 >>>> * Accurate ECN TCP Feedback: Changes & Status >>>> * Bob Briscoe or Mirja or Richard Scheffenegger (sorry, haven't = discussed >>>> between us yet!) >>>> * draft-ietf-tcpm-accurate-ecn-11 >>>> * 15-20mins. >>>>=20 >>>> Are you carrying over requests from the Cancelled Vancouver mtg as = well? >>> No, since things might have changed in between. >>>> Cos I think Ilpo was going to give a talk on his AccECN = implementation >>>> that I'd like to hear. >>> Ilpo, In case you want to give that presentation, please send a = request... >>=20 >> May I ask on Ilpo's behalf, just to ensure he meets the deadline? >> It's possible he's missed your email, but I'm pretty sure he'll want = to >> present, 'cos I know he prepared his slides some time ago (he showed = them to >> me), and they are still relevant. >>=20 >>=20 >>>> Might be best to have the one below first, to give context for = Ilpo's >>>> talk. >>> You mean the one above, right? First you presentation, then Ilpo's, = if he >>> want to give it. >>=20 >> Yeah sorry, I meant 'above' I moved my email around before sending. >>=20 >> Cheers >>=20 >>=20 >>=20 >> Bob >>=20 >>> Best regards >>> Michael >>>>=20 >>>> Cheers >>>>=20 >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>> On 14/04/2020 21:27, Michael Tuexen wrote: >>>>> Dear all, >>>>>=20 >>>>> TCPM has a 2.5 hour virtual interim meeting, scheduled for >>>>> 2020-04-29 from 16:00 to 18:30 Europe/Berlin (14:00 to 16:30 UTC). >>>>>=20 >>>>> If you would like to present during this meeting, please provide = by the >>>>> end of Friday, April 17th: >>>>>=20 >>>>> * Title of the presentation >>>>> * Name of the presenter >>>>> * Name of the Internet Draft >>>>> * Time required (including Q/A) >>>>> Please send us the slides for your presentations by Friday, April = 24th, >>>>> latest. >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>>=20 >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> --=20 >>>> ________________________________________________________________ >>>> Bob Briscoe >>>> http://bobbriscoe.net/ >>=20 >>=20 --Apple-Mail=_0D380C4B-80AC-4340-81F7-81DCEB337687 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MTgwOTA4MjBaMC8GCSqGSIb3DQEJBDEiBCB3XOESC7zsDfTraqDaueORS5Z76VKX6c22DMmKv8lJ 0TCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAQCnNP3EhLpQc8MQOP/ROAZW1jjhj I6z9tEn3kDKTlqO6q11eisw9yGVqJn4pYQ4lexmuePpiZj6bWRBp2s/G314icIewwkx56kCJ2TZh ZJyre7ThCqHwipPG15C7vzU/lxheAw2C0DbSRsKp+mTIzDyH8M/EEYYKln3YgMvN1QAPkfzPdAKp fT2uavLINGcO7bsgmk5dGaX9+YGLDswlNYwkx1wzIIElRMVVWuJb4P7Lcq2b2hVXgmVYkX5Ab4Wy FoiofKzzVAaCmEGm74fc6xjauSZGkBm+PmkM9NXgmpyD8+VsVQo72+eTI5VtWDI6CGWISmfuZ/Dv 4QrCl5fEAwAAAAAAAA== --Apple-Mail=_0D380C4B-80AC-4340-81F7-81DCEB337687-- From nobody Mon Apr 20 07:53:26 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 4F5BE3A084A; Mon, 20 Apr 2020 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 6Aa8buWvv8VO; Mon, 20 Apr 2020 07:53:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5393A0848; Mon, 20 Apr 2020 07:53:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3E7D7F406D5; Mon, 20 Apr 2020 07:53:10 -0700 (PDT) To: wes@mti-systems.com, ananth@cisco.com, randall@lakerest.net, mdalal@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: martin.h.duke@gmail.com, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200420145310.3E7D7F406D5@rfc-editor.org> Date: Mon, 20 Apr 2020 07:53:10 -0700 (PDT) Archived-At: Subject: [tcpm] [Errata Held for Document Update] RFC5961 (5068) 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, 20 Apr 2020 14:53:16 -0000 The following errata report has been held for document update for RFC5961, "Improving TCP's Robustness to Blind In-Window Attacks". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5068 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Wesley Eddy Date Reported: 2017-07-12 Held by: Martin Duke (IESG) Section: 3.2 Original Text ------------- [RFC0793] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: Corrected Text -------------- [RFC0793] currently requires handling of a segment with the RST bit when not in SYN-SENT to be processed as follows: Notes ----- The text in section 3.2 begins by stating a change from RFC 793 for RST bit handling "when in a synchronized state" (which means all states except for LISTEN, SYN-SENT, and SYN-RECEIVED). Section 3.4 of RFC 793 refers to "all states but SYN-SENT", so the description of RFC 793 is inaccurate. -------------------------------------- RFC5961 (draft-ietf-tcpm-tcpsecure-13) -------------------------------------- Title : Improving TCP's Robustness to Blind In-Window Attacks Publication Date : August 2010 Author(s) : A. Ramaiah, R. Stewart, M. Dalal Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Thu Apr 23 13:19: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 96C5B3A1354 for ; Thu, 23 Apr 2020 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=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 o_cXk4oWiK2Q for ; Thu, 23 Apr 2020 13:18:57 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2525E3A07AA for ; Thu, 23 Apr 2020 13:18:54 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:f009:e2e4:e606:a015] (unknown [IPv6:2a02:8109:1140:c3d:f009:e2e4:e606:a015]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 55E19722CD404 for ; Thu, 23 Apr 2020 22:18:50 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_FFB533A6-C77A-405E-A54C-D588E0413125"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <18CF9332-2F18-4939-AADE-A275AB29BF65@fh-muenster.de> Date: Thu, 23 Apr 2020 22:18:46 +0200 To: tcpm IETF list X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [tcpm] Agenda for upcoming interim meeting 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, 23 Apr 2020 20:19:00 -0000 --Apple-Mail=_FFB533A6-C77A-405E-A54C-D588E0413125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, the agenda of the interim meeting on Wednesday, April 29, 2020, 14:00 - = 16:30 UTC is available at: https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01/ Best regards Michael= --Apple-Mail=_FFB533A6-C77A-405E-A54C-D588E0413125 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MjMyMDE4NDZaMC8GCSqGSIb3DQEJBDEiBCDs2etstwPjS+gRD6AF9QFMi2iZVbgwaUiFWs4zbKX2 qjCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEApo27cf9qG/MekNO08Ht+mb1naP62 C/A7//Gg9F341iQCONwvjepL7Euh6nN7e9l8KfhkuMT7nc8lxI4NgWgU3pPwBv+UitH+2NtFO7nH 7XKw0YQKTCFXGmiY7wD/yUvMqCRofZRRtunAZ5DiOfUs5wWqVDVeMCQbQGEpOI+9YDninmxTdhvl w93P4Rpfk85zFfkywbCAgc9nhV4Hfk0mp+maCn9M8CfRom7Q3wSiIMwXEiK210WOo7dB4CPPFDrf FuPSOgM2XRhwUh2poM/pwRcZzoR9BNAbaKPVygVbw93j2TUC8aeFSQfj4m0jznCp2+WCQXQVUR28 4PwLNqdwdgAAAAAAAA== --Apple-Mail=_FFB533A6-C77A-405E-A54C-D588E0413125-- From nobody Fri Apr 24 10:32:25 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 04DBE3A102C; Fri, 24 Apr 2020 10:32:15 -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: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158774953492.2213.11582423726358760031@ietfa.amsl.com> Date: Fri, 24 Apr 2020 10:32:15 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-03.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, 24 Apr 2020 17:32:15 -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 : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-03.txt Pages : 32 Date : 2020-04-24 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-03 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 Sun Apr 26 20:02: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 AD9BC3A0528 for ; Sun, 26 Apr 2020 20:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=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=microsoft.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 mR49GbxU-WVN for ; Sun, 26 Apr 2020 20:02:00 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650090.outbound.protection.outlook.com [40.107.65.90]) (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 F0E3E3A04BB for ; Sun, 26 Apr 2020 20:01:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mhk/JB5nVcbbRZYYfErFON5X7NK/MiRtc/gGYa0y6x+P4q7DrZfu0eSCgcHBOWUakeRBJ5qMn+y+W18etfVER4fRgZoqiyzY61OP+AdpKsMCCPG6S3u+b8ZJN30GCu+8RhN5kII32DmHKU4iHVAevgofvnk4fkIuwRB6PrNDCfvYqCrY/BbONodsGLflyqKkti3f01RiNfiS7tv9swLG3Vv9mWWsmqKeCBkYI5wwc3jN5F4jOaNuq6fVh02w6xHI2/jD+BkGtlEHvYUttShP3G5c4gu+eyb9Xac6OqyUHAGOyZiFDNtMHq29z8d5IWcdr/0yO68d7XaO2gVo2T9c0w== 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=omZKhxqJkxXX4bXnzZYQcORYPiU4qyBNaefzkE2HHYw=; b=YhHzsRAX5dnomePI7DeS+oJOFerd8E2JL9dCqfeTS3czx5aaad+me7be2qgMCvZF6gtcPiFwtzagXcfQbtA9WH3Hb0LjvDoCqHjqqm1pooviIUGf5TLxqhbq70h9kKj1T667/C7rMoDQbBjndwyEHOpP+r7rSsBN9F6wPvVhiqMOSVNBGRZ9lKt4/tSQA/wfXs17kh4yasi/C7nmzYGWgjzDAg9hiEKszLCyA5V6qM+vvEL9JfxP1hv+t27EMHz5y1B9l8HInknRqfvSCGlSIrh3x/m9T8opZcwhH8g9eirDa6N7BbsO1pxhZyWJXV75ND+xpv7lNblS/6g7ddBt+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=omZKhxqJkxXX4bXnzZYQcORYPiU4qyBNaefzkE2HHYw=; b=io/yKm9szSDIn2CcV10/D0GdOQpSnf5g1LGjJNnZyv+57qrJvRjPclij9tU/ijAdDni09mJ36ukVL+Tk4L/NvDe1whvCj/EWIL+7IdDr3oVaQ3Q6QfIxqV+VB5hZyLVelYvzo/tkQHj+eLlsUOdWP5s2Dmk8LeLHNctPKyjqjls= Received: from CO2PR00MB0120.namprd00.prod.outlook.com (2603:10b6:102:18::18) by CO2PR00MB0181.namprd00.prod.outlook.com (2603:10b6:102:15::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2988.0; Mon, 27 Apr 2020 03:01:42 +0000 Received: from CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::8459:85d:30f8:53e5]) by CO2PR00MB0120.namprd00.prod.outlook.com ([fe80::8459:85d:30f8:53e5%13]) with mapi id 15.20.2989.000; Mon, 27 Apr 2020 03:01:42 +0000 From: Praveen Balasubramanian To: Martin Duke , "tcpm@ietf.org Extensions" Thread-Topic: [EXTERNAL] [tcpm] Review: draft-balasubramanian-tcpm-hystartplusplus-01 Thread-Index: AQHV5G/QnZcSwFUa+E2KZLTsf7pwlKggULfw Date: Mon, 27 Apr 2020 03:01:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-27T03:01:41.1427938Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=66fc8c08-2fe5-4690-8f7f-10e7ce0b0260; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:1:95d7:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a3433a39-2eae-4596-d0dc-08d7ea57503f x-ms-traffictypediagnostic: CO2PR00MB0181: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0386B406AA received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LVKoFlO5q5AHzzNnU7UeVXRKHyDE8+ilc5o2UvmTTWACy2z1DCatZVUuS+vhuUdtiFvjpa0UvFwr36QMifDCi9m7121oTdKJFA6XDrrgPo0fsU10ThhSEPHA5WNYM+Qm29NuUP1jnznBcyhpK10lh1+/yrz5hjrY91y4RYeNUMz4/qXU9VR2Ceyr0oIujTvJt6y3RgnHthbUfXQs4Rc6bQAa/M1AMpVO/sFR+XOLdSOi/sQqIpq8/rSYUyc/gjTY2tNFatE1SZBSRceqo4fYC4okWd+CNpRpSPBF3/JjiFpo3jVBJTXArh2LtUdadKbx1TaJv2xjIXwK9ZqF22DuOJBnl9WeqwZXmcWRxU7bDa4Q0Dqs06DOGl+QpZ/l7q5SaNcr/kvgkTla0xORk92XT7VYx1bRSij7ZwPlrWWFaziBLYig32dcdzQvdkK2onkN x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO2PR00MB0120.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(366004)(396003)(136003)(5660300002)(86362001)(478600001)(9686003)(8676002)(66946007)(2906002)(82950400001)(186003)(66446008)(64756008)(66556008)(66476007)(66574012)(76116006)(6506007)(53546011)(7696005)(10290500003)(82960400001)(33656002)(8990500004)(55016002)(52536014)(316002)(8936002)(110136005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: UvU08LvScuwWr+Z/+B1rTLBpzrKGXsX+lxAo66WQPB1IROau7k7bhyN0xFX5A+LRhO0kVaT9NULh0Rwur81OP3PKBSzcl7Wb2UwyoKpZ8yJnQNX2IGwnqfHgIxRO55IMrvQzL6Sawc5zrfl0n+jPAtGBW02lZdPvaXHL7Otzm4KgeJVEkenHTszX8VIJO4f7zLzma//bW7/2rBOk1Hc4unYovY9N/NGi5ZvZMJ/9WkXRVdDAVu92j8Kt2q92r7PeM1cGc7vzKzx0s1suQe4ditTgZL/MXuCcmGBPaDAY7GZZnd/y+qxSpTA31yuhz0koAWLGJUyUo7Myl6uxiDhurnUojY6zvnoyFW7bjBHehffdB01MeEPwIrUgQrIVTWIX3/mHDGtB3AEf7c18k71lZ+R6Yi8LP7ZIgEKJ3T6+Q1cVtQTxTc9SGOmya08BqmACqxsM/0XH0yi99Wj84MYtpfwBavVMeYcnrZtaGxB4nS50X6fsrGbJUED/mlBCOZbYPLoxS4k9WYnOs+JXCrsSiXs9Ijfp12OiAWiB/kMImSubNjqj6erGGV9qolkYRKnOWY/s2hRrMzdSIEst6WTP/hyAkBWV8lEzFnWj0WyrYNw/wLgcBNn9BDXfMUsOefbU5698P1EBxP2YStlBKM33BHfSrFVwzZ+ZBIYzcbV4v4gKQTVx9kus8MteU3EHh2mBugGNJBxxvOWFTAqtfoWCgjoFFz5kzleBXPx9puSwhO92IZReI1sBwHFaTrrami8DTwjGZ5zaaivKq6ZYbaPjmyiJWeydS0+yjIUejLDQp7NbAVrF6jvBkqmd+S5h6WEhOip5zicCc1WxYC8gRn/cwk5lqW1Ae1z7MBU7Ft+b02E= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO2PR00MB01203A3F155DE5A8071997ABB6AF0CO2PR00MB0120namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO2PR00MB0120.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3433a39-2eae-4596-d0dc-08d7ea57503f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 03:01:42.3789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YKcb4wHYj/LLvl/APO3GUfNKxkS3aC3d1C3g419rGFx3vBvYZ0a/Lr2wlzE18nxU/NYd8L+wrIqYrbc87iOrY6P0tg0eg1mCd00w4qcQogU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0181 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Review: draft-balasubramanian-tcpm-hystartplusplus-01 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, 27 Apr 2020 03:02:03 -0000 --_000_CO2PR00MB01203A3F155DE5A8071997ABB6AF0CO2PR00MB0120namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmV2aWV3IE1hcnRpbiEgU29ycnkgZm9yIHRoZSByZWFsbHkgbG9uZyBk ZWxheSBpbiByZXNwb25zZS4gSnVzdCBwdWJsaXNoZWQgdmVyc2lvbiAwMy4gQ29tbWVudHMgaW5s aW5lIHByZWZpeGVkIGJ5ID4+Lg0KDQpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBNYXJ0aW4gRHVrZQ0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDE1LCAy MDIwIDY6MjAgUE0NClRvOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbRVhURVJOQUxdIFt0Y3BtXSBSZXZpZXc6IGRyYWZ0LWJhbGFzdXJhbWFuaWFu LXRjcG0taHlzdGFydHBsdXNwbHVzLTAxDQoNCg0KSGkgUHJhdmVlbiwNCg0KVGhhbmtzIGZvciB3 cml0aW5nIHRoaXMgdXAuIEl0J3MgZ3JlYXQgdG8gaGVhciB3aGF0J3MgYWN0dWFsbHkgaGFwcGVu aW5nIG91dCB0aGVyZSB3aXRoIG1ham9yIGltcGxlbWVudGF0aW9ucy4NCg0KMS4gSSB0aGluayB0 aGlzIGRyYWZ0IGhhcyBhIHNvbWV3aGF0IHVuY29tZm9ydGFibGUgcmVsYXRpb25zaGlwIHdpdGgg QUJDIChSRkMgMzQ2NSksIHdoaWNoIGZvciBzb21lIHJlYXNvbiBpcyBzdGlsbCBFeHBlcmltZW50 YWwuIEluIGVhY2ggZGVzY3JpcHRpb24gb2YgU2xvdyBTdGFydCAoU2VjIDEgYW5kIDMuMikgeW91 IHNheSBvbmUgTVNTIHBlciBhY2ssIHdoaWNoIGlzIHRoZSBub24tQUJDIFJlbm8gYmVoYXZpb3Iu IEJ1dCB0aGVuIHRoZSBhY3R1YWwgTFNTIGFsZ29yaXRobSB1c2VzIGJ5dGVzIGNvdW50ZWQuDQoN Cj4+IFdpbmRvd3MgVENQIGRvZXMgdXNlIEFCQyBidXQgd2l0aCBhIGxpbWl0IEwgdmFsdWUgdGhh dOKAmXMgZGlmZmVyZW50IHRoYW4gUkZDIDM0NjUuICBXZSBoYXZlIGluY29ycG9yYXRlZCBzb21l IHRleHQgdGhhdCBzdWdnZXN0cyB1c2Ugb2YgQUJDIGFsb25nIHdpdGggSHlTdGFydCsrLiBJIGFn cmVlIHRoYXQgaXQgaXMgcXVpdGUgc3RyYW5nZSB0aGF0IEFCQyBpcyBleHBlcmltZW50YWwuDQoN Ck5vdGUgdGhhdCBmb3IgYSBub24tQUJDIGltcGxlbWVudGF0aW9uIHRoYXQgYWxzbyB1c2VzIEh5 U3RhcnQrKywgdGhpcyBtZWFucyBhbiBMU1NfRElWSVNPUiBhcyBsb3cgYXMgMC41IGNhbiBjYXVz ZSBMU1MgdG8gYmUgKm1vcmUqIGFnZ3Jlc3NpdmUgdGhhbiByZWd1bGFyIHNsb3cgc3RhcnQgaWYg dGhlIHJlY2VpdmVyIGFja3MgZXZlcnkgb3RoZXIgcGFja2V0LiBJbiB0aGUgbm9uLVJGQyBidXQg Y29tbW9uIGNhc2Ugd2hlcmUgQUNLcyBhcmUgYWdncmVnYXRlZCBldmVuIG1vcmUgYWdncmVzc2l2 ZWx5LCBMU1MgY2FuIGJlIG1vcmUgYWdncmVzc2l2ZSB0aGFuIHNsb3cgc3RhcnQgZm9yIGFyYml0 cmFyaWx5IGxvdyBkaXZpc29yIHZhbHVlcy4gSSdtIG5vdCBzdXJlIHRoZSBkZXNpZ24gaGFzIHRv IGNoYW5nZSwgYnV0IHRoZXJlIG91Z2h0IHRvIGJlIHNvbWUgZGlzY3Vzc2lvbiBvZiB0aGVzZSBj b25zaWRlcmF0aW9ucy4NCg0KMi4gaW4gc2VjdGlvbiAzLjIsIHlvdSBzZXQgdGhlIHNzdGhyZXNo IHRvIGN3bmQgdXBvbiBlbnRlcmluZyBMU1MuIEJ1dCB0aGVuIGxhdGVyIHlvdSBzYXkgIkh5U3Rh cnQrKyBlbmRzIHdoZW4gY3duZCBleGNlZWRzIHNzdGhyZXNoLi4uIiB3aGljaCBieSBkZWZpbml0 aW9uIGlzIGltbWVkaWF0ZWx5LiBJIHRoaW5rIHlvdSBtZWFuIHRoZSBub3JtYWwgUmVuby9DdWJp YyBzc3RocmVzaDsgcGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaW52ZW50IGEgbmV3IG5h bWUgZm9yIHRoZSB2YWx1ZSB0aGF0IGlzIHVzZWQgaW4gY29tcHV0aW5nIEsuDQoNCj4+IFRoYXQg d2FzIGEgbWlzdGFrZS4gVGhpcyBpcyBub3cgZml4ZWQgdG8gc2F5IHRoYXQgSHlTdGFydCsrIG9u bHkgZW5kcyB1cG9uIG9ic2VydmluZyBhIGNvbmdlc3Rpb24gc2lnbmFsLg0KDQpTaW1pbGFybHks IEkgZG9uJ3QgYmVsaWV2ZSBNSU5fU1NUSFJFU0ggaGFzIGFueSByZWxhdGlvbnNoaXAgdG8gdGhl IGNvbnZlbnRpb25hbCBzc3RocmVzaCAoaS5lLiBpdCBpcyBub3QgYSBtaW5pbXVtKSBhbmQgdGhl cmVmb3JlIHNob3VsZCBhbHNvIGJlIHJlbmFtZWQuDQoNCj4+IFRoYXTigJlzIGZhaXIuIE5vdyBy ZW5hbWVkIHRvIExPV19DV05ELg0KDQozLiBTZWN0aW9uIDMuMyBjb3VsZCB1c2Ugc29tZSBmdXJ0 aGVyIGNvbnNpZGVyYXRpb25zIGZvciBzZXR0aW5nIHRoZXNlIHBhcmFtZXRlcnMuIEluIHBhcnRp Y3VsYXIsIHZhbHVlcyBvZiBMU1NfRElWSVNPUiA+IDEgd2lsbCBiZSBtb3JlIGFnZ3Jlc3NpdmUg dGhhbiBzbG93IHN0YXJ0LCBhdCBsZWFzdCBmb3IgbG93IHZhbHVlcyBvZiBjd25kL3NzdGhyZXNo LiBEZXBlbmRpbmcgb24gdGhlIHJlc3VsdCBvZiAjMSBhYm92ZSwgdGhlIHdhcm5pbmcgbWF5IG5l ZWQgdG8gYmUgZm9yIGEgbG93ZXIgdmFsdWUuDQoNCj4+IEFkZGVkIHRleHQgdG8gc3VnZ2VzdCB0 aGF0IHZhbHVlcyBncmVhdGVyIHRoYW4gMC41ICh2YWx1ZSBzdWdnZXN0ZWQgaW4gdGhlIG9yaWdp bmFsIExTUyBSRkMpIHNob3VsZCBub3QgYmUgdXNlZC4NCg0KNC4gVGhvdWdoIG5vdCBuZWNlc3Nh cnkgdG8gbWFrZSB0aGlzIGRyYWZ0IHdvcnRod2hpbGUsIHNvbWUgZGF0YSBmcm9tIE1pY3Jvc29m dCdzIGRlcGxveW1lbnQgc2hvd2luZyB0aGUgdmFsdWUgb2YgdGhpcyB3b3VsZCBiZSBoZWxwZnVs LiBJZiBJIHdlcmUgdG8gdHJ5IHRvIHNlbGwgdGhpcyBmZWF0dXJlIHRvIG91ciBjdXN0b21lcnMs IHRoZXkgd291bGQgcHJvYmFibHkgd2FudCB0byBzZWUgdGhhdCBpdCB3YXMgcHJvdmlkaW5nIGJl bmVmaXRzIHRvIGxhcmdlIHRyYWZmaWMgZ2VuZXJhdG9ycyByYXRoZXIgdGhhbiBiYWNraW5nIG9m ZiBmb3IgdGhlIGdvb2Qgb2YgdGhlIGludGVybmV0LiBJbiBwYXJ0aWN1bGFyLCBJIHdvbmRlciB3 aGV0aGVyIFJlbm8vQ3ViaWMgaXMgZmFpciB0byBIeXN0YXJ0KysgYXMgcmVndWxhciBzbG93IHN0 YXJ0IHdvdWxkIHNlZW0gdG8gY2F1c2UgTFNTIHRvIGN1dCB0aGUgdGhyb3R0bGUuDQoNCj4+IFdl IHByZXNlbnRlZCBsYWIgbWVhc3VyZW1lbnQgZGF0YSBhdCB0aGUgbGFzdCBJRVRGLiBXZSBhcmUg aW4gdGhlIHByb2Nlc3Mgb2YgZG9pbmcgc29tZSBBL0IgZXhwZXJpbWVudHMgYXQgc2NhbGUgd2l0 aCByZWFsIHdvcmxkIHdvcmtsb2Fkcy4gV2UgZGlkIGZhaXJuZXNzIGNvbXBhcmlzb25zIGluIG91 ciBsYWIgbWVhc3VyZW1lbnRzIGJldHdlZW4gSHlzdGFydCBhbmQgbm9uLUh5c3RhcnQgYW5kIHdl IGRpZG7igJl0IHNlZSBhbnkgcHJvYmxlbXMuDQoNCk5pdHM6DQotIFBsZWFzZSBzcGVsbCBvdXQg U01TUyBiZWZvcmUgdXNpbmcgaXQuDQoNCj4+IERvbmUNCg0KLSBUaXRsZSBvZiAzLjM6IHMvQ29u c3RhbnQvQ29uc3RhbnRzDQoNCj4+IEZpeGVkDQoNCg0KLSAzLjMuIFlvdSBhcmUgbGl0dGxlIHNs b3BweSB3aXRoIHVuaXRzLiBNSU5fU1NUSFJFU0ggaXMgY2xlYXJseSBtZWFzdXJlZCBpbiBieXRl cyBpbiBTZWMgMy4yIGJ1dCBpcyByZXBvcnRlZCBpbiBzZWdtZW50cyBpbiB0aGlzIHNlY3Rpb24u DQo+PiBGYWlyLiBGaXhlZCBMT1dfQ1dORCB0byBiZSBpbiBwYWNrZXRzIGFuZCBmaXhlZCB0aGUg ZXF1YXRpb24gdG8gdXNlIHRoZSBTTVNTIG11bHRpcGxpZXIuDQo= --_000_CO2PR00MB01203A3F155DE5A8071997ABB6AF0CO2PR00MB0120namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9y IHRoZSByZXZpZXcgTWFydGluISBTb3JyeSBmb3IgdGhlIHJlYWxseSBsb25nIGRlbGF5IGluIHJl c3BvbnNlLiBKdXN0IHB1Ymxpc2hlZCB2ZXJzaW9uIDAzLiBDb21tZW50cyBpbmxpbmUgcHJlZml4 ZWQgYnkgJmd0OyZndDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB0Y3Bt ICZsdDt0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpNYXJ0 aW4gRHVrZTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMTUsIDIwMjAgNjoy MCBQTTxicj4NCjxiPlRvOjwvYj4gdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zICZsdDt0Y3BtQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFt0Y3BtXSBSZXZpZXc6 IGRyYWZ0LWJhbGFzdXJhbWFuaWFuLXRjcG0taHlzdGFydHBsdXNwbHVzLTAxPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkhpIFByYXZlZW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDoxMi4wcHQ7bWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzIGZvciB3cml0aW5nIHRoaXMgdXAuIEl0J3MgZ3JlYXQgdG8gaGVh ciB3aGF0J3MgYWN0dWFsbHkgaGFwcGVuaW5nIG91dCB0aGVyZSB3aXRoIG1ham9yIGltcGxlbWVu dGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+MS4gSSB0aGlu ayB0aGlzIGRyYWZ0IGhhcyBhIHNvbWV3aGF0IHVuY29tZm9ydGFibGUgcmVsYXRpb25zaGlwIHdp dGggQUJDIChSRkMgMzQ2NSksIHdoaWNoIGZvciBzb21lIHJlYXNvbiBpcyBzdGlsbCBFeHBlcmlt ZW50YWwuIEluIGVhY2ggZGVzY3JpcHRpb24gb2YgU2xvdyBTdGFydCAoU2VjIDEgYW5kDQogMy4y KSB5b3Ugc2F5IG9uZSBNU1MgcGVyIGFjaywgd2hpY2ggaXMgdGhlIG5vbi1BQkMgUmVubyBiZWhh dmlvci4gQnV0IHRoZW4gdGhlIGFjdHVhbCBMU1MgYWxnb3JpdGhtIHVzZXMgYnl0ZXMgY291bnRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsmZ3Q7IFdpbmRvd3MgVENQIGRvZXMgdXNlIEFCQyBidXQgd2l0aCBh IGxpbWl0IEwgdmFsdWUgdGhhdOKAmXMgZGlmZmVyZW50IHRoYW4gUkZDIDM0NjUuJm5ic3A7IFdl IGhhdmUgaW5jb3Jwb3JhdGVkIHNvbWUgdGV4dCB0aGF0IHN1Z2dlc3RzIHVzZSBvZiBBQkMgYWxv bmcgd2l0aCBIeVN0YXJ0JiM0MzsmIzQzOy4gSSBhZ3JlZSB0aGF0IGl0IGlzIHF1aXRlIHN0cmFu Z2UgdGhhdCBBQkMgaXMgZXhwZXJpbWVudGFsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdGUgdGhhdCBmb3IgYSBub24tQUJDIGltcGxlbWVu dGF0aW9uIHRoYXQgYWxzbyB1c2VzIEh5U3RhcnQmIzQzOyYjNDM7LCB0aGlzIG1lYW5zIGFuIExT U19ESVZJU09SIGFzIGxvdyBhcyAwLjUgY2FuIGNhdXNlIExTUyB0byBiZSAqbW9yZSogYWdncmVz c2l2ZSB0aGFuIHJlZ3VsYXIgc2xvdyBzdGFydCBpZiB0aGUgcmVjZWl2ZXINCiBhY2tzIGV2ZXJ5 IG90aGVyIHBhY2tldC4gSW4gdGhlIG5vbi1SRkMgYnV0IGNvbW1vbiBjYXNlIHdoZXJlIEFDS3Mg YXJlIGFnZ3JlZ2F0ZWQgZXZlbiBtb3JlIGFnZ3Jlc3NpdmVseSwgTFNTIGNhbiBiZSBtb3JlIGFn Z3Jlc3NpdmUgdGhhbiBzbG93IHN0YXJ0IGZvciBhcmJpdHJhcmlseSBsb3cgZGl2aXNvciB2YWx1 ZXMuIEknbSBub3Qgc3VyZSB0aGUgZGVzaWduIGhhcyB0byBjaGFuZ2UsIGJ1dCB0aGVyZSBvdWdo dCB0byBiZSBzb21lIGRpc2N1c3Npb24NCiBvZiB0aGVzZSBjb25zaWRlcmF0aW9ucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjIuIGluIHNlY3Rpb24gMy4y LCB5b3Ugc2V0IHRoZSBzc3RocmVzaCB0byBjd25kIHVwb24gZW50ZXJpbmcgTFNTLiBCdXQgdGhl biBsYXRlciB5b3Ugc2F5ICZxdW90O0h5U3RhcnQmIzQzOyYjNDM7IGVuZHMgd2hlbiBjd25kIGV4 Y2VlZHMgc3N0aHJlc2guLi4mcXVvdDsgd2hpY2ggYnkgZGVmaW5pdGlvbiBpcyBpbW1lZGlhdGVs eS4gSQ0KIHRoaW5rIHlvdSBtZWFuIHRoZSBub3JtYWwgUmVuby9DdWJpYyBzc3RocmVzaDsgcGVy aGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaW52ZW50IGEgbmV3IG5hbWUgZm9yIHRoZSB2YWx1 ZSB0aGF0IGlzIHVzZWQgaW4gY29tcHV0aW5nIEsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBUaGF0IHdh cyBhIG1pc3Rha2UuIFRoaXMgaXMgbm93IGZpeGVkIHRvIHNheSB0aGF0IEh5U3RhcnQmIzQzOyYj NDM7IG9ubHkgZW5kcyB1cG9uIG9ic2VydmluZyBhIGNvbmdlc3Rpb24gc2lnbmFsLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNpbWlsYXJseSwg SSBkb24ndCBiZWxpZXZlIE1JTl9TU1RIUkVTSCBoYXMgYW55IHJlbGF0aW9uc2hpcCB0byB0aGUg Y29udmVudGlvbmFsIHNzdGhyZXNoIChpLmUuIGl0IGlzIG5vdCBhIG1pbmltdW0pIGFuZCB0aGVy ZWZvcmUgc2hvdWxkIGFsc28gYmUgcmVuYW1lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsg VGhhdOKAmXMgZmFpci4gTm93IHJlbmFtZWQgdG8gTE9XX0NXTkQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+My4gU2VjdGlvbiAzLjMgY291bGQg dXNlIHNvbWUgZnVydGhlciBjb25zaWRlcmF0aW9ucyBmb3Igc2V0dGluZyB0aGVzZSBwYXJhbWV0 ZXJzLiBJbiBwYXJ0aWN1bGFyLCB2YWx1ZXMgb2YgTFNTX0RJVklTT1IgJmd0OyAxIHdpbGwgYmUg bW9yZSBhZ2dyZXNzaXZlIHRoYW4gc2xvdyBzdGFydCwgYXQgbGVhc3QgZm9yDQogbG93IHZhbHVl cyBvZiBjd25kL3NzdGhyZXNoLiBEZXBlbmRpbmcgb24gdGhlIHJlc3VsdCBvZiAjMSBhYm92ZSwg dGhlIHdhcm5pbmcgbWF5IG5lZWQgdG8gYmUgZm9yIGEgbG93ZXIgdmFsdWUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jmd0OyBBZGRlZCB0ZXh0IHRvIHN1Z2dlc3QgdGhhdCB2YWx1ZXMgZ3JlYXRlciB0aGFuIDAu NSAodmFsdWUgc3VnZ2VzdGVkIGluIHRoZSBvcmlnaW5hbCBMU1MgUkZDKSBzaG91bGQgbm90IGJl IHVzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+NC4gVGhvdWdoIG5vdCBuZWNlc3NhcnkgdG8gbWFrZSB0aGlzIGRyYWZ0IHdvcnRod2hpbGUs IHNvbWUgZGF0YSBmcm9tIE1pY3Jvc29mdCdzIGRlcGxveW1lbnQgc2hvd2luZyB0aGUgdmFsdWUg b2YgdGhpcyB3b3VsZCBiZSBoZWxwZnVsLiBJZiBJIHdlcmUgdG8gdHJ5IHRvIHNlbGwgdGhpcyBm ZWF0dXJlDQogdG8gb3VyIGN1c3RvbWVycywgdGhleSB3b3VsZCBwcm9iYWJseSB3YW50IHRvIHNl ZSB0aGF0IGl0IHdhcyBwcm92aWRpbmcgYmVuZWZpdHMgdG8gbGFyZ2UgdHJhZmZpYyBnZW5lcmF0 b3JzIHJhdGhlciB0aGFuIGJhY2tpbmcgb2ZmIGZvciB0aGUgZ29vZCBvZiB0aGUgaW50ZXJuZXQu IEluIHBhcnRpY3VsYXIsIEkgd29uZGVyIHdoZXRoZXIgUmVuby9DdWJpYyBpcyBmYWlyIHRvIEh5 c3RhcnQmIzQzOyYjNDM7IGFzIHJlZ3VsYXIgc2xvdyBzdGFydCB3b3VsZCBzZWVtDQogdG8gY2F1 c2UgTFNTIHRvIGN1dCB0aGUgdGhyb3R0bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBXZSBwcmVzZW50 ZWQgbGFiIG1lYXN1cmVtZW50IGRhdGEgYXQgdGhlIGxhc3QgSUVURi4gV2UgYXJlIGluIHRoZSBw cm9jZXNzIG9mIGRvaW5nIHNvbWUgQS9CIGV4cGVyaW1lbnRzIGF0IHNjYWxlIHdpdGggcmVhbCB3 b3JsZCB3b3JrbG9hZHMuIFdlIGRpZCBmYWlybmVzcyBjb21wYXJpc29ucyBpbiBvdXIgbGFiIG1l YXN1cmVtZW50cyBiZXR3ZWVuIEh5c3RhcnQgYW5kIG5vbi1IeXN0YXJ0IGFuZCB3ZSBkaWRu4oCZ dA0KIHNlZSBhbnkgcHJvYmxlbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Tml0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0gUGxlYXNlIHNwZWxsIG91 dCBTTVNTIGJlZm9yZSB1c2luZyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsmZ3Q7IERvbmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSBUaXRsZSBvZiAzLjM6IHMvQ29uc3RhbnQv Q29uc3RhbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBGaXhlZDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSAzLjMuIFlvdSBhcmUgbGl0 dGxlIHNsb3BweSB3aXRoIHVuaXRzLiBNSU5fU1NUSFJFU0ggaXMgY2xlYXJseSBtZWFzdXJlZCBp biBieXRlcyBpbiBTZWMgMy4yIGJ1dCBpcyByZXBvcnRlZCBpbiBzZWdtZW50cyBpbiB0aGlzIHNl Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBGYWlyLiBGaXhlZCBMT1dfQ1dORCB0 byBiZSBpbiBwYWNrZXRzIGFuZCBmaXhlZCB0aGUgZXF1YXRpb24gdG8gdXNlIHRoZSBTTVNTIG11 bHRpcGxpZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CO2PR00MB01203A3F155DE5A8071997ABB6AF0CO2PR00MB0120namp_-- From nobody Mon Apr 27 14:59: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 C92CE3A0BED for ; Mon, 27 Apr 2020 14:58:58 -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 gSrWPdqNVCJY for ; Mon, 27 Apr 2020 14:58:56 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 87AF03A0BEF for ; Mon, 27 Apr 2020 14:58:56 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id u12so19180265uau.10 for ; Mon, 27 Apr 2020 14:58:56 -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=fFbFVAGVr8fG5bZ/pXSoEXe5q18oeEmj21+TFH5VyLw=; b=iTz45IJE1MKuOxl+n1Dc5raZcL2gPB9pz5+hnxbk2UcdzhoY3DTrQsozW3QguSdQOf RC/qemvsBe37RLnpn7Y+bO0wL3DWfos7pEuLad+yqJGwF/oNV3giBxytoQYizwrY6t2+ dT+gEti2nbY140ynMtRzGye7v13eJ6ZyYcki/Rgn0AQ+l2kaXLv85SuZJhMhzhUONosG yDCeO45UyzWwK1cayoLUkGWAZyBDVNiY5jJILSAw6EdSfgzQH5EL8SvOX08kQFHMkRE9 6NTB5/joY6tc/HbPAxdGkdwN0p8zWbFcNM/NYT03jgLWE16wxIHJUplkATPzNV+0mzxD tL2Q== 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=fFbFVAGVr8fG5bZ/pXSoEXe5q18oeEmj21+TFH5VyLw=; b=eViesgzuK9pIJ7Z37VY9IPqq7qKqnZoJSR1Ce/f61HL9FqIrqr4ola/TYZ7wI5PoJb 7mTjUAVmtwQ+R9nQ9JcF8ifEK6+oxg54CMIg+V61dxhEFlByy/nzIsgiTxTiXFVBB0wv RV46s+OJRQLSbr3Qoq53NmxGUEEiov/rcN5tNeEzdR0hkZBW8bzSFhis4qXguunmuPxA HCvqdDArnRSy76BDX7g+DXrY1M6xTqVugZMX8Dvoz3Xl7tLcyMQHwgkF+KwbnsJAqJyg cfQUzJcIqJebwVmSR0ePDDWHaPlsHbUJ8Ztk4ENlEzTZeeM0Upp7d+wd/yH6sXhUpnD6 z6GQ== X-Gm-Message-State: AGi0Pubwl9BAwXBsJcO0UuU6feSC0VaQG5Rk2Ogk/FDmLGHeu5KLZ7ee Y1yJZoV44iUolguJ5Lz+HysdF8VcCzjGviG38wW3ew== X-Google-Smtp-Source: APiQypJ/cU4zeD0uffWp0mS6SHfahLucZVhACysC+op2Ar6syCIxSDC/5ah+/Bsew7KCTfqzTx92Ml/y4E80B0jmLcs= X-Received: by 2002:a67:2d82:: with SMTP id t124mr18740176vst.123.1588024735058; Mon, 27 Apr 2020 14:58:55 -0700 (PDT) MIME-Version: 1.0 References: <35cbdaef-77b9-7d7d-0b73-012288f017db@erg.abdn.ac.uk> In-Reply-To: From: Yuchung Cheng Date: Mon, 27 Apr 2020 14:58:18 -0700 Message-ID: To: Martin Duke Cc: Gorry Fairhurst , Neal Cardwell , Priyaranjan Jha , draft-ietf-tcpm-rack.authors@ietf.org, "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Comment on draft-ietf-tcpm-rack 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, 27 Apr 2020 21:58:59 -0000 On Tue, Apr 7, 2020 at 1:39 PM Martin Duke wrote: > > Either is fine with me. > > BTW there's no Table of Contents in the draft either. > > On Tue, Apr 7, 2020 at 12:16 PM Gorry Fairhurst wrote: >> >> >> On 07/04/2020 19:49, Neal Cardwell wrote: >> > On Tue, Apr 7, 2020 at 12:09 PM Martin Duke wrote: >> >> Not a full review, but I may be missing something in this paragraph in Section 3: >> >> >> >> Using a threshold for counting duplicate acknowledgments (i.e., >> >> DupThresh) alone is no longer reliable because of today's prevalent >> >> reordering patterns. A common type of reordering is that the last >> >> "runt" packet of a window's worth of packet bursts gets delivered >> >> first, then the rest arrive shortly after in order. To handle this >> >> effectively, a sender would need to constantly adjust the DupThresh >> >> to the burst size; but this would risk increasing the frequency of >> >> RTOs on real losses. >> >> >> >> In the "runt" pattern you describe, would not the returning sequence be >> >> >> >> Dupack, Ack, Ack, Ack ... >> >> >> >> So that any threshold > 1 would handle this with no problems? >> >> >> >> Martin >> > Thanks, I think this point about the threshold is a good point. AFAICT >> > the "final runt packet" case was a real problem for the FACK loss >> > recovery algorithm used by Linux for many years until RACK, but this >> > case was probably not a problem for implementations that used RFC6675 >> > (since RFC6675 basically requires 3 packets SACKed above a hole to >> > mark it lost). >> > >> > To address this, what do you think about the following more general >> > text as a replacement for that paragraph: >> > >> > "Using a threshold for counting duplicate acknowledgments (i.e., >> > DupThresh) alone is no longer reliable because of today's prevalent >> > reordering. Any time at least DupThresh packets in a flight arrive out >> > of order, traditional packet-counting approaches >> > [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To >> > avoid such problems, some implementations have dynamically increased >> > the DupThresh packet count based on the measured degree of reordering >> > in sequence space; but this increases the frequency of RTOs upon real >> > losses in the common case of small flights of data." >> > >> > Thanks, >> > neal >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> >> Neil, would you accept something that doesn't inflame a discussion of >> what is prevalent and where? >> >> Such as: >> >> "Using a threshold for counting duplicate acknowledgments (i.e., >> DupThresh) alone is not reliable in the presence of significant packet >> reordering. Any time at least DupThresh packets in a flight arrive out >> of order, traditional packet-counting approaches >> [RFC5681][RFC6675][FACK] can incur spurious retransmissions. To >> avoid such problems, some implementations have dynamically increased >> the DupThresh packet count based on the measured degree of reordering >> in sequence space; but this increases the frequency of RTOs upon actual >> losses in the common case of small flights of data." looks fine. We'll take this paragraph you suggested. also we'll add a ToC >> >> - and would you allow "dynamically increased >> the DupThresh packet count (e.g., methods based on RFC5960)"? >> >> Gorry From nobody Mon Apr 27 17:30:28 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 AFD023A0A06 for ; Mon, 27 Apr 2020 17:30:21 -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 FSbyEpvAWesI for ; Mon, 27 Apr 2020 17:30:19 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 D13EE3A09DA for ; Mon, 27 Apr 2020 17:30:19 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id a10so19576554uad.7 for ; Mon, 27 Apr 2020 17:30:19 -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=nLBHTpsDXIdiC/+kG1/dL9vU4r7tln5FTWUR7hM9yeE=; b=lovkPMVfxVdUkcOqtORhgj47j/b3eRptzC8gj8QN3mjVEHuHIJZKHNcStf/SJkbn3s 2y2uC7jo3Qwl1OIHNXEEMCZLt1+cgpkeIjKlsh06hyOOEVEzX+urJLn7lvgjDQC+emy9 s3yVONg5PHSDUZWHfAbg2y+Ajv4Xx7eAVhPnNdFKSFd8L/SIE/hriBxfnhzNFjZD5Uea I+laCzQ/J/hJqsOpEFHkmnjt9QnXcBv6ViemmGcI2IN2Uc8fXEneptuQMDvqvAUkcqP+ 73aLy3GpyUmgX511i8yW3izJppZhCPOhstlAUi84d7tEHHWQP7lz8u6NpQHlFJSeGFK7 XXaA== 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=nLBHTpsDXIdiC/+kG1/dL9vU4r7tln5FTWUR7hM9yeE=; b=SonHRXax17sFIKY942j4sGwN4m8N88YR7vE5VPJUBBtQm7xIB+3TMgISO3iilgSBZ9 TXYaPhRpg1AAJrUagJySa6sxuaqUcMVXoC6DAXNDFFWmY7naPffUqrJCXfGjNWJ12m9s CnnX+s0raHH0Lp5mowl/6+5pldsu/KdLe+zWWmNduqiP2qKXu+8F+iDgQ5CW0w4DoPCF dyWQt51JvkGh8YOElVEeuf449BLiZiNocfz3b0+QooOIyIj2RbJOZoZptPoC+y1jeUsQ uMiSIclSkjUtpDKl2CwYWdBTbPdUBrGk0F3ZMxnHe+AeqVa9pFZovYmjCUKSGnYOIx7i rJOg== X-Gm-Message-State: AGi0PuaQ7FGt/XhqrlZVD+m9k9Z68pjG/u58fRM3viX7DS7hp8OUsoGM +koKhapr69lw9ry6tfn7jVPgym0EWi4kv8HW51o= X-Google-Smtp-Source: APiQypIY62qCvs4a5CuHafBm3g8EdR6OAmqY0vWfS0+ZkQ4DjpAM7BUy6NIKI5qRZLcyCTAaAeiUUjpSqbfAkc9DqO4= X-Received: by 2002:a9f:3826:: with SMTP id p35mr17972965uad.123.1588033818650; Mon, 27 Apr 2020 17:30:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junho Choi Date: Mon, 27 Apr 2020 17:29:42 -0700 Message-ID: To: Yi Huang Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a6ee3505a44eefa0" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 00:30:26 -0000 --000000000000a6ee3505a44eefa0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI, I made a PR https://github.com/cloudflare/quiche/pull/476 for implementing HyStart++ in quiche, based on draft 02. The algorithm is modified for QUIC a little (e.g. tcp sequence number vs quic packet number) but in general it's same. Best, On Tue, Apr 7, 2020 at 5:32 PM Junho Choi wrote: > Ok, thanks for clarifying! > > On Tue, Apr 7, 2020 at 5:24 PM Yi Huang wrote: > >> Yeah, it does nothing for the first round. >> >> >> >> *From:* Junho Choi >> *Sent:* Thursday, April 2, 2020 12:55 AM >> *To:* Yi Huang >> *Cc:* Praveen Balasubramanian ; tcpm@ietf.org >> *Subject:* Re: [EXTERNAL] Questions on HyStart++ draft 02 >> >> >> >> Hi Yi, >> >> >> >> Thanks. See inline for my following question. >> >> >> >> On Wed, Apr 1, 2020 at 5:04 PM Yi Huang wrote: >> >> 1. Section 4.2 -- each round is initialized as >> >> >> >> lastRoundMinRTT =3D currentRoundMinRTT >> >> currentRoundMinRTT =3D infinity >> >> rttSampleCount =3D 0 >> >> >> >> In the very beginning of the connection, what is "currentRoundMinRTT" wh= en >> >> there is no previous value? >> >> >> >> I am using current rtt (or initial rtt value) and is it ok? >> >> >> >> [Yi]: In our implementation, lastRoundMinRTT and currentRoundMinRTT are >> initialized to 0xffffffff as sentinel values. We only compare >> lastRoundMinRTT with currentRoundMinRTT when both of them are valid valu= es. >> Using currRTT seems to essentially behave the same as assigning a sentin= el >> value. >> >> >> >> So in the beginning of the connection lastRoundMinRTT is . When ack >> is received currentRoundMinRTT =3D min_rtt but >> >> lastRoundMinRTT is still . When the 1st round ends, it looks always >> doing nothing because the following if() is always false? >> >> >> >> if (currentRoundMinRTT >=3D (lastRoundMinRTT + RttThresh)) >> >> >> >> >> >> >> >> 2. Section 4.2 -- When used with cubic, CA_cwnd() is based on cubic >> algorithm I think. >> >> This means I need to do cubic variables calculation during slow start >> >> such as K and W_cubic. When is considered as a start of >> >> congestion avoidance and what W_max will be? >> >> >> >> Currently I use a start of limited slow start as a beginning of >> congestion recovery >> >> and use cwnd at the time for W_max. Is my understanding correct? >> >> >> >> [Yi]: Yes, that=E2=80=99s exactly what we do in Windows. >> >> >> >> Sound great. Thanks. >> >> >> >> Best, >> >> >> -- >> >> Junho Choi > >> > >> > > > -- > Junho Choi > --=20 Junho Choi --000000000000a6ee3505a44eefa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, I made a PR https://github.com/cloudflare/quiche/pull/476 for= implementing HyStart++ in quiche, based on draft 02.
The algorit= hm is modified for QUIC a little (e.g. tcp sequence number vs quic packet n= umber) but in general it's same.

Best,
=

On Tue, Apr 7, 2020 at 5:32 PM Junho Choi <junho.choi@gmail.com> wrote:
Ok, thanks for clarif= ying!

On Tue, Apr 7, 2020 at 5:24 PM Yi Huang <huanyi@microsoft.com> wrote:
=

Yeah, it does nothing for the first round.=

=C2=A0

From: Junho Choi <junho.choi@gmail.com>
Sent: Thursday, April 2, 2020 12:55 AM
To: Yi Huang <huanyi@microsoft.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; tcpm@ietf.org
Subject: Re: [EXTERNAL] Questions on HyStart++ draft 02

=C2=A0

Hi Yi,

=C2=A0

Thanks. See inline for my following question.=

=C2=A0

On Wed, Apr 1, 2020 at 5:04 PM Yi Huang <huanyi@microsoft.com= > wrote:

1. Section 4.2 -- each round is initialized as

=C2=A0

=C2=A0 =C2=A0lastRoundMinRTT =3D currentRoundMinRTT<= u>

=C2=A0 =C2=A0currentRoundMinRTT =3D infinity<= u>

=C2=A0 =C2=A0rttSampleCount =3D 0

=C2=A0

In the very beginning of the connection, what is &qu= ot;currentRoundMinRTT" when

there is no previous value?

=C2=A0

I am using current rtt (or initial rtt value) and is= it ok?

=C2=A0

[Yi]: In our implementation, lastRoundMinRTT and cur= rentRoundMinRTT are initialized to 0xffffffff as sentinel values. We only c= ompare lastRoundMinRTT with currentRoundMinRTT when both of them are valid values. Using currRTT seems to essentially behave t= he same as assigning a sentinel value.

=C2=A0

So in the beginning of the connection lastRoundMinRT= T is <inf>. When ack is received currentRoundMinRTT =3D min_rtt but

lastRoundMinRTT is still <inf>. When the 1st r= ound ends, it looks always doing nothing because the following if() is alwa= ys false?

=C2=A0

=C2=A0 if (currentRoundMinRTT >=3D (lastRoundMinR= TT + RttThresh))

=C2=A0

=C2=A0

=C2=A0

2. Section 4.2 -- When used with cubic, CA_cwnd() is= based on cubic algorithm I think.

=C2=A0This means I need to do cubic variables calcul= ation during slow start

=C2=A0such as K and W_cubic. When is considered as a= start of

=C2=A0congestion avoidance and what W_max will be?

=C2=A0

=C2=A0Currently I use a start of limited slow start = as a beginning of congestion recovery

=C2=A0and use cwnd at the time for W_max. Is my unde= rstanding correct?

=C2=A0

[Yi]: Yes, that=E2=80=99s exactly what we do in Wind= ows.

=C2=A0

Sound great. Thanks.

=C2=A0

Best,


--

Junho Choi <junho dot choi at gmail.com>



--
Junho Choi <junho dot choi at gmail.com>


--
Junho Choi <junho= dot choi at gmail.com&g= t;
--000000000000a6ee3505a44eefa0-- From nobody Mon Apr 27 17:42:42 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 9D9483A09EE for ; Mon, 27 Apr 2020 17:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=microsoft.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 gma90QlzisU7 for ; Mon, 27 Apr 2020 17:42:34 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650102.outbound.protection.outlook.com [40.107.65.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 1E3293A09DF for ; Mon, 27 Apr 2020 17:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DJ43DxyUKSUCp4cUM+v7O3mtbkKgz39Lt6z91UXbMX9FBExzcpSBbRbFzvMb37gRkFyZcYyvhsAq8RYM7MOF9zxOY9BtXe4eFbW3G6QWS1e8Kop2lf8nkIbKHdLYdJnGkkKcMer0sl/qLUMARVePOLCAre/GEZ+UDEFTuQsuBcHqQJ/2LgRUZ+ipaj75q5K6bKXddvKgQUEdkn2KnG/IVevvVY+s2pwC9XTxsWbR2LwLt4XKOkQXER/FO/uQPn6/1UYPPSJG37nzqoAoWeX1gTsPGZ8TAHmV0QtSxIzxh/MEI1rjBFhIehqwTtUzQgcEFT6skWDp1GdlFPVqI8Z+sQ== 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=Oh2rzolOD2ZUHzNhC0uSi/FwBTjKwM8AQ4T/GuAVQhQ=; b=bU8Oqov9vuqbQq7K7ZWUGeBSu1Kz5ray6DVvgqFeJB6klTs5vExGbWeek/bNOFAICWu+a/h5IS7s5B5viJOHccCDHD9jPRYh2QlmSbWzYWQJlQiJ0AHqPCg2Alu+mPPAjLjdG7rrp7ooQ/76m7z9rNaP73IShWD9+cqRZpN6ar5p6W5BqnBcxwvcoP/IIXUcoM+hHZZHPe0i6wpofCUZrxD8NkrNQH0u9fV4KtvETBG1rVxEoaF5wcUV6R0lGtHtzluwN9mEqyokp9mRISyIf3YHqPjxlD9x9YM8bddVPj4v6IpwJdyMAZci7xNNNpb+6qOQZHXXrUOpC+3zQohR4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oh2rzolOD2ZUHzNhC0uSi/FwBTjKwM8AQ4T/GuAVQhQ=; b=gItKsZxxuOgpezDv793FrNxulY1Do+x+juXYiqMDDX+lrVrijKGSQDB+niqjyrBE+ChdNyR5gTXXopgVXYDVGDPKYh0WhzYoDajOSpq21/pVhHhdZuDaNGeDERkGwBRALVS+6G3HkmUKzqQhrTPqFA7QUBKCLh7hWPvvLAE6wJg= Received: from DM5PR00MB0392.namprd00.prod.outlook.com (2603:10b6:4:a0::28) by DM5PR00MB0325.namprd00.prod.outlook.com (2603:10b6:4:9f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2992.0; Tue, 28 Apr 2020 00:42:30 +0000 Received: from DM5PR00MB0392.namprd00.prod.outlook.com ([fe80::9087:2452:8a31:6981]) by DM5PR00MB0392.namprd00.prod.outlook.com ([fe80::9087:2452:8a31:6981%9]) with mapi id 15.20.2989.000; Tue, 28 Apr 2020 00:42:30 +0000 From: Yi Huang To: Junho Choi CC: Praveen Balasubramanian , "tcpm@ietf.org" , Matt Olson Thread-Topic: [EXTERNAL] Questions on HyStart++ draft 02 Thread-Index: AQHWCHuVjeyKxI/TR0GdAjicR50BCqhk60fwgACL0ACACO+DgIAAAsGAgB9t5QCAAAKEkA== Date: Tue, 28 Apr 2020 00:42:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-28T00:42:28.2464627Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4c839093-0436-47d8-9cf0-93d1901158dd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2601:600:877f:ac89:f4ce:1642:68b9:d6f4] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8b9b0c12-b82c-4a50-af3a-08d7eb0d08a1 x-ms-traffictypediagnostic: DM5PR00MB0325: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0387D64A71 received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2UFqitCHAaaWoRbwY3S88q5OUWRlgegymPeUwEtoPpmPqogepOTpGWKLpfTyQitHZLzbmLrkQbFV79dsWZdIqs/TB0FDADigxt1VQM7Z8CDk8ex7akw6ebfoK8yKOdwefZ9dR5F5RH3r27ohMB73UwYL7q2KyWQ4ZKu57HTiTkxB2Oe96ZqXevmrblUlguUmfkZwrXqXkAGB8DJQ7bIsuLO5xhTxv9xv4f9Xrl8H+YGpmCQFlL3/BJfcUMYtKVJOSyaf86V/SRmBzj4a/huEknJ7M8DU+zTJfrJmvZy8ITH99F6O4/ptBUFrMud0maIHXtJuEzJGgOxUtCMsTLV2FhMUxwTQRWeTi28Mlsqmmgvb2gy12MqHOeoYvwTV9ndUKhfzIjd3wAlnzUSpw82+8zUpoU1Bhu2xbW+VEXQezUwM6Y5f2wIQZVozWYIeh0+6axwlzr7+sa9tBlFXsZQExGBFsZQVYK4LY0kiBFcUOaoMgxDiE7+ZREH6rl2A3obhwSaQb50QBdqNbVouq30gDw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR00MB0392.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(4636009)(396003)(346002)(366004)(376002)(39860400002)(136003)(86362001)(66476007)(66946007)(71200400001)(4326008)(52536014)(9686003)(186003)(107886003)(55016002)(2906002)(8676002)(8936002)(66556008)(66446008)(76116006)(64756008)(82950400001)(33656002)(82960400001)(7696005)(54906003)(478600001)(53546011)(6506007)(8990500004)(316002)(966005)(6916009)(10290500003)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: rQzdMP7rWe2UaGsXR9fr4BL5JGRZcHijk0gYV3tmwV59wcisOEImZ5Jqg0xGM2uPeTuUBfs7LkBY8hJryvu/bkg/Qb8mb5TAlAZDm0fAdFQaXyOpC7ld4QF6Py9DjSj743dzwmakofgJ3oEjd9U13UI0CCAOi6NvTl+3/Rm3PEUDlkk8WLdLvRAXfzguN4ryGXA52xopJ7n//jkKOlYUv8NCbg++hCFigjjsla10BZO6F0d1D0t87I+MQS/c2khvlnL5uG6AbJNjklMP1Ph/3vtio1cCM3HGFzTTlPdFVu2UNtt7Fz2Vg7uF5A7BFPV0Q4G/WWJSFfrS16nJh/jYKjekgM9ISxsMlxkPU/5IfqlXQpYAHi4mlEehvG3ACZrD4I4ITvISFtfsv3D643jJZvaCdI2avetLbE6TeX8PBK92Tz7r6katgLRyfkog4g25oDwZGA+wuSDzMyJQD5TvUV95aXanJDpHMT2UJMiGSkORpxD/+vE738wdBUaifjfi7m2GUbXHGym/atAWrKmKZhMnJOVMJABaEYJiTmXsosDMCa9U9iZ8N3ctaY+4hCDrniiW18kZciLt+I3eS6nHdkViC1KCdkmgdljmSr6x6f0f2EklO8z66/BWBqWZt3dcR+y/I46MI8QAdT+Li7Y1Fbv9V6z++v2RsejeRST/h7vDJjGI1GdZrkN79KyUEEHox0EGzOjHmq2cE72FYeBJBTBr86vSW62vfaK6uXQngUPCD9qAyHwploAhTN18BSkU3WOSK6I6nCq68soiDCJXZ8JgPWL7AiShyi8jn231gQ4Ltt0uHBIBhCw4Cha/PMF4O6CZdBmUohnb7kAUQgSPL+7RR43mKIvgeUTPjPm6LWQ= Content-Type: multipart/alternative; boundary="_000_DM5PR00MB039215AA5AD1262CAC67CA15C3AC0DM5PR00MB0392namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR00MB0392.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b9b0c12-b82c-4a50-af3a-08d7eb0d08a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 00:42:30.7241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DXByrqINBpL/EHVQT/HbU+wRs8tH4W6RcGeg3M9IIe59az+yIMedt5VhesaMDz9jrqjSd0dGBotcs8Pw77VKKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0325 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Questions on HyStart++ draft 02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 00:42:39 -0000 --_000_DM5PR00MB039215AA5AD1262CAC67CA15C3AC0DM5PR00MB0392namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBleGNpdGVkIHRvIHNlZSBIeXN0YXJ0Kysgd2FzIGFkb3B0ZWQgYnkgeW91ciBRVUlDIGlt cGxlbWVudGF0aW9uLiBUaGFua3MgSnVuaG8hDQoNCkZyb206IEp1bmhvIENob2kgPGp1bmhvLmNo b2lAZ21haWwuY29tPg0KU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAyMCA1OjMwIFBNDQpUbzog WWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtF WFRFUk5BTF0gUXVlc3Rpb25zIG9uIEh5U3RhcnQrKyBkcmFmdCAwMg0KDQpGWUksIEkgbWFkZSBh IFBSIGh0dHBzOi8vZ2l0aHViLmNvbS9jbG91ZGZsYXJlL3F1aWNoZS9wdWxsLzQ3NjxodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZnaXRodWIuY29tJTJGY2xvdWRmbGFyZSUyRnF1aWNoZSUyRnB1bGwlMkY0NzYmZGF0YT0wMiU3 QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2UyZDA0ZmQxM2FjMDQzY2Y4ZGFjMDhkN2Vi MGI1NGJkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIz NjMwNjIyMDg0ODc1NyZzZGF0YT13VHVwMDJ1b2NTRVlreTV1dEIyZWltY0k4ellDbXptZnY5M1NO eUdZTVg0JTNEJnJlc2VydmVkPTA+IGZvciBpbXBsZW1lbnRpbmcgSHlTdGFydCsrIGluIHF1aWNo ZSwgYmFzZWQgb24gZHJhZnQgMDIuDQpUaGUgYWxnb3JpdGhtIGlzIG1vZGlmaWVkIGZvciBRVUlD IGEgbGl0dGxlIChlLmcuIHRjcCBzZXF1ZW5jZSBudW1iZXIgdnMgcXVpYyBwYWNrZXQgbnVtYmVy KSBidXQgaW4gZ2VuZXJhbCBpdCdzIHNhbWUuDQoNCkJlc3QsDQoNCk9uIFR1ZSwgQXByIDcsIDIw MjAgYXQgNTozMiBQTSBKdW5obyBDaG9pIDxqdW5oby5jaG9pQGdtYWlsLmNvbTxtYWlsdG86anVu aG8uY2hvaUBnbWFpbC5jb20+PiB3cm90ZToNCk9rLCB0aGFua3MgZm9yIGNsYXJpZnlpbmchDQoN Ck9uIFR1ZSwgQXByIDcsIDIwMjAgYXQgNToyNCBQTSBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29m dC5jb208bWFpbHRvOmh1YW55aUBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpZZWFoLCBpdCBkb2Vz IG5vdGhpbmcgZm9yIHRoZSBmaXJzdCByb3VuZC4NCg0KRnJvbTogSnVuaG8gQ2hvaSA8anVuaG8u Y2hvaUBnbWFpbC5jb208bWFpbHRvOmp1bmhvLmNob2lAZ21haWwuY29tPj4NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAyLCAyMDIwIDEyOjU1IEFNDQpUbzogWWkgSHVhbmcgPGh1YW55aUBtaWNyb3Nv ZnQuY29tPG1haWx0bzpodWFueWlAbWljcm9zb2Z0LmNvbT4+DQpDYzogUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+ PjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRVhU RVJOQUxdIFF1ZXN0aW9ucyBvbiBIeVN0YXJ0KysgZHJhZnQgMDINCg0KSGkgWWksDQoNClRoYW5r cy4gU2VlIGlubGluZSBmb3IgbXkgZm9sbG93aW5nIHF1ZXN0aW9uLg0KDQpPbiBXZWQsIEFwciAx LCAyMDIwIGF0IDU6MDQgUE0gWWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPG1haWx0bzpo dWFueWlAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KMS4gU2VjdGlvbiA0LjIgLS0gZWFjaCByb3Vu ZCBpcyBpbml0aWFsaXplZCBhcw0KDQogICBsYXN0Um91bmRNaW5SVFQgPSBjdXJyZW50Um91bmRN aW5SVFQNCiAgIGN1cnJlbnRSb3VuZE1pblJUVCA9IGluZmluaXR5DQogICBydHRTYW1wbGVDb3Vu dCA9IDANCg0KSW4gdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoZSBjb25uZWN0aW9uLCB3aGF0IGlz ICJjdXJyZW50Um91bmRNaW5SVFQiIHdoZW4NCnRoZXJlIGlzIG5vIHByZXZpb3VzIHZhbHVlPw0K DQpJIGFtIHVzaW5nIGN1cnJlbnQgcnR0IChvciBpbml0aWFsIHJ0dCB2YWx1ZSkgYW5kIGlzIGl0 IG9rPw0KDQpbWWldOiBJbiBvdXIgaW1wbGVtZW50YXRpb24sIGxhc3RSb3VuZE1pblJUVCBhbmQg Y3VycmVudFJvdW5kTWluUlRUIGFyZSBpbml0aWFsaXplZCB0byAweGZmZmZmZmZmIGFzIHNlbnRp bmVsIHZhbHVlcy4gV2Ugb25seSBjb21wYXJlIGxhc3RSb3VuZE1pblJUVCB3aXRoIGN1cnJlbnRS b3VuZE1pblJUVCB3aGVuIGJvdGggb2YgdGhlbSBhcmUgdmFsaWQgdmFsdWVzLiBVc2luZyBjdXJy UlRUIHNlZW1zIHRvIGVzc2VudGlhbGx5IGJlaGF2ZSB0aGUgc2FtZSBhcyBhc3NpZ25pbmcgYSBz ZW50aW5lbCB2YWx1ZS4NCg0KU28gaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgY29ubmVjdGlvbiBs YXN0Um91bmRNaW5SVFQgaXMgPGluZj4uIFdoZW4gYWNrIGlzIHJlY2VpdmVkIGN1cnJlbnRSb3Vu ZE1pblJUVCA9IG1pbl9ydHQgYnV0DQpsYXN0Um91bmRNaW5SVFQgaXMgc3RpbGwgPGluZj4uIFdo ZW4gdGhlIDFzdCByb3VuZCBlbmRzLCBpdCBsb29rcyBhbHdheXMgZG9pbmcgbm90aGluZyBiZWNh dXNlIHRoZSBmb2xsb3dpbmcgaWYoKSBpcyBhbHdheXMgZmFsc2U/DQoNCiAgaWYgKGN1cnJlbnRS b3VuZE1pblJUVCA+PSAobGFzdFJvdW5kTWluUlRUICsgUnR0VGhyZXNoKSkNCg0KDQoNCjIuIFNl Y3Rpb24gNC4yIC0tIFdoZW4gdXNlZCB3aXRoIGN1YmljLCBDQV9jd25kKCkgaXMgYmFzZWQgb24g Y3ViaWMgYWxnb3JpdGhtIEkgdGhpbmsuDQogVGhpcyBtZWFucyBJIG5lZWQgdG8gZG8gY3ViaWMg dmFyaWFibGVzIGNhbGN1bGF0aW9uIGR1cmluZyBzbG93IHN0YXJ0DQogc3VjaCBhcyBLIGFuZCBX X2N1YmljLiBXaGVuIGlzIGNvbnNpZGVyZWQgYXMgYSBzdGFydCBvZg0KIGNvbmdlc3Rpb24gYXZv aWRhbmNlIGFuZCB3aGF0IFdfbWF4IHdpbGwgYmU/DQoNCiBDdXJyZW50bHkgSSB1c2UgYSBzdGFy dCBvZiBsaW1pdGVkIHNsb3cgc3RhcnQgYXMgYSBiZWdpbm5pbmcgb2YgY29uZ2VzdGlvbiByZWNv dmVyeQ0KIGFuZCB1c2UgY3duZCBhdCB0aGUgdGltZSBmb3IgV19tYXguIElzIG15IHVuZGVyc3Rh bmRpbmcgY29ycmVjdD8NCg0KW1lpXTogWWVzLCB0aGF04oCZcyBleGFjdGx5IHdoYXQgd2UgZG8g aW4gV2luZG93cy4NCg0KU291bmQgZ3JlYXQuIFRoYW5rcy4NCg0KQmVzdCwNCg0KLS0NCkp1bmhv IENob2kgPGp1bmhvIGRvdCBjaG9pIGF0IGdtYWlsLmNvbTxodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmdtYWlsLmNvbSUyRiZk YXRhPTAyJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMwNDNjZjhk YWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MjM2MzA2MjIwODU4NzUwJnNkYXRhPWY4Y2VrSmlKeDRTNjI1b0NrYVVEVnltWGlWUGtu YWFyUlI5SXVMaHl0ZnMlM0QmcmVzZXJ2ZWQ9MD4+DQoNCg0KLS0NCkp1bmhvIENob2kgPGp1bmhv IGRvdCBjaG9pIGF0IGdtYWlsLmNvbTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmdtYWlsLmNvbSUyRiZkYXRhPTAyJTdDMDEl N0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMwNDNjZjhkYWMwOGQ3ZWIwYjU0 YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjM2MzA2 MjIwODY4NzQ1JnNkYXRhPUZIb292MzNTb0NVMURXU1paMG40RHFDTDB0UVZqQnJMYzJtR0JYTnhJ MFElM0QmcmVzZXJ2ZWQ9MD4+DQoNCg0KLS0NCkp1bmhvIENob2kgPGp1bmhvIGRvdCBjaG9pIGF0 IGdtYWlsLmNvbTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzQSUyRiUyRmdtYWlsLmNvbSUyRiZkYXRhPTAyJTdDMDElN0NodWFueWklNDBt aWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMwNDNjZjhkYWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjM2MzA2MjIwODY4NzQ1JnNk YXRhPUZIb292MzNTb0NVMURXU1paMG40RHFDTDB0UVZqQnJMYzJtR0JYTnhJMFElM0QmcmVzZXJ2 ZWQ9MD4+DQo= --_000_DM5PR00MB039215AA5AD1262CAC67CA15C3AC0DM5PR00MB0392namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGV4Y2l0ZWQgdG8gc2Vl IEh5c3RhcnQmIzQzOyYjNDM7IHdhcyBhZG9wdGVkIGJ5IHlvdXIgUVVJQyBpbXBsZW1lbnRhdGlv bi4gVGhhbmtzIEp1bmhvITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSnVuaG8gQ2hvaSAmbHQ7anVuaG8uY2hvaUBnbWFpbC5j b20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEFwcmlsIDI3LCAyMDIwIDU6MzAgUE08 YnI+DQo8Yj5Ubzo8L2I+IFlpIEh1YW5nICZsdDtodWFueWlAbWljcm9zb2Z0LmNvbSZndDs8YnI+ DQo8Yj5DYzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQu Y29tJmd0OzsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0VYVEVSTkFM XSBRdWVzdGlvbnMgb24gSHlTdGFydCYjNDM7JiM0MzsgZHJhZnQgMDI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZZSSwgSSBtYWRlIGEgUFIgPGEgaHJlZj0i aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGZ2l0aHViLmNvbSUyRmNsb3VkZmxhcmUlMkZxdWljaGUlMkZwdWxsJTJGNDc2JmFt cDtkYXRhPTAyJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMwNDNj ZjhkYWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM3MjM2MzA2MjIwODQ4NzU3JmFtcDtzZGF0YT13VHVwMDJ1b2NTRVlreTV1dEIyZWlt Y0k4ellDbXptZnY5M1NOeUdZTVg0JTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8vZ2l0aHVi LmNvbS9jbG91ZGZsYXJlL3F1aWNoZS9wdWxsLzQ3NjwvYT4gZm9yIGltcGxlbWVudGluZyBIeVN0 YXJ0JiM0MzsmIzQzOyBpbiBxdWljaGUsIGJhc2VkIG9uIGRyYWZ0IDAyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFsZ29yaXRobSBpcyBt b2RpZmllZCBmb3IgUVVJQyBhIGxpdHRsZSAoZS5nLiB0Y3Agc2VxdWVuY2UgbnVtYmVyIHZzIHF1 aWMgcGFja2V0IG51bWJlcikgYnV0IGluIGdlbmVyYWwgaXQncyBzYW1lLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEFwciA3 LCAyMDIwIGF0IDU6MzIgUE0gSnVuaG8gQ2hvaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1bmhvLmNo b2lAZ21haWwuY29tIj5qdW5oby5jaG9pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9rLCB0aGFua3MgZm9yIGNsYXJpZnlpbmchPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEFwciA3LCAyMDIwIGF0IDU6MjQgUE0gWWkgSHVhbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpodWFueWlAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pmh1YW55aUBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WWVh aCwgaXQgZG9lcyBub3RoaW5nIGZvciB0aGUgZmlyc3Qgcm91bmQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gSnVuaG8gQ2hvaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmp1bmhvLmNob2lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+anVuaG8uY2hv aUBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAy LCAyMDIwIDEyOjU1IEFNPGJyPg0KPGI+VG86PC9iPiBZaSBIdWFuZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmh1YW55aUBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHVhbnlpQG1pY3Jvc29m dC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJh dmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0VYVEVSTkFMXSBRdWVzdGlvbnMgb24gSHlTdGFydCYjNDM7JiM0MzsgZHJhZnQgMDI8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBZaSw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo YW5rcy4gU2VlIGlubGluZSBmb3IgbXkgZm9sbG93aW5nIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXByIDEsIDIwMjAg YXQgNTowNCBQTSBZaSBIdWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1YW55aUBtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+aHVhbnlpQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBj dXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4xLiBTZWN0aW9uIDQuMiAtLSBlYWNoIHJvdW5kIGlzIGluaXRpYWxpemVkIGFzPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7bGFzdFJvdW5kTWluUlRUID0gY3VycmVudFJvdW5kTWluUlRUPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAm bmJzcDtjdXJyZW50Um91bmRNaW5SVFQgPSBpbmZpbml0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7cnR0U2FtcGxlQ291 bnQgPSAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SW4gdGhlIHZlcnkgYmVnaW5uaW5nIG9mIHRoZSBjb25uZWN0aW9uLCB3 aGF0IGlzICZxdW90O2N1cnJlbnRSb3VuZE1pblJUVCZxdW90OyB3aGVuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZXJlIGlzIG5vIHByZXZp b3VzIHZhbHVlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SSBhbSB1c2luZyBjdXJyZW50IHJ0dCAob3IgaW5pdGlhbCBydHQgdmFsdWUp IGFuZCBpcyBpdCBvaz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltZaV06IEluIG91ciBp bXBsZW1lbnRhdGlvbiwgbGFzdFJvdW5kTWluUlRUIGFuZCBjdXJyZW50Um91bmRNaW5SVFQgYXJl IGluaXRpYWxpemVkIHRvIDB4ZmZmZmZmZmYgYXMgc2VudGluZWwgdmFsdWVzLiBXZSBvbmx5IGNv bXBhcmUgbGFzdFJvdW5kTWluUlRUIHdpdGggY3VycmVudFJvdW5kTWluUlRUIHdoZW4NCiBib3Ro IG9mIHRoZW0gYXJlIHZhbGlkIHZhbHVlcy4gVXNpbmcgY3VyclJUVCBzZWVtcyB0byBlc3NlbnRp YWxseSBiZWhhdmUgdGhlIHNhbWUgYXMgYXNzaWduaW5nIGEgc2VudGluZWwgdmFsdWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIGluIHRoZSBiZWdp bm5pbmcgb2YgdGhlIGNvbm5lY3Rpb24gbGFzdFJvdW5kTWluUlRUIGlzICZsdDtpbmYmZ3Q7LiBX aGVuIGFjayBpcyByZWNlaXZlZCBjdXJyZW50Um91bmRNaW5SVFQgPSBtaW5fcnR0IGJ1dDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5sYXN0Um91 bmRNaW5SVFQgaXMgc3RpbGwgJmx0O2luZiZndDsuIFdoZW4gdGhlIDFzdCByb3VuZCBlbmRzLCBp dCBsb29rcyBhbHdheXMgZG9pbmcgbm90aGluZyBiZWNhdXNlIHRoZSBmb2xsb3dpbmcgaWYoKSBp cyBhbHdheXMgZmFsc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgaWYgKGN1cnJlbnRSb3VuZE1pblJUVCAmZ3Q7PSAobGFz dFJvdW5kTWluUlRUICYjNDM7IFJ0dFRocmVzaCkpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDti b3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIw NCwyMDQsMjA0KSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjIuIFNlY3Rpb24gNC4yIC0tIFdoZW4gdXNlZCB3aXRoIGN1Ymlj LCBDQV9jd25kKCkgaXMgYmFzZWQgb24gY3ViaWMgYWxnb3JpdGhtIEkgdGhpbmsuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwO1RoaXMg bWVhbnMgSSBuZWVkIHRvIGRvIGN1YmljIHZhcmlhYmxlcyBjYWxjdWxhdGlvbiBkdXJpbmcgc2xv dyBzdGFydDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDtzdWNoIGFzIEsgYW5kIFdfY3ViaWMuIFdoZW4gaXMgY29uc2lkZXJlZCBhcyBh IHN0YXJ0IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwO2Nvbmdlc3Rpb24gYXZvaWRhbmNlIGFuZCB3aGF0IFdfbWF4IHdpbGwgYmU/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtDdXJyZW50 bHkgSSB1c2UgYSBzdGFydCBvZiBsaW1pdGVkIHNsb3cgc3RhcnQgYXMgYSBiZWdpbm5pbmcgb2Yg Y29uZ2VzdGlvbiByZWNvdmVyeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDthbmQgdXNlIGN3bmQgYXQgdGhlIHRpbWUgZm9yIFdfbWF4 LiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5bWWldOiBZZXMsIHRoYXTigJlzIGV4YWN0bHkgd2hhdCB3ZSBkbyBpbiBXaW5kb3dzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb3VuZCBncmVhdC4g VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QmVzdCw8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVuaG8g Q2hvaSAmbHQ7anVuaG8gZG90IGNob2kgYXQNCjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZ21haWwuY29tJTJG JmFtcDtkYXRhPTAyJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMw NDNjZjhkYWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM3MjM2MzA2MjIwODU4NzUwJmFtcDtzZGF0YT1mOGNla0ppSng0UzYyNW9Da2FV RFZ5bVhpVlBrbmFhclJSOUl1TGh5dGZzJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+DQpnbWFpbC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkp1bmhvIENob2kgJmx0O2p1bmhvIGRvdCBjaG9pIGF0IDxhIGhyZWY9Imh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZ21h aWwuY29tJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJk MDRmZDEzYWMwNDNjZjhkYWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzElN0MwJTdDNjM3MjM2MzA2MjIwODY4NzQ1JmFtcDtzZGF0YT1GSG9vdjMzU29D VTFEV1NaWjBuNERxQ0wwdFFWakJyTGMybUdCWE54STBRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJn ZXQ9Il9ibGFuayI+DQpnbWFpbC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1bmhvIENob2kg Jmx0O2p1bmhvIGRvdCBjaG9pIGF0IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZ21haWwuY29tJTJGJmFtcDtk YXRhPTAyJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDZTJkMDRmZDEzYWMwNDNjZjhk YWMwOGQ3ZWIwYjU0YmQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM3MjM2MzA2MjIwODY4NzQ1JmFtcDtzZGF0YT1GSG9vdjMzU29DVTFEV1NaWjBuNERxQ0ww dFFWakJyTGMybUdCWE54STBRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpn bWFpbC5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR00MB039215AA5AD1262CAC67CA15C3AC0DM5PR00MB0392namp_-- From nobody Tue Apr 28 01:40: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 ED8003A1098 for ; Tue, 28 Apr 2020 01:40:00 -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, HTML_MESSAGE=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 wIE6QylYbloI for ; Tue, 28 Apr 2020 01:39:59 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 B6BC73A1084 for ; Tue, 28 Apr 2020 01:39:59 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id s5so20520150uad.4 for ; Tue, 28 Apr 2020 01:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/CT22fBkZIkB4WJ4a+7t5K+NG77bBHGpyEfi4kvzXpE=; b=NEB+3EsWS0CmytSTh3U2uUKvml1JW5aXauUJe80WInzUfjFHaFTx+Apr4yl4LTDgkv /lS69p0mkNyB4CHFm0q0iXZoeNI0vC9hhvgUnnqqJiwzDYYVrUls0PzEniNp7hV59Jjj /awtnqEVJAdYbWq2mxaGFDnHwlLzKXwrDREpbPveRL8wrGB+hmSgpegPhqv3Z7iQqnvG 1ntfxQQfNSY7JeSLtXwFntn7e+1GwNl1VdwDJaJTSnKAzIblzNcb0Qtnx2GBXCDDz8Dc GvRcnTqYeFn7QNWVjpgLPZABNt+k4c9c2qfm6jrk4MwnS/BfhSxXGSb136+bwxgWIu/C cEbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/CT22fBkZIkB4WJ4a+7t5K+NG77bBHGpyEfi4kvzXpE=; b=sYMlpZFbRJw1iyi4Z/6KrukTP05h4Ezpp/BV3U1lcvb3JXnmvu6rA5A8ZorecJId2h WuytTtTXqudPueUV0EdqfkeZUugec9NyAy1ym8u49bWY7J8rfRSoORCSPNEUBQ7JeMfO A234XJjfthxjYfzTGeFxUQgX7jpNV1pQT47e5azG5VB0MBaXcJmNVrf5xmMyV28RM1Mg xjuvngsbiJxO8A2LSBOHcv5xt8SpiOO0hbv6NA95bEBVM8aIj2qunT0VQTyKBSNKJ7z5 CQWbWYGzbCRRofg4IFnFdq2Yz0jQmDrVBkRP5ngl7BkJBPrOp8hiRD4jZXMCtvQaYxFM Yutw== X-Gm-Message-State: AGi0Pub2ojp40d9r+szjrFBHcDhw3URCULxNq6zoIkac1o2+3Yb66wKD H5LES7EWFAzzQhB3rCiumP7C5OxzkqqwYDWiwH1G+A== X-Google-Smtp-Source: APiQypLmF7W53i/+JSjjhLvP7UpYzuDYrPAxQaw4Cku8lycZoPWn8fia4X+fvcF4ZNWfaSDoZd7Uhj3YVX76fAJoPYY= X-Received: by 2002:a67:fd69:: with SMTP id h9mr20216977vsa.129.1588063198569; Tue, 28 Apr 2020 01:39:58 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Tue, 28 Apr 2020 01:39:47 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000d4e8a705a455c6bd" Archived-At: Subject: [tcpm] comments on draft-li-tcpm-advancing-ack-for-wireless X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:40:01 -0000 --000000000000d4e8a705a455c6bd Content-Type: text/plain; charset="UTF-8" Hello, I've read the draft. I basically agree with the motivation of the draft although I have several comments. My general question is how to implement this. So, I'm wondering the following points. 1: Is this receiver only logic or do we need to negotiate between endpoints beforehand? Or, is it out-of-scope? 2: if this is receiver only logic, you might need to consider the case where sender doesn't use ABC. 3: How does receiver check BW or RTTmin? Thanks, -- Yoshi --000000000000d4e8a705a455c6bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I've read the draft. I basically agree = with the motivation of the draft although I have several comments.
My general question is how to implement this. So, I'm wondering t= he following points.

1: Is this receiver only logi= c or do we need to negotiate between endpoints beforehand? Or, is it out-of= -scope?
2: if this is receiver only logic, you might need to cons= ider the case where sender doesn't use ABC.
3: How does recei= ver check BW or RTTmin?=C2=A0

Thanks,
--=
Yoshi
--000000000000d4e8a705a455c6bd-- From nobody Tue Apr 28 01:53: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 5624D3A1109 for ; Tue, 28 Apr 2020 01:53:15 -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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GeEEMruT9GsA for ; Tue, 28 Apr 2020 01:53:11 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 108923A1101 for ; Tue, 28 Apr 2020 01:53:10 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 03S8qMPD055016; Tue, 28 Apr 2020 10:52:22 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6A33C1D53C1; Tue, 28 Apr 2020 10:52:21 +0200 (CEST) Received: from 83.53.208.128 by webmail.entel.upc.edu with HTTP; Tue, 28 Apr 2020 10:52:22 +0200 Message-ID: In-Reply-To: <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net> References: <3326ed99-b077-592b-7913-aeb2286912c4@bobbriscoe.net> <13486113479ebcb344247daedda10467.squirrel@webmail.entel.upc.edu> <3f4d3d94-24a8-4ed8-a752-ae5242907d43@gmx.at> <391035ee6f57baa407f9be225db8dfbc.squirrel@webmail.entel.upc.edu> <44192613-4e05-bffa-a810-ef261d78d190@bobbriscoe.net> <220dabb7-c4bb-d2f2-4b56-29a2de62a71c@bobbriscoe.net> Date: Tue, 28 Apr 2020 10:52:22 +0200 From: "Carles Gomez Montenegro" To: "Bob Briscoe" Cc: "tcpm IETF list" , "Jon Crowcroft" 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 dash X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Tue, 28 Apr 2020 10:52:22 +0200 (CEST) Archived-At: Subject: Re: [tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 08:53:15 -0000 Hi Bob, Thanks a lot for your further feedback below. We will update the document as per your comments after tomorrow's WG meeting. By the way, thanks for suggesting a request for WG adoption. We plan to make the request during our slot in tomorrow's meeting. Cheers, Carles > Carles, > > On 26/03/2020 14:06, Carles Gomez Montenegro wrote: >> Hi Bob, >> >> Thanks a lot once again for all your comments! >> >> As you may have seen, we just published a -01, with the aim to address >> your comments. >> >> Please find below our inline responses: >> >>> Carles & Jon, >>> >>> Yes, if the tcpm WG was prepared to consider adopting this, I'd support >>> it. >>> >>> A few comments: >>> >>> I'm not sure I would limit it to "suppression" of delayed ACKs, and I >>> don't just mean it should include releasing suppression. In many >>> circumstances the sender would be happy with less frequent ACKs than >>> the >>> receiver is generating. E.g. with high performance data transfers, 1/16 >>> would often be fine when there are hundreds of packets in flight. But, >>> because the receiver can't be sure whether the sender would suffer one >>> of the downsides to delaying ACKs, it maintains a conservatively low >>> delayed ACK ratio. >>> >>> So perhaps a better scope (and title) would be "Sender control of >>> Delayed ACKs in TCP"? >>> >>> I've added 'in TCP', because I think it's useful to make the scope >>> concrete. But I think this doc could also be useful for other transport >>> protocols, particularly QUIC. >> Agreed! >> >> We have updated accordingly the document (including the title and >> abstract). >> >>> S3.1 & S3.2 Slow start & High bit rate environments and short data >>> segments >>> >>> However, use of Delayed ACKs reduces the amount >>> of ACKs received by the sender, thus reducing the rate of cwnd >>> growth, increasing transfer time and reducing throughput, when >>> compared with sending an ACK for each incoming data segment. >>> >>> I think ABC (appropriate byte counting) allows the sender to >>> unilaterally address that concern without needing ACK Pull [RFC3465]. >> Thanks for the comment. Version -01 now reflects that ABC could be used >> to >> address the concern, while also mentioning that it remains as an >> experimental mechanism, not fully included in RFC 5681. >> >>> The reference to 'more rapidly get up to speed during slow-start >>> without >>> overshoot' is a bit opaque. Rather than "describing by reference", it >>> needs to describe the lack of ability to send patterns of packets (e.g. >>> chirps) and be able to time the gaps between the ACKs. At minimum, the >>> citation should refer to Appendix B.4, which was the mechanism proposed >>> to do ACK pull at the time. >> Agreed. We have added a more explicit description in -01, and we also >> refer to Appendix B.4. >> >>> S.3.4 Beyond classic ACK transmission behavior >>> >>> It ought to mention that many link technologies (Satellite, DOCSIS, >>> LTE, >>> WiFi, ...?) do TCP ACK thinning 'cos TCP doesn't do it itself, but it >>> improves performance (when the ACK stream becomes the bottleneck for >>> the >>> forward path, because many reverse paths have pathetic bandwidth, esp. >>> if a parallel upload is going on). >>> >>> See "ACK Scaling and Performance on AsymmetricPaths" >>> https://erg.abdn.ac.uk/~downloads/ackscaling.pdf >> Agreed. Added in -01. And thanks for the pointer! > > [BB] >                 Examples of technologies where deployments > have >                 been reported to do ACK thinning include > satellite > links, DOCSIS >                 cable networks, mobile cellular networks, > among others. > > For DOCSIS at least I know that it's not just a case of "deployments > have been reported". TCP ACK thinning is in the DOCSIS spec [DOCSIS3.1]. > > Also, I've just been talking with a colleague, who tells me that in WiFi > (sorry, don't know how widely this applies), if there are multiple TCP > ACKs for the same flow in the transmit queue, it will remove them all > except the last when it transmits the queue. Also [Kim06] includes > pseudocode for a model of WiFi ACK thinning. > > >  [DOCSIS3.1] CableLabs, "MAC and Upper Layer Protocols Interface > (MULPI) Specification, CM-SP-MULPIv3.1", Data-Over-Cable Service > Interface Specifications DOCSIS(R) 3.1, > . > > [Kim06] Hyogon Kim, Hyogon Kim, Heejo Lee, Heejo Lee, Sangmin Shin and > Inhye Kang, "On the Cross-Layer Impact of TCP ACK Thinning on IEEE > 802.11 Wireless MAC Dynamics"     DOI: 10.1109/VTCF.2006.463 In Proc. > 64th IEEE Vehicular Technology Conference, VTC 25-28 (September 2006) > > > > Nit: > s/may allow alleviating congestion on that path/ >  /may allow congestion on that path to be alleviated/ > > >> >>> 4.2. Per-segment granularity >>> >>> Between per-segment and permanent, there's per-connection suppression. >>> I'm not saying that would be any use, I'm just saying it doesn't have >>> to >>> be permanent. >> Agreed! Added in -01. >> >>> 4.4 Support for enabling generic ACK ratios >>> >>> This reminds me of a subtle additional requirement. When you move from >>> ACK pull to controlling the ACK ratio, there's an important distinction >>> between a sender's packet stopping the receiver delaying the ACK for >>> /that/ packet (as in ACK pull), vs. setting the receiver's Delayed ACK >>> policy for /that and subsequent/ packets. >>> >>> This raises the question, should the mechanism use soft state (repeated >>> in every packet), or connection state (remembered by the receiver)? >>> Which is hinted at in your section on "safe return to normal >>> operation".x >> We have added text in section 4.4, with the aim to incorporate your >> comments above. > > [BB] > >                 The desired generic ACK ratio is intended > to be in > force for the >                 current data segment, and for subsequent data > segments > (at least, >                 during a time interval of a duration that may > depend on > several >                 factors). > > I didn't mean to say "that packet and subsequent packets" should be the > only requirement. The original ACK pull pattern where the pull is just > for "that packet" is also a valid possibility. They are just different > models. If the mechanism ends up using a field in the main TCP header, > then presumably it will be sent on every packet, and therefore there's > no need to say what the behaviour should be in the absence of any > request on subsequent packets. > > >> >>> 4.10+ Extra requirement: Who's in control? >>> >>> The receiver cannot be expected to control ACKs in any way the sender >>> wants, which it will not always be able to honour anyway. So the >>> semantics have to be of a hint, not a request or a command. Then >>> there's >>> the question of whether the receiver just does what it wants, or >>> whether >>> it ought to tell the sender it's not doing what it was asked. >>> >>> It might seem that the the receiver silently not doing what it's told >>> is >>> the simple case. However,  it adds complexity to anything trying to >>> rely >>> on the behaviour (e.g. the slow start examples). >> We have added the new requirement, and have edited its content, based on >> your input. > > [BB] Thanks for picking up all my comments so willingly. > > It occurs to me that there's probably not much point in a message from > the receiver saying whether it is complying with the request or not. The > sender can detect which ACKs are arriving, so it knows the truth, > whatever the receiver says it's doing. It sort-of might be useful to > know what the receiver says it's trying to do, to know how the network > might be intervening. But, if ground truth doesn't match what the > receiver says it's doing, the sender doesn't know whether the receiver > is lying, or whether the network is thinning ACKs. > >>> A good first draft. >>> Thank you. >> Once again, thanks a lot for your comments! > > [BB] I suggest you ask the chairs how to go about asking for an adoption > call, given that ought to be able to happen on the ML given we might not > have a f2f meeting for some time. > > Cheers > > > > Bob > >> >> Best regards, >> >> Carles >> >> >>> Bob > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > From nobody Tue Apr 28 04:18:37 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 70CFB3A1377; Tue, 28 Apr 2020 04:18:34 -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, HTML_MESSAGE=0.001, SPF_HELO_FAIL=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=bobbriscoe.net 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 DlwWWlfTTBeD; Tue, 28 Apr 2020 04:18:32 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 61F533A1376; Tue, 28 Apr 2020 04:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To: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=ay7KLjKxcLrRZTCejl6YR5/fEaXbfJhIzEDyADFYAWA=; b=V+g68R5u+7YD2LpKnMbxSa3vV mZmchXUrKeWemGo5jctsufCFUBLsSB3NhexQUj8yvgZOuI0nD/flF1a4AyRctHwkG9W0AhQdW+IAq GwaOMHzvkbSrTak9nQ+phPCk+fmjjhkj+AVo6X2NokzesoMDvc7ls0UhUCVcbLs1aCD+B7ltuPYdN 4rDwztdlPUltRJiSEzn+oIX5EZw3933Z7zYgwyiLdWTjDrrn8rLEQNfDp/KUJ48TsKvx3xwKyKlPp 83RFmByqGnBfnIH8ONYcG1tHg07tTBUFVMNneH9EknEcOvyQyEeisSNSCni92BMidQPOK5Y6pAjoI xo/jJLyJA==; Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:53860 helo=[192.168.2.5]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jTOFy-000DqD-Gj; Tue, 28 Apr 2020 12:18:30 +0100 To: Michael Tuexen References: <18CF9332-2F18-4939-AADE-A275AB29BF65@fh-muenster.de> Cc: tcpm IETF list , "tcpm-chairs@ietf.org" From: Bob Briscoe Message-ID: <44b72eca-ab66-ef06-af0d-b4c19db24174@bobbriscoe.net> Date: Tue, 28 Apr 2020 12:18:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <18CF9332-2F18-4939-AADE-A275AB29BF65@fh-muenster.de> Content-Type: multipart/alternative; boundary="------------4AC816BD9C09502D285A4A30" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Agenda for upcoming interim meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 11:18:35 -0000 This is a multi-part message in MIME format. --------------4AC816BD9C09502D285A4A30 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Michael*2, Yoshi. Has any thought been given to how to arrange remote opinion gathering, e.g. the equivalent of humming? I say this in advance, because at a recent interim, the whole agenda was set up to make a decision at the end, but then the chairs didn't have a way to poll for people's positions. It was quite a large audience, so perhaps for tcpm, it will be possible for individual opinions to be voiced in some way that doesn't need to scale. I'm thinking of adoption calls in particular. I'd at least like to propose that there's an adoption call for draft-gomez-tcpm-delack-suppr-reqs (altho I haven't asked the authors whether they want that). And a WGLC for accurate-ecn and generalized-ecn would be good. Bob On 23/04/2020 21:18, Michael Tuexen wrote: > Dear all, > > the agenda of the interim meeting on Wednesday, April 29, 2020, 14:00 - 16:30 UTC > is available at: > > https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01/ > > Best regards > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------4AC816BD9C09502D285A4A30 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Michael*2, Yoshi.

Has any thought been given to how to arrange remote opinion gathering, e.g. the equivalent of humming?

I say this in advance, because at a recent interim, the whole agenda was set up to make a decision at the end, but then the chairs didn't have a way to poll for people's positions. It was quite a large audience, so perhaps for tcpm, it will be possible for individual opinions to be voiced in some way that doesn't need to scale.

I'm thinking of adoption calls in particular.
I'd at least like to propose that there's an adoption call for draft-gomez-tcpm-delack-suppr-reqs (altho I haven't asked the authors whether they want that).

And a WGLC for accurate-ecn and generalized-ecn would be good.


Bob

On 23/04/2020 21:18, Michael Tuexen wrote:
Dear all,

the agenda of the interim meeting on Wednesday, April 29, 2020, 14:00 - 16:30 UTC
is available at:

https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01/

Best regards
Michael

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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------4AC816BD9C09502D285A4A30-- From nobody Tue Apr 28 04:41:18 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 270F43A13C0; Tue, 28 Apr 2020 04:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=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 iwyhSm78rjkh; Tue, 28 Apr 2020 04:41:12 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7632C3A13BF; Tue, 28 Apr 2020 04:41:11 -0700 (PDT) Received: from mbp.fritz.box (ip4d16e760.dynamic.kabel-deutschland.de [77.22.231.96]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E38D072243809; Tue, 28 Apr 2020 13:41:07 +0200 (CEST) From: Michael Tuexen Message-Id: <7710CBFA-79E4-4B66-A7E4-9B90B4B138E4@fh-muenster.de> Content-Type: multipart/signed; boundary="Apple-Mail=_4C361A8A-DD86-41DE-BF75-2FC6786BB0D6"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 28 Apr 2020 13:41:06 +0200 In-Reply-To: <44b72eca-ab66-ef06-af0d-b4c19db24174@bobbriscoe.net> Cc: tcpm IETF list , "tcpm-chairs@ietf.org" To: Bob Briscoe References: <18CF9332-2F18-4939-AADE-A275AB29BF65@fh-muenster.de> <44b72eca-ab66-ef06-af0d-b4c19db24174@bobbriscoe.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [tcpm] Agenda for upcoming interim meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 11:41:15 -0000 --Apple-Mail=_4C361A8A-DD86-41DE-BF75-2FC6786BB0D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 28. Apr 2020, at 13:18, Bob Briscoe wrote: >=20 > Michael*2, Yoshi. >=20 > Has any thought been given to how to arrange remote opinion gathering, = e.g. the equivalent of humming? No. >=20 > I say this in advance, because at a recent interim, the whole agenda = was set up to make a decision at the end, but then the chairs didn't = have a way to poll for people's positions. It was quite a large = audience, so perhaps for tcpm, it will be possible for individual = opinions to be voiced in some way that doesn't need to scale. >=20 > I'm thinking of adoption calls in particular.=20 > I'd at least like to propose that there's an adoption call for = draft-gomez-tcpm-delack-suppr-reqs (altho I haven't asked the authors = whether they want that). I guess we will try to get some feedback from the attendees and then use = the mailing list. >=20 > And a WGLC for accurate-ecn and generalized-ecn would be good. Let's see what the state is.=20 I'm not sure we should do a WGLC before the ECN stuff is sorted out... Best regards Michael >=20 >=20 > Bob >=20 > On 23/04/2020 21:18, Michael Tuexen wrote: >> Dear all, >>=20 >> the agenda of the interim meeting on Wednesday, April 29, 2020, 14:00 = - 16:30 UTC >> is available at: >>=20 >>=20 >> https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01/ >>=20 >>=20 >> Best regards >> Michael >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >>=20 >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > --=20 > ________________________________________________________________ > Bob Briscoe =20 > http://bobbriscoe.net/ --Apple-Mail=_4C361A8A-DD86-41DE-BF75-2FC6786BB0D6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MjgxMTQxMDZaMC8GCSqGSIb3DQEJBDEiBCCJ+FizRNKSRHD8g91/L2uS+HMbpQFLXfbu524GpmLN zTCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAuuBARY22RVigWOFQ8FhslB9BqYml tpCX3bkqWlifIRCwN6ccI1jWAYOk35uqIzv4/qnolol6fzFQ7zF5WFsTiq/NLr5wO/u1Jo47lbPo h10/aUF0wlzNCDNoQbKvbOhv8Kk/t1Z5QS0fyEi/JOPeMwQSw2ANJDbhC6hVeZ4+T04QvRw5yOH2 pqyb+wEiitOlouGc3pNHI5h/wMwxrJks1w42lWqjCwH/nePZJqU/odceLoi+OhygER4RdPchqrq2 dKXgPoEv/t5MCeI+Fx6OyJBzRR0Ak83eJy0OlMGhYbbApwjfAI+q5Y77yAKqr0nwnO75CbnXtY3q P7dO1OaLMAAAAAAAAA== --Apple-Mail=_4C361A8A-DD86-41DE-BF75-2FC6786BB0D6-- From nobody Tue Apr 28 05:24:42 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 C66663A144E for ; Tue, 28 Apr 2020 05:24:40 -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_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 cWfXjH3peZcp for ; Tue, 28 Apr 2020 05:24:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 203DB3A144D for ; Tue, 28 Apr 2020 05:24:39 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E14BD805FD7FECB4FE50; Tue, 28 Apr 2020 13:24:35 +0100 (IST) Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 28 Apr 2020 13:24:35 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.64]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0487.000; Tue, 28 Apr 2020 17:53:44 +0530 From: Rahul Arvind Jadhav To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] comments on draft-li-tcpm-advancing-ack-for-wireless Thread-Index: AQHWHTirVv2SlyTYeESuVgkxMj/USqiOchCQ Date: Tue, 28 Apr 2020 12:23:44 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5E2C44AE@BLREML503-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.76.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-li-tcpm-advancing-ack-for-wireless X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 12:24:41 -0000 SGkgWW9zaGksDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBQbGVhc2UgZmluZCB0aGUgcmVz cG9uc2UgW1JKXSBpbmxpbmUuDQoNCkJlc3QsDQpSYWh1bA0KDQpGcm9tOiB0Y3BtIFttYWlsdG86 dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9zaGlmdW1pIE5pc2hpZGENClNl bnQ6IDI4IEFwcmlsIDIwMjAgMTY6NDANClRvOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRj cG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbdGNwbV0gY29tbWVudHMgb24gZHJhZnQtbGktdGNwbS1h ZHZhbmNpbmctYWNrLWZvci13aXJlbGVzcw0KDQpIZWxsbywNCkkndmUgcmVhZCB0aGUgZHJhZnQu IEkgYmFzaWNhbGx5IGFncmVlIHdpdGggdGhlIG1vdGl2YXRpb24gb2YgdGhlIGRyYWZ0IGFsdGhv dWdoIEkgaGF2ZSBzZXZlcmFsIGNvbW1lbnRzLg0KTXkgZ2VuZXJhbCBxdWVzdGlvbiBpcyBob3cg dG8gaW1wbGVtZW50IHRoaXMuIFNvLCBJJ20gd29uZGVyaW5nIHRoZSBmb2xsb3dpbmcgcG9pbnRz Lg0KDQoxOiBJcyB0aGlzIHJlY2VpdmVyIG9ubHkgbG9naWMgb3IgZG8gd2UgbmVlZCB0byBuZWdv dGlhdGUgYmV0d2VlbiBlbmRwb2ludHMgYmVmb3JlaGFuZD8gT3IsIGlzIGl0IG91dC1vZi1zY29w ZT8NCg0KW1JKXSBDdXJyZW50bHkgaXQgaXMgb3V0LW9mLXNjb3BlLiBXZSBkZXBsb3llZCB0aGlz IGluIGNvbnRleHQgdG8gYSBzcGVjaWZpYyBhcHBsaWNhdGlvbiBhc3N1bWluZyBzb21lIHNldHRp bmdzIG9uIHRoZSBzZW5kZXIvcmVjZWl2ZXIgc2lkZS4gU2V0dGluZ3Mgc3VjaCBhcyBgYmV0YWAg KHNlY3Rpb24gMy4yKSB3aGljaCBkaWN0YXRlcyBob3cgYWdncmVzc2l2ZSB0aGUgQUNLaW5nIHNo b3VsZCBiZSB3YXMgYXNzdW1lZCB0byBiZSA0IGluIG91ciB0ZXN0cy4gVGhpcyBjb3VsZCBiZSBw YXJhbWV0ZXJpemVkIGFuZCB3aWxsIGJlbmVmaXQgZXNwZWNpYWxseSB0aGUgaGlnaCBCRFAgcGF0 aHMuDQoNCjI6IGlmIHRoaXMgaXMgcmVjZWl2ZXIgb25seSBsb2dpYywgeW91IG1pZ2h0IG5lZWQg dG8gY29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgc2VuZGVyIGRvZXNuJ3QgdXNlIEFCQy4NCg0KW1JK XSBJbiBjb250ZXh0IHRvIEFCQywgd2UgZXhwZWN0IHRoYXQgdGhlIHNlbmRlciBmb2xsb3dzIHRo ZSBjd25kIGluY3JlbWVudHMgdG8gYmUgZG9uZSBhcyBzcGVjaWZpZWQgaW4gUkZDIDM0NjUuIE1v c3Qgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBhbHJlYWR5IGRvIHRoYXQuIEhvd2V2ZXIsIGFzIGNv bXBhcmVkIHRvIGRlbGF5ZWQgQUNLcyB0aGlzIGRyYWZ0IGlzIG11Y2ggbW9yZSBhZ2dyZXNzaXZl IGluIHJlZHVjaW5nIHRoZSBBQ0sgdHJhZmZpYyBhbmQgYXMgc3VjaCB0aGUgY3duZCBpbmNyZW1l bnRzIGFzIHNwZWNpZmllZCBpbiBBQkMgaXMgc3VyZWx5IGdvaW5nIHRvIHJlc3VsdCBpbiBiaWdn ZXIgYnVyc3RzIG9mIHBhY2tldHMuIFVzdWFsbHkgdGhpcyBpcyBhIGJhZCB0aGluZywgYnV0IGdp dmVuIG91ciB1c2UtY2FzZSAobG9jYWwgV2ktRmkgdXNlLWNhc2UpIHdlIGZvdW5kIHRoYXQgbGFy Z2VyIGJ1cnN0cyBhY3R1YWxseSBpbXByb3ZlZCB0aGUgZWZmaWNpZW5jeSBvZiBsb3dlciBsZXZl bCBXaS1GaSBhZ2dyZWdhdGlvbi4gTm90IGNvbnNpZGVyaW5nIEFCQyBvbiBzZW5kZXIgc2lkZSBo YXMgaW1wbGljYXRpb25zIGFuZCB3ZSB3aWxsIHRyeSB0byBhZGRyZXNzIHRoaXMgKGF0LWxlYXN0 IHN0YXRlIHRoZSBpbXBsaWNhdGlvbnMgY2xlYXJseSkuDQoNCjM6IEhvdyBkb2VzIHJlY2VpdmVy IGNoZWNrIEJXIG9yIFJUVG1pbj/CoA0KDQpbUkpdIFRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgcG9p bnQuIFRoZXJlIGlzIGFuIGltcGFjdCBvbiBCVyBhbmQgUlRUbWluIGVzdGltYXRpb24gb24gc2Vu ZGVyIHNpZGUgZXNwZWNpYWxseSB3aXRoIHRoZSBsaWtlcyBvZiBhZ2dyZXNzaXZlIEFDSyByZWR1 Y3Rpb24gdGhhdCB0aGUgZHJhZnQgc2Vla3MuIEluIHRoZSBhYnNlbmNlIG9mIGNvbnRpbnVvdXMg QUNLIGZlZWRiYWNrLCB3ZSBwcm9wb3NlIHRoYXQgdGhlIHJlY2VpdmVyIGFpZHMgdGhlIHNlbmRl cidzIFJUVG1pbiBlc3RpbWF0aW9uIChhbmQgaW4gdHVybiBCVyBlc3RpbWF0aW9uKSBieSBzZW5k aW5nIGV4cGxpY2l0IE9XRCAob25lLXdheSBkZWxheSkgbWVhc3VyZW1lbnRzLiBXZSB1bmRlcnN0 YW5kIHRoYXQgdGhpcyB3b3JrcyBvbmx5IGZvciBuZWFyLXN5bW1ldHJpYyBsaW5rcywgYnV0IHdl IHRoaW5rIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGdlbmVyYWxpemUgZnVydGhlciBhbmQgYWxs ZXZpYXRlIHRoZSByaXNrIG9mIGluYWNjdXJhdGUgUlRUbWluIGVzdGltYXRpb24uIFdlIHBsYW4g dG8gdXBkYXRlIHRoaXMgcGFydCBpbiB0aGUgbmV4dCByZXZpc2lvbiAoU2VjdGlvbiA0LjIgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXF1aWMtb3B0aW1pemluZy1hY2st aW4td2xhbi0wMCBpbiBRVUlDIFdHIGhhcyBtb3JlIGRldGFpbHMpLg0KDQo= From nobody Tue Apr 28 06:31:27 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 B1C723A1529; Tue, 28 Apr 2020 06:31:18 -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 Psb7ufr3S-nY; Tue, 28 Apr 2020 06:31:16 -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 69A403A16E6; Tue, 28 Apr 2020 06:29:52 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0588F1B000FF; Tue, 28 Apr 2020 14:29:42 +0100 (BST) To: Yuchung Cheng , Martin Duke Cc: Neal Cardwell , Priyaranjan Jha , draft-ietf-tcpm-rack.authors@ietf.org, "tcpm@ietf.org Extensions" References: <35cbdaef-77b9-7d7d-0b73-012288f017db@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: <7da00b5b-572b-8cd3-7981-2a6c11864ea1@erg.abdn.ac.uk> Date: Tue, 28 Apr 2020 14:29:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Comment on draft-ietf-tcpm-rack X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 13:31:19 -0000 Thanks, Gorry On 27/04/2020 22:58, Yuchung Cheng wrote: > On Tue, Apr 7, 2020 at 1:39 PM Martin Duke wrote: >> Either is fine with me. >> >> BTW there's no Table of Contents in the draft either. >> >> On Tue, Apr 7, 2020 at 12:16 PM Gorry Fairhurst wrote: >>> >>> On 07/04/2020 19:49, Neal Cardwell wrote: >>>> On Tue, Apr 7, 2020 at 12:09 PM Martin Duke wrote: >>>>> Not a full review, but I may be missing something in this paragraph in Section 3: >>>>> >>>>> Using a threshold for counting duplicate acknowledgments (i.e., >>>>> DupThresh) alone is no longer reliable because of today's prevalent >>>>> reordering patterns. A common type of reordering is that the last >>>>> "runt" packet of a window's worth of packet bursts gets delivered >>>>> first, then the rest arrive shortly after in order. To handle this >>>>> effectively, a sender would need to constantly adjust the DupThresh >>>>> to the burst size; but this would risk increasing the frequency of >>>>> RTOs on real losses. >>>>> >>>>> In the "runt" pattern you describe, would not the returning sequence be >>>>> >>>>> Dupack, Ack, Ack, Ack ... >>>>> >>>>> So that any threshold > 1 would handle this with no problems? >>>>> >>>>> Martin >>>> Thanks, I think this point about the threshold is a good point. AFAICT >>>> the "final runt packet" case was a real problem for the FACK loss >>>> recovery algorithm used by Linux for many years until RACK, but this >>>> case was probably not a problem for implementations that used RFC6675 >>>> (since RFC6675 basically requires 3 packets SACKed above a hole to >>>> mark it lost). >>>> >>>> To address this, what do you think about the following more general >>>> text as a replacement for that paragraph: >>>> >>>> "Using a threshold for counting duplicate acknowledgments (i.e., >>>> DupThresh) alone is no longer reliable because of today's prevalent >>>> reordering. Any time at least DupThresh packets in a flight arrive out >>>> of order, traditional packet-counting approaches >>>> [RFC5681][RFC6675][FACK] usually suffer spurious retransmissions. To >>>> avoid such problems, some implementations have dynamically increased >>>> the DupThresh packet count based on the measured degree of reordering >>>> in sequence space; but this increases the frequency of RTOs upon real >>>> losses in the common case of small flights of data." >>>> >>>> Thanks, >>>> neal >>>> >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> Neil, would you accept something that doesn't inflame a discussion of >>> what is prevalent and where? >>> >>> Such as: >>> >>> "Using a threshold for counting duplicate acknowledgments (i.e., >>> DupThresh) alone is not reliable in the presence of significant packet >>> reordering. Any time at least DupThresh packets in a flight arrive out >>> of order, traditional packet-counting approaches >>> [RFC5681][RFC6675][FACK] can incur spurious retransmissions. To >>> avoid such problems, some implementations have dynamically increased >>> the DupThresh packet count based on the measured degree of reordering >>> in sequence space; but this increases the frequency of RTOs upon actual >>> losses in the common case of small flights of data." > looks fine. We'll take this paragraph you suggested. > > also we'll add a ToC > > > >>> - and would you allow "dynamically increased >>> the DupThresh packet count (e.g., methods based on RFC5960)"? >>> >>> Gorry -- G. Fairhurst, School of Engineering From nobody Tue Apr 28 09:32:45 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 84F8D3A08E6; Tue, 28 Apr 2020 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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 q5LglHJL4uTx; Tue, 28 Apr 2020 09:32:42 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00105.outbound.protection.outlook.com [40.107.0.105]) (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 02CCD3A08E4; Tue, 28 Apr 2020 09:32:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WJVMktc9seBITPQZ4mFwG+GOEaT54Ay4cvbS+fnnN8voUuO7J6ZSLpy/BLvV6lhdQRbDkuJ7HJh6we/qTuxLCNUFYgDWjsfR5eFXhdYVNuF+zL4YFHMF5Oy/FCfX9IA2JDMqA6eWpXTS96m293j+b3PSV2d1NNMrw/v+gBOPULynZ3y6w90J9FWkC71FOLjtohPGLD4V6y48xzGOVS9JMyzLRMkxIas2XroFxCylhetzroUVqgpAQVYUjXEPYwdSvK4nPy3Scm9ZNbNpK5tu8qr8dKdXXmCDSsO7SljOu6uA+Gh+Ai3s1vPY+5Hf0xDDNPSSiYMAGH2vtyFYMbifIw== 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=GqCcn9hTJr49nR38yhf7H7vYMjC9gr9IdNJR0F609cs=; b=SzKF3WGF+rk8DdxDWGE/xNBfzS0hrxlM865xuXiw7XHHRexkkWpdy+Ek9+EKhvrzzyjoBE9vlgHjNrq/UmYNqye75ifGKZxB1T1IWdfCE6eUoXFAzatKTsmTwOCKoum+Gn0QqZDgQ/nwKsOEVqZ8A6PeXNYo2zzdj+8sLWJLxwG8pCW3CgDbejGSvXc7TBjAvzLF1fsjTk25hLsawoCYuSufnHoIz/jyp/eyur5oJqHig+WGsxzT9zMdig8B5i2oLgUz3bITMx6NYffJTC++PI2dl44qTj8T/Ts02cV4kQWPyfHITnAQKiI3iLA/LJrRrSUHc16TTxpNAL2jqc/fMA== 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=GqCcn9hTJr49nR38yhf7H7vYMjC9gr9IdNJR0F609cs=; b=LdT5XKn5Q5kTdAm0HajTAAk8migRt5B/vsvLLjLow+wqZQlYgIMD40xVXna4wdYtSPDBXq8LRpbX8NaZ/XVrDS71rxkD4Of2QFcBwV2I/4eJqbnAtpJij3NVDme6co6ADEpF9HfHLNJIw/N2gi2v4qj9o47U6LTXb20FFD3mSUo= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB4972.eurprd07.prod.outlook.com (2603:10a6:10:6b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.12; Tue, 28 Apr 2020 16:32:38 +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.2958.014; Tue, 28 Apr 2020 16:32:38 +0000 From: tom petch To: Michael Tuexen , Bob Briscoe CC: tcpm IETF list , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Agenda for upcoming interim meeting Thread-Index: AQHWHU7MUZU69Z7aOkCJqUG1UlzEc6iOaTAAgABQx6Y= Date: Tue, 28 Apr 2020 16:32:38 +0000 Message-ID: References: <18CF9332-2F18-4939-AADE-A275AB29BF65@fh-muenster.de> <44b72eca-ab66-ef06-af0d-b4c19db24174@bobbriscoe.net>, <7710CBFA-79E4-4B66-A7E4-9B90B4B138E4@fh-muenster.de> In-Reply-To: <7710CBFA-79E4-4B66-A7E4-9B90B4B138E4@fh-muenster.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fh-muenster.de; dkim=none (message not signed) header.d=none;fh-muenster.de; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0bee2e75-3bb7-4464-2d08-08d7eb91c3ad x-ms-traffictypediagnostic: DB7PR07MB4972: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0387D64A71 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hq4IKOhVxXrzkfPHqszk/GgZHyWpOHKSEqV2OUnM6TLKSsKomvNt55Z1okiwHqsm4SlfMhkKp7qdSD4SuM9XH2iLewRNOL9AYElTK1/I4nCzaMzS+9hWQJtRD3fuRy7gE2bd2Kn9lat6fCWxgu1sin6+ejBEcvWmxry4f9ooy2PTZm3P7RM6lpEFfzRyfwP0tlLJAt1MkxSqBXiWTLxpQxI04sM7SEaRrNJ9FWjvdQ0hWIOFhp6xJtNEXL4ib3b2+G4LyWxSNv9nsFQOxFuD3PTkEDaEr630/ttiqmvI9NwzH7GninXk1lrbtRV5NWJ4/S9PtBGHKgxIfXPn7g5+4bf55GoRySHIEOKXoOKjpAFMFaIraaYDL9ahR/u69ZS6UB1DSliQiwJ8FpJWfTw84sC22yqPce0svF1kIE0coT/+eHIGANtMU5Fydnjji83CCe9Kc+jTQYvbVVFHrgcIggRzbPsWhvBNlM69Xsc23qqK6AWqcwdgK47QT+o8OtesOYbY2Z2hIhLSRSUQNfCT6WuV7uJimwPPipm0pf6L7ohOJL9B5eiElX5+3iJTPXLwNDhOkJ5GORiWNJWQK4NCkM3VOuDU4HZTcIiiu1J2D0w= 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:(136003)(346002)(39860400002)(366004)(376002)(396003)(66946007)(2906002)(4326008)(54906003)(86362001)(26005)(316002)(53546011)(966005)(6506007)(8936002)(9686003)(55016002)(66446008)(64756008)(66556008)(7696005)(8676002)(91956017)(66476007)(76116006)(33656002)(5660300002)(478600001)(110136005)(186003)(71200400001)(52536014)(336755003)(18886065003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: J6VqILshRBnwiiblPlPlbuPW6Fn/QtqDXf+IKr8eW+9c9mrHVQYEqi0e5RGdDtZ+qSGhqyG1x6cbnIVtuU5BHiA3G0C54seh+z6MUD9EkGkm1UJIxuYXsKQ7a7/VYWPAY5cyvctIkiwrYTVD9ijXGJkMVst1/8khFk0//SbAHa5hSg3zPkOnqDRTxR/6yjOIZ8a/Bq2DbYbFOmDjp0LzF1eOw5a6obq2MVga7NypSLP2qeeJXJfwSxB3XZJnorLBO0ZpkG5Ng574sOI2pNds0aqWDAFjBRJxG4RSNoIw3olJCGzr6/fPPwMJr+nfPStFELPuq0xaALzoCWvLr0CE6OCgWqyOmKdbrMXruj8fOgSakT/DnS1qRUFt90Bur+19bbyykcl6Okn5+ZFxTjyZw9ldeth2kfiibOJzNAkMR3zrcYV6TyoVxMQfsoXf+F+uoUp5B9p2OwTGIan/dkKOw8L9U0RQz387VESRvCZLc57bv01eon1btonQtGNfwVimjp05QHWnDOwmwglueyElX2xnu7Wz33FyG73yUBXOaQyYj3LqX+fpvKfB0EuClqhUMneSKHsT0SHYf5cxxymXDKadN36K+OdPVIe/bPGzfaUcf/fukRYtDwkR7HgoyvHF54ypL4jyRUQ0E+3SxzLqK5zEHmYAZ8Pwgqoc97lGME8zuDR9XB8RsoLIygR0387ZrVyeIG9WrRt1S0Va7DqEzBmuhS80fhsm6Jzqm26URx717H3bGSo6oXPUP1lEka7yZ8vTK2peA2laQILUutVvQ+gtEGavqaodc72Lu2IQEtY= 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: 0bee2e75-3bb7-4464-2d08-08d7eb91c3ad X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 16:32:38.0758 (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: TTUYbn5fFcvPbH1ZMKIyCKA3T0DNOoTtLqi+hG9d1sz6Hw9yWCxajOJRZehOYFL5Rcjtlzeutc07vupWOxfFLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4972 Archived-At: Subject: Re: [tcpm] Agenda for upcoming interim meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 16:32:45 -0000 From: tcpm on behalf of Michael Tuexen =0A= Sent: 28 April 2020 12:41=0A= =0A= > On 28. Apr 2020, at 13:18, Bob Briscoe wrote:=0A= >=0A= > Michael*2, Yoshi.=0A= >=0A= > Has any thought been given to how to arrange remote opinion gathering, e.= g. the equivalent of humming?=0A= No.=0A= =0A= =0A= Michael, =0A= The Netmod WG Chair set up a virtual hum using a doodle poll although this = was used outside the time of the meeting. Perhaps it could also be used in= side=0A= Tom Petch=0A= =0A= =0A= =0A= =0A= >=0A= > I say this in advance, because at a recent interim, the whole agenda was = set up to make a decision at the end, but then the chairs didn't have a way= to poll for people's positions. It was quite a large audience, so perhaps = for tcpm, it will be possible for individual opinions to be voiced in some = way that doesn't need to scale.=0A= >=0A= > I'm thinking of adoption calls in particular.=0A= > I'd at least like to propose that there's an adoption call for draft-gome= z-tcpm-delack-suppr-reqs (altho I haven't asked the authors whether they wa= nt that).=0A= I guess we will try to get some feedback from the attendees and then use th= e mailing list.=0A= >=0A= > And a WGLC for accurate-ecn and generalized-ecn would be good.=0A= Let's see what the state is.=0A= I'm not sure we should do a WGLC before the ECN stuff is sorted out...=0A= =0A= Best regards=0A= Michael=0A= >=0A= >=0A= > Bob=0A= >=0A= > On 23/04/2020 21:18, Michael Tuexen wrote:=0A= >> Dear all,=0A= >>=0A= >> the agenda of the interim meeting on Wednesday, April 29, 2020, 14:00 - = 16:30 UTC=0A= >> is available at:=0A= >>=0A= >>=0A= >> https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01/=0A= >>=0A= >>=0A= >> Best regards=0A= >> Michael=0A= >>=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> tcpm mailing list=0A= >>=0A= >> tcpm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tcpm=0A= >=0A= > --=0A= > ________________________________________________________________=0A= > Bob Briscoe=0A= > http://bobbriscoe.net/=0A= =0A= From nobody Wed Apr 29 04:30: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 4B47B3A0D12 for ; Wed, 29 Apr 2020 04:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 kYLosQuJ_ufH for ; Wed, 29 Apr 2020 04:30:12 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E1F3A0D0A for ; Wed, 29 Apr 2020 04:30:12 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:e18b:10f8:d406:d83e] (unknown [IPv6:2a02:8109:1140:c3d:e18b:10f8:d406:d83e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6D05E7220F42E for ; Wed, 29 Apr 2020 13:30:07 +0200 (CEST) From: Michael Tuexen Content-Type: multipart/signed; boundary="Apple-Mail=_8FBECFD2-A1A1-4FE6-8A12-8E81D0A91189"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <12EEC290-52A4-40BE-A349-A08A33964480@fh-muenster.de> Date: Wed, 29 Apr 2020 13:30:06 +0200 To: tcpm IETF list X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [tcpm] TCPM Interim at 14:00 UTC 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, 29 Apr 2020 11:30:15 -0000 --Apple-Mail=_8FBECFD2-A1A1-4FE6-8A12-8E81D0A91189 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, you a reminder: today at 14:00 UTC is the TCPM interim meeting. Webex: = https://ietf.webex.com/ietf/j.php?MTID=3Dma838311f033ebe35fefacc0d50658988= Etherpad: = https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-tcpm-01?useMonosp= aceFont=3Dtrue Agenda: = https://datatracker.ietf.org/doc/agenda-interim-2020-tcpm-01-tcpm-01 Best regards Michael= --Apple-Mail=_8FBECFD2-A1A1-4FE6-8A12-8E81D0A91189 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0 MjkxMTMwMDZaMC8GCSqGSIb3DQEJBDEiBCCvQ5NSUqsvDzWfLnYdoYi+behWBzy3v1FCDZMwre6h fzCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAXTQhOlT1bJtQWFOICXocj7BwmGHd pHXFP/WvE6JRp9+uSaPVvqgcg7hKRzBqvT9MvcNpnoJl587WWBLN4wW6MPyTfb/v5sQV/XSYIM5k S3RssJotSLAgM9NzRwIXbioRCrfjLkgkeoPij9ITe+paLnemVwqlZ2ctRRcahVIUInXdm0DbYaAJ Cnt0MnlmxGnJjaaKyw7KRwuoL8O62lmxeK5WNMcLIP8ziIyZqHNgiVZmoSByf+coTbvzEbr4Poa5 lplhQtB/MAveBt8X7dxzVZuChlbDs5UgxpcFkKbHazDphWkBlPpqUlYn4F/QAIW6IusLCnXdNuY2 F4YyuoXX/AAAAAAAAA== --Apple-Mail=_8FBECFD2-A1A1-4FE6-8A12-8E81D0A91189-- From nobody Wed Apr 29 06:30:35 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 5F6F73A0F2E for ; Wed, 29 Apr 2020 06:30:33 -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 pSIfB0qfbe4i for ; Wed, 29 Apr 2020 06:30:32 -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 C6EC13A0F2D for ; Wed, 29 Apr 2020 06:30:31 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 92AD21B00115 for ; Wed, 29 Apr 2020 14:30:27 +0100 (BST) To: tcpm@ietf.org From: Gorry Fairhurst Message-ID: Date: Wed, 29 Apr 2020 14:30:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [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, 29 Apr 2020 13:30:33 -0000 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. The draft says: “An 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 <= feedback_info/(plr_data*plr_ack), where    feedback_info denotes the amount of information carried by an ACK.” - 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. - In contrast, an L that is based on target asymmetry, e.g. L=10 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 = 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? Once the cwnd, rwnd >> flow’s required BDP, the effect of L on 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: “Latency-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.”? 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. 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? One last thing I am curious about is how your proposal will interact with methods such as ACK Thinning at the network layer, I’d hope there are only positive benefits when both schemes are used. Do you have experience of this? Best wishes, Gorry Fairhurst From nobody Wed Apr 29 10:02: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 2A5AE3A1450 for ; Wed, 29 Apr 2020 10:02:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=gmx.net 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 TFEGcqfYnvQ7 for ; Wed, 29 Apr 2020 10:02:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 368723A144E for ; Wed, 29 Apr 2020 10:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588179725; bh=71xqL/9hygCM7GHO2iEYcNB03bzlwM8PqF1dz9QhaQc=; h=X-UI-Sender-Class:To:From:Subject:Date; b=TPu4B1QQMq6l/fbPpjkvX+04nBQqFEbTEgf5oYvk5IwNOqsZW06uePeiut8OTRsdk AiXbMfjJLy5C3Uq6PLAdEClcMt3QTyXpjh4+Kb9VU5W8zAmni6t5kFKAGEqK2nsJBG oAS9VE2k1epMk/TFLKpzQQlkpOrN94/c1RfKtyvo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.233.104] ([185.236.167.136]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M2f5T-1jT1Xu37Gh-004DAX; Wed, 29 Apr 2020 19:02:05 +0200 To: "tcpm@ietf.org" , Gorry Fairhurst From: "Scheffenegger, Richard" Message-ID: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> Date: Wed, 29 Apr 2020 19:02:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Yi3IB1FQyU01clMsGIK4IZ2zzLXIUz94e49jVpZebfHK0wP5U9l XWLBIfWS9q0Pii4d4DwqeFeMH+SnOnqTHd2eS/GJlEmtWXShM7GDF1ifkLQInGeMkt9FW9y gb8fX1RKdyFaOnMeXN/AbXQiQhWO7h28Eb9kHOKYvj7rmlpUUH83jXLuImv0fLZcCcDc1ed f3YnvO8FiXXfRarHz5BPQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:imiT/OzC2Ps=:8xhxVFnvpj5JTm1VeQPhwG LjFaU5XlXjIeggUzgcfamEUqlj6yofpx6xH+XaUz7kxTbzlJVT12w2kqr9Ax4OUOw67jQxTd0 8z5YANWbDMQYX4L6kt+7VJCHwM7eWXkRDaBbLrS3oDRGKEa3qZz5N/AqdaZn3sq5WxJKN1YcA k+P5MGaQwuRgkbxgc5GbfilkSjQGrNdyfc4NilDIZYL9q1t9RQY7Vz/hGuhyr9xyXgMl595Lc 5EFwuQ9OoECjtCRoPRRcuYNWQ7RjdhDQJ1VUIjBw8c6abeFCcBR2lpVtjMN1/A/Noj+cQmYON EFPKwF2zrkn2vp/GFSx/il/0T1udmkuyP4tjwvTAiohKU4oC5+o3NpxI1/7M+6rI9CnaKjwNU fd6/sM1lja/fB4RNFqtpJAwwy2cYkvNX5rtw3e/VJkssg8f9m4o39b6Zs1P9GaMTCD29yQdCb hr8voDErt2FFueMCbce3BuzdD7kXV0e7eBeHhbG6+Klt9hBBLHJyv2BXA8RDjlTkJJj2xYNvl aNjpGr2gDuGhNVp7pEpL8D8BPE16h+vZzR03TC/zJ2RXf4OuD4U0fYtGodXE0YCfqQIl15Ari 7SAsaBa37pAa7rojaoiyji+TpEB7wMHgJ2KtD/23LlIEobKm4y6jyd0cAwtQF8U6iFrr/k/OA vSqh9cFcdg55EhPpGvt/fkLioZDgwb3WFMzi+ys9QmA+EeA2wwQWlvYmQqcB8U68BMRzW1sG0 sj4ZI+nmuy11wUNs0GUDlbamLj8ZtNjD6pMYoJ6CvLrNHB9/KLsWJA03dItq7r1hJf9J56hPw jpKh4lTwTdCaid+AL434Si0P2pDz95dKQIS01fcJ3C6K6+5WJTZo/tTa/2VMikdXnUVFVCksY WidKuqYf2+MuemJiSckYn6Cu4+mrmcg20uyNN0iXlQtgp5e4MJqo9M9fwlOvq0sahenF0zq/U mE07jJwqlj8snpZxXYK2pzNxm1Fgk9d8R1pmIwijN5vzcE2OmwNsnNiSeBLXGBm0QubrIXaKO yUOx6EBU20ujELCYEbTsR0l5kt/+Xttqz8jmvlZ+3lnZZRi0Zh3Mk9nsNhN3K5EpT/zwvDnWl UAJNbG3FutyddFYOidTvstZMiFY/kVTFWsO7gMTl26oGHxV1d/x34fIuuY7UTa5VyF3ggKgzG IURn3i72uXTNR5HDif/haBIQkLEYSVL+JaI/RxJnYwxE1sMB9PwmF5kTEEOxX2sLOpIZZacVA PQ0iMOKjLddKGerem Archived-At: Subject: [tcpm] 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: Wed, 29 Apr 2020 17:02:12 -0000 Hi, as many here know, I'm very much interested in transactional data exchange across TCP sessions, rather than the more common architectural approach of assuming unlimited data to transmit unidirectional. One of the issues in that space is, that these application limited sessions can very frequently run out of data, and expirience idle periods. Eliciting an ACK under certain circumstances, for a timely continuation of the data transmission / growth of the congestion window is a known method to reduce network delay. E.g. Linux has been using the CWR flag for the purpose of sending out an immediate ACK by the receiver, since there is an increased chance of a very small cwnd when the sender had just reduced it's congestion window. https://lore.kernel.org/patchwork/patch/970486/ and we also found latency improvements doing this when running ECN-enabled sessions https://reviews.freebsd.org/D22670 There are also numerous advisories, suggesting to disable delayed ACK completely when latency and/or timely bandwidth recovery under adversarial conditions is a major driver (e.g. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpape= r/performance/esxi7-nfs-read-perf.pdf for one that was just published very recently). To summarize: While I agree that under steady load conditions, there are probably some benefits to be had by TCP itself thinning out ACKs, and address certain environment (e.g. asymetric link bandwidth), there are also conditions, where a timely ACK is crucial in maintaining low latency and timely bandwidth recovery. Short of having a mechansim do explicitly do this, at least for the latter issue, TLP (or TLP-like) methods are the only ones to currently address that - but the duplicate unconditional transmission of a (small) data packet does have additional cost associated with it. Best regards, Richard From nobody Wed Apr 29 10:03:37 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 7581F3A1449 for ; Wed, 29 Apr 2020 10:03:35 -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=ham 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 DkaATkuUAq6J for ; Wed, 29 Apr 2020 10:03:33 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 7B2123A1451 for ; Wed, 29 Apr 2020 10:03:33 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id z16so1201149uae.11 for ; Wed, 29 Apr 2020 10:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lgSV+ilukrrqtWlfy7HUJ9KYquKwy8RYKE2EP+SHyFs=; b=H0rAFxZc1WMkzthIKm7OeZtiqb170HndrA05iQtxbcPMAYhXzktPPgR2n02CgJgHzX g8pr9JmB0tYWehD9BEPsyS1RY29WpW+cOhSelK/a4jazov1kWhQRKmp4ix/Mbiw/cMz5 JwVIeT1rS3HYtO0/fKToQCRQsE+0eMZVLyJfRFaP5SwGx2JECU54wtF/g4cFuzzfRC5o 2v8J2FnoSk/moEk07kvukaXDPGU08MnzncGzUoBhtEagB5y8AeUF0FgTE81iB2Xrh+ee c5KNZNBfs1QzRv53q/+NBMBjGD7VPhncdOSlj5jLmsHXZnQPj+NcaAaQQTBSFbPJv3PI ng0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lgSV+ilukrrqtWlfy7HUJ9KYquKwy8RYKE2EP+SHyFs=; b=nt4yi8fLMCW4d9bYc/lczILH4elDHVg8hqfi2U7Di8Od4HCiHLKM2BJbGXXRU47SIq J+wIbQ8tmB+AzARXRF4noivA4yAYTSCHPrzHoMWkIW2jJp64AHm8g5Mo1bd1UpB6/Qq5 wYj/3ESZWEyyraBaeg73BzcdtnUx9s2ZXgr3RI6hnIkFD9+yALc6fZx9mUDxyWgWjWJv k2aNXBjfF9RK54Ma1HP51+tDms9YL/c4bIhOBiGGjdlqelU3axYtnHirGklcW1OVlF85 UmfsOYfMN7QNqlWZJYZ9d9232MiowuQ5DPfpjyI2PmVAmxmWmr+6yMatreKTV/aS1T2A UBwQ== X-Gm-Message-State: AGi0PuY0jew8KdjCDpa3prisT/5ux5a75+7+AwmyL6ydVLk2kXsAJNnM DP8YxBeMv4BLzo7jLi8N78Vv1wd3uuiz+qhTHLk1hj5H X-Google-Smtp-Source: APiQypLqKNjiN1YQ3Q5hKFSMvtox1ucQBSe3FSnxL7QEaJ2WUWRFOTJbgJJBRFrlgRKrsmkpXzreWiU9U6eS+89ouqE= X-Received: by 2002:ab0:408a:: with SMTP id i10mr13129644uad.80.1588179811200; Wed, 29 Apr 2020 10:03:31 -0700 (PDT) MIME-Version: 1.0 From: Yuchung Cheng Date: Wed, 29 Apr 2020 10:02:54 -0700 Message-ID: To: "tcpm@ietf.org Extensions" , Neal Cardwell Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] question regarding draft-gomez-tcpm-delack-suppr-reqs 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, 29 Apr 2020 17:03:36 -0000 thanks for the talk! https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01#section-3.1 "Note that, while Appropriate Byte Counting (ABC) [RFC3465] might be used to address this problem, it remains as an experimental mechanism, not fully included in RFC 5681, which specifies standard TCP congestion control. " It's not clear what "fully included" means here. AFAICT, RFC5681 includes the essence of ABC explicitly. https://tools.ietf.org/html/rfc5681#section-3.1 " During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data. Slow start ends when cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted above) or when congestion is observed. While traditionally TCP implementations have increased cwnd by precisely SMSS bytes upon receipt of an ACK covering new data, we RECOMMEND that TCP implementations increase cwnd, per: cwnd += min (N, SMSS) (2) where N is the number of previously unacknowledged bytes acknowledged in the incoming ACK. This adjustment is part of Appropriate Byte Counting [RFC3465] and provides robustness against misbehaving receivers that may attempt to induce a sender to artificially inflate cwnd using a mechanism known as "ACK Division" [SCWA99]. ACK Division consists of a receiver sending multiple ACKs for a single TCP data segment, each acknowledging only a portion of its data. A TCP that increments cwnd by SMSS for each such ACK will inappropriately inflate the amount of data injected into the network." As a side note, Linux stack has implemented the principle of abc in its congestion control (including slow start) regarding delayed ACK harming slow-start or latency, I am not too sure either: 1) The ACK is delayed but not the data 2) The delay of the ACK can indeed delay cwnd growth during slowstart. But the ACK is delayed because the packet is likely a sub-MSS data, which is again likely caused by application limit (i.e. the application has sent all its data like a HTTP response). In this case the delay of the cwnd growth does not hurt the performance since the application has no data left to send. The only penalty occurs when the application has more data to send but cwnd is still gated by the arrival of the delayed ACK. However, in many request - response protocol, either the (non-delayed) ACKs triggered by prior full-MSS data inflight or the delayed ACKs would have returned to grow the cwnd to sending immediately. I can construct scenarios where delayed ACK significantly hurts application. But I don't think the scenario is too common. I will suggest more tests to quantify the effect of delayed ACK effect on slow-start. From nobody Wed Apr 29 10:04:36 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 1D4EC3A13FD; Wed, 29 Apr 2020 10:04:34 -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: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158817987404.31575.9839322047019142940@ietfa.amsl.com> Date: Wed, 29 Apr 2020 10:04:34 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 17:04:34 -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 : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-04.txt Pages : 31 Date : 2020-04-29 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-04 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 29 10:32: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 06B723A14A8 for ; Wed, 29 Apr 2020 10:32:27 -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, HTML_MESSAGE=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 VHZ4ocibNNrz for ; Wed, 29 Apr 2020 10:32:25 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 D38823A14A5 for ; Wed, 29 Apr 2020 10:32:25 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id k18so2266478ion.0 for ; Wed, 29 Apr 2020 10:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sdv3aMIw7i49I64uHwdyxBhqnOluVIWmztvCvcxRhPI=; b=WHTgLajZ6qOwfYfkbQeOkqbHNjQ8EBgWv9qrZKTqS3DV/ovQ1fwmYaI8u+CVlJVCEt YTDakgvUSwSbd7IIf/93rYYB97zuyP6wFxjDbHFZmY7Ji9A1CoxoDjNRKXR7VdkH24Ub o5/6qfUeyrIppjatDdv0hDCf/Wv2zbXo56p26CwplaPtRIUYlf+6V1eaER5/T4fBv8cp 1MRxLaEQrrV8MxnQEaBXHaAMjKmmlV4Bvi0kYs3q/cjPuA9ZH5/Z624FfUw/aFn2oPQi geyhvJ2cqaB34+JIjqpuv19u/cLnLm+6zZ5SKZ8b2NOZzMGhl984YmpCCKgTCvkXsrKD NyWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sdv3aMIw7i49I64uHwdyxBhqnOluVIWmztvCvcxRhPI=; b=J2eVID7+GzhSZeoFSmPUUJxPex6h+r8GJBSMt32ZGvj9Rfx+vaMeNzjNaBIn5AUQ91 nqSEXYxZfwqaMwm/chn6wMOV0uD8wMWcQ55peXraesleYaer4ZrUoYzRIh14cVLJmvun zROxvTtbZHnWThYDmQDQP3Uo2krInGKBlWNYWeYvca3UNjbXag6XVXW4ARicg3gwvYmM HSoWSfG7ICGAGfFe8H5WCnrpoyga6LUN0ucpygmck+UOyKw2wT7BtL3JwpBEgtz36jtz X4stQRf54FC0MsZW1wFuKjbg0ZptxCgtVbUpGpxhs50Doa2hxDQII28HsvkYwbKEg/BU KqAQ== X-Gm-Message-State: AGi0PuYm0fh4t87VYrFP67U1aIia6yVJx8MmLWgoTXp6aJs5T3LeEwU8 lE+sHx4e2rrzp3T2JVkIHRw1DG6hJJ/L1zDp/KfO1REg X-Google-Smtp-Source: APiQypJHZ0f6s/2/Qi1CmEWkZbQ+x9gkWaQQb2hLygRQcouSirLTG6ofZC0IsOh1XyWGY3FI9t53mfUelVRO3y2oEN0= X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr24613811iow.51.1588181544800; Wed, 29 Apr 2020 10:32:24 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Wed, 29 Apr 2020 10:32:14 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000d1158605a471549a" Archived-At: Subject: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 17:32:27 -0000 --000000000000d1158605a471549a Content-Type: text/plain; charset="UTF-8" I support adoption of this work. I would also encourage anyone in the WG thinking about implementing this draft to speak up. If this set is not null, I would encourage Praveen to move this draft to the Proposed Standard (preferred) or at least Experimental track. Martin --000000000000d1158605a471549a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this work.

=
I would also encourage anyone in the WG thinking about implementing th= is draft to speak up. If this set is not null, I would encourage Praveen to= move this draft to the Proposed Standard (preferred) or at least Experimen= tal track.

Martin
--000000000000d1158605a471549a-- From nobody Wed Apr 29 10:55: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 78B6C3A14F0 for ; Wed, 29 Apr 2020 10:55:03 -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 D5EC1G3KSF-V for ; Wed, 29 Apr 2020 10:55:00 -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 776733A14F5 for ; Wed, 29 Apr 2020 10:55:00 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DEB261B0007A for ; Wed, 29 Apr 2020 18:54:56 +0100 (BST) To: tcpm IETF list References: From: Gorry Fairhurst Message-ID: <8c3aca0d-0ea6-69f6-5ad8-fbdc984de77b@erg.abdn.ac.uk> Date: Wed, 29 Apr 2020 18:54:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: [tcpm] A longer follow-up on my comment on draft-gomez-tcpm-delack-suppr-reqs 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, 29 Apr 2020 17:55:04 -0000 First of all thank you for bringing this topic to the WG. I do think it is important that we discuss what ACKs are used for, how we expect them to be used and what the practical implications are for using ACKs across Internet paths. About the slides, I didn't have much time at the Mic. so maybe I sounded rather harsh, but I would suggest we do need to set a relatively high bar to adopting a piece of work in this space ... and we do need data and real understanding of what we are trying to fix and how we can avoid making it worse by accident in other cases. We went through a rather lengthy discussion in tsvwg on a similar (but different) topic regarding immediate negative acknowledgment for SCTP (RFC 7053- SACK-IMMEDIATELY Extension for SCTP) and found there were a few key places where for that protocol this did make sense. However, I actually don't believe your list of issues (i). Here is why... (I am interested if you think differently or know more). I've tried to roughly follow your points: * Slow start - I agree Delayed ACKs increase slow start, the more you delay the bigger the impact. However, the impact is for cases where ACKs are delayed on intervals comparable with or more than the Path RTT. - DAASS is a simple fix, that appears to help a lot when there is data waiting for the arrival of the delayed ACK. ABC is important also (well what I think people understand by ABC - rather than the RFC on this). * High bit rate environments and short data segments If you really don’t want delayed ACKs, the protocol using TCP ought to disable nagle. Or you would perhaps use DAASS... I’m not sure which problem you speak about? * Beyond classic ACK transmission behavior I do agree that Delayed ACKs preclude using sender behaviors intended to quickly and non-intrusively probe for available capacity during slow start. This is important to me, but I am very wary about the idea of sending more ACKs to do this, and we need to be careful to gain sufficient information about what the receiver has seen - not just to get a bunch of separate (each cumulative) ACKs. This really doesn’t give much fidelity to the sender. I’d be happy to talk more about what might be better! * IoT scenarios I can see the argument of an ACK energy cost for the IoT device. At least, I would assume IoT devices can be tuned, and the apps they talk to can be tuned. Appropriate guidance helps! * Bursty Apps I think you can add varying workloads as something important.  By which I mean apps that do transactional stuff, or are controlled by applications where the data transmission need varies.When we looked at CWV and the ideas that the applications control the traffic patterns in one group of applications, we also noted that these applications change the way they use the network. That’s important for a timely restart to growing the cwnd (etc). Such applications can also be very sensitive to  network delay.  These are probably also of interest! So....  the reason for hesitancy overall is I see this as tricky space to get correct. There are many places where fewer ACKs are good - if you have per ACK interrupt costs - if the capacity consumed by ACKs is important - the cost of sending in the link technology is high - etc. This is complicated for TCP (and much less so for QUIC - because QUIC has a notion of pacing; QUIC’s loss recovery is different; and QUIC’s ACKs are not easily thinned, at least at present). Any TCP method has to live with networks that experience pain from more ACKs, but also may deploy (various) mitigations. There are also cases where you’d like more information than a delayed ACK provides (e.g. chirping and similar probing methods) and there are application pathologies that would love an ACK at the end of a packet burst (be that 1 or 100s of packets). Any method has to live with a wide variety of paths and applications. Happy to discuss more. And I suspect other people may also respond on list. We have lots of data for QUIC and TCP - but most of our data focusses on testbeds or on actual broadband satellite services. Gorry From nobody Wed Apr 29 12:10:23 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 46D5D3A1682 for ; Wed, 29 Apr 2020 12:10:21 -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=ham 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 tJGKtuvxEPKY for ; Wed, 29 Apr 2020 12:10:19 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 27FFB3A1680 for ; Wed, 29 Apr 2020 12:10:19 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id m24so2144268vsq.10 for ; Wed, 29 Apr 2020 12:10:19 -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=yBjhEOntPOPNNQpl54wqxXvZXDFVTM75aoa4L9JKEK0=; b=pUjo2UpkMhZNRYu8stsa+Mz2OLUZl+ykVARxos38WX1GNoJe0+R6lWd+nYjG6loGwX 164FSFdGucCPOkco46yy6O+dA1coBHiyeyXwKoVesisyuQNv0Kg/pdyDcky19Z0jECYT mQIYjvtAwjPz/Wq0zNucXoZbaK44n2m5jqWdP88g6tMMQlghkxePEhcoR45W82h3amA4 T9oRbJ0isme5hd9lOF52fciAMx7CvVQtt0g1avr5/CLmV+eCG4ecZMVLzFCw5XdjrKJU 7fbRkh3Wpp2OlxfQ8mp+/tdI/+LWiyuwRLQmLnQr8tggcceuR9yYkCwZpgEYAJEIxvtL 2esg== 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=yBjhEOntPOPNNQpl54wqxXvZXDFVTM75aoa4L9JKEK0=; b=j2fEHY7RSodQrYH/9svMp0aYBCuNlOhYfQ/qNfAVBB0mjw5tXiQJ6QAUG+k2Z/TJ7p 7pM/GlDsaaR6AYyK5Zffp5KN8qWsneElAUoNik8TK19Iq5tIVSbdhGRQyKtSMMn5I+XS 84jvLodEuksP5fErIrLPdAn5f6svD8MKsdbOWy7pKjGWfHgS1STFpoBi7L9WDthxrnh0 E6CFQ0PLSTsxGNlpRTrk7MCXyPIiki3UbfuCD5mHf+nSoGOuf+FxjyDFB6L57xTLzZa3 WXbYnvuEwz5M1c3WVse9wokY7vQiw2RBSGLoh8F4ILsMPq8qwpW7iTwNSfDUvEXvNcuP ezmQ== X-Gm-Message-State: AGi0PuafNOpGJrdATqn20xmmmFBKizWCActSGjh+R6yFIBNmSeX1qPCX h+/lQwbNdW1ua9i31HHTB53ezw/6kFquW1dp3vMNkQ== X-Google-Smtp-Source: APiQypJyd/5c7hFNVaOm/UW9rbs6h/BaFljO+naD+kohJYhzkL7YsPTla9rhpg8/eyr9Cd3mtFEMEqtIeJQTU4MHFMU= X-Received: by 2002:a67:7f89:: with SMTP id a131mr29829137vsd.184.1588187417776; Wed, 29 Apr 2020 12:10:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 29 Apr 2020 12:09:41 -0700 Message-ID: To: Martin Duke Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 19:10:22 -0000 +1 on adoption two questions 1. RttSampleCount. Since the counter is incremented on a per ACK basis, the receiver behavior may significantly influence the actual hystart timeline. For example a receiver acking one full cwnd burst vs acking every packet (or even every byte). it'd be good to clarify if the intended rounds or time-scale in hystart++ design 2. "In practice, the Inter- Packet Arrival algorithm does not perform well and is not able to detect congestion early, primarily due to ACK compression." In my experience, another reason is it relies on packets being pushed out in a window of burst in slow start. Therefore in paced slow start (e.g. slow_start w/ linux fq/pacing) often produces premature exit as well. I am curious if the authors have similar experience? Lastly, I am a fan of the BBR startup algorithm for obvious reasons. The algorithm can be easily ported to produce an ssthresh for conventional C.C.. It'd be great to see some words describing the difference and even some real comparisons. BBR startup definitely requires a lot more states (e.g. to track bw) for example. so there are pros & cons. On Wed, Apr 29, 2020 at 10:32 AM Martin Duke wrote: > > I support adoption of this work. > > I would also encourage anyone in the WG thinking about implementing this draft to speak up. If this set is not null, I would encourage Praveen to move this draft to the Proposed Standard (preferred) or at least Experimental track. > > Martin > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 29 12:47:18 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 8CDD13A09C8 for ; Wed, 29 Apr 2020 12:47:15 -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, 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=ham 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 70mqO1p9sfFa for ; Wed, 29 Apr 2020 12:47:13 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 D31763A0AAD for ; Wed, 29 Apr 2020 12:47:12 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id z6so3382537wml.2 for ; Wed, 29 Apr 2020 12:47:12 -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=Wpz5nUYHISOjbsULHFeD56Qe7D55Vz8Pq3BvxnOrxZQ=; b=njKbOwdOeFwH6MvWHDlpIGVJI5JlQ+NErg0TtBXx8CPfVvmYfhfG4/G9B7+PWzC+Sl vA2F4gdyELGAQUH/h9ry2qb0/REjfJUG5srPYPZ323ee02SNbrtT1U8CPljRDHh8Mxi4 hF9sZS11avluBJ+7QMb1RUz1npOksgOujgR8o+LfYu9bTLsLp9Im7hPMB1g9act50+Bh BD+dDRcn9Go8a9fe2lQ9+zjkZrpX8Ss+6XkGmuhS7t7gMa7C+HEdorCCxIQG36luzPgb Wluz//aXQOiwhM0C4wY9WSfdci9WWXoewc1LpULNDnSOfyTF+LqVQlEG8/+QYG2lbTu5 xjTw== 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=Wpz5nUYHISOjbsULHFeD56Qe7D55Vz8Pq3BvxnOrxZQ=; b=Je6+7Dm/LT51MsOmf4wM/ntdqz38Yievk05c/Eg3vuSVaqtl/y9L0TqXX0pJmBO3nK gUzBko+zHlEk40AxI8Ys+7FgHQuFjh2++mL9iRBSeicMM3KErjImc2OuCEUSFJf1lUI1 msvdhk17AHVd5ajsbjgUtzR0xC/4DtTK3o9iD4iWRsP4RaO4zFstBLx7an1YWFm2jXil hhy5Pi2z52Ki6WP7b+hDrm/GxAEtrpt9tHWcJFAqFxJUEfnsMcqdGqnb2oSXEq0+BMDq N/JbV5xdxminHx3v+DNZE6BDY+V9WuwLewlq5+ZZ9d2svfxPb7z0ckzrQrxhgjb9SGbh GCKA== X-Gm-Message-State: AGi0PuZQ88gd77cAEwuqQ7sknAgPXrFDHDQEP3XjSbf/rAL054xoHub+ vA4HE/ri4shuUhNpB4Kjoz7LXMdS7XlBs0wioeK9y6PGde8= X-Google-Smtp-Source: APiQypJB2RkuecQLE8luXq5KpTABjHe0Gm+Ew5DWv6cUkCRmoYlSOVTorYi5U0ofdwgO6nCsn2lLeecBoZveYhTwzX0= X-Received: by 2002:a7b:cf27:: with SMTP id m7mr5272135wmg.183.1588189630782; Wed, 29 Apr 2020 12:47:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 29 Apr 2020 15:46:58 -0400 Message-ID: To: Yuchung Cheng Cc: Martin Duke , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000c7c81405a47336c0" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 19:47:16 -0000 --000000000000c7c81405a47336c0 Content-Type: text/plain; charset="UTF-8" +1 on adoption from me as well. I'd be happy to implement this in our QUIC Cubic implementation(which is still the default CC for Chrome QUIC). On Wed, Apr 29, 2020 at 3:10 PM Yuchung Cheng wrote: > +1 on adoption > > two questions > 1. RttSampleCount. Since the counter is incremented on a per ACK > basis, the receiver behavior may significantly influence the actual > hystart timeline. For example a receiver acking one full cwnd burst vs > acking every packet (or even every byte). it'd be good to clarify if > the intended rounds or time-scale in hystart++ design > > 2. "In practice, the Inter- Packet Arrival algorithm does not perform > well and is not able to detect congestion early, primarily due to ACK > compression." In my experience, another reason is it relies on packets > being pushed out in a window of burst in slow start. Therefore in > paced slow start (e.g. slow_start w/ linux fq/pacing) often produces > premature exit as well. I am curious if the authors have similar > experience? > > Lastly, I am a fan of the BBR startup algorithm for obvious reasons. > The algorithm can be easily ported to produce an ssthresh for > conventional C.C.. It'd be great to see some words describing the > difference and even some real comparisons. BBR startup definitely > requires a lot more states (e.g. to track bw) for example. so there > are pros & cons. > > On Wed, Apr 29, 2020 at 10:32 AM Martin Duke > wrote: > > > > I support adoption of this work. > > > > I would also encourage anyone in the WG thinking about implementing this > draft to speak up. If this set is not null, I would encourage Praveen to > move this draft to the Proposed Standard (preferred) or at least > Experimental track. > > > > Martin > > _______________________________________________ > > 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 > --000000000000c7c81405a47336c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 on adoption from me as well.

I'd= be happy to implement this in our QUIC Cubic implementation(which is still= the default CC for Chrome QUIC).

On Wed, Apr 29, 2020 at 3:10 PM = Yuchung Cheng <ycheng=3D4= 0google.com@dmarc.ietf.org> wrote:
+1 on adoption

two questions
1. RttSampleCount. Since the counter is incremented on a per ACK
basis, the receiver behavior may significantly influence the actual
hystart timeline. For example a receiver acking one full cwnd burst vs
acking every packet (or even every byte). it'd be good to clarify if the intended rounds or time-scale in hystart++ design

2. "In practice, the Inter- Packet Arrival algorithm does not perform<= br> well and is not able to detect congestion early, primarily due to ACK
compression." In my experience, another reason is it relies on packets=
being pushed out in a window of burst in slow start. Therefore in
paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
premature exit as well. I am curious if the authors have similar
experience?

Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
The algorithm can be easily ported to produce an ssthresh for
conventional C.C.. It'd be great to see some words describing the
difference and even some real comparisons. BBR startup definitely
requires a lot more states (e.g. to track bw) for example. so there
are pros & cons.

On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com> wrote: >
> I support adoption of this work.
>
> I would also encourage anyone in the WG thinking about implementing th= is draft to speak up. If this set is not null, I would encourage Praveen to= move this draft to the Proposed Standard (preferred) or at least Experimen= tal track.
>
> Martin
> _______________________________________________
> 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
--000000000000c7c81405a47336c0-- From nobody Wed Apr 29 14:08: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 8B1FA3A1804 for ; Wed, 29 Apr 2020 14:08:13 -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=ham 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 YrS_rp4BG8tG for ; Wed, 29 Apr 2020 14:08:11 -0700 (PDT) Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (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 9E4883A1802 for ; Wed, 29 Apr 2020 14:08:10 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id k8so2822984ejv.3 for ; Wed, 29 Apr 2020 14:08:10 -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=ny7X+PNkhiOZjA6reOB74Nuo+fW7y0kHI28xbDcyOlo=; b=ragffGD+YpwJ+4lbM0WmAalCjeyGWI6xRs+hm96W7y6a61rXut5uY0YuiCP10Gc898 T6SB8FdjK51sYq/JGC3NaZbKudNbP1Aqa/TwfIxsjJklVGAv5IflivZaHfEBEY/rvUMO +v5UwC6UOmSQkgRTQBrJMJPUiww1rrY1r2Z5F+bXuaLy2T7okO6mXMFnjovD8/oEKx7e u4ie/UMIt6qi6qeOlx2mh4NCYS95z37GF7ycre9LHK+pRYuVRmBYc1qu+5oqsvOoaRSP dljKrf3p3IhVEMeW7Uf02zrlXy4C4dZRbHD7C0rV4nQz9XCBhsYN8imlhRAjh5beVBr/ LRwQ== 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=ny7X+PNkhiOZjA6reOB74Nuo+fW7y0kHI28xbDcyOlo=; b=alYpv+9jCEHvhmwgVQfgEO3i8RmrvZyqIN7KlRYNIh3ZGBASpmbDBKuQAsiyuJHKUZ 9fOjsZPofpNx6HTr5YHsiRMB80d0fzzyutNBBrqnfIWn6Um2hofJMnELCMu/Dl7/dDTP ZsefFY1fnbS6gqRcbht6PAzbQ2G7v9MC8wsZY7/9shqJ8l1orvZ1FAckwz+7WtbY0LP9 8d9QKboCSO4BqYP1i3obkO3L75LQVkXzEW3Fm+znaUztxGsHLelHJMGBBm3BecrCSTND eAxY/7z2yrk52uV7fzUsQx8ZN5teeLk72WSDGNpEaIa7tIPxL8qMldaAnLhyS0O45QRs iBfg== X-Gm-Message-State: AGi0PuZEmbSUVegAIWkxJ3qW9e091o6lMyAd2E6D+OyORaQjSjt/3bni KICkuyiS+rMSKQ/GffS+bsEQlMm5EQvQWTlzYyVNRw== X-Google-Smtp-Source: APiQypILzN/k0+jXP3YhN1zrAZ03FN7ynRhcV0I/WHb2V5tAmkXcJIkP+lBU7heQ7NgcHI0Ofap7xl+AABkYLWqA3gk= X-Received: by 2002:a17:906:74c:: with SMTP id z12mr4608748ejb.87.1588194488179; Wed, 29 Apr 2020 14:08:08 -0700 (PDT) MIME-Version: 1.0 References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> In-Reply-To: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> From: Neal Cardwell Date: Wed, 29 Apr 2020 17:07:51 -0400 Message-ID: To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org" , Gorry Fairhurst , carlesgo@entel.upc.edu, Bob Briscoe Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] 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: Wed, 29 Apr 2020 21:08:14 -0000 On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard wrote: > Eliciting an ACK under certain circumstances, for a timely continuation > of the data transmission / growth of the congestion window is a known > method to reduce network delay. > > E.g. Linux has been using the CWR flag for the purpose of sending out an > immediate ACK by the receiver, since there is an increased chance of a > very small cwnd when the sender had just reduced it's congestion window. > > https://lore.kernel.org/patchwork/patch/970486/ > > and we also found latency improvements doing this when running > ECN-enabled sessions > > https://reviews.freebsd.org/D22670 Yes, agreed. IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1 case. In datacenter networks the BDPs tend to be so small, and the numbers of flows can be so large, that it's not unusual for a flow's fair share of the BDP to be one packet or less. If the flows want to maintain low queuing delays, then ideally they would be able to reduce their cwnd to 1 packet (or effectively even lower, with pacing). But the current behavior of TCP delayed ACKs often causes terrible delays with a cwnd of 1. The Linux TCP approach of sending an immediate ACK upon receiving a packet with CWR set (see Richard's link above) helps a lot with this case. But that's a non-standard heuristic, and doesn't help for senders that have a congestion control that does not use ECN CWR signals (e.g. Accurate ECN). Unless I'm missing something, it seems like endpoints using Accurate ECN are going to run into this same latency issue. To avoid this, I guess they may want to either use a cwnd >= 2, or make use of some new explicit ACK-pull mechanism. best, neal From nobody Wed Apr 29 14:33:44 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 BA4133A182E for ; Wed, 29 Apr 2020 14:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj3zXr27Sppd for ; Wed, 29 Apr 2020 14:33:39 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 111903A0D40 for ; Wed, 29 Apr 2020 14:33:39 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id f11so4280924ljp.1 for ; Wed, 29 Apr 2020 14:33:38 -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=S7DGc+yD26Jna8MUvkxgCwfpJs86GYpS6Y6cLmaX4fc=; b=FwuqFM7jB5gA62uifC6ZgMW9GXfAdbmY81XsmSGl3ueiMv1T05TPcFhOa3RxzXlWVT yJsb00h67sdT01QAqnKNJBLeZM9cxxubUL1L8Fym8Y2RvqrNDLOGOELuUTTJ1+Tk+eUZ jD0XosAl9MScbFnMFOurMI5IFuxwCftiSurmvfE0RX619CMjF2dVp/iN6IKJjDAv+Qpm zM1mFSoVMVD+PrMxFnCQSGbh9ZhiRVmjLa3LuiH8e0DHJEr36jWamSrMPTNM1na3tOra fsyuFU8fmenIgpmlg9MedEOtaMXU0UpXrFwblg2pISeRMHYxuo0P36lCmHq72+G0AI0r Xqag== 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=S7DGc+yD26Jna8MUvkxgCwfpJs86GYpS6Y6cLmaX4fc=; b=RT6g7LzM+5QELrg57hPDCenrfWCp2XKFdW+dM0WZResc2VlLM9/fDQGtFrFFvnmrFD KlbohIDibHVxKSqpjuJBWfOmqHmeCBy8c7haof3CVVS/d8Xd1aHxxXkD/bhLYmbGtcEe Zp285XDur2Uc4s87/QP149taAh0XXVCtXNegqMlm8U9u/Koj6HF3nr4VQSC6aO1Hckjb KZ0OpvgrgZGDlsRYBVm8aoDSWyzao5QGnDSh1uGANLbKEM9swJWhjIZjyUq7KKf/jOUe 79DpA8Q3STYkKtA+0VgJ5pckutfPi35GcuOkFqATOIc0qBRAiqgccLpj14am5dsR6hvZ hU2A== X-Gm-Message-State: AGi0PubBbsTofwotyrcDnJdSjgVEhXsivfxalpSlLrImAeD5Qn5/h12D DSH6vCzvDC6NYI6QQLbXTiA= X-Google-Smtp-Source: APiQypI4jvh0969FVH00Vj75FRrhcuIyTOdRdxad/9CnzOz/3jPiARPdS0jmQlMdwdfBx0lFPWmP2Q== X-Received: by 2002:a2e:8658:: with SMTP id i24mr110575ljj.287.1588196017195; Wed, 29 Apr 2020 14:33:37 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-192-nat-p.elisa-mobile.fi. [83.245.235.192]) by smtp.gmail.com with ESMTPSA id h24sm3278303lji.99.2020.04.29.14.33.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 14:33:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Thu, 30 Apr 2020 00:33:35 +0300 Cc: "Scheffenegger, Richard" , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <01E0F7B3-30E1-419C-A933-C718D0B3F990@gmail.com> References: <683902e8-a2af-cfb7-ffd0-c5c5742e5bd5@gmx.at> To: Neal Cardwell X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] 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: Wed, 29 Apr 2020 21:33:42 -0000 > On 30 Apr, 2020, at 12:07 am, Neal Cardwell = wrote: >=20 > The Linux TCP approach of sending an immediate ACK upon receiving a > packet with CWR set (see Richard's link above) helps a lot with this > case. But that's a non-standard heuristic, and doesn't help for > senders that have a congestion control that does not use ECN CWR > signals (e.g. Accurate ECN). Unless I'm missing something, it seems > like endpoints using Accurate ECN are going to run into this same > latency issue. To avoid this, I guess they may want to either use a > cwnd >=3D 2, or make use of some new explicit ACK-pull mechanism. Just to note, this is a problem that SCE wouldn't be affected by, as it = doesn't change the ECE/CWR handling. - Jonathan Morton= From nobody Wed Apr 29 14:36:28 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 BF4F03A18A5; Wed, 29 Apr 2020 14:36:26 -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: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158819618671.32088.3115018826349552828@ietfa.amsl.com> Date: Wed, 29 Apr 2020 14:36:26 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 21:36:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF. Title : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-05.txt Pages : 33 Date : 2020-04-29 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 29 14:58: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 3EF9B3A0736 for ; Wed, 29 Apr 2020 14:57:58 -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 zNK-G4j_PwwX for ; Wed, 29 Apr 2020 14:57:56 -0700 (PDT) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 740EB3A065A for ; Wed, 29 Apr 2020 14:57:56 -0700 (PDT) Received: by mail-ua1-x944.google.com with SMTP id s5so1579897uad.4 for ; Wed, 29 Apr 2020 14:57:56 -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=sIelIKirSzaj2l44kAlGID0CoQZTn5vOuiHGooKdRck=; b=JRSnYvYO0T0qz2O6fB6jiSaQ4YT+CGsSJLyDfJyU6Fpyc8ZrxHFA8pFBCaLCmjspfr q85VFrc0mjmt97wAzgA2TfucoeTYK0ZHK08MBQt7jMPD/+iKUtB8rOvgKQYjNIENM7as PT+IWo5i9QUvwKeL3v3UXxP1Poq9B+uWG2oaiRYRVRo51JG/wZW69W4KRqsdr7zew1Ef QW1G7E/yvKQkWYFWiKE5eCD80tiqaobQlFP2yP+lW1NlfBHyKP8HdIrxLsBjzpUFhAjw De5c8enZo2PIs47wLrZoN/vF4tIrxThshuXDmOhiY3eRTDtTL4AkyIGEeOD49B1NuZFt hqvQ== 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=sIelIKirSzaj2l44kAlGID0CoQZTn5vOuiHGooKdRck=; b=UZxrgCKHoYhN5atVLc1jO28Zmbcyrr2V8fmIyrPwh6zbBhMeIaxRBzl/dJkMeV0sLT KNI0p6T2EZVM4jvQJdX6IPcgsXG0Zh+UnwVdBBjdFvTGgCEW2pNjBBaqGkgpplYL2Q5N m4Dj31okDYlgBM9MVyOe6w/5rqrbgT84qZAHwx/0aJfvktm9XRIHpMfPkMgfdbgPAZfw sfiGutaopLt8/h8VVjMy0cBIvpBj3JCSQEow+F4RRUpzkgZHOEYbGGL142mw9w29SiE4 Ef2PnbffaLoznPfEA4rUnz1uKdCbeZGgQjV7VRUC0bYfauItW9E1qLazeXLONgwhyQp6 7qig== X-Gm-Message-State: AGi0PubJZxrEGg8Pj751JT2ZWhoHUPSQoo+Ml8mGuhZ/Wb829suALwCU s91i//N0SgfSe0nrbnWdAAIyTQBP2t39QDmdBIP9+bRleRQ= X-Google-Smtp-Source: APiQypIqiejFud2mom7obEGiWHO7UT51/019ZgoRSHTnpWiy9+XfigKwMLtMzPTyg0G93QM07cSvWt1MCIhOlIqmSSY= X-Received: by 2002:a9f:3826:: with SMTP id p35mr16469uad.123.1588197475204; Wed, 29 Apr 2020 14:57:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junho Choi Date: Wed, 29 Apr 2020 14:57:18 -0700 Message-ID: To: Ian Swett Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000057c19d05a4750ad4" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 21:57:59 -0000 --00000000000057c19d05a4750ad4 Content-Type: text/plain; charset="UTF-8" Ian - I implemented for Cloudflare quiche: https://github.com/cloudflare/quiche/pull/476 There is a minor difference due to TCP vs QUIC (see PR desciprion) but in general it's easy to port and works well so far. On Wed, Apr 29, 2020 at 12:47 PM Ian Swett wrote: > +1 on adoption from me as well. > > I'd be happy to implement this in our QUIC Cubic implementation(which is > still the default CC for Chrome QUIC). > > On Wed, Apr 29, 2020 at 3:10 PM Yuchung Cheng 40google.com@dmarc.ietf.org> wrote: > >> +1 on adoption >> >> two questions >> 1. RttSampleCount. Since the counter is incremented on a per ACK >> basis, the receiver behavior may significantly influence the actual >> hystart timeline. For example a receiver acking one full cwnd burst vs >> acking every packet (or even every byte). it'd be good to clarify if >> the intended rounds or time-scale in hystart++ design >> >> 2. "In practice, the Inter- Packet Arrival algorithm does not perform >> well and is not able to detect congestion early, primarily due to ACK >> compression." In my experience, another reason is it relies on packets >> being pushed out in a window of burst in slow start. Therefore in >> paced slow start (e.g. slow_start w/ linux fq/pacing) often produces >> premature exit as well. I am curious if the authors have similar >> experience? >> >> Lastly, I am a fan of the BBR startup algorithm for obvious reasons. >> The algorithm can be easily ported to produce an ssthresh for >> conventional C.C.. It'd be great to see some words describing the >> difference and even some real comparisons. BBR startup definitely >> requires a lot more states (e.g. to track bw) for example. so there >> are pros & cons. >> >> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke > > wrote: >> > >> > I support adoption of this work. >> > >> > I would also encourage anyone in the WG thinking about implementing >> this draft to speak up. If this set is not null, I would encourage Praveen >> to move this draft to the Proposed Standard (preferred) or at least >> Experimental track. >> > >> > Martin >> > _______________________________________________ >> > 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 > -- Junho Choi --00000000000057c19d05a4750ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ian - I implemented for Cloudflare quiche: https://github.com/cloudfla= re/quiche/pull/476

There is a minor difference= due to TCP vs QUIC (see PR desciprion) but in general it's easy to por= t and works well so far.

On Wed, Apr 29, 2020 at 12:47 PM Ian Swet= t <ianswett=3D40google.co= m@dmarc.ietf.org> wrote:
+1 on adoption from me as well.

I'd be happy to implement this in our QUIC Cubic implementatio= n(which is still the default CC for Chrome QUIC).

On Wed, Apr 29, = 2020 at 3:10 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:=
+1 on adoption<= br>
two questions
1. RttSampleCount. Since the counter is incremented on a per ACK
basis, the receiver behavior may significantly influence the actual
hystart timeline. For example a receiver acking one full cwnd burst vs
acking every packet (or even every byte). it'd be good to clarify if the intended rounds or time-scale in hystart++ design

2. "In practice, the Inter- Packet Arrival algorithm does not perform<= br> well and is not able to detect congestion early, primarily due to ACK
compression." In my experience, another reason is it relies on packets=
being pushed out in a window of burst in slow start. Therefore in
paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
premature exit as well. I am curious if the authors have similar
experience?

Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
The algorithm can be easily ported to produce an ssthresh for
conventional C.C.. It'd be great to see some words describing the
difference and even some real comparisons. BBR startup definitely
requires a lot more states (e.g. to track bw) for example. so there
are pros & cons.

On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com> wrote:<= br> >
> I support adoption of this work.
>
> I would also encourage anyone in the WG thinking about implementing th= is draft to speak up. If this set is not null, I would encourage Praveen to= move this draft to the Proposed Standard (preferred) or at least Experimen= tal track.
>
> Martin
> _______________________________________________
> 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


--
Junho Choi <junho= dot choi at gmail.com&g= t;
--00000000000057c19d05a4750ad4-- From nobody Wed Apr 29 14:58: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 A88AC3A073E for ; Wed, 29 Apr 2020 14:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 jB42j3F0-ko9 for ; Wed, 29 Apr 2020 14:58:44 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 8DA643A073D for ; Wed, 29 Apr 2020 14:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:From:References:To:Subject: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=WuZAVdPIBAIw/pSwsNUfCSBcEOarxVxU06jFe9ZtTvo=; b=AsJXMcSTBI0WIxCfqrBYAT8Kdy B2Stnu9F8ImT5N55WZEFYmllsr7yzpuitOhan2enFfBWBKQk+5iV8fzQRchFpCkJ/BqOi17RfI8Ap VoZFB+Z8ohBmv3CWKI6D1myZK42DOm7kTRTlwKEldU5V/q3+kq9GlQQifQqF/z7XSS7x3ESAJbt4n sYHycL4L6NVRECblwxrq5XLeTymV8RqX1Fk2p3xvfqyStlgZN6MoaWyy7aR6KV2Or6PlaJJr8M9v3 R2wwjM2HQTlBCfY0960Mq/8P332Df7IoITAj3PlIqhqhPSf2Ejcrg11vBk0iRKiR0Muo6ws5LqWxj IOYT2nRg==; Received: from [31.185.128.97] (port=54488 helo=[192.168.0.6]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jTuj4-004uV1-Pc; Wed, 29 Apr 2020 22:58:42 +0100 To: Gorry Fairhurst References: <8c3aca0d-0ea6-69f6-5ad8-fbdc984de77b@erg.abdn.ac.uk> From: Bob Briscoe Cc: tcpm IETF list Message-ID: <42a218f6-3d9d-25f1-9e00-476144b671fc@bobbriscoe.net> Date: Wed, 29 Apr 2020 22:58:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8c3aca0d-0ea6-69f6-5ad8-fbdc984de77b@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] A longer follow-up on my comment on draft-gomez-tcpm-delack-suppr-reqs 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, 29 Apr 2020 21:58:50 -0000 Gorry, On 29/04/2020 18:54, Gorry Fairhurst wrote: > > > First of all thank you for bringing this topic to the WG. I do think > it is important that we discuss what ACKs are used for, how we expect > them to be used and what the practical implications are for using ACKs > across Internet paths. > > About the slides, I didn't have much time at the Mic. so maybe I > sounded rather harsh, but I would suggest we do need to set a > relatively high bar to adopting a piece of work in this space ... and > we do need data and real understanding of what we are trying to fix > and how we can avoid making it worse by accident in other cases. > > We went through a rather lengthy discussion in tsvwg on a similar (but > different) topic regarding immediate negative acknowledgment for SCTP > (RFC 7053- SACK-IMMEDIATELY Extension for SCTP) and found there were a > few key places where for that protocol this did make sense. > > However, I actually don't believe your list of issues (i). Here is > why... (I am interested if you think differently or know more). > > I've tried to roughly follow your points: > > * Slow start > - I agree Delayed ACKs increase slow start, the more you delay the > bigger the impact. However, the impact is for cases where ACKs are > delayed on intervals comparable with or more than the Path RTT. I appreciate you taking time to qualify your initial harsh words. I would ask you to still take even more time over this review. People listen to you on this subject, and I think you are glossing over large areas of the issue too quickly. > - DAASS is a simple fix, that appears to help a lot when there is data > waiting for the arrival of the delayed ACK. Any heuristic at the receiver to detect the end of a pattern of start-up such as slow-start, ossifies that pattern into the Internet. Sender control of the DelACK ratio removes that ossification. > ABC is important also (well what I think people understand by ABC - > rather than the RFC on this). Yes. > * High bit rate environments and short data segments > > If you really don’t want delayed ACKs, the protocol using TCP ought to > disable nagle. Or you would perhaps use DAASS... I’m not sure which > problem you speak about? > > > * Beyond classic ACK transmission behavior > I do agree that Delayed ACKs preclude using sender behaviors intended > to quickly and non-intrusively probe for available capacity during > slow start. This is important to me, but I am very wary about the idea > of sending more ACKs to do this, and we need to be careful to gain > sufficient information about what the receiver has seen - not just to > get a bunch of separate (each cumulative) ACKs. This really doesn’t > give much fidelity to the sender. I’d be happy to talk more about what > might be better! Indeed, ACK frames in QUIC that give the arrival times of data packets are an alternative - as long as they are not stretched beyond the time at which they would have been useful. But we are more limited for space in TCP. As long as a TCP server is serving bulk and short flows, it can put more effort into receiving more ACKs during flow startup, and save its processing power by using less frequent ACKs for the majority of its data - transmitted in congestion avoidance. > * IoT scenarios > I can see the argument of an ACK energy cost for the IoT device. At > least, I would assume IoT devices can be tuned, and the apps they talk > to can be tuned. Appropriate guidance helps! Tuning is for a scenario, not for widely differing scenarios. The message of this draft is that a connection sometimes needs to be able to adapt its ACK ratio at run-time. Not every IoT device is always deployed for just one scenario. Neither is its peer. To me this says adaptation mustn't be complex (and doesn't have to be). > > * Bursty Apps > I think you can add varying workloads as something important.  By > which I mean apps that do transactional stuff, or are controlled by > applications where the data transmission need varies.When we looked at > CWV and the ideas that the applications control the traffic patterns > in one group of applications, we also noted that these applications > change the way they use the network. That’s important for a timely > restart to growing the cwnd (etc). Such applications can also be very > sensitive to  network delay.  These are probably also of interest! Yes. > > So....  the reason for hesitancy overall is I see this as tricky space > to get correct. But trickiness is the point of starting this requirements document, isn't it? Please can you articulate better why you seem negative about this exercise? > > There are many places where fewer ACKs are good - if you have per ACK > interrupt costs - if the capacity consumed by ACKs is important - the > cost of sending in the link technology is high - etc. This is > complicated for TCP (and much less so for QUIC - because QUIC has a > notion of pacing; QUIC’s loss recovery is different; and QUIC’s ACKs > are not easily thinned, at least at present). Any TCP method has to > live with networks that experience pain from more ACKs, but also may > deploy (various) mitigations. Yes. But reading between the lines I hear you say "Don't start this exercise". Pls explicitly articulate your implicit message. > > > There are also cases where you’d like more information than a delayed > ACK provides (e.g. chirping and similar probing methods) and there are > application pathologies that would love an ACK at the end of a packet > burst (be that 1 or 100s of packets). Any method has to live with a > wide variety of paths and applications. > > Happy to discuss more. And I suspect other people may also respond on > list. We have lots of data for QUIC and TCP - but most of our data > focusses on testbeds or on actual broadband satellite services. Thanks for elaborating. Bob > > Gorry > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Apr 29 15:03: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 E24973A07D5 for ; Wed, 29 Apr 2020 15:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtZwCo_lFkxA for ; Wed, 29 Apr 2020 15:03:43 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 515C33A07F4 for ; Wed, 29 Apr 2020 15:03:20 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03TM1fIL054563; Wed, 29 Apr 2020 15:03:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=OimHZgniM4O2ZuLP4FSrt13YEeQEPhq5j6LF3iCjyQM=; b=PADNnC1G09hZa/E7EFN8U4iRa7Le4MLVoDh2dkpAsTKTpea+wqFoj5MtlL6xvXnGzmI7 GjAFPUW3r1PHYftor1tUrwFysS7pUBK4+MHABYhSFEQOnuhXL0V/xHUexbktRM9BK1b4 w5KPB1HGqyihIyDSvkPvpHjJIAk08jbbAArR6D26a264D6Lg0XGF9SIcce7r/XOmYMQn lBkLOeD+Ju7+20Wz/Pt0/yfoBea7nq2bN0PSTGtk0W290slBTSFnoV9PhrXIReh8a8NB RGgt1+XcskSruBphwEKFwmW45Vw6sfRLxT17iCUHIeVaWsC5N3J7+M+qkvFcF95u7zzu Dw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp02.apple.com with ESMTP id 30mhshsbx0-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Apr 2020 15:03:19 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9K00PTQL9DI7F0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 29 Apr 2020 15:03:13 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9K00900L0LOA00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 29 Apr 2020 15:03:13 -0700 (PDT) X-Va-A: X-Va-T-CD: a2adaffc1823609fc183c24dd23c1091 X-Va-E-CD: 3f12e9cb947885c7b4170cc2da01a6c6 X-Va-R-CD: 63192fceae19d38c4291a59766388cfd X-Va-CD: 0 X-Va-ID: ded66b4c-b941-421f-86b0-74878e493f24 X-V-A: X-V-T-CD: a2adaffc1823609fc183c24dd23c1091 X-V-E-CD: 3f12e9cb947885c7b4170cc2da01a6c6 X-V-R-CD: 63192fceae19d38c4291a59766388cfd X-V-CD: 0 X-V-ID: a583b7d1-18b2-47de-9dc4-5c6a7420a29b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-29_11:2020-04-29, 2020-04-29 signatures=0 Received: from vimac.scv.apple.com (vimac.scv.apple.com [17.192.171.33]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9K006BOL9BBO00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 29 Apr 2020 15:03:12 -0700 (PDT) From: Vidhi Goel Message-id: <2F75440D-69C7-4BD7-8383-4CB8F5BCB831@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_7C64D6E3-BC29-4D65-95E2-5E2C242CE344" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.13.2.1\)) Date: Wed, 29 Apr 2020 15:03:11 -0700 In-reply-to: Cc: Ian Swett , Yuchung Cheng , "tcpm@ietf.org Extensions" To: Junho Choi References: X-Mailer: Apple Mail (2.3608.80.13.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-29_11:2020-04-29, 2020-04-29 signatures=0 Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 22:03:46 -0000 --Apple-Mail=_7C64D6E3-BC29-4D65-95E2-5E2C242CE344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for adoption. I plan to implement this in Apple QUIC which uses Cubic = by default later this fall. Vidhi > On Apr 29, 2020, at 2:57 PM, Junho Choi wrote: >=20 > Ian - I implemented for Cloudflare quiche: = https://github.com/cloudflare/quiche/pull/476 = >=20 > There is a minor difference due to TCP vs QUIC (see PR desciprion) but = in general it's easy to port and works well so far. >=20 > On Wed, Apr 29, 2020 at 12:47 PM Ian Swett = > wrote: > +1 on adoption from me as well. >=20 > I'd be happy to implement this in our QUIC Cubic implementation(which = is still the default CC for Chrome QUIC). >=20 > On Wed, Apr 29, 2020 at 3:10 PM Yuchung Cheng = > wrote: > +1 on adoption >=20 > two questions > 1. RttSampleCount. Since the counter is incremented on a per ACK > basis, the receiver behavior may significantly influence the actual > hystart timeline. For example a receiver acking one full cwnd burst vs > acking every packet (or even every byte). it'd be good to clarify if > the intended rounds or time-scale in hystart++ design >=20 > 2. "In practice, the Inter- Packet Arrival algorithm does not perform > well and is not able to detect congestion early, primarily due to ACK > compression." In my experience, another reason is it relies on packets > being pushed out in a window of burst in slow start. Therefore in > paced slow start (e.g. slow_start w/ linux fq/pacing) often produces > premature exit as well. I am curious if the authors have similar > experience? >=20 > Lastly, I am a fan of the BBR startup algorithm for obvious reasons. > The algorithm can be easily ported to produce an ssthresh for > conventional C.C.. It'd be great to see some words describing the > difference and even some real comparisons. BBR startup definitely > requires a lot more states (e.g. to track bw) for example. so there > are pros & cons. >=20 > On Wed, Apr 29, 2020 at 10:32 AM Martin Duke > wrote: > > > > I support adoption of this work. > > > > I would also encourage anyone in the WG thinking about implementing = this draft to speak up. If this set is not null, I would encourage = Praveen to move this draft to the Proposed Standard (preferred) or at = least Experimental track. > > > > Martin > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = >=20 >=20 > --=20 > Junho Choi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_7C64D6E3-BC29-4D65-95E2-5E2C242CE344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 = for adoption. I plan to implement this in Apple QUIC which uses Cubic by = default later this fall.

Vidhi

On Apr 29, 2020, at 2:57 PM, = Junho Choi <junho.choi@gmail.com> wrote:

Ian - I implemented for Cloudflare quiche: https://github.com/cloudflare/quiche/pull/476

There is a minor = difference due to TCP vs QUIC (see PR desciprion) but in general it's = easy to port and works well so far.

On Wed, Apr 29, 2020 at 12:47 PM Ian Swett = <ianswett=3D40google.com@dmarc.ietf.org> wrote:
+1 on = adoption from me as well.

I'd be happy to implement this in our QUIC Cubic = implementation(which is still the default CC for Chrome QUIC).

On Wed, Apr 29, 2020 at 3:10 PM Yuchung = Cheng <ycheng=3D40google.com@dmarc.ietf.org> = wrote:
+1 on adoption

two questions
1. RttSampleCount. Since the counter is incremented on a per ACK
basis, the receiver behavior may significantly influence the actual
hystart timeline. For example a receiver acking one full cwnd burst = vs
acking every packet (or even every byte). it'd be good to clarify if
the intended rounds or time-scale in hystart++ design

2. "In practice, the Inter- Packet Arrival algorithm does not perform
well and is not able to detect congestion early, primarily due to ACK
compression." In my experience, another reason is it relies on = packets
being pushed out in a window of burst in slow start. Therefore in
paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
premature exit as well. I am curious if the authors have similar
experience?

Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
The algorithm can be easily ported to produce an ssthresh for
conventional C.C.. It'd be great to see some words describing the
difference and even some real comparisons. BBR startup definitely
requires a lot more states (e.g. to track bw) for example. so there
are pros & cons.

On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com> wrote:
>
> I support adoption of this work.
>
> I would also encourage anyone in the WG thinking about implementing = this draft to speak up. If this set is not null, I would encourage = Praveen to move this draft to the Proposed Standard (preferred) or at = least Experimental track.
>
> Martin
> _______________________________________________
> 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


--
Junho Choi = <junho dot choi at gmail.com>
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_7C64D6E3-BC29-4D65-95E2-5E2C242CE344-- From nobody Wed Apr 29 15:09: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 7CD4C3A0871 for ; Wed, 29 Apr 2020 15:09:30 -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, 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=ham 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 B3bu3GQUcbEc for ; Wed, 29 Apr 2020 15:09:28 -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 5627E3A086D for ; Wed, 29 Apr 2020 15:09:28 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id h30so2486551vsr.5 for ; Wed, 29 Apr 2020 15:09:28 -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=TVir1X0pbP2yCijFsD+2gjRlqEj3HwcJ0+mjWS2qm8c=; b=tTO6boweY6FiMUpBEKWweWDSVDK7LjC6RdeQT7Q8DYLLM7YLmCi3TeNRh7DKMBrjJW pi9e0oLmHL5jVcvlj4+GQ6kHmjl/4skUaLukzwLjjf6U3Koy2jQH5uSI+x1ICLKT9E63 n11fjHRcwGKFRe3BKJZ+QA+IcBz6uUW9Ep6ambgpfwgpQ6pgUOlGzW4muu47icjI4yzV hVZkAKBeEoqlbFmTEMA4mm9YhFRq0ILA1GPjO6kqOeqNzRlT6ffKso7KgHDWGmg7QCjo EiyXHiQukQDIcGhR6sFAk3tqPVQ5n+8DnkxPHPEWqP2snltDtpbSVP7cO1FUZ9SI7c/X Odxg== 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=TVir1X0pbP2yCijFsD+2gjRlqEj3HwcJ0+mjWS2qm8c=; b=uBV1T7ymf3ZfV1HXCOTZE50Y7EAogIzJNRrMGrNboaunS9FwlST0ZmoSPRA3D0xScc ueacAxqAS+Et5f3uGCIjafRF0GwCll/ZUfHLYJqDYwpcxf1LgdczN52SK7NOctuqPqnc d/IZc2q/evc5kJEfvWDB6fqfKwVN9cWTlRwh3C67oPXVquFXe9fvxXMUwQ6olNUv0fRK Iv+9snQ3z7pLnOANU7AqUpPdxVR4Egz7SDE8OHIbqg+nLmEInNpJsMMguTKsXyu2nAjY +zLsHNCNDJIo+o2pXuHaYSrMUVb5zantT7QV5T1AE5dVJFQWqlz50c3rePPMg5MqMyrV YYng== X-Gm-Message-State: AGi0PubWuUuYtrv06dhXE+p0sJS6Nci48Oc0EcZDPua1yBfdXccyV2RL 5JyXvNhd9EspEfe53qoEjpS42yJ9cacrVyT+8vdFKOCShPM= X-Google-Smtp-Source: APiQypKsl58SjinQAdZRLJNjUwIZQgIchXiOvFja5XLDofDm9Jw2VMHY6fs7/Oztu1BkNFVAz6zJsA/SgU2Lj/LG9vY= X-Received: by 2002:a67:c20b:: with SMTP id i11mr628754vsj.134.1588198166860; Wed, 29 Apr 2020 15:09:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 29 Apr 2020 15:08:49 -0700 Message-ID: To: Martin Duke Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000091f90405a4753386" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 29 Apr 2020 22:09:31 -0000 --00000000000091f90405a4753386 Content-Type: text/plain; charset="UTF-8" btw it might be good to see the draft discusses applying it to other C.C. that uses ssthresh too in the draft, particularly RFC5681 reno On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng wrote: > +1 on adoption > > two questions > 1. RttSampleCount. Since the counter is incremented on a per ACK > basis, the receiver behavior may significantly influence the actual > hystart timeline. For example a receiver acking one full cwnd burst vs > acking every packet (or even every byte). it'd be good to clarify if > the intended rounds or time-scale in hystart++ design > > 2. "In practice, the Inter- Packet Arrival algorithm does not perform > well and is not able to detect congestion early, primarily due to ACK > compression." In my experience, another reason is it relies on packets > being pushed out in a window of burst in slow start. Therefore in > paced slow start (e.g. slow_start w/ linux fq/pacing) often produces > premature exit as well. I am curious if the authors have similar > experience? > > Lastly, I am a fan of the BBR startup algorithm for obvious reasons. > The algorithm can be easily ported to produce an ssthresh for > conventional C.C.. It'd be great to see some words describing the > difference and even some real comparisons. BBR startup definitely > requires a lot more states (e.g. to track bw) for example. so there > are pros & cons. > > On Wed, Apr 29, 2020 at 10:32 AM Martin Duke > wrote: > > > > I support adoption of this work. > > > > I would also encourage anyone in the WG thinking about implementing this > draft to speak up. If this set is not null, I would encourage Praveen to > move this draft to the Proposed Standard (preferred) or at least > Experimental track. > > > > Martin > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000091f90405a4753386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
btw it might be good to see the draft discusses applying i= t to other C.C. that uses ssthresh too in the draft, particularly RFC5681 r= eno

On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng <ycheng@google.com> wrote:
+1 on adoption

two questions
1. RttSampleCount. Since the counter is incremented on a per ACK
basis, the receiver behavior may significantly influence the actual
hystart timeline. For example a receiver acking one full cwnd burst vs
acking every packet (or even every byte). it'd be good to clarify if the intended rounds or time-scale in hystart++ design

2. "In practice, the Inter- Packet Arrival algorithm does not perform<= br> well and is not able to detect congestion early, primarily due to ACK
compression." In my experience, another reason is it relies on packets=
being pushed out in a window of burst in slow start. Therefore in
paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
premature exit as well. I am curious if the authors have similar
experience?

Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
The algorithm can be easily ported to produce an ssthresh for
conventional C.C.. It'd be great to see some words describing the
difference and even some real comparisons. BBR startup definitely
requires a lot more states (e.g. to track bw) for example. so there
are pros & cons.

On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com> wrote: >
> I support adoption of this work.
>
> I would also encourage anyone in the WG thinking about implementing th= is draft to speak up. If this set is not null, I would encourage Praveen to= move this draft to the Proposed Standard (preferred) or at least Experimen= tal track.
>
> Martin
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
--00000000000091f90405a4753386-- From nobody Wed Apr 29 19:30: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 B68BA3A0D7F for ; Wed, 29 Apr 2020 19:30:34 -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=ham 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 vJkU9nPn0Lv4 for ; Wed, 29 Apr 2020 19:30:24 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 9B99F3A0D7C for ; Wed, 29 Apr 2020 19:30:24 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id c24so1723224uap.13 for ; Wed, 29 Apr 2020 19:30:24 -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=pRvLz52uath2JnPpqBzfKQpeMj1AJ7IfFQUS27sbcEs=; b=LvqxC3H8TUL38EK6/I4mlaKjws1sjwquV8Tdx27zvz8IgXMfxGZnixDKrTFnSAxbFN qIO92Hdh+y2Cjm2HFy17hPyYTsqVT/DXEEFN5ui9w2CCfKS+j6XHtpD5oHp4D619HEw5 0RlpFKzzYKo3of1ThzaUI11B+HMJJ5hD+GMCbYHfKUszj6YRGMZORI0E+NOyIfWh3GgA 5owiCbXQTgqG5W7MJItCKVyeum9Hb2iqp83nthZYAEDvmSO3dg2e4X0dmlEaMeDI3TGJ 1nCliGKJmA6IUAEfXy54jn4iGeq3WaWbjqdwPATGPW94iQwiRXB0UgCO4e9qGDU4CVhb F8bQ== 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=pRvLz52uath2JnPpqBzfKQpeMj1AJ7IfFQUS27sbcEs=; b=Dd3k2ROyGdgWy8OdcL3Mlp18UGMTtg2Mx+yyoyVJ57Hu90XNCabMdPJBXn7q92+Ec7 dkgc7BBswsqZ/7w+Qx+bWW809i3s4UBWqPtK4144Vp0yeVzAUGhm4P1+MqwCXUeFssTg /CY4CkUdi8hIoy9hviyHRbh/6zh3X3NPpNZzWKT2IYGotqo1C2/M4/4U1/49uqvObGJS vLVhOaseXq+K46ORlco+8WDq1HlV3fvhlwJ3LlDlm80NRhgysQyWvQb5FjVKd2szZlVO 7Eq7n076yhUpOl9/Blcn/zrRLrIZWzgvnFU4LN32nN/E0UMJT4EFy2lebeKD+aIpb6Wl QxMw== X-Gm-Message-State: AGi0PuaR1asLkm82gJLU3k/yPDrWDbdpliINGTnU1o9Tqzd15ANkjZSh YYA4MZqO/UZ8mloM8PpqfdFSX7MDHLAKhbeWo3WIWg== X-Google-Smtp-Source: APiQypI2vIEsvqsBzHBpnh5BOQQ1xQh/A+vm6Km/XKnFwiAW8f+SzzrgxLnrDBrnMIlBafkxiWqQgk2J3mTJnmg136A= X-Received: by 2002:a9f:2065:: with SMTP id 92mr679023uam.33.1588213822660; Wed, 29 Apr 2020 19:30:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Wed, 29 Apr 2020 22:30:05 -0400 Message-ID: To: Yuchung Cheng Cc: Martin Duke , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 30 Apr 2020 02:30:35 -0000 I support adoption of this work as well. The HyStart++ algorithm has some nice improvements over the original delay-based HyStart mechanism. The draft already seems to do a nice job of stating the algorithm generically, without tying it to CUBIC. But I like Yuchung's idea to explicitly state that the algorithm can be used for Reno or CUBIC. neal On Wed, Apr 29, 2020 at 6:09 PM Yuchung Cheng wrote: > > btw it might be good to see the draft discusses applying it to other C.C. that uses ssthresh too in the draft, particularly RFC5681 reno > > On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng wrote: >> >> +1 on adoption >> >> two questions >> 1. RttSampleCount. Since the counter is incremented on a per ACK >> basis, the receiver behavior may significantly influence the actual >> hystart timeline. For example a receiver acking one full cwnd burst vs >> acking every packet (or even every byte). it'd be good to clarify if >> the intended rounds or time-scale in hystart++ design >> >> 2. "In practice, the Inter- Packet Arrival algorithm does not perform >> well and is not able to detect congestion early, primarily due to ACK >> compression." In my experience, another reason is it relies on packets >> being pushed out in a window of burst in slow start. Therefore in >> paced slow start (e.g. slow_start w/ linux fq/pacing) often produces >> premature exit as well. I am curious if the authors have similar >> experience? >> >> Lastly, I am a fan of the BBR startup algorithm for obvious reasons. >> The algorithm can be easily ported to produce an ssthresh for >> conventional C.C.. It'd be great to see some words describing the >> difference and even some real comparisons. BBR startup definitely >> requires a lot more states (e.g. to track bw) for example. so there >> are pros & cons. >> >> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke wrote: >> > >> > I support adoption of this work. >> > >> > I would also encourage anyone in the WG thinking about implementing this draft to speak up. If this set is not null, I would encourage Praveen to move this draft to the Proposed Standard (preferred) or at least Experimental track. >> > >> > Martin >> > _______________________________________________ >> > 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 Thu Apr 30 00:09: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 D1A033A09F3 for ; Thu, 30 Apr 2020 00:09:50 -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 dcL0vnn76hPS for ; Thu, 30 Apr 2020 00:09:49 -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 2F9833A09F1 for ; Thu, 30 Apr 2020 00:09:49 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id z1so3121325vsn.11 for ; Thu, 30 Apr 2020 00:09:49 -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=0g6V+Qj5+xbattY6V0rCVTh5SnQip20bdGhlY1XSgpI=; b=qL5IIFtVbSHsbVDQI+vqMyOncmqEJJefY/5QC9e/4rxjQkIm4NsZ/vXfxlt7BbCRiO XHm28tGlSCgyTAWEjtRAcZ0j7YfErv/3VC3kc+PCiv5AnI547/oSuibBAPnt+9gp0zeq jxkCDZWB+X8J14hfDjtntmDr6kyGVj0yrm36oGNt8PRwBwyIrfz5ZNnig4rgSsBzIXM0 OqOgyl1wL9kbxHFOurgXxktpULmXYc0+acmzjK6spUo7QMziOo+16vp0hQCHXva7rqNB l0hMLJ3N64/z3KBrVIbmbw2VAAJSmTTB8hIsHUZkOkPbadpVOs44VqzmXjg2UWe2rVSn 7L/A== 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=0g6V+Qj5+xbattY6V0rCVTh5SnQip20bdGhlY1XSgpI=; b=B+GRkhhlww9zVroKz3FaVb4rLc+bOIj0WtIEvEbcEw6JjgpUlSo1oX68j8ehrjjRwB ljpBqOigSLO4nzIMnGdlz7Pz9dqj+8ALzHFY2UV0kCsMSJX+4WRcpjLaD0ZtxJ1xAvHd kDJkKBNTekkBb3kDkAF3dXeJwjsWJBu0ES6WSD18vuqZLLROZgZ61DcjbZOh1BPy/al4 yHhD7qg7mmDAr+Jqtdu4RdecUY38neEVqiMFA7TafGTRrnoSkWROYJ+3DVn3aR9s+iDu 6DGk8AOPqZLZxKUw8ZDbJIeEyWcrIOCNkKKG6E1MGnmZBlhlpE+9sZJWKkwhd5qzfswB t9jg== X-Gm-Message-State: AGi0PuYXAUzFT6W0gkmaLnJEBtFUdpUsfY9zIBSMjhXyDHBjMRFpYP2z 7C4ulMhCdB8mZXHikbgpAj58c5HvVWk3qf9iIq9+LI9B X-Google-Smtp-Source: APiQypKLaMycpJDspY6KoeVRByk8y4hj2cYlFhdOhc+X5AAfAFz/dXFBVH8iCDto2XZl6yk0gLAYDE/LBBaKUCsMAyA= X-Received: by 2002:a67:f718:: with SMTP id m24mr1644370vso.236.1588230587888; Thu, 30 Apr 2020 00:09:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Junho Choi Date: Thu, 30 Apr 2020 00:09:11 -0700 Message-ID: To: Neal Cardwell Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000033aa005a47cc03e" Archived-At: Subject: Re: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03 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, 30 Apr 2020 07:09:51 -0000 --000000000000033aa005a47cc03e Content-Type: text/plain; charset="UTF-8" FYI, my HyStart++ implementation for quiche is just an option for slow start, so can be set for Reno and CUBIC both. On Wed, Apr 29, 2020 at 7:30 PM Neal Cardwell wrote: > I support adoption of this work as well. The HyStart++ algorithm has > some nice improvements over the original delay-based HyStart > mechanism. > > The draft already seems to do a nice job of stating the algorithm > generically, without tying it to CUBIC. But I like Yuchung's idea to > explicitly state that the algorithm can be used for Reno or CUBIC. > > neal > > On Wed, Apr 29, 2020 at 6:09 PM Yuchung Cheng > wrote: > > > > btw it might be good to see the draft discusses applying it to other > C.C. that uses ssthresh too in the draft, particularly RFC5681 reno > > > > On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng > wrote: > >> > >> +1 on adoption > >> > >> two questions > >> 1. RttSampleCount. Since the counter is incremented on a per ACK > >> basis, the receiver behavior may significantly influence the actual > >> hystart timeline. For example a receiver acking one full cwnd burst vs > >> acking every packet (or even every byte). it'd be good to clarify if > >> the intended rounds or time-scale in hystart++ design > >> > >> 2. "In practice, the Inter- Packet Arrival algorithm does not perform > >> well and is not able to detect congestion early, primarily due to ACK > >> compression." In my experience, another reason is it relies on packets > >> being pushed out in a window of burst in slow start. Therefore in > >> paced slow start (e.g. slow_start w/ linux fq/pacing) often produces > >> premature exit as well. I am curious if the authors have similar > >> experience? > >> > >> Lastly, I am a fan of the BBR startup algorithm for obvious reasons. > >> The algorithm can be easily ported to produce an ssthresh for > >> conventional C.C.. It'd be great to see some words describing the > >> difference and even some real comparisons. BBR startup definitely > >> requires a lot more states (e.g. to track bw) for example. so there > >> are pros & cons. > >> > >> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke > wrote: > >> > > >> > I support adoption of this work. > >> > > >> > I would also encourage anyone in the WG thinking about implementing > this draft to speak up. If this set is not null, I would encourage Praveen > to move this draft to the Proposed Standard (preferred) or at least > Experimental track. > >> > > >> > Martin > >> > _______________________________________________ > >> > 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 > -- Junho Choi --000000000000033aa005a47cc03e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, my HyStart++ implementation for quiche is just a= n option for slow start, so can be set for Reno and CUBIC both.
=
On Wed= , Apr 29, 2020 at 7:30 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
<= /div>
I support adoption o= f this work as well. The HyStart++ algorithm has
some nice improvements over the original delay-based HyStart
mechanism.

The draft already seems to do a nice job of stating the algorithm
generically, without tying it to CUBIC. But I like Yuchung's idea to explicitly state that the algorithm can be used for Reno or CUBIC.

neal

On Wed, Apr 29, 2020 at 6:09 PM Yuchung Cheng
<ycheng=3D40google.com@dmarc.ietf.org> wrote:
>
> btw it might be good to see the draft discusses applying it to other C= .C. that uses ssthresh too in the draft, particularly RFC5681 reno
>
> On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng <ycheng@google.com> wrote:
>>
>> +1 on adoption
>>
>> two questions
>> 1. RttSampleCount. Since the counter is incremented on a per ACK >> basis, the receiver behavior may significantly influence the actua= l
>> hystart timeline. For example a receiver acking one full cwnd burs= t vs
>> acking every packet (or even every byte). it'd be good to clar= ify if
>> the intended rounds or time-scale in hystart++ design
>>
>> 2. "In practice, the Inter- Packet Arrival algorithm does not= perform
>> well and is not able to detect congestion early, primarily due to = ACK
>> compression." In my experience, another reason is it relies o= n packets
>> being pushed out in a window of burst in slow start. Therefore in<= br> >> paced slow start (e.g. slow_start w/ linux fq/pacing) often produc= es
>> premature exit as well. I am curious if the authors have similar >> experience?
>>
>> Lastly, I am a fan of the BBR startup algorithm for obvious reason= s.
>> The algorithm can be easily ported to produce an ssthresh for
>> conventional C.C.. It'd be great to see some words describing = the
>> difference and even some real comparisons. BBR startup definitely<= br> >> requires a lot more states (e.g. to track bw) for example. so ther= e
>> are pros & cons.
>>
>> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <martin.h.duke@gmail.com>= wrote:
>> >
>> > I support adoption of this work.
>> >
>> > I would also encourage anyone in the WG thinking about implem= enting this draft to speak up. If this set is not null, I would encourage P= raveen to move this draft to the Proposed Standard (preferred) or at least = Experimental track.
>> >
>> > Martin
>> > _______________________________________________
>> > 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


--
Junho Choi <junho= dot choi at gmail.com&g= t;
--000000000000033aa005a47cc03e-- From nobody Thu Apr 30 00:31: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 4B1EA3A0A53 for ; Thu, 30 Apr 2020 00:31:48 -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 Sj087CF84puX for ; Thu, 30 Apr 2020 00:31:46 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 82EBB3A0A51 for ; Thu, 30 Apr 2020 00:31:46 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id v8so6739980wma.0 for ; Thu, 30 Apr 2020 00:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TAnCH2lJjnSeUmZqzXPvYSyKLMV5YIEiioXv5VjcflE=; b=dH7IetMgOjDJ5Yb5AiqNAQlMiE4egfD8SbiNhH5YIDrrpColokk3Qjq9IOgyErr/0e caFcrjOpk/yKkonSojYC4GhPKjzS4knGviwSgkAPMZU5g3OEmbgd27mWHjiqDJOZu9CI 499O4cyGUehweEJ7fojlcUQ6IdaCJtie7j923KZ5HgUMlb+WALwkx3z7JtYxcnjhtXry 3PO4sDOLA+9TeH8JSdNVkENFRqWJAcIapnGY27eTMcU2MvKXASa+DCE3mymyg2/ifbhA 0CzWXAMc69dIG7vF0wDiAs5i2I6MTOvBQo1Z5NVkA/KREGVqff3PmA5/SHrM9uJ2liaW hw/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TAnCH2lJjnSeUmZqzXPvYSyKLMV5YIEiioXv5VjcflE=; b=qWYJdRY06g2suRBZZkV0Aul+OEFOaSQTFE2jOJmucynl/npLnvZ+eO3CT7hOdmuSc8 j8pgjl/iIJYvMdzqgQwwPdosIWNvr8ealjShXDC2nCsfu96yHNiYcLamKjVRWgA+8yYK 6Bxq/XjCAzKauJRpieFsSi7uTADCq3mbFhQr2DW7Fv+ledjNwS7X5YawgJg+0mkZQPdH pQ/MKL0aOzgXv6w7aLeGoNl3QesnQhGxMH1iUZcq15zO8ALjNsoqkiBehEftDoHzn7SF PrriOC969rqzB/vjwW9LMFD2OudfHdqj1hGen/lUrfjgTrQc9I9OpDBqaVCG1B9CG+zP n0cg== X-Gm-Message-State: AGi0Pube1vCCP/5kiJW25j9FGsG1+jwfUgAGKvy6FWxJwAviyMZpc+S5 YD370GzhduFtpugWjot7A2hLlOtWxGdj+UYuMJT3mktIt+Y= X-Google-Smtp-Source: APiQypL4D1KyjyTkF9W6NfWU35OkALEhmZxKxnykLdm+gEBOBl+OsqHzsWhUzRBPcgGyVqHKYOxfo4LznQEnIOZkLyM= X-Received: by 2002:a05:600c:225a:: with SMTP id a26mr1441955wmm.104.1588231904409; Thu, 30 Apr 2020 00:31:44 -0700 (PDT) MIME-Version: 1.0 From: juhamatk@gmail.com Date: Thu, 30 Apr 2020 10:31:32 +0300 Message-ID: To: tcpm@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] RFC 5925 SNE algorithm concern 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, 30 Apr 2020 07:31:49 -0000 Hello all, While working with RFC 5925, I have been checking the details of example SNE algorithm. I have a slight concern with the example algorithm proposed by the RFC. The idea of SNE is to simulate 64-bit sequence number with 32-bit sequences to prevent replay attacks. RFC 5925 proposes the following algorithm to implement 64-bit sequence numbering: Original algorithm pseudo-code in the RFC 5925 + errata: /* set the flag when the SEG.SEQ first rolls over */ if ((RCV.SNE_FLAG == 0) && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { RCV.SNE = RCV.SNE + 1; RCV.SNE_FLAG = 1; } /* decide which SNE to use after incremented */ if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fffffff)) { SNE = RCV.SNE - 1; # use the pre-increment value } else { SNE = RCV.SNE; # use the current value } /* reset the flag in the *middle* of the window */ if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) { RCV.SNE_FLAG = 0; } /* save the current SEQ for the next time through the code */ RCV.PREV_SEQ = SEG.SEQ; When looking into this in detail, to me it looks like there might be an issue when 32-bit sequence wraps back to the beginning and a retransmission occurs with the high sequence range. Then SNE is increased unexpectedly and does not follow proper sequencing. A test case below: State: PREV_SEQ = 0xffffffe RCV.SNE = 0 RCV.SNE_FLAG = 0 New frame: SEG.SEQ = 0x0 RCV.SNE => 1 RCV.SNE_FLAG => 1 PREV_SEQ => 0 Retransmit: SEG.SEQ = 0xfffffffd RCV.SNE_FLAG => 0 - incorrectly updated PREV_SEQ => 0xfffffffd - incorrectly updated New frame: SEG.SEQ = 0x2 RCV.SNE => 2 - incorrect value, should be 1 based on sequencing RCV.SNE_FLAG => 1 PREV_SEQ => 0x2 I could not figure out any reason why the above sequence would not be valid. Even though it is mentioned in the RFC that the algorithm is just an example, the sequencing mismatch is unfortunate as mismatching SNEs on different sides will bring the authenticated TCP session down and cause data loss through timeout. Thus, for interoperability, it is crucial that correct sequencing is used on both ends. If above is really a real problem, then perhaps an improved algorithm could be as follows: Improved algorithm suggestion pseudo-code: PRE = 0; // set the flag when the SEG.SEQ first rolls over if ((RCV.SNE_FLAG == 0) && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { RCV.SNE = RCV.SNE + 1; RCV.SNE_FLAG = 1; } // decide which SNE to use after incremented, // pre-increment is used for retransmits if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fffffff)) { SNE = RCV.SNE - 1; # use the pre-increment value PRE = 1; } else { SNE = RCV.SNE; # use the current value } // reset the flag in the *middle* of the window, // include SEG.SEQ equals half so that we do not miss // that edge case if (PRE == 0) { if(RCV.SNE_FLAG == 1 && RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ >= 0x7fffffff)) { RCV.SNE_FLAG = 0; } // save the current SEQ for the next time through the code, // if we are not retransmitting RCV.PREV_SEQ = SEG.SEQ; } This passes the problematic case (and bunch of others I have tested). This also includes a small additional fix in the middle window handling where SEG.SEQ was missing one edge value (SEG.SEQ > 0x7fffffff => SEG.SEQ >= 0x7fffffff). I hope I have not missed anything else, but it is certainly possible, so comments are welcome. So, what do you think, is this a real concern? If it is a real issue, what would be the best way to handle this, perhaps an errata with an improved algorithm after throughout review of the new algorithm? Thank you, -- Juhamatti From nobody Thu Apr 30 01:36: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 DE0AF3A0BA9 for ; Thu, 30 Apr 2020 01:36:55 -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 95hzUX4TF5cC for ; Thu, 30 Apr 2020 01:36:53 -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 14EE63A0BA8 for ; Thu, 30 Apr 2020 01:36:52 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B02FE1B001AB; Thu, 30 Apr 2020 09:36:47 +0100 (BST) To: Bob Briscoe Cc: tcpm IETF list References: <8c3aca0d-0ea6-69f6-5ad8-fbdc984de77b@erg.abdn.ac.uk> <42a218f6-3d9d-25f1-9e00-476144b671fc@bobbriscoe.net> From: Gorry Fairhurst Message-ID: Date: Thu, 30 Apr 2020 09:36:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <42a218f6-3d9d-25f1-9e00-476144b671fc@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] A longer follow-up on my comment on draft-gomez-tcpm-delack-suppr-reqs 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, 30 Apr 2020 08:36:56 -0000 See some more explanation in line. On 29/04/2020 22:58, Bob Briscoe wrote: > Gorry, > > On 29/04/2020 18:54, Gorry Fairhurst wrote: >> >> >> First of all thank you for bringing this topic to the WG. I do think >> it is important that we discuss what ACKs are used for, how we expect >> them to be used and what the practical implications are for using >> ACKs across Internet paths. >> >> About the slides, I didn't have much time at the Mic. so maybe I >> sounded rather harsh, but I would suggest we do need to set a >> relatively high bar to adopting a piece of work in this space ... and >> we do need data and real understanding of what we are trying to fix >> and how we can avoid making it worse by accident in other cases. >> >> We went through a rather lengthy discussion in tsvwg on a similar >> (but different) topic regarding immediate negative acknowledgment for >> SCTP (RFC 7053- SACK-IMMEDIATELY Extension for SCTP) and found there >> were a few key places where for that protocol this did make sense. >> >> However, I actually don't believe your list of issues (i). Here is >> why... (I am interested if you think differently or know more). >> >> I've tried to roughly follow your points: >> >> * Slow start >> - I agree Delayed ACKs increase slow start, the more you delay the >> bigger the impact. However, the impact is for cases where ACKs are >> delayed on intervals comparable with or more than the Path RTT. > I appreciate you taking time to qualify your initial harsh words. I > would ask you to still take even more time over this review. People > listen to you on this subject, and I think you are glossing over large > areas of the issue too quickly. > >> - DAASS is a simple fix, that appears to help a lot when there is >> data waiting for the arrival of the delayed ACK. > > Any heuristic at the receiver to detect the end of a pattern of > start-up such as slow-start, ossifies that pattern into the Internet. > Sender control of the DelACK ratio removes that ossification. > I initially thought the same, DAASS tried to fix multiple problems. However, as regards DAASS  reducing the waiti for the ACK to a rounds of initial cwnd growth, I think the key understanding is the sender use of byte accounting (for stretch-ACKs) not individual ACKs, (that might imply a need for some burst-mitigation for stretch ACKs, because you reduce ACK clocking). I like what I understand Chrome's QUIC does:  In the first 100 received packets, send an ACK for each packet (could be each pair of packets).  This rapidly grows a cwnd of about 140 packets (assuming exponetial growth). Once the cwnd is >100 then an ACK covering 10 packets/segments becomes a small proportion of the cwnd (the additional delay from per-packet ACKs is small). The receiver can moves to a larger default ACK ratio. > >> ABC is important also (well what I think people understand by ABC - >> rather than the RFC on this). > > Yes. > >> * High bit rate environments and short data segments >> >> If you really don’t want delayed ACKs, the protocol using TCP ought >> to disable nagle. Or you would perhaps use DAASS... I’m not sure >> which problem you speak about? >> >> >> * Beyond classic ACK transmission behavior >> I do agree that Delayed ACKs preclude using sender behaviors intended >> to quickly and non-intrusively probe for available capacity during >> slow start. This is important to me, but I am very wary about the >> idea of sending more ACKs to do this, and we need to be careful to >> gain sufficient information about what the receiver has seen - not >> just to get a bunch of separate (each cumulative) ACKs. This really >> doesn’t give much fidelity to the sender. I’d be happy to talk more >> about what might be better! > > Indeed, ACK frames in QUIC that give the arrival times of data packets > are an alternative - as long as they are not stretched beyond the time > at which they would have been useful. > Interesting, I think. > But we are more limited for space in TCP. As long as a TCP server is > serving bulk and short flows, it can put more effort into receiving > more ACKs during flow startup, and save its processing power by using > less frequent ACKs for the majority of its data - transmitted in > congestion avoidance. > > Also seems true. >> * IoT scenarios >> I can see the argument of an ACK energy cost for the IoT device. At >> least, I would assume IoT devices can be tuned, and the apps they >> talk to can be tuned. Appropriate guidance helps! > > Tuning is for a scenario, not for widely differing scenarios. The > message of this draft is that a connection sometimes needs to be able > to adapt its ACK ratio at run-time. Not every IoT device is always > deployed for just one scenario. Neither is its peer. To me this says > adaptation mustn't be complex (and doesn't have to be). > Heterogeniety of the network segments is tricky. Some optimisations could be handled by link-specific methods - header compression perhaps is an example, other things need to be adapted end-to-end. However, end-to-end transport has to work for all types of path (links) - and often does not know the path. >> >> * Bursty Apps >> I think you can add varying workloads as something important. By >> which I mean apps that do transactional stuff, or are controlled by >> applications where the data transmission need varies.When we looked >> at CWV and the ideas that the applications control the traffic >> patterns in one group of applications, we also noted that these >> applications change the way they use the network. That’s important >> for a timely restart to growing the cwnd (etc). Such applications can >> also be very sensitive to network delay.  These are probably also of >> interest! > > Yes. > >> >> So....  the reason for hesitancy overall is I see this as tricky >> space to get correct. > > But trickiness is the point of starting this requirements document, > isn't it? > Please can you articulate better why you seem negative about this > exercise? >> >> There are many places where fewer ACKs are good - if you have per ACK >> interrupt costs - if the capacity consumed by ACKs is important - the >> cost of sending in the link technology is high - etc. This is >> complicated for TCP (and much less so for QUIC - because QUIC has a >> notion of pacing; QUIC’s loss recovery is different; and QUIC’s ACKs >> are not easily thinned, at least at present). Any TCP method has to >> live with networks that experience pain from more ACKs, but also may >> deploy (various) mitigations. > > Yes. But reading between the lines I hear you say "Don't start this > exercise". > Pls explicitly articulate your implicit message. > The slide asked about adopting this work - my words were against doing that at that time with that revision of this document. I miss seeing presentations with results and showing the thinking. I  wonder if we need a specific agenda slot to focus on such topics. I expect we'll learn a lot from some data from a variety of problem-spaces/use-cases, especially if the timeslot is sufficient to include thinking and experience from people outside of TCPM. (That's another thought - and probably should be another thread). >> >> There are also cases where you’d like more information than a delayed >> ACK provides (e.g. chirping and similar probing methods) and there >> are application pathologies that would love an ACK at the end of a >> packet burst (be that 1 or 100s of packets). Any method has to live >> with a wide variety of paths and applications. >> >> Happy to discuss more. And I suspect other people may also respond on >> list. We have lots of data for QUIC and TCP - but most of our data >> focusses on testbeds or on actual broadband satellite services. > > Thanks for elaborating. > > > > Bob Gorry > > >> >> Gorry >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Apr 30 02:06: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 0F9D33A0C27 for ; Thu, 30 Apr 2020 02:06:36 -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, HTML_MESSAGE=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 josKRWoFe2Eb for ; Thu, 30 Apr 2020 02:06:34 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 2CB933A0C26 for ; Thu, 30 Apr 2020 02:06:34 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id l25so3321144vso.6 for ; Thu, 30 Apr 2020 02:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E9Nd3tmVz3g++SPxMqhcvUEX4QK07zkxTm1sryy7V9c=; b=Njfqdb1i2OMprb2EuEmZ2jvCbI3L1xbPIuIW9tMSyH3uknrtZkr/81517/lCHXJsqV Ab6UX5VDWbsXXdijwLqbvodt7vO7yeWiX3YFGPGoaBAdfwrFMV+Nip5ntfpbpEQ3lh9q e3O+mDzZiogEcYrOasJZhzBXqANmsgMY+HDF0ra6LntsgKkqa06PYdmR+DSIx1AYmVSO egako24iEouoXHRDSn6xNi68JJmUMaUrIrSCFrTUZQO9JsuSSLv4p4IHN6U5FVBLr6GT 4pZ4lxiKYMWEvScBC0Um/QOOhL6INtrvTi9vZg48W3Edo/1CbhJd2cM5CGEAtAfisCu3 Xivw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E9Nd3tmVz3g++SPxMqhcvUEX4QK07zkxTm1sryy7V9c=; b=J/Mm7KEvhAhkto4iadWJ0kAzSPEHCJwR2dJTmshIvP+h4ItnAxcUPSo1PheFs5MUb6 NK7wmIQ7J/4XBRtX/mfBKaa6nGe5rqDUBFzVYQ8lzfynvGfIJOM1oQyjvti64vv5Xs9+ dYABaAt6pluFp+gi26AXlf0DxcGC5X7icje7E+OjoWzJase4C/9t1xm01c/m+XMXGUhC tUBwC1QOzhpFMF8j8RVUS4GVagN4hJGXPgsIKk2Ju/oaHzjam7bcd3e9WKTlqK3WTlET GUqIRysu5fEhP+8qZS0zc8vlHTNTeKlcPtax0yzrEbKiXs2ZX5QTXSuOkLm9Ua0J6iXR r+NQ== X-Gm-Message-State: AGi0PuaigaKW0S5hALrcHvmoVbZ7Yj72fSnxojspAcDoWeqsGVyynT/W wzeD6U/bfffuC6Et9rkvGmITclHSiPAn/QsewDSZ3A== X-Google-Smtp-Source: APiQypJeueXhAPdLZbGmwCszrKXZn+ffWXmR7eB0lrhVXHHXCeZ9t53FZlCNa4sVZmA4o5Hkq2YI5dL04dwoPUKHCaU= X-Received: by 2002:a05:6102:3d2:: with SMTP id n18mr2109996vsq.157.1588237592554; Thu, 30 Apr 2020 02:06:32 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Thu, 30 Apr 2020 02:06:21 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="00000000000085f15005a47e61d8" Archived-At: Subject: [tcpm] bit length for byte counter fields in accurate ecn 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, 30 Apr 2020 09:06:37 -0000 --00000000000085f15005a47e61d8 Content-Type: text/plain; charset="UTF-8" Hi, I am still a bit wondering about the length of the field for the byte counter. In my understanding, the length of the counter is (at least) 32 bits and encoded into 24 bits field. So, I am thinking that reducing the bit size doesn't affect accuracy directly while the potential risks for miscalculation will be increased. Is this incorrect? Thanks, -- Yoshi --00000000000085f15005a47e61d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I am still a bit wondering about the length=C2=A0o= f the field for the byte counter.
In my understanding, the length= =C2=A0of the counter is (at least) 32 bits and encoded into 24 bits field.<= br>
So, I am thinking that reducing the bit size doesn't affe= ct accuracy directly while the potential risks for miscalculation will be i= ncreased. Is this incorrect?

Thanks,
--<= /div>
Yoshi=C2=A0
--00000000000085f15005a47e61d8-- From nobody Thu Apr 30 07:31: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 3E4BB3A08FA for ; Thu, 30 Apr 2020 07:31:26 -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 4z3Hyg5GQ4s8 for ; Thu, 30 Apr 2020 07:31:24 -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 129753A08F8 for ; Thu, 30 Apr 2020 07:31:23 -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=KaBBnuWk7OtLSpzNtxbLTW20JsXqbQ/5wytAqJe3PrI=; b=k+Cb3FsKMGsYcP/3vOoPFOmIQ N13hhEQbdxEpqsFMzu4k29V1H2JGHoaYpb46LxF8cDx0L/bKOt0+RxGJ7llXeNE8k2Y2ug7fQSznh cZbIPVgL5Ugr9fSjXgN2EhCL0qGVoG/bmt5dWwhvAeVgZ29wFfRFafXBg0SwWmgbOC66TqUSw33AV /V9kmXtC7651kSMko7EmstIvkw7XA73XBChipMxOGEN1BWT4/xMp9r2E6rPBRDzTtiYwLOAwnGamn mHaJi2SzoZqbhBiupzZ9gcEG9CNM/9mo28dxz8sBAgY4Pz4NkFvkkGEDfMscTK/GnzAkruPrDPf31 q+er1VS2A==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62288 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 1jUADf-003nhl-76; Thu, 30 Apr 2020 10:31:23 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Joseph Touch In-Reply-To: Date: Thu, 30 Apr 2020 07:31:18 -0700 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: juhamatk@gmail.com X-Mailer: Apple Mail (2.3608.60.0.2.5) 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] RFC 5925 SNE algorithm concern 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, 30 Apr 2020 14:31:28 -0000 Hi, Juhamatti, See embedded below: > On Apr 30, 2020, at 12:31 AM, juhamatk@gmail.com wrote: >=20 > Hello all, >=20 > While working with RFC 5925, I have been checking the details of > example SNE algorithm. I have a slight concern with the example > algorithm proposed by the RFC. >=20 > The idea of SNE is to simulate 64-bit sequence number with 32-bit > sequences to prevent replay attacks. RFC 5925 proposes the following > algorithm to implement 64-bit sequence numbering: >=20 > Original algorithm pseudo-code in the RFC 5925 + errata: > /* set the flag when the SEG.SEQ first rolls over */ > if ((RCV.SNE_FLAG =3D=3D 0) > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { > RCV.SNE =3D RCV.SNE + 1; > RCV.SNE_FLAG =3D 1; > } > /* decide which SNE to use after incremented */ > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { > SNE =3D RCV.SNE - 1; # use the pre-increment value > } else { > SNE =3D RCV.SNE; # use the current value > } > /* reset the flag in the *middle* of the window */ > if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) { > RCV.SNE_FLAG =3D 0; > } > /* save the current SEQ for the next time through the code */ > RCV.PREV_SEQ =3D SEG.SEQ; >=20 > When looking into this in detail, to me it looks like there might be > an issue when 32-bit sequence wraps back to the beginning and a > retransmission occurs with the high sequence range. Retransmission should always use the value cached with that segment, so = there should not be an issue. > Then SNE is > increased unexpectedly and does not follow proper sequencing. A test > case below: >=20 > State: > PREV_SEQ =3D 0xffffffe > RCV.SNE =3D 0 > RCV.SNE_FLAG =3D 0 >=20 > New frame: > SEG.SEQ =3D 0x0 > RCV.SNE =3D> 1 > RCV.SNE_FLAG =3D> 1 > PREV_SEQ =3D> 0 >=20 > Retransmit: > SEG.SEQ =3D 0xfffffffd > RCV.SNE_FLAG =3D> 0 - incorrectly updated > PREV_SEQ =3D> 0xfffffffd - incorrectly updated You=E2=80=99re using the pseudocode that creates new SNEs with a = previously transmitted value. It=E2=80=99s acting like you=E2=80=99ve = wrapped too quickly.=20 >=20 > New frame: > SEG.SEQ =3D 0x2 > RCV.SNE =3D> 2 - incorrect value, should be 1 based on sequencing > RCV.SNE_FLAG =3D> 1 > PREV_SEQ =3D> 0x2 >=20 > I could not figure out any reason why the above sequence would not be > valid. Because retransmission should be using the values cached when the = original transmission occurred. I don=E2=80=99t think the new code is needed - at least from this = example. Joe > Even though it is mentioned in the RFC that the algorithm is > just an example, the sequencing mismatch is unfortunate as mismatching > SNEs on different sides will bring the authenticated TCP session down > and cause data loss through timeout. Thus, for interoperability, it is > crucial that correct sequencing is used on both ends. >=20 > If above is really a real problem, then perhaps an improved algorithm > could be as follows: >=20 > Improved algorithm suggestion pseudo-code: > PRE =3D 0; > // set the flag when the SEG.SEQ first rolls over > if ((RCV.SNE_FLAG =3D=3D 0) > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { > RCV.SNE =3D RCV.SNE + 1; > RCV.SNE_FLAG =3D 1; > } > // decide which SNE to use after incremented, > // pre-increment is used for retransmits > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { > SNE =3D RCV.SNE - 1; # use the pre-increment value > PRE =3D 1; > } else { > SNE =3D RCV.SNE; # use the current value > } > // reset the flag in the *middle* of the window, > // include SEG.SEQ equals half so that we do not miss > // that edge case > if (PRE =3D=3D 0) { > if(RCV.SNE_FLAG =3D=3D 1 && > RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ >=3D 0x7fffffff)) { > RCV.SNE_FLAG =3D 0; > } > // save the current SEQ for the next time through the code, > // if we are not retransmitting > RCV.PREV_SEQ =3D SEG.SEQ; > } >=20 > This passes the problematic case (and bunch of others I have tested). > This also includes a small additional fix in the middle window > handling where SEG.SEQ was missing one edge value (SEG.SEQ > > 0x7fffffff =3D> SEG.SEQ >=3D 0x7fffffff). I hope I have not missed > anything else, but it is certainly possible, so comments are welcome. >=20 > So, what do you think, is this a real concern? If it is a real issue, > what would be the best way to handle this, perhaps an errata with an > improved algorithm after throughout review of the new algorithm? >=20 > Thank you, > -- > Juhamatti >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Apr 30 07:36:48 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 E6E333A08FB; Thu, 30 Apr 2020 07:36: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 DuQUtjonLo59; Thu, 30 Apr 2020 07:36: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 424B63A005D; Thu, 30 Apr 2020 07:36:44 -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=2bn1LxlIug0Ad5FsxK8bQjaizNaJwOk8h1bBPv/T7KU=; b=ahXNs7+OQgk/0uLHH0WwHqVv7 El0iegRuaC2o9NIstePmFETpNlU0h5C2sXoM01l08cA8DRMvCd7ZLeoH7Ydy8Nn8tIufwNXpepoMN H5WzcNuT+BWXPiGxPmmyQ6L/riY4EZybLl3I8A3K7T38TlaZvkCV9AXSo99AAgvjIruNzSgGifoM7 J3oKkvbQE+NRX+4tPUk2mpU4RVMIgU2wOqduXR1IaxBjFe51ihuxtscq1PxqYsbElV9bGZKmtCmBo oh0Vc9pZzSp+tF4UJJgUWg5yuiMwwI4285g3AByaozqSiwn+Sa1+IV2aiEycmIQuQbOYM6/HN2SDq 2nTA5zWYQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62357 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 1jUAIp-003uj0-Kg; Thu, 30 Apr 2020 10:36:43 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Joseph Touch In-Reply-To: <158819618671.32088.3115018826349552828@ietfa.amsl.com> Date: Thu, 30 Apr 2020 07:36:38 -0700 Cc: i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <81C3C043-1D1F-400B-9824-F83909E55EAA@strayalpha.com> References: <158819618671.32088.3115018826349552828@ietfa.amsl.com> To: tcpm IETF list X-Mailer: Apple Mail (2.3608.60.0.2.5) 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] I-D Action: draft-ietf-tcpm-2140bis-05.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, 30 Apr 2020 14:36:46 -0000 Hi, all, The recent updates are corrections to typos, re-center of table formats, = a more complete terminology section, and a pass for consistency, a pass = to remove informal notes to the WG, and a check for use of updated RFCs. Nothing substantive was intended to change. Joe > On Apr 29, 2020, at 2:36 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : TCP Control Block Interdependence > Authors : Joe Touch > Michael Welzl > Safiqul Islam > Filename : draft-ietf-tcpm-2140bis-05.txt > Pages : 33 > Date : 2020-04-29 From nobody Thu Apr 30 09:44: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 EDBA53A0C2C for ; Thu, 30 Apr 2020 09:44:01 -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 gu4e2gU_ok_G for ; Thu, 30 Apr 2020 09:43:59 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 0AB453A0C2A for ; Thu, 30 Apr 2020 09:43:59 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id u127so2747540wmg.1 for ; Thu, 30 Apr 2020 09:43:58 -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=Y8d4AWjgUJJ37iz0RHDNhAVPV07VDb6HMU5MFd36JNo=; b=HtJXW0cyqV1buxOrOjn8MsfQuyJ2yJgM6V5hvQUGDYF9VBbRjqCvQfVSSbj691Xgu4 QbUjvIsqLgitrsNsrcyO5JmHcE2mcC/FhEznAa0v9Vrtq2lxoLAZqUuf85GCbpn6srZa mbPRTNFMEOW6AxRaoviVweka5iDhp/vu03i1PGcP2alQPVuyyAnwzvnl0qLSXDFNczpn 9yIQh3AkRCd7KpIvnQjoCu4ZBW8epZkhOpMilvX/KN0Q/Yc4zeB6NM7moaCryVw1gUCn DAAC+kv3Km09rrkOHrxCn+NsTS90wRSOdibCct1mooYUMh+lpTlS3REFVjq8VDtkXVfQ uHuw== 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=Y8d4AWjgUJJ37iz0RHDNhAVPV07VDb6HMU5MFd36JNo=; b=i6lpJSX1KtsAWAreXH/QOiIDK1+JpvYxx3YDohXtztRq4KgV1JgtsRzoNsj98qCogw KGouPTS8WzyCxB4zgYXS2gFk96hozs6HJ7WPH4be76Cbp6rta3CS2DgLP4UDf3mxtoh2 N/qa+0Wj1R9NpcrB8yELIwC8Ta/f5F8yVPQhJAmwUnEC0/z+WEHzceUFnyCvWwj0IjCY T/tZ1FMnl+PdhU7rGDGKl9YniTiMAWUI9ImGEW7q/GrltEE3b7hwG8Qfb7uo1rsg2Y8p kENdCpBHGOMnCEP37q80oq1s1L8xZ7dkMQXX9sttAZc2IanpmRfnqoCfPJ2r0jzxLZLT iS1g== X-Gm-Message-State: AGi0PuYIHF28AHar5ij4rMytba27TtPs/CpdfIznP4NRv9xPZMIqvDaV aFPDwRMO8NQWvECVisKpHTuARYx5QiPVqN4zpMY= X-Google-Smtp-Source: APiQypJVURU6pB9OuYZ60Wnxa9uOB8jrNNgDfhIHuh4nnnRAI8H5/mcNWam/MMH9GBBVehIMKl4QCHxQjwfb13yLA+w= X-Received: by 2002:a1c:e90a:: with SMTP id q10mr3877647wmc.22.1588265037365; Thu, 30 Apr 2020 09:43:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: juhamatk@gmail.com Date: Thu, 30 Apr 2020 19:43:45 +0300 Message-ID: To: Joseph Touch Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary="0000000000005c848705a484c568" Archived-At: Subject: Re: [tcpm] RFC 5925 SNE algorithm concern 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, 30 Apr 2020 16:44:03 -0000 --0000000000005c848705a484c568 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Joe, Thanks for your reply. While I talk about retransmit, I refer actually to the other side retransmitting. So this is the receive side pseudo code. Does that change the situation? Thanks for the clarifications, -- Juhamatti to 30. huhtikuuta 2020 klo 17.31 Joseph Touch kirjoitti: > Hi, Juhamatti, > > See embedded below: > > > On Apr 30, 2020, at 12:31 AM, juhamatk@gmail.com wrote: > > > > Hello all, > > > > While working with RFC 5925, I have been checking the details of > > example SNE algorithm. I have a slight concern with the example > > algorithm proposed by the RFC. > > > > The idea of SNE is to simulate 64-bit sequence number with 32-bit > > sequences to prevent replay attacks. RFC 5925 proposes the following > > algorithm to implement 64-bit sequence numbering: > > > > Original algorithm pseudo-code in the RFC 5925 + errata: > > /* set the flag when the SEG.SEQ first rolls over */ > > if ((RCV.SNE_FLAG =3D=3D 0) > > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { > > RCV.SNE =3D RCV.SNE + 1; > > RCV.SNE_FLAG =3D 1; > > } > > /* decide which SNE to use after incremented */ > > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { > > SNE =3D RCV.SNE - 1; # use the pre-increment value > > } else { > > SNE =3D RCV.SNE; # use the current value > > } > > /* reset the flag in the *middle* of the window */ > > if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) { > > RCV.SNE_FLAG =3D 0; > > } > > /* save the current SEQ for the next time through the code */ > > RCV.PREV_SEQ =3D SEG.SEQ; > > > > When looking into this in detail, to me it looks like there might be > > an issue when 32-bit sequence wraps back to the beginning and a > > retransmission occurs with the high sequence range. > > Retransmission should always use the value cached with that segment, so > there should not be an issue. > > > Then SNE is > > increased unexpectedly and does not follow proper sequencing. A test > > case below: > > > > State: > > PREV_SEQ =3D 0xffffffe > > RCV.SNE =3D 0 > > RCV.SNE_FLAG =3D 0 > > > > New frame: > > SEG.SEQ =3D 0x0 > > RCV.SNE =3D> 1 > > RCV.SNE_FLAG =3D> 1 > > PREV_SEQ =3D> 0 > > > > Retransmit: > > SEG.SEQ =3D 0xfffffffd > > RCV.SNE_FLAG =3D> 0 - incorrectly updated > > PREV_SEQ =3D> 0xfffffffd - incorrectly updated > > You=E2=80=99re using the pseudocode that creates new SNEs with a previous= ly > transmitted value. It=E2=80=99s acting like you=E2=80=99ve wrapped too qu= ickly. > > > > > New frame: > > SEG.SEQ =3D 0x2 > > RCV.SNE =3D> 2 - incorrect value, should be 1 based on sequencing > > RCV.SNE_FLAG =3D> 1 > > PREV_SEQ =3D> 0x2 > > > > I could not figure out any reason why the above sequence would not be > > valid. > > Because retransmission should be using the values cached when the origina= l > transmission occurred. > > I don=E2=80=99t think the new code is needed - at least from this example= . > > Joe > > > Even though it is mentioned in the RFC that the algorithm is > > just an example, the sequencing mismatch is unfortunate as mismatching > > SNEs on different sides will bring the authenticated TCP session down > > and cause data loss through timeout. Thus, for interoperability, it is > > crucial that correct sequencing is used on both ends. > > > > If above is really a real problem, then perhaps an improved algorithm > > could be as follows: > > > > Improved algorithm suggestion pseudo-code: > > PRE =3D 0; > > // set the flag when the SEG.SEQ first rolls over > > if ((RCV.SNE_FLAG =3D=3D 0) > > && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff)) { > > RCV.SNE =3D RCV.SNE + 1; > > RCV.SNE_FLAG =3D 1; > > } > > // decide which SNE to use after incremented, > > // pre-increment is used for retransmits > > if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ > 0x7fffffff)) { > > SNE =3D RCV.SNE - 1; # use the pre-increment value > > PRE =3D 1; > > } else { > > SNE =3D RCV.SNE; # use the current value > > } > > // reset the flag in the *middle* of the window, > > // include SEG.SEQ equals half so that we do not miss > > // that edge case > > if (PRE =3D=3D 0) { > > if(RCV.SNE_FLAG =3D=3D 1 && > > RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ >=3D 0x7fffffff)) { > > RCV.SNE_FLAG =3D 0; > > } > > // save the current SEQ for the next time through the code, > > // if we are not retransmitting > > RCV.PREV_SEQ =3D SEG.SEQ; > > } > > > > This passes the problematic case (and bunch of others I have tested). > > This also includes a small additional fix in the middle window > > handling where SEG.SEQ was missing one edge value (SEG.SEQ > > > 0x7fffffff =3D> SEG.SEQ >=3D 0x7fffffff). I hope I have not missed > > anything else, but it is certainly possible, so comments are welcome. > > > > So, what do you think, is this a real concern? If it is a real issue, > > what would be the best way to handle this, perhaps an errata with an > > improved algorithm after throughout review of the new algorithm? > > > > Thank you, > > -- > > Juhamatti > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > --0000000000005c848705a484c568 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello = Joe,

Thanks for your reply. While I talk a= bout retransmit, I refer actually to the other side retransmitting. So this= is the receive side pseudo code. Does that change the situation?

Thanks for the clarifications,
--
=C2=A0Juhamatti

to= 30. huhtikuuta 2020 klo 17.31 Joseph Touch <touch@strayalpha.com> kirjoitti:
Hi, Juhamatti,

See embedded below:

> On Apr 30, 2020, at 12:31 AM, juhamatk@gmail.com wrote:
>
> Hello all,
>
> While working with RFC 5925, I have been checking the details of
> example SNE algorithm. I have a slight concern with the example
> algorithm proposed by the RFC.
>
> The idea of SNE is to simulate 64-bit sequence number with 32-bit
> sequences to prevent replay attacks. RFC 5925 proposes the following > algorithm to implement 64-bit sequence numbering:
>
> Original algorithm pseudo-code in the RFC 5925 + errata:
>=C2=A0 =C2=A0 =C2=A0/* set the flag when the SEG.SEQ first rolls over *= /
>=C2=A0 =C2=A0 =C2=A0if ((RCV.SNE_FLAG =3D=3D 0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 && (RCV.PREV_SEQ > 0x7fffffff) &= amp;& (SEG.SEQ < 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RCV.SNE =3D RCV.SNE + 1;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RCV.SNE_FLAG =3D 1;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0/* decide which SNE to use after incremented */
>=C2=A0 =C2=A0 =C2=A0if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ >= ; 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SNE =3D RCV.SNE - 1; # use the pre-incremen= t value
>=C2=A0 =C2=A0 =C2=A0} else {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SNE =3D RCV.SNE; # use the current value >=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0/* reset the flag in the *middle* of the window */<= br> >=C2=A0 =C2=A0 =C2=A0if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.= SEQ > 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RCV.SNE_FLAG =3D 0;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0/* save the current SEQ for the next time through t= he code */
>=C2=A0 =C2=A0 =C2=A0RCV.PREV_SEQ =3D SEG.SEQ;
>
> When looking into this in detail, to me it looks like there might be > an issue when 32-bit sequence wraps back to the beginning and a
> retransmission occurs with the high sequence range.

Retransmission should always use the value cached with that segment, so the= re should not be an issue.

> Then SNE is
> increased unexpectedly and does not follow proper sequencing. A test > case below:
>
> State:
> PREV_SEQ =3D 0xffffffe
> RCV.SNE =3D 0
> RCV.SNE_FLAG =3D 0
>
> New frame:
> SEG.SEQ =3D 0x0
> RCV.SNE =3D> 1
> RCV.SNE_FLAG =3D> 1
> PREV_SEQ =3D> 0
>
> Retransmit:
> SEG.SEQ =3D 0xfffffffd
> RCV.SNE_FLAG =3D> 0 - incorrectly updated
> PREV_SEQ =3D> 0xfffffffd - incorrectly updated

You=E2=80=99re using the pseudocode that creates new SNEs with a previously= transmitted value. It=E2=80=99s acting like you=E2=80=99ve wrapped too qui= ckly.

>
> New frame:
> SEG.SEQ =3D 0x2
> RCV.SNE =3D> 2 - incorrect value, should be 1 based on sequencing > RCV.SNE_FLAG =3D> 1
> PREV_SEQ =3D> 0x2
>
> I could not figure out any reason why the above sequence would not be<= br> > valid.

Because retransmission should be using the values cached when the original = transmission occurred.

I don=E2=80=99t think the new code is needed - at least from this example.<= br>
Joe

> Even though it is mentioned in the RFC that the algorithm is
> just an example, the sequencing mismatch is unfortunate as mismatching=
> SNEs on different sides will bring the authenticated TCP session down<= br> > and cause data loss through timeout. Thus, for interoperability, it is=
> crucial that correct sequencing is used on both ends.
>
> If above is really a real problem, then perhaps an improved algorithm<= br> > could be as follows:
>
> Improved algorithm suggestion pseudo-code:
>=C2=A0 =C2=A0 =C2=A0PRE =3D 0;
>=C2=A0 =C2=A0 =C2=A0// set the flag when the SEG.SEQ first rolls over >=C2=A0 =C2=A0 =C2=A0if ((RCV.SNE_FLAG =3D=3D 0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 && (RCV.PREV_SEQ > 0x7fffffff) &= amp;& (SEG.SEQ < 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RCV.SNE =3D RCV.SNE + 1;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RCV.SNE_FLAG =3D 1;
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0// decide which SNE to use after incremented,
>=C2=A0 =C2=A0 =C2=A0// pre-increment is used for retransmits
>=C2=A0 =C2=A0 =C2=A0if ((RCV.SNE_FLAG =3D=3D 1) && (SEG.SEQ >= ; 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SNE =3D RCV.SNE - 1; # use the pre-incremen= t value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 PRE =3D 1;
>=C2=A0 =C2=A0 =C2=A0} else {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SNE =3D RCV.SNE; # use the current value >=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0// reset the flag in the *middle* of the window, >=C2=A0 =C2=A0 =C2=A0// include SEG.SEQ equals half so that we do not mi= ss
>=C2=A0 =C2=A0 =C2=A0// that edge case
>=C2=A0 =C2=A0 =C2=A0if (PRE =3D=3D 0) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(RCV.SNE_FLAG =3D=3D 1 &&
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RCV.PREV_SEQ < 0x7fffffff) = && (SEG.SEQ >=3D 0x7fffffff)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RCV.SNE_FLAG =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // save the current SEQ for the next time t= hrough the code,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // if we are not retransmitting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RCV.PREV_SEQ =3D SEG.SEQ;
>=C2=A0 =C2=A0 =C2=A0}
>
> This passes the problematic case (and bunch of others I have tested).<= br> > This also includes a small additional fix in the middle window
> handling where SEG.SEQ was missing one edge value (SEG.SEQ >
> 0x7fffffff =3D> SEG.SEQ >=3D 0x7fffffff). I hope I have not miss= ed
> anything else, but it is certainly possible, so comments are welcome.<= br> >
> So, what do you think, is this a real concern? If it is a real issue,<= br> > what would be the best way to handle this, perhaps an errata with an > improved algorithm after throughout review of the new algorithm?
>
> Thank you,
> --
> Juhamatti
>
> _______________________________________________
> tcpm mailing list
> = tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm=

--0000000000005c848705a484c568-- From nobody Thu Apr 30 12:31:04 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 185DF3A1196; Thu, 30 Apr 2020 12:30:28 -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: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <158827502797.6042.15313343958284896274@ietfa.amsl.com> Date: Thu, 30 Apr 2020 12:30:28 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-11.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 19:30:29 -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-11.txt Pages : 10 Date : 2020-04-30 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-11 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/