From nobody Tue Jul 9 02:33:58 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2651203DB for ; Tue, 9 Jul 2019 02:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KTklubqfEMYZ for ; Tue, 9 Jul 2019 02:33:53 -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 AFB011200B6 for ; Tue, 9 Jul 2019 02:33:53 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B0483B404C01EF2EF261 for ; Tue, 9 Jul 2019 10:33:51 +0100 (IST) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Jul 2019 10:33:51 +0100 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 9 Jul 2019 10:33:51 +0100 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 9 Jul 2019 10:33:50 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.66]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Tue, 9 Jul 2019 17:33:47 +0800 From: Liyizhou To: "loops@ietf.org" CC: "mohamed.boucadair@orange.com" , "JACQUENET Christian TGI/OLN" , wangjl1.bri Thread-Topic: I-D Action: draft-li-tsvwg-loops-problem-opportunities-03.txt Thread-Index: AQHVNTGndyQCrR3bqU6JvakVksrZYKbCA7qQ Date: Tue, 9 Jul 2019 09:33:47 +0000 Message-ID: References: <156255152178.5046.9972414026058286353@ietfa.amsl.com> In-Reply-To: <156255152178.5046.9972414026058286353@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.186.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [LOOPS] FW: I-D Action: draft-li-tsvwg-loops-problem-opportunities-03.txt X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 09:33:56 -0000 Hi all, We have uploaded a revision of problem statement and opportunities draft.=20 A new use case about "Enterprise Branch Office WAN Connection" has been add= ed. vCPE has enabled some value added service to be provided from provider = network. Path selection over Internet from vCPE to either public cloud virt= ual PoP or to another vCPE is in the progress of deployment, say possibly v= ia SRv6. Some segments of path suffers from packet loss. Local in-network r= ecovery can help in this case to provide higher quality Internet connection= in terms of loss rate and recovery. It also sounds like part of SDWAN scen= ario.=20 Do you think it is an applicable case that LOOPS should also focus on? Rgds, Yizhou -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, July 08, 2019 10:05 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-li-tsvwg-loops-problem-opportunities-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : LOOPS (Localized Optimizations on Path Segments) = Problem Statement and Opportunities for Network-Assisted Performance Enhanc= ement Authors : Yizhou Li Xingwang Zhou Mohamed Boucadair Jianglong Wang Filename : draft-li-tsvwg-loops-problem-opportunities-03.txt Pages : 24 Date : 2019-07-07 Abstract: In various network deployments, end to end forwarding paths are partitioned into multiple segments. For example, in some cloud-based WAN communications, stitching multiple overlay tunnels are used for traffic policy enforcement matters such as to optimize traffic distribution or to select paths exposing a lower latency. Likewise, in satellite communications, the communication path is decomposed into two terrestrial segments and a satellite segment. Such long- haul paths are naturally composed of multiple network segments with various encapsulation schemes. Packet loss may show different characteristics on different segments. Traditional transport protocols (e.g., TCP) respond to packet loss slowly especially in long-haul networks: they either wait for some signal from the receiver to indicate a loss and then retransmit from the sender or rely on sender's timeout which is often quite long. Non-congestive loss may make the TCP sender over-reduce the sending rate unnecessarily. With the increase of end-to-end transport encryption (e.g., QUIC), traditional PEP (performance enhancing proxy) techniques such as TCP splitting are no longer applicable. LOOPS (Local Optimizations on Path Segments) is a network-assisted performance enhancement over path segment and it aims to provide local in-network recovery to achieve better data delivery by making packet loss recovery faster and by avoiding the senders over-reducing their sending rate. In an overlay network scenario, LOOPS can be performed over a variety of the existing, or purposely created, tunnel-based path segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-li-tsvwg-loops-problem-opportunities= / There are also htmlized versions available at: https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03 https://datatracker.ietf.org/doc/html/draft-li-tsvwg-loops-problem-opportun= ities-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-li-tsvwg-loops-problem-opportunit= ies-03 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From nobody Thu Jul 11 14:00:28 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64C1120159 for ; Thu, 11 Jul 2019 14:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, 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 YMaAyJIGIrsA for ; Thu, 11 Jul 2019 14:00:24 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 69764120143 for ; Thu, 11 Jul 2019 14:00:24 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id 16so7175479ljv.10 for ; Thu, 11 Jul 2019 14:00:24 -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=PKXcLMH7E9cFYXNFeDyAkhqT7Yids1KayikneaQNLZ0=; b=rZIYUS5LTS7n62NkQU1BbUtJvQ0uBz1Wh+WTIinOr1cG8VJ8s78/yjHHFA/L559LWE aqGQBsgOl4GD2kO5DX55/I6kg0TD+I6nJJMlRoPAYa9HX7bBXOXrZySVI+8sPV4OP2yq 7klLGBt364hhufrKF9Vp/e7KI+WZSNFxbkVLa0auJtZlzSbqD9D9X7UteaRriTS42i4V IGHO9gcjG6Hp+Sc84dwUBDql6zKyTJUiD/NBlWJ0x0X6yPK5fFt7z3r0kT/dKlLwEWf8 dfiglnRTRwgsUBzedeXpDQXKC+VaOg2klZnY7ou/xqxbhvBEmmn0WzhTYhcGvXp8TtXn zatA== 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=PKXcLMH7E9cFYXNFeDyAkhqT7Yids1KayikneaQNLZ0=; b=bwJQ/Wk7Go1ryH9xYjmbd9RtKkQueMcBSHVgdIKwKDN9cY8K4/IUVSFATIRMjecQ8K ASYEDGMwHVUzmtM+iEjSrMQ2kjnn5FZk4YJyFlYyGorZGpt/M4A5dE+7gvuJNjJOUu7j 7B5IJTIzMOwX7vF0MHI3+8V2/K1UcIkSk4frAh2nDwOIVgUzf1q8RNg3mgNr6n4ieXOQ Qqx3uEWDZF5xcWyGG8e3TD+JnRL7zqrXLt2bwMhv9f9D0GxNCd4ZqqZ1yx1QlJMy6RkN RRONOynl/D5yjlHjFfe6x4cByR+pgnIL+OMO0OaTn5Zp7Iq9y2/CYjUqjDu+kYzDV81o pg3w== X-Gm-Message-State: APjAAAVHHCWzE0f9NAfhtVVJTSLr7EGXKPf3cDebnJIciYmYRwErInW/ VLWfO3sZ7XTfmDtzBcb3KKPxVcmscIR3DceedWyby0Cj X-Google-Smtp-Source: APXvYqxMidviMqHJPAY6ttbX0f9Jzta/AfOZykTfyhO/lDyTt7+2EXpaC7+4R+lN7+MfaHW8/CoTKIuo38TlpuTdULA= X-Received: by 2002:a2e:5b1b:: with SMTP id p27mr3615214ljb.97.1562878822298; Thu, 11 Jul 2019 14:00:22 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Thu, 11 Jul 2019 15:59:56 -0500 Message-ID: To: loops@ietf.org Cc: Ole Troan Content-Type: multipart/alternative; boundary="00000000000007bb80058d6e150c" Archived-At: Subject: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:00:27 -0000 --00000000000007bb80058d6e150c Content-Type: text/plain; charset="UTF-8" Dear LOOPSers. We've been talking about the agenda for LOOPS at IETF 105 in private messages, but should be having that discussion on the mailing list. I've just uploaded https://datatracker.ietf.org/meeting/105/materials/agenda-105-loops-00 to the datatracker. It's subject to change, of course, and if you have agenda-bashing thoughts, Ole and I would love to have that discussion on the mailing list before 10:00-12:00 Monday Morning session I on July 22, so please send those thoughts to the list! Travel safely if you're traveling, and Meetecho safely if you'll be attending remotely. Spencer and Ole, as co-chairs --00000000000007bb80058d6e150c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear LOOPSers.=C2=A0

We've been tal= king about the agenda for LOOPS at IETF 105 in private messages, but should= be having that discussion on the mailing list.=C2=A0

<= div>I've just uploaded=C2=A0https://datatracker.ietf.org/meetin= g/105/materials/agenda-105-loops-00 to the datatracker. It's subjec= t to change, of course, and if you have agenda-bashing thoughts, Ole and I = would love to have that discussion on the mailing list before 10:00-12:00 M= onday Morning session I on July 22, so please send those thoughts to the li= st!

Travel safely if you're traveling, and Mee= techo safely if you'll be attending remotely.=C2=A0

Spencer and Ole, as co-chairs
--00000000000007bb80058d6e150c-- From nobody Thu Jul 11 14:45:26 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8E12009E for ; Thu, 11 Jul 2019 14:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWW1St30J6WC for ; Thu, 11 Jul 2019 14:45:22 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 C14E4120156 for ; Thu, 11 Jul 2019 14:45:21 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hlgsR-0004Ln-Ak; Thu, 11 Jul 2019 23:45:19 +0200 Received: from ti0182q160-3005.bb.online.no ([62.16.247.223] helo=[10.0.0.5]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hlgsQ-0001XX-LE; Thu, 11 Jul 2019 23:45:19 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-CD5D5E85-B112-45D0-B70F-8F9B22D058B9 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Thu, 11 Jul 2019 23:45:17 +0200 Cc: loops@ietf.org, Ole Troan Content-Transfer-Encoding: 7bit Message-Id: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> References: To: Spencer Dawkins at IETF X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.5]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.1, required=5.0, autolearn=disabled, AWL=-0.083, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AF9C0FC2FE734EFAAA6623ABBCAB9458050350CA Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:45:25 -0000 --Apple-Mail-CD5D5E85-B112-45D0-B70F-8F9B22D058B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi, if i understand this right, my slot is 10 minutes and that doesn=E2=80=99t s= eem realistic to me. 20? Sent from my iPhone > On 11 Jul 2019, at 22:59, Spencer Dawkins at IETF wrote: >=20 > Dear LOOPSers.=20 >=20 > We've been talking about the agenda for LOOPS at IETF 105 in private messa= ges, but should be having that discussion on the mailing list.=20 >=20 > I've just uploaded https://datatracker.ietf.org/meeting/105/materials/agen= da-105-loops-00 to the datatracker. It's subject to change, of course, and i= f you have agenda-bashing thoughts, Ole and I would love to have that discus= sion on the mailing list before 10:00-12:00 Monday Morning session I on July= 22, so please send those thoughts to the list! >=20 > Travel safely if you're traveling, and Meetecho safely if you'll be attend= ing remotely.=20 >=20 > Spencer and Ole, as co-chairs > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops --Apple-Mail-CD5D5E85-B112-45D0-B70F-8F9B22D058B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi,

if i understand this= right, my slot is 10 minutes and that doesn=E2=80=99t seem realistic to me.= 20?


Sent from m= y iPhone

On 11 Jul 2019, at 22:59, Spencer Dawkins= at IETF <spencerdawkins= .ietf@gmail.com> wrote:

Dear LOOPSers. 

We've be= en talking about the agenda for LOOPS at IETF 105 in private messages, but s= hould be having that discussion on the mailing list. 

I've just uploaded https://datatracker.ietf.org/meeting/= 105/materials/agenda-105-loops-00 to the datatracker. It's subject to ch= ange, of course, and if you have agenda-bashing thoughts, Ole and I would lo= ve to have that discussion on the mailing list before 10:00-12:00 Monday Mor= ning session I on July 22, so please send those thoughts to the list!
<= div>
Travel safely if you're traveling, and Meetecho safely if= you'll be attending remotely. 

Spencer and Ol= e, as co-chairs
= --Apple-Mail-CD5D5E85-B112-45D0-B70F-8F9B22D058B9-- From nobody Tue Jul 16 01:42:30 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5966120150 for ; Tue, 16 Jul 2019 01:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4_wxcY2qvuAV for ; Tue, 16 Jul 2019 01:42:25 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFCF12004F for ; Tue, 16 Jul 2019 01:42:25 -0700 (PDT) Received: from [192.168.217.110] (p548DCE40.dip0.t-ipconnect.de [84.141.206.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45nv670Hdpz108Z; Tue, 16 Jul 2019 10:42:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> Date: Tue, 16 Jul 2019 10:42:22 +0200 Cc: Spencer Dawkins at IETF , Ole Troan , loops@ietf.org X-Mao-Original-Outgoing-Id: 584959340.3604521-1b5a99aaf0edc8fad8b578d5abec25d8 Content-Transfer-Encoding: quoted-printable Message-Id: References: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 08:42:29 -0000 On Jul 11, 2019, at 23:45, Michael Welzl wrote: >=20 > hi, >=20 > if i understand this right, my slot is 10 minutes and that doesn=E2=80=99= t seem realistic to me. 20? I=E2=80=99m not sure we have 20, but we can move over 5 minutes from the = first use case presentation. (Maybe another 2 or 3 from the =E2=80=9Crelated work=E2=80=9D part.) So this could be: Time Topic Responsible Time used Time Remaining 10 Introduction, Scribe Kidnapping, and Agenda Bashing Chairs = 10 110 10 "What is LOOPS?=E2=80=9D = Carsten 20 100 10 Main use case [1] Yizhou = 30 90 10 Two specific use cases (2) = 40 80 18 Solution sketch [2] Michael = 58 62 12 Related work that is not LOOPS, for context Carsten? = 70 50 20 Technical discussion=E2=80=A6 = All 90 30 20 Whether and where to do this work in the IETF All = 110 10 10 Questions and hums for the AD Chairs = 120 0 [1] draft-li-tsvwg-loops-problem-opportunities-03 [2] draft-welzl-loops-gen-info-00 Right now, we plan to have an administrative discussion on Saturday = morning near the Hackathon (say, 09:00; some of us will not yet be = there, notably Michael). This could then morph into a few technical = discussion groups, with potential changes being discussed to the slides = (so it would be good to have them available before Saturday morning). On Sunday 09:00 we could then have a slide review meeting (including = Michael). All these pre-meetings are not meant to be long. We=E2=80=99ll have = then informally, around the Hackathon [3] where most of us are involved = in one thing or another already. If you haven=E2=80=99t registered for = that: You still can (at no cost to you) at = https://www.ietf.org/registration/ietf105/hackathonregistration.py [3]: https://www.ietf.org/how/runningcode/hackathons/105-hackathon/ Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 16 02:07:01 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FE112017A for ; Tue, 16 Jul 2019 02:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZihdoCScCvLq for ; Tue, 16 Jul 2019 02:06:56 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 9FB43120150 for ; Tue, 16 Jul 2019 02:06:56 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hnJQ8-000CG7-94; Tue, 16 Jul 2019 11:06:48 +0200 Received: from ti0182q160-3005.bb.online.no ([62.16.247.223] helo=[10.0.0.2]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hnJQ7-0008SV-4f; Tue, 16 Jul 2019 11:06:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: Date: Tue, 16 Jul 2019 11:06:45 +0200 Cc: Spencer Dawkins , Ole Troan , loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9F47075F-DEF4-4A20-BEA4-D5FE7832AF97@ifi.uio.no> References: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 77B3B5B5ECCF887B6F0263BDE094EDDD3F89D229 Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 09:06:59 -0000 > On Jul 16, 2019, at 10:42 AM, Carsten Bormann wrote: >=20 > On Jul 11, 2019, at 23:45, Michael Welzl wrote: >>=20 >> hi, >>=20 >> if i understand this right, my slot is 10 minutes and that doesn=E2=80=99= t seem realistic to me. 20? >=20 > I=E2=80=99m not sure we have 20, but we can move over 5 minutes from = the first use case presentation. > (Maybe another 2 or 3 from the =E2=80=9Crelated work=E2=80=9D part.) >=20 > So this could be: >=20 > Time Topic Responsible Time used Time Remaining > 10 Introduction, Scribe Kidnapping, and Agenda Bashing Chairs = 10 110 > 10 "What is LOOPS?=E2=80=9D = Carsten 20 100 > 10 Main use case [1] Yizhou = 30 90 > 10 Two specific use cases (2) = 40 80 > 18 Solution sketch [2] Michael = 58 62 > 12 Related work that is not LOOPS, for context Carsten? = 70 50 > 20 Technical discussion=E2=80=A6 = All 90 30 > 20 Whether and where to do this work in the IETF All = 110 10 > 10 Questions and hums for the AD Chairs = 120 0 >=20 > [1] draft-li-tsvwg-loops-problem-opportunities-03 > [2] draft-welzl-loops-gen-info-00 ACK: that works for me. Thanks! (and I=E2=80=99ll do my best to be efficient) > Right now, we plan to have an administrative discussion on Saturday = morning near the Hackathon (say, 09:00; some of us will not yet be = there, notably Michael). Sorry. > This could then morph into a few technical discussion groups, with = potential changes being discussed to the slides (so it would be good to = have them available before Saturday morning). >=20 > On Sunday 09:00 we could then have a slide review meeting (including = Michael). ACK. > All these pre-meetings are not meant to be long. We=E2=80=99ll have = then informally, around the Hackathon [3] where most of us are involved = in one thing or another already. If you haven=E2=80=99t registered for = that: You still can (at no cost to you) at = https://www.ietf.org/registration/ietf105/hackathonregistration.py >=20 > [3]: https://www.ietf.org/how/runningcode/hackathons/105-hackathon/ >=20 > Gr=C3=BC=C3=9Fe, Carsten I hadn=E2=80=99t; done now, thanks for the hint. Cheers, Michael From nobody Tue Jul 16 04:02:08 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4694112032B for ; Tue, 16 Jul 2019 04:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qLAvK4-A-DKU for ; Tue, 16 Jul 2019 04:02:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29109120328 for ; Tue, 16 Jul 2019 04:02:04 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 45nyCG5Dm9z605Z; Tue, 16 Jul 2019 13:02:02 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.62]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45nyCG3FrPzyPk; Tue, 16 Jul 2019 13:02:02 +0200 (CEST) Received: from OPEXCNORMAE.corporate.adroot.infra.ftgroup ([fe80::897f:9a74:3898:db87]) by OPEXCNORM2E.corporate.adroot.infra.ftgroup ([fe80::c505:acb8:89e0:c6d6%20]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 13:02:02 +0200 From: To: Michael Welzl CC: "loops@ietf.org" Thread-Topic: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded Thread-Index: AQHVOCutNoycKCZ2AUePLb86PEA+/6bF0f2AgAcA6QCAAAbQgIAAO3Fg Date: Tue, 16 Jul 2019 11:02:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EC8B3F1@OPEXCNORMAE.corporate.adroot.infra.ftgroup> References: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> <9F47075F-DEF4-4A20-BEA4-D5FE7832AF97@ifi.uio.no> In-Reply-To: <9F47075F-DEF4-4A20-BEA4-D5FE7832AF97@ifi.uio.no> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 11:02:06 -0000 SGkgTWljaGFlbCwNCg0KRldJVywgc29tZSBpbnB1dHMgdG8geW91ciBzbG90IG1heSBiZSBmb3Vu ZCBhdCAoIlNrZXRjaGluZyBhIFdvcmsgRGlyZWN0aW9uOiBSYXRpb25hbGUgJiBHb2FscyIpIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9w cG9ydHVuaXRpZXMtMDMjc2VjdGlvbi0xLjIuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBMT09QUyBbbWFpbHRvOmxvb3BzLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWljaGFlbCBXZWx6bA0KPiBFbnZvecOpwqA6IG1hcmRp IDE2IGp1aWxsZXQgMjAxOSAxMTowNw0KPiDDgMKgOiBDYXJzdGVuIEJvcm1hbm4NCj4gQ2PCoDog T2xlIFRyb2FuOyBTcGVuY2VyIERhd2tpbnM7IGxvb3BzQGlldGYub3JnDQo+IE9iamV0wqA6IFJl OiBbTE9PUFNdIERyYWZ0IExPT1BTIGFnZW5kYSBmb3IgSUVURiAxMDUgdXBsb2FkZWQNCj4gDQo+ IA0KPiANCj4gPiBPbiBKdWwgMTYsIDIwMTksIGF0IDEwOjQyIEFNLCBDYXJzdGVuIEJvcm1hbm4g PGNhYm9AdHppLm9yZz4gd3JvdGU6DQo+ID4NCj4gPiBPbiBKdWwgMTEsIDIwMTksIGF0IDIzOjQ1 LCBNaWNoYWVsIFdlbHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KPiA+Pg0KPiA+PiBo aSwNCj4gPj4NCj4gPj4gaWYgaSB1bmRlcnN0YW5kIHRoaXMgcmlnaHQsIG15IHNsb3QgaXMgMTAg bWludXRlcyBhbmQgdGhhdCBkb2VzbuKAmXQgc2VlbQ0KPiByZWFsaXN0aWMgdG8gbWUuIDIwPw0K PiA+DQo+ID4gSeKAmW0gbm90IHN1cmUgd2UgaGF2ZSAyMCwgYnV0IHdlIGNhbiBtb3ZlIG92ZXIg NSBtaW51dGVzIGZyb20gdGhlIGZpcnN0DQo+IHVzZSBjYXNlIHByZXNlbnRhdGlvbi4NCj4gPiAo TWF5YmUgYW5vdGhlciAyIG9yIDMgZnJvbSB0aGUg4oCccmVsYXRlZCB3b3Jr4oCdIHBhcnQuKQ0K PiA+DQo+ID4gU28gdGhpcyBjb3VsZCBiZToNCj4gPg0KPiA+IFRpbWUJVG9waWMJUmVzcG9uc2li bGUJVGltZSB1c2VkCVRpbWUgUmVtYWluaW5nDQo+ID4gMTAJSW50cm9kdWN0aW9uLCBTY3JpYmUg S2lkbmFwcGluZywgYW5kIEFnZW5kYSBCYXNoaW5nCUNoYWlycwkxMA0KPiAJMTEwDQo+ID4gMTAJ IldoYXQgaXMgTE9PUFM/4oCdCQkJCQlDYXJzdGVuCTIwCTEwMA0KPiA+IDEwCU1haW4gdXNlIGNh c2UgWzFdCQkJCQlZaXpob3UJMzAJOTANCj4gPiAxMAlUd28gc3BlY2lmaWMgdXNlIGNhc2VzCQkJ CQkoMikJNDAJODANCj4gPiAxOAlTb2x1dGlvbiBza2V0Y2ggWzJdCQkJCQlNaWNoYWVsCTU4CTYy DQo+ID4gMTIJUmVsYXRlZCB3b3JrIHRoYXQgaXMgbm90IExPT1BTLCBmb3IgY29udGV4dAlDYXJz dGVuPwk3MAk1MA0KPiA+IDIwCVRlY2huaWNhbCBkaXNjdXNzaW9u4oCmCQkJCQlBbGwJOTAJMzAN Cj4gPiAyMAlXaGV0aGVyIGFuZCB3aGVyZSB0byBkbyB0aGlzIHdvcmsgaW4gdGhlIElFVEYJCUFs bAkxMTAJMTANCj4gPiAxMAlRdWVzdGlvbnMgYW5kIGh1bXMgZm9yIHRoZSBBRAkJCQlDaGFpcnMJ MTIwCTANCj4gPg0KPiA+IFsxXSBkcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVu aXRpZXMtMDMNCj4gPiBbMl0gZHJhZnQtd2VsemwtbG9vcHMtZ2VuLWluZm8tMDANCj4gDQo+IEFD SzogdGhhdCB3b3JrcyBmb3IgbWUuIFRoYW5rcyENCj4gKGFuZCBJ4oCZbGwgZG8gbXkgYmVzdCB0 byBiZSBlZmZpY2llbnQpDQo+IA0KPiANCj4gPiBSaWdodCBub3csIHdlIHBsYW4gdG8gaGF2ZSBh biBhZG1pbmlzdHJhdGl2ZSBkaXNjdXNzaW9uIG9uIFNhdHVyZGF5DQo+IG1vcm5pbmcgbmVhciB0 aGUgSGFja2F0aG9uICAoc2F5LCAwOTowMDsgc29tZSBvZiB1cyB3aWxsIG5vdCB5ZXQgYmUgdGhl cmUsDQo+IG5vdGFibHkgTWljaGFlbCkuDQo+IA0KPiBTb3JyeS4NCj4gDQo+IA0KPiA+ICBUaGlz IGNvdWxkIHRoZW4gbW9ycGggaW50byBhIGZldyB0ZWNobmljYWwgZGlzY3Vzc2lvbiBncm91cHMs IHdpdGgNCj4gcG90ZW50aWFsIGNoYW5nZXMgYmVpbmcgZGlzY3Vzc2VkIHRvIHRoZSBzbGlkZXMg KHNvIGl0IHdvdWxkIGJlIGdvb2QgdG8NCj4gaGF2ZSB0aGVtIGF2YWlsYWJsZSBiZWZvcmUgU2F0 dXJkYXkgbW9ybmluZykuDQo+ID4NCj4gPiBPbiBTdW5kYXkgMDk6MDAgd2UgY291bGQgdGhlbiBo YXZlIGEgc2xpZGUgcmV2aWV3IG1lZXRpbmcgKGluY2x1ZGluZw0KPiBNaWNoYWVsKS4NCj4gDQo+ IEFDSy4NCj4gDQo+IA0KPiA+IEFsbCB0aGVzZSBwcmUtbWVldGluZ3MgYXJlIG5vdCBtZWFudCB0 byBiZSBsb25nLiAgV2XigJlsbCBoYXZlIHRoZW4NCj4gaW5mb3JtYWxseSwgYXJvdW5kIHRoZSBI YWNrYXRob24gWzNdIHdoZXJlIG1vc3Qgb2YgdXMgYXJlIGludm9sdmVkIGluIG9uZQ0KPiB0aGlu ZyBvciBhbm90aGVyIGFscmVhZHkuICBJZiB5b3UgaGF2ZW7igJl0IHJlZ2lzdGVyZWQgZm9yIHRo YXQ6IFlvdSBzdGlsbA0KPiBjYW4gKGF0IG5vIGNvc3QgdG8geW91KSBhdA0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vaWV0ZjEwNS9oYWNrYXRob25yZWdpc3RyYXRpb24ucHkN Cj4gPg0KPiA+IFszXTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaG93L3J1bm5pbmdjb2RlL2hhY2th dGhvbnMvMTA1LWhhY2thdGhvbi8NCj4gPg0KPiA+IEdyw7zDn2UsIENhcnN0ZW4NCj4gDQo+IA0K PiBJIGhhZG7igJl0OyBkb25lIG5vdywgdGhhbmtzIGZvciB0aGUgaGludC4NCj4gDQo+IENoZWVy cywNCj4gTWljaGFlbA0KPiANCj4gLS0NCj4gTE9PUFMgbWFpbGluZyBsaXN0DQo+IExPT1BTQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== From nobody Tue Jul 16 04:11:57 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC581203F6 for ; Tue, 16 Jul 2019 04:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xzaAOj_v_1U for ; Tue, 16 Jul 2019 04:11:52 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC0212004D for ; Tue, 16 Jul 2019 04:11:52 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hnLN7-0006Ma-P3; Tue, 16 Jul 2019 13:11:49 +0200 Received: from ti0182q160-3005.bb.online.no ([62.16.247.223] helo=[10.0.0.2]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hnLN6-000FTU-Je; Tue, 16 Jul 2019 13:11:49 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EC8B3F1@OPEXCNORMAE.corporate.adroot.infra.ftgroup> Date: Tue, 16 Jul 2019 13:11:47 +0200 Cc: "loops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> <9F47075F-DEF4-4A20-BEA4-D5FE7832AF97@ifi.uio.no> <787AE7BB302AE849A7480A190F8B93302EC8B3F1@OPEXCNORMAE.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 49A412E8018A0F8A6F21EF0CE6BF4FE4C197B711 Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 11:11:56 -0000 Ok, thanks! > On Jul 16, 2019, at 1:02 PM, mohamed.boucadair@orange.com wrote: >=20 > Hi Michael, >=20 > FWIW, some inputs to your slot may be found at ("Sketching a Work = Direction: Rationale & Goals") = https://tools.ietf.org/html/draft-li-tsvwg-loops-problem-opportunities-03#= section-1.2. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : LOOPS [mailto:loops-bounces@ietf.org] De la part de Michael = Welzl >> Envoy=C3=A9 : mardi 16 juillet 2019 11:07 >> =C3=80 : Carsten Bormann >> Cc : Ole Troan; Spencer Dawkins; loops@ietf.org >> Objet : Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded >>=20 >>=20 >>=20 >>> On Jul 16, 2019, at 10:42 AM, Carsten Bormann wrote: >>>=20 >>> On Jul 11, 2019, at 23:45, Michael Welzl wrote: >>>>=20 >>>> hi, >>>>=20 >>>> if i understand this right, my slot is 10 minutes and that = doesn=E2=80=99t seem >> realistic to me. 20? >>>=20 >>> I=E2=80=99m not sure we have 20, but we can move over 5 minutes from = the first >> use case presentation. >>> (Maybe another 2 or 3 from the =E2=80=9Crelated work=E2=80=9D part.) >>>=20 >>> So this could be: >>>=20 >>> Time Topic Responsible Time used Time Remaining >>> 10 Introduction, Scribe Kidnapping, and Agenda Bashing Chairs = 10 >> 110 >>> 10 "What is LOOPS?=E2=80=9D = Carsten 20 100 >>> 10 Main use case [1] Yizhou = 30 90 >>> 10 Two specific use cases (2) = 40 80 >>> 18 Solution sketch [2] Michael = 58 62 >>> 12 Related work that is not LOOPS, for context Carsten? = 70 50 >>> 20 Technical discussion=E2=80=A6 = All 90 30 >>> 20 Whether and where to do this work in the IETF All = 110 10 >>> 10 Questions and hums for the AD Chairs = 120 0 >>>=20 >>> [1] draft-li-tsvwg-loops-problem-opportunities-03 >>> [2] draft-welzl-loops-gen-info-00 >>=20 >> ACK: that works for me. Thanks! >> (and I=E2=80=99ll do my best to be efficient) >>=20 >>=20 >>> Right now, we plan to have an administrative discussion on Saturday >> morning near the Hackathon (say, 09:00; some of us will not yet be = there, >> notably Michael). >>=20 >> Sorry. >>=20 >>=20 >>> This could then morph into a few technical discussion groups, with >> potential changes being discussed to the slides (so it would be good = to >> have them available before Saturday morning). >>>=20 >>> On Sunday 09:00 we could then have a slide review meeting (including >> Michael). >>=20 >> ACK. >>=20 >>=20 >>> All these pre-meetings are not meant to be long. We=E2=80=99ll have = then >> informally, around the Hackathon [3] where most of us are involved in = one >> thing or another already. If you haven=E2=80=99t registered for = that: You still >> can (at no cost to you) at >> https://www.ietf.org/registration/ietf105/hackathonregistration.py >>>=20 >>> [3]: https://www.ietf.org/how/runningcode/hackathons/105-hackathon/ >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> I hadn=E2=80=99t; done now, thanks for the hint. >>=20 >> Cheers, >> Michael >>=20 >> -- >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops From nobody Tue Jul 16 21:33:59 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62180120058 for ; Tue, 16 Jul 2019 21:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 e7xH9liOIIK7 for ; Tue, 16 Jul 2019 21:33:54 -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 A97C912000F for ; Tue, 16 Jul 2019 21:33:54 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 37DBF31EFB9483480735; Wed, 17 Jul 2019 05:33:52 +0100 (IST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 17 Jul 2019 05:33:51 +0100 Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 17 Jul 2019 05:33:51 +0100 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 17 Jul 2019 05:33:51 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.51]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Wed, 17 Jul 2019 12:33:46 +0800 From: Liyizhou To: Carsten Bormann , Michael Welzl CC: Ole Troan , Spencer Dawkins at IETF , "loops@ietf.org" Thread-Topic: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded Thread-Index: AQHVOCu1tVuQDIKIg0K+ffi5MtL+xabFbWeAgAcA6gCAAdI9MA== Date: Wed, 17 Jul 2019 04:33:46 +0000 Message-ID: References: <371AA0CB-21CB-458C-BBB8-D3F3BA56FC41@ifi.uio.no> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.186.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Draft LOOPS agenda for IETF 105 uploaded X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2019 04:33:57 -0000 VGltZSB3b3JrcyBmb3IgbWUuIFdpbGwgYmUgdGhlcmUuDQoNCllpemhvdQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTE9PUFMgW21haWx0bzpsb29wcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE2 LCAyMDE5IDQ6NDIgUE0NClRvOiBNaWNoYWVsIFdlbHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+DQpD YzogT2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz47IFNwZW5jZXIgRGF3a2lucyBhdCBJ RVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT47IGxvb3BzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW0xPT1BTXSBEcmFmdCBMT09QUyBhZ2VuZGEgZm9yIElFVEYgMTA1IHVwbG9hZGVk DQoNCk9uIEp1bCAxMSwgMjAxOSwgYXQgMjM6NDUsIE1pY2hhZWwgV2VsemwgPG1pY2hhd2VAaWZp LnVpby5ubz4gd3JvdGU6DQo+IA0KPiBoaSwNCj4gDQo+IGlmIGkgdW5kZXJzdGFuZCB0aGlzIHJp Z2h0LCBteSBzbG90IGlzIDEwIG1pbnV0ZXMgYW5kIHRoYXQgZG9lc27igJl0IHNlZW0gcmVhbGlz dGljIHRvIG1lLiAyMD8NCg0KSeKAmW0gbm90IHN1cmUgd2UgaGF2ZSAyMCwgYnV0IHdlIGNhbiBt b3ZlIG92ZXIgNSBtaW51dGVzIGZyb20gdGhlIGZpcnN0IHVzZSBjYXNlIHByZXNlbnRhdGlvbi4N CihNYXliZSBhbm90aGVyIDIgb3IgMyBmcm9tIHRoZSDigJxyZWxhdGVkIHdvcmvigJ0gcGFydC4p DQoNClNvIHRoaXMgY291bGQgYmU6DQoNClRpbWUJVG9waWMJUmVzcG9uc2libGUJVGltZSB1c2Vk CVRpbWUgUmVtYWluaW5nDQoxMAlJbnRyb2R1Y3Rpb24sIFNjcmliZSBLaWRuYXBwaW5nLCBhbmQg QWdlbmRhIEJhc2hpbmcJQ2hhaXJzCTEwCTExMA0KMTAJIldoYXQgaXMgTE9PUFM/4oCdCQkJCQlD YXJzdGVuCTIwCTEwMA0KMTAJTWFpbiB1c2UgY2FzZSBbMV0JCQkJCVlpemhvdQkzMAk5MA0KMTAJ VHdvIHNwZWNpZmljIHVzZSBjYXNlcwkJCQkJKDIpCTQwCTgwDQoxOAlTb2x1dGlvbiBza2V0Y2gg WzJdCQkJCQlNaWNoYWVsCTU4CTYyDQoxMglSZWxhdGVkIHdvcmsgdGhhdCBpcyBub3QgTE9PUFMs IGZvciBjb250ZXh0CUNhcnN0ZW4/CTcwCTUwDQoyMAlUZWNobmljYWwgZGlzY3Vzc2lvbuKApgkJ CQkJQWxsCTkwCTMwDQoyMAlXaGV0aGVyIGFuZCB3aGVyZSB0byBkbyB0aGlzIHdvcmsgaW4gdGhl IElFVEYJCUFsbAkxMTAJMTANCjEwCVF1ZXN0aW9ucyBhbmQgaHVtcyBmb3IgdGhlIEFECQkJCUNo YWlycwkxMjAJMA0KDQpbMV0gZHJhZnQtbGktdHN2d2ctbG9vcHMtcHJvYmxlbS1vcHBvcnR1bml0 aWVzLTAzDQpbMl0gZHJhZnQtd2VsemwtbG9vcHMtZ2VuLWluZm8tMDANCg0KUmlnaHQgbm93LCB3 ZSBwbGFuIHRvIGhhdmUgYW4gYWRtaW5pc3RyYXRpdmUgZGlzY3Vzc2lvbiBvbiBTYXR1cmRheSBt b3JuaW5nIG5lYXIgdGhlIEhhY2thdGhvbiAgKHNheSwgMDk6MDA7IHNvbWUgb2YgdXMgd2lsbCBu b3QgeWV0IGJlIHRoZXJlLCBub3RhYmx5IE1pY2hhZWwpLiAgVGhpcyBjb3VsZCB0aGVuIG1vcnBo IGludG8gYSBmZXcgdGVjaG5pY2FsIGRpc2N1c3Npb24gZ3JvdXBzLCB3aXRoIHBvdGVudGlhbCBj aGFuZ2VzIGJlaW5nIGRpc2N1c3NlZCB0byB0aGUgc2xpZGVzIChzbyBpdCB3b3VsZCBiZSBnb29k IHRvIGhhdmUgdGhlbSBhdmFpbGFibGUgYmVmb3JlIFNhdHVyZGF5IG1vcm5pbmcpLg0KDQpPbiBT dW5kYXkgMDk6MDAgd2UgY291bGQgdGhlbiBoYXZlIGEgc2xpZGUgcmV2aWV3IG1lZXRpbmcgKGlu Y2x1ZGluZyBNaWNoYWVsKS4NCg0KQWxsIHRoZXNlIHByZS1tZWV0aW5ncyBhcmUgbm90IG1lYW50 IHRvIGJlIGxvbmcuICBXZeKAmWxsIGhhdmUgdGhlbiBpbmZvcm1hbGx5LCBhcm91bmQgdGhlIEhh Y2thdGhvbiBbM10gd2hlcmUgbW9zdCBvZiB1cyBhcmUgaW52b2x2ZWQgaW4gb25lIHRoaW5nIG9y IGFub3RoZXIgYWxyZWFkeS4gIElmIHlvdSBoYXZlbuKAmXQgcmVnaXN0ZXJlZCBmb3IgdGhhdDog WW91IHN0aWxsIGNhbiAoYXQgbm8gY29zdCB0byB5b3UpIGF0IGh0dHBzOi8vd3d3LmlldGYub3Jn L3JlZ2lzdHJhdGlvbi9pZXRmMTA1L2hhY2thdGhvbnJlZ2lzdHJhdGlvbi5weQ0KDQpbM106IGh0 dHBzOi8vd3d3LmlldGYub3JnL2hvdy9ydW5uaW5nY29kZS9oYWNrYXRob25zLzEwNS1oYWNrYXRo b24vDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KLS0gDQpMT09QUyBtYWlsaW5nIGxpc3QNCkxPT1BT QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xvb3BzDQo= From nobody Sat Jul 20 04:02:57 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4C12016E for ; Sat, 20 Jul 2019 03:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_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 Cl7AxmeWnxhI for ; Sat, 20 Jul 2019 03:40:39 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 8CC81120176 for ; Sat, 20 Jul 2019 03:40:38 -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:To:References: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=0VQHuo6+mQ2tA99tGWNEV/K/a6Hm/TpQ4qMXuZZIj2o=; b=SEQ7FRcLZ/Nw5DjC8oge5NR0U PjCbpr0PDmKosWu7pC031NhMZSUPtROBrpK7zgz+bJja+WrV4lLPSVwUiI5gxE202A269LFagJ53p 00jCjHs7a1iBM9+XfaSukhLanNSfkc4j90JRnjTWKq8VbR8ZolhNxDry0jFzntPFbhEhyUsPLwOLe lSWtzr5T1hZu3LboprR5GUv0utOBQtnSLMgonYcexxhEfK+CKJzi0vECckXrdlyZ2DXibwW52XDDC z4u3XSopaXKMDpQNjqcZaaM4cFYTJhUPxNoIrSEk00X1IKZ8rohOjE2aNVU4MP/9JVr963SsR78EL yAoPwBFhQ==; Received: from modemcable186.232-83-70.mc.videotron.ca ([70.83.232.186]:51680 helo=[192.168.0.161]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1homn5-00079n-5M; Sat, 20 Jul 2019 11:40:35 +0100 References: To: Carsten Bormann , loops@ietf.org Cc: Michael WELZL From: Bob Briscoe X-Forwarded-Message-Id: Message-ID: Date: Sat, 20 Jul 2019 11:40:34 +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="------------F3148A64C8282431069C0733" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com 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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: X-Mailman-Approved-At: Sat, 20 Jul 2019 04:02:55 -0700 Subject: [LOOPS] Fwd: Re: Relevant to Loops? X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2019 10:40:42 -0000 This is a multi-part message in MIME format. --------------F3148A64C8282431069C0733 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Carsten, I see that you're presenting the slot in loops on related work. Below I've digested a conversation I've been having with Michael Welzl listing work that should be useful to loops. -------- Forwarded Message -------- Subject: Re: Relevant to Loops? Date: Sat, 20 Jul 2019 11:25:56 +0100 From: Bob Briscoe To: Michael Welzl Michael, On 19/07/2019 08:17, Michael Welzl wrote: > Hi, > > >> On Jul 18, 2019, at 5:21 PM, Bob Briscoe > > wrote: >> >> Michael, >> >> I only scanned the drafts, so I've not quite grocked what "the >> proposed mechanism" is - the descriptions seem quite abstract. > > Understood; I guess it’s good to be somewhat abstract at this early > stage. Also, there isn’t one single proposed mechanism - the one in > the appendix is quite different from the rest: no need to tunnel (use > a hash instead), and never delay packets (just to re-sequence them). A > “LOOPS egress” could just ACK the hashes, and the “LOOPS ingress” > would retransmit packets from its cache. > > >> So, I just offer the stuff below as a stream of consciousness, in >> case it's relevant: >> >> * There's an analysis of when it becomes more efficient to >> retransmit locally than e2e, dependent on loss level, in Short >> Messages  (Damon Wischik) >> > I knew about the short messages work, but it has moved so far back in > my mind that I didn’t think of its relevance for LOOPS. I think it's very relevant. Even if the calculation has to be adapted (e.g. I don't think it takes account of the processing on the link receiver), it gives a good structure for the optimization. It's in S.3.b) of Short Messages . The optimization is between processing load of the retransmitting machine vs. completion time (of short messages) in the common case, assuming the usual distribution of mice vs elephants seen on the Internet. The result determines at what level of loss it becomes worth all the bother of maintaining all the machinery and state to retransmit over the local link. >> >> * The PWE protocol (and some other encaps) already has a seq no, so >> OE to OE loss can be detected. >> > Ok… but note my point above about tunneling OK, I've read appx B.1 now. I like the hash idea. But, where a protocol already has the facilities, using them improves performance, given network nodes sometimes need to shave every last per-packet op... I assume you're aware of tunnel congestion feedback , which is already a tsvwg WG draft (it was originally based on a tunnel alternative in an expired ConEx draft ). TCF has to count bytes to work out loss levels over the tunnel, so it's already half way to loops, and retrans info from loops would give TCF loss level for free. However, I guess retrans info (e.g. hashes) is heavier than just a couple of counters. The TCF authors defined an IPFIX f/b channel (at my suggestion), which made sense 'cos it was only sending counters, so you could run it over a partially reliable SCTP transport. Therefore, on reflection, I think there's still a place for separate approaches for just congestion f/b and for retransmission f/b. Indeed, combining two of the above, the f/b protocol would have to determine the loss level all the time (using TCF). Then when loss was high, it could switch to retransmission (or FEC) mode. > >> * Is Magnus Austrheim's thesis relevant? It shows how you can relax >> the ordering requirement for 'link' layer retransmissions, where >> 'link' includes overlays. Unfortunately, the evaluation >> tantalizingly ends abruptly ('cos Magnus wanted to focus on his >> new job). >> Implementing immediate forwarding for 4G in a network simulator >> > Thanks for the pointers! He ended with this odd result where, with RACK and the LTE receiving node not doing resequencing, completion times were generally worse. We couldn't work out how spurious retransmissions could make that much difference. But then Joakim remembered that RACK starts in 3-DUPACK mode. So we surmised that the RACK flow was dropping out of SS early. Some day, I'll find some way to finish that off by trying to improve the start-up behaviour of RACK - or if anyone else on this list wants to - feel free. Bob > > Cheers, > Michael > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------F3148A64C8282431069C0733 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Carsten,

I see that you're presenting the slot in loops on related work.
Below I've digested a conversation I've been having with Michael Welzl listing work that should be useful to loops.


-------- Forwarded Message --------
Subject: Re: Relevant to Loops?
Date: Sat, 20 Jul 2019 11:25:56 +0100
From: Bob Briscoe <research@bobbriscoe.net>
To: Michael Welzl <michawe@ifi.uio.no>


Michael,

On 19/07/2019 08:17, Michael Welzl wrote:
Hi,


On Jul 18, 2019, at 5:21 PM, Bob Briscoe <research@bobbriscoe.net> wrote:

Michael,

I only scanned the drafts, so I've not quite grocked what "the proposed mechanism" is - the descriptions seem quite abstract.

Understood; I guess it’s good to be somewhat abstract at this early stage. Also, there isn’t one single proposed mechanism - the one in the appendix is quite different from the rest: no need to tunnel (use a hash instead), and never delay packets (just to re-sequence them). A “LOOPS egress” could just ACK the hashes, and the “LOOPS ingress” would retransmit packets from its cache.


So, I just offer the stuff below as a stream of consciousness, in case it's relevant:
  • There's an analysis of when it becomes more efficient to retransmit locally than e2e, dependent on loss level, in Short Messages  (Damon Wischik)
I knew about the short messages work, but it has moved so far back in my mind that I didn’t think of its relevance for LOOPS.
I think it's very relevant. Even if the calculation has to be adapted (e.g. I don't think it takes account of the processing on the link receiver), it gives a good structure for the optimization.
It's in S.3.b) of Short Messages.

The optimization is between processing load of the retransmitting machine vs. completion time (of short messages) in the common case, assuming the usual distribution of mice vs elephants seen on the Internet. The result determines at what level of loss it becomes worth all the bother of maintaining all the machinery and state to retransmit over the local link.
  • The PWE protocol (and some other encaps) already has a seq no, so OE to OE loss can be detected.
Ok… but note my point above about tunneling
OK, I've read appx B.1 now.
I like the hash idea.

But, where a protocol already has the facilities, using them improves performance, given network nodes sometimes need to shave every last per-packet op...

I assume you're aware of tunnel congestion feedback, which is already a tsvwg WG draft (it was originally based on a tunnel alternative in an expired ConEx draft). TCF has to count bytes to work out loss levels over the tunnel, so it's already half way to loops, and retrans info from loops would give TCF loss level for free.

However, I guess retrans info (e.g. hashes) is heavier than just a couple of counters. The TCF authors defined an IPFIX f/b channel (at my suggestion), which made sense 'cos it was only sending counters, so you could run it over a partially reliable SCTP transport.

Therefore, on reflection, I think there's still a place for separate approaches for just congestion f/b and for retransmission f/b.

Indeed, combining two of the above, the f/b protocol would have to determine the loss level all the time (using TCF). Then when loss was high, it could switch to retransmission (or FEC) mode.



  • Is Magnus Austrheim's thesis relevant? It shows how you can relax the ordering requirement for 'link' layer retransmissions, where 'link' includes overlays. Unfortunately, the evaluation tantalizingly ends abruptly ('cos Magnus wanted to focus on his new job).
Implementing immediate forwarding for 4G in a network simulator
Thanks for the pointers!
He ended with this odd result where, with RACK and the LTE receiving node not doing resequencing, completion times were generally worse. We couldn't work out how spurious retransmissions could make that much difference.

But then Joakim remembered that RACK starts in 3-DUPACK mode. So we surmised that the RACK flow was dropping out of SS early. Some day, I'll find some way to finish that off by trying to improve the start-up behaviour of RACK - or if anyone else on this list wants to - feel free.



Bob



Cheers,
Michael


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F3148A64C8282431069C0733-- From nobody Mon Jul 22 02:45:30 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D210B1201EC for ; Mon, 22 Jul 2019 02:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 eW6naB8jbxte for ; Mon, 22 Jul 2019 02:45:26 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450: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 8FD8712002E for ; Mon, 22 Jul 2019 02:45:26 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id u10so26114335lfm.12 for ; Mon, 22 Jul 2019 02:45:26 -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=YpmkyoPfa3XCv1D1sGAq5AqRafM28crFXDLGbkSwZ1g=; b=ZdX3LXbPRYYZzU1hceKZW/rClaKUNq2P8iUObNKCCIazONVMjanYSGDFU2Zb3wBmJC ijQ2F8WGLensEs+iXSQ926iz9QpkgRg7PK9qbiGkjqkPfZYCNw+HKua5Wlm4jqvfdXci PIZogdgHIjo78qiNzECzJCBAM7yzl7nDy8M/Eg7/seBCfOXUYF1FYX6J944S1D7uOmR6 h2pomKerU4VoGgTq3j7JuhMTnQAHTKWyphZKwiHg5+GXyQ1o40fqyeK8krAxmmaIB2+R cA5d2DmB+ayXL95ZiL487bpaCtWcsNsh7iyX+NCiU1WLvxYCxo2mhzAvU95tB6ojPN+A FH5Q== 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=YpmkyoPfa3XCv1D1sGAq5AqRafM28crFXDLGbkSwZ1g=; b=jUxzwTr+C2diuOSSA9rOH/eQZ90iz5VWPdIUHTLHtIIJAreDNX1UZ8yRHupFLYIJmC yS20jQ5ic5BJzLNiOXNyYj3Dvf/u1yWtNxnvMcE0MTUVQM8geK8k9wieZ2tImHQ9j8T1 tnN4eUIrXhL8d4Yn//w6yKIYct+NtcDyp8pzAFngKl++uR5Eepnqzh39RH0v62PMX68B X9seCdWmMzTV7cCtPxV6b8ChqWhQSDcxXXGOcmX1rykOXgqkV5/cx3m7DddO3CWK9oMl 4Uaa0sdhduFz0kmNoSpQ7MkSIZnIPfLWVDACe+PPa4iD51CK8qrqwujJkkZkMTiUa5KO XfhQ== X-Gm-Message-State: APjAAAW/3GDdy8v1VrfeoN5Q/qcRh7y2PznPVvK7Pr/88l2oJ01y17Y8 5JKXfQLLK+ln5Qj8BxhmZxVHdCN1qdV1ipC97jwI+j4r X-Google-Smtp-Source: APXvYqy0RGSOpIvQsUZkRDlGjUsBCRJJjK/G6KaDeUuqIZohClWXs86hQqzjNAZ3Z1k+Ve+HROoOFXytLDCNHnoZgQc= X-Received: by 2002:ac2:5337:: with SMTP id f23mr32009604lfh.15.1563788724247; Mon, 22 Jul 2019 02:45:24 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Mon, 22 Jul 2019 05:45:13 -0400 Message-ID: To: loops@ietf.org Content-Type: multipart/alternative; boundary="00000000000069a431058e41efb7" Archived-At: Subject: [LOOPS] Note taker for today's LOOPS session X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 09:45:29 -0000 --00000000000069a431058e41efb7 Content-Type: text/plain; charset="UTF-8" Dear LOOPers and interested parties, Ole and I will need a note taker and a jabber monitor for this morning's LOOPS session. The role of the note taker is to capture major points during the session. The role of the jabber monitor is to relay questions and the results of hums from remote participants. If you care about the results of this BOF, and don't expect to be spending all your time standing in line at the mikes, please consider serving the community in this way! Spencer --00000000000069a431058e41efb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear LOOPers and interested parties,
Ole and I will need a note taker and a jabber moni= tor for this morning's LOOPS session.

=
The role of the note taker is to capture major points dur= ing=C2=A0the session.=C2=A0

The role of the jabber monitor is to relay questions and the results of= hums from remote participants.=C2=A0

If you care about the results of this BOF, and don't expe= ct to be spending all your time standing in line at the mikes, please consi= der serving the community in this way!

Spencer --00000000000069a431058e41efb7-- From nobody Mon Jul 22 04:34:33 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376C12006F for ; Mon, 22 Jul 2019 04:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, 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 iv_T9ZcYGTNn for ; Mon, 22 Jul 2019 04:34:30 -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 2E30D12004A for ; Mon, 22 Jul 2019 04:34:30 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CCEEA9EC9B8D53381E97; Mon, 22 Jul 2019 12:34:28 +0100 (IST) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Jul 2019 12:34:28 +0100 Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.3]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Mon, 22 Jul 2019 19:34:21 +0800 From: "Chenlijuan (Rachel)" To: Spencer Dawkins at IETF , "loops@ietf.org" Thread-Topic: [LOOPS] Note taker for today's LOOPS session Thread-Index: AQHVQHI+MB8+QdLdRU+WO3pIfiA6iqbWgerE Date: Mon, 22 Jul 2019 11:34:20 +0000 Message-ID: 40C8027B-929A-4A37-8592-AB055819D140 References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_40C8027B929A4A378592AB055819D140_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] Note taker for today's LOOPS session X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:34:32 -0000 --_000_40C8027B929A4A378592AB055819D140_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlcg0KSSBjYW4gbW9uaXRvciB0aGUgamFiYmVyIGZvciBsb29wcyBtZWV0aW5nLg0K DQpSYWNoZWwgQ2hlbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K6ZmI5Li95aifIFJhY2hlbA0KTW9iaWxlOiArODYtMTgxMTQwMzM2MjE8dGVs Ois4Ni0xODExNDAzMzYyMT4NCkVtYWlsOiBjaGVubGlqdWFuNUBodWF3ZWkuY29tPG1haWx0bzpj aGVubGlqdWFuNUBodWF3ZWkuY29tPg0K5Y+R5Lu25Lq677yaU3BlbmNlciBEYXdraW5zIGF0IElF VEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPg0K5pS25Lu25Lq677yabG9vcHNAaWV0 Zi5vcmcgPGxvb3BzQGlldGYub3JnPg0K5pe26Ze077yaMjAxOS0wNy0yMiAwNTo0NTo1MA0K5Li7 4oCD6aKY77yaW0xPT1BTXSBOb3RlIHRha2VyIGZvciB0b2RheSdzIExPT1BTIHNlc3Npb24NCg0K RGVhciBMT09QZXJzIGFuZCBpbnRlcmVzdGVkIHBhcnRpZXMsDQoNCk9sZSBhbmQgSSB3aWxsIG5l ZWQgYSBub3RlIHRha2VyIGFuZCBhIGphYmJlciBtb25pdG9yIGZvciB0aGlzIG1vcm5pbmcncyBM T09QUyBzZXNzaW9uLg0KDQpUaGUgcm9sZSBvZiB0aGUgbm90ZSB0YWtlciBpcyB0byBjYXB0dXJl IG1ham9yIHBvaW50cyBkdXJpbmcgdGhlIHNlc3Npb24uDQoNClRoZSByb2xlIG9mIHRoZSBqYWJi ZXIgbW9uaXRvciBpcyB0byByZWxheSBxdWVzdGlvbnMgYW5kIHRoZSByZXN1bHRzIG9mIGh1bXMg ZnJvbSByZW1vdGUgcGFydGljaXBhbnRzLg0KDQpJZiB5b3UgY2FyZSBhYm91dCB0aGUgcmVzdWx0 cyBvZiB0aGlzIEJPRiwgYW5kIGRvbid0IGV4cGVjdCB0byBiZSBzcGVuZGluZyBhbGwgeW91ciB0 aW1lIHN0YW5kaW5nIGluIGxpbmUgYXQgdGhlIG1pa2VzLCBwbGVhc2UgY29uc2lkZXIgc2Vydmlu ZyB0aGUgY29tbXVuaXR5IGluIHRoaXMgd2F5IQ0KDQpTcGVuY2VyDQo= --_000_40C8027B929A4A378592AB055819D140_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHN0eWxlIHR5cGU9 InRleHQvY3NzIj4NCjwhLS0NCioNCgl7fQ0KYm9keQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0K LS0+DQo8L3N0eWxlPg0KPGRpdj5IaSBTcGVuY2VyPGJyPg0KSSBjYW4gbW9uaXRvciB0aGUgamFi YmVyIGZvciBsb29wcyBtZWV0aW5nLiZuYnNwOyA8YnI+DQo8YnI+DQpSYWNoZWwgQ2hlbjxicj4N Cjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQrpmYjkuL3lqJ8gUmFjaGVsPGJyPg0KTW9i aWxlOiA8YSBocmVmPSJ0ZWw6JiM0Mzs4Ni0xODExNDAzMzYyMSI+JiM0Mzs4Ni0xODExNDAzMzYy MTwvYT48YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmNoZW5saWp1YW41QGh1YXdlaS5jb20i PmNoZW5saWp1YW41QGh1YXdlaS5jb208L2E+PC9kaXY+DQo8ZGl2IG5hbWU9IkFueU9mZmljZS1C YWNrZ3JvdW5kLUltYWdlIiBzdHlsZT0iYm9yZGVyLXRvcDoxcHggc29saWQgI0I1QzRERjsgcGFk ZGluZzo4cHgiPg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxiPuWPkeS7tuS6 uu+8mjwvYj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURiAmbHQ7c3BlbmNlcmRhd2tpbnMuaWV0ZkBn bWFpbC5jb20mZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+ 5pS25Lu25Lq677yaPC9iPmxvb3BzQGlldGYub3JnICZsdDtsb29wc0BpZXRmLm9yZyZndDs8L2Rp dj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7ml7bpl7TvvJo8L2I+MjAx OS0wNy0yMiAwNTo0NTo1MDwvZGl2Pg0KPGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwi PjxiPuS4u+KAg+mimO+8mjwvYj5bTE9PUFNdIE5vdGUgdGFrZXIgZm9yIHRvZGF5J3MgTE9PUFMg c2Vzc2lvbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGly PSJhdXRvIj5EZWFyIExPT1BlcnMgYW5kIGludGVyZXN0ZWQgcGFydGllcywNCjxkaXYgZGlyPSJh dXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5PbGUgYW5kIEkgd2lsbCBuZWVkIGEg bm90ZSB0YWtlciBhbmQgYSBqYWJiZXIgbW9uaXRvciBmb3IgdGhpcyBtb3JuaW5nJ3MgTE9PUFMg c2Vzc2lvbi48L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJh dXRvIj5UaGUgcm9sZSBvZiB0aGUgbm90ZSB0YWtlciBpcyB0byBjYXB0dXJlIG1ham9yIHBvaW50 cyBkdXJpbmcmbmJzcDt0aGUgc2Vzc2lvbi4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48 YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj5UaGUgcm9sZSBvZiB0aGUgamFiYmVyIG1vbml0 b3IgaXMgdG8gcmVsYXkgcXVlc3Rpb25zIGFuZCB0aGUgcmVzdWx0cyBvZiBodW1zIGZyb20gcmVt b3RlIHBhcnRpY2lwYW50cy4mbmJzcDs8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIj48YnI+DQo8L2Rp dj4NCjxkaXYgZGlyPSJhdXRvIj5JZiB5b3UgY2FyZSBhYm91dCB0aGUgcmVzdWx0cyBvZiB0aGlz IEJPRiwgYW5kIGRvbid0IGV4cGVjdCB0byBiZSBzcGVuZGluZyBhbGwgeW91ciB0aW1lIHN0YW5k aW5nIGluIGxpbmUgYXQgdGhlIG1pa2VzLCBwbGVhc2UgY29uc2lkZXIgc2VydmluZyB0aGUgY29t bXVuaXR5IGluIHRoaXMgd2F5ITwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPlNwZW5jZXI8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_40C8027B929A4A378592AB055819D140_-- From nobody Mon Jul 22 07:32:22 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB4C12036D for ; Mon, 22 Jul 2019 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DIMLVxO_xEiQ for ; Mon, 22 Jul 2019 07:32:03 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9B712034A for ; Mon, 22 Jul 2019 07:31:48 -0700 (PDT) Received: from client-0097.vpn.uni-bremen.de (client-0097.vpn.uni-bremen.de [134.102.107.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45skZV1HbLzyrc; Mon, 22 Jul 2019 16:31:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann Date: Mon, 22 Jul 2019 10:31:44 -0400 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 585498702.936903-d61c1784e8220bbd0d5a5927f4d15435 Content-Transfer-Encoding: quoted-printable Message-Id: To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [LOOPS] Using the host as a LOOPS node... X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:32:10 -0000 You are not alone: Please see slide 21 of=20 = https://datatracker.ietf.org/meeting/105/materials/slides-105-loops-propon= ent-slides-00 But we chose to keep this out of scope for now. It might be a good second step; it will require more work on setup = protocols and deployability. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 22 07:35:43 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC60A12030D for ; Mon, 22 Jul 2019 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M-IaKPQuVVk for ; Mon, 22 Jul 2019 07:33:37 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 8319312030A for ; Mon, 22 Jul 2019 07:33:37 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id a27so28759311qkk.5 for ; Mon, 22 Jul 2019 07:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0ixgz0PTL8hrxEpeIWp9tbKOor5LnHYr2t//k73BqFg=; b=I5hWPgog8RONekf7HM/qgTqk5onIw+70GLoR9ORFHLFlrLvHC2HKNtcl+LOl/rBzlw H9Ox1I/cbgceRqEb5ekOFw9uY6ZllxUm8RiasF9fJFle3XaROTJr0yYfJkpOexh8iCI8 9AR37i+/q3hFNEUjUSdeQfhAtT7V7JMfe2CYq177UPh86bfIzkuCxcd/nJzJKWnNyo/D ZE7/iVwxCmk2tIBwM8lNK0LDxbCcBL/H2w9ik3D/lWnQ0exhkECaPLR//uivSNy0CaGZ IQQb8wksnz660m6f8W1q6rBzXmZybCg2o9cb6kj3j4ramsFIykUNi653HsazyjtWhnnU 3JnQ== 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=0ixgz0PTL8hrxEpeIWp9tbKOor5LnHYr2t//k73BqFg=; b=AHbL+HJajK7cUkPRtBGspjRSwzhqacwpdUdS2+ZoDZa5bR9NC6QVlsOby8JB/jER0N vbbi9qN/TcvOLOUrTAGxqy4SF1t4xta/qQx7CL4iy/wtAwu9t5wCZjpBHPySZydsSSYu ZKCw6IhLAAiWFdyxGS8ijQV1lAHt7ZHpkCd3uAhRLi/zv+cO68iv31WuvVzRj85onuxK HDF5y6fmW+b87zMYwZRGZtcGOptwrT/kfi1hnllf0mmNnJF/+msFWOMxE5g6QHSUbTfF zoTa1kAosDFmXCnV3Z1KGFpoQS0oNf/jSJ5YjWmEong3/S5wnvxnyq2U0rfUwqO65tE3 EX6A== X-Gm-Message-State: APjAAAX/wTREFjc9Bwg4/HB3wAhtFi14wDfyhzP5hCAnGfgpQ9YxtvKr e92Fqxy5fhOJbxw5kgiL8dZKiw== X-Google-Smtp-Source: APXvYqx4uEyuP6SBVDYq2HBMfgsNTb+g9JBMlZgp0DMy5tyPbpASb0URiIxG+y0YoMQCt17XsflwKQ== X-Received: by 2002:a05:620a:1310:: with SMTP id o16mr44918563qkj.196.1563806016561; Mon, 22 Jul 2019 07:33:36 -0700 (PDT) Received: from dhcp-8921.meeting.ietf.org (dhcp-8921.meeting.ietf.org. [31.133.137.33]) by smtp.gmail.com with ESMTPSA id z19sm18965498qtu.43.2019.07.22.07.33.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 07:33:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Ted Lemon In-Reply-To: Date: Mon, 22 Jul 2019 10:33:33 -0400 Cc: loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DE94132-F127-4B2B-BA06-AC86F6798C76@fugue.com> References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-Mailman-Approved-At: Mon, 22 Jul 2019 07:35:39 -0700 Subject: Re: [LOOPS] Using the host as a LOOPS node... X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:33:40 -0000 Thanks. What I have in mind is to fit TCP frames into 802.15 frames so = that we can just use existing TCP to provide reliable delivery to the = border router. This means no fragmentation; there would be a challenge = in terms of shrinking the header, of course, but I think that can work. = The advantage is that retransmission is per frame rather than per = fragmented packet. So I think this is actually a fairly constrained = problem. :) > On Jul 22, 2019, at 10:31 AM, Carsten Bormann wrote: >=20 > You are not alone: > Please see slide 21 of=20 > = https://datatracker.ietf.org/meeting/105/materials/slides-105-loops-propon= ent-slides-00 >=20 > But we chose to keep this out of scope for now. > It might be a good second step; it will require more work on setup = protocols and deployability. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Mon Jul 22 09:08:41 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3912012B for ; Mon, 22 Jul 2019 09:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wWyOKXvh39ml for ; Mon, 22 Jul 2019 09:08:37 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BF5120052 for ; Mon, 22 Jul 2019 09:08:37 -0700 (PDT) Received: from client-0082.vpn.uni-bremen.de (client-0082.vpn.uni-bremen.de [134.102.107.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45smkC482dzyt3; Mon, 22 Jul 2019 18:08:35 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 585504512.110094-f4b223ea7b649fda0e6bb9f13263199a Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 22 Jul 2019 12:08:33 -0400 Message-Id: <2D201D96-F33C-4AA8-9A54-0670EAF990D9@tzi.org> To: loops@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [LOOPS] Results of the BOF X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 16:08:40 -0000 Given that this was a non-WG-forming BOF that was not supposed to = discuss scope, the result =E2=80=9Cwe are not sure about the scope of = this work=E2=80=9D is pretty much what was to be expected. As a reminder and segue to the discussion about the scope that we = weren=E2=80=99t supposed to have at the non-WG-forming BOF today =E2=80=94= here is the proposal for a scope we have developed in the last 8 = months: https://github.com/loops-wg/charter Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 22 12:26:45 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7612008C for ; Mon, 22 Jul 2019 12:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AiouhvZmTeG for ; Mon, 22 Jul 2019 12:26:41 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 B88CC12004E for ; Mon, 22 Jul 2019 12:26:40 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id y17so14141253ljk.10 for ; Mon, 22 Jul 2019 12:26:40 -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=q42Ygd/YPspvWj41qi6kiJnYSgidPvumU9ZfpNqyn90=; b=P9DYa9qJy7Cu8k2I09IDzJynhl02IwPnWaLVc3mfrdUKV0l+FGGnlkArO6cWtJnS/I qRGtsV6tAbnVW8rS8QK1SwM+C3S6hTRRRQZbof69aLG/Tn1SI4jcl0fsTAUpUpS2rVCQ PHOHIqbmKgJDq5P/jR5IV/1jJbF2xIogbveXPM8VO3o5yhMQp57yKc+LrQi8gDZ6dLN3 hFIWIg7yNYxV5oECrIzDtRzZdzER45TlQSjnQjYBejn1W/SjMRSKLTRN4FuCzwJnQGqN QHOHAGi9a1H0hJmT8xfc2DA3I95bx4W+og1Z/vOsjketaZbVUGOA4lbqPhAN3ZbooWqL JIFg== 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=q42Ygd/YPspvWj41qi6kiJnYSgidPvumU9ZfpNqyn90=; b=S8A/8hPUrGkerU7UV0XP8DK+WPFlzSV+QbmeXtH41hiGc33q8C03Bqbr850mqd5GZL O9RTeyCuNFops/l2vzwZwffFvjHCf49mWM/GT5IWgsyPQs0/bl4CyVOVyxCPhdE89Kv7 WN2LXheG6sQwa3n6OZTpdIxVeJYhLFpw3tZblzniCaF56eokPlANPANXJHZhPKBrYPtP HmcRcbRyqKG2FdqXgu+3bRcdSK2Mp1We21s10e+7nGdCb00WETWyg/D2PMhrQwEJat02 rvRjTsZOer7xQx5Yrt3VHTqcyIRWbNHFnr5WcBar3u5MkOIDtmUwGSS3/OInKZ0o66FU ZDEQ== X-Gm-Message-State: APjAAAU8mq+g3Lx/ghsTOWH2Oax6D0ARC+xUe8GNKinejeuNyqWlKc1W PKSl2RD6+9iuwMqqtfCmXWT56yEvFu9NfFl+YxQ= X-Google-Smtp-Source: APXvYqzj5rMmuputmtteZ/7ye6HRemI/JH2KiF3EwheZquV9cppMnG5Z/H7YuAmrlhtet5JUeEDyFq/kDqmWJcGLXjI= X-Received: by 2002:a2e:85d4:: with SMTP id h20mr37606077ljj.142.1563823598949; Mon, 22 Jul 2019 12:26:38 -0700 (PDT) MIME-Version: 1.0 References: <5d359f48.1c69fb81.808d9.63eaSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <5d359f48.1c69fb81.808d9.63eaSMTPIN_ADDED_BROKEN@mx.google.com> From: Spencer Dawkins at IETF Date: Mon, 22 Jul 2019 15:26:14 -0400 Message-ID: To: "Chenlijuan (Rachel)" Cc: "loops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001b5bd2058e4a0e80" Archived-At: Subject: Re: [LOOPS] Note taker for today's LOOPS session X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 19:26:43 -0000 --0000000000001b5bd2058e4a0e80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Rachel, Thank you for that! Spencer On Mon, Jul 22, 2019 at 7:34 AM Chenlijuan (Rachel) wrote: > Hi Spencer > I can monitor the jabber for loops meeting. > > Rachel Chen > > -------------------------------------------------- > =E9=99=88=E4=B8=BD=E5=A8=9F Rachel > Mobile: +86-18114033621 > Email: chenlijuan5@huawei.com > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A*Spencer Dawkins at IETF > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A*loops@ietf.org > *=E6=97=B6=E9=97=B4=EF=BC=9A*2019-07-22 05:45:50 > *=E4=B8=BB =E9=A2=98=EF=BC=9A*[LOOPS] Note taker for today's LOOPS sessio= n > > Dear LOOPers and interested parties, > > Ole and I will need a note taker and a jabber monitor for this morning's > LOOPS session. > > The role of the note taker is to capture major points during the session. > > The role of the jabber monitor is to relay questions and the results of > hums from remote participants. > > If you care about the results of this BOF, and don't expect to be spendin= g > all your time standing in line at the mikes, please consider serving the > community in this way! > > Spencer > --0000000000001b5bd2058e4a0e80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Rachel,

Thank you for that!

Spencer

On Mon, Jul 22, 2019 at 7:34 AM Chenlijuan (= Rachel) <chenlijuan5@huawei.co= m> wrote:
Hi Spencer
I can monitor the jabber for loops meeting.=C2=A0

Rachel Chen

--------------------------------------------------
=E9=99=88=E4=B8=BD=E5=A8=9F Rachel
Mobile: +86-18114033621
Email: chenliju= an5@huawei.com
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A= Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A= loops@ietf.org = <loops@ietf.org&= gt;
=E6=97=B6=E9=97=B4=EF=BC=9A2019-= 07-22 05:45:50
=E4=B8=BB=E2=80=83=E9=A2=98=EF=BC=9A= [LOOPS] Note taker for today's LOOPS session

Dear LOOPers and interested parties,

Ole and I will need a note taker and a jabber monitor for= this morning's LOOPS session.

The role of the note taker is to capture major points dur= ing=C2=A0the session.=C2=A0

The role of the jabber monitor is to relay questions and = the results of hums from remote participants.=C2=A0

If you care about the results of this BOF, and don't = expect to be spending all your time standing in line at the mikes, please c= onsider serving the community in this way!

Spencer
--0000000000001b5bd2058e4a0e80-- From nobody Mon Jul 22 13:01:51 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5748B12008C for ; Mon, 22 Jul 2019 13:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTicPhVVnPbd for ; Mon, 22 Jul 2019 13:01:48 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E7A191200DE for ; Mon, 22 Jul 2019 13:01:47 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id m23so38726460lje.12 for ; Mon, 22 Jul 2019 13:01:47 -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=O9hTH+14ymb4c/sTqnmnVgknuXK2AP40mX4LBixqjT4=; b=ARZpz5h8NmaiDEJnge9vuNtS8FjyPHFiNzZubUdKbjhaG7dd+cCoeb6Jvh69AXlyFm hxJLxvOsdqj+QWgM8gcqiR/reLk9rtt793x1BdRrNyJdK6JPzSSq+0Hj1QdrBjZXmJrA 5G/4rAN5q0GoYtFCwXoWn/RgcWUT/yAFl/xCsXlxlDRyoZsHP/bpNtMwXucLktd9xdpI oHcII32nCgUnUETzs0xRI72yDBrCRUYSJysmGqujqzl4HOLZFQyvr1EDhVwzV7wCjsno KAurTgga1NKoJG1e69zBoKxbxBo1VVJzN37lkw7qmz4wp9IPcO1G1BpD+WP+S5rYk0DG Hftg== 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=O9hTH+14ymb4c/sTqnmnVgknuXK2AP40mX4LBixqjT4=; b=n+9hqACgQmErUzVJXLVxgpFEQ2Bi263ioOilpfygn8cuApI/B7sfPxHXKdIZfRO/hB EjMxaR7hMD0qbI7PJ76RtuN6B4rq1SV3Ug+kvKPH9t0VPtUyTkBfuJ4tdRbqssEoBml2 K7WqWJOVxhRDnivWF+OtDaDsdZLRZtDVM+f8Np/MEozZV9U2wl57/xbIYW8Lf6+7t4oy nrAAomXcHvowWjHddVD+5pP9F2vYQUE8g1N6nFsUMxHWWUom+CrFDtyP7wyrnytC0m5K Pt/fq2nLo6djZYeRUKyyNgZQWC/YPuXx5D4ZJ4vTZV28WLGW2JPxEKjs2El+OvJGD+S0 qr3A== X-Gm-Message-State: APjAAAUw8bPlYUQ/IqxQ1shGrL+pwu0wvjBm//+AHyg+C0JAkTO0drWs H6kop0rHrFbapFFVk0bB+y55Lq6qbmH8eLkzfvTAhDzN X-Google-Smtp-Source: APXvYqzsy7iKsBA5CT3teTHyDN0GD9w/rz8kk9QokhxIW72JvNXHsmGHTJaovNrnUiL07cxScq3dSUUcD4uqc88BzQg= X-Received: by 2002:a2e:96c3:: with SMTP id d3mr37105319ljj.68.1563825706127; Mon, 22 Jul 2019 13:01:46 -0700 (PDT) MIME-Version: 1.0 References: <2D201D96-F33C-4AA8-9A54-0670EAF990D9@tzi.org> In-Reply-To: <2D201D96-F33C-4AA8-9A54-0670EAF990D9@tzi.org> From: Spencer Dawkins at IETF Date: Mon, 22 Jul 2019 16:01:21 -0400 Message-ID: To: Carsten Bormann Cc: loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000b45773058e4a8b5f" Archived-At: Subject: Re: [LOOPS] Results of the BOF X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 20:01:50 -0000 --000000000000b45773058e4a8b5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't asked the ADs or my co-chair about this, but On Mon, Jul 22, 2019 at 12:08 PM Carsten Bormann wrote: > Given that this was a non-WG-forming BOF that was not supposed to discuss > scope, the result =E2=80=9Cwe are not sure about the scope of this work= =E2=80=9D is pretty > much what was to be expected. > this sounds like a good plan, and we have the most time for face-to-face hallway conversations that BOF attendees can have during IETF week, because we met Monday morning, but *please* start a thread for a question that you haven't seen discussed on the list yet! Someday, someone's going to have to figure out what "the community" wants to propose for a working group, and some IESG is going to have to figure whether "the community" agrees with that proposal. Please Do The Right Thing. Thanks! Spencer, who doesn't actually have a dot after the BOF, so typing as an individual participant > > As a reminder and segue to the discussion about the scope that we weren= =E2=80=99t > supposed to have at the non-WG-forming BOF today =E2=80=94 here is the pr= oposal for > a scope we have developed in the last 8 months: > > https://github.com/loops-wg/charter > > Gr=C3=BC=C3=9Fe, Carsten > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000b45773058e4a8b5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I haven't asked the ADs or my co-chai= r about this, but=C2=A0

On Mon, Jul 22, 2019 at 12:08 PM Carsten Bormann <= ;cabo@tzi.org> wrote:
Given that this was a non-WG-f= orming BOF that was not supposed to discuss scope, the result =E2=80=9Cwe a= re not sure about the scope of this work=E2=80=9D is pretty much what was t= o be expected.

this sounds like a good = plan, and we have the most time for face-to-face hallway conversations that= BOF attendees can have during IETF week, because we met Monday morning, bu= t *please* start a thread for a question that you haven't seen discusse= d on the list yet!

Someday, someone's going to= have to figure out what "the community" wants to propose for a w= orking group, and some IESG is going to have to figure whether "the co= mmunity" agrees with that proposal. Please Do The Right Thing.

Thanks!

Spencer, who doesn't= actually have a dot after the BOF, so typing as an individual participant= =C2=A0

As a reminder and segue to the discussion about the scope that we weren=E2= =80=99t supposed to have at the non-WG-forming BOF today =E2=80=94 here is = the proposal for a scope we have developed in the last 8 months:

https://github.com/loops-wg/charter

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

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--000000000000b45773058e4a8b5f-- From nobody Mon Jul 22 14:11:14 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888F112008C for ; Mon, 22 Jul 2019 14:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 W8ZQJIFcp4nl for ; Mon, 22 Jul 2019 14:11:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40CC12001B for ; Mon, 22 Jul 2019 14:11:10 -0700 (PDT) Received: from client-0062.vpn.uni-bremen.de (client-0062.vpn.uni-bremen.de [134.102.107.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45svRK0zJ3zyth; Mon, 22 Jul 2019 23:11:08 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 585522665.809437-53095e7fe97588208a63db82c6e31465 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 22 Jul 2019 17:11:07 -0400 Message-Id: To: loops@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:11:13 -0000 After the BOF, I had an interesting hallway conversation with Bob = Briscoe on congestion feedback signaling, and about congestion detection = (i.e., grouping losses into non-congestive and congestive). One assumption behind the solutions strawman draft was that it is a = valid approach to signal loss events that occur inside the path segment, = as CE markings to the end hosts. Bob pointed out that some end host = implementations today interpret CE as definite congestion events, while = applying congestion detection to loss signals, so this conversion might = be counterproductive. Congestion detection is then a necessary = component of a LOOPS implementation, in order not to be worse than the = congestion detection employed by the end hosts. Congestion detection does not need to be standardized (we probably do = want to have a BCP or two at some point, though), so that would not be a = theoretical roadblock. But would it be, in a practical sense? Do we expect congestion = detection along a full path (as Stuart Card said today, against the = composition of the statistical behaviors of multiple segments) to be = better than in a LOOPS implementation looking at a single path segment? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 22 14:34:19 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254BD1200A3 for ; Mon, 22 Jul 2019 14:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GszSAGGxjdxc for ; Mon, 22 Jul 2019 14:34:14 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 B527212001B for ; Mon, 22 Jul 2019 14:34:14 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hpfwh-00056A-Sj; Mon, 22 Jul 2019 23:34:11 +0200 Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hpfwh-000A5O-6M; Mon, 22 Jul 2019 23:34:11 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: Date: Mon, 22 Jul 2019 17:34:08 -0400 Cc: loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> References: To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FA4D51549FD0A7351FA42BDBE69C3252B18C6364 Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 21:34:17 -0000 Hi, I can=E2=80=99t parse this: > On Jul 22, 2019, at 5:11 PM, Carsten Bormann wrote: >=20 > After the BOF, I had an interesting hallway conversation with Bob = Briscoe on congestion feedback signaling, and about congestion detection = (i.e., grouping losses into non-congestive and congestive). >=20 > One assumption behind the solutions strawman draft was that it is a = valid approach to signal loss events that occur inside the path segment, = as CE markings to the end hosts. Bob pointed out that some end host = implementations today interpret CE as definite congestion events, while = applying congestion detection to loss signals, so this conversion might = be counterproductive. The last sentence - I don't understand it (=E2=80=9Cinterpret CE as = definite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). = What does it mean? Or, maybe: what=E2=80=99s the issue here? Trying to guess: is it that this would incur a double-reaction? That = would be a strange implementation indeed, if that would happen within = the same RTT - but: I thought the whole point is to signal CE *as a = replacement* for the loss that LOOPS repairs. So, then=E2=80=A6 ? Cheers, Michael From nobody Mon Jul 22 15:17:13 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABAF1200B1 for ; Mon, 22 Jul 2019 15:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kJN2YOP9hep9 for ; Mon, 22 Jul 2019 15:17:09 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13A812006B for ; Mon, 22 Jul 2019 15:17:09 -0700 (PDT) Received: from client-0195.vpn.uni-bremen.de (client-0195.vpn.uni-bremen.de [134.102.107.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45swvR66Z4zyXT; Tue, 23 Jul 2019 00:17:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> Date: Mon, 22 Jul 2019 18:17:06 -0400 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 585526624.6265661-936b29a38df59ab5a6f0b933801204aa Content-Transfer-Encoding: quoted-printable Message-Id: <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> References: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:17:11 -0000 Sorry for typing a message from a heated BOF where I was representing a = WG that needs a specific outcome=E2=80=A6 >> Bob pointed out that some end host implementations today interpret = CE as definite congestion events, while applying congestion detection to = loss signals, so this conversion might be counterproductive. >=20 > The last sentence - I don't understand it (=E2=80=9Cinterpret CE as = definite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). = What does it mean? Or, maybe: what=E2=80=99s the issue here? What I think Bob meant: An end-host noticing a loss might make its own = determination (a.k.a. congestion detection) whether that is a reason to = slow down or not. An end-host getting a CE might simply assume this is indeed congestion, = and always slow down. So, CE > loss, and a simple replacement of loss = by CE worsens throughput. > I thought the whole point is to signal CE *as a replacement* for the = loss that LOOPS repairs. So, then=E2=80=A6 ? If CE > loss, replacing loss by CE is not enough, we need to vet the = losses via a LOOPS-side congestion detection that is as good as the one = as the end-host would do, or (preferably) better. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 22 15:51:49 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBFA1200BA for ; Mon, 22 Jul 2019 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTB7OKPBx9YN for ; Mon, 22 Jul 2019 15:51:44 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A224C1200B9 for ; Mon, 22 Jul 2019 15:51:44 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hph9i-0007cs-Lw; Tue, 23 Jul 2019 00:51:42 +0200 Received: from dhcp-9902.meeting.ietf.org ([31.133.153.2]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hph9h-00018I-VM; Tue, 23 Jul 2019 00:51:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> Date: Mon, 22 Jul 2019 18:51:39 -0400 Cc: loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> References: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 31.133.153.2 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.153.2; envelope-from=michawe@ifi.uio.no; helo=dhcp-9902.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7F95E3C45F3709DF3AE4DB52A4DC207924705ACA Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 22:51:47 -0000 > On Jul 22, 2019, at 6:17 PM, Carsten Bormann wrote: >=20 > Sorry for typing a message from a heated BOF where I was representing = a WG that needs a specific outcome=E2=80=A6 >=20 >>> Bob pointed out that some end host implementations today interpret = CE as definite congestion events, while applying congestion detection to = loss signals, so this conversion might be counterproductive. >>=20 >> The last sentence - I don't understand it (=E2=80=9Cinterpret CE as = definite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). = What does it mean? Or, maybe: what=E2=80=99s the issue here? >=20 > What I think Bob meant: An end-host noticing a loss might make its own = determination (a.k.a. congestion detection) whether that is a reason to = slow down or not. > An end-host getting a CE might simply assume this is indeed = congestion, and always slow down. So, CE > loss, and a simple = replacement of loss by CE worsens throughput. Ok, thanks! now I understand that the statement is indeed what I = thought, but it still makes zero sense to me. See below: >> I thought the whole point is to signal CE *as a replacement* for the = loss that LOOPS repairs. So, then=E2=80=A6 ? >=20 > If CE > loss, replacing loss by CE is not enough, we need to vet the = losses via a LOOPS-side congestion detection that is as good as the one = as the end-host would do, or (preferably) better. RFC 3168 says CE =3D loss. RFC 8311 finally allows us to diverge from = this rule, which we used in RFC to state: =E2=80=9CCE < loss=E2=80=9D. L4S of course also does =E2=80=9CCE < loss=E2=80=9D, albeit in much more = elaborate ways. However: "CE > loss=E2=80=9D is truly weird to me - perhaps this IS now = allowed by RFC 8311 :-D but if it=E2=80=99s spec=E2=80=99ed then it = must be an April 1 RFC. What am I missing, Bob? Cheers, Michael From nobody Tue Jul 23 07:45:50 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F1120319 for ; Tue, 23 Jul 2019 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEmpRp6YO2MM for ; Tue, 23 Jul 2019 07:45:38 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 F3E261202F0 for ; Tue, 23 Jul 2019 07:45:37 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id i21so41350882ljj.3 for ; Tue, 23 Jul 2019 07:45:37 -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=O1rQvmxw6kxVjOrSYotxkjdI3NpEDNzQRrdZzcVKQgM=; b=cPI1G4HwdqvYaBCc/soWEMfl4GxUtCg9Wwmng3VFlzftR5NerouNkqvs7AHx+L/mFX ELeoB5AQ1GeOFWxI/JN9R1/8TnyWR4Wgzw3+fkbtTKJaaMtFm52cOF1vPzImqUCTL3qk M0Xl59IELb59ZXA0XjWFiGoo2EWZDrjDRSaCsZtcI3IckFdG6817ZsiHC/+5T3NToNMr 7tCeqm+72HQ0P1J2klbeEFnnWZyf2vgksDPiwgn7H7pvxSXq6hWCv+jcm1F5mP/hf5L1 T0+8wehgusfrwz5nL7IijaXTphRqg4C8CRDrUi7E/CYGXf7hPAIi+6U43t7tEWdzCT/k oE9g== 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=O1rQvmxw6kxVjOrSYotxkjdI3NpEDNzQRrdZzcVKQgM=; b=gBiBqFmZgzxYaOTmJqG7OWvvMdcD3+ojkFPTJB99dqmZfhdJ1plaJiqD2GB8lgV7MX M44dYz14nBtO+L88taZ4bNqTSyn/++tYFl7FHHHAcHjGMNoH7HH/B9Dq1TeDScYN14Pm MRhu6i/Bb3Copq8WvjhjHkvH9VeDa4Pfw2dOXMc/xF0mH9gja5A6J9Npk0n69pZXYWBj EUpYjPaEoTJm/Crk1pfci+LJqnygaGHx6BjiquVPVzdNwo6IEc+G7nnxYxn7+0rCnOp/ gkr85EaM3esHLS77P7hMpoR1Uip1RHD/hiKbCHM/g44A7xKsJZNDTAwXXRdwn70dZ8mc +xZQ== X-Gm-Message-State: APjAAAUh5WWdWMLq2qh53e9sikTxQC5r27HP7jvTehi+MeufhRb0mPD8 0imS23plfRYBkEJJyRGSWN5FALAG7WEr8qa5dCk= X-Google-Smtp-Source: APXvYqwZMQPQYLDwLi7JA8iTrgUdUwB89LBqV+wh9zLcsbycvPtvix3GCCYWb8JteZCPBKNwelXKybLj5YqlLkjxb+M= X-Received: by 2002:a2e:8741:: with SMTP id q1mr39445297ljj.144.1563893136110; Tue, 23 Jul 2019 07:45:36 -0700 (PDT) MIME-Version: 1.0 References: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> In-Reply-To: <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> From: Spencer Dawkins at IETF Date: Tue, 23 Jul 2019 10:45:11 -0400 Message-ID: To: Michael Welzl Cc: Carsten Bormann , loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000d83955058e5a3ebc" Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 14:45:48 -0000 --000000000000d83955058e5a3ebc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, On Mon, Jul 22, 2019 at 6:51 PM Michael Welzl wrote: > > > > On Jul 22, 2019, at 6:17 PM, Carsten Bormann wrote: > > > > Sorry for typing a message from a heated BOF where I was representing a > WG that needs a specific outcome=E2=80=A6 > > > >>> Bob pointed out that some end host implementations today interpret CE > as definite congestion events, while applying congestion detection to los= s > signals, so this conversion might be counterproductive. > >> > >> The last sentence - I don't understand it (=E2=80=9Cinterpret CE as de= finite=E2=80=A6 > while applying detection to loss=E2=80=9D - huh?). What does it mean? Or,= maybe: > what=E2=80=99s the issue here? > > > > What I think Bob meant: An end-host noticing a loss might make its own > determination (a.k.a. congestion detection) whether that is a reason to > slow down or not. > > An end-host getting a CE might simply assume this is indeed congestion, > and always slow down. So, CE > loss, and a simple replacement of loss by > CE worsens throughput. > > Ok, thanks! now I understand that the statement is indeed what I thought= , > but it still makes zero sense to me. See below: > > > >> I thought the whole point is to signal CE *as a replacement* for the > loss that LOOPS repairs. So, then=E2=80=A6 ? > > > > If CE > loss, replacing loss by CE is not enough, we need to vet the > losses via a LOOPS-side congestion detection that is as good as the one a= s > the end-host would do, or (preferably) better. > > RFC 3168 says CE =3D loss. RFC 8311 finally allows us to diverge from thi= s > rule, which we used in RFC to state: =E2=80=9CCE < loss=E2=80=9D. > L4S of course also does =E2=80=9CCE < loss=E2=80=9D, albeit in much more = elaborate ways. > > However: "CE > loss=E2=80=9D is truly weird to me - perhaps this IS now a= llowed by > RFC 8311 :-D but if it=E2=80=99s spec=E2=80=99ed then it must be an A= pril 1 RFC. > > What am I missing, Bob? > I was hoping CE > loss was a typo, myself. Spencer > > Cheers, > Michael > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000d83955058e5a3ebc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW,=C2=A0

On Mon, Jul 22, 2019 at 6:51 P= M Michael Welzl <michawe@ifi.uio.n= o> wrote:


> On Jul 22, 2019, at 6:17 PM, Carsten Bormann <cabo@tzi.org> wrote:
>
> Sorry for typing a message from a heated BOF where I was representing = a WG that needs a specific outcome=E2=80=A6
>
>>> Bob pointed out that some end host implementations today inter= pret CE as definite congestion events, while applying congestion detection = to loss signals, so this conversion might be counterproductive.
>>
>> The last sentence - I don't understand it (=E2=80=9Cinterpret = CE as definite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). = What does it mean? Or, maybe: what=E2=80=99s the issue here?
>
> What I think Bob meant: An end-host noticing a loss might make its own= determination (a.k.a. congestion detection) whether that is a reason to sl= ow down or not.
> An end-host getting a CE might simply assume this is indeed congestion= , and always slow down.=C2=A0 So, CE > loss, and a simple replacement of= loss by CE worsens throughput.

Ok, thanks!=C2=A0 now I understand that the statement is indeed what I thou= ght, but it still makes zero sense to me. See below:


>> I thought the whole point is to signal CE *as a replacement* for t= he loss that LOOPS repairs. So, then=E2=80=A6 ?
>
> If CE > loss, replacing loss by CE is not enough, we need to vet th= e losses via a LOOPS-side congestion detection that is as good as the one a= s the end-host would do, or (preferably) better.

RFC 3168 says CE =3D loss. RFC 8311 finally allows us to diverge from this = rule, which we used in RFC to state: =E2=80=9CCE < loss=E2=80=9D.
L4S of course also does =E2=80=9CCE < loss=E2=80=9D, albeit in much more= elaborate ways.

However: "CE > loss=E2=80=9D is truly weird to me - perhaps this IS= now allowed by RFC 8311=C2=A0 :-D=C2=A0 =C2=A0 but if it=E2=80=99s spec=E2= =80=99ed then it must be an April 1 RFC.

What am I missing, Bob?

I was hoping CE= > loss was a typo, myself.

Spencer
= =C2=A0

Cheers,
Michael

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--000000000000d83955058e5a3ebc-- From nobody Tue Jul 23 16:12:31 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE211200B1 for ; Tue, 23 Jul 2019 16:12:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMDZYDv_M3wM for ; Tue, 23 Jul 2019 16:12:27 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 BB311120098 for ; Tue, 23 Jul 2019 16:12:27 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id m24so85554290ioo.2 for ; Tue, 23 Jul 2019 16:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:date:message-id:subject:to; bh=9YiKOhs5GDUsIwRaWRQdqOO11u5EHiQl7QWvWLZ2F78=; b=r3kf3Fl+l5RFo5DCKUpHcN94/DDShlwzHcdugL4vjlgqOZxl8ZZoP89K0ZWDujBR0z SV+IKo2FImicpyRy99c6VwKJFRvVP47YHd29b8VgvIFeH+OQAnor6OwJFnfF6xE8zYUt ZayeaJ1gQGBYA1kS7Uwz/lffDIhoYnX20EFWvwH4c7tJSoJE+tv5pvrsdRqy/jjC7JTD jMseKWoAKVYdnWWueD6W6ji3sGUPGMRo0tBO50eTDvR+XEDFJ67H5n7JeOlGX18nPnGI lu+Za9DRGUUrBhopYWKFdpoWHpk5HkT+rUyUeRzmLEEIs3a0X2mhIeIZLn4Y9QnikL3Y EOzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=9YiKOhs5GDUsIwRaWRQdqOO11u5EHiQl7QWvWLZ2F78=; b=Ll27jHf8nHmegA7An37yYHJ+jb85OdE7Rl9x/kbqkIGaMQ6P1AUlGm1FPd/YEiMAr+ 1Cf4/MkqdUdu6JrwY2NhJNiSwt9tvZCRhywCpg8OWA89yO5LVilZ/zn1jIcMP61r+cHf QKxkLrnEUMsQLFiFXDNUvrH+GF2PuvBoa76vqIAnODw2ovIyc5qwlQdJ3fKMYbhLxEpr WhY9SZ2QX/Ex0U7wougcimtmJ0huY7x/od65ciNEXbBeYiK19HiCva8k0Mi3fntw7bAO /mxpWcvQwvt1speL5eZLO6DGk1evu5veeJrluM+wsxvjL9RYw68D+mRFGOLidro/gbQ1 7zTg== X-Gm-Message-State: APjAAAXtHty1z1Ds9RpY7dfhN77jRza56bIhMsZBdjhBVVzJCGvdsL0s K9EbsAGgyVx46Jn5Jnkj4BrlbKFrbRD9megxCZeFmxSw X-Google-Smtp-Source: APXvYqzoFybqJwIm87Q4ds74yuCUmB4xcwtmO66XkJfnv5VpHKCTuwTZ9l16HcD7nfXYs8pkpQdwsEUQQARlBTE5Z/A= X-Received: by 2002:a6b:6e01:: with SMTP id d1mr1680830ioh.156.1563923546850; Tue, 23 Jul 2019 16:12:26 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jul 2019 16:12:25 -0700 From: Marie-Jose Montpetit MIME-Version: 1.0 Date: Tue, 23 Jul 2019 16:12:25 -0700 Message-ID: To: loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000775b8c058e615375" Archived-At: Subject: [LOOPS] LOOPS BOF X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 23:12:30 -0000 --000000000000775b8c058e615375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My take on Monday=E2=80=99s non-WG forming BOF - in a nutshell what is the = problem? (not even the scope yet) If it is performance optimization over interconnected links with different delay/loss characteristics and with or without host collaboration and/or access I am sorry to tell you that there has been a lot of work done in industry and academia addressing this. Whatever you do you will hit t the fact that a lot of the network coding or FEC you need is protected. Will LOOPS develop at new code? If yes then LOOPS is NWCWG the IETF version of our RG. You will also hit the tunneling limitations and of course proprietary PEPs (the open source ones are okish though) and the usual issues of congestion losses vs. random losses and we have looked at this for ages now it seems and we have gotten good at it. I disagree with the assessment that =E2=80=9Clong losses=E2=80=9D are due t= o congestion on your path, they may be due to issues on another path and in wireless some kind of deep fade that the lower layers did not catch - beware that =E2=80= =9Cdelay=E2=80=9D is also a sign of loss. I agree with some of the discussions today : what layer are we talking about here? L3? But some of the diagrams showed OLT and below L3. =E2=80=9CSolving" problems at L3 without looking at what is either below o= r above is I think something the proposing team should look at. It has helped me in the past. A combination of the work we did in NWCRG and what has also been addressed in ICNRG and ICCRG (and others) is what LOOPS needs. DO we need a new WG to get that work out of IRTF? But if the goal of this group is to make progress there are other issues to address. Mine would be how to implement L3 solutions in an L4 encrypted world. And others. Just to say you are there to improve Internet performance of course is good: we are all here to do that. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu --000000000000775b8c058e615375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
My take on M= onday=E2=80=99= s non-WG forming BOF - in a nutshell what is the problem? (not even th= e scope yet)

If it is performance optimization over interconnected = links with different delay/loss characteristics and with or without host co= llaboration and/or access I am sorry to tell you that there has been a lot = of work done in industry and academia addressing this.

Whatever you do you will = hit t the fact that a lot of the network=C2=A0coding or FEC you need is protected. Will LOOPS develop a= t new code? If yes then LOOPS is NWCWG the IETF version of our RG.= =C2=A0You will also hit the tunneling limitations and of course proprietary= PEPs (the open source ones are okish though) and the usual issues of conge= stion losses vs. random losses and we have looked at this for ages now it s= eems and we have gotten good at it.

I disagree with the assessment= that =E2=80=9Clong losses=E2=80=9D are due to congestion on your path, the= y may be due to issues on another path and in wireless some kind of deep fa= de that the lower layers did not catch - beware that =E2=80=9Cdelay=E2=80= =9D is also a sign of loss.=C2=A0

I agree with some of the discussi= ons=C2=A0today: what = layer are we talking about here? L3?=C2=A0 But some of the diagrams showed = OLT and below =C2=A0L3. =C2=A0=E2=80=9CSolving" problems at L3 without= looking at what is either below or above is I think something the proposin= g team should look at. It has helped me in the past.

A combination of the work we did in NWCRG and what has also be= en addressed in ICNRG and ICCRG (and others) is what LOOPS needs. DO we nee= d a new WG to get that work out of IRTF?

But if the goal of this gr= oup is to make progress there are other issues to address. Mine would be ho= w to implement L3 solutions in an L4 encrypted world. And others.=C2=A0
Just to say you are there to improve Internet performance of course is go= od: we are all here to do that.

= mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.
Research Affiliate, MIT = Media Laboratory
--000000000000775b8c058e615375-- From nobody Tue Jul 23 16:54:43 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1912097B for ; Tue, 23 Jul 2019 16:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, 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 jBdzZFRa39yZ for ; Tue, 23 Jul 2019 16:54:39 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 87D8A1201B5 for ; Tue, 23 Jul 2019 16:54:38 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id p197so30568789lfa.2 for ; Tue, 23 Jul 2019 16:54:38 -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=rCt1l5rz1OclPUu5LyKlvElkFtQ8SDOJuiYHEmFqY4o=; b=dy0TI2fYGiiCUN8p40EVzo4thK/9OUMnPMZNwDX4ZbAXkOSUDfP3CeD6p8ob1PCTxj ILDfyJMNTIEwBi44KaWW1Ycck6FfYi6L7/UWrpUmOu/DEN/jxtN53PaIzoNfTdLlHurr iBj6Wso4U5sxETyqII5quA1ul7XniWsuj/TM7Wtle/L21QKPlNx4nAgNuLqATUm/luDZ 7Q5JRNsdrSoLhPPjafc3km2PfhdA6paW5iVq2MX0rn+gud8+uswldi0fg32zycA62HII gSrXqIBJ9cSGeXwI4xpARiHaRUX9p2lJBr+7kb+0UMEkHyVDqXO7nrc9wFMdEqd2f60H /Lfg== 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=rCt1l5rz1OclPUu5LyKlvElkFtQ8SDOJuiYHEmFqY4o=; b=O/ssjxBP3LVvyF40LsLAnth0uFIKzPHNw8H/aB/6vHooKSx0jK8AZJ442Ds8VBbCcM sVrW/WmJfuU1oRNKdAA8cnGJ2+ulVefXegrGcPBivbEwLGuEHKNX4RbYRAnbZGif7A/n N9f0cUKvzOG266YA3EB4+vbdgPo+tbS9FEd1+ThocTfpRP3tgP3IzaAVzalc1/9/aPSV /t1vCmIHA89d9Zo6tegoHhauVfYp9qvL8J60wq86SHHIugrNQWE/daWt4XCrchOC8c9H S2gqjwA7ITZYM6U86H4kMclMGuSi1dlVGIM3fFEiTQDf8KNaNrZ6aCVQ3QiNAxDb4Zec /G3Q== X-Gm-Message-State: APjAAAXEkzMiEuiHgLU2Vj0+0URt+PizqhaUSvgD0O98siuxvga1pvuL sLxCfphOA6UH0I7cdgA6S+I5/VPy2N+/vzk1KUPGpqDSRV8= X-Google-Smtp-Source: APXvYqy3gObluZ8byOoN13ibSTuvwL7Sj0gjzi8IsWFsRz2YUFFoN5PKRRepDE3TrwpgEa10YRo+ev8DRYYXvy/7hZo= X-Received: by 2002:a19:f806:: with SMTP id a6mr23177314lff.102.1563926076674; Tue, 23 Jul 2019 16:54:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 23 Jul 2019 19:54:12 -0400 Message-ID: To: Marie-Jose Montpetit Cc: loops@ietf.org Content-Type: multipart/alternative; boundary="00000000000041582a058e61eab8" Archived-At: Subject: Re: [LOOPS] LOOPS BOF X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 23:54:42 -0000 --00000000000041582a058e61eab8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Marie-Jose, Thank you for bring these considerations to this mailing list. (Aside - what follows is my opinion with no hats, because I don't have any, but I hope it is also helpful to the LOOPS community). On Tue, Jul 23, 2019 at 7:12 PM Marie-Jose Montpetit wrote: > My take on Monday=E2=80=99s non-WG forming BOF - in a nutshell what is th= e > problem? (not even the scope yet) > > If it is performance optimization over interconnected links with differen= t > delay/loss characteristics and with or without host collaboration and/or > access I am sorry to tell you that there has been a lot of work done in > industry and academia addressing this. > One way that the IESG has chartered new work in the past, has been when research communities feel that at least some of their research output is stable enough to standardize for engineering. As NWCRG co-chair, you would know (but others may not) that some of your work came to TSVWG in order to add Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME - and that worked, because three of those documents are in the RFC Editor queue now. IRTF work coming to the IETF allows wider review, and publication on the Internet standards track. I hope LOOPS will consider NWCRG's experience in this area. > Whatever you do you will hit t the fact that a lot of the network coding > or FEC you need is protected. > Do you mean IPR-encumbered? If so, that doe mean IETF working groups providing technology to perform local optimizations will need to consider IPR and licensing disclosures. > Will LOOPS develop at new code? If yes then LOOPS is NWCWG the IETF > version of our RG. > The question of reference implementations should be considered by the LOOPS community before requesting WG actions by the IESG. > You will also hit the tunneling limitations and of course proprietary PEP= s > (the open source ones are okish though) and the usual issues of congestio= n > losses vs. random losses and we have looked at this for ages now it seems > and we have gotten good at it. > That will be very helpful in scoping LOOPS. I disagree with the assessment that =E2=80=9Clong losses=E2=80=9D are due t= o congestion on > your path, they may be due to issues on another path and in wireless some > kind of deep fade that the lower layers did not catch - beware that =E2= =80=9Cdelay=E2=80=9D > is also a sign of loss. > This is exactly the kind of question that an IETF working group should be looking at. > I agree with some of the discussions today > : what layer are > we talking about here? L3? But some of the diagrams showed OLT and below > L3. =E2=80=9CSolving" problems at L3 without looking at what is either = below or > above is I think something the proposing team should look at. It has help= ed > me in the past. > Agree. I had the privilege of watching most of the LOOPS proponents discussing their thoughts intensely for almost the entire length of the Hackathon last weekend, and I think you're pointing to the misalignments that are inevitable when many implementers are working in isolation. That alignment needs to happen during chartering discussions, so that we are all solving the same problem. About 10-12 BOF participants raised their hands to indicate that they were working on products in this space, and the proponents are hoping to make it easier for these people to be more aligned. > A combination of the work we did in NWCRG and what has also been addresse= d > in ICNRG and ICCRG (and others) is what LOOPS needs. DO we need a new WG = to > get that work out of IRTF? > If it is to be published on the Internet standards track, yes. The IRTF stream produces Informational and Experimental RFCs, but not BCPs or Standards-track RFCs. > But if the goal of this group is to make progress there are other issues > to address. Mine would be how to implement L3 solutions in an L4 encrypte= d > world. And others. > Yes. Discussions on this mailing list will be necessary to scope any charter requests to the IESG, if we don't want to be holding another BOF in Singapore that starts from where we are now :-) > Just to say you are there to improve Internet performance of course is > good: we are all here to do that. > Again, thank you for your help and insights. Spencer > mjm > > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --00000000000041582a058e61eab8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Marie-Jose,=C2=A0

Thank you for bring these considerations to this mailing = list.=C2=A0

(Aside - what follows is my opinion wi= th no hats, because I don't have any, but I hope it is also helpful to = the LOOPS community).=C2=A0

On Tue, Jul 23, 2019 at 7:12 PM Marie-Jose Montp= etit <marie@mjmontpetit.com= > wrote:
My take on Monday= =E2=80=99s non-WG forming BOF - in a nutshell what is th= e problem? (not even the scope yet)

If it is performance optimizat= ion over interconnected links with different delay/loss characteristics and= with or without host collaboration and/or access I am sorry to tell you th= at there has been a lot of work done in industry and academia addressing th= is.

One way that the IES= G has chartered new work in the past, has been when research communities fe= el that at least some of their research output is stable enough to standard= ize for engineering. As NWCRG co-chair, you would know (but others may not)= that some of your work came to TSVWG in order to add=C2=A0Sliding Window R= andom Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRA= ME - and that worked, because three of those documents are in the RFC Edito= r queue now. IRTF work coming to the IETF allows wider review, and publicat= ion on the Internet standards track.=C2=A0

I h= ope LOOPS will consider NWCRG's experience in this area.
=C2= =A0
Whatever you do you will hit t the = fact that a lot of the network=C2=A0coding or FEC you need is protect= ed.

Do you mean = IPR-encumbered? If so, that doe mean IETF working groups providing technolo= gy to perform local optimizations will need to consider IPR and licensing d= isclosures.=C2=A0=C2=A0=C2=A0
=C2=A0
Will LOOPS develop at new code? If yes then LOOPS is NWC= WG the IETF version of our RG.=C2=A0
=

The question of reference implementations should be con= sidered by the LOOPS community before requesting WG actions by the IESG.=C2= =A0
=C2=A0
You will also hit t= he tunneling limitations and of course proprietary PEPs (the open source on= es are okish though) and the usual issues of congestion losses vs. random l= osses and we have looked at this for ages now it seems and we have gotten g= ood at it.

That will be = very helpful in scoping LOOPS.=C2=A0

I disagree with the assessment that =E2=80=9Clong= losses=E2=80=9D are due to congestion on your path, they may be due to iss= ues on another path and in wireless some kind of deep fade that the lower l= ayers did not catch - beware that =E2=80=9Cdelay=E2=80=9D is also a sign of= loss.=C2=A0

This is exa= ctly the kind of question that an IETF working group should be looking at.<= /div>
=C2=A0
I agree wi= th some of the discussions=C2= =A0today: what layer are we talking about here? L3?= =C2=A0 But some of the diagrams showed OLT and below =C2=A0L3. =C2=A0=E2=80= =9CSolving" problems at L3 without looking at what is either below or = above is I think something the proposing team should look at. It has helped= me in the past.

Agree. = I had the privilege of watching most of the LOOPS proponents discussing the= ir thoughts intensely for almost the entire length of the Hackathon last we= ekend, and I think you're pointing to the misalignments that are inevit= able when many implementers are working in isolation. That alignment needs = to happen during chartering discussions, so that we are all solving the sam= e problem. About 10-12 BOF participants raised their hands to indicate that= they were working on products in this space, and the proponents are hoping= to make it easier for these people to be more aligned.=C2=A0
=C2= =A0
A combination of the w= ork we did in NWCRG and what has also been addressed in ICNRG and ICCRG (an= d others) is what LOOPS needs. DO we need a new WG to get that work out of = IRTF?

If it is to be= published on the Internet standards track, yes. The IRTF stream produces I= nformational and Experimental RFCs, but not BCPs or Standards-track RFCs.= =C2=A0
=C2=A0
But if the goal of this group is to make progre= ss there are other issues to address. Mine would be how to implement L3 sol= utions in an L4 encrypted world. And others.=C2=A0

Yes. Discussions on this mailing list will be ne= cessary to scope any charter requests to the IESG, if we don't want to = be holding another BOF in Singapore that starts from where we are now :-)
=C2=A0
Just to say= you are there to improve Internet performance of course is good: we are al= l here to do that.
<= /div>

Again, thank you for your help = and insights.=C2=A0

Spencer
=C2=A0
=
mjm

Marie-Jos=C3=A9 Montpetit,= Ph.D.
Research Affiliate, MIT Media Laboratory
--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--00000000000041582a058e61eab8-- From nobody Tue Jul 23 17:02:57 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936D51201B5 for ; Tue, 23 Jul 2019 17:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SUBJ_ALL_CAPS=0.5, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6uTuAnmT85F for ; Tue, 23 Jul 2019 17:02:53 -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 E8F86120991 for ; Tue, 23 Jul 2019 17:02:52 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id z3so85757646iog.0 for ; Tue, 23 Jul 2019 17:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3uwJZWHjNuqC5l3N+BGlgbu16PUGtjfEmCY6I/a55+U=; b=ZvMYxmSymX4O/4jgxgtG0Tp24uwInWIKPzxF8FTLgqw9yom1vkvYoKNhXrvcPWjlhw yfsfjGpxOrqh5BVBSfCbur9z9f2XNvJ1qLyGT7cVSZiyooghaIVGtdaAipc7G1MAlHap q5LY3xNDjwB3SexTPRn/nbTxmqTM7SqdxHW0uoCK4/DeGr+Il02PlFtsWf6bD5UGuRJX F1/rp5CUBL0z8d+3XJpDhgqj0XijG/+NZoSp9FTf1hVj6uc8/QvdGBSfFxNTX7CezynR 35xD0R0Ill33ViiI96K68hcobdwFAyoh+QHRCCSNp/csO9OUy0PBezmeSBW+OdT55JwC Mxcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3uwJZWHjNuqC5l3N+BGlgbu16PUGtjfEmCY6I/a55+U=; b=k4tR86lWYjzjlK010PS+kYRk+QQTGSwEO6qMXf7CALOL80PswzAhmjr1PHePfhkugE mDJIpyJWdAmacNOzknEuLmTtcf7Bh/56MGE08jc9MXDVxFXxDQJ3k47DngvgpC84H0eb d4s1Q5BKH9yRICsIlM5xNU6jkEk3GcqEF9zac0jqUTEuAl20vx7p5V9+c5Ihzwpfn+p/ 6wUvQij8bMbTOpgLlwkF+9jPzxLrH0eb5+xV++o8iXHk+grif+goK8ODY5ZQ9T09+nbg XX8BM/GeLMWTlmnUOAqpuIj+XmgzXD9N/bqQiMsUxXuRsNht3OMr3WJNA2/KZ+QfFpH4 dipQ== X-Gm-Message-State: APjAAAVqpHX+foiqilDk8e059u/Yg52kvIi610PegBm/u0JZn2WmAYn+ ui5VJcGLIEHL31mtbbZooAx1z/SZhdHvK4II+ck= X-Google-Smtp-Source: APXvYqy+6mrL81OCIGwBn8uD0pIbCg0T2zqk0zsLQSAq9425U9oZI4GuGkME7wrKwF6v04dMUEIDqKZF/FVewWXsrKM= X-Received: by 2002:a5d:8c81:: with SMTP id g1mr8033083ion.239.1563926572088; Tue, 23 Jul 2019 17:02:52 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 23 Jul 2019 17:02:51 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 23 Jul 2019 17:02:51 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000c8d62d058e6207ef" Archived-At: Subject: Re: [LOOPS] LOOPS BOF X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 00:02:56 -0000 --000000000000c8d62d058e6207ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See inline. Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 23, 2019 at 7:54:37 PM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: Hi, Marie-Jose, Thank you for bring these considerations to this mailing list. (Aside - what follows is my opinion with no hats, because I don't have any, but I hope it is also helpful to the LOOPS community). On Tue, Jul 23, 2019 at 7:12 PM Marie-Jose Montpetit wrote: > My take on Monday=E2=80=99s non-WG forming BOF - in a nutshell what is th= e > problem? (not even the scope yet) > > If it is performance optimization over interconnected links with differen= t > delay/loss characteristics and with or without host collaboration and/or > access I am sorry to tell you that there has been a lot of work done in > industry and academia addressing this. > One way that the IESG has chartered new work in the past, has been when research communities feel that at least some of their research output is stable enough to standardize for engineering. As NWCRG co-chair, you would know (but others may not) that some of your work came to TSVWG in order to add Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME - and that worked, because three of those documents are in the RFC Editor queue now. IRTF work coming to the IETF allows wider review, and publication on the Internet standards track. I agree and LOOPS could be some exit strategy for the work. But talking to us before could have been nice. I had talked to some of the proponents individually but not in a BOF sense. I hope LOOPS will consider NWCRG's experience in this area. > Whatever you do you will hit t the fact that a lot of the network coding > or FEC you need is protected. > Do you mean IPR-encumbered? If so, that doe mean IETF working groups providing technology to perform local optimizations will need to consider IPR and licensing disclosures. > Will LOOPS develop at new code? If yes then LOOPS is NWCWG the IETF > version of our RG. > The question of reference implementations should be considered by the LOOPS community before requesting WG actions by the IESG. There are many. Depends on the use case. > You will also hit the tunneling limitations and of course proprietary PEP= s > (the open source ones are okish though) and the usual issues of congestio= n > losses vs. random losses and we have looked at this for ages now it seems > and we have gotten good at it. > That will be very helpful in scoping LOOPS. OK. We can discuss that. I disagree with the assessment that =E2=80=9Clong losses=E2=80=9D are due t= o congestion on > your path, they may be due to issues on another path and in wireless some > kind of deep fade that the lower layers did not catch - beware that =E2= =80=9Cdelay=E2=80=9D > is also a sign of loss. > This is exactly the kind of question that an IETF working group should be looking at. IETF? I think a lot of that is research. > I agree with some of the discussions today > : what layer are > we talking about here? L3? But some of the diagrams showed OLT and below > L3. =E2=80=9CSolving" problems at L3 without looking at what is either = below or > above is I think something the proposing team should look at. It has help= ed > me in the past. > Agree. I had the privilege of watching most of the LOOPS proponents discussing their thoughts intensely for almost the entire length of the Hackathon last weekend, and I think you're pointing to the misalignments that are inevitable when many implementers are working in isolation. That alignment needs to happen during chartering discussions, so that we are all solving the same problem. About 10-12 BOF participants raised their hands to indicate that they were working on products in this space, and the proponents are hoping to make it easier for these people to be more aligned. That is the point. The architectures presented at the BOF were mixing layers. Again like Aaron Falk said: what is the problem? > A combination of the work we did in NWCRG and what has also been addresse= d > in ICNRG and ICCRG (and others) is what LOOPS needs. DO we need a new WG = to > get that work out of IRTF? > If it is to be published on the Internet standards track, yes. The IRTF stream produces Informational and Experimental RFCs, but not BCPs or Standards-track RFCs. Ok. But ignoring what we did in the RGs is no way forward. And kills the purpose of the IRTF. > But if the goal of this group is to make progress there are other issues > to address. Mine would be how to implement L3 solutions in an L4 encrypte= d > world. And others. > Yes. Discussions on this mailing list will be necessary to scope any charter requests to the IESG, if we don't want to be holding another BOF in Singapore that starts from where we are now :-) Ok > Just to say you are there to improve Internet performance of course is > good: we are all here to do that. > Again, thank you for your help and insights. Spencer Thanks > mjm > > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000c8d62d058e6207ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
See = inline.

Marie-Jos=C3=A9 Montpetit= , Ph.D.
Research Affiliate, MIT Media Laboratory

On July 23, 2019 at 7:54:37 PM, Spencer Dawkins at IE= TF (spencerdawkins.ietf@gm= ail.com) wrote:

Hi, Marie-Jose,=C2=A0

Thank y= ou for bring these considerations to this mailing list.=C2=A0
(Aside - what follows is my opinion with no hats, because I don= 't have any, but I hope it is also helpful to the LOOPS community).=C2= =A0

On Tue, Jul 23, 2019 at 7:12 PM Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
My tak= e on Monday=E2=80=99s non-WG forming BOF - in a nu= tshell what is the problem? (not even the scope yet)

If it is perf= ormance optimization over interconnected links with different delay/loss ch= aracteristics and with or without host collaboration and/or access I am sor= ry to tell you that there has been a lot of work done in industry and acade= mia addressing this.

One= way that the IESG has chartered new work in the past, has been when resear= ch communities feel that at least some of their research output is stable e= nough to standardize for engineering. As NWCRG co-chair, you would know (bu= t others may not) that some of your work came to TSVWG in order to add=C2= =A0Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)= Schemes for FECFRAME - and that worked, because three of those documents a= re in the RFC Editor queue now. IRTF work coming to the IETF allows wider r= eview, and publication on the Internet standards track.=C2=A0

I agree and LOOPS could be som= e exit strategy for the work. But talking to us before could have been nice= . I had talked to some of the proponents individually but not in a BOF sens= e.


I hope LOOPS will cons= ider NWCRG's experience in this area.
=C2=A0
Whatever you d= o you will hit t the fact that a lot of the network=C2=A0coding or FE= C you need is protected.

Do you mean IPR-encumbered? If so, that doe mean IETF working group= s providing technology to perform local optimizations will need to consider= IPR and licensing disclosures.=C2=A0=C2=A0=C2=A0
=C2=A0
Will LOOPS develop at new code? If yes then LOOPS is NWCWG the IETF ver= sion of our RG.=C2=A0

=
The question of reference implementations should be considered by the = LOOPS community before requesting WG actions by the IESG.=C2=A0
=

There are many. Depends on t= he use case.


=C2=A0
You will also hit = the tunneling limitations and of course proprietary PEPs (the open source o= nes are okish though) and the usual issues of congestion losses vs. random = losses and we have looked at this for ages now it seems and we have gotten = good at it.

That will be= very helpful in scoping LOOPS.=C2=A0
<= /blockquote>

OK. We can discuss that.



I disagree with the assessment that =E2=80=9Clong= losses=E2=80=9D are due to congestion on your path, they may be due to iss= ues on another path and in wireless some kind of deep fade that the lower l= ayers did not catch - beware that =E2=80=9Cdelay=E2=80=9D is also a sign of= loss.=C2=A0

This is exa= ctly the kind of question that an IETF working group should be looking at.<= /div>

IETF? I think a l= ot of that is research.


=C2=A0
I agree with some of the discussions=C2=A0to= day: what layer are we talking abo= ut here? L3?=C2=A0 But some of the diagrams showed OLT and below =C2=A0L3. = =C2=A0=E2=80=9CSolving" problems at L3 without looking at what is eith= er below or above is I think something the proposing team should look at. I= t has helped me in the past.

=
Agree. I had the privilege of watching most of the LOOPS proponents di= scussing their thoughts intensely for almost the entire length of the Hacka= thon last weekend, and I think you're pointing to the misalignments tha= t are inevitable when many implementers are working in isolation. That alig= nment needs to happen during chartering discussions, so that we are all sol= ving the same problem. About 10-12 BOF participants raised their hands to i= ndicate that they were working on products in this space, and the proponent= s are hoping to make it easier for these people to be more aligned.=C2=A0

That is the point.= The architectures presented at the BOF were mixing layers. Again like Aaro= n Falk said: what is the problem?

=C2=A0
A combination of the w= ork we did in NWCRG and what has also been addressed in ICNRG and ICCRG (an= d others) is what LOOPS needs. DO we need a new WG to get that work out of = IRTF?

If it is to be= published on the Internet standards track, yes. The IRTF stream produces I= nformational and Experimental RFCs, but not BCPs or Standards-track RFCs.= =C2=A0

Ok. But ig= noring what we did in the RGs is no way forward. And kills the purpose of t= he IRTF.=C2=A0


=C2=A0
But= if the goal of this group is to make progress there are other issues to ad= dress. Mine would be how to implement L3 solutions in an L4 encrypted world= . And others.=C2=A0

Yes.= Discussions on this mailing list will be necessary to scope any charter re= quests to the IESG, if we don't want to be holding another BOF in Singa= pore that starts from where we are now :-)

Ok


=C2=A0
Just to say you are there to improve Internet performance of c= ourse is good: we are all here to do that.

Again, thank you for your help and insights.=C2=A0<= /div>

Spencer

Thanks


=C2=A0
= mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.
Research Affiliate, MIT Media Lab= oratory
--
LOOP= S mailing list
LOOPS= @ietf.org
https://www.ietf.org/mailman/listinfo/lo= ops
<= /div> --000000000000c8d62d058e6207ef-- From nobody Wed Jul 24 07:54:48 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F612006F; Wed, 24 Jul 2019 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAfaxqiUUkuQ; Wed, 24 Jul 2019 07:54:45 -0700 (PDT) Received: from clarinet.employees.org (unknown [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826451200F4; Wed, 24 Jul 2019 07:54:42 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2001:67c:370:128:2b:ca8d:3bb4:1807]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id A6EA54E11A4F; Wed, 24 Jul 2019 14:54:41 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 9C5A51954045; Wed, 24 Jul 2019 10:54:40 -0400 (EDT) From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <984ADA80-CBEF-47AF-8DBE-23546DFABD95@employees.org> Date: Wed, 24 Jul 2019 10:54:40 -0400 Cc: loops-chairs@ietf.org, Magnus Westerlund To: loops@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [LOOPS] Loops session minutes posted X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 14:54:47 -0000 Dear all, The draft minutes from the Monday BOF session are available here: https://datatracker.ietf.org/meeting/105/materials/minutes-105-loops-00 Please review. Best regards, Ole and Spencer From nobody Wed Jul 24 08:25:21 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABE512039C for ; Wed, 24 Jul 2019 08:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh2WpDzaP4qy for ; Wed, 24 Jul 2019 08:25:17 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 7A3731203C1 for ; Wed, 24 Jul 2019 08:25:10 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 62so27378804lfa.8 for ; Wed, 24 Jul 2019 08:25:10 -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=L0vGgmG+ZmVvy4FFXNIVH2rpHOugq+e+9z9YbHvoJoc=; b=kmGOd84Q9r3FyRW3mRSf4++lrmWfAU85OhP9+elWRqKsMmD1+0P7FZQrfQmKn0GBE6 +cZBVFdUW0ihMMVLWMol5sP7H4gtoWLh2osrhF2RICG7lLMiKOKoJJYud3a/skC5rCqA BuF4/iZXl/kg8MlG+bB8GTCvNKn+XnTPwYbgZTtEE76hjb3UzAc5al0EcgCZ328tJfsC 5JZ8RxDm0pORdAXOwYGB+tuLRRx+3BloBO1Y27YIUl5+ETIgeeYHvfJpNV1SXmKx/VvD v+MSe+rHzmJFseQu0DBKT4SxQF5tSFniAL3zrYTpe3xwrJEO6JhVZZpvLUNidVt6mZAY QLkA== 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=L0vGgmG+ZmVvy4FFXNIVH2rpHOugq+e+9z9YbHvoJoc=; b=BaKM1uyzyA46ZDAR7FX8F5Txon4KK8aaUAJN2AYFehx3el8yyz+NDVXcJnGqkkscPT 0SsxCUwhptInywSwiqpAT+z8KBJ9CFVhOWtS7PFjSrvgfeqOehMZ6d+rQuUqHNSVTTFO dB7hNnt0RCzEZOh7KiNUHFWDcxosc9SS3ET++dd7s987jAIVj3ZJdTLFloyvfxjfQqVt Ar1Rzv/uiQuKG2JHXcSX1Tx5Hu3hte+QdZcptD7PgUYSjhowXwpJ/K1lf0s00l13KFwj 7Pwz1KjOo3AMc7o2hfJsCoKi4n6AO3Y7jZJ5E/uUibSBllkFT56Nx6CCVycHJ+d+2txD 9Vew== X-Gm-Message-State: APjAAAW3Ch0dm9VqeAruWLi1IC9PZzazRHc7Wp39u9p77Qw5MIRjTg/X PF2Nw6qfOzlf9el0G7mrLs6A18codBMMRGow5Qs= X-Google-Smtp-Source: APXvYqxc9Vsrjq9RJow7hYSpT7NUExGry52hzjvQuNXz35Whg2qhJq+My+q0wFvAXkXnXqqyhMrSlFUQSwsPXWGZko0= X-Received: by 2002:ac2:5337:: with SMTP id f23mr39412560lfh.15.1563981908669; Wed, 24 Jul 2019 08:25:08 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Wed, 24 Jul 2019 11:24:43 -0400 Message-ID: To: Magnus Westerlund Cc: Mirja Kuehlewind , Suresh Krishnan , loops@ietf.org, IAB IAB Content-Type: multipart/alternative; boundary="00000000000019f9f1058e6eea9b" Archived-At: Subject: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:25:20 -0000 --00000000000019f9f1058e6eea9b Content-Type: text/plain; charset="UTF-8" Hi, Magnus, Ole and I wanted to let you know what things looked like to us as co-chairs. We are copying the mailing list, to provide transparency for the LOOPS community. Wes Hardaker suggested that we copy the IAB because at least two IAB folk were covering the BOF, and would be sending write-ups to the IAB and IESG afterwards. (Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail on the mailing list. Interested IAB members are subscribed to LOOPS, or will be very soon. Uninterested IAB members don't need more e-mail from us!) First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. That was extremely helpful. Draft minutes have been posted at https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize ... We asked these questions at the beginning of the BOF: Chairs: What sort of people were in the room? - 1/3 transport people - 1/3 encaps people - 1/10 apps people - 2 ops people - 5 measurements people - 1.5 security people - 10-12 people on products/systems they do some form of enhancement. - Who has read the problem draft? 1/3 room We think that holding a BOF was a good decision, based on the number of people (even in the room) working on products and systems in this space. We think that holding a non-working group-forming BOF was a good decision, because many of the people who have been working in this space haven't been talking to each other (which makes products that don't interoperate or provide the same services in the same way - same as our previous experience with NATs). Providing a place for them to talk was very helpful. Ole was impressed at the low number of tourists in the room. The key points from the BOF proponents were - First, do no harm - measure what you're doing, and adjust what you're doing based on feedback, including turning your optimizations off entirely. - Do local repair between LOOPS endpoints, not involving hosts (at least, not now) - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out of scope (at least for now) - Use FEC for local repair - Do The Right Thing in tuning FEC usage based on feedback - In some cases, use limited retransmission for local repair, probably if FEC is not sufficient The key points from discussion were - Marie-Jose Montpetit, co-chair of Network Coding Research Group, said that they have much research that is applicable for FEC. Marie-Jean has followed up on the mailing list after the BOF. - It's not clear how much vendors in this space want a standardized solution, but it's more likely that operators will want that - Multiple people have concerns about masking signals about actual losses and adverse interactions between multiple levels of optimizations. These are things to watch out for in future work Hums at the end of the session were - There are multiple problems involved here, so a key next step will be teasing those problems apart and identifying what the IETF (and IRTF) has already done, that is applicable, and could be reused with no changes, or extended/modified as part of LOOPS, and what problems still remain unaddressed and clearly require protocol work in the IETF - Colin Perkins said there were big parts of the LOOPS problem set that are engineering now (Spencer and Ole happen to agree) - Andrew McGregor said that LOOPS would benefit from additional research (Spencer and Ole happen to agree, but think there is enough engineering work that waiting for more research to charter work isn't necessary) - Magnus asked if standardization in this space would be useful or beneficial. Many hums YES, some hums NO. We will send our recommendations on how to follow up to the LOOPS mailing list separately, so that the discussion happens in the right place. If IESG and IAB people have opinions about that, subscribing would be good :-) We can imagine that work in this space would result in standards-conformant products, but we can also imagine that work in this space would result in significantly improved proprietary products, or standards-conformant products with significant extensions. A lot depends on the people doing the work. Thanks for the opportunity to serve the community in this way. Spencer and Ole, as co-chairs for the BOF --00000000000019f9f1058e6eea9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Magnus,=C2=A0

Ole and I wanted to l= et you know what things looked like to us as co-chairs.=C2=A0
We are copying the mailing list, to provide transparency for th= e LOOPS community. Wes Hardaker suggested that we copy the IAB because at l= east two IAB folk were covering the BOF, and would be sending write-ups to = the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to = remove the IAB from any follow-up e-mail on the mailing list. Interested IA= B members are subscribed to LOOPS, or will be very soon. Uninterested IAB m= embers don't need more e-mail from us!)

First,= I'd like to thank you (and Suresh) for bringing in an INT co-chair. Th= at was extremely helpful.=C2=A0

Draft minutes have= been posted at=C2=A0https://datatracker.ietf.org/doc/minutes-105-loops/. But, to = summarize ...=C2=A0

We asked these questions at th= e beginning of the BOF:

Chairs: What sort of peopl= e were in the room?
  • 1/3 transport people
  • 1/3 encaps peop= le
  • 1/10 apps people
  • 2 ops people
  • 5 measurements peo= ple
  • 1.5 security people
  • 10-12 people on products/systems th= ey do some form of enhancement.
  • Who has read the problem draft? =C2= =A01/3 room
We think that holding a BOF was a good decisi= on, based on the number of people (even in the room) working on products an= d systems in this space.=C2=A0

We think that= holding a non-working group-forming BOF was a good decision, because many = of the people who have been working in this space haven't been talking = to each other (which makes products that don't interoperate or provide = the same services in the same way - same as our previous experience with NA= Ts). Providing a place for them to talk was very helpful.

Ole was impressed at the low number of tourists in the room.=C2=A0<= /div>

The key points from the BOF proponents were
<= div>
  • First, do no harm - measure what you're doing, and adjust w= hat you're doing based on feedback, including turning your optimization= s off entirely.
  • Do local repair between LOOPS endpoints, not involv= ing hosts (at least, not now)
  • Multipath; Measurement; MTU-handling;= Encapsulation/Tunnels were out of scope (at least for now)
  • Use= FEC for local repair
  • Do The Right Thing in tuning FEC usage based = on feedback
  • In some cases, use limited retransmission for local rep= air, probably if FEC is not sufficient
The key points fro= m discussion were
  • Marie-Jose Montpetit, co-chair of Netwo= rk Coding Research Group, said that they have much research that is applica= ble for FEC. Marie-Jean has followed up on the mailing list after the BOF.<= br>
  • It's not clear how much vendors in this space want a standa= rdized solution, but it's more likely that operators will want that=C2= =A0
  • Multiple people have concerns about masking signals about actua= l losses and adverse interactions between multiple levels of optimizations.= These are things to watch out for in future work
Hums at the= end of the session were=C2=A0
  • There are multiple problem= s involved here, so a key next step will be teasing those problems apart an= d identifying what the IETF (and IRTF) has already done, that is applicable= , and could be reused with no changes, or extended/modified as part of LOOP= S, and what problems still remain unaddressed and clearly require protocol = work in the IETF
  • Colin Perkins said there were big parts of the LOO= PS problem set that are engineering now (Spencer and Ole happen to agree)
  • Andrew McGregor said that LOOPS would benefit from additional resear= ch (Spencer and Ole happen to agree, but think there is enough engineering = work that waiting for more research to charter work isn't necessary)
  • Magnus asked if standardization in this space would be useful or bene= ficial. Many hums YES, some hums NO.=C2=A0
We will send= our recommendations on how to follow up to the LOOPS mailing list separate= ly, so that the discussion happens in the right place. If IESG and IAB peop= le have opinions about that, subscribing would be good :-)=C2=A0
<= /div>

We can imagine that work in this space would resul= t in standards-conformant products, but we can also imagine that work in th= is space would result in significantly improved proprietary products, or st= andards-conformant products with significant extensions. A lot depends on t= he people doing the work.=C2=A0

Thanks for the opp= ortunity to serve the community in this way.

Spenc= er and Ole, as co-chairs for the BOF
--00000000000019f9f1058e6eea9b-- From nobody Wed Jul 24 08:30:48 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F43120496 for ; Wed, 24 Jul 2019 08:30:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFvV7_gYrtb6 for ; Wed, 24 Jul 2019 08:30:39 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 3141F12048A for ; Wed, 24 Jul 2019 08:30:38 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id e20so60095041iob.9 for ; Wed, 24 Jul 2019 08:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aZavIbRK+5b8P4+enKcgpVd/Sh4K8qa7vJ9AXeSHfNc=; b=a6FEj5qGxIvpEmslzlagVbdA6+UvZFNpc+M9nmKHDdOnth3qwtQEvGFVEg1RMGLLP+ SAizyaaJe+k5a5QvGRp6CoSkmY52AZptGSecKQheKDrr0mX7xr8NdqeH3SM45gcIjwu2 vmkXDxCEo1d3HcHpoYDegF8zg7WGbrUEt8WYuPNRDA26kRc5xiztmxtdxRPbhKRV5pUm 8vhBSud5340Wxhhy6DcWaSoHfFGgFxnwN6wqW2aokk4rn4Nf1S8GwNkEp8fPkW5rjUwv PoOkvMAn1o0SVfRSxb2EAA6dAfQSHDqvwx8RKv3Gnnfn4bo7q22Zuw1xe1j7RMpx7zia GGvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=aZavIbRK+5b8P4+enKcgpVd/Sh4K8qa7vJ9AXeSHfNc=; b=E9adkt6w8KtslOGY51dDpxxq/APfBP3i9exYguLFzZlUTXDdtqYqaEobR35ex9GONk 168LKeQ/thbH/XsTke3mgCxKcHTRGrB2D/clmSvt7xEarI5/kz+67Xw+sVx4f3a1JGjU 9S1Wz20bgXWTBlIGKsvK5uJra6BP01qKHdrqBYW2UDNRKNeBv58Pr3nLDuP1vwwaqB1d 9bDE/Zf2kdbqVPM4N6XeZkrLFO2G3Yo1xzY6LMGclIWUFYggiRw4V0WFsW4jCiuwYIuc GQpb1mS2pzt5S8Tdw9redl774mWwQ49V3GTz97U1Dtre99zlsb4fOM5agXcYOZUCXJDw jNYw== X-Gm-Message-State: APjAAAXcKxR6rxhOSgaPuOXJScQeWgOU1AqhqZexTjv40OVLN/EAqVLW JnoIDWNt8bfonTipO0ZP2+mmOQlwrHe4hI6c+eA= X-Google-Smtp-Source: APXvYqzyHUMXuMX/YCFMZHyETEaUbOv3Nj4wS/4rkpKgLiJG9dIwZDqGzHqxRNm81zVLsm3WoHzhm4cfzj5AEtlqxgA= X-Received: by 2002:a6b:6e01:: with SMTP id d1mr5032057ioh.156.1563982237415; Wed, 24 Jul 2019 08:30:37 -0700 (PDT) Received: from 895490483151 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jul 2019 08:30:37 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 24 Jul 2019 08:30:37 -0700 Message-ID: To: Magnus Westerlund , Spencer Dawkins at IETF Cc: Suresh Krishnan , IAB IAB , Mirja Kuehlewind , loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000b25a1b058e6efdd0" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:30:46 -0000 --000000000000b25a1b058e6efdd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There was no Marie-Jean follow up. It was only me :) Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 24, 2019 at 11:24:43 AM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: > Hi, Magnus, > > Ole and I wanted to let you know what things looked like to us as > co-chairs. > > We are copying the mailing list, to provide transparency for the LOOPS > community. Wes Hardaker suggested that we copy the IAB because at least t= wo > IAB folk were covering the BOF, and would be sending write-ups to the IAB > and IESG afterwards. > > (Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail > on the mailing list. Interested IAB members are subscribed to LOOPS, or > will be very soon. Uninterested IAB members don't need more e-mail from u= s!) > > First, I'd like to thank you (and Suresh) for bringing in an INT co-chair= . > That was extremely helpful. > > Draft minutes have been posted at > https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize > ... > > We asked these questions at the beginning of the BOF: > > Chairs: What sort of people were in the room? > > - 1/3 transport people > - 1/3 encaps people > - 1/10 apps people > - 2 ops people > - 5 measurements people > - 1.5 security people > - 10-12 people on products/systems they do some form of enhancement. > - Who has read the problem draft? 1/3 room > > We think that holding a BOF was a good decision, based on the number of > people (even in the room) working on products and systems in this space. > > We think that holding a non-working group-forming BOF was a good decision= , > because many of the people who have been working in this space haven't be= en > talking to each other (which makes products that don't interoperate or > provide the same services in the same way - same as our previous experien= ce > with NATs). Providing a place for them to talk was very helpful. > > Ole was impressed at the low number of tourists in the room. > > The key points from the BOF proponents were > > - First, do no harm - measure what you're doing, and adjust what > you're doing based on feedback, including turning your optimizations o= ff > entirely. > - Do local repair between LOOPS endpoints, not involving hosts (at > least, not now) > - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out > of scope (at least for now) > - Use FEC for local repair > - Do The Right Thing in tuning FEC usage based on feedback > - In some cases, use limited retransmission for local repair, probably > if FEC is not sufficient > > The key points from discussion were > > - Marie-Jose Montpetit, co-chair of Network Coding Research Group, > said that they have much research that is applicable for FEC. Marie-Je= an > has followed up on the mailing list after the BOF. > - It's not clear how much vendors in this space want a standardized > solution, but it's more likely that operators will want that > - Multiple people have concerns about masking signals about actual > losses and adverse interactions between multiple levels of optimizatio= ns. > These are things to watch out for in future work > > Hums at the end of the session were > > - There are multiple problems involved here, so a key next step will > be teasing those problems apart and identifying what the IETF (and IRT= F) > has already done, that is applicable, and could be reused with no chan= ges, > or extended/modified as part of LOOPS, and what problems still remain > unaddressed and clearly require protocol work in the IETF > - Colin Perkins said there were big parts of the LOOPS problem set > that are engineering now (Spencer and Ole happen to agree) > - Andrew McGregor said that LOOPS would benefit from additional > research (Spencer and Ole happen to agree, but think there is enough > engineering work that waiting for more research to charter work isn't > necessary) > - Magnus asked if standardization in this space would be useful or > beneficial. Many hums YES, some hums NO. > > We will send our recommendations on how to follow up to the LOOPS mailing > list separately, so that the discussion happens in the right place. If IE= SG > and IAB people have opinions about that, subscribing would be good :-) > > We can imagine that work in this space would result in > standards-conformant products, but we can also imagine that work in this > space would result in significantly improved proprietary products, or > standards-conformant products with significant extensions. A lot depends = on > the people doing the work. > > Thanks for the opportunity to serve the community in this way. > > Spencer and Ole, as co-chairs for the BOF > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000b25a1b058e6efdd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There was no Marie-Jean follow up. It was only me = :)

Marie-Jos=C3=A9 Montpetit, Ph.D.<= div>Research Affiliate, MIT Media Laboratory
On July 24, 2019 at 11:24:43 AM= , Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wrote:

Hi, Magnus,=C2=A0

Ole and I wanted to let you know what things looked like to us as co-chairs.=C2=A0

We are copying the mailing list, to provide transparency for the LOOPS community. Wes Hardaker suggested that we copy the IAB because at least two IAB folk were covering the BOF, and would be sending write-ups to the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail on the mailing list. Interested IAB members are subscribed to LOOPS, or will be very soon. Uninterested IAB members don't need more e-mail from us!)

First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. That was extremely helpful.=C2=A0

Draft minutes have been posted at=C2=A0https://datatracker.ietf.org/doc/minutes-1= 05-loops/. But, to summarize ...=C2=A0

We asked these questions at the beginning of the BOF:

Chairs: What sort of people were in the room?
  • 1/3 transport people
  • 1/3 encaps people
  • 1/10 apps people
  • 2 ops people
  • 5 measurements people
  • 1.5 security people
  • 10-12 people on products/systems they do some form of enhancement.
  • Who has read the problem draft? =C2=A01/3 room
We think that holding a BOF was a good decision, based on the number of people (even in the room) working on products and systems in this space.=C2=A0

We think that holding a non-working group-forming BOF was a good decision, because many of the people who have been working in this space haven't been talking to each other (which makes products that don't interoperate or provide the same services in the same way - same as our previous experience with NATs). Providing a place for them to talk was very helpful.

Ole was impressed at the low number of tourists in the room.=C2=A0

The key points from the BOF proponents were
  • First, do no harm - measure what you're doing, and adjust what you're doing based on feedback, including turning your optimizations off entirely.
  • Do local repair between LOOPS endpoints, not involving hosts (at least, not now)
  • Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out of scope (at least for now)
  • Use FEC for local repair
  • Do The Right Thing in tuning FEC usage based on feedback
  • In some cases, use limited retransmission for local repair, probably if FEC is not sufficient
The key points from discussion were
  • Marie-Jose Montpetit, co-chair of Network Coding Research Group, said that they have much research that is applicable for FEC. Marie-Jean has followed up on the mailing list after the BOF.
  • It's not clear how much vendors in this space want a standardized solution, but it's more likely that operators will want that=C2=A0
  • Multiple people have concerns about masking signals about actual losses and adverse interactions between multiple levels of optimizations. These are things to watch out for in future work
Hums at the end of the session were=C2=A0
  • There are multiple problems involved here, so a key next step will be teasing those problems apart and identifying what the IETF (and IRTF) has already done, that is applicable, and could be reused with no changes, or extended/modified as part of LOOPS, and what problems still remain unaddressed and clearly require protocol work in the IETF
  • Colin Perkins said there were big parts of the LOOPS problem set that are engineering now (Spencer and Ole happen to agree)
  • Andrew McGregor said that LOOPS would benefit from additional research (Spencer and Ole happen to agree, but think there is enough engineering work that waiting for more research to charter work isn't necessary)
  • Magnus asked if standardization in this space would be useful or beneficial. Many hums YES, some hums NO.=C2=A0
We will send our recommendations on how to follow up to the LOOPS mailing list separately, so that the discussion happens in the right place. If IESG and IAB people have opinions about that, subscribing would be good :-)=C2=A0

We can imagine that work in this space would result in standards-conformant products, but we can also imagine that work in this space would result in significantly improved proprietary products, or standards-conformant products with significant extensions. A lot depends on the people doing the work.=C2=A0

Thanks for the opportunity to serve the community in this way.

Spencer and Ole, as co-chairs for the BOF
-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.iet= f.org/mailman/listinfo/loops
--000000000000b25a1b058e6efdd0-- From nobody Wed Jul 24 08:33:31 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BE7120341 for ; Wed, 24 Jul 2019 08:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgP3z5ET-N6C for ; Wed, 24 Jul 2019 08:33:25 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 D0217120383 for ; Wed, 24 Jul 2019 08:33:24 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id d24so44916557ljg.8 for ; Wed, 24 Jul 2019 08:33:24 -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=0+IWGYpE5ofA1aIAz8+HAZQH3g8fAkPgUdfnJZdE/V0=; b=MweVGkjpWL5ibAP1RAcng8sihB7ZgE2feJrkjX3gDwDujfgZpvEaRQDV0OaY4PsZJj eUjwZ6VIPkNByyefxONRDukzNWVamMHH3OF/ksreyDOAZAvUpJIbZXl9sp1P5H4PR3Kc zHjceYgR+7ZTZjTUZDCsfq/hrJf7eUPjMPYhkBHl62IeYFd556ql0NIYkbhkH/QF5imC KTgn1wIfdeGyA6oUJYG2Hae9a/+WGmg1xzt5QWnQRTDCiFX40rzCiUn0/dn13ddVEPgQ XT9+P+dQ9Bu1x0ZHNyTu2oeXZ7eDzXFmEJTvxXCUAzLvWoKtw8X7bWNuvazl/sit3evQ lJRA== 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=0+IWGYpE5ofA1aIAz8+HAZQH3g8fAkPgUdfnJZdE/V0=; b=Sdey7/79UgwsWIAnu/Rr71UBtfJ2WwAu/mVsiZNOVzeICBMHEXoAtdunCfBJU0Nj05 /nm71eBz6Ic3KvtPe5oZlqeyGPhqQCdtLBk+jP1THk8LS1WogkOV3h3XjPKlWKHhK0fr gtuYCArDyhfAhIumpjGiVKyzHB9e7MKKXddOgoBgFGeN8/3q9dZcg2ZHyYUZNbPziUjW FPBzigahSgOk1+h+yEyr/3hZ0aqJvMiCMWoQGLYIzmM1toLVyV4Z9Qdx+cs+6WYl5kZt m7dRQXIj9SX5M7wi3xWnZ5r/H87ihEeBzeZ4MpKff2SKKt3sRts56VklwCwgDKqeqR0M qS3A== X-Gm-Message-State: APjAAAVPsMgtN1pe7Q47GX7PKgpyW0wGybIdpDG6uKGpMtmlPNf5hGbw L1luf+Oy4aN+Tni6hCBF+7Jz3WRGpqzWEg8qTwQ= X-Google-Smtp-Source: APXvYqykn35triTzEIC2LaGFTrFMFAuFNvREafEU5LiS716fB/lN+DfQD7JQ1p0LDLk/Q7cgAHADzv1Is1OsftBHu2k= X-Received: by 2002:a2e:96c3:: with SMTP id d3mr323569ljj.68.1563982402993; Wed, 24 Jul 2019 08:33:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 24 Jul 2019 11:32:58 -0400 Message-ID: To: Marie-Jose Montpetit Cc: Magnus Westerlund , Suresh Krishnan , IAB IAB , Mirja Kuehlewind , loops@ietf.org Content-Type: multipart/alternative; boundary="00000000000090c2ba058e6f0728" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 15:33:29 -0000 --00000000000090c2ba058e6f0728 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Marie-Jose, On Wed, Jul 24, 2019 at 11:30 AM Marie-Jose Montpetit wrote: > There was no Marie-Jean follow up. It was only me :) > My apologies for horrible mental pattern matching! It was definitely you ;-= ) Best regards, Spencer Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 24, 2019 at 11:24:43 AM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: > Hi, Magnus, > > Ole and I wanted to let you know what things looked like to us as > co-chairs. > > We are copying the mailing list, to provide transparency for the LOOPS > community. Wes Hardaker suggested that we copy the IAB because at least t= wo > IAB folk were covering the BOF, and would be sending write-ups to the IAB > and IESG afterwards. > > (Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail > on the mailing list. Interested IAB members are subscribed to LOOPS, or > will be very soon. Uninterested IAB members don't need more e-mail from u= s!) > > First, I'd like to thank you (and Suresh) for bringing in an INT co-chair= . > That was extremely helpful. > > Draft minutes have been posted at > https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize > ... > > We asked these questions at the beginning of the BOF: > > Chairs: What sort of people were in the room? > > - 1/3 transport people > - 1/3 encaps people > - 1/10 apps people > - 2 ops people > - 5 measurements people > - 1.5 security people > - 10-12 people on products/systems they do some form of enhancement. > - Who has read the problem draft? 1/3 room > > We think that holding a BOF was a good decision, based on the number of > people (even in the room) working on products and systems in this space. > > We think that holding a non-working group-forming BOF was a good decision= , > because many of the people who have been working in this space haven't be= en > talking to each other (which makes products that don't interoperate or > provide the same services in the same way - same as our previous experien= ce > with NATs). Providing a place for them to talk was very helpful. > > Ole was impressed at the low number of tourists in the room. > > The key points from the BOF proponents were > > - First, do no harm - measure what you're doing, and adjust what > you're doing based on feedback, including turning your optimizations o= ff > entirely. > - Do local repair between LOOPS endpoints, not involving hosts (at > least, not now) > - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out > of scope (at least for now) > - Use FEC for local repair > - Do The Right Thing in tuning FEC usage based on feedback > - In some cases, use limited retransmission for local repair, probably > if FEC is not sufficient > > The key points from discussion were > > - Marie-Jose Montpetit, co-chair of Network Coding Research Group, > said that they have much research that is applicable for FEC. Marie-Je= an > has followed up on the mailing list after the BOF. > - It's not clear how much vendors in this space want a standardized > solution, but it's more likely that operators will want that > - Multiple people have concerns about masking signals about actual > losses and adverse interactions between multiple levels of optimizatio= ns. > These are things to watch out for in future work > > Hums at the end of the session were > > - There are multiple problems involved here, so a key next step will > be teasing those problems apart and identifying what the IETF (and IRT= F) > has already done, that is applicable, and could be reused with no chan= ges, > or extended/modified as part of LOOPS, and what problems still remain > unaddressed and clearly require protocol work in the IETF > - Colin Perkins said there were big parts of the LOOPS problem set > that are engineering now (Spencer and Ole happen to agree) > - Andrew McGregor said that LOOPS would benefit from additional > research (Spencer and Ole happen to agree, but think there is enough > engineering work that waiting for more research to charter work isn't > necessary) > - Magnus asked if standardization in this space would be useful or > beneficial. Many hums YES, some hums NO. > > We will send our recommendations on how to follow up to the LOOPS mailing > list separately, so that the discussion happens in the right place. If IE= SG > and IAB people have opinions about that, subscribing would be good :-) > > We can imagine that work in this space would result in > standards-conformant products, but we can also imagine that work in this > space would result in significantly improved proprietary products, or > standards-conformant products with significant extensions. A lot depends = on > the people doing the work. > > Thanks for the opportunity to serve the community in this way. > > Spencer and Ole, as co-chairs for the BOF > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --00000000000090c2ba058e6f0728 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Marie-Jose,

On Wed, Jul 24, 2019 at 11:30 = AM Marie-Jose Montpetit <marie@= mjmontpetit.com> wrote:
There was no Marie-Jean follow up. It was only me :)

My apologies for horrible mental pa= ttern matching! It was definitely you ;-)

Best reg= ards,

Spencer=C2=A0

Marie-Jos=C3=A9 Montpetit,= Ph.D.
Research Affiliate, MIT Media Laboratory

On July 24, 2019 at 11:24:43 AM, Spencer Dawkins at IETF = (spencer= dawkins.ietf@gmail.com) wrote:

Hi, Magnus,=C2=A0

Ole and I wanted to let you know what things looked like to us as co-chairs.=C2=A0

We are copying the mailing list, to provide transparency for the LOOPS community. Wes Hardaker suggested that we copy the IAB because at least two IAB folk were covering the BOF, and would be sending write-ups to the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail on the mailing list. Interested IAB members are subscribed to LOOPS, or will be very soon. Uninterested IAB members don't need more e-mail from us!)

First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. That was extremely helpful.=C2=A0

Draft minutes have been posted at=C2=A0https://datatracker.ietf= .org/doc/minutes-105-loops/. But, to summarize ...=C2=A0

We asked these questions at the beginning of the BOF:

Chairs: What sort of people were in the room?
  • 1/3 transport people
  • 1/3 encaps people
  • 1/10 apps people
  • 2 ops people
  • 5 measurements people
  • 1.5 security people
  • 10-12 people on products/systems they do some form of enhancement.
  • Who has read the problem draft? =C2=A01/3 room
We think that holding a BOF was a good decision, based on the number of people (even in the room) working on products and systems in this space.=C2=A0

We think that holding a non-working group-forming BOF was a good decision, because many of the people who have been working in this space haven't been talking to each other (which makes products that don't interoperate or provide the same services in the same way - same as our previous experience with NATs). Providing a place for them to talk was very helpful.

Ole was impressed at the low number of tourists in the room.=C2=A0

The key points from the BOF proponents were
  • First, do no harm - measure what you're doing, and adjust what you're doing based on feedback, including turning your optimizations off entirely.
  • Do local repair between LOOPS endpoints, not involving hosts (at least, not now)
  • Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out of scope (at least for now)
  • Use FEC for local repair
  • Do The Right Thing in tuning FEC usage based on feedback
  • In some cases, use limited retransmission for local repair, probably if FEC is not sufficient
The key points from discussion were
  • Marie-Jose Montpetit, co-chair of Network Coding Research Group, said that they have much research that is applicable for FEC. Marie-Jean has followed up on the mailing list after the BOF.
  • It's not clear how much vendors in this space want a standardized solution, but it's more likely that operators will want that=C2=A0
  • Multiple people have concerns about masking signals about actual losses and adverse interactions between multiple levels of optimizations. These are things to watch out for in future work
Hums at the end of the session were=C2=A0
  • There are multiple problems involved here, so a key next step will be teasing those problems apart and identifying what the IETF (and IRTF) has already done, that is applicable, and could be reused with no changes, or extended/modified as part of LOOPS, and what problems still remain unaddressed and clearly require protocol work in the IETF
  • Colin Perkins said there were big parts of the LOOPS problem set that are engineering now (Spencer and Ole happen to agree)
  • Andrew McGregor said that LOOPS would benefit from additional research (Spencer and Ole happen to agree, but think there is enough engineering work that waiting for more research to charter work isn't necessary)
  • Magnus asked if standardization in this space would be useful or beneficial. Many hums YES, some hums NO.=C2=A0
We will send our recommendations on how to follow up to the LOOPS mailing list separately, so that the discussion happens in the right place. If IESG and IAB people have opinions about that, subscribing would be good :-)=C2=A0

We can imagine that work in this space would result in standards-conformant products, but we can also imagine that work in this space would result in significantly improved proprietary products, or standards-conformant products with significant extensions. A lot depends on the people doing the work.=C2=A0

Thanks for the opportunity to serve the community in this way.

Spencer and Ole, as co-chairs for the BOF
-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--00000000000090c2ba058e6f0728-- From nobody Wed Jul 24 14:40:33 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33CE1203B8 for ; Wed, 24 Jul 2019 14:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XiaFT9h6OfE for ; Wed, 24 Jul 2019 14:40:29 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 28539120159 for ; Wed, 24 Jul 2019 14:40:29 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id r15so15976286lfm.11 for ; Wed, 24 Jul 2019 14:40:29 -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=Pdmqd7B854jWb0B4V7/oOrJ0a/yRFIY3ilcFtcqoJUQ=; b=Y0m6InB2WBs5Jp7aRWfz65N+GNXakxLZiEV2IU7l3CN3qSgy08k5P0S8S4N2O9vPrQ 3Va6CiHaKD5CE/m7Yu13acVUCbAsWFeDhdFdPARPsiKRCAVFBoxZX9IioTYz2ZHfWgVM Hk3KQpLDegH9dkAP1cyptCBDkJRXmk20rpCXMmZBWJ2JCS1yYJcDg8WGGookU20DWBZ3 cPVLe/zAc1gDj6HnpDUyIObtLiZX0A+GfJspXyDLYFmq4mNZg63/H0/PjltQTQ5BaIq5 lF3bBCQA2Yptkt277LgrQm9191MtIqbA/i/afjY4Ogf4A91zy2CbIqQZlf7iV4fRcoNf WlaQ== 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=Pdmqd7B854jWb0B4V7/oOrJ0a/yRFIY3ilcFtcqoJUQ=; b=kf9twwdn/xJeyiiYnZsZgzvGu8634wjc0sXL04WWA+scVAfnM6hpvdUDHLqXK1/daV cNLg4Gf2f1EA51JmIFPVbZOk0BCGFV2ztCZMrZ5UGrO2K/U1lnFz8uR/tEXrYg71onSX 1Viq7XtfubfhNQv9ebF59UA+qiCvJbl/WFC6mStLAsdvsr6IK45BpI81vDFqG4BCW/tI WwnDA/w7at/cqmKnX0goBCMYzr5cFBGjiy90KxJOqorbpnl3bm5G8a8+CNb7f1lSP9eO lkDR711FOpvYrrkcCSBBWp2/1rzOywbbrnXj9A/E7wHwesDpbLnhRzeI4HcJTWtstvah ckvg== X-Gm-Message-State: APjAAAVgtPK9ZBXZ9/L8zuUbicgJK+NHoEqlxmUd0AInx2n+niB9/CJF HclTA9RvQe5dJvpxn+LG2HTSBRuQqdg9XhqZb0w= X-Google-Smtp-Source: APXvYqyJ/0h7IS0qx518wcTPDL0mrO8FpFJk05iqBgpFmr77/yuJU1mfsgRdyOo3mVeFCDDFFNEmES7BMKrYc9WzRIY= X-Received: by 2002:a19:f806:: with SMTP id a6mr26094686lff.102.1564004427286; Wed, 24 Jul 2019 14:40:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 24 Jul 2019 17:40:03 -0400 Message-ID: To: Magnus Westerlund Cc: Mirja Kuehlewind , Suresh Krishnan , loops@ietf.org Content-Type: multipart/alternative; boundary="00000000000050cee4058e742847" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 21:40:33 -0000 --00000000000050cee4058e742847 Content-Type: text/plain; charset="UTF-8" Dear All, I met with the ADs to talk about the next steps they would like to see for LOOPS. Here's what I know. - There are people working in this space now - The community thinks standardization would help - What's necessary is to identify exactly what work is required, so that the ADs can make decisions about where that work should take place. - We got some suggestions about technologies that could be used in LOOPS at the BOF. That will be a great starting point. - Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D I told Magnus I was willing to work with the LOOPS community as you move forward toward a charter. Make good choices! Spencer On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Magnus, > > Ole and I wanted to let you know what things looked like to us as > co-chairs. > > We are copying the mailing list, to provide transparency for the LOOPS > community. Wes Hardaker suggested that we copy the IAB because at least two > IAB folk were covering the BOF, and would be sending write-ups to the IAB > and IESG afterwards. > > (Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail > on the mailing list. Interested IAB members are subscribed to LOOPS, or > will be very soon. Uninterested IAB members don't need more e-mail from us!) > > First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. > That was extremely helpful. > > Draft minutes have been posted at > https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize > ... > > We asked these questions at the beginning of the BOF: > > Chairs: What sort of people were in the room? > > - 1/3 transport people > - 1/3 encaps people > - 1/10 apps people > - 2 ops people > - 5 measurements people > - 1.5 security people > - 10-12 people on products/systems they do some form of enhancement. > - Who has read the problem draft? 1/3 room > > We think that holding a BOF was a good decision, based on the number of > people (even in the room) working on products and systems in this space. > > We think that holding a non-working group-forming BOF was a good decision, > because many of the people who have been working in this space haven't been > talking to each other (which makes products that don't interoperate or > provide the same services in the same way - same as our previous experience > with NATs). Providing a place for them to talk was very helpful. > > Ole was impressed at the low number of tourists in the room. > > The key points from the BOF proponents were > > - First, do no harm - measure what you're doing, and adjust what > you're doing based on feedback, including turning your optimizations off > entirely. > - Do local repair between LOOPS endpoints, not involving hosts (at > least, not now) > - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out > of scope (at least for now) > - Use FEC for local repair > - Do The Right Thing in tuning FEC usage based on feedback > - In some cases, use limited retransmission for local repair, probably > if FEC is not sufficient > > The key points from discussion were > > - Marie-Jose Montpetit, co-chair of Network Coding Research Group, > said that they have much research that is applicable for FEC. Marie-Jose > has followed up on the mailing list after the BOF. > - It's not clear how much vendors in this space want a standardized > solution, but it's more likely that operators will want that > - Multiple people have concerns about masking signals about actual > losses and adverse interactions between multiple levels of optimizations. > These are things to watch out for in future work > > Hums at the end of the session were > > - There are multiple problems involved here, so a key next step will > be teasing those problems apart and identifying what the IETF (and IRTF) > has already done, that is applicable, and could be reused with no changes, > or extended/modified as part of LOOPS, and what problems still remain > unaddressed and clearly require protocol work in the IETF > - Colin Perkins said there were big parts of the LOOPS problem set > that are engineering now (Spencer and Ole happen to agree) > - Andrew McGregor said that LOOPS would benefit from additional > research (Spencer and Ole happen to agree, but think there is enough > engineering work that waiting for more research to charter work isn't > necessary) > - Magnus asked if standardization in this space would be useful or > beneficial. Many hums YES, some hums NO. > > We will send our recommendations on how to follow up to the LOOPS mailing > list separately, so that the discussion happens in the right place. If IESG > and IAB people have opinions about that, subscribing would be good :-) > > We can imagine that work in this space would result in > standards-conformant products, but we can also imagine that work in this > space would result in significantly improved proprietary products, or > standards-conformant products with significant extensions. A lot depends on > the people doing the work. > > Thanks for the opportunity to serve the community in this way. > > Spencer and Ole, as co-chairs for the BOF > --00000000000050cee4058e742847 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,=C2=A0

I met with t= he ADs to talk about the next steps they would like to see for LOOPS.=C2=A0=

Here's what I know.=C2=A0
  • T= here are people working in this space now
  • The community thinks stan= dardization would help
  • What's necessary is to identify exactly = what work is required, so that the ADs can make decisions about where that = work should take place.=C2=A0
  • We got some suggestions about technol= ogies that could be used in LOOPS at the BOF. That will be a great starting= point.=C2=A0
  • Here's a hint from the ADs - if the proponents ca= n come up with a clear charter, limited in scope, that will make their live= s easier, and make it easier for them to charter this work :D
=
I told Magnus I was willing to work with the LOOPS community as you mo= ve forward toward a charter.=C2=A0

Make good choic= es!

Spencer




On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.co= m> wrote:
Hi, Magnus,=C2=A0

Ole and I wanted to = let you know what things looked like to us as co-chairs.=C2=A0
We are copying the mailing list, to provide transparency for t= he LOOPS community. Wes Hardaker suggested that we copy the IAB because at = least two IAB folk were covering the BOF, and would be sending write-ups to= the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to= remove the IAB from any follow-up e-mail on the mailing list. Interested I= AB members are subscribed to LOOPS, or will be very soon. Uninterested IAB = members don't need more e-mail from us!)

First= , I'd like to thank you (and Suresh) for bringing in an INT co-chair. T= hat was extremely helpful.=C2=A0

Draft minutes hav= e been posted at=C2=A0https://datatracker.ietf.org/doc/minutes-105-l= oops/. But, to summarize ...=C2=A0

We asked th= ese questions at the beginning of the BOF:

Chairs:= What sort of people were in the room?
  • 1/3 transport people
    • =
  • 1/3 encaps people
  • 1/10 apps people
  • 2 ops people
    • 5 measurements people
  • 1.5 security people
  • 10-12 people on = products/systems they do some form of enhancement.
  • Who has read the= problem draft? =C2=A01/3 room
We think that holding a BO= F was a good decision, based on the number of people (even in the room) wor= king on products and systems in this space.=C2=A0

We think that holding a non-working group-forming BOF was a good deci= sion, because many of the people who have been working in this space haven&= #39;t been talking to each other (which makes products that don't inter= operate or provide the same services in the same way - same as our previous= experience with NATs). Providing a place for them to talk was very helpful= .

Ole was impressed at the low number of tourists = in the room.=C2=A0

The key points from the BOF pro= ponents were
  • First, do no harm - measure what you're = doing, and adjust what you're doing based on feedback, including turnin= g your optimizations off entirely.
  • Do local repair between LOOPS en= dpoints, not involving hosts (at least, not now)
  • Multipath; Measure= ment; MTU-handling; Encapsulation/Tunnels were out of scope (at least for n= ow)
  • Use FEC for local repair
  • Do The Right Thing in tuni= ng FEC usage based on feedback
  • In some cases, use limited retransmi= ssion for local repair, probably if FEC is not sufficient
The key points from discussion were
  • Marie-Jose Montpetit= , co-chair of Network Coding Research Group, said that they have much resea= rch that is applicable for FEC. Marie-Jose has followed up on the mailing l= ist after the BOF.
  • It's not clear how much vendors in this = space want a standardized solution, but it's more likely that operators= will want that=C2=A0
  • Multiple people have concerns about masking s= ignals about actual losses and adverse interactions between multiple levels= of optimizations. These are things to watch out for in future work
    • Hums at the end of the session were=C2=A0
    • There ar= e multiple problems involved here, so a key next step will be teasing those= problems apart and identifying what the IETF (and IRTF) has already done, = that is applicable, and could be reused with no changes, or extended/modifi= ed as part of LOOPS, and what problems still remain unaddressed and clearly= require protocol work in the IETF
    • Colin Perkins said there were bi= g parts of the LOOPS problem set that are engineering now (Spencer and Ole = happen to agree)
    • Andrew McGregor said that LOOPS would benefit from= additional research (Spencer and Ole happen to agree, but think there is e= nough engineering work that waiting for more research to charter work isn&#= 39;t necessary)
    • Magnus asked if standardization in this space would= be useful or beneficial. Many hums YES, some hums NO.=C2=A0
    We will send our recommendations on how to follow up to the LOOPS mai= ling list separately, so that the discussion happens in the right place. If= IESG and IAB people have opinions about that, subscribing would be good :-= )=C2=A0

    We can imagine that work in this= space would result in standards-conformant products, but we can also imagi= ne that work in this space would result in significantly improved proprieta= ry products, or standards-conformant products with significant extensions. = A lot depends on the people doing the work.=C2=A0

    = Thanks for the opportunity to serve the community in this way.
    Spencer and Ole, as co-chairs for the BOF
--00000000000050cee4058e742847-- From nobody Wed Jul 24 15:17:34 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF51202C3 for ; Wed, 24 Jul 2019 15:17:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stHSrEm5ZoYp for ; Wed, 24 Jul 2019 15:17:29 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C243C120112 for ; Wed, 24 Jul 2019 15:17:29 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k20so92932821ios.10 for ; Wed, 24 Jul 2019 15:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=GOG+ydi2wbdplMceLhTs9FycNvVsivLLK2yxbIqpiwk=; b=To9/Znu03IPndXsCLYsMF9nYWpeyg9aFpnUFnr8LNqgfto0m/ZUefnO0kkVTuytm7i GmKBD84ZO/yewX7HdnXAhiiLG4gPunNsLtA17L+xuXxS0xpVWIOP3TDUNE9WH5fwBeQY c5eOAJE2mvW71X6ESaNrpcAuUaH2VK2tQ3EvZ9ylJmNNK4TO+Jk3oJhwB52U+oYNbh0K /gGsCJznFgls4gC8r3Zd4tq6Sot9OTKCGySCkgY/sE37/cBmJ8NR86v53py8zxfqxYjR tXBrFp4NjY6T7zgYhe8/U6ub7r/b9Xr4bswet3rX0/9N9e8bm7aV4+j+3IkJ6Hn/Cujo wRGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=GOG+ydi2wbdplMceLhTs9FycNvVsivLLK2yxbIqpiwk=; b=cYcGsatSzZjfT10MH4e5lgaoqlPUyyjo6p+kHXtNKCgPKOYH+yjnRHRzhvtGAMw/u1 P+8AiEnNFG3oqGmP6f5Z9I5auv4UVfKtZMosv5KaocbNzlFZ4ui9up5nGri7iIa04Ej/ HhPxZ8OJx5BjC6+qc3MGV/aZ8y0iFRu1LskplUAP/yt+U/1uAGC7oXLmSyDp4IAxRJeb T5yUZiqzy7hgQ3xK8WPDdaXaDGJM8qYLySJglSgwu3Gl6UGczRmz9SZNCv6zots0C1MS 3YX9gowEtt2nV9PkqGfN2zMoEBYY5/lupRrGNTk2wOJXb79fQQGmVXXo4Ovvu7Dba/9F MqhA== X-Gm-Message-State: APjAAAVONMOKXEDgnld2mYPqT1VuVlRc3ruhvoHstglGe1oRZb2t/EWC f/nf5WW23Zxwzs3GtgMfbBtlPt1X7xNPyL5mhu4= X-Google-Smtp-Source: APXvYqwvVAFmKnx5idMP9A6uh7aCy29/5PchzbcYpQWuxnkGfKm6w04E6+UQKkOlwj9K/OptRy8KalicsrfDZZtW1V4= X-Received: by 2002:a05:6638:38f:: with SMTP id y15mr32874318jap.143.1564006649028; Wed, 24 Jul 2019 15:17:29 -0700 (PDT) Received: from 895490483151 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jul 2019 15:17:28 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 24 Jul 2019 15:17:28 -0700 Message-ID: To: Magnus Westerlund , Spencer Dawkins at IETF Cc: loops@ietf.org, Mirja Kuehlewind , Suresh Krishnan Content-Type: multipart/alternative; boundary="000000000000bdf6a4058e74ac1f" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2019 22:17:33 -0000 --000000000000bdf6a4058e74ac1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies? mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 24, 2019 at 5:40:03 PM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: > Dear All, > > I met with the ADs to talk about the next steps they would like to see fo= r > LOOPS. > > Here's what I know. > > - There are people working in this space now > - The community thinks standardization would help > - What's necessary is to identify exactly what work is required, so > that the ADs can make decisions about where that work should take plac= e. > - We got some suggestions about technologies that could be used in > LOOPS at the BOF. That will be a great starting point. > - Here's a hint from the ADs - if the proponents can come up with a > clear charter, limited in scope, that will make their lives easier, an= d > make it easier for them to charter this work :D > > I told Magnus I was willing to work with the LOOPS community as you move > forward toward a charter. > > Make good choices! > > Spencer > > > > > On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Magnus, >> >> Ole and I wanted to let you know what things looked like to us as >> co-chairs. >> >> We are copying the mailing list, to provide transparency for the LOOPS >> community. Wes Hardaker suggested that we copy the IAB because at least = two >> IAB folk were covering the BOF, and would be sending write-ups to the IA= B >> and IESG afterwards. >> >> (Dear LOOPists - you may wish to remove the IAB from any follow-up e-mai= l >> on the mailing list. Interested IAB members are subscribed to LOOPS, or >> will be very soon. Uninterested IAB members don't need more e-mail from = us!) >> >> First, I'd like to thank you (and Suresh) for bringing in an INT >> co-chair. That was extremely helpful. >> >> Draft minutes have been posted at >> https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize >> ... >> >> We asked these questions at the beginning of the BOF: >> >> Chairs: What sort of people were in the room? >> >> - 1/3 transport people >> - 1/3 encaps people >> - 1/10 apps people >> - 2 ops people >> - 5 measurements people >> - 1.5 security people >> - 10-12 people on products/systems they do some form of enhancement. >> - Who has read the problem draft? 1/3 room >> >> We think that holding a BOF was a good decision, based on the number of >> people (even in the room) working on products and systems in this space. >> >> We think that holding a non-working group-forming BOF was a good >> decision, because many of the people who have been working in this space >> haven't been talking to each other (which makes products that don't >> interoperate or provide the same services in the same way - same as our >> previous experience with NATs). Providing a place for them to talk was v= ery >> helpful.. >> >> Ole was impressed at the low number of tourists in the room. >> >> The key points from the BOF proponents were >> >> - First, do no harm - measure what you're doing, and adjust what >> you're doing based on feedback, including turning your optimizations = off >> entirely. >> - Do local repair between LOOPS endpoints, not involving hosts (at >> least, not now) >> - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were >> out of scope (at least for now) >> - Use FEC for local repair >> - Do The Right Thing in tuning FEC usage based on feedback >> - In some cases, use limited retransmission for local repair, >> probably if FEC is not sufficient >> >> The key points from discussion were >> >> - Marie-Jose Montpetit, co-chair of Network Coding Research Group, >> said that they have much research that is applicable for FEC. Marie-J= ose >> has followed up on the mailing list after the BOF. >> - It's not clear how much vendors in this space want a standardized >> solution, but it's more likely that operators will want that >> - Multiple people have concerns about masking signals about actual >> losses and adverse interactions between multiple levels of optimizati= ons. >> These are things to watch out for in future work >> >> Hums at the end of the session were >> >> - There are multiple problems involved here, so a key next step will >> be teasing those problems apart and identifying what the IETF (and IR= TF) >> has already done, that is applicable, and could be reused with no cha= nges, >> or extended/modified as part of LOOPS, and what problems still remain >> unaddressed and clearly require protocol work in the IETF >> - Colin Perkins said there were big parts of the LOOPS problem set >> that are engineering now (Spencer and Ole happen to agree) >> - Andrew McGregor said that LOOPS would benefit from additional >> research (Spencer and Ole happen to agree, but think there is enough >> engineering work that waiting for more research to charter work isn't >> necessary) >> - Magnus asked if standardization in this space would be useful or >> beneficial. Many hums YES, some hums NO. >> >> We will send our recommendations on how to follow up to the LOOPS mailin= g >> list separately, so that the discussion happens in the right place. If I= ESG >> and IAB people have opinions about that, subscribing would be good :-) >> >> We can imagine that work in this space would result in >> standards-conformant products, but we can also imagine that work in this >> space would result in significantly improved proprietary products, or >> standards-conformant products with significant extensions. A lot depends= on >> the people doing the work. >> >> Thanks for the opportunity to serve the community in this way. >> >> Spencer and Ole, as co-chairs for the BOF >> > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --000000000000bdf6a4058e74ac1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Standardisation of what? The architecture? The pro= tocols (beware there is already FECFRAME and others)? The proxies?

=
mjm

Marie-Jos=C3=A9 Montp= etit, Ph.D.
Research Affiliate, MIT Media Laboratory

On July 24, 2019 at= 5:40:03 PM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wrote:

Dear All,=C2=A0

I met with the ADs to talk about the next steps they would like to see for LOOPS.=C2=A0

Here's what I know.=C2=A0
  • There are people working in this space now
  • The community thinks standardization would help
  • What's necessary is to identify exactly what work is required, so that the ADs can make decisions about where that work should take place.=C2=A0
  • We got some suggestions about technologies that could be used in LOOPS at the BOF. That will be a great starting point.=C2=A0
  • Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D
I told Magnus I was willing to work with the LOOPS community as you move forward toward a charter.=C2=A0

Make good choices!

Spencer




On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Magnus,=C2=A0

Ole and I wanted to let you know what things looked like to us as co-chairs.=C2=A0

We are copying the mailing list, to provide transparency for the LOOPS community. Wes Hardaker suggested that we copy the IAB because at least two IAB folk were covering the BOF, and would be sending write-ups to the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail on the mailing list. Interested IAB members are subscribed to LOOPS, or will be very soon. Uninterested IAB members don't need more e-mail from us!)

First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. That was extremely helpful.=C2=A0

Draft minutes have been posted at=C2=A0https://datatracker.ietf= .org/doc/minutes-105-loops/. But, to summarize ...=C2=A0

We asked these questions at the beginning of the BOF:

Chairs: What sort of people were in the room?
  • 1/3 transport people
  • 1/3 encaps people
  • 1/10 apps people
  • 2 ops people
  • 5 measurements people
  • 1.5 security people
  • 10-12 people on products/systems they do some form of enhancement.
  • Who has read the problem draft? =C2=A01/3 room
We think that holding a BOF was a good decision, based on the number of people (even in the room) working on products and systems in this space.=C2=A0

We think that holding a non-working group-forming BOF was a good decision, because many of the people who have been working in this space haven't been talking to each other (which makes products that don't interoperate or provide the same services in the same way - same as our previous experience with NATs). Providing a place for them to talk was very helpful..

Ole was impressed at the low number of tourists in the room.=C2=A0

The key points from the BOF proponents were
  • First, do no harm - measure what you're doing, and adjust what you're doing based on feedback, including turning your optimizations off entirely.
  • Do local repair between LOOPS endpoints, not involving hosts (at least, not now)
  • Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out of scope (at least for now)
  • Use FEC for local repair
  • Do The Right Thing in tuning FEC usage based on feedback
  • In some cases, use limited retransmission for local repair, probably if FEC is not sufficient
The key points from discussion were
  • Marie-Jose Montpetit, co-chair of Network Coding Research Group, said that they have much research that is applicable for FEC. Marie-Jose has followed up on the mailing list after the BOF.
  • It's not clear how much vendors in this space want a standardized solution, but it's more likely that operators will want that=C2=A0
  • Multiple people have concerns about masking signals about actual losses and adverse interactions between multiple levels of optimizations. These are things to watch out for in future work
Hums at the end of the session were=C2=A0
  • There are multiple problems involved here, so a key next step will be teasing those problems apart and identifying what the IETF (and IRTF) has already done, that is applicable, and could be reused with no changes, or extended/modified as part of LOOPS, and what problems still remain unaddressed and clearly require protocol work in the IETF
  • Colin Perkins said there were big parts of the LOOPS problem set that are engineering now (Spencer and Ole happen to agree)
  • Andrew McGregor said that LOOPS would benefit from additional research (Spencer and Ole happen to agree, but think there is enough engineering work that waiting for more research to charter work isn't necessary)
  • Magnus asked if standardization in this space would be useful or beneficial. Many hums YES, some hums NO.=C2=A0
We will send our recommendations on how to follow up to the LOOPS mailing list separately, so that the discussion happens in the right place. If IESG and IAB people have opinions about that, subscribing would be good :-)=C2=A0

We can imagine that work in this space would result in standards-conformant products, but we can also imagine that work in this space would result in significantly improved proprietary products, or standards-conformant products with significant extensions. A lot depends on the people doing the work.=C2=A0

Thanks for the opportunity to serve the community in this way.

Spencer and Ole, as co-chairs for the BOF
-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.iet= f.org/mailman/listinfo/loops
--000000000000bdf6a4058e74ac1f-- From nobody Wed Jul 24 21:56:41 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9611201E2 for ; Wed, 24 Jul 2019 21:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sNbue90HqYSd for ; Wed, 24 Jul 2019 21:56:38 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBD51201C5 for ; Wed, 24 Jul 2019 21:56:37 -0700 (PDT) Received: from dhcp-9abf.meeting.ietf.org (dhcp-9abf.meeting.ietf.org [31.133.154.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vKgR5N4bzykm; Thu, 25 Jul 2019 06:56:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jul 2019 00:56:33 -0400 Cc: Magnus Westerlund , Spencer Dawkins at IETF , Mirja Kuehlewind , loops@ietf.org, Suresh Krishnan X-Mao-Original-Outgoing-Id: 585723392.010839-c9494d8d4024ec7ab14e6d0d9e068dcd Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 04:56:40 -0000 On Jul 24, 2019, at 18:17, Marie-Jose Montpetit = wrote: >=20 > Standardisation of what? The architecture? The protocols (beware there = is already FECFRAME and others)? The proxies? Hi Marie-Jos=C3=A9, details of the thinking that was developed in the side meetings that = happened at the previous two IETF meetings can be found at https://github.com/loops-wg/charter The BOF actually added one piece of information I didn=E2=80=99t = previously perceive that way: People seem to really want to tackle the host-to-node case (as needed, = e.g., for going through WiFi access clouds) right away, not just the = in-network (node-to-node) case. That would be the one thing I would = change based on my recollection of the BOF. But of course there may be = other things; it may be worth to now have another round of discussion of = the proposed charter. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 25 03:32:49 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1296E12012E for ; Thu, 25 Jul 2019 03:32:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dY0l5YUaXua for ; Thu, 25 Jul 2019 03:32:46 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5291201F8 for ; Thu, 25 Jul 2019 03:32:45 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id s7so96032296iob.11 for ; Thu, 25 Jul 2019 03:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=JzQawyr8OyIvBK8X1BVd989x+K+oz78eCKbCrE/nSr0=; b=yGwuuK5YRDEpW/8Dpvgjk7bBRxbmU61gFSPfpO7un62a0fojcdqj0X/HVXtXPDOGql DWeYQ0iryUe/3Jdrx7pwf0sOLtHCmvvziHQx1XH8MgpTRgbhcduPlpnauQmXblkwo4T3 saHmxpiGhHPEYK7yHMbrp3kXouO2/m++r4OOCXud1aSdxBuWE+7bo5kv/8/v4u/NrF4A sd/MLHih+lmnO+3n0QT+30mNrctWbqk6sY9v1q2xBni83+zr+DHJmQs90Wm9FJyhXgZN T37n1yXnteAruN7VIsGTYig6TZdvTxhrICFIxp63+Q53T2adGY0UtJ7TVw5K18UV4Jhi bSXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=JzQawyr8OyIvBK8X1BVd989x+K+oz78eCKbCrE/nSr0=; b=SBckic8K8NI0ksUU6mj0mMP3h9eTg6H9vjsbB1BRBF3Dm8VQy7bW37HaghzP0ijE+d n3R58BbTd7Emsokzr5bkAr08WWxGQBGegL6SuER8+mu0BMywUMESwz+x6Hi7EFal7Iha 5XqT3HyxkaABoZs4ypiJjOyx+Zw77IgnkFIOO/58hCJbEngdLv9945dwq/B/48vfnEyi BYhdXVi6bsIsoA7iT6Ss5Cm561fBqMnf0tsiJ8OAb9H4cTOj7BdiuH5S9aA5RypvXzzi XLsaiUVwrif46RZUJnkce9HhTSCHRUT3S0QpcJmEN/+fNV0eSnTx4MFpYF8ifHIVXAgP 5Ndw== X-Gm-Message-State: APjAAAUWrdA3X+TOtckDV1ivH2cAAoYJ3wHfQZnW5Q6ZN0/Nu3y65Bd0 TLjhsIWVYSG7LJ/LNx8CHNmtTqjmk+w9rmvsFZs= X-Google-Smtp-Source: APXvYqyXqBoqYmn5pcz43vZGtyu75q/E+F3ejyXZtwgUw+YiLj2cIXtmsjp7lRFPuLo51mTEIoUQJmGxMTRuSXyRn1Y= X-Received: by 2002:a5d:96d8:: with SMTP id r24mr19188451iol.269.1564050765273; Thu, 25 Jul 2019 03:32:45 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jul 2019 03:32:44 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 25 Jul 2019 03:32:44 -0700 Message-ID: To: Carsten Bormann Cc: loops@ietf.org, Suresh Krishnan , Magnus Westerlund , Spencer Dawkins at IETF , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="0000000000004673a4058e7ef28f" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 10:32:48 -0000 --0000000000004673a4058e7ef28f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually the wifi to node segment was the original use case fo the nwcrg. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 25, 2019 at 12:56:37 AM, Carsten Bormann (cabo@tzi.org) wrote: On Jul 24, 2019, at 18:17, Marie-Jose Montpetit wrote: > > Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies? Hi Marie-Jos=C3=A9, details of the thinking that was developed in the side meetings that happened at the previous two IETF meetings can be found at https://github.com/loops-wg/charter The BOF actually added one piece of information I didn=E2=80=99t previously perceive that way: People seem to really want to tackle the host-to-node case (as needed, e.g., for going through WiFi access clouds) right away, not just the in-network (node-to-node) case. That would be the one thing I would change based on my recollection of the BOF. But of course there may be other things; it may be worth to now have another round of discussion of the proposed charter. Gr=C3=BC=C3=9Fe, Carsten --0000000000004673a4058e7ef28f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Actu= ally the wifi to node segment was the original use case fo the nwcrg.
=

mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.
Research Affilia= te, MIT Media Laboratory

On Jul= y 25, 2019 at 12:56:37 AM, Carsten Bormann (cabo@tzi.org) wrote:

=
On Jul 24, 2019, at 18:17, Marie-Jose Montpetit = <marie@mjmontpetit.com> = wrote:
> =20
> Standardisation of what? The architecture? The protocols (beware t= here is already FECFRAME and others)? The proxies?

Hi Marie-Jos=C3=A9,

details of the thinking that was developed in the side meetings that ha= ppened at the previous two IETF meetings can be found at

https://github.com/loop= s-wg/charter

The BOF actually added one piece of information I didn=E2=80=99t previo= usly perceive that way:
People seem to really want to tackle the host-to-node case (as needed, = e.g., for going through WiFi access clouds) right away, not just the in-net= work (node-to-node) case. That would be the one thing I would change based= on my recollection of the BOF. But of course there may be other things; i= t may be worth to now have another round of discussion of the proposed char= ter.

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

--0000000000004673a4058e7ef28f-- From nobody Thu Jul 25 05:35:00 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5463D120183 for ; Thu, 25 Jul 2019 05:34:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INIBgp_mo-iB for ; Thu, 25 Jul 2019 05:34:56 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 397E31200A4 for ; Thu, 25 Jul 2019 05:34:56 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id j5so92693036ioj.8 for ; Thu, 25 Jul 2019 05:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PC3A+1B3wjsVi5L1AqT3rzZ4/qcTaLOcpzgC97RoBa0=; b=duLMJmZjSP1fxMTRk4EQAbIn0YfiKyuzWX6qNfOVAPyDOabvUHM+2Sa0pPbgEqN5eV Vcu+Dtfe5j92Fd4s9qJWfWCXuRV8hczll0RFXX0pLa8Q6X4xtF1jgnPS3JBwJEXZyewk piouLY1otkW/s58drXaBqDWtVcc5himOu1O3lsHYi8Kp0vQb0Os+cZvyMg0n8EbAjyuB ECqzYZqW+7tYuME/7uU5t0uf39bdpc2quhaRFmDK++h1UOZA4S/Zsfx8qwEirUZ1EJWU YQ2wkkqKFeeCKP4T1xPLslS1cIvl4h1/P1Zmc4hAO5pHmJTJclJ2LNK4JExGwB+jOXjT 2tpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PC3A+1B3wjsVi5L1AqT3rzZ4/qcTaLOcpzgC97RoBa0=; b=S/S3PjiDRkMyviCaemPsd8w7h0jBt7M6c0lSCwB55Dmdo2N/zEjWtFGi6q6MkQ6QY8 JCOktsZgs2r3xHBfLfXZUs3mpalNGU4Z2oE492M3ToXcmHRg6bG2YDdfhxEc3HlzJ9w0 0gaKmOet2/qSluezIkxG+bb1bAT/8H3qhZR/QFU+5yfjZ+jRxNqR4YmKXcOvYgjNQo3O d/z1Sl1lQ3zK4THDyQOIosW+7nNpsAIEl5UC17pOW5IYuKA8KG+GsCnc6GW6xG1NF6Yg jVWTWCA0ZqYltbJKmEO2wel2MAaMrbPPARPE+pyndAFNEyIeaK7p6dHMbGHPJitnmdjB C5zQ== X-Gm-Message-State: APjAAAUaS5GMmrExjDmCpxGQ4m5sdTeo68/TorX9PbwKr9T7NwkNTHJj XApKR+S2mB92j4Hv1ZmnqXCPdKXIYt//fBuhyLM= X-Google-Smtp-Source: APXvYqzdwQpt39IIZ+ReUu328eg5s1aoP7G494dU9WP7lwXcXpayfkPtEzPiioqdr3g1o2qBzSK/Lyi3QqR0hdnFruY= X-Received: by 2002:a02:8814:: with SMTP id r20mr94766607jai.115.1564058095453; Thu, 25 Jul 2019 05:34:55 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jul 2019 05:34:55 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 25 Jul 2019 05:34:54 -0700 Message-ID: To: Carsten Bormann Cc: loops@ietf.org, Suresh Krishnan , Magnus Westerlund , Spencer Dawkins at IETF , Mirja Kuehlewind , "nwcrg@irtf.org" Content-Type: multipart/alternative; boundary="000000000000301181058e80a7ac" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 12:34:58 -0000 --000000000000301181058e80a7ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding the nwcrg list to list thread. And with my NWCRG co-chair hat on. Like I mentioned the WIFI to node hop was one of the original successes of network coding as Prof. M=C3=A9dard and her team can attest to. A lot of th= e LOOPS use cases for per hop network optimization have been not only *researched* but *implemented* with running code by many of the nwcrg participants. NWCRG-ites; there was a LOOPS BOF on Monday to address the issues of performance in multiple hop networks and Carsten is pointing to the related material. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 25, 2019 at 12:56:37 AM, Carsten Bormann (cabo@tzi.org) wrote: On Jul 24, 2019, at 18:17, Marie-Jose Montpetit wrote: > > Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies? Hi Marie-Jos=C3=A9, details of the thinking that was developed in the side meetings that happened at the previous two IETF meetings can be found at https://github.com/loops-wg/charter The BOF actually added one piece of information I didn=E2=80=99t previously perceive that way: People seem to really want to tackle the host-to-node case (as needed, e.g., for going through WiFi access clouds) right away, not just the in-network (node-to-node) case. That would be the one thing I would change based on my recollection of the BOF. But of course there may be other things; it may be worth to now have another round of discussion of the proposed charter. Gr=C3=BC=C3=9Fe, Carsten --000000000000301181058e80a7ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Addi= ng the nwcrg list to list thread. And with my NWCRG co-chair hat on.
<= div style=3D"font-family:Helvetica,Arial;font-size:12px">
Like I mentioned the WIFI= to node hop was one of the original successes of network coding as Prof. M= =C3=A9dard and her team can attest to. A lot of the LOOPS use cases for per= hop network optimization have been not only researched but imple= mented with running code by many of the nwcrg participants.=C2=A0
=

NWCRG-ites; there was a = LOOPS BOF on Monday to address the issues of performance in multiple hop ne= tworks and Carsten is pointing to the related material.=C2=A0


mjm=C2=A0
Marie-Jos=C3=A9 Montpetit, Ph.D.
Research Affil= iate, MIT Media Laboratory

On J= uly 25, 2019 at 12:56:37 AM, Carsten Bormann (cabo@tzi.org) wrote:

On Jul 24, 2019, at 18:17, Marie-Jose Montpeti= t <marie@mjmontpetit.com>= ; wrote:
> =20
> Standardisation of what? The architecture? The protocols (beware t= here is already FECFRAME and others)? The proxies?

Hi Marie-Jos=C3=A9,

details of the thinking that was developed in the side meetings that ha= ppened at the previous two IETF meetings can be found at

https://github.com/loop= s-wg/charter

The BOF actually added one piece of information I didn=E2=80=99t previo= usly perceive that way:
People seem to really want to tackle the host-to-node case (as needed, = e.g., for going through WiFi access clouds) right away, not just the in-net= work (node-to-node) case. That would be the one thing I would change based= on my recollection of the BOF. But of course there may be other things; i= t may be worth to now have another round of discussion of the proposed char= ter.

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

--000000000000301181058e80a7ac-- From nobody Thu Jul 25 08:13:32 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E251202DE for ; Thu, 25 Jul 2019 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kLF1tFzPrZ0 for ; Thu, 25 Jul 2019 08:13:25 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450: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 AE7731201D1 for ; Thu, 25 Jul 2019 08:13:03 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id s19so34796614lfb.9 for ; Thu, 25 Jul 2019 08:13:03 -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=e05tDtS6LQZfVjbNrUTtpjFj0tX+Xcps4MqVsp0rh0Q=; b=lstUrt3tvTebx4yynIa8/0+Y9MAKPC5pfZBRf8ru5e0WoGMj9/h26ra3QrB/SM+QrL yHtMeNK2dT8zVZf1n4Qlf2qlWS8L70IKOMD3wkGpm2mD/j0BcAzuRKy+edEIi0dX0RK+ 7pweWRNqKKdugzHlgDCE/m2DqWk9p+iszoA6wIQOgjZwFDlLPlnHEFO7vUuAXnDajucG rRcp1kfk9jFk0uWFf6GwqpbgzANTe1jlqPgsx+QkDViICLsV0gUceQv76+W9gBQxRjNv Wqg4Dgy9ZiAAymxgR1BObzCzlR98BesxPiN+wPYwMdL9YIAvWgLhjIH4FJt7y2OOXqqh t/DQ== 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=e05tDtS6LQZfVjbNrUTtpjFj0tX+Xcps4MqVsp0rh0Q=; b=BYDuRbrPT3KpyFHMqwtUJlXG36k38kptv2EFXemRGfLd9e5N3IwN3r4CJnvskgvHae 6a2HOwTVA/y+VgEFRp5BtEcP21EkbGiFppkASzofhGhP1fdeOOliQa2DOlgUGsH+LdGP hnWktC5zt4+AM0HgZkcAF0Yj5XsYuzksJhl+k3yM3LC7OIlQRceOSJhcsBRyKznwOXEU 6FWyWWuu/cQHRRfJ4Ov4mRS/6Xl6zO3GRUFXYGJOvoO9BYcrFpT3t80tZLeptB5UZr7Y CATkQni5zWEbhtYQD8PZ35JKR49cLuZQgX0DOh3w9uTwHF/fGwAL4o0PBjhq/r9/vkPe e+hQ== X-Gm-Message-State: APjAAAWQ7kPUb74J5IkO+da6v7NKKuccU+vSqImw7C37yUWKBov+U9l9 C6+tBdVUrYGyfiHvQtCegoChhirioxpgis72SVM= X-Google-Smtp-Source: APXvYqzBR0ouhdXdSPrA2rzbQKcyEAmJXLTAhygbCi6oWN860OGOFzcFrEiqUYFcLG4/9DyVe84XBDM/0+Y76T2cGNQ= X-Received: by 2002:ac2:43d0:: with SMTP id u16mr10621404lfl.38.1564067581786; Thu, 25 Jul 2019 08:13:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 25 Jul 2019 11:12:36 -0400 Message-ID: To: Marie-Jose Montpetit Cc: Magnus Westerlund , loops@ietf.org, Mirja Kuehlewind , Suresh Krishnan Content-Type: multipart/alternative; boundary="0000000000009dfe1f058e82dc2d" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 15:13:29 -0000 --0000000000009dfe1f058e82dc2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Marie-Jose, On Wed, Jul 24, 2019 at 6:17 PM Marie-Jose Montpetit wrote: > Standardisation of what? The architecture? The protocols (beware there is > already FECFRAME and others)? The proxies? > Speaking as a chair for the IETF 105 BOF, which has already happened, so I have no special status in this discussion :-) I think that's a question that should guide LOOPS participants as they discuss items for a proposed charter. You mention a couple of possibilities, but in addition, the IETF can produce BCPs that explain how to use existing protocols and mechanisms effectively to improve performance. The IETF can also produce standards-track Applicability Statements that describe when those existing protocols and mechanisms should, and should not, be used. So there are a number of possible answers to your question, and IMO the LOOPS community should be looking at what exists today in more detail, including NWCRG work that is applicable, and then proposing a charter that includes what is needed, but does not yet exist. Past IESGs have referred to this as "maps and gaps analysis" - mapping what you need to do onto mechanisms that already exist, identifying gaps in those mechanisms, and then deciding what to do, to fill in those gaps. Best regards, Spencer > mjm > > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > > On July 24, 2019 at 5:40:03 PM, Spencer Dawkins at IETF ( > spencerdawkins.ietf@gmail.com) wrote: > >> Dear All, >> >> I met with the ADs to talk about the next steps they would like to see >> for LOOPS. >> >> Here's what I know. >> >> - There are people working in this space now >> - The community thinks standardization would help >> - What's necessary is to identify exactly what work is required, so >> that the ADs can make decisions about where that work should take pla= ce. >> - We got some suggestions about technologies that could be used in >> LOOPS at the BOF. That will be a great starting point. >> - Here's a hint from the ADs - if the proponents can come up with a >> clear charter, limited in scope, that will make their lives easier, a= nd >> make it easier for them to charter this work :D >> >> I told Magnus I was willing to work with the LOOPS community as you move >> forward toward a charter. >> >> Make good choices! >> >> Spencer >> >> >> >> >> On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> Hi, Magnus, >>> >>> Ole and I wanted to let you know what things looked like to us as >>> co-chairs. >>> >>> We are copying the mailing list, to provide transparency for the LOOPS >>> community. Wes Hardaker suggested that we copy the IAB because at least= two >>> IAB folk were covering the BOF, and would be sending write-ups to the I= AB >>> and IESG afterwards. >>> >>> (Dear LOOPists - you may wish to remove the IAB from any follow-up >>> e-mail on the mailing list. Interested IAB members are subscribed to LO= OPS, >>> or will be very soon. Uninterested IAB members don't need more e-mail f= rom >>> us!) >>> >>> First, I'd like to thank you (and Suresh) for bringing in an INT >>> co-chair. That was extremely helpful. >>> >>> Draft minutes have been posted at >>> https://datatracker.ietf.org/doc/minutes-105-loops/. But, to summarize >>> ... >>> >>> We asked these questions at the beginning of the BOF: >>> >>> Chairs: What sort of people were in the room? >>> >>> - 1/3 transport people >>> - 1/3 encaps people >>> - 1/10 apps people >>> - 2 ops people >>> - 5 measurements people >>> - 1.5 security people >>> - 10-12 people on products/systems they do some form of enhancement. >>> - Who has read the problem draft? 1/3 room >>> >>> We think that holding a BOF was a good decision, based on the number of >>> people (even in the room) working on products and systems in this space= . >>> >>> We think that holding a non-working group-forming BOF was a good >>> decision, because many of the people who have been working in this spac= e >>> haven't been talking to each other (which makes products that don't >>> interoperate or provide the same services in the same way - same as our >>> previous experience with NATs). Providing a place for them to talk was = very >>> helpful.. >>> >>> Ole was impressed at the low number of tourists in the room. >>> >>> The key points from the BOF proponents were >>> >>> - First, do no harm - measure what you're doing, and adjust what >>> you're doing based on feedback, including turning your optimizations= off >>> entirely. >>> - Do local repair between LOOPS endpoints, not involving hosts (at >>> least, not now) >>> - Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were >>> out of scope (at least for now) >>> - Use FEC for local repair >>> - Do The Right Thing in tuning FEC usage based on feedback >>> - In some cases, use limited retransmission for local repair, >>> probably if FEC is not sufficient >>> >>> The key points from discussion were >>> >>> - Marie-Jose Montpetit, co-chair of Network Coding Research Group, >>> said that they have much research that is applicable for FEC. Marie-= Jose >>> has followed up on the mailing list after the BOF. >>> - It's not clear how much vendors in this space want a standardized >>> solution, but it's more likely that operators will want that >>> - Multiple people have concerns about masking signals about actual >>> losses and adverse interactions between multiple levels of optimizat= ions. >>> These are things to watch out for in future work >>> >>> Hums at the end of the session were >>> >>> - There are multiple problems involved here, so a key next step will >>> be teasing those problems apart and identifying what the IETF (and I= RTF) >>> has already done, that is applicable, and could be reused with no ch= anges, >>> or extended/modified as part of LOOPS, and what problems still remai= n >>> unaddressed and clearly require protocol work in the IETF >>> - Colin Perkins said there were big parts of the LOOPS problem set >>> that are engineering now (Spencer and Ole happen to agree) >>> - Andrew McGregor said that LOOPS would benefit from additional >>> research (Spencer and Ole happen to agree, but think there is enough >>> engineering work that waiting for more research to charter work isn'= t >>> necessary) >>> - Magnus asked if standardization in this space would be useful or >>> beneficial. Many hums YES, some hums NO. >>> >>> We will send our recommendations on how to follow up to the LOOPS >>> mailing list separately, so that the discussion happens in the right pl= ace. >>> If IESG and IAB people have opinions about that, subscribing would be g= ood >>> :-) >>> >>> We can imagine that work in this space would result in >>> standards-conformant products, but we can also imagine that work in thi= s >>> space would result in significantly improved proprietary products, or >>> standards-conformant products with significant extensions. A lot depend= s on >>> the people doing the work. >>> >>> Thanks for the opportunity to serve the community in this way. >>> >>> Spencer and Ole, as co-chairs for the BOF >>> >> -- >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops >> > --0000000000009dfe1f058e82dc2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Marie-Jose,=C2=A0

On Wed, Jul 24, 2019= at 6:17 PM Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
Standardisation of what? The architecture? The= protocols (beware there is already FECFRAME and others)? The proxies?

Speaking as a chair for the IETF 105 BOF,= which has already happened, so I have no special status in this discussion= :-)

I think that's a question that should gui= de LOOPS participants as they discuss items for a proposed charter. You men= tion a couple of possibilities, but in addition, the IETF can produce BCPs = that explain how to use existing protocols and mechanisms effectively to im= prove performance. The IETF can also produce standards-track Applicability = Statements that describe when those existing protocols and mechanisms shoul= d, and should not, be used.=C2=A0

So there are a n= umber of possible answers to your=C2=A0question, and IMO the LOOPS communit= y should be looking at what exists today in more detail, including NWCRG wo= rk that is applicable, and then proposing a charter that includes what is n= eeded, but does not yet exist.=C2=A0

Past IESGs ha= ve referred to this as "maps and gaps analysis" - mapping what yo= u need to do onto mechanisms that already exist, identifying gaps in those = mechanisms, and then deciding what to do, to fill in those gaps.=C2=A0

Best regards,=C2=A0

Spencer
=C2=A0
mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.
Research Affiliate, MIT Me= dia Laboratory

On July 24, 2019 a= t 5:40:03 PM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wrote:

Dear All,=C2=A0

I met with the ADs to talk about the next steps they would like to see for LOOPS.=C2=A0

Here's what I know.=C2=A0
  • There are people working in this space now
  • The community thinks standardization would help
  • What's necessary is to identify exactly what work is required, so that the ADs can make decisions about where that work should take place.=C2=A0
  • We got some suggestions about technologies that could be used in LOOPS at the BOF. That will be a great starting point.=C2=A0
  • Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D
I told Magnus I was willing to work with the LOOPS community as you move forward toward a charter.=C2=A0

Make good choices!

Spencer




On Wed, Jul 24, 2019 at 11:24 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Magnus,=C2=A0

Ole and I wanted to let you know what things looked like to us as co-chairs.=C2=A0

We are copying the mailing list, to provide transparency for the LOOPS community. Wes Hardaker suggested that we copy the IAB because at least two IAB folk were covering the BOF, and would be sending write-ups to the IAB and IESG afterwards.=C2=A0

(Dear LOOPists - you may wish to remove the IAB from any follow-up e-mail on the mailing list. Interested IAB members are subscribed to LOOPS, or will be very soon. Uninterested IAB members don't need more e-mail from us!)

First, I'd like to thank you (and Suresh) for bringing in an INT co-chair. That was extremely helpful.=C2=A0

Draft minutes have been posted at=C2=A0https://datatracker.ietf= .org/doc/minutes-105-loops/. But, to summarize ...=C2=A0

We asked these questions at the beginning of the BOF:

Chairs: What sort of people were in the room?
  • 1/3 transport people
  • 1/3 encaps people
  • 1/10 apps people
  • 2 ops people
  • 5 measurements people
  • 1.5 security people
  • 10-12 people on products/systems they do some form of enhancement.
  • Who has read the problem draft? =C2=A01/3 room
We think that holding a BOF was a good decision, based on the number of people (even in the room) working on products and systems in this space.=C2=A0

We think that holding a non-working group-forming BOF was a good decision, because many of the people who have been working in this space haven't been talking to each other (which makes products that don't interoperate or provide the same services in the same way - same as our previous experience with NATs). Providing a place for them to talk was very helpful..

Ole was impressed at the low number of tourists in the room.=C2=A0

The key points from the BOF proponents were
  • First, do no harm - measure what you're doing, and adjust what you're doing based on feedback, including turning your optimizations off entirely.
  • Do local repair between LOOPS endpoints, not involving hosts (at least, not now)
  • Multipath; Measurement; MTU-handling; Encapsulation/Tunnels were out of scope (at least for now)
  • Use FEC for local repair
  • Do The Right Thing in tuning FEC usage based on feedback
  • In some cases, use limited retransmission for local repair, probably if FEC is not sufficient
The key points from discussion were
  • Marie-Jose Montpetit, co-chair of Network Coding Research Group, said that they have much research that is applicable for FEC. Marie-Jose has followed up on the mailing list after the BOF.
  • It's not clear how much vendors in this space want a standardized solution, but it's more likely that operators will want that=C2=A0
  • Multiple people have concerns about masking signals about actual losses and adverse interactions between multiple levels of optimizations. These are things to watch out for in future work
Hums at the end of the session were=C2=A0
  • There are multiple problems involved here, so a key next step will be teasing those problems apart and identifying what the IETF (and IRTF) has already done, that is applicable, and could be reused with no changes, or extended/modified as part of LOOPS, and what problems still remain unaddressed and clearly require protocol work in the IETF
  • Colin Perkins said there were big parts of the LOOPS problem set that are engineering now (Spencer and Ole happen to agree)
  • Andrew McGregor said that LOOPS would benefit from additional research (Spencer and Ole happen to agree, but think there is enough engineering work that waiting for more research to charter work isn't necessary)
  • Magnus asked if standardization in this space would be useful or beneficial. Many hums YES, some hums NO.=C2=A0
We will send our recommendations on how to follow up to the LOOPS mailing list separately, so that the discussion happens in the right place. If IESG and IAB people have opinions about that, subscribing would be good :-)=C2=A0

We can imagine that work in this space would result in standards-conformant products, but we can also imagine that work in this space would result in significantly improved proprietary products, or standards-conformant products with significant extensions. A lot depends on the people doing the work.=C2=A0

Thanks for the opportunity to serve the community in this way.

Spencer and Ole, as co-chairs for the BOF
-- =20
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--0000000000009dfe1f058e82dc2d-- From nobody Thu Jul 25 11:59:54 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEB51201C9 for ; Thu, 25 Jul 2019 11:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ImOn-T6pYSM for ; Thu, 25 Jul 2019 11:59:38 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 CA6531201B3 for ; Thu, 25 Jul 2019 11:59:37 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id q26so35322279lfc.3 for ; Thu, 25 Jul 2019 11:59:37 -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=EtpY0ZSR2WxDCgxFTUAz122BwJGtwVszrFKpIbTK9/Y=; b=KiNCFs8S4k1VN523epad0DBmxJN3Us4B6bQbXR5mzXq3e3RTKnt0XRAW4ICzR0z/vC Gd8wwAi8Bav/DR+dKtt6oE4bp+fjquF+Obw8dG+6XRN+7/aaeK8hH8gkj+8kbG74IQax 7UuTmVEy9xMtBQ0QeFWjwmX3qhuUMJkNqMz8GFiM6cVilI+XHRZIV5i848iQZYahQ1Cp xp7D/Lw2iF+Nx9JNBSPeLx5m1728EpvIKyy5nSSwT0HZ+2yziswzgVcnNUnD9HFZQ/0k 5cH2ZBI0Rk9511x0NEcYNtxuG7O9kSCt1xOrCIthuOnP1F/LGsApO+FBL9Mh/NJb2GuW wQsw== 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=EtpY0ZSR2WxDCgxFTUAz122BwJGtwVszrFKpIbTK9/Y=; b=atMbNZYO2TBEcrgkTz5ef8M92dbErUfBmqINuhygIVx+LBcQ1hzDv0d2adxI2NkpZC /dz5dgZJusX1YDGOtYsviMcRA7OKDWZjpXoWH51EFvQ8S+i1lHeuDnGjxM6Q6qe4L2MX r+shJLiYWbZ2XREXKWwdCDme0KAtscefCfad5r4uysyGmaNlUx7ZLjNyko24YI+ofy8I MvNb+x+rJC02prx5/hVnq8bPeJw3OV8Fc2BmZ0X6inJvTKiJLAyjGrkS0+4AJFMC/6GH m9h8WrP3srZJz6nqC2quO0h4fVWrsvy3SWZ7uvaEySWmxXBvmy5iqkzR01/GpPR4htnn k3oQ== X-Gm-Message-State: APjAAAVSI9kaI8LFWHYGML5w4did+Fwa9zR8gF8RbFIHWqatdiDS1snp 4DfPVNMdaG+X2XMZisvLlIld05Qt2uuJ/obWdZg= X-Google-Smtp-Source: APXvYqw/7ypIlD6iqTSwjAAMyHuJw+IntI2nfPzbiQqFaXyqt/xADq+MI/74bg6GAYZIEPtbtFyYYcWLj+xXFs48YkM= X-Received: by 2002:a19:f806:: with SMTP id a6mr28856900lff.102.1564081175842; Thu, 25 Jul 2019 11:59:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 25 Jul 2019 14:59:10 -0400 Message-ID: To: Carsten Bormann Cc: Marie-Jose Montpetit , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="000000000000e2d3df058e860618" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 18:59:52 -0000 --000000000000e2d3df058e860618 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Still wearing no hats, because I no longer have any dots ... On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann wrote: > On Jul 24, 2019, at 18:17, Marie-Jose Montpetit > wrote: > > > > Standardisation of what? The architecture? The protocols (beware there > is already FECFRAME and others)? The proxies? > > Hi Marie-Jos=C3=A9, > > details of the thinking that was developed in the side meetings that > happened at the previous two IETF meetings can be found at > > https://github.com/loops-wg/charter > > The BOF actually added one piece of information I didn=E2=80=99t previous= ly > perceive that way: > People seem to really want to tackle the host-to-node case (as needed, > e.g., for going through WiFi access clouds) right away, not just the > in-network (node-to-node) case. That would be the one thing I would chan= ge > based on my recollection of the BOF. But of course there may be other > things; it may be worth to now have another round of discussion of the > proposed charter. > Communication is good, but one thing I mentioned in my summary of my chat with the ADs was - Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D So, it's reasonable for the LOOPS community to consider adding host-to-node, but it's worth checking whether this would expand the scope of the requested charter, and whether excluding host-to-node makes the initial work easier to complete. My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) Best wishes, Spencer --000000000000e2d3df058e860618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Still wearing no hats, because I no longer have any d= ots ...

On Thu, Jul 25, 2019 at 12:56 AM Carsten B= ormann <cabo@tzi.org> wrote:
<= /div>
On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <marie@mjmontpetit.com> wr= ote:
>
> Standardisation of what? The architecture? The protocols (beware there= is already FECFRAME and others)? The proxies?

Hi Marie-Jos=C3=A9,

details of the thinking that was developed in the side meetings that happen= ed at the previous two IETF meetings can be found at

https://github.com/loops-wg/charter

The BOF actually added one piece of information I didn=E2=80=99t previously= perceive that way:
People seem to really want to tackle the host-to-node case (as needed, e.g.= , for going through WiFi access clouds) right away, not just the in-network= (node-to-node) case.=C2=A0 That would be the one thing I would change base= d on my recollection of the BOF.=C2=A0 But of course there may be other thi= ngs; it may be worth to now have another round of discussion of the propose= d charter.

Communication is good, but o= ne thing I mentioned in my summary of my chat with the ADs was
  • Here's a hint from the ADs - if the proponents can come up with a= clear charter, limited in scope, that will make their lives easier, and ma= ke it easier for them to charter this work :D=C2=A0
    • So, it= 9;s reasonable for the LOOPS community to consider adding host-to-node, but= it's worth checking whether this would expand the scope of the request= ed charter, and whether excluding host-to-node makes the initial work easie= r to complete.=C2=A0

    My impression, and Magn= us might say I'm insane, was that Magnus is right on the edge of whethe= r this work can be chartered without a second, working group-forming BOF. I= f the LOOPS community can't live without host-to-node, the community sh= ould add it. If the community can make use of LOOPS without host-to-node an= d add it later, the community might consider whether that reduces the scope= of the initial proposed charter enough to help Magnus approve it :-)=C2=A0=

    Best wishes,=C2=A0

    Spenc= er
    --000000000000e2d3df058e860618-- From nobody Thu Jul 25 12:10:44 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69321201B0 for ; Thu, 25 Jul 2019 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uLrXRu-JqUbA for ; Thu, 25 Jul 2019 12:10:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B018A1201A0 for ; Thu, 25 Jul 2019 12:10:40 -0700 (PDT) Received: from dhcp-80d9.meeting.ietf.org (dhcp-80d9.meeting.ietf.org [31.133.128.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45vhcs38Ftz1096; Thu, 25 Jul 2019 21:10:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 25 Jul 2019 15:10:34 -0400 Cc: Marie-Jose Montpetit , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Suresh Krishnan X-Mao-Original-Outgoing-Id: 585774632.598539-70d365e0ba5733283864bb0664b80b71 Content-Transfer-Encoding: quoted-printable Message-Id: <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org> References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:10:43 -0000 On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF = wrote: >=20 > [=E2=80=A6] If the LOOPS community can=E2=80=99t live without = host-to-node, the community should add it. If the community can make use = of LOOPS without host-to-node and add it later, the community might = consider whether that reduces the scope of the initial proposed charter = enough to help Magnus approve it :-)=20 Right. One other place where we can structure the milestones further is = by starting with retransmission mode only and add FEC mode in a second = step. So this would give us a nice and small first deliverable (retransmission = mode for node-to-node) that we can then recharter from. If we do this = right, this doesn=E2=80=99t even need to increase the time up to when we = deliver the whole protocol including both host-to-node and FEC. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 25 12:13:34 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508531201A0 for ; Thu, 25 Jul 2019 12:13:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1hAZCl_2jPt for ; Thu, 25 Jul 2019 12:13:30 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 B09141201C5 for ; Thu, 25 Jul 2019 12:13:30 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id h6so13021844iom.7 for ; Thu, 25 Jul 2019 12:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=gnRtr6ZSX8hTCxFxStqTw892EbNTRunDsno7OaypUwU=; b=Sfe/9hPIRyMvoKpGwlL7cDX6OZSVabh2xyY5fo9AlmBEdoF1OLji4AZGPys2OCOt7X bOxGzcR+yN8eBRMXVF6a1grxl4CnmM5tk4CUPQRqEu9ufAJX5C5ptaz2RSgBlGH3FFkj ltR4ovHA6nOmQ7Ras8lurdF8P0njHCRJxvoTugPRY2WJVAafH2BJ6b6hmmv04jDyWBfq PcpgVsKlZavzb6daBy9gLfkIQ+jmfo+6KFgxprICywciMTUi+mTp6I27+g69NcFUZRto gAuWe09rKw6XWJjY5BzY7DkRRjrGzlfQvB+8qLaSLlebKbGExCgE25Afj5w3ivCsfVf8 kTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=gnRtr6ZSX8hTCxFxStqTw892EbNTRunDsno7OaypUwU=; b=lGxh8NzirmXz5Sx80/w6jQsFhb5kfrNSJBXGPxHjFy3+fqL21Tgn0ox1lfyrSx84ET rCfPAocuiVGdGss8xz8HXeMAqMxNXMuET/QtfKGMqCWPHaWloX5fndalFiQxpvbJMK7p Vj2adWQpX/w9FF/q0c0sAQ5tYuilAF5J6H1BUFTsmtaKnl8YLNI/a/J8/CbJIGP59ssc ucoZHyoA6Vgv45HFWPYhgeZoUn7v2iU8pzJMoLA9aPqRl3QwuLdoEAy7q+huBQX588RE ZT/ept625VfKr84HaBZosshFa7oPN//JG61WcovvOeRgEN1pkRZ4Gf5n0xWi9P6lkyrr UcXg== X-Gm-Message-State: APjAAAVEP+/0+OyKnc3LHJgZcCAaVVQAD4htTMPwaL6pp7RdwUKxPy27 deRP/0fbec+qtacD+gDHm+jkOpTsEAPP/2HsqDU= X-Google-Smtp-Source: APXvYqysci1MALZ2Ebj9YVzExnOXdAeGbwlN3bKuslE3VOAPiJkbcx+LfJxb7+YpS9DSaeMh20zTWFK8jIMaKIT9D/s= X-Received: by 2002:a6b:3b03:: with SMTP id i3mr83459760ioa.302.1564082009958; Thu, 25 Jul 2019 12:13:29 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jul 2019 12:13:29 -0700 From: Marie-Jose Montpetit In-Reply-To: <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org> References: <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org> MIME-Version: 1.0 Date: Thu, 25 Jul 2019 12:13:29 -0700 Message-ID: To: Spencer Dawkins at IETF , Carsten Bormann Cc: Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a8298058e8638c4" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:13:33 -0000 --0000000000009a8298058e8638c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Which begs the question if the retransmission delay will kill the application. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 25, 2019 at 3:10:39 PM, Carsten Bormann (cabo@tzi.org) wrote: On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > [=E2=80=A6] If the LOOPS community can=E2=80=99t live without host-to-nod= e, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) Right. One other place where we can structure the milestones further is by starting with retransmission mode only and add FEC mode in a second step. So this would give us a nice and small first deliverable (retransmission mode for node-to-node) that we can then recharter from. If we do this right, this doesn=E2=80=99t even need to increase the time up to when we de= liver the whole protocol including both host-to-node and FEC. Gr=C3=BC=C3=9Fe, Carsten --0000000000009a8298058e8638c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    Whic= h begs the question if the retransmission delay will kill the application.<= /div>

    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Research Af= filiate, MIT Media Laboratory

    O= n July 25, 2019 at 3:10:39 PM, Carsten Bormann (cabo@tzi.org) wrote:

    On Jul 25, 2019, at 14:59, Spencer Dawkins a= t IETF <spencerdawkins.= ietf@gmail.com> wrote:
    > =20
    > [=E2=80=A6] If the LOOPS community can=E2=80=99t live without host= -to-node, the community should add it. If the community can make use of LOO= PS without host-to-node and add it later, the community might consider whet= her that reduces the scope of the initial proposed charter enough to help M= agnus approve it :-) =20

    Right. One other place where we can structure the milestones further i= s by starting with retransmission mode only and add FEC mode in a second st= ep.

    So this would give us a nice and small first deliverable (retransmissio= n mode for node-to-node) that we can then recharter from. If we do this ri= ght, this doesn=E2=80=99t even need to increase the time up to when we deli= ver the whole protocol including both host-to-node and FEC.

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

    --0000000000009a8298058e8638c4-- From nobody Thu Jul 25 12:28:04 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63C41201A0 for ; Thu, 25 Jul 2019 12:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peXbJV8TS9k0 for ; Thu, 25 Jul 2019 12:28:01 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 E54C912019F for ; Thu, 25 Jul 2019 12:28:00 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hqjP5-0002qo-37; Thu, 25 Jul 2019 21:27:51 +0200 Received: from dhcp-8190.meeting.ietf.org ([31.133.129.144]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hqjP3-00094W-KD; Thu, 25 Jul 2019 21:27:50 +0200 From: Michael Welzl Message-Id: <7EC8FC19-F116-44F0-B03F-4351D1A0EC9C@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_4A0991B4-A492-407E-9598-BA76A8252C09" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 25 Jul 2019 15:27:45 -0400 In-Reply-To: Cc: Spencer Dawkins , Carsten Bormann , Magnus Westerlund , Mirja Kuehlewind , Suresh Krishnan , loops@ietf.org To: Marie-Jose Montpetit References: <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 31.133.129.144 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.129.144; envelope-from=michawe@ifi.uio.no; helo=dhcp-8190.meeting.ietf.org; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7232EED145DDBCBAEAAF9F502815AF431C70F291 Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:28:04 -0000 --Apple-Mail=_4A0991B4-A492-407E-9598-BA76A8252C09 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not if the egress doesn't re-sequence. Then the worst thing that can happen (except for congestion in the LOOPS = segment itself, which the LOOPS nodes should avoid) is that the = retransmission doesn=E2=80=99t help. It does help, though: - for reasonably re-ordering robust TCP implementations (I=E2=80=99m not = even talking about RACK: spurious loss recovery mechanisms such as F-RTO = are also widely deployed) - for, e.g., UDP-based applications that might not care about = re-ordering (I=E2=80=99m not an expert enough on RTP to know how many = RTP applications could handle some degree of re-ordering too, but I = suspect it=E2=80=99s a fair amount) - for application-limited scenarios where a new packet might not even = appear in time to create re-ordering; the last data packet of a TCP = connection (tail loss) is such a case. So I=E2=80=99m an advocate of =E2=80=9Cnever create extra delay=E2=80=9D. = Delay is bad, and it=E2=80=99s hard to know what =E2=80=9Cjust the right = amount=E2=80=9D of extra delay is (it depends on too many factors IMO). Cheers, Michael > On Jul 25, 2019, at 3:13 PM, Marie-Jose Montpetit = wrote: >=20 > Which begs the question if the retransmission delay will kill the = application. >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > On July 25, 2019 at 3:10:39 PM, Carsten Bormann (cabo@tzi.org = ) wrote: >=20 >> On Jul 25, 2019, at 14:59, Spencer Dawkins at IETF = > = wrote:=20 >> > =20 >> > [=E2=80=A6] If the LOOPS community can=E2=80=99t live without = host-to-node, the community should add it. If the community can make use = of LOOPS without host-to-node and add it later, the community might = consider whether that reduces the scope of the initial proposed charter = enough to help Magnus approve it :-) =20 >>=20 >> Right. One other place where we can structure the milestones further = is by starting with retransmission mode only and add FEC mode in a = second step.=20 >>=20 >> So this would give us a nice and small first deliverable = (retransmission mode for node-to-node) that we can then recharter from. = If we do this right, this doesn=E2=80=99t even need to increase the time = up to when we deliver the whole protocol including both host-to-node and = FEC.=20 >>=20 >> Gr=C3=BC=C3=9Fe, Carsten=20 >>=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops --Apple-Mail=_4A0991B4-A492-407E-9598-BA76A8252C09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Not = if the egress doesn't re-sequence.

    Then the worst thing that can happen = (except for congestion in the LOOPS segment itself, which the LOOPS = nodes should avoid) is that the retransmission doesn=E2=80=99t = help.
    It does help, though:
    - = for reasonably re-ordering robust TCP implementations (I=E2=80=99m not = even talking about RACK: spurious loss recovery mechanisms such as F-RTO = are also widely deployed)
    - for, e.g., UDP-based = applications that might not care about re-ordering  (I=E2=80=99m = not an expert enough on RTP to know how many RTP applications could = handle some degree of re-ordering too, but I suspect it=E2=80=99s a fair = amount)
    - for application-limited scenarios where a new packet = might not even appear in time to create re-ordering; the last data = packet of a TCP connection (tail loss) is such a case.

    So I=E2=80=99m an advocate of =E2=80=9Cnever = create extra delay=E2=80=9D. Delay is bad, and it=E2=80=99s hard to know = what =E2=80=9Cjust the right amount=E2=80=9D of extra delay is (it = depends on too many factors IMO).

    Cheers,
    Michael


    On Jul 25, 2019, at 3:13 PM, Marie-Jose = Montpetit <marie@mjmontpetit.com> wrote:

    Which begs the question if the retransmission delay = will kill the application.

    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Research = Affiliate, MIT Media Laboratory
    mariejose@mjmontpetit.com
    mariejo@mit.edu

    On July 25, 2019 at 3:10:39 PM, Carsten Bormann = (cabo@tzi.org) = wrote:

    On Jul 25, 2019, at 14:59, Spencer = Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote: 
    >  
    > [=E2=80=A6= ] If the LOOPS community can=E2=80=99t live without host-to-node, the = community should add it. If the community can make use of LOOPS without = host-to-node and add it later, the community might consider whether that = reduces the scope of the initial proposed charter enough to help Magnus = approve it :-)  

    Right. One other place where we can structure the milestones = further is by starting with retransmission mode only and add FEC mode in = a second step. 

    So this would give us a nice and small first = deliverable (retransmission mode for node-to-node) that we can then = recharter from. If we do this right, this doesn=E2=80=99t even need to = increase the time up to when we deliver the whole protocol including = both host-to-node and FEC. 

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

    -- 
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.org/mailman/listinfo/loops

    = --Apple-Mail=_4A0991B4-A492-407E-9598-BA76A8252C09-- From nobody Thu Jul 25 12:31:40 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740CA1201C6 for ; Thu, 25 Jul 2019 12:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 rhw1_WwxYotO for ; Thu, 25 Jul 2019 12:31:36 -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 C7BFA1201C5 for ; Thu, 25 Jul 2019 12:31:35 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3ABFA56DB3CD8B554E07; Thu, 25 Jul 2019 20:31:33 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 25 Jul 2019 20:31:32 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.207]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 03:31:28 +0800 From: Liyizhou To: Marie-Jose Montpetit , Spencer Dawkins at IETF , Carsten Bormann CC: Magnus Westerlund , Mirja Kuehlewind , Suresh Krishnan , loops Thread-Topic: [LOOPS] BOF co-chairs thinking on LOOPS next steps Thread-Index: AQHVQjQKypVGc4E2bk+lpeh9RRMAhKbZxi+AgAAKdACAAG+BgIAA620AgAADLwCAAADRgIAAiyEE Date: Thu, 25 Jul 2019 19:31:27 +0000 Message-ID: References: <5A453FDB-79D2-4E70-A384-AEDC82547FF8@tzi.org>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D408889639FC5E4FADB4E00A3E01FA8FC5F44C34nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:31:39 -0000 --_000_D408889639FC5E4FADB4E00A3E01FA8FC5F44C34nkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYXBwbGljYXRpb25zIGhhdmUgbm90IGJlZW4ga2lsbGVkIGJ5IGVuZCB0byBlbmQgcmV0cmFu c21pc3Npb24sIEkgYmVsaWV2ZSB0aGV5IGFyZSBvayB3aXRoIHNob3J0ZXIgcmV0cmFuc21pc3Np b25zLg0KQ2VydGFpbmx5IHdlIG5lZWQgdG8gZGVzaWduIGl0IGluIGEgcmlnaHQgd2F5LiBBbmQg aXQgaXMgcGFydCBvZiB0aGUgd29yayBMT09QUyBpcyB0cnlpbmcgdG8gZG8uDQoNCg0KUmdkcywN CllpemhvdQ0KDQrlj5Hku7bkurrvvJogTWFyaWUtSm9zZSBNb250cGV0aXQ8bWFyaWVAbWptb250 cGV0aXQuY29tPG1haWx0bzptYXJpZUBtam1vbnRwZXRpdC5jb20+Pg0K5pS25Lu25Lq677yaIFNw ZW5jZXIgRGF3a2lucyBhdCBJRVRGPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0 bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+O0NhcnN0ZW4gQm9ybWFubjxjYWJvQHR6 aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+DQrmioTpgIHvvJogTWFnbnVzIFdlc3Rlcmx1bmQ8 bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20+PjtNaXJqYSBLdWVobGV3aW5kPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRv OmlldGZAa3VlaGxld2luZC5uZXQ+PjtTdXJlc2ggS3Jpc2huYW48c3VyZXNoQGthbG9vbS5jb208 bWFpbHRvOnN1cmVzaEBrYWxvb20uY29tPj47bG9vcHM8bG9vcHNAaWV0Zi5vcmc8bWFpbHRvOmxv b3BzQGlldGYub3JnPj4NCuS4u+mimO+8miBSZTogW0xPT1BTXSBCT0YgY28tY2hhaXJzIHRoaW5r aW5nIG9uIExPT1BTIG5leHQgc3RlcHMNCuaXtumXtO+8miAyMDE5LTA3LTI1IDE1OjEzOjUzDQoN CldoaWNoIGJlZ3MgdGhlIHF1ZXN0aW9uIGlmIHRoZSByZXRyYW5zbWlzc2lvbiBkZWxheSB3aWxs IGtpbGwgdGhlIGFwcGxpY2F0aW9uLg0KDQptam0NCg0KTWFyaWUtSm9zw6kgTW9udHBldGl0LCBQ aC5ELg0KUmVzZWFyY2ggQWZmaWxpYXRlLCBNSVQgTWVkaWEgTGFib3JhdG9yeQ0KbWFyaWVqb3Nl QG1qbW9udHBldGl0LmNvbTxtYWlsdG86bWFyaWVqb3NlQG1qbW9udHBldGl0LmNvbT4NCm1hcmll am9AbWl0LmVkdTxtYWlsdG86bWFyaWVqb0BtaXQuZWR1Pg0KDQoNCk9uIEp1bHkgMjUsIDIwMTkg YXQgMzoxMDozOSBQTSwgQ2Fyc3RlbiBCb3JtYW5uIChjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9A dHppLm9yZz4pIHdyb3RlOg0KDQpPbiBKdWwgMjUsIDIwMTksIGF0IDE0OjU5LCBTcGVuY2VyIERh d2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IFvigKZdIElmIHRoZSBMT09Q UyBjb21tdW5pdHkgY2Fu4oCZdCBsaXZlIHdpdGhvdXQgaG9zdC10by1ub2RlLCB0aGUgY29tbXVu aXR5IHNob3VsZCBhZGQgaXQuIElmIHRoZSBjb21tdW5pdHkgY2FuIG1ha2UgdXNlIG9mIExPT1BT IHdpdGhvdXQgaG9zdC10by1ub2RlIGFuZCBhZGQgaXQgbGF0ZXIsIHRoZSBjb21tdW5pdHkgbWln aHQgY29uc2lkZXIgd2hldGhlciB0aGF0IHJlZHVjZXMgdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFs IHByb3Bvc2VkIGNoYXJ0ZXIgZW5vdWdoIHRvIGhlbHAgTWFnbnVzIGFwcHJvdmUgaXQgOi0pDQoN ClJpZ2h0LiBPbmUgb3RoZXIgcGxhY2Ugd2hlcmUgd2UgY2FuIHN0cnVjdHVyZSB0aGUgbWlsZXN0 b25lcyBmdXJ0aGVyIGlzIGJ5IHN0YXJ0aW5nIHdpdGggcmV0cmFuc21pc3Npb24gbW9kZSBvbmx5 IGFuZCBhZGQgRkVDIG1vZGUgaW4gYSBzZWNvbmQgc3RlcC4NCg0KU28gdGhpcyB3b3VsZCBnaXZl IHVzIGEgbmljZSBhbmQgc21hbGwgZmlyc3QgZGVsaXZlcmFibGUgKHJldHJhbnNtaXNzaW9uIG1v ZGUgZm9yIG5vZGUtdG8tbm9kZSkgdGhhdCB3ZSBjYW4gdGhlbiByZWNoYXJ0ZXIgZnJvbS4gSWYg d2UgZG8gdGhpcyByaWdodCwgdGhpcyBkb2VzbuKAmXQgZXZlbiBuZWVkIHRvIGluY3JlYXNlIHRo ZSB0aW1lIHVwIHRvIHdoZW4gd2UgZGVsaXZlciB0aGUgd2hvbGUgcHJvdG9jb2wgaW5jbHVkaW5n IGJvdGggaG9zdC10by1ub2RlIGFuZCBGRUMuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0K --_000_D408889639FC5E4FADB4E00A3E01FA8FC5F44C34nkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCmJvZHkNCgl7Zm9udC1m YW1pbHk6SGVsdmV0aWNhLEFyaWFsOw0KCWZvbnQtc2l6ZToxMnB4fQ0KLS0+DQo8L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEhlbHZldGlj YSFpbXBvcnRhbnQiPkFzIGFwcGxpY2F0aW9ucyBoYXZlIG5vdCBiZWVuIGtpbGxlZCBieSBlbmQg dG8gZW5kIHJldHJhbnNtaXNzaW9uLCBJIGJlbGlldmUgdGhleSBhcmUgb2sgd2l0aCBzaG9ydGVy IHJldHJhbnNtaXNzaW9ucy4NCjxicj4NCkNlcnRhaW5seSB3ZSBuZWVkIHRvIGRlc2lnbiBpdCBp biBhIHJpZ2h0IHdheS4gQW5kIGl0IGlzIHBhcnQgb2YgdGhlIHdvcmsgTE9PUFMgaXMgdHJ5aW5n IHRvIGRvLjxicj4NCjxicj4NCjxicj4NClJnZHMsPGJyPg0KWWl6aG91PGJyPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IG5hbWU9IkFueU9mZmljZS1CYWNrZ3JvdW5kLUltYWdlIiBzdHlsZT0iYm9yZGVy LXRvcDoxcHggc29saWQgI0I1QzRERjsgcGFkZGluZzo4cHgiPg0KPGRpdj48Yj7lj5Hku7bkurrv vJogPC9iPk1hcmllLUpvc2UgTW9udHBldGl0Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJpZUBtam1v bnRwZXRpdC5jb20iPm1hcmllQG1qbW9udHBldGl0LmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2Pjxi PuaUtuS7tuS6uu+8miA8L2I+U3BlbmNlciBEYXdraW5zIGF0IElFVEYmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7O0NhcnN0ZW4gQm9ybWFubiZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0 emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OzwvZGl2Pg0KPGRpdj48Yj7mioTpgIHvvJogPC9i Pk1hZ251cyBXZXN0ZXJsdW5kJmx0OzxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7O01pcmph IEt1ZWhsZXdpbmQmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiPmlldGZA a3VlaGxld2luZC5uZXQ8L2E+Jmd0OztTdXJlc2ggS3Jpc2huYW4mbHQ7PGEgaHJlZj0ibWFpbHRv OnN1cmVzaEBrYWxvb20uY29tIj5zdXJlc2hAa2Fsb29tLmNvbTwvYT4mZ3Q7O2xvb3BzJmx0Ozxh IGhyZWY9Im1haWx0bzpsb29wc0BpZXRmLm9yZyI+bG9vcHNAaWV0Zi5vcmc8L2E+Jmd0OzwvZGl2 Pg0KPGRpdj48Yj7kuLvpopjvvJogPC9iPlJlOiBbTE9PUFNdIEJPRiBjby1jaGFpcnMgdGhpbmtp bmcgb24gTE9PUFMgbmV4dCBzdGVwczwvZGl2Pg0KPGRpdj48Yj7ml7bpl7TvvJogPC9iPjIwMTkt MDctMjUgMTU6MTM6NTM8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbDsgZm9udC1zaXplOjEycHgiPldoaWNoIGJlZ3MgdGhl IHF1ZXN0aW9uIGlmIHRoZSByZXRyYW5zbWlzc2lvbiBkZWxheSB3aWxsIGtpbGwgdGhlIGFwcGxp Y2F0aW9uLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsOyBm b250LXNpemU6MTJweCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2 ZXRpY2EsQXJpYWw7IGZvbnQtc2l6ZToxMnB4Ij5tam08L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3NpZ25hdHVyZSI+TWFyaWUtSm9zw6kgTW9udHBldGl0LCBQaC5ELg0KPGRpdj5SZXNl YXJjaCBBZmZpbGlhdGUsIE1JVCBNZWRpYSBMYWJvcmF0b3J5PGJyPg0KPGRpdj48YSBocmVmPSJt YWlsdG86bWFyaWVqb3NlQG1qbW9udHBldGl0LmNvbSI+bWFyaWVqb3NlQG1qbW9udHBldGl0LmNv bTwvYT48L2Rpdj4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOm1hcmllam9AbWl0LmVkdSI+bWFyaWVq b0BtaXQuZWR1PC9hPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxwIGNsYXNzPSJhaXJt YWlsX29uIj5PbiBKdWx5IDI1LCAyMDE5IGF0IDM6MTA6MzkgUE0sIENhcnN0ZW4gQm9ybWFubiAo PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyI+Y2Fib0B0emkub3JnPC9hPikgd3JvdGU6PC9w Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9ImNsZWFuX2JxIj48c3Bhbj4NCjxkaXY+ DQo8ZGl2PjwvZGl2Pg0KPGRpdj5PbiBKdWwgMjUsIDIwMTksIGF0IDE0OjU5LCBTcGVuY2VyIERh d2tpbnMgYXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFvigKZdIElmIHRoZSBMT09QUyBjb21tdW5pdHkgY2Fu4oCZdCBs aXZlIHdpdGhvdXQgaG9zdC10by1ub2RlLCB0aGUgY29tbXVuaXR5IHNob3VsZCBhZGQgaXQuIElm IHRoZSBjb21tdW5pdHkgY2FuIG1ha2UgdXNlIG9mIExPT1BTIHdpdGhvdXQgaG9zdC10by1ub2Rl IGFuZCBhZGQgaXQgbGF0ZXIsIHRoZSBjb21tdW5pdHkgbWlnaHQgY29uc2lkZXIgd2hldGhlciB0 aGF0IHJlZHVjZXMgdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsIHByb3Bvc2VkIGNoYXJ0ZXINCiBl bm91Z2ggdG8gaGVscCBNYWdudXMgYXBwcm92ZSBpdCA6LSkgPGJyPg0KPGJyPg0KUmlnaHQuIE9u ZSBvdGhlciBwbGFjZSB3aGVyZSB3ZSBjYW4gc3RydWN0dXJlIHRoZSBtaWxlc3RvbmVzIGZ1cnRo ZXIgaXMgYnkgc3RhcnRpbmcgd2l0aCByZXRyYW5zbWlzc2lvbiBtb2RlIG9ubHkgYW5kIGFkZCBG RUMgbW9kZSBpbiBhIHNlY29uZCBzdGVwLg0KPGJyPg0KPGJyPg0KU28gdGhpcyB3b3VsZCBnaXZl IHVzIGEgbmljZSBhbmQgc21hbGwgZmlyc3QgZGVsaXZlcmFibGUgKHJldHJhbnNtaXNzaW9uIG1v ZGUgZm9yIG5vZGUtdG8tbm9kZSkgdGhhdCB3ZSBjYW4gdGhlbiByZWNoYXJ0ZXIgZnJvbS4gSWYg d2UgZG8gdGhpcyByaWdodCwgdGhpcyBkb2VzbuKAmXQgZXZlbiBuZWVkIHRvIGluY3JlYXNlIHRo ZSB0aW1lIHVwIHRvIHdoZW4gd2UgZGVsaXZlciB0aGUgd2hvbGUgcHJvdG9jb2wgaW5jbHVkaW5n IGJvdGggaG9zdC10by1ub2RlDQogYW5kIEZFQy4gPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3Rl biA8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D408889639FC5E4FADB4E00A3E01FA8FC5F44C34nkgeml513mbschi_-- From nobody Tue Jul 30 03:14:47 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2701203D5 for ; Tue, 30 Jul 2019 03:14:45 -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 0cBQU5wjeA0J for ; Tue, 30 Jul 2019 03:14:44 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 373411203DA for ; Tue, 30 Jul 2019 03:14:44 -0700 (PDT) Received: from 200116b82cf82f00096e5b7dce73fffb.dip.versatel-1u1.de ([2001:16b8:2cf8:2f00:96e:5b7d:ce73:fffb]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hsP9S-0005ql-Vg; Tue, 30 Jul 2019 12:14:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 30 Jul 2019 12:14:38 +0200 Cc: Carsten Bormann , loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2693E1C9-B778-48CD-9790-EEE70DAFDADF@kuehlewind.net> References: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> To: Spencer Dawkins at IETF , Michael Welzl X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564481684;bc3d3898; X-HE-SMSGID: 1hsP9S-0005ql-Vg Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 10:14:46 -0000 BRR is ignoring loss (up to some % of loss rate) while it will always = react to CE. > On 23. Jul 2019, at 16:45, Spencer Dawkins at IETF = wrote: >=20 > FWIW,=20 >=20 > On Mon, Jul 22, 2019 at 6:51 PM Michael Welzl = wrote: >=20 >=20 > > On Jul 22, 2019, at 6:17 PM, Carsten Bormann wrote: > >=20 > > Sorry for typing a message from a heated BOF where I was = representing a WG that needs a specific outcome=E2=80=A6 > >=20 > >>> Bob pointed out that some end host implementations today interpret = CE as definite congestion events, while applying congestion detection to = loss signals, so this conversion might be counterproductive. > >>=20 > >> The last sentence - I don't understand it (=E2=80=9Cinterpret CE as = definite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). = What does it mean? Or, maybe: what=E2=80=99s the issue here? > >=20 > > What I think Bob meant: An end-host noticing a loss might make its = own determination (a.k.a. congestion detection) whether that is a reason = to slow down or not. > > An end-host getting a CE might simply assume this is indeed = congestion, and always slow down. So, CE > loss, and a simple = replacement of loss by CE worsens throughput. >=20 > Ok, thanks! now I understand that the statement is indeed what I = thought, but it still makes zero sense to me. See below: >=20 >=20 > >> I thought the whole point is to signal CE *as a replacement* for = the loss that LOOPS repairs. So, then=E2=80=A6 ? > >=20 > > If CE > loss, replacing loss by CE is not enough, we need to vet the = losses via a LOOPS-side congestion detection that is as good as the one = as the end-host would do, or (preferably) better. >=20 > RFC 3168 says CE =3D loss. RFC 8311 finally allows us to diverge from = this rule, which we used in RFC to state: =E2=80=9CCE < loss=E2=80=9D. > L4S of course also does =E2=80=9CCE < loss=E2=80=9D, albeit in much = more elaborate ways. >=20 > However: "CE > loss=E2=80=9D is truly weird to me - perhaps this IS = now allowed by RFC 8311 :-D but if it=E2=80=99s spec=E2=80=99ed then = it must be an April 1 RFC. >=20 > What am I missing, Bob? >=20 > I was hoping CE > loss was a typo, myself. >=20 > Spencer > =20 >=20 > Cheers, > Michael >=20 > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops From nobody Tue Jul 30 03:34:44 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8121203E2 for ; Tue, 30 Jul 2019 03:34:42 -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 irHPmGyBSO5N for ; Tue, 30 Jul 2019 03:34:41 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 DDFA112012B for ; Tue, 30 Jul 2019 03:34:40 -0700 (PDT) Received: from 200116b82cf82f00096e5b7dce73fffb.dip.versatel-1u1.de ([2001:16b8:2cf8:2f00:96e:5b7d:ce73:fffb]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hsPSo-0004FV-9X; Tue, 30 Jul 2019 12:34:38 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 30 Jul 2019 12:34:37 +0200 Cc: Magnus Westerlund , loops@ietf.org, Suresh Krishnan Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Spencer Dawkins at IETF , Carsten Bormann X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564482880;5ae631dd; X-HE-SMSGID: 1hsPSo-0004FV-9X Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 10:34:42 -0000 Hi Carsten, hi Spencer, > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF = wrote: >=20 > My impression, and Magnus might say I'm insane, was that Magnus is = right on the edge of whether this work can be chartered without a = second, working group-forming BOF. If the LOOPS community can't live = without host-to-node, the community should add it. If the community can = make use of LOOPS without host-to-node and add it later, the community = might consider whether that reduces the scope of the initial proposed = charter enough to help Magnus approve it :-)=20 Yes, it would be possible to charter without another BoF a small and = well-scoped group, however, it also would be possible to work on small = and well-defined pieces of work without a new working group. This was = one of the reasons why this was not a non-wg-forming BoF because it is = not clear yet if a new group is needed or the resulting pieces of = standardization work are small enough to fit into an existing group.=20 Therefore, I really recommend focus on defining the standardising work = items that you think are needed rather than trying to do any = word-smithing of a potential charter (that eventually is not needed). Mirja From nobody Tue Jul 30 04:34:19 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C431203FA for ; Tue, 30 Jul 2019 04:34:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmLUrH5e3oSc for ; Tue, 30 Jul 2019 04:34:15 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A02D1200F1 for ; Tue, 30 Jul 2019 04:34:15 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id s7so127081231iob.11 for ; Tue, 30 Jul 2019 04:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=jp81MHFGPItKqCagfrYRYMDXF90S7VSFzFjWNigp+4s=; b=JZt1ryQrhIdVP5rN7RDeXITKYDQzHDwHQTu9gHDNPRJWHu7xBmyQdjSPR7ZYBuAPvr Dps0V32x09C4g1boufCqs6BpDm0q+h3IaSsACIQkwyg9R283vJ+I0tN0/qi0pBO/vRFR LRI0EEbnQ2nUkFhbGFRH6fbN3OgsazkbomvNlHNhmcwb1usevHjLkmGOJNqmbLNpFk5B aW6BOkbvgEf0D7TreKy47G6rqP3qyYc9T6KGm8+o18NsObYkRPpd0nQoTbLSpt/yVQwA 3liMtBoC0sshuCXPr7lPAe53L7XLXZu8qyEJQaQcB2pGS5PiE8tEwsiAdq6E5XETHKys kW3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=jp81MHFGPItKqCagfrYRYMDXF90S7VSFzFjWNigp+4s=; b=nYCzqIAvlWqLx0T7tl/m8nTl4wPZgG2cb5KJCjbeJ4yAjQMioyV/npBZRp5z9qKPqa r0EHivKVglvD5wXUDRzvzs1xVUy3ZfSqreccCDcXsyrsGwDAAhCjT2IBwJPUrBLfxR5J ALa6rSlolu+7EBoqH1jgVL6JUIXYlxHMwRQU44uKJ78PHvGYNlEC9p6QCkEfEdOBOCEK nZ5OqTuuKJvljJy2nzqtwWAlqwzp1ZClTyH1GPRoMBL9fypaR9/ISV6yYkv5op3A/vm2 aoKOB5en7vlKePC8TCgzwSRit02Fbt4QZZSVJeKXVFmZgljkcRhQzpONeFOt0RbkF5Il RyHA== X-Gm-Message-State: APjAAAXx2dAI03o4eNLQwRyWZd59p8EFQF1u5d71Ui2I7MASZZ/UFjRG GQyPuh3zomIY9DAWBf/2bSnYirYDxijgt+D1fH1JOw== X-Google-Smtp-Source: APXvYqxG5gjwE5rlsbhSH7k4l5NLnc2VTO5viRfU7mytzL5RsX6muk2u92mk9lGS0/l2ysjQY4ffqj2j1QaDJPO1lL8= X-Received: by 2002:a5d:948a:: with SMTP id v10mr78198192ioj.103.1564486454299; Tue, 30 Jul 2019 04:34:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jul 2019 04:34:13 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 30 Jul 2019 04:34:13 -0700 Message-ID: To: Spencer Dawkins at IETF , Mirja Kuehlewind , Carsten Bormann Cc: Magnus Westerlund , loops@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="0000000000005dfb8e058ee4635e" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 11:34:17 -0000 --0000000000005dfb8e058ee4635e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I fully agree with Mirja. There are pieces already being implemented in existing groups. Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 30, 2019 at 6:34:46 AM, Mirja Kuehlewind (ietf@kuehlewind.net) wrote: Hi Carsten, hi Spencer, > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) Yes, it would be possible to charter without another BoF a small and well-scoped group, however, it also would be possible to work on small and well-defined pieces of work without a new working group. This was one of the reasons why this was not a non-wg-forming BoF because it is not clear yet if a new group is needed or the resulting pieces of standardization work are small enough to fit into an existing group. Therefore, I really recommend focus on defining the standardising work items that you think are needed rather than trying to do any word-smithing of a potential charter (that eventually is not needed). Mirja --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --0000000000005dfb8e058ee4635e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    I fu= lly agree with Mirja. There are pieces already being implemented in existin= g groups.

    Marie-Jos=C3=A9 Montpet= it, Ph.D.
    Research Affiliate, MIT Media Laboratory
    mariejo@mit.edu

    =

    On July 30, 2019 at 6:34:46 AM, Mirja Kuehlewind (<= a href=3D"mailto:ietf@kuehlewind.net">ietf@kuehlewind.net) wrote:

    <= blockquote type=3D"cite" class=3D"clean_bq">
    Hi C= arsten, hi Spencer,

    > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= wrote:
    > =20
    > My impression, and Magnus might say I'm insane, was that Magnu= s is right on the edge of whether this work can be chartered without a seco= nd, working group-forming BOF. If the LOOPS community can't live withou= t host-to-node, the community should add it. If the community can make use = of LOOPS without host-to-node and add it later, the community might conside= r whether that reduces the scope of the initial proposed charter enough to = help Magnus approve it :-) =20

    Yes, it would be possible to charter without another BoF a small and we= ll-scoped group, however, it also would be possible to work on small and we= ll-defined pieces of work without a new working group. This was one of the = reasons why this was not a non-wg-forming BoF because it is not clear yet i= f a new group is needed or the resulting pieces of standardization work are= small enough to fit into an existing group. =20

    Therefore, I really recommend focus on defining the standardising work = items that you think are needed rather than trying to do any word-smithing = of a potential charter (that eventually is not needed).

    Mirja



    -- =20
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.iet= f.org/mailman/listinfo/loops
    --0000000000005dfb8e058ee4635e-- From nobody Tue Jul 30 07:23:00 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D97912019C for ; Tue, 30 Jul 2019 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avJUzfu-__-J for ; Tue, 30 Jul 2019 07:22:57 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 183AD120199 for ; Tue, 30 Jul 2019 07:22:57 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id x25so62350866ljh.2 for ; Tue, 30 Jul 2019 07:22: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=EQob+AR4LuFvcZpZpf5FvhIpZkr5X7rJMgiS9bYOmbA=; b=LUJzMQVJhITg0i44e0+bq0Hl5g72tCGtuzDfy6BU7P5joQzRUeZVhgaad23y2/U51n TV4fs6beHtf7YufNnca5pk4FR/wvs0n3YN8hoM+PitvOtVVr3AwoAoZoaTei1c2ZZmOh dJxmx1mYtvkovna1viYiZq/Of2fbwRzXL5X4DBS+t7KbGgqWDrSOIX/+V55z61DFH9GY Ji/9ALJDV6UCAR+g9I5cp/adzIOhZU8EqqjDMc31IwUrW7EpVBRNHxQtS1dSYRsMNJIi 5RdlxIZRdGIreaDlha1Z+Mid/8xMRqvtvsrvLTIHOXl74rGt8/tbgNJisYmUneVBUQL/ EMKA== 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=EQob+AR4LuFvcZpZpf5FvhIpZkr5X7rJMgiS9bYOmbA=; b=ShfDGhEQ4LA7ID+46WOmHyHDAUeMiEisj2Mls7lFuBGPYaSaoktJFkd/SiLtOXetLc BDTxTNL6IdoQAyK6zx+MkrGPOoBzlGhMRwFWJAGrTcnFUvYQatuQh75Ez4Zj1pKeTT88 20PORU9Qg4OPM0UISnqpAdUjwQmq5Fev2JgglUMKYqB+i5LMexS9WYr8A1666cVLUR+q O+aSWgma1YcT9gnYKDHARiu8Yt/aVE1Yz8+0U1shpLlYGrhxHQfO304BNf4yByQVSTHi 8t934zpJQnGOr6mmkBTT2eEGbqoICXhQeCKNafu9RUT5d/hwj4zEvhOZAFGbSKC4PuBN OoQQ== X-Gm-Message-State: APjAAAVFRjgJp7baufjxR30BAsJpoMXWQhDe+zCmxbQoz7CTWqiXEQOJ GTfa1h0JBIzSEZnmZWhC58qdNiDhCi+r5kXl68I= X-Google-Smtp-Source: APXvYqyLXcRn2hcaMDz2KS8XG0lr7BvjhODsDsEWQc6Gk0d/kpCgPtePC3A/zOXKUk7LK42OtX5q9CreJNl0lTqU4J0= X-Received: by 2002:a2e:8741:: with SMTP id q1mr8726496ljj.144.1564496574354; Tue, 30 Jul 2019 07:22:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 30 Jul 2019 09:22:26 -0500 Message-ID: To: Mirja Kuehlewind Cc: Carsten Bormann , Magnus Westerlund , loops@ietf.org, Suresh Krishnan Content-Type: multipart/alternative; boundary="00000000000091185a058ee6be3b" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 14:23:00 -0000 --00000000000091185a058ee6be3b Content-Type: text/plain; charset="UTF-8" Hi, Mirja, On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind wrote: > Hi Carsten, hi Spencer, > > > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > My impression, and Magnus might say I'm insane, was that Magnus is right > on the edge of whether this work can be chartered without a second, working > group-forming BOF. If the LOOPS community can't live without host-to-node, > the community should add it. If the community can make use of LOOPS without > host-to-node and add it later, the community might consider whether that > reduces the scope of the initial proposed charter enough to help Magnus > approve it :-) > > Yes, it would be possible to charter without another BoF a small and > well-scoped group, however, it also would be possible to work on small and > well-defined pieces of work without a new working group. This was one of > the reasons why this was not a non-wg-forming BoF because it is not clear > yet if a new group is needed or the resulting pieces of standardization > work are small enough to fit into an existing group. > > Therefore, I really recommend focus on defining the standardising work > items that you think are needed rather than trying to do any word-smithing > of a potential charter (that eventually is not needed). > Thanks for giving me the chance to clarify - I really was talking about chartering work, not just chartering a working group, but that wasn't clear from my note. As you said, knowing what the work is, in more detail, will help you and Magnus know what to do next. So, my suggestion for the interested community is to nail down 1. In order to "do LOOPS", what already exists, that can be used without changes? 2. what already exists, but needs to be extended for LOOPS? 3. what needs to be created, because nothing exists that meets the needs? I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a month before IETF 105), but speaking as someone who hasn't been involved in depth, I wonder about 1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there? 2. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically? 3. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")? Does everyone know how to do those three things, except me? :-) Pointers to specifications would be awesome ... Spencer > Mirja > > > > --00000000000091185a058ee6be3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Mirja,=C2=A0

    On Tue, Jul 30, 2019 at 5= :34 AM Mirja Kuehlewind <ietf@kue= hlewind.net> wrote:
    Hi Carsten, hi Spencer,

    > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
    >
    > My impression, and Magnus might say I'm insane, was that Magnus is= right on the edge of whether this work can be chartered without a second, = working group-forming BOF. If the LOOPS community can't live without ho= st-to-node, the community should add it. If the community can make use of L= OOPS without host-to-node and add it later, the community might consider wh= ether that reduces the scope of the initial proposed charter enough to help= Magnus approve it :-)

    Yes, it would be possible to charter without another BoF a small and well-s= coped group, however, it also would be possible to work on small and well-d= efined pieces of work without a new working group. This was one of the reas= ons why this was not a non-wg-forming BoF because it is not clear yet if a = new group is needed or the resulting pieces of standardization work are sma= ll enough to fit into an existing group.

    Therefore, I really recommend focus on defining the standardising work item= s that you think are needed rather than trying to do any word-smithing of a= potential charter (that eventually is not needed).
    Thanks for giving me the chance to clarify - I really was talk= ing about chartering work, not just chartering a working group, but that wa= sn't clear from my note. As you said, knowing what the work is, in more= detail, will help you and Magnus know what to do next.=C2=A0
    So, my suggestion for the interested community is to nail down<= /div>
    1. In order to "do LOOPS", what already exists, th= at can be used without changes?
    2. what already exists, but needs to b= e extended for LOOPS?
    3. what needs to be created, because nothing exi= sts that meets the needs?
    =C2=A0I'm not a LOOPS proponent (the= ADs asked me to chair the BOF about a month before IETF 105), but speaking= as someone who hasn't been involved in depth, I wonder about
    =
    1. How a sender tunes FEC dynamically - is that automatic, based = on FEC mechanisms people are thinking about, or is there work to do there?<= /li>
    2. How a sender knows whether to do FEC, retransmission, or both FEC a= nd retransmission, dynamically?
    3. How a sender knows that it shouldn&= #39;t be doing anything, because anything it does won't help ("fir= st, do no harm")?
    Does everyone know how to do those thr= ee things, except me? :-)=C2=A0

    Pointers to specif= ications would be awesome ...=C2=A0

    Spencer
    <= br>

    Mirja



    --00000000000091185a058ee6be3b-- From nobody Tue Jul 30 07:42:27 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB711200F8 for ; Tue, 30 Jul 2019 07:42:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D2yZLiTdzNU for ; Tue, 30 Jul 2019 07:42:16 -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 70BA31200F7 for ; Tue, 30 Jul 2019 07:42:16 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id g20so128591268ioc.12 for ; Tue, 30 Jul 2019 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3ADXQJgyPItC24gszKAQUw/uZ3nStvIDWWQq2bTOLrc=; b=l5cWXw8iH7jTPwgxY+xzIZU4aSm4KpZruTDNWkZkSkuPqpQDGQWlL2hQip6lawZO8X 5XtAGTgxLQBI1LXIN5FE39mN3UjmndorWV43SZ9tSvF5npP2PkwVz39Y1NidGZK8l9Ch txb0tSbg7HaAilpjjRBq1TBsVEFJdlIfpAafAbIcH94gVenJnkOzncexb4ICdITf6tuq /t4yeLbKQidBuxfgYsVkTWzbpq9zAY/HcYAldoi1ByvQh1B9eG/a+HjDZNtjlIMT8Zpx LhQk8QR/oiIxmp3QIC3cUHKBU2bqXWx6SU5dxwtkXn1zl9JM6nAquyBai2ClBJR9a94+ PSrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3ADXQJgyPItC24gszKAQUw/uZ3nStvIDWWQq2bTOLrc=; b=N+PuOVi6sicue5+6rn9wlPZZECvDIekZ/unG1vSn0C8rxGUVNaFxGj3MoNpYLRrfy8 WrKx/BfK9bP9nmc3GDZvFvMxjvg+UfrmlskLrT+/6aMsGtvDXzTmKzyA4KNx0QqCebmU 5HDL9w7/Y09zWMbue4WUPEq+6mGo0V5cAqZfmg3AO2QfR/WK0CPk4D+N6ctgxpv1vqKt b8zCuW8pyJQr/TWhT+DiXWNHWCJmEwgRnHU9r2GzNXcpl+ZP2Djm42IopMYJ99BK6/7b Vo3/Oag6RoPnBhYJTpdOwqywSvF9oQmvmeNGdDJt/e9Xhq4p1i4VeVXC7oanQD+uZiBC q7ZA== X-Gm-Message-State: APjAAAXklGHv8OaYwDKevx5uPiXv1V+tg78gx6Bgs5g0oZr2OngtmgHT ku+odT6xilFXWasxeQXQnrtsIK3waKI7CT79wkM= X-Google-Smtp-Source: APXvYqxjeW2INI3QqzOmcWRh9132Q+sjN3lSn6JLY58qfai/k4toU8pJLVSyus+3IJ1C77aWzQxMKK1dc2Wr3Q+7zIY= X-Received: by 2002:a5d:8c81:: with SMTP id g1mr42742015ion.239.1564497735650; Tue, 30 Jul 2019 07:42:15 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jul 2019 07:42:14 -0700 From: Marie-Jose Montpetit In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 30 Jul 2019 07:42:14 -0700 Message-ID: To: Spencer Dawkins at IETF , Mirja Kuehlewind , "nwcrg@irtf.org" Cc: Suresh Krishnan , Carsten Bormann , Magnus Westerlund , loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000c92aa5058ee70331" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 14:42:20 -0000 --000000000000c92aa5058ee70331 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since most of your questions are related to FEC I copy the nwcrg. See below mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: Hi, Mirja, On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind wrote: > Hi Carsten, hi Spencer, > > > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > My impression, and Magnus might say I'm insane, was that Magnus is righ= t > on the edge of whether this work can be chartered without a second, worki= ng > group-forming BOF. If the LOOPS community can't live without host-to-node= , > the community should add it. If the community can make use of LOOPS witho= ut > host-to-node and add it later, the community might consider whether that > reduces the scope of the initial proposed charter enough to help Magnus > approve it :-) > > Yes, it would be possible to charter without another BoF a small and > well-scoped group, however, it also would be possible to work on small an= d > well-defined pieces of work without a new working group. This was one of > the reasons why this was not a non-wg-forming BoF because it is not clear > yet if a new group is needed or the resulting pieces of standardization > work are small enough to fit into an existing group. > > Therefore, I really recommend focus on defining the standardising work > items that you think are needed rather than trying to do any word-smithin= g > of a potential charter (that eventually is not needed). > Thanks for giving me the chance to clarify - I really was talking about chartering work, not just chartering a working group, but that wasn't clear from my note. As you said, knowing what the work is, in more detail, will help you and Magnus know what to do next. So, my suggestion for the interested community is to nail down 1. In order to "do LOOPS", what already exists, that can be used without changes? 2. what already exists, but needs to be extended for LOOPS? 3. what needs to be created, because nothing exists that meets the needs= ? I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a month before IETF 105), but speaking as someone who hasn't been involved in depth, I wonder about 1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there? There are FEC mechanisms to adapt coding dynamically based on acknowledgments for example. In the QUICK implementation we will have flag a RECOVERED packet that could be used to adapt the coding rate. Other implementations or code-specific protocols are also available. 1. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically? Well the use of FEC (or not) is a design decision. Of course you need the code (and the libraries). And then the decision will be based on known link condition, goodput, expected performance, type of traffic (video, time sensitive etc.). And finding a tunnel and PEPs if you need to. And it can depend on path statistics and not being end to end. I am not sure you could standardize that decision. 1. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")? Of course in a congested network doing nothing is probably best. Again there is a lot of work on the interaction of coding and congestion control. Not everyone knows the things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work was done in a research group not a working group. But real implementations exist in famous =E2=80=9Cnetworks". Since most of your questions are about erasure coding (coding for packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG? mjm Does everyone know how to do those three things, except me? :-) Pointers to specifications would be awesome ... Spencer > Mirja > > > > -- LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000c92aa5058ee70331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    Sinc= e most of your questions are related to FEC I copy the nwcrg. See <mjm&g= t; below
    mjm
    =
    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Re= search Affiliate, MIT Media Laboratory

    On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com= ) wrote:

    Hi, = Mirja,=C2=A0

    On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
    Hi Carsten, hi Spencer,

    > On 25. Jul 2019, at 20:5= 9, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
    >=
    > My impression, and Magnus might say I'm insane, was that Magnu= s is right on the edge of whether this work can be chartered without a seco= nd, working group-forming BOF. If the LOOPS community can't live withou= t host-to-node, the community should add it. If the community can make use = of LOOPS without host-to-node and add it later, the community might conside= r whether that reduces the scope of the initial proposed charter enough to = help Magnus approve it :-)

    Yes, it would be possible to charter with= out another BoF a small and well-scoped group, however, it also would be po= ssible to work on small and well-defined pieces of work without a new worki= ng group. This was one of the reasons why this was not a non-wg-forming BoF= because it is not clear yet if a new group is needed or the resulting piec= es of standardization work are small enough to fit into an existing group.<= br>
    Therefore, I really recommend focus on defining the standardising wo= rk items that you think are needed rather than trying to do any word-smithi= ng of a potential charter (that eventually is not needed).
    =

    Thanks for giving me the chance to clarify - I really w= as talking about chartering work, not just chartering a working group, but = that wasn't clear from my note. As you said, knowing what the work is, = in more detail, will help you and Magnus know what to do next.=C2=A0
    <= div>
    So, my suggestion for the interested community is to nai= l down
    1. In order to "do LOOPS", what already exi= sts, that can be used without changes?
    2. what already exists, but nee= ds to be extended for LOOPS?
    3. what needs to be created, because noth= ing exists that meets the needs?
    =C2=A0I'm not a LOOPS propone= nt (the ADs asked me to chair the BOF about a month before IETF 105), but s= peaking as someone who hasn't been involved in depth, I wonder about
    1. How a sender tunes FEC dynamically - is that automatic,= based on FEC mechanisms people are thinking about, or is there work to do = there?

    = <mjm> There are FEC mechanisms to adapt coding dynamically based on a= cknowledgments for example. In the QUICK implementation we will have flag a= RECOVERED packet that could be used to adapt the coding rate. Other implem= entations or code-specific protocols are also available.


    1. How a sender knows whether to do FEC, retransmissi= on, or both FEC and retransmission, dynamically?

    <mjm> Well the use of FEC (= or not) is a design decision.=C2=A0 Of course you need the code (and the li= braries). And then the decision will be based on known link condition, good= put, expected performance, type of traffic (video, time sensitive etc.). An= d finding a tunnel and PEPs if you need to. And it can depend on path stati= stics and not being end to end. I am not sure you could standardize that de= cision.


    1. How a sender knows that = it shouldn't be doing anything, because anything it does won't help= ("first, do no harm")?

    <mjm> Of course in a congested network doi= ng nothing is probably best. Again there is a lot of work on the interactio= n of coding and congestion control.

    <mjm> Not everyone knows th= e things but there has been a lot of work in FECFRAME (in IETF) and NWCRG. = Someone did mention that a lot of the work was done in a research group not= a working group. But real implementations exist in famous =E2=80=9Cnetwork= s".=C2=A0

    <mjm> Since most of your questions are about era= sure coding (coding for packet loss) is that a direction LOOPS wants to tak= e? Somekind of nwcWG?


    mjm



    Does everyone know how to do those three things, except me? := -)=C2=A0

    Pointers to specifications would be aweso= me ...=C2=A0

    Spencer


    Mirja



    --=C2=A0
    LOOPS mailing list=C2=A0
    LOOPS@ie= tf.org=C2=A0
    https://www.ietf.org/mailman/= listinfo/loops=C2=A0
    --000000000000c92aa5058ee70331-- From nobody Tue Jul 30 08:01:34 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE41201A8 for ; Tue, 30 Jul 2019 08:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HXqXphFtoUeq for ; Tue, 30 Jul 2019 08:01:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2263D120130 for ; Tue, 30 Jul 2019 08:01:30 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45yfs41sChzyf5; Tue, 30 Jul 2019 17:01:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 30 Jul 2019 17:01:27 +0200 Cc: Spencer Dawkins at IETF , Mirja Kuehlewind , "nwcrg@irtf.org" , Suresh Krishnan , Magnus Westerlund , loops@ietf.org X-Mao-Original-Outgoing-Id: 586191627.7237149-79f44496709c5aa7790c100c12d7c2bf Content-Transfer-Encoding: quoted-printable Message-Id: <9AED146F-0A68-41EA-8218-D25F1572A129@tzi.org> References: To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 15:01:32 -0000 Hi Marie-Jos=C3=A9, > There are FEC mechanisms to adapt coding dynamically based on = acknowledgments for example. In the QUICK implementation we will have = flag a RECOVERED packet that could be used to adapt the coding rate. = Other implementations or code-specific protocols are also available. Right. So a LOOPS variant will still need to be developed. >> =E2=80=A2=20 >> How a sender knows whether to do FEC, retransmission, or both FEC and = retransmission, dynamically? > Well the use of FEC (or not) is a design decision. Of course = you need the code (and the libraries). And then the decision will be = based on known link condition, goodput, expected performance, type of = traffic (video, time sensitive etc.). And finding a tunnel and PEPs if = you need to. And it can depend on path statistics and not being end to = end. I am not sure you could standardize that decision. What can be decided unilaterally does not need to be standardized. Information that needs to be collected in cooperation between both ends = to enable this decision (=E2=80=9Cmeasurement information=E2=80=9D) may = need to be standardized. In any case, the LOOPS stance to setting up the channel is a = =E2=80=9Ccontroller model=E2=80=9D, i.e. we don=E2=80=99t plan to have = negotiation or some such in the protocol, but expect a controller to set = up both ends in a coordinated way. This is probably the biggest item = that needs to be added to enable host-to-node mode, as the host is less = likely to be involved in that controller model (even though it could be, = that part would then also need to be standardized). >> How a sender knows that it shouldn't be doing anything, because = anything it does won't help ("first, do no harm")? > Of course in a congested network doing nothing is probably best. = Again there is a lot of work on the interaction of coding and congestion = control. Right, which would need to be worked out into a protocol plus at least = some basic best current practice algorithms for LOOPS. > Not everyone knows the things but there has been a lot of work = in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the = work was done in a research group not a working group. But real = implementations exist in famous =E2=80=9Cnetworks=E2=80=9D.=20 Great. So let=E2=80=99s start to identify those documents that are = nearly ready to be used and fit well. E.g., for NWCRG, I=E2=80=99m = aware of: "Sliding Window Random Linear Code (RLC) Forward Erasure Correction = (FEC) Schemes for FECFRAME", Vincent Roca, Belkacem Teibi, 2019-06-18, and possibly (I=E2=80=99m not sure yet LOOPS will be a straightforward = application of FECFRAME): "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes", Vincent Roca, Ali Begen, 2019-01-11, >=20 > Since most of your questions are about erasure coding (coding = for packet loss) is that a direction LOOPS wants to take? Somekind of = nwcWG? In a certain way, very much so. Now LOOPS is intended to have a = retransmission mode, too, which probably would go beyond standard fare = of NWCRG. I=E2=80=99m also not sure that the finer points of = measurement that are needed (bilaterally) to enable really good LOOPS = implementations (mostly unilaterally) are covered in NWCRG, and I=E2=80=99= m also not sure about congestion feedback. But I wouldn=E2=80=99t mind = to call the thing NWCWG, as long as we get to ship the retransmission = mode first. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 30 08:14:50 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A541200E0 for ; Tue, 30 Jul 2019 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3X4Gsu0gkHzI for ; Tue, 30 Jul 2019 08:14:39 -0700 (PDT) Received: from smtpextng.isae.fr (smtpextng.isae.fr [192.93.254.80]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0A1200E7 for ; Tue, 30 Jul 2019 08:14:39 -0700 (PDT) Received: from smtp-secu-int (smtp-secu-int.isae.fr [10.132.1.48]) by smtpextng.isae.fr (Postfix) with ESMTP id 3143371278; Tue, 30 Jul 2019 17:14:37 +0200 (CEST) Received: from [10.161.3.211] (pc-lochin.isae.fr [10.161.3.211]) by smtp-secu-int (Postfix) with ESMTPSA id 2AF7559; Tue, 30 Jul 2019 17:14:37 +0200 (CEST) To: loops@ietf.org, nwcrg@irtf.org References: From: Emmanuel Lochin Message-ID: <7b64f9e8-5b8b-6ce6-145d-2c4ccb10c62b@isae-supaero.fr> Date: Tue, 30 Jul 2019 17:14:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F06F60B90633DE1B8CCBF927" Content-Language: en-US Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 15:14:43 -0000 This is a multi-part message in MIME format. --------------F06F60B90633DE1B8CCBF927 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Spencer, all, On 30/07/2019 16:22, Spencer Dawkins at IETF wrote: > > 1. How a sender tunes FEC dynamically - is that automatic, based on > FEC mechanisms people are thinking about, or is there work to do > there? > 2. How a sender knows whether to do FEC, retransmission, or both FEC > and retransmission, dynamically? > 3. How a sender knows that it shouldn't be doing anything, because > anything it does won't help ("first, do no harm")? > IMHO, each answer depends on which layer you seek to apply FEC and why. Adding and adapting FEC at L2 or L3 does not have the same impact than at L4 and does not lead to the same adaptive mechanism. Then, adding FEC at L4 also depends on whether you are congestion controlled or not, you want to stick to TCP-friendliness, your QoS objectives, and many other things... Finally concerning #3, I would say that monitoring the e2e delay would give you a good indication to enable FEC or not. If the delay is "small", you won't beat ARQ. Emmanuel -- Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 Web : http://personnel.isae.fr/emmanuel-lochin/ --------------F06F60B90633DE1B8CCBF927 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Spencer, all,

    On 30/07/2019 16:22, Spencer Dawkins at IETF wrote:
    1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?
    2. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
    3. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
    IMHO, each answer depends on which layer you seek to apply FEC and why. Adding and adapting FEC at L2 or L3 does not have the same impact than at L4 and does not lead to the same adaptive mechanism. Then, adding FEC at L4 also depends on whether you are congestion controlled or not, you want to stick to TCP-friendliness, your QoS objectives, and many other things...
    Finally concerning #3, I would say that monitoring the e2e delay would give you a good indication to enable FEC or not. If the delay is "small", you won't beat ARQ.

    Emmanuel


    -- 
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://personnel.isae.fr/emmanuel-lochin/
    --------------F06F60B90633DE1B8CCBF927-- From nobody Tue Jul 30 09:16:02 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575B512016F for ; Tue, 30 Jul 2019 09:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diAUS83lzNxd for ; Tue, 30 Jul 2019 09:15:59 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B8D12015C for ; Tue, 30 Jul 2019 09:15:59 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id s7so129276540iob.11 for ; Tue, 30 Jul 2019 09:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lQ9b/HG9RWw2I7ZpBy8qSQrPsAclxrChp/vJWlAgss4=; b=voL35qH9WTGXzX8D4FLIiWm+zd9jKyRnNA20nFOFEfWECdPAGRlXf1pQ6Gz4za15G1 lKyAw9dg51H2QZqhoYMYv9tJADyfZoLvbohXhypG6hSTmTtCVyFOH+yBSF/3JM92PiaT ZlYyGxo4xoklTu0qDt2tNJ9TAkpn5L9vfbpJ/1uFLTza/wpwZa5lKRGnLN2t5t+FfOMZ XBwXd2T6IoOqh/unGUn0g+bqbG6OiFWMyLv3WcEp2zH3fADerSGwTg8MeF3ZVG6zcBsZ M+C5AjUvIEGg6OwGNJSZek1Ahw1RSKSMeHlmY4zYuDxD46vCeG2wi1tOuv5FnmAPv/tG dcLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lQ9b/HG9RWw2I7ZpBy8qSQrPsAclxrChp/vJWlAgss4=; b=ZQRq18MpKwlVHmpez3+X0cOvz+g0/DKddTSHu40eAfKn3/765xULCzS9aenL7t7LyM S+nuZPzv8OhhIaDjjM1mjfmZ4rAEmcdt+rea/R6beJossu6DQDNhdFjEpXXYwnSEJngW ObycJ1/k/gMrd8jXFFve4v4+Id8F3SB5phlw1wfUQWG3pJ8vF0NhdzQt7G/Z0PjTeIz5 AIxGljDOHgyNKQe6DLByuYX3DS90pM8juYdGj7/drphhWBD0om2rB6UHJbEYP27mov+W U8wDqTtcNPjRvncZ/VwpFqbsZOkDK4XYQ/1H+D6DUGk0h99MV4TEE0XdayflnyaVMQF6 drFw== X-Gm-Message-State: APjAAAWeChuDZNYumg0ws9ECRbbnrrGfPVZdlccn4VIGm5kbPQLgAvPT fgJ0T9xsKUTTZ1pew3nNIgAaNSEF X-Google-Smtp-Source: APXvYqyzB/M98+5ZnqckiEOLMzaD03vrZxJBxi8YbIY8o76YyBPIA31Guee8heMPnIEgyejZWLx8uw== X-Received: by 2002:a6b:f910:: with SMTP id j16mr36696512iog.256.1564503358121; Tue, 30 Jul 2019 09:15:58 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id a1sm51306520ioo.5.2019.07.30.09.15.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 09:15:57 -0700 (PDT) To: loops@ietf.org References: From: Wesley Eddy Message-ID: Date: Tue, 30 Jul 2019 12:15:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------52299EE2264D59214376781E" Content-Language: en-US Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 16:16:01 -0000 This is a multi-part message in MIME format. --------------52299EE2264D59214376781E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/30/2019 10:22 AM, Spencer Dawkins at IETF wrote: > > Thanks for giving me the chance to clarify - I really was talking > about chartering work, not just chartering a working group, but that > wasn't clear from my note. As you said, knowing what the work is, in > more detail, will help you and Magnus know what to do next. > > So, my suggestion for the interested community is to nail down > > 1. In order to "do LOOPS", what already exists, that can be used > without changes? > 2. what already exists, but needs to be extended for LOOPS? > 3. what needs to be created, because nothing exists that meets the needs? > >  I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a > month before IETF 105), but speaking as someone who hasn't been > involved in depth, I wonder about > > 1. How a sender tunes FEC dynamically - is that automatic, based on > FEC mechanisms people are thinking about, or is there work to do > there? > 2. How a sender knows whether to do FEC, retransmission, or both FEC > and retransmission, dynamically? > 3. How a sender knows that it shouldn't be doing anything, because > anything it does won't help ("first, do no harm")? > > Does everyone know how to do those three things, except me? :-) > I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for "dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks. For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification). When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this.  It's easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard. --------------52299EE2264D59214376781E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    On 7/30/2019 10:22 AM, Spencer Dawkins at IETF wrote:

    Thanks for giving me the chance to clarify - I really was talking about chartering work, not just chartering a working group, but that wasn't clear from my note. As you said, knowing what the work is, in more detail, will help you and Magnus know what to do next. 

    So, my suggestion for the interested community is to nail down
    1. In order to "do LOOPS", what already exists, that can be used without changes?
    2. what already exists, but needs to be extended for LOOPS?
    3. what needs to be created, because nothing exists that meets the needs?
     I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a month before IETF 105), but speaking as someone who hasn't been involved in depth, I wonder about
    1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?
    2. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
    3. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
    Does everyone know how to do those three things, except me? :-) 

    I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for "dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks.

    For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification).  When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this.  It's easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard.


    --------------52299EE2264D59214376781E-- From nobody Tue Jul 30 09:30:45 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1513312015C for ; Tue, 30 Jul 2019 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 m4jnBGUCRW8b for ; Tue, 30 Jul 2019 09:30:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45265120089 for ; Tue, 30 Jul 2019 09:30:42 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45yhr01ZSQzyNP; Tue, 30 Jul 2019 18:30:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Tue, 30 Jul 2019 18:30:39 +0200 Cc: loops@ietf.org X-Mao-Original-Outgoing-Id: 586197028.205039-2548d43771a9236c69c1e1217a318d14 Content-Transfer-Encoding: quoted-printable Message-Id: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> References: To: Wesley Eddy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 16:30:44 -0000 > I skimmed the drafts, but might be missing some context still ... = LOOPS seems like it is intended for =E2=80=9Cdumb" subnetworks, but = could be potentially harmful over "smarter" subnetworks. If the path segment already tries to be =E2=80=9Chelpful=E2=80=9D, there = might indeed be an adverse interaction. Or the =E2=80=9Chelp=E2=80=9D = might only be available or effective for certain transport protocols, = and LOOPS can still do something useful for those not (yet!) covered = (for instance, this could be QUIC). Also, the =E2=80=9Chelp=E2=80=9D = might be geared towards close interaction with the transport, and adding = a tunnel layer could interfere with this. So whether running LOOPS on a = Sat PEP is useful in any way or even detrimental depends a lot on how = up-to-date that PEP is. Note that the entity running LOOPS may not be = the entity running the Sat PEP, so it may not have control over the PEP = situation. Running LOOPS on the path segments from host to Sat and from the Sat to = host can remove the need for some costly (in bandwidth and latency) = retransmissions on the Sat link itself. =20 > For satellite links, there is the capability to do per-frame adaptive = coding and modulation (based on traffic classification). When the lower = layer offers service tailored for the needs of each packet already, = LOOPS doing something up above is possibly at odds with this. It=E2=80=99= s easy to imagine scenarios where this leads to actual performance = degradation, positive feedback loops, or other problems, so I'm = interested in what people have done or been thinking about in this = regard. LOOPS is not meant as pixie dust that you sprinkle indiscriminately over = your network. The cost is not entirely trivial and the benefits depend on the = characteristics of both the path and the traffic. You should have a reason to use LOOPS. See above for some potential reasons to use LOOPS on top of Sat PEPs. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 30 10:43:49 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8843B1202BD for ; Tue, 30 Jul 2019 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 TI78rnTR0eAY for ; Tue, 30 Jul 2019 10:43:45 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 DE0C61202AA for ; Tue, 30 Jul 2019 10:43:44 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id z28so8662197ljn.4 for ; Tue, 30 Jul 2019 10:43:44 -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=Ab5YTvvmGQor8LGXVO8SAjjZ0LtbqAHJIxMpMww/D0U=; b=tHz/PGQ9ft3YwX92bQq0V2ZZmzCaZ5G+LLJ6lUzOgrEtw9ulyGK4pliRX+Q+53WmeX YioeVWcnBxjPXNrYOBd5VcCtWrn477+FkG2+FVORBqr3hdgoi1T0ns7keu80r3pvPrj0 S0fpB4bIBWj1XnlfaSzzeA4G57TJsqnkIv5UYF6Wi2fEjgNHhcesPoP94efIGzhYnF74 44Sq7JpEIm6J0ulfKm1j6qxGt93xIHhm9FY6O1f1yUc6bSCLP2igQKrFWv7OG7P2dCCA XZ+XItxbFbJLLc2NBiNnla7aV6IYQaS0QI+l2HNAp6Mqe4BiQvQ8wT9Qj2x92Ml9kID0 wjRQ== 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=Ab5YTvvmGQor8LGXVO8SAjjZ0LtbqAHJIxMpMww/D0U=; b=W2mor+w3TmaBFEyIp9SEiyLWJnef0oG+eBnpjbmRWtKebZXfNDSYr0y/vVYL8o+Ec8 42k/VIRobYERghpFZC9XAdU+oSRedLhDJCHrSENxPkPtAXpXDtG1hfcpf+X5e/yI8CaZ IaItpjZGtk7ebJud/FLl0UWyhaEzQLXYeraEfVW2fvtWwniQuzfhUSVhITN2WCE6w2WX vpt0+WKgkYAizBoINOymFys80CLB/qQzHXrXj2Qpt6NwxIrrijXWNHm4nWYWasmUd/ky m/m6+i6ZIYCly7zO5hjtfDKlnT3L8azjZZbw2R98WCYtIcMGIsEbgJl3nhNGOwpYtRJS miHg== X-Gm-Message-State: APjAAAVv9Xxw7lo3LB1f+Klm0AfQOiSjqqOmVQKwH29PmNblbvOiXmdN c67uGjWkhKY7xbCHbis0CM2QF6ANt1dJpvvo3ZY= X-Google-Smtp-Source: APXvYqxabxZ4bkIgfKgPY5g7fphe7+1K+lqghMed9d6mJVSrIejhizsNWm9ZWFmW3t+Wm8l5eKJGY5t6OFsZqyv6P8I= X-Received: by 2002:a2e:8741:: with SMTP id q1mr9213835ljj.144.1564508623037; Tue, 30 Jul 2019 10:43:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 30 Jul 2019 12:43:15 -0500 Message-ID: To: Marie-Jose Montpetit Cc: Mirja Kuehlewind , "nwcrg@irtf.org" , Suresh Krishnan , Carsten Bormann , Magnus Westerlund , loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000b9675b058ee98ccb" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 17:43:48 -0000 --000000000000b9675b058ee98ccb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm going to be replying to two or three e-mail in this thread, so I'll try to be coherent over my replies ... On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit wrote: > Since most of your questions are related to FEC I copy the nwcrg. See > below > > mjm > > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > > On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF ( > spencerdawkins.ietf@gmail.com) wrote: > > Hi, Mirja, > > On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind > wrote: > >> Hi Carsten, hi Spencer, >> >> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> > >> > My impression, and Magnus might say I'm insane, was that Magnus is >> right on the edge of whether this work can be chartered without a second= , >> working group-forming BOF. If the LOOPS community can't live without >> host-to-node, the community should add it. If the community can make use= of >> LOOPS without host-to-node and add it later, the community might conside= r >> whether that reduces the scope of the initial proposed charter enough to >> help Magnus approve it :-) >> >> Yes, it would be possible to charter without another BoF a small and >> well-scoped group, however, it also would be possible to work on small a= nd >> well-defined pieces of work without a new working group. This was one of >> the reasons why this was not a non-wg-forming BoF because it is not clea= r >> yet if a new group is needed or the resulting pieces of standardization >> work are small enough to fit into an existing group. >> >> Therefore, I really recommend focus on defining the standardising work >> items that you think are needed rather than trying to do any word-smithi= ng >> of a potential charter (that eventually is not needed). >> > > Thanks for giving me the chance to clarify - I really was talking about > chartering work, not just chartering a working group, but that wasn't cle= ar > from my note. As you said, knowing what the work is, in more detail, will > help you and Magnus know what to do next. > > So, my suggestion for the interested community is to nail down > > 1. In order to "do LOOPS", what already exists, that can be used > without changes? > 2. what already exists, but needs to be extended for LOOPS? > 3. what needs to be created, because nothing exists that meets the > needs? > > I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a > month before IETF 105), but speaking as someone who hasn't been involved = in > depth, I wonder about > > 1. How a sender tunes FEC dynamically - is that automatic, based on > FEC mechanisms people are thinking about, or is there work to do there= ? > > There are FEC mechanisms to adapt coding dynamically based on > acknowledgments for example. In the QUICK implementation we will have fla= g > a RECOVERED packet that could be used to adapt the coding rate. Other > implementations or code-specific protocols are also available. > > > 1. > How a sender knows whether to do FEC, retransmission, or both FEC and > retransmission, dynamically? > > Well the use of FEC (or not) is a design decision. Of course you > need the code (and the libraries). And then the decision will be based on > known link condition, goodput, expected performance, type of traffic > (video, time sensitive etc.). And finding a tunnel and PEPs if you need t= o. > And it can depend on path statistics and not being end to end. I am not > sure you could standardize that decision. > So, speaking with no dots because I don't have any, I agree with what Marie-Jose is saying here, but my understanding is that LOOPS endpoints might turn LOOPS off completely if local optimizations aren't needed. So I'm thinking about how a sender makes that decision, and how a sender might do trade-offs. I think one point in discussions with Marie-Jose might be that she's thinking in terms of Technical Specifications ( https://tools.ietf.org/html/rfc2026#section-3.1), which are necessary, but discussions are making me think that proponents might usefully also think in terms of Applicability Statements ( https://tools.ietf.org/html/rfc2026#section-3.2), which (quoting) An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 7. An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required, recommended, or elective (see section 3.3). An AS may describe particular methods of using a TS in a restricted "domain of applicability", such as Internet routers, terminal servers, Internet systems that interface to Ethernets, or datagram- based database servers. So, if Applicability Statements (also standards-track documents) would be helpful for LOOPS deployment and operation, the proponents might think about whether they want to do work in that space. If decisions about what senders do turn out to be entirely up to the sender, that's great, but if the proponents want to bound the possible behaviors of implementations to improve deployment and operation, that might also be appropriate in BCPs ( https://tools.ietf.org/html/rfc2026#section-5). > > 1. > How a sender knows that it shouldn't be doing anything, because > anything it does won't help ("first, do no harm")? > > Of course in a congested network doing nothing is probably best. > Again there is a lot of work on the interaction of coding and congestion > control. > > Not everyone knows the things but there has been a lot of work in > FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work > was done in a research group not a working group. But real implementation= s > exist in famous =E2=80=9Cnetworks". > Right - so one possibility is publishing work from NWCRG in the IETF stream, and especially standards-track, with appropriate review by the IETF community. That could take a lot of forms (RGs and WGs can interact in a lot of different ways). > Since most of your questions are about erasure coding (coding for > packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG? > See Mirja's note about chartering work, and only chartering working groups when that's needed. But as you note, the FECFRAME extensions happened in TSVWG, so that would be a reasonable conversation to have with TSVWG chairs (and I note that Wes Eddy, who popped up further down in this thread, is a TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in an existing working group, NWCWG could be a plan. > > mjm > > > > Does everyone know how to do those three things, except me? :-) > > Pointers to specifications would be awesome ... > > Spencer > > >> Mirja >> >> >> >> -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > > --000000000000b9675b058ee98ccb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm going to be replying to two or th= ree e-mail in this thread, so I'll try to be coherent over my replies .= ..=C2=A0

    On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
    Since most of your questions are re= lated to FEC I copy the nwcrg. See <mjm> below

    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Researc= h Affiliate, MIT Media Laboratory

    On July 30= , 2019 at 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) = wrote:

    Hi, Mirja,=C2=A0

    On Tue, Jul 30, 2019 at 5:34 AM Mirja K= uehlewind <ietf= @kuehlewind.net> wrote:
    Hi Carsten, hi Spencer,

    > On 25. Jul 2019, at 20:5= 9, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
    >=
    > My impression, and Magnus might say I'm insane, was that Magnu= s is right on the edge of whether this work can be chartered without a seco= nd, working group-forming BOF. If the LOOPS community can't live withou= t host-to-node, the community should add it. If the community can make use = of LOOPS without host-to-node and add it later, the community might conside= r whether that reduces the scope of the initial proposed charter enough to = help Magnus approve it :-)

    Yes, it would be possible to charter with= out another BoF a small and well-scoped group, however, it also would be po= ssible to work on small and well-defined pieces of work without a new worki= ng group. This was one of the reasons why this was not a non-wg-forming BoF= because it is not clear yet if a new group is needed or the resulting piec= es of standardization work are small enough to fit into an existing group.<= br>
    Therefore, I really recommend focus on defining the standardising wo= rk items that you think are needed rather than trying to do any word-smithi= ng of a potential charter (that eventually is not needed).
    =

    Thanks for giving me the chance to clarify - I really w= as talking about chartering work, not just chartering a working group, but = that wasn't clear from my note. As you said, knowing what the work is, = in more detail, will help you and Magnus know what to do next.=C2=A0
    <= div>
    So, my suggestion for the interested community is to nai= l down
    1. In order to "do LOOPS", what already exi= sts, that can be used without changes?
    2. what already exists, but nee= ds to be extended for LOOPS?
    3. what needs to be created, because noth= ing exists that meets the needs?
    =C2=A0I'm not a LOOPS propone= nt (the ADs asked me to chair the BOF about a month before IETF 105), but s= peaking as someone who hasn't been involved in depth, I wonder about
    1. How a sender tunes FEC dynamically - is that automatic,= based on FEC mechanisms people are thinking about, or is there work to do = there?

    = <mjm> There are FEC mechanisms to adapt coding dynamically based on a= cknowledgments for example. In the QUICK implementation we will have flag a= RECOVERED packet that could be used to adapt the coding rate. Other implem= entations or code-specific protocols are also available.


    1. How a sender knows whether to do FEC, retransmission, or both FEC and ret= ransmission, dynamically?

    <mjm> Well the use of FEC (or not) is a design dec= ision.=C2=A0 Of course you need the code (and the libraries). And then the = decision will be based on known link condition, goodput, expected performan= ce, type of traffic (video, time sensitive etc.). And finding a tunnel and = PEPs if you need to. And it can depend on path statistics and not being end= to end. I am not sure you could standardize that decision.

    =

    So, speaking with no dots because I don= 9;t have any, I agree with what Marie-Jose is saying here, but my understan= ding is that LOOPS endpoints might turn LOOPS off completely if local optim= izations aren't needed. So I'm thinking about how a sender makes th= at decision, and how a sender might do trade-offs.=C2=A0

    I think one point in discussions with Marie-Jose might be that she&#= 39;s thinking in terms of Technical Specifications (https://tools.ietf.org/html/rfc2026#se= ction-3.1), which are necessary, but discussions are making me think th= at proponents might usefully also think in terms of Applicability Statement= s (https://tool= s.ietf.org/html/rfc2026#section-3.2), which (quoting)=C2=A0
    <= br>
    =C2=A0 =C2=A0An Applicability Statement specifies how, and un= der what
    =C2=A0 =C2=A0circumstances, one or more TSs may be applied to s= upport a particular
    =C2=A0 =C2=A0Internet capability.=C2=A0 An AS may sp= ecify uses for TSs that are not
    =C2=A0 =C2=A0Internet Standards, as disc= ussed in Section 7.

    =C2=A0 =C2=A0An AS identifies the relevant TSs a= nd the specific way in which they
    =C2=A0 =C2=A0are to be combined, and m= ay also specify particular values or ranges
    =C2=A0 =C2=A0of TS parameter= s or subfunctions of a TS protocol that must be
    =C2=A0 =C2=A0implemented= .=C2=A0 An AS also specifies the circumstances in which the use
    =C2=A0 = =C2=A0of a particular TS is required, recommended, or elective (see section=
    =C2=A0 =C2=A03.3).

    =C2=A0 =C2=A0An AS may describe particular me= thods of using a TS in a restricted
    =C2=A0 =C2=A0"domain of applica= bility", such as Internet routers, terminal
    =C2=A0 =C2=A0servers, I= nternet systems that interface to Ethernets, or datagram-
    =C2=A0 =C2=A0b= ased database servers.

    So, if Applicability St= atements (also standards-track documents) would be helpful for LOOPS deploy= ment and operation, the proponents might think about whether they want to d= o work in that space.=C2=A0

    If decisions about wha= t senders do turn out to be entirely up to the sender, that's great, bu= t if the proponents want to bound the possible behaviors of implementations= to improve deployment and operation, that might also be appropriate in BCP= s (https://tools.= ietf.org/html/rfc2026#section-5).
    =C2=A0

    1. How a sender = knows that it shouldn't be doing anything, because anything it does won= 't help ("first, do no harm")?

    <mjm> Of course in a congested = network doing nothing is probably best. Again there is a lot of work on the= interaction of coding and congestion control.

    <mjm> Not everyo= ne knows the things but there has been a lot of work in FECFRAME (in IETF) = and NWCRG. Someone did mention that a lot of the work was done in a researc= h group not a working group. But real implementations exist in famous =E2= =80=9Cnetworks".=C2=A0

    Right - = so one possibility is publishing work from NWCRG in the IETF stream, and es= pecially standards-track, with appropriate review by the IETF community. Th= at could take a lot of forms (RGs and WGs can interact in a lot of differen= t ways).=C2=A0
    =

    <mjm> Since most of your questions are about erasure cod= ing (coding for packet loss) is that a direction LOOPS wants to take? Somek= ind of nwcWG?


    See Mir= ja's note about chartering work, and only chartering working groups whe= n that's needed. But as you note, the FECFRAME extensions happened in T= SVWG, so that would be a reasonable conversation to have with TSVWG chairs = (and I note that Wes Eddy, who popped up further down in this thread, is a = TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit i= n an existing working group, NWCWG could be a plan.=C2=A0=C2=A0


    mj= m



    Does everyone know how to do those three things, e= xcept me? :-)=C2=A0

    Pointers to specifications wou= ld be awesome ...=C2=A0

    Spencer


    Mirja



    --=C2=A0
    LOOPS mailing list=C2=A0
    LOOPS@ietf.org=C2=A0
    https://www.ietf.org/= mailman/listinfo/loops=C2=A0
    --000000000000b9675b058ee98ccb-- From nobody Tue Jul 30 10:46:48 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9A12019C for ; Tue, 30 Jul 2019 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyKKBancfIy4 for ; Tue, 30 Jul 2019 10:46:44 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B5FDF120089 for ; Tue, 30 Jul 2019 10:46:43 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id b29so38117325lfq.1 for ; Tue, 30 Jul 2019 10:46:43 -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=7weHovtgfZVHRBy3l0zH6K1kZIeWd93R83AAHjzlPkY=; b=GbH/QrwpKCVbWx0s4+6AqTCPnPszaIHg9uu7Q9/DLysN/JjAah9hEAvFtiq9oAkAsZ wlB5LfnTMY6aOb/Eyc02HLLH0Thb0b41/uMfGqeXsFgbMcJ8zY+0/HI9N6mhIs6gmPJ+ MyNfRX2t+fZb3Wtvn1+1UZNSQt4PVM8GVYtExCn8spRqZsQeyWQ/wlqIWpiJyS0uncIx XtzIZRpEndKLjY5KoMwQj0qf9usbsmAFl6x3hMCTkKS4S8HeRbYaAkTtD6WL/0JMsA0W RPp2JyShQ96dg0QGARvVWJw8djbeblHvnN8oCNJj814B1ZaRnkUo1ok6tXvJNrNnG+a8 p+vw== 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=7weHovtgfZVHRBy3l0zH6K1kZIeWd93R83AAHjzlPkY=; b=fQftw0IpgOyRtIrMQ8eRfZKErS50BYTQ7KAsqeWuR6hEtsfFp7b+Okx8X6dv6guU+3 +57So3J57WBFkYlgp+4/+EunNkXOTQYwDmGvLXH8jneGdTCIIndsC5LBOt32q8T2NObX +0nySPvmNfmhfdIeIcdqgoNPaQT8bgC7wkHx6Qcx7FoSaD9XpjecckCnMIwTBWKaqn4q PqUSROpA6xw7/IdlvGgk4ZOOpkqlJroSDrjI5+xAhctLVrigj3tfv6vLlkvG1mtkI6xB agA9spoqNjsqmQ76AqMiJqVp7HNCIUszDm5K/9tKPCSvoTgXq9IYFc0fndCIZhc9B0SK afjw== X-Gm-Message-State: APjAAAUflydk6BGfVHwFv5c8g+1wyWPHLFLvD9r2j21ozbMVR16kGryp m6C6WmnT2bg1gAxNkls5Drq4PHjpdV6hTTxlzRs= X-Google-Smtp-Source: APXvYqwL3rSCqoGvGj+yNnuvV1QEi2sYY8YVzhyNzuNTbodt+BWKF+o8P4ZAsQXG0B2I4eyWq6BLztAY/jKD8fSV4aA= X-Received: by 2002:ac2:5337:: with SMTP id f23mr56403101lfh.15.1564508801875; Tue, 30 Jul 2019 10:46:41 -0700 (PDT) MIME-Version: 1.0 References: <7b64f9e8-5b8b-6ce6-145d-2c4ccb10c62b@isae-supaero.fr> In-Reply-To: <7b64f9e8-5b8b-6ce6-145d-2c4ccb10c62b@isae-supaero.fr> From: Spencer Dawkins at IETF Date: Tue, 30 Jul 2019 12:46:14 -0500 Message-ID: To: Emmanuel Lochin Cc: loops@ietf.org, nwcrg@irtf.org Content-Type: multipart/alternative; boundary="0000000000006245af058ee9973f" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 17:46:47 -0000 --0000000000006245af058ee9973f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Emmanuel, On Tue, Jul 30, 2019 at 10:14 AM Emmanuel Lochin < emmanuel.lochin@isae-supaero.fr> wrote: > Hi Spencer, all, > > On 30/07/2019 16:22, Spencer Dawkins at IETF wrote: > > > 1. How a sender tunes FEC dynamically - is that automatic, based on > FEC mechanisms people are thinking about, or is there work to do there= ? > 2. How a sender knows whether to do FEC, retransmission, or both FEC > and retransmission, dynamically? > 3. How a sender knows that it shouldn't be doing anything, because > anything it does won't help ("first, do no harm")? > > IMHO, each answer depends on which layer you seek to apply FEC and why. > Adding and adapting FEC at L2 or L3 does not have the same impact than at > L4 and does not lead to the same adaptive mechanism. Then, adding FEC at = L4 > also depends on whether you are congestion controlled or not, you want to > stick to TCP-friendliness, your QoS objectives, and many other things... > Finally concerning #3, I would say that monitoring the e2e delay would > give you a good indication to enable FEC or not. If the delay is "small", > you won't beat ARQ. > My understanding from discussions around the LOOPS BOF is that this is intended to be transport-agnostic, so most likely L3. I haven't heard anyone talking about L2 LOOPS, but as you note, that depends on the networks that you're trying to help out. Thanks for the insight! (I thought that was true, but I'm not an NWC expert by any stretch) Spencer > Emmanuel > > > -- > Emmanuel LOCHIN > Professeur ISAE > ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l'Esp= ace > 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http:= //www.isae-supaero.fr > Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 > Web : http://personnel.isae.fr/emmanuel-lochin/ > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --0000000000006245af058ee9973f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Emmanuel,=C2=A0

    On Tue, Jul 30, 2019= at 10:14 AM Emmanuel Lochin <emmanuel.lochin@isae-supaero.fr> wrote:
    =20 =20 =20
    Hi Spencer, all,

    On 30/07/2019= 16:22, Spencer Dawkins at IETF wrote:
    1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?
    2. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
    3. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm&= quot;)?
    IMHO, each answer depends on which layer you seek to apply FEC and why. Adding and adapting FEC at L2 or L3 does not have the same impact than at L4 and does not lead to the same adaptive mechanism. Then, adding FEC at L4 also depends on whether you are congestion controlled or not, you want to stick to TCP-friendliness, your QoS objectives, and many other things...
    Finally concerning #3, I would say that monitoring the e2e delay would give you a good indication to enable FEC or not. If the delay is "small", you won't beat ARQ.

    My understanding from discussions around the LOOPS BOF is = that this is intended to be transport-agnostic, so most likely L3. I haven&= #39;t heard anyone talking about L2 LOOPS, but as you note, that depends on= the networks that you're trying to help out.=C2=A0

    Thanks for the insight! (I thought that was true, but I'm not an = NWC expert by any stretch)

    Spencer
    =C2= =A0
    Emmanuel


    --=
=20
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l&#=
39;Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://person=
nel.isae.fr/emmanuel-lochin/
    --
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.org/mailman/listinfo/loops
    --0000000000006245af058ee9973f-- From nobody Tue Jul 30 10:56:13 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E176120233 for ; Tue, 30 Jul 2019 10:56:04 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLusHjftmadb for ; Tue, 30 Jul 2019 10:56:01 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C95F120089 for ; Tue, 30 Jul 2019 10:56:01 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id i10so16829069iol.13 for ; Tue, 30 Jul 2019 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=9QNkC++TGOmwQDBH+PD8BO9ZqlIUPJBxnPGlgUsVb5I=; b=oVhbwFgT1QK0judtxiULDXEi64HaY7URAAjtKdtFufVIlWz+0g3ry901JY7xO4ybIS gaMbD78ggeWQq9DBhCSeZA1oX63b+bDX1jqN1lVja0gFieDu+zJxp8PqQYpeNES29i7/ fob/doYxQhdwEjruJr5ch8Fl01LtSyRbVn/jbUn5XW7V8IOFHsiQVhNq5XAIqtpGF2xP hkJdO2jxEaTjjcaqR4Va1fLs7Jz98/2mWTJrV+RQxld7n1nzr5drfet6jVkw0i/21MCj GBoCdYzxPohRa209lPdTh4q3iilh7QqNW1kPkeFl89Xvmo4fQKY9D9W8ScUeN2B/fHjh qQxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=9QNkC++TGOmwQDBH+PD8BO9ZqlIUPJBxnPGlgUsVb5I=; b=mHWwcJo42oZBrbVePJt5keAMMEXOky2Ytzd3grjvZW+mbsp80huYacg8yLMa/nnWo7 ESozgKNlcU65q/yIXSWuQeZaz1iSkn3JPRPc5MuDdHAdZcZR0nlxbx6oBUM404j2FUy7 qIvxjOIJiYe+tIo99CWYQ9suWZVPrFHARa8O6Zc9SxMLukt/97gHE9hcHUVPrDNg5hVI ipcXgLigQCNj66WdndkW8Myyf4/23nfB2GfW1SooxnLpfiOLP6Qgz59fxlUV6/9XVJAB s9OdA1SOKRykefMPlJyt7OkmRMF11JdT5ktifnJ0roopfZ4ydgjzL7fcgZn4HAzleHpY 6Iyg== X-Gm-Message-State: APjAAAUtxalmnLBoz9XbQDt38ITaXgI5tbO1K8pZLIJDq0WOoT7W0f7Q O/YRbzizyWHTejiu9GnTy13jyH8B3pqubYyHkUA= X-Google-Smtp-Source: APXvYqyoEikHy4HLUDuvW57a35O6pvfKbklmdKpwpNyU6ZzfpwesDzuU8r5XEb8dVasGS/5mUhLmwQIVCfnX4kXZ8sg= X-Received: by 2002:a5d:948a:: with SMTP id v10mr79986553ioj.103.1564509360330; Tue, 30 Jul 2019 10:56:00 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jul 2019 10:55:59 -0700 From: Marie-Jose Montpetit In-Reply-To: References: <7b64f9e8-5b8b-6ce6-145d-2c4ccb10c62b@isae-supaero.fr> MIME-Version: 1.0 Date: Tue, 30 Jul 2019 10:55:58 -0700 Message-ID: To: Spencer Dawkins at IETF , Emmanuel Lochin Cc: nwcrg@irtf.org, loops@ietf.org Content-Type: multipart/alternative; boundary="000000000000ac15fd058ee9b85c" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 17:56:05 -0000 --000000000000ac15fd058ee9b85c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well if you to encode IP packets and you have encryption you will get into the problem of the proposed coding scheme for QUIC that recovers ALL packets without knowing what the losses were due to and messing with congestion control above or not knowing what these packets carry to determine if they need coding or not or to define the adaptive schemes. Our solution is before encryption because of that. And as Emmanuel said at layer 4 you also need to deal with TCP congestion control unless you split the sessions. There is a lot of accumulated research, development and implementations out there :) But ok you are talking to the right people! mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 30, 2019 at 1:46:51 PM, Spencer Dawkins at IETF ( spencerdawkins.ietf@gmail.com) wrote: Hi, Emmanuel, On Tue, Jul 30, 2019 at 10:14 AM Emmanuel Lochin < emmanuel.lochin@isae-supaero.fr> wrote: > Hi Spencer, all, > > On 30/07/2019 16:22, Spencer Dawkins at IETF wrote: > > > 1. How a sender tunes FEC dynamically - is that automatic, based on > FEC mechanisms people are thinking about, or is there work to do there= ? > 2. How a sender knows whether to do FEC, retransmission, or both FEC > and retransmission, dynamically? > 3. How a sender knows that it shouldn't be doing anything, because > anything it does won't help ("first, do no harm")? > > IMHO, each answer depends on which layer you seek to apply FEC and why. > Adding and adapting FEC at L2 or L3 does not have the same impact than at > L4 and does not lead to the same adaptive mechanism. Then, adding FEC at = L4 > also depends on whether you are congestion controlled or not, you want to > stick to TCP-friendliness, your QoS objectives, and many other things... > Finally concerning #3, I would say that monitoring the e2e delay would > give you a good indication to enable FEC or not. If the delay is "small", > you won't beat ARQ. > My understanding from discussions around the LOOPS BOF is that this is intended to be transport-agnostic, so most likely L3. I haven't heard anyone talking about L2 LOOPS, but as you note, that depends on the networks that you're trying to help out. Thanks for the insight! (I thought that was true, but I'm not an NWC expert by any stretch) Spencer > Emmanuel > > > -- > Emmanuel LOCHIN > Professeur ISAE > ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l'Esp= ace > 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -http:= //www.isae-supaero.fr > Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45 > Web : http://personnel.isae.fr/emmanuel-lochin/ > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000ac15fd058ee9b85c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    Well= if you to encode IP packets and you have encryption you will get into the = problem of the proposed coding scheme for QUIC that recovers =C2=A0ALL pack= ets without knowing what the losses were due to and messing with congestion= control above or not knowing what these packets carry to determine if they= need coding or not or to define the adaptive schemes. Our solution is befo= re encryption because of that. And as Emmanuel said at layer 4 you also nee= d to deal with TCP congestion control unless you split the sessions.=C2=A0<= /div>

    There is a lot of a= ccumulated research, development and implementations out there :) But ok yo= u are talking to the right people!

    mjm



    Marie-Jos=C3=A9 Montpetit, = Ph.D.
    Research Affiliate, MIT Media Laboratory

    On July 30, 2019 at 1:46:51 PM, Spencer Dawkins at IETF= (spencerdawkins.ietf@gmai= l.com) wrote:

    Hi, Emmanuel,=C2=A0

    On Tue, Jul 30, 2019 at 10:14 AM Emmanuel Lochin <emma= nuel.lochin@isae-supaero.fr> wrote:
    Hi Spencer, all,

    On 30/07/2019 16:22, Spencer Dawkins at IETF wrote:
    1. How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?
    2. How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?
    3. How a sender knows that it shouldn't be doing anything, because anything it does won't help ("first, do no harm")?
    IMHO, each answer depends on which layer you seek to apply FEC and why. Adding and adapting FEC at L2 or L3 does not have the same impact than at L4 and does not lead to the same adaptive mechanism. Then, adding FEC at L4 also depends on whether you are congestion controlled or not, you want to stick to TCP-friendliness, your QoS objectives, and many other things...
    Finally concerning #3, I would say that monitoring the e2e delay would give you a good indication to enable FEC or not. If the delay is "small", you won't beat ARQ.

    My understanding from discussions around the LOOPS BOF is that this is intended to be transport-agnostic, so most likely L3. I haven't heard anyone talking about L2 LOOPS, but as you note, that depends on the networks that you're trying to help out.=C2=A0

    Thanks for the insight! (I thought that was true, but I'm not an NWC expert by any stretch)

    Spencer
    =C2=A0
    Emmanuel


    -- =20
Emmanuel LOCHIN
Professeur ISAE
ISAE SUPAERO - Institut Sup=C3=A9rieur de l'A=C3=A9ronautique et de l&#=
39;Espace
10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE -
http://www.isae-supaero.fr
Tel +33 5 61 33 84 85 - Fax (+33) 5 61 33 83 45
Web : http://person=
nel.isae.fr/emmanuel-lochin/
    --
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.org/mailman/listinfo/loops
    -- =20
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.iet= f.org/mailman/listinfo/loops
    --000000000000ac15fd058ee9b85c-- From nobody Tue Jul 30 11:21:22 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52561201E2 for ; Tue, 30 Jul 2019 11:21:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU0G7w-0FKSI for ; Tue, 30 Jul 2019 11:21:17 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 DEC6A1201D5 for ; Tue, 30 Jul 2019 11:21:16 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id o9so26756997iom.3 for ; Tue, 30 Jul 2019 11:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HiXgzd3xDeCu33++J3vyLkmpIbqENCwLb+3r2/ejLyw=; b=Q3NpBJzWZSMKO8xfBW1sxiaec29ztvWQ02IAXZ40bHtepDZmDE36GFymuM5TjdnZh9 PFbhMkLxBqgB+kw1xr7eEIV1mcGRCxh7TQST2YkJ1b7zc5IfiCQXxuaystbO6prJKU8X 5c9vNjrDOQTtNun0QX4kcxjEyOH/aYtgcgvNX4zLy0MAFMbTSjbCWkRcW8eXSt+9YiIA LIo8cGYm1Qe/Xay+3pdiSVy9pw+OENHd4Npb6GeIByNj1UuiN0h+4t6EpaNjv5vJKQTU Ke89VaSviByvieWM/ah2uNZfPhRjdNh7IqXq7FO7pPb6Z4Ep/Ni8aNnzcTlyUBhk/T3R 78kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HiXgzd3xDeCu33++J3vyLkmpIbqENCwLb+3r2/ejLyw=; b=AuZ3T/oazsVpUxjyBFv2eoMQvAVKj7+b/4jEdSN5beNGrkctEDcUUZbKX63aL5sUGl 0g/Vbevefop6OAYR7MaIyZSglG+5pCTefpg1Hs6xGL6te3/d076mHQqjlZo5B4hDEk5F dWUOYEcmfooomsUHJATZuHj2JKWbOHxwf/cg4PyJm2wvpuoux/A1W0qPYubv8OJnYxUx lisxLgFdRYwAAynfV6mEX7VahDR/AxklrxbdsbHx5Gp+lyPAqBetAlrGObq1T3jNeWgo 3ddQKXtuloXdeSOPfpmRJnIn+yBEJtgIEZRV5wuh2n1ONytVy3Z5xn4ad42mjkQjJv3x u/+A== X-Gm-Message-State: APjAAAV3SFmBYFL9s4jiS0JYYnMpRxjzi7z6m9tdMICHYnMF2BDLYwxf KBOmjyaNo+e6uM5NAT8vuodrCqX7 X-Google-Smtp-Source: APXvYqyXKzmIv6K476uFU8YJZJTNKSdxg2ITxwHlSXVkKi4R7yXAnqBgtt8yABzlQs+u0H353uD+Gw== X-Received: by 2002:a5d:9d42:: with SMTP id k2mr60530054iok.45.1564510876032; Tue, 30 Jul 2019 11:21:16 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id l5sm118896991ioq.83.2019.07.30.11.21.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 11:21:15 -0700 (PDT) To: Carsten Bormann Cc: loops@ietf.org References: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> From: Wesley Eddy Message-ID: <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> Date: Tue, 30 Jul 2019 14:21:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 18:21:19 -0000 On 7/30/2019 12:30 PM, Carsten Bormann wrote: >> I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for “dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks. > If the path segment already tries to be “helpful”, there might indeed be an adverse interaction. Or the “help” might only be available or effective for certain transport protocols, and LOOPS can still do something useful for those not (yet!) covered (for instance, this could be QUIC). Also, the “help” might be geared towards close interaction with the transport, and adding a tunnel layer could interfere with this. So whether running LOOPS on a Sat PEP is useful in any way or even detrimental depends a lot on how up-to-date that PEP is. Note that the entity running LOOPS may not be the entity running the Sat PEP, so it may not have control over the PEP situation. > > Running LOOPS on the path segments from host to Sat and from the Sat to host can remove the need for some costly (in bandwidth and latency) retransmissions on the Sat link itself. > >> For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification). When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this. It’s easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard. > LOOPS is not meant as pixie dust that you sprinkle indiscriminately over your network. > The cost is not entirely trivial and the benefits depend on the characteristics of both the path and the traffic. > You should have a reason to use LOOPS. > See above for some potential reasons to use LOOPS on top of Sat PEPs. You mention PEP a few times, but I didn't mention PEP, but rather the modulation and coding in satellite modems.  The framing and selection of MODCOD done by a modem is a lower layer function that's not related to PEP techniques at higher layers. From nobody Tue Jul 30 13:29:26 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6564E120108 for ; Tue, 30 Jul 2019 13:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UGAGz7q1VcI for ; Tue, 30 Jul 2019 13:29:21 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 61318120024 for ; Tue, 30 Jul 2019 13:29:21 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hsYkI-00009X-Fm; Tue, 30 Jul 2019 22:29:18 +0200 Received: from 91.141.3.254.wireless.dyn.drei.com ([91.141.3.254] helo=[192.168.1.113]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hsYkH-000Aqi-3S; Tue, 30 Jul 2019 22:29:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (16F203) In-Reply-To: <2693E1C9-B778-48CD-9790-EEE70DAFDADF@kuehlewind.net> Date: Tue, 30 Jul 2019 22:29:11 +0200 Cc: Spencer Dawkins at IETF , Carsten Bormann , loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7548531E-37C6-4643-9E60-E848891FAFFC@ifi.uio.no> References: <7CF8FA24-C705-48EB-9D7D-F1520ED379AE@ifi.uio.no> <6CA35516-1E10-4638-9B87-0F6AE2FEE1F1@tzi.org> <5EEF6351-EC39-40A1-8A99-876B53094B08@ifi.uio.no> <2693E1C9-B778-48CD-9790-EEE70DAFDADF@kuehlewind.net> To: Mirja Kuehlewind X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 91.141.3.254 is neither permitted nor denied by domain of ifi.uio.no) client-ip=91.141.3.254; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.113]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69621AAD0C25FC7CF81F47A325C57B2281E0A6D2 Archived-At: Subject: Re: [LOOPS] How important is congestion detection X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 20:29:25 -0000 Yes, and I hope less so with every version. I also hope that we don=E2=80=99t have to design the Internet around BBR now= . Sent from my iPhone > On 30 Jul 2019, at 12:14, Mirja Kuehlewind wrote: >=20 > BRR is ignoring loss (up to some % of loss rate) while it will always reac= t to CE. >=20 >=20 >> On 23. Jul 2019, at 16:45, Spencer Dawkins at IETF wrote: >>=20 >> FWIW,=20 >>=20 >> On Mon, Jul 22, 2019 at 6:51 PM Michael Welzl wrote:= >>=20 >>=20 >>> On Jul 22, 2019, at 6:17 PM, Carsten Bormann wrote: >>>=20 >>> Sorry for typing a message from a heated BOF where I was representing a W= G that needs a specific outcome=E2=80=A6 >>>=20 >>>>> Bob pointed out that some end host implementations today interpret CE a= s definite congestion events, while applying congestion detection to loss si= gnals, so this conversion might be counterproductive. >>>>=20 >>>> The last sentence - I don't understand it (=E2=80=9Cinterpret CE as def= inite=E2=80=A6 while applying detection to loss=E2=80=9D - huh?). What does i= t mean? Or, maybe: what=E2=80=99s the issue here? >>>=20 >>> What I think Bob meant: An end-host noticing a loss might make its own d= etermination (a.k.a. congestion detection) whether that is a reason to slow d= own or not. >>> An end-host getting a CE might simply assume this is indeed congestion, a= nd always slow down. So, CE > loss, and a simple replacement of loss by CE w= orsens throughput. >>=20 >> Ok, thanks! now I understand that the statement is indeed what I thought= , but it still makes zero sense to me. See below: >>=20 >>=20 >>>> I thought the whole point is to signal CE *as a replacement* for the lo= ss that LOOPS repairs. So, then=E2=80=A6 ? >>>=20 >>> If CE > loss, replacing loss by CE is not enough, we need to vet the los= ses via a LOOPS-side congestion detection that is as good as the one as the e= nd-host would do, or (preferably) better. >>=20 >> RFC 3168 says CE =3D loss. RFC 8311 finally allows us to diverge from thi= s rule, which we used in RFC to state: =E2=80=9CCE < loss=E2=80=9D. >> L4S of course also does =E2=80=9CCE < loss=E2=80=9D, albeit in much more e= laborate ways. >>=20 >> However: "CE > loss=E2=80=9D is truly weird to me - perhaps this IS now a= llowed by RFC 8311 :-D but if it=E2=80=99s spec=E2=80=99ed then it must b= e an April 1 RFC. >>=20 >> What am I missing, Bob? >>=20 >> I was hoping CE > loss was a typo, myself. >>=20 >> Spencer >>=20 >>=20 >> Cheers, >> Michael >>=20 >> --=20 >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops >> --=20 >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops >=20 From nobody Tue Jul 30 15:24:29 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3F3120074 for ; Tue, 30 Jul 2019 14:56:46 -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=unavailable 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 NGfTaJSouBvs for ; Tue, 30 Jul 2019 14:56:44 -0700 (PDT) Received: from mail.critical.com (mail.critical.com [209.217.211.166]) by ietfa.amsl.com (Postfix) with ESMTP id E1952120045 for ; Tue, 30 Jul 2019 14:56:43 -0700 (PDT) Received: by mail.critical.com (Postfix, from userid 99) id 55C173801E; Tue, 30 Jul 2019 17:53:46 -0400 (EDT) Received: from www.critical.com (unknown [192.168.6.38]) by mail.critical.com (Postfix) with ESMTP id 5F5C64A19; Tue, 30 Jul 2019 17:53:44 -0400 (EDT) Received: from 172.97.99.187 (SquirrelMail authenticated user cardsw) by www.critical.com with HTTP; Tue, 30 Jul 2019 17:56:40 -0400 Message-ID: <83f8b01280e4fa933d5c423f1c43f69a.squirrel@www.critical.com> In-Reply-To: References: <7b64f9e8-5b8b-6ce6-145d-2c4ccb10c62b@isae-supaero.fr> Date: Tue, 30 Jul 2019 17:56:40 -0400 From: "Stuart William Card" To: loops@ietf.org Cc: nwcrg@irtf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: X-Mailman-Approved-At: Tue, 30 Jul 2019 15:24:28 -0700 Subject: Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 21:56:46 -0000 I realize LOOPS is about neither multicast nor transport, but for likely useful background, I hope interested people will at least briefly renew their acquaintance with, inter alia, RFCs 2357, 3048, 3453, 5740, 6584. > ... > There is a lot of accumulated research, development and implementations > out there :) But ok you are talking to the right people! > ... Marie-Jos Montpetit... -- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) From nobody Wed Jul 31 03:19:21 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E869612008C for ; Wed, 31 Jul 2019 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbwftb10y57o for ; Wed, 31 Jul 2019 03:19:16 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941F7120033 for ; Wed, 31 Jul 2019 03:19:16 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hslhQ-0008Be-59; Wed, 31 Jul 2019 12:19:12 +0200 Received: from 91.141.3.254.wireless.dyn.drei.com ([91.141.3.254] helo=[192.168.1.162]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hslhP-00066d-Ci; Wed, 31 Jul 2019 12:19:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> Date: Wed, 31 Jul 2019 12:19:08 +0200 Cc: Carsten Bormann , loops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <579BEAE9-23E2-4E4F-BA26-6FA7F7C9CF6D@ifi.uio.no> References: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 91.141.3.254 is neither permitted nor denied by domain of ifi.uio.no) client-ip=91.141.3.254; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.162]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E98DC9333C051F5269677B8F7E13D919839FA427 Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 10:19:19 -0000 > On Jul 30, 2019, at 8:21 PM, Wesley Eddy wrote: >=20 > On 7/30/2019 12:30 PM, Carsten Bormann wrote: >>> I skimmed the drafts, but might be missing some context still ... = LOOPS seems like it is intended for =E2=80=9Cdumb" subnetworks, but = could be potentially harmful over "smarter" subnetworks. >> If the path segment already tries to be =E2=80=9Chelpful=E2=80=9D, = there might indeed be an adverse interaction. Or the =E2=80=9Chelp=E2=80=9D= might only be available or effective for certain transport protocols, = and LOOPS can still do something useful for those not (yet!) covered = (for instance, this could be QUIC). Also, the =E2=80=9Chelp=E2=80=9D = might be geared towards close interaction with the transport, and adding = a tunnel layer could interfere with this. So whether running LOOPS on a = Sat PEP is useful in any way or even detrimental depends a lot on how = up-to-date that PEP is. Note that the entity running LOOPS may not be = the entity running the Sat PEP, so it may not have control over the PEP = situation. >>=20 >> Running LOOPS on the path segments from host to Sat and from the Sat = to host can remove the need for some costly (in bandwidth and latency) = retransmissions on the Sat link itself. >>=20 >>> For satellite links, there is the capability to do per-frame = adaptive coding and modulation (based on traffic classification). When = the lower layer offers service tailored for the needs of each packet = already, LOOPS doing something up above is possibly at odds with this. = It=E2=80=99s easy to imagine scenarios where this leads to actual = performance degradation, positive feedback loops, or other problems, so = I'm interested in what people have done or been thinking about in this = regard. >> LOOPS is not meant as pixie dust that you sprinkle indiscriminately = over your network. >> The cost is not entirely trivial and the benefits depend on the = characteristics of both the path and the traffic. >> You should have a reason to use LOOPS. >> See above for some potential reasons to use LOOPS on top of Sat PEPs. >=20 >=20 > You mention PEP a few times, but I didn't mention PEP, but rather the = modulation and coding in satellite modems. The framing and selection of = MODCOD done by a modem is a lower layer function that's not related to = PEP techniques at higher layers. Maybe it=E2=80=99s just me, but I don=E2=80=99t understand the potential = for negative interactions, positive feedback loops etc: LOOPS endpoints will only repair losses that they see; whatever L2 can = repair wouldn=E2=80=99t be seen by them. Similarly, whatever repairing LOOPS does wouldn=E2=80=99t be understood = by L2 devices - in particular if we=E2=80=99re talking about modems and = not PEPs that might try to look a bit deeper into the packets. Cheers, Michael From nobody Wed Jul 31 05:37:07 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1068D1200E6; Wed, 31 Jul 2019 05:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EIyxe7h9GIX; Wed, 31 Jul 2019 05:36:54 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 861C01200D7; Wed, 31 Jul 2019 05:36:54 -0700 (PDT) Received: from [130.209.157.54] (port=17374 helo=glaroam2-179-133.wireless.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hsnqa-0005dJ-0q; Wed, 31 Jul 2019 13:36:52 +0100 From: Colin Perkins Message-Id: <2342D6E9-FF90-4D51-9647-0F7ABDA47268@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_CDB03A42-AA7D-4CC1-9B0A-408D875B0D28" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 31 Jul 2019 13:17:21 +0100 In-Reply-To: Cc: Marie-Jose Montpetit , Magnus Westerlund , "nwcrg@irtf.org" , loops@ietf.org, Mirja Kuehlewind , Carsten Bormann , Suresh Krishnan To: Spencer Dawkins at IETF References: X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 12:36:58 -0000 --Apple-Mail=_CDB03A42-AA7D-4CC1-9B0A-408D875B0D28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF = wrote: >=20 > I'm going to be replying to two or three e-mail in this thread, so = I'll try to be coherent over my replies ....=20 >=20 > On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit = > wrote: > Since most of your questions are related to FEC I copy the nwcrg. See = below >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF = (spencerdawkins.ietf@gmail.com ) = wrote: >=20 >> Hi, Mirja,=20 >>=20 >> On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind > wrote: >> Hi Carsten, hi Spencer, >>=20 >> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF = > = wrote: >> > >> > My impression, and Magnus might say I'm insane, was that Magnus is = right on the edge of whether this work can be chartered without a = second, working group-forming BOF. If the LOOPS community can't live = without host-to-node, the community should add it. If the community can = make use of LOOPS without host-to-node and add it later, the community = might consider whether that reduces the scope of the initial proposed = charter enough to help Magnus approve it :-) >>=20 >> Yes, it would be possible to charter without another BoF a small and = well-scoped group, however, it also would be possible to work on small = and well-defined pieces of work without a new working group. This was = one of the reasons why this was not a non-wg-forming BoF because it is = not clear yet if a new group is needed or the resulting pieces of = standardization work are small enough to fit into an existing group. >>=20 >> Therefore, I really recommend focus on defining the standardising = work items that you think are needed rather than trying to do any = word-smithing of a potential charter (that eventually is not needed). >>=20 >> Thanks for giving me the chance to clarify - I really was talking = about chartering work, not just chartering a working group, but that = wasn't clear from my note. As you said, knowing what the work is, in = more detail, will help you and Magnus know what to do next.=20 >>=20 >> So, my suggestion for the interested community is to nail down >> In order to "do LOOPS", what already exists, that can be used without = changes? >> what already exists, but needs to be extended for LOOPS? >> what needs to be created, because nothing exists that meets the = needs? >> I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a = month before IETF 105), but speaking as someone who hasn't been involved = in depth, I wonder about >> How a sender tunes FEC dynamically - is that automatic, based on FEC = mechanisms people are thinking about, or is there work to do there? >=20 > There are FEC mechanisms to adapt coding dynamically based on = acknowledgments for example. In the QUICK implementation we will have = flag a RECOVERED packet that could be used to adapt the coding rate. = Other implementations or code-specific protocols are also available. >=20 >>=20 >> How a sender knows whether to do FEC, retransmission, or both FEC and = retransmission, dynamically? >=20 > Well the use of FEC (or not) is a design decision. Of course = you need the code (and the libraries). And then the decision will be = based on known link condition, goodput, expected performance, type of = traffic (video, time sensitive etc.). And finding a tunnel and PEPs if = you need to. And it can depend on path statistics and not being end to = end. I am not sure you could standardize that decision. >=20 >=20 > So, speaking with no dots because I don't have any, I agree with what = Marie-Jose is saying here, but my understanding is that LOOPS endpoints = might turn LOOPS off completely if local optimizations aren't needed. So = I'm thinking about how a sender makes that decision, and how a sender = might do trade-offs.=20 >=20 > I think one point in discussions with Marie-Jose might be that she's = thinking in terms of Technical Specifications = (https://tools.ietf.org/html/rfc2026#section-3.1 = ), which are necessary, = but discussions are making me think that proponents might usefully also = think in terms of Applicability Statements = (https://tools.ietf.org/html/rfc2026#section-3.2 = ), which (quoting)=20 >=20 > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a = particular > Internet capability. An AS may specify uses for TSs that are not > Internet Standards, as discussed in Section 7. >=20 > An AS identifies the relevant TSs and the specific way in which = they > are to be combined, and may also specify particular values or = ranges > of TS parameters or subfunctions of a TS protocol that must be > implemented.. An AS also specifies the circumstances in which the = use > of a particular TS is required, recommended, or elective (see = section > 3.3). >=20 > An AS may describe particular methods of using a TS in a restricted > "domain of applicability", such as Internet routers, terminal > servers, Internet systems that interface to Ethernets, or datagram- > based database servers. >=20 > So, if Applicability Statements (also standards-track documents) would = be helpful for LOOPS deployment and operation, the proponents might = think about whether they want to do work in that space.=20 >=20 > If decisions about what senders do turn out to be entirely up to the = sender, that's great, but if the proponents want to bound the possible = behaviors of implementations to improve deployment and operation, that = might also be appropriate in BCPs = (https://tools.ietf.org/html/rfc2026#section-5 = ). > =20 >>=20 >> How a sender knows that it shouldn't be doing anything, because = anything it does won't help ("first, do no harm")? >=20 > Of course in a congested network doing nothing is probably best. = Again there is a lot of work on the interaction of coding and congestion = control. >=20 > Not everyone knows the things but there has been a lot of work = in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the = work was done in a research group not a working group. But real = implementations exist in famous =E2=80=9Cnetworks".=20 >=20 > Right - so one possibility is publishing work from NWCRG in the IETF = stream, and especially standards-track, with appropriate review by the = IETF community. That could take a lot of forms (RGs and WGs can interact = in a lot of different ways).=20 An IETF WG could have a work item to develop a standards track FEC = scheme based on the research previously done in NWCRG, certainly. > Since most of your questions are about erasure coding (coding = for packet loss) is that a direction LOOPS wants to take? Somekind of = nwcWG? >=20 >=20 > See Mirja's note about chartering work, and only chartering working = groups when that's needed. But as you note, the FECFRAME extensions = happened in TSVWG, so that would be a reasonable conversation to have = with TSVWG chairs (and I note that Wes Eddy, who popped up further down = in this thread, is a TSVWG co-chair). If it fits, TSVWG could be a plan. = If it doesn't fit in an existing working group, NWCWG could be a plan. =20= I perhaps misunderstood LOOPS, but I=E2=80=99d assumed that =E2=80=93 to = the extent is uses FEC and not retransmission =E2=80=93 it=E2=80=99d = pull in one of the schemes developed in FECFRAME. Has there been any = requirements analysis to show if anything further is needed? This is separate to the question of whether there's work in NWCRG = that=E2=80=99s ready to move into IETF for standardisation, of course.=20= Colin --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_CDB03A42-AA7D-4CC1-9B0A-408D875B0D28 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On = 30 Jul 2019, at 18:43, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

    I'm going to be replying to two = or three e-mail in this thread, so I'll try to be coherent over my = replies .... 

    On Tue, Jul 30, 2019 at 9:42 AM = Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
    Since = most of your questions are related to FEC I copy the nwcrg. See = <mjm> below

    mjm

    Marie-Jos=C3=A9 = Montpetit, Ph.D.
    Research Affiliate, MIT Media = Laboratory
    mariejose@mjmontpetit.com
    mariejo@mit.edu

    On July 30, 2019 at = 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) wrote:

    Hi, Mirja, 

    On Tue, Jul = 30, 2019 at 5:34 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
    Hi Carsten, hi Spencer,

    > On 25. Jul 2019, at 20:59, Spencer = Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:
    >
    > My impression, and Magnus = might say I'm insane, was that Magnus is right on the edge of whether = this work can be chartered without a second, working group-forming BOF. = If the LOOPS community can't live without host-to-node, the community = should add it. If the community can make use of LOOPS without = host-to-node and add it later, the community might consider whether that = reduces the scope of the initial proposed charter enough to help Magnus = approve it :-)

    Yes, it would be possible to = charter without another BoF a small and well-scoped group, however, it = also would be possible to work on small and well-defined pieces of work = without a new working group. This was one of the reasons why this was = not a non-wg-forming BoF because it is not clear yet if a new group is = needed or the resulting pieces of standardization work are small enough = to fit into an existing group.

    Therefore, I = really recommend focus on defining the standardising work items that you = think are needed rather than trying to do any word-smithing of a = potential charter (that eventually is not needed).

    Thanks for giving me the chance to clarify - I really was = talking about chartering work, not just chartering a working group, but = that wasn't clear from my note. As you said, knowing what the work is, = in more detail, will help you and Magnus know what to do = next. 

    So, = my suggestion for the interested community is to nail down
    1. In order to "do LOOPS", what = already exists, that can be used without changes?
    2. what = already exists, but needs to be extended for LOOPS?
    3. what needs to be created, because nothing exists that meets = the needs?
     I'm not a LOOPS proponent (the ADs asked me to = chair the BOF about a month before IETF 105), but speaking as someone = who hasn't been involved in depth, I wonder about
    1. How a sender tunes FEC = dynamically - is that automatic, based on FEC mechanisms people are = thinking about, or is there work to do = there?
    <mjm> There are FEC mechanisms to adapt coding = dynamically based on acknowledgments for example. In the QUICK = implementation we will have flag a RECOVERED packet that could be used = to adapt the coding rate. Other implementations or code-specific = protocols are also available.


    1. How a = sender knows whether to do FEC, retransmission, or both FEC and = retransmission, = dynamically?

    <mjm> Well the use of FEC (or not) is a design = decision.  Of course you need the code (and the libraries). And = then the decision will be based on known link condition, goodput, = expected performance, type of traffic (video, time sensitive etc.). And = finding a tunnel and PEPs if you need to. And it can depend on path = statistics and not being end to end. I am not sure you could standardize = that decision.


    So, speaking with no dots because I = don't have any, I agree with what Marie-Jose is saying here, but my = understanding is that LOOPS endpoints might turn LOOPS off completely if = local optimizations aren't needed. So I'm thinking about how a sender = makes that decision, and how a sender might do = trade-offs. 

    I think one point in discussions with Marie-Jose might be = that she's thinking in terms of Technical Specifications (https://tools.ietf.org/html/rfc2026#section-3.1), which = are necessary, but discussions are making me think that proponents might = usefully also think in terms of Applicability Statements (https://tools.ietf.org/html/rfc2026#section-3.2), which = (quoting) 

       An Applicability Statement specifies how, and = under what
       circumstances, one or more TSs may = be applied to support a particular
       Internet = capability.  An AS may specify uses for TSs that are not
       Internet Standards, as discussed in Section = 7.

       An AS identifies the = relevant TSs and the specific way in which they
      =  are to be combined, and may also specify particular values or = ranges
       of TS parameters or subfunctions of a = TS protocol that must be
       implemented..  = An AS also specifies the circumstances in which the use
       of a particular TS is required, recommended, or = elective (see section
       3.3).

       An AS may describe particular methods of using a = TS in a restricted
       "domain of applicability", = such as Internet routers, terminal
       servers, = Internet systems that interface to Ethernets, or datagram-
       based database servers.

    So, if Applicability = Statements (also standards-track documents) would be helpful for LOOPS = deployment and operation, the proponents might think about whether they = want to do work in that space. 

    If decisions about what senders do turn = out to be entirely up to the sender, that's great, but if the proponents = want to bound the possible behaviors of implementations to improve = deployment and operation, that might also be appropriate in BCPs (https://tools.ietf.org/html/rfc2026#section-5).
     

    1. How a = sender knows that it shouldn't be doing anything, because anything it = does won't help ("first, do no = harm")?
    <= p class=3D""><mjm> Of course in a congested network doing nothing = is probably best. Again there is a lot of work on the interaction of = coding and congestion control.

    <mjm> Not everyone = knows the things but there has been a lot of work in FECFRAME (in IETF) = and NWCRG. Someone did mention that a lot of the work was done in a = research group not a working group. But real implementations exist in = famous =E2=80=9Cnetworks". 

    Right - so one possibility is publishing work from NWCRG in = the IETF stream, and especially standards-track, with appropriate review = by the IETF community. That could take a lot of forms (RGs and WGs can = interact in a lot of different = ways). 

    An IETF WG could have a work item to develop a = standards track FEC scheme based on the research previously done in = NWCRG, certainly.

    <mjm> Since most of your questions are = about erasure coding (coding for packet loss) is that a direction LOOPS = wants to take? Somekind of nwcWG?


    See Mirja's note about = chartering work, and only chartering working groups when that's needed. = But as you note, the FECFRAME extensions happened in TSVWG, so that = would be a reasonable conversation to have with TSVWG chairs (and I note = that Wes Eddy, who popped up further down in this thread, is a TSVWG = co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in an = existing working group, NWCWG could be a = plan.  

    I perhaps misunderstood LOOPS, but I=E2=80=99d assumed = that =E2=80=93 to the extent is uses FEC and not retransmission =E2=80=93 = it=E2=80=99d pull in one of the schemes developed in FECFRAME. Has there = been any requirements analysis to show if anything further is = needed?

    This is separate to the = question of whether there's work in NWCRG that=E2=80=99s ready to move = into IETF for standardisation, of course. 

    Colin




    -- 
    Colin Perkins
    https://csperkins.org/




    = --Apple-Mail=_CDB03A42-AA7D-4CC1-9B0A-408D875B0D28-- From nobody Wed Jul 31 05:56:13 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77050120128 for ; Wed, 31 Jul 2019 05:56:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRlQD__e1cwn for ; Wed, 31 Jul 2019 05:56:09 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C9784120018 for ; Wed, 31 Jul 2019 05:56:09 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id g20so135969220ioc.12 for ; Wed, 31 Jul 2019 05:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=3pNftcCS2Jznk0buGRjQZn0HQHJeuXY4tfrJ0qNQpLg=; b=s3zKIuPZvt05jsu+1ZfIJKN+5TtITblPIoXAV7vpbJMrLqYtxoViXH8WaBfuj4VVWm OMw2rnXeYKGYKtsrFbXwALn9x8oMfYU/lFVHLCYRP51oy+CXiVJ8YjQwX3mXuaxZ39DL 1nz1ulm64t8NhpqtR81JSZkrnqaH98Gl9gcP9NrNciukyQ8o4sxsg9RJhep9bI48i1KS eN/FzfQqzUZLKe1INiFiHAQX3LBefOIgX1TQWwPeQAH7GQlq2hW0wW9RdOPGBy/2Cg4T e8npf/MOrrNqK2p0h7R7qoduiXwSoBivn7NhhIdNCBE680gaJBQOygyIzZH7Rmx+RuXh RiWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=3pNftcCS2Jznk0buGRjQZn0HQHJeuXY4tfrJ0qNQpLg=; b=KSs7TYO9yveVIvsnX9uFV9mIS/+ld0SD7SajU00EDl7yuFNmUwLSjTHzt0X14+R8Rv lwJjiXzsa7VMdrssnwyc7J2TMPZz2oB1+1hIUCwv8Sk41gtAa2WfMuXYBBjGVAaDBagX gJCUstVsGuHxkye7CdrCH3ufh2ZdWFZpU5lJ53tt0XdAv/Z1QCTCPh9/jj9u8Lwn21ZZ 9Fd1Q52jCEUFpy5YpytCgQakzKE+XtuO5mY6xmpsz9NDU8G/c6VtUC5gksEwmAK0O/i/ w8TMBnMlI2QTmPTfnE80jt99ebdmeONLTygP1OfdSlvI9jSQy00CLHTv8LqjBx4GiWRp sMCQ== X-Gm-Message-State: APjAAAXd6jyTl2HDZw3UjW8ydpWNRYDw47IW+y3frpcsAVoJ1nP5mcj+ 4GxVF12PWq8lj/q1OamwAB67Fb3d X-Google-Smtp-Source: APXvYqzURT+Er0fVDTSwrjDwq7FNbeDHSdul5zo22eA2C08kOW4nA/hP/K8loI4hLQDt8xGumXT2dw== X-Received: by 2002:a5e:9404:: with SMTP id q4mr51973121ioj.46.1564577768897; Wed, 31 Jul 2019 05:56:08 -0700 (PDT) Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id n21sm48237436ioh.30.2019.07.31.05.56.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 05:56:08 -0700 (PDT) To: Michael Welzl Cc: Carsten Bormann , loops@ietf.org References: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> <579BEAE9-23E2-4E4F-BA26-6FA7F7C9CF6D@ifi.uio.no> From: Wesley Eddy Message-ID: <3d808274-38d7-98eb-42b7-875f2f840f29@mti-systems.com> Date: Wed, 31 Jul 2019 08:56:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <579BEAE9-23E2-4E4F-BA26-6FA7F7C9CF6D@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 12:56:12 -0000 On 7/31/2019 6:19 AM, Michael Welzl wrote: > Maybe it’s just me, but I don’t understand the potential for negative interactions, positive feedback loops etc: > > LOOPS endpoints will only repair losses that they see; whatever L2 can repair wouldn’t be seen by them. > Similarly, whatever repairing LOOPS does wouldn’t be understood by L2 devices - in particular if we’re talking about modems and not PEPs that might try to look a bit deeper into the packets. > I think some of it may depend on what LOOPS sees and acts on (aggregate of flows or per-flow information), since some flows may be treated entirely differently by the lower layer, and may be okay (or even desire) different treatment. In LOOPS tunneling, do different traffic classes wind up in different tunnels, or are they all lumped into the same tunnel? From nobody Wed Jul 31 06:18:59 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D5F120121 for ; Wed, 31 Jul 2019 06:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Y0Vug3D3fvA1 for ; Wed, 31 Jul 2019 06:18:47 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 83F2D120020 for ; Wed, 31 Jul 2019 06:18:46 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id m23so65497277lje.12 for ; Wed, 31 Jul 2019 06:18: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=ixFnhJ/E1YNryVNYjGUqDies+aKMqQu5TkVqeNHA1mM=; b=MKWy6N0pLuFMbVYYYcBWi+4bPRM0UojlvCSACGupHaH25S3SOPogiqB4tbjQK+lHBH ZwVRCNRV/K2eeR63CveHhMgYToCv6KOCeRuh57TJdpC/4rIguibMBQ8iQVEm/g4PiaJf FjLZ2i0YvUOuf5QsgOZPq7sfKoi8aecIOBsVVdTmJTFMaPS9unp5IwhNRpgluOkH0qda O4KMcL+1vSbUf9Yj3VcaStWcUqXdXH4v2J+TvM73luyF1/LXAW6eKeFvOwmBH8Sw+dkH vc2Q6BUAFtYYBZ01LbrPLid6nr1u5QAwkanumELXFVjHqR7c7IYeyYxmZ2XRP1mBZzwE Hg1w== 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=ixFnhJ/E1YNryVNYjGUqDies+aKMqQu5TkVqeNHA1mM=; b=IigzVgJf4AE26923aQhwODRmRIKA+UXoAfStlBRMbztDLDT8RnTrKVH4TFpLGhQip6 ZdLmNXuJmPLPttPlrrBdHyQtpVGelbTA1yWkDnU1dk3wE3HQnv26b7CnuHNM4EU9lWJa sc/NIcLOx2v2fzLyg+wWYGvb4NzEUV2a6svI3hgyHf4zziGGzk4D3+j44rRjr+OQha6w xhdcbrDIMb4jEZmZY1TXx/FwNV4l0vjFPLVr9F7rCTR6Ne31FiLcSmX8fR8yXZKZp0cD +uzIzFkLl97TKX82BVqGZHO0huQK3VAPn9j7+NdnuxEmIvHDjA2bjD3ZislrV1cDxc1U hfcw== X-Gm-Message-State: APjAAAUG3iUnc1DelRsUmHdoq0oUvKJw0dDfOSpBoCJGCmZFC8e624Ur If07jupTtA1D4vDv59l0Gj9EZm5uUPdQs0Rn4AI= X-Google-Smtp-Source: APXvYqwqD9SeuAMPnPLjkn7lvYS2o7eRBvPHMHAGin72MgnpOfVEOTj6TqvlZyZuf9OsyQMA+HYUQBKF2ANcHfmaaGY= X-Received: by 2002:a2e:8696:: with SMTP id l22mr379210lji.201.1564579124659; Wed, 31 Jul 2019 06:18:44 -0700 (PDT) MIME-Version: 1.0 References: <2342D6E9-FF90-4D51-9647-0F7ABDA47268@csperkins.org> In-Reply-To: <2342D6E9-FF90-4D51-9647-0F7ABDA47268@csperkins.org> From: Spencer Dawkins at IETF Date: Wed, 31 Jul 2019 08:18:32 -0500 Message-ID: To: Colin Perkins Cc: Marie-Jose Montpetit , Magnus Westerlund , "nwcrg@irtf.org" , loops@ietf.org, Mirja Kuehlewind , Carsten Bormann , Suresh Krishnan Content-Type: multipart/alternative; boundary="000000000000f2c846058ef9f6a0" Archived-At: Subject: Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:18:50 -0000 --000000000000f2c846058ef9f6a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Colin, On Wed, Jul 31, 2019, 07:36 Colin Perkins wrote: > On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > I'm going to be replying to two or three e-mail in this thread, so I'll > try to be coherent over my replies .... > > On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit < > marie@mjmontpetit.com> wrote: > >> Since most of your questions are related to FEC I copy the nwcrg. See >> below >> >> mjm >> >> Marie-Jos=C3=A9 Montpetit, Ph.D. >> Research Affiliate, MIT Media Laboratory >> mariejose@mjmontpetit.com >> mariejo@mit.edu >> >> On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF ( >> spencerdawkins.ietf@gmail.com) wrote: >> >> Hi, Mirja, >> >> On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind >> wrote: >> >>> Hi Carsten, hi Spencer, >>> >>> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> > >>> > My impression, and Magnus might say I'm insane, was that Magnus is >>> right on the edge of whether this work can be chartered without a secon= d, >>> working group-forming BOF. If the LOOPS community can't live without >>> host-to-node, the community should add it. If the community can make us= e of >>> LOOPS without host-to-node and add it later, the community might consid= er >>> whether that reduces the scope of the initial proposed charter enough t= o >>> help Magnus approve it :-) >>> >>> Yes, it would be possible to charter without another BoF a small and >>> well-scoped group, however, it also would be possible to work on small = and >>> well-defined pieces of work without a new working group. This was one o= f >>> the reasons why this was not a non-wg-forming BoF because it is not cle= ar >>> yet if a new group is needed or the resulting pieces of standardization >>> work are small enough to fit into an existing group. >>> >>> Therefore, I really recommend focus on defining the standardising work >>> items that you think are needed rather than trying to do any word-smith= ing >>> of a potential charter (that eventually is not needed). >>> >> >> Thanks for giving me the chance to clarify - I really was talking about >> chartering work, not just chartering a working group, but that wasn't cl= ear >> from my note. As you said, knowing what the work is, in more detail, wil= l >> help you and Magnus know what to do next. >> >> So, my suggestion for the interested community is to nail down >> >> 1. In order to "do LOOPS", what already exists, that can be used >> without changes? >> 2. what already exists, but needs to be extended for LOOPS? >> 3. what needs to be created, because nothing exists that meets the >> needs? >> >> I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a >> month before IETF 105), but speaking as someone who hasn't been involved= in >> depth, I wonder about >> >> 1. How a sender tunes FEC dynamically - is that automatic, based on >> FEC mechanisms people are thinking about, or is there work to do ther= e? >> >> There are FEC mechanisms to adapt coding dynamically based on >> acknowledgments for example. In the QUICK implementation we will have fl= ag >> a RECOVERED packet that could be used to adapt the coding rate. Other >> implementations or code-specific protocols are also available. >> >> >> 1. >> How a sender knows whether to do FEC, retransmission, or both FEC and >> retransmission, dynamically? >> >> Well the use of FEC (or not) is a design decision. Of course you >> need the code (and the libraries). And then the decision will be based o= n >> known link condition, goodput, expected performance, type of traffic >> (video, time sensitive etc.). And finding a tunnel and PEPs if you need = to. >> And it can depend on path statistics and not being end to end. I am not >> sure you could standardize that decision. >> > > So, speaking with no dots because I don't have any, I agree with what > Marie-Jose is saying here, but my understanding is that LOOPS endpoints > might turn LOOPS off completely if local optimizations aren't needed. So > I'm thinking about how a sender makes that decision, and how a sender mig= ht > do trade-offs. > > I think one point in discussions with Marie-Jose might be that she's > thinking in terms of Technical Specifications ( > https://tools.ietf.org/html/rfc2026#section-3.1), which are necessary, > but discussions are making me think that proponents might usefully also > think in terms of Applicability Statements ( > https://tools.ietf.org/html/rfc2026#section-3.2), which (quoting) > > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a particular > Internet capability. An AS may specify uses for TSs that are not > Internet Standards, as discussed in Section 7. > > An AS identifies the relevant TSs and the specific way in which they > are to be combined, and may also specify particular values or ranges > of TS parameters or subfunctions of a TS protocol that must be > implemented.. An AS also specifies the circumstances in which the use > of a particular TS is required, recommended, or elective (see section > 3.3). > > An AS may describe particular methods of using a TS in a restricted > "domain of applicability", such as Internet routers, terminal > servers, Internet systems that interface to Ethernets, or datagram- > based database servers. > > So, if Applicability Statements (also standards-track documents) would be > helpful for LOOPS deployment and operation, the proponents might think > about whether they want to do work in that space. > > If decisions about what senders do turn out to be entirely up to the > sender, that's great, but if the proponents want to bound the possible > behaviors of implementations to improve deployment and operation, that > might also be appropriate in BCPs ( > https://tools.ietf.org/html/rfc2026#section-5). > > >> >> 1. >> How a sender knows that it shouldn't be doing anything, because >> anything it does won't help ("first, do no harm")? >> >> Of course in a congested network doing nothing is probably best. >> Again there is a lot of work on the interaction of coding and congestion >> control. >> >> Not everyone knows the things but there has been a lot of work in >> FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the work >> was done in a research group not a working group. But real implementatio= ns >> exist in famous =E2=80=9Cnetworks". >> > Right - so one possibility is publishing work from NWCRG in the IETF > stream, and especially standards-track, with appropriate review by the IE= TF > community. That could take a lot of forms (RGs and WGs can interact in a > lot of different ways). > > > An IETF WG could have a work item to develop a standards track FEC scheme > based on the research previously done in NWCRG, certainly. > > Since most of your questions are about erasure coding (coding for >> packet loss) is that a direction LOOPS wants to take? Somekind of nwcWG? >> > > See Mirja's note about chartering work, and only chartering working group= s > when that's needed. But as you note, the FECFRAME extensions happened in > TSVWG, so that would be a reasonable conversation to have with TSVWG chai= rs > (and I note that Wes Eddy, who popped up further down in this thread, is = a > TSVWG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in = an > existing working group, NWCWG could be a plan. > > > I perhaps misunderstood LOOPS, but I=E2=80=99d assumed that =E2=80=93 to = the extent is > uses FEC and not retransmission =E2=80=93 it=E2=80=99d pull in one of the= schemes developed > in FECFRAME. Has there been any requirements analysis to show if anything > further is needed? > That's the analysis that I'm suggesting the proponents work on now. I didn't talk to all the proponents in Montreal, but at least a couple were pretty sure they wanted to use FEC, but were still figuring out details on that usage. Marie-Jose and some other nice people from NWCRG are providing pointers to help with that analysis. For which, I'm grateful. I was the responsible AD for the recent sliding window FECFRAME extensions that migrated through TSVWG, and I understand FECFRAME at a 10,000-meter level, but the proponents (and interested parties) need to work through the next level of details. This is separate to the question of whether there's work in NWCRG that=E2= =80=99s > ready to move into IETF for standardisation, of course. > The nice thing about the existing relationship between NWCRG and TSVWG is that if there's more stuff from NWCRG that's ready to standardize in the IETF, we know how to do that, and Wes Eddy (one of the TSVWG co-chairs) is already helping with congestion discussion on this mailing list. I think the non-working group-forming BOF did a good job at flushing out the questions and the resources needed to answer them. Thanks, Magnus and Mirja, for making that easy. Spencer Colin > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --000000000000f2c846058ef9f6a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Colin,

    On Wed, Jul 31, 2019, 07:36 Colin Perkins &l= t;csp@csperkins.org> wrote:
    =
    On 30 Jul 20= 19, at 18:43, Spencer Dawkins at IETF <spencerdawkins.ietf@gm= ail.com> wrote:

    I'm going to be re= plying to two or three e-mail in this thread, so I'll try to be coheren= t over my replies ....=C2=A0

    On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Mo= ntpetit <marie@mjmontpetit.com> wrote:
    Since most of your questions are related to FEC I = copy the nwcrg. See <mjm> below

    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    R= esearch Affiliate, MIT Media Laboratory

    On July 30, 2019 at = 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.= com) wrote:

    =
    Hi, Mirja,=C2=A0
    On Tue, J= ul 30, 2019 at 5:34 AM Mirja Kuehlewind <ietf@kuehlewind.net> wr= ote:
    Hi Carsten,= hi Spencer,

    > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF= <spencerdawkins.ietf@gmail.com> wrote:
    >
    >= ; My impression, and Magnus might say I'm insane, was that Magnus is ri= ght on the edge of whether this work can be chartered without a second, wor= king group-forming BOF. If the LOOPS community can't live without host-= to-node, the community should add it. If the community can make use of LOOP= S without host-to-node and add it later, the community might consider wheth= er that reduces the scope of the initial proposed charter enough to help Ma= gnus approve it :-)

    Yes, it would be possible to charter without ano= ther BoF a small and well-scoped group, however, it also would be possible = to work on small and well-defined pieces of work without a new working grou= p. This was one of the reasons why this was not a non-wg-forming BoF becaus= e it is not clear yet if a new group is needed or the resulting pieces of s= tandardization work are small enough to fit into an existing group.

    = Therefore, I really recommend focus on defining the standardising work item= s that you think are needed rather than trying to do any word-smithing of a= potential charter (that eventually is not needed).
    Thanks for giving me the chance to clarify - I really was talk= ing about chartering work, not just chartering a working group, but that wa= sn't clear from my note. As you said, knowing what the work is, in more= detail, will help you and Magnus know what to do next.=C2=A0
    So, my suggestion for the interested community is to nail down<= /div>
    1. In order to "do LOOPS", what already exists, th= at can be used without changes?
    2. what already exists, but needs to b= e extended for LOOPS?
    3. what needs to be created, because nothing exi= sts that meets the needs?
    =C2=A0I'm not a LOOPS proponent (the= ADs asked me to chair the BOF about a month before IETF 105), but speaking= as someone who hasn't been involved in depth, I wonder about
    =
    1. How a sender tunes FEC dynamically - is that automatic, based = on FEC mechanisms people are thinking about, or is there work to do there?<= /li>

    <mjm= > There are FEC mechanisms to adapt coding dynamically based on acknowle= dgments for example. In the QUICK implementation we will have flag a RECOVE= RED packet that could be used to adapt the coding rate. Other implementatio= ns or code-specific protocols are also available.


    1. How a sender knows whether to do FEC, = retransmission, or both FEC and retransmission, dynamically?

    <mjm> Well the = use of FEC (or not) is a design decision.=C2=A0 Of course you need the code= (and the libraries). And then the decision will be based on known link con= dition, goodput, expected performance, type of traffic (video, time sensiti= ve etc.). And finding a tunnel and PEPs if you need to. And it can depend o= n path statistics and not being end to end. I am not sure you could standar= dize that decision.


    So, spe= aking with no dots because I don't have any, I agree with what Marie-Jo= se is saying here, but my understanding is that LOOPS endpoints might turn = LOOPS off completely if local optimizations aren't needed. So I'm t= hinking about how a sender makes that decision, and how a sender might do t= rade-offs.=C2=A0

    I think one point in discussions = with Marie-Jose might be that she's thinking in terms of Technical Spec= ifications (https://tools.ietf.org/html/rfc2026#secti= on-3.1), which are necessary, but discussions are making me think that = proponents might usefully also think in terms of Applicability Statements (= https://tools.ietf.org/html/rfc2026#section-3.2),= which (quoting)=C2=A0

    =C2=A0 =C2=A0An Applicabili= ty Statement specifies how, and under what
    =C2=A0 =C2=A0circumstances, o= ne or more TSs may be applied to support a particular
    =C2=A0 =C2=A0Inter= net capability.=C2=A0 An AS may specify uses for TSs that are not
    =C2=A0= =C2=A0Internet Standards, as discussed in Section 7.

    =C2=A0 =C2=A0A= n AS identifies the relevant TSs and the specific way in which they
    =C2= =A0 =C2=A0are to be combined, and may also specify particular values or ran= ges
    =C2=A0 =C2=A0of TS parameters or subfunctions of a TS protocol that = must be
    =C2=A0 =C2=A0implemented..=C2=A0 An AS also specifies the circum= stances in which the use
    =C2=A0 =C2=A0of a particular TS is required, re= commended, or elective (see section
    =C2=A0 =C2=A03.3).

    =C2=A0 =C2= =A0An AS may describe particular methods of using a TS in a restricted
    = =C2=A0 =C2=A0"domain of applicability", such as Internet routers,= terminal
    =C2=A0 =C2=A0servers, Internet systems that interface to Ether= nets, or datagram-
    =C2=A0 =C2=A0based database servers.
    So, if Applicability Statements (also standards-track document= s) would be helpful for LOOPS deployment and operation, the proponents migh= t think about whether they want to do work in that space.=C2=A0
    <= br>
    If decisions about what senders do turn out to be entirely up= to the sender, that's great, but if the proponents want to bound the p= ossible behaviors of implementations to improve deployment and operation, t= hat might also be appropriate in BCPs (https://tools.ie= tf.org/html/rfc2026#section-5).
    =C2=A0

    1. How a sender knows that it shouldn't be doin= g anything, because anything it does won't help ("first, do no har= m")?
    =

    <mjm> Of course in a congested network doing nothing is probably b= est. Again there is a lot of work on the interaction of coding and congesti= on control.

    <mjm> Not everyone knows the things but there has b= een a lot of work in FECFRAME (in IETF) and NWCRG. Someone did mention that= a lot of the work was done in a research group not a working group. But re= al implementations exist in famous =E2=80=9Cnetworks".=C2=A0

    =
    Right - so one possibility is publishing work= from NWCRG in the IETF stream, and especially standards-track, with approp= riate review by the IETF community. That could take a lot of forms (RGs and= WGs can interact in a lot of different ways).=C2=A0

    An IETF WG could have a work item to develop a= standards track FEC scheme based on the research previously done in NWCRG,= certainly.

    <mjm> Since most of your questions are about erasure coding= (coding for packet loss) is that a direction LOOPS wants to take? Somekind= of nwcWG?


    See Mirja&= #39;s note about chartering work, and only chartering working groups when t= hat's needed. But as you note, the FECFRAME extensions happened in TSVW= G, so that would be a reasonable conversation to have with TSVWG chairs (an= d I note that Wes Eddy, who popped up further down in this thread, is a TSV= WG co-chair). If it fits, TSVWG could be a plan. If it doesn't fit in a= n existing working group, NWCWG could be a plan.=C2=A0=C2=A0

    I perhaps misunderstood LOOPS, but I= =E2=80=99d assumed that =E2=80=93 to the extent is uses FEC and not retrans= mission =E2=80=93 it=E2=80=99d pull in one of the schemes developed in FECF= RAME. Has there been any requirements analysis to show if anything further = is needed?

    =
    That's the analysis that I'm suggesting the propo= nents work on now. I didn't talk to all the proponents in Montreal, but= at least a couple were pretty sure they wanted to use FEC, but were still = figuring out details on that usage.=C2=A0

    =
    Marie-Jose and some other nice people from NWCRG are prov= iding pointers to help with that analysis. For which, I'm grateful. I w= as the responsible AD for the recent sliding window FECFRAME extensions tha= t migrated through TSVWG, and I understand FECFRAME at a 10,000-meter level= , but the proponents (and interested parties) need to work through the next= level of details.

    This is separate to the que= stion of whether there's work in NWCRG that=E2=80=99s ready to move int= o IETF for standardisation, of course.=C2=A0

    The nice thing abou= t the existing relationship between NWCRG and TSVWG is that if there's = more stuff from NWCRG that's ready to standardize in the IETF, we know = how to do that, and Wes Eddy (one of the TSVWG co-chairs) is already helpin= g with congestion discussion on this mailing list.
    <= br>
    I think the non-working group-forming BOF did a = good job at flushing out the questions and the resources needed to answer t= hem. Thanks, Magnus and Mirja, for making that easy.

    Spencer

    Colin




    --=C2=A0
    Colin Perkins
    https://csperkins.org/




    --000000000000f2c846058ef9f6a0-- From nobody Wed Jul 31 06:33:09 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C77120020 for ; Wed, 31 Jul 2019 06:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RBIAa7qhCIHt for ; Wed, 31 Jul 2019 06:33:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545AB120018 for ; Wed, 31 Jul 2019 06:33:06 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45zDrc3KmYzysD; Wed, 31 Jul 2019 15:33:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <3d808274-38d7-98eb-42b7-875f2f840f29@mti-systems.com> Date: Wed, 31 Jul 2019 15:33:03 +0200 Cc: Michael Welzl , loops@ietf.org X-Mao-Original-Outgoing-Id: 586272777.395498-14b8599b1f46a8c38333c98677589103 Content-Transfer-Encoding: quoted-printable Message-Id: References: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org> <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com> <579BEAE9-23E2-4E4F-BA26-6FA7F7C9CF6D@ifi.uio.no> <3d808274-38d7-98eb-42b7-875f2f840f29@mti-systems.com> To: Wesley Eddy X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:33:08 -0000 On Jul 31, 2019, at 14:56, Wesley Eddy wrote: >=20 > In LOOPS tunneling, do different traffic classes wind up in different = tunnels, or are they all lumped into the same tunnel? That depends entirely on the tunnel setup, which is out of scope of = LOOPS itself. A network operator typically will select the traffic that will receive = the (relatively speaking, more expensive) LOOPS treatment. In a = host-to-node scenario (that was stressed to be important at the BOF), = there may be sufficient explicit configuration to do this as well, or it = may be a catch-all. So LOOPS is meant to operate on an aggregate, not just a finely sliced = piece of traffic (or a single flow). I=E2=80=99m not aware of proposals to have the LOOPS protocol itself = handle different classes differently. However, the actual = retransmission decision has some room for adding (unilateral) secret = sauce, and that may include looking at the class. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 31 06:55:33 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4505C120128 for ; Wed, 31 Jul 2019 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ozqFLHvVgS0g for ; Wed, 31 Jul 2019 06:55:23 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E39120227 for ; Wed, 31 Jul 2019 06:55:22 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 45zFLK17Gxz10Gx; Wed, 31 Jul 2019 15:55:21 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45zFLK0YSKzyQR; Wed, 31 Jul 2019 15:55:21 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 15:55:20 +0200 From: To: Spencer Dawkins at IETF CC: Magnus Westerlund , Mirja Kuehlewind , "loops@ietf.org" , Suresh Krishnan Thread-Topic: [LOOPS] BOF co-chairs thinking on LOOPS next steps Thread-Index: AQHVQjQEpZ4+gLxtik2FBkQ64rVAdqbaKsSAgAAKdACAAG+BgIAA620AgAk25qA= Date: Wed, 31 Jul 2019 13:55:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330312ECCEBOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:55:31 -0000 --_000_787AE7BB302AE849A7480A190F8B9330312ECCEBOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwgYWxsLA0KDQpJIHdvdWxkIHJlc3RyaWN0IHRoZSBob3N0LXRvLW5ldHdvcmsg aW50ZXJhY3Rpb24gdG8gdGhlIG1pbmltdW0gKHJlYWQgRUNOKSBpbiB0aGUgaW5pdGlhbCBzY29w ZSBvZiB0aGUgdGhpcyBwcm9wb3NlZCB3b3JrLiBGV0lXLCBiZWxvdyBhIHRlbnRhdGl2ZSBzY29w ZSB3ZSBpbmNsdWRlZCBpbiB0aGUgdXNlLWNhc2VzIEktRDoNCg0KPT09PT09PT09DQogICBpbnZl c3RpZ2F0ZSB0byB3aGF0IGV4dGVudCBhIG5ldHdvcmstYXNzaXN0ZWQgYXBwcm9hY2ggY2FuIGNv bnRyaWJ1dGUNCiAgIHRvIGluY3JlYXNlIHRoZSBvdmVyYWxsIHBlcmNlaXZlZCBxdWFsaXR5IG9m IGV4cGVyaWVuY2UgaW4gc3BlY2lmaWMNCiAgIHNpdHVhdGlvbnMgKGUuZy4sIFNlY3Rpb25zIDMu NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktdHN2d2ctbG9vcHMtcHJvYmxl bS1vcHBvcnR1bml0aWVzLTAzI3NlY3Rpb24tMy41PiBhbmQgMy42PGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMtMDMj c2VjdGlvbi0zLjY+IG9mIFtSRkM4NTE3PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NTE3Pl0pIHdpdGhvdXQNCiAgIHJlcXVpcmluZyBhY2Nlc3MgdG8gaW50ZXJuYWwgdHJhbnNwb3J0 IHByaW1pdGl2ZXMuICBUaGUgcmF0aW9uYWxlDQogICBiZW5lYXRoIHRoaXMgYXBwcm9hY2ggaXMg dGhhdCBzb21lIGluZm9ybWF0aW9uIChsb3NzIGRldGVjdGlvbiwNCiAgIGJldHRlciB2aXNpYmls aXR5IG9uIGF2YWlsYWJsZSBwYXRocyBhbmQgdGhlaXIgY2hhcmFjdGVyaXN0aWNzLCBldGMuKQ0K ICAgY2FuIGJlIHVzZWQgdG8gdHJpZ2dlciBsb2NhbCBhY3Rpb25zIHdoaWxlIGF2b2lkaW5nIGFz IG11Y2ggYXMNCiAgIHBvc3NpYmxlIHVuZGVzaXJlZCBzaWRlIGVmZmVjdHMgKGUuZy4sIGV4cG9z ZSBhIGJlaGF2aW9yIHRoYXQgd291bGQNCiAgIGJlIGludGVycHJldGVkIGJ5IGFuIGVuZHBvaW50 IGFzIGFuIGFub21hbHkgKGNvcnJ1cHQgZGF0YSkgYW5kIHdoaWNoDQogICB3b3VsZCBsZWFkIHRv IGV4YWNlcmJhdGUgZW5kLXRvLWVuZCByZWNvdmVyeS4gIFN1Y2ggbG9jYWwgYWN0aW9ucw0KICAg d291bGQgaGF2ZSBhIGZhc3RlciBlZmZlY3QgKGUuZy4sIGZhc3RlciByZWNvdmVyeSwgdXNlZCBt dWx0aXBsZQ0KICAgcGF0aHMgc2ltdWx0YW5lb3VzbHkpLg0KDQogICBUbyB0aGF0IGFpbSwgdGhl IHdvcmsgaXMgc3RydWN0dXJlZCBpbnRvIHR3byAoMikgcGhhc2VkIHN0YWdlczoNCg0KICAgbyAg U3RhZ2UgMTogTmV0d29yay1hc3Npc3RlZCBvcHRpbWl6YXRpb24uICBUaGlzIG9uZSBhc3N1bWVz IHRoYXQNCiAgICAgIG9wdGltaXphdGlvbnMgKGUuZy4sIHN1cHBvcnQgbGF0ZW5jeS1zZW5zaXRp dmUgYXBwbGljYXRpb25zKSBjYW4NCiAgICAgIGJlIGltcGxlbWVudGVkIGF0IHRoZSBuZXR3b3Jr IHdpdGhvdXQgcmVxdWlyaW5nIGRlZmluaW5nIG5ldw0KICAgICAgaW50ZXJhY3Rpb24gd2l0aCB0 aGUgZW5kcG9pbnQuICBFeGlzdGluZyB0b29scyBzdWNoIGFzIEVDTiB3aWxsIGJlDQogICAgICB1 c2VkLiAgU29tZSBvZiB0aGVzZSBvcHRpbWl6YXRpb25zIG1heSBiZSB2YWx1YWJsZSBpbiBkZXBs b3ltZW50cw0KICAgICAgd2hlcmUgY29tbXVuaWNhdGlvbnMgYXJlIGVzdGFibGlzaGVkIG92ZXIg cGF0aHMgdGhhdCBhcmUgbm90DQogICAgICBleHBvc2luZyB0aGUgc2FtZSBwZXJmb3JtYW5jZSBj aGFyYWN0ZXJpc3RpY3MuDQoNCiAgIG8gIFN0YWdlIDI6IENvbGxhYm9yYXRpdmUgbmV0d29ya2lu ZyBvcHRpbWl6YXRpb24uICBUaGlzIG9uZSByZXF1aXJlcw0KICAgICAgbW9yZSBpbnRlcmFjdGlv biBiZXR3ZWVuIHRoZSBuZXR3b3JrIGFuZCBhbiBlbmRwb2ludCB0byBpbXBsZW1lbnQNCiAgICAg IGNvb3JkaW5hdGVkIGFuZCBtb3JlIHN1cmdpY2FsIG5ldHdvcmstYXNzaXN0ZWQgb3B0aW1pemF0 aW9ucyBiYXNlZA0KICAgICAgb24gaW5mb3JtYXRpb24vaW5zdHJ1Y3Rpb25zIHNoYXJlZCBieSBh biBlbmRwb2ludCBvciBzaGFyaW5nDQogICAgICBsb2NhbGx5LXZpc2libGUgaW5mb3JtYXRpb24g d2l0aCBlbmRwb2ludCBmb3IgYmV0dGVyIGFuZCBmYXN0ZXINCiAgICAgIHJlY292ZXJ5Lg0KDQog ICBFZmZvcnQgcmVsYXRlZCB0byB0aGUNCiAgIHNlY29uZCBzdGFnZSBpcyBvdXQgb2Ygc2NvcGUg b2YgdGhlIGluaXRpYWwgcGxhbm5lZCB3b3JrLg0KICAgTmV2ZXJ0aGVsZXNzLCBmdXR1cmUgd29y ayB3aWxsIGJlIHBsYW5uZWQgb25jZSBwcm9ncmVzcyBpcw0KICAgKGhvcGVmdWxseSkgbWFkZSBv biB0aGUgZmlyc3Qgc3RhZ2UuDQo9PT09PQ0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBMT09QUyBb bWFpbHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3BlbmNlciBEYXdr aW5zIGF0IElFVEYNCkVudm95w6kgOiBqZXVkaSAyNSBqdWlsbGV0IDIwMTkgMjA6NTkNCsOAIDog Q2Fyc3RlbiBCb3JtYW5uDQpDYyA6IE1hZ251cyBXZXN0ZXJsdW5kOyBNYXJpZS1Kb3NlIE1vbnRw ZXRpdDsgTWlyamEgS3VlaGxld2luZDsgbG9vcHNAaWV0Zi5vcmc7IFN1cmVzaCBLcmlzaG5hbg0K T2JqZXQgOiBSZTogW0xPT1BTXSBCT0YgY28tY2hhaXJzIHRoaW5raW5nIG9uIExPT1BTIG5leHQg c3RlcHMNCg0KU3RpbGwgd2VhcmluZyBubyBoYXRzLCBiZWNhdXNlIEkgbm8gbG9uZ2VyIGhhdmUg YW55IGRvdHMgLi4uDQoNCk9uIFRodSwgSnVsIDI1LCAyMDE5IGF0IDEyOjU2IEFNIENhcnN0ZW4g Qm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCk9uIEp1 bCAyNCwgMjAxOSwgYXQgMTg6MTcsIE1hcmllLUpvc2UgTW9udHBldGl0IDxtYXJpZUBtam1vbnRw ZXRpdC5jb208bWFpbHRvOm1hcmllQG1qbW9udHBldGl0LmNvbT4+IHdyb3RlOg0KPg0KPiBTdGFu ZGFyZGlzYXRpb24gb2Ygd2hhdD8gVGhlIGFyY2hpdGVjdHVyZT8gVGhlIHByb3RvY29scyAoYmV3 YXJlIHRoZXJlIGlzIGFscmVhZHkgRkVDRlJBTUUgYW5kIG90aGVycyk/IFRoZSBwcm94aWVzPw0K DQpIaSBNYXJpZS1Kb3PDqSwNCg0KZGV0YWlscyBvZiB0aGUgdGhpbmtpbmcgdGhhdCB3YXMgZGV2 ZWxvcGVkIGluIHRoZSBzaWRlIG1lZXRpbmdzIHRoYXQgaGFwcGVuZWQgYXQgdGhlIHByZXZpb3Vz IHR3byBJRVRGIG1lZXRpbmdzIGNhbiBiZSBmb3VuZCBhdA0KDQpodHRwczovL2dpdGh1Yi5jb20v bG9vcHMtd2cvY2hhcnRlcg0KDQpUaGUgQk9GIGFjdHVhbGx5IGFkZGVkIG9uZSBwaWVjZSBvZiBp bmZvcm1hdGlvbiBJIGRpZG7igJl0IHByZXZpb3VzbHkgcGVyY2VpdmUgdGhhdCB3YXk6DQpQZW9w bGUgc2VlbSB0byByZWFsbHkgd2FudCB0byB0YWNrbGUgdGhlIGhvc3QtdG8tbm9kZSBjYXNlIChh cyBuZWVkZWQsIGUuZy4sIGZvciBnb2luZyB0aHJvdWdoIFdpRmkgYWNjZXNzIGNsb3Vkcykgcmln aHQgYXdheSwgbm90IGp1c3QgdGhlIGluLW5ldHdvcmsgKG5vZGUtdG8tbm9kZSkgY2FzZS4gIFRo YXQgd291bGQgYmUgdGhlIG9uZSB0aGluZyBJIHdvdWxkIGNoYW5nZSBiYXNlZCBvbiBteSByZWNv bGxlY3Rpb24gb2YgdGhlIEJPRi4gIEJ1dCBvZiBjb3Vyc2UgdGhlcmUgbWF5IGJlIG90aGVyIHRo aW5nczsgaXQgbWF5IGJlIHdvcnRoIHRvIG5vdyBoYXZlIGFub3RoZXIgcm91bmQgb2YgZGlzY3Vz c2lvbiBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlci4NCg0KQ29tbXVuaWNhdGlvbiBpcyBnb29kLCBi dXQgb25lIHRoaW5nIEkgbWVudGlvbmVkIGluIG15IHN1bW1hcnkgb2YgbXkgY2hhdCB3aXRoIHRo ZSBBRHMgd2FzDQoNCiAgKiAgIEhlcmUncyBhIGhpbnQgZnJvbSB0aGUgQURzIC0gaWYgdGhlIHBy b3BvbmVudHMgY2FuIGNvbWUgdXAgd2l0aCBhIGNsZWFyIGNoYXJ0ZXIsIGxpbWl0ZWQgaW4gc2Nv cGUsIHRoYXQgd2lsbCBtYWtlIHRoZWlyIGxpdmVzIGVhc2llciwgYW5kIG1ha2UgaXQgZWFzaWVy IGZvciB0aGVtIHRvIGNoYXJ0ZXIgdGhpcyB3b3JrIDpEDQpTbywgaXQncyByZWFzb25hYmxlIGZv ciB0aGUgTE9PUFMgY29tbXVuaXR5IHRvIGNvbnNpZGVyIGFkZGluZyBob3N0LXRvLW5vZGUsIGJ1 dCBpdCdzIHdvcnRoIGNoZWNraW5nIHdoZXRoZXIgdGhpcyB3b3VsZCBleHBhbmQgdGhlIHNjb3Bl IG9mIHRoZSByZXF1ZXN0ZWQgY2hhcnRlciwgYW5kIHdoZXRoZXIgZXhjbHVkaW5nIGhvc3QtdG8t bm9kZSBtYWtlcyB0aGUgaW5pdGlhbCB3b3JrIGVhc2llciB0byBjb21wbGV0ZS4NCg0KTXkgaW1w cmVzc2lvbiwgYW5kIE1hZ251cyBtaWdodCBzYXkgSSdtIGluc2FuZSwgd2FzIHRoYXQgTWFnbnVz IGlzIHJpZ2h0IG9uIHRoZSBlZGdlIG9mIHdoZXRoZXIgdGhpcyB3b3JrIGNhbiBiZSBjaGFydGVy ZWQgd2l0aG91dCBhIHNlY29uZCwgd29ya2luZyBncm91cC1mb3JtaW5nIEJPRi4gSWYgdGhlIExP T1BTIGNvbW11bml0eSBjYW4ndCBsaXZlIHdpdGhvdXQgaG9zdC10by1ub2RlLCB0aGUgY29tbXVu aXR5IHNob3VsZCBhZGQgaXQuIElmIHRoZSBjb21tdW5pdHkgY2FuIG1ha2UgdXNlIG9mIExPT1BT IHdpdGhvdXQgaG9zdC10by1ub2RlIGFuZCBhZGQgaXQgbGF0ZXIsIHRoZSBjb21tdW5pdHkgbWln aHQgY29uc2lkZXIgd2hldGhlciB0aGF0IHJlZHVjZXMgdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFs IHByb3Bvc2VkIGNoYXJ0ZXIgZW5vdWdoIHRvIGhlbHAgTWFnbnVzIGFwcHJvdmUgaXQgOi0pDQoN CkJlc3Qgd2lzaGVzLA0KDQpTcGVuY2VyDQo= --_000_787AE7BB302AE849A7480A190F8B9330312ECCEBOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1u YW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RlI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0 IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzA1MTMyMzU1Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTMyMDgzOTMwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3 Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgU3BlbmNlciwgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkkgd291bGQgcmVzdHJpY3QgdGhlIGhv c3QtdG8tbmV0d29yayBpbnRlcmFjdGlvbiB0byB0aGUgbWluaW11bSAocmVhZCBFQ04pIGluIHRo ZSBpbml0aWFsIHNjb3BlIG9mIHRoZSB0aGlzIHByb3Bvc2VkIHdvcmsuIEZXSVcsIGJlbG93IGEg dGVudGF0aXZlIHNjb3BlIHdlDQogaW5jbHVkZWQgaW4gdGhlIHVzZS1jYXNlcyBJLUQ6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPj09PT09PT09PTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGludmVz dGlnYXRlIHRvIHdoYXQgZXh0ZW50IGEgbmV0d29yay1hc3Npc3RlZCBhcHByb2FjaCBjYW4gY29u dHJpYnV0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRvIGluY3JlYXNlIHRoZSBvdmVyYWxsIHBl cmNlaXZlZCBxdWFsaXR5IG9mIGV4cGVyaWVuY2UgaW4gc3BlY2lmaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBzaXR1YXRpb25zIChlLmcuLCBTZWN0aW9ucw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktdHN2d2ctbG9vcHMtcHJv YmxlbS1vcHBvcnR1bml0aWVzLTAzI3NlY3Rpb24tMy41Ij48c3BhbiBsYW5nPSJFTi1VUyI+My41 PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCiBhbmQgPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktdHN2 d2ctbG9vcHMtcHJvYmxlbS1vcHBvcnR1bml0aWVzLTAzI3NlY3Rpb24tMy42Ij48c3BhbiBsYW5n PSJFTi1VUyI+My42PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCiBv ZiBbPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODUxNyIgdGl0bGU9IiZxdW90O0FuIEludmVudG9yeSBvZiBUcmFuc3BvcnQtQ2VudHJpYyBG dW5jdGlvbnMgUHJvdmlkZWQgYnkgTWlkZGxlYm94ZXM6IEFuIE9wZXJhdG9yIFBlcnNwZWN0aXZl JnF1b3Q7Ij48c3BhbiBsYW5nPSJFTi1VUyI+UkZDODUxNzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+XSkNCiB3aXRob3V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmVx dWlyaW5nIGFjY2VzcyB0byBpbnRlcm5hbCB0cmFuc3BvcnQgcHJpbWl0aXZlcy4mbmJzcDsgVGhl IHJhdGlvbmFsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGJlbmVhdGggdGhpcyBhcHByb2FjaCBp cyB0aGF0IHNvbWUgaW5mb3JtYXRpb24gKGxvc3MgZGV0ZWN0aW9uLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGJldHRlciB2aXNpYmlsaXR5IG9uIGF2YWlsYWJsZSBwYXRocyBhbmQgdGhlaXIgY2hh cmFjdGVyaXN0aWNzLCBldGMuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNhbiBiZSB1c2VkIHRv IHRyaWdnZXIgbG9jYWwgYWN0aW9ucyB3aGlsZSBhdm9pZGluZyBhcyBtdWNoIGFzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgcG9zc2libGUgdW5kZXNpcmVkIHNpZGUgZWZmZWN0cyAoZS5nLiwgZXhw b3NlIGEgYmVoYXZpb3IgdGhhdCB3b3VsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGJlIGludGVy cHJldGVkIGJ5IGFuIGVuZHBvaW50IGFzIGFuIGFub21hbHkgKGNvcnJ1cHQgZGF0YSkgYW5kIHdo aWNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd291bGQgbGVhZCB0byBleGFjZXJiYXRlIGVuZC10 by1lbmQgcmVjb3ZlcnkuJm5ic3A7IFN1Y2ggbG9jYWwgYWN0aW9uczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IHdvdWxkIGhhdmUgYSBmYXN0ZXIgZWZmZWN0IChlLmcuLCBmYXN0ZXIgcmVjb3Zlcnks IHVzZWQgbXVsdGlwbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYXRocyBzaW11bHRhbmVvdXNs eSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUbyB0aGF0IGFpbSwg dGhlIHdvcmsgaXMgc3RydWN0dXJlZCBpbnRvIHR3byAoMikgcGhhc2VkIHN0YWdlczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU3RhZ2UgMTogTmV0d29y ay1hc3Npc3RlZCBvcHRpbWl6YXRpb24uJm5ic3A7IFRoaXMgb25lIGFzc3VtZXMgdGhhdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGltaXphdGlvbnMgKGUuZy4s IHN1cHBvcnQgbGF0ZW5jeS1zZW5zaXRpdmUgYXBwbGljYXRpb25zKSBjYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBpbXBsZW1lbnRlZCBhdCB0aGUgbmV0d29y ayB3aXRob3V0IHJlcXVpcmluZyBkZWZpbmluZyBuZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbnRlcmFjdGlvbiB3aXRoIHRoZSBlbmRwb2ludC4mbmJzcDsgRXhp c3RpbmcgdG9vbHMgc3VjaCBhcyBFQ04gd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHVzZWQuJm5ic3A7IFNvbWUgb2YgdGhlc2Ugb3B0aW1pemF0aW9ucyBt YXkgYmUgdmFsdWFibGUgaW4gZGVwbG95bWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB3aGVyZSBjb21tdW5pY2F0aW9ucyBhcmUgZXN0YWJsaXNoZWQgb3ZlciBw YXRocyB0aGF0IGFyZSBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBleHBvc2luZyB0aGUgc2FtZSBwZXJmb3JtYW5jZSBjaGFyYWN0ZXJpc3RpY3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFN0YWdlIDI6IENvbGxhYm9y YXRpdmUgbmV0d29ya2luZyBvcHRpbWl6YXRpb24uJm5ic3A7IFRoaXMgb25lIHJlcXVpcmVzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9yZSBpbnRlcmFjdGlvbiBi ZXR3ZWVuIHRoZSBuZXR3b3JrIGFuZCBhbiBlbmRwb2ludCB0byBpbXBsZW1lbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb29yZGluYXRlZCBhbmQgbW9yZSBzdXJn aWNhbCBuZXR3b3JrLWFzc2lzdGVkIG9wdGltaXphdGlvbnMgYmFzZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvbiBpbmZvcm1hdGlvbi9pbnN0cnVjdGlvbnMgc2hh cmVkIGJ5IGFuIGVuZHBvaW50IG9yIHNoYXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBsb2NhbGx5LXZpc2libGUgaW5mb3JtYXRpb24gd2l0aCBlbmRwb2ludCBm b3IgYmV0dGVyIGFuZCBmYXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyByZWNvdmVyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEVm Zm9ydCByZWxhdGVkIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNlY29uZCBzdGFnZSBp cyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGluaXRpYWwgcGxhbm5lZCB3b3JrLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IE5ldmVydGhlbGVzcywgZnV0dXJlIHdvcmsgd2lsbCBiZSBwbGFubmVkIG9uY2Ug cHJvZ3Jlc3MgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAoaG9wZWZ1bGx5KSBtYWRlIG9uIHRo ZSBmaXJzdCBzdGFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBMT09QUyBbbWFp bHRvOmxvb3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBTcGVuY2Vy IERhd2tpbnMgYXQgSUVURjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAyNSBqdWls bGV0IDIwMTkgMjA6NTk8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IENhcnN0ZW4gQm9ybWFubjxicj4N CjxiPkNjJm5ic3A7OjwvYj4gTWFnbnVzIFdlc3Rlcmx1bmQ7IE1hcmllLUpvc2UgTW9udHBldGl0 OyBNaXJqYSBLdWVobGV3aW5kOyBsb29wc0BpZXRmLm9yZzsgU3VyZXNoIEtyaXNobmFuPGJyPg0K PGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0xPT1BTXSBCT0YgY28tY2hhaXJzIHRoaW5raW5nIG9u IExPT1BTIG5leHQgc3RlcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0aWxsIHdlYXJpbmcgbm8gaGF0cywgYmVjYXVzZSBJIG5v IGxvbmdlciBoYXZlIGFueSBkb3RzIC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyNSwgMjAxOSBhdCAxMjo1NiBBTSBD YXJzdGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHpp Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCAyNCwgMjAxOSwgYXQgMTg6MTcsIE1h cmllLUpvc2UgTW9udHBldGl0ICZsdDs8YSBocmVmPSJtYWlsdG86bWFyaWVAbWptb250cGV0aXQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWFyaWVAbWptb250cGV0aXQuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFN0YW5kYXJkaXNhdGlvbiBvZiB3aGF0PyBUaGUgYXJjaGl0 ZWN0dXJlPyBUaGUgcHJvdG9jb2xzIChiZXdhcmUgdGhlcmUgaXMgYWxyZWFkeSBGRUNGUkFNRSBh bmQgb3RoZXJzKT8gVGhlIHByb3hpZXM/PGJyPg0KPGJyPg0KSGkgTWFyaWUtSm9zw6ksPGJyPg0K PGJyPg0KZGV0YWlscyBvZiB0aGUgdGhpbmtpbmcgdGhhdCB3YXMgZGV2ZWxvcGVkIGluIHRoZSBz aWRlIG1lZXRpbmdzIHRoYXQgaGFwcGVuZWQgYXQgdGhlIHByZXZpb3VzIHR3byBJRVRGIG1lZXRp bmdzIGNhbiBiZSBmb3VuZCBhdDxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9sb29wcy13Zy9jaGFydGVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2xv b3BzLXdnL2NoYXJ0ZXI8L2E+PGJyPg0KPGJyPg0KVGhlIEJPRiBhY3R1YWxseSBhZGRlZCBvbmUg cGllY2Ugb2YgaW5mb3JtYXRpb24gSSBkaWRu4oCZdCBwcmV2aW91c2x5IHBlcmNlaXZlIHRoYXQg d2F5Ojxicj4NClBlb3BsZSBzZWVtIHRvIHJlYWxseSB3YW50IHRvIHRhY2tsZSB0aGUgaG9zdC10 by1ub2RlIGNhc2UgKGFzIG5lZWRlZCwgZS5nLiwgZm9yIGdvaW5nIHRocm91Z2ggV2lGaSBhY2Nl c3MgY2xvdWRzKSByaWdodCBhd2F5LCBub3QganVzdCB0aGUgaW4tbmV0d29yayAobm9kZS10by1u b2RlKSBjYXNlLiZuYnNwOyBUaGF0IHdvdWxkIGJlIHRoZSBvbmUgdGhpbmcgSSB3b3VsZCBjaGFu Z2UgYmFzZWQgb24gbXkgcmVjb2xsZWN0aW9uIG9mIHRoZSBCT0YuJm5ic3A7IEJ1dA0KIG9mIGNv dXJzZSB0aGVyZSBtYXkgYmUgb3RoZXIgdGhpbmdzOyBpdCBtYXkgYmUgd29ydGggdG8gbm93IGhh dmUgYW5vdGhlciByb3VuZCBvZiBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q29tbXVuaWNhdGlvbiBpcyBnb29kLCBidXQgb25lIHRoaW5nIEkgbWVudGlvbmVkIGluIG15 IHN1bW1hcnkgb2YgbXkgY2hhdCB3aXRoIHRoZSBBRHMgd2FzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCkhlcmUncyBhIGhpbnQgZnJvbSB0aGUgQURzIC0gaWYgdGhl IHByb3BvbmVudHMgY2FuIGNvbWUgdXAgd2l0aCBhIGNsZWFyIGNoYXJ0ZXIsIGxpbWl0ZWQgaW4g c2NvcGUsIHRoYXQgd2lsbCBtYWtlIHRoZWlyIGxpdmVzIGVhc2llciwgYW5kIG1ha2UgaXQgZWFz aWVyIGZvciB0aGVtIHRvIGNoYXJ0ZXIgdGhpcyB3b3JrIDpEJm5ic3A7PG86cD48L286cD48L2xp PjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIGl0J3MgcmVhc29uYWJsZSBm b3IgdGhlIExPT1BTIGNvbW11bml0eSB0byBjb25zaWRlciBhZGRpbmcgaG9zdC10by1ub2RlLCBi dXQgaXQncyB3b3J0aCBjaGVja2luZyB3aGV0aGVyIHRoaXMgd291bGQgZXhwYW5kIHRoZSBzY29w ZSBvZiB0aGUgcmVxdWVzdGVkIGNoYXJ0ZXIsIGFuZCB3aGV0aGVyIGV4Y2x1ZGluZyBob3N0LXRv LW5vZGUgbWFrZXMgdGhlIGluaXRpYWwgd29yayBlYXNpZXIgdG8gY29tcGxldGUuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TXkgaW1wcmVzc2lvbiwgYW5kIE1hZ251cyBtaWdodCBzYXkgSSdtIGluc2FuZSwgd2FzIHRo YXQgTWFnbnVzIGlzIHJpZ2h0IG9uIHRoZSBlZGdlIG9mIHdoZXRoZXIgdGhpcyB3b3JrIGNhbiBi ZSBjaGFydGVyZWQgd2l0aG91dCBhIHNlY29uZCwgd29ya2luZyBncm91cC1mb3JtaW5nIEJPRi4g SWYgdGhlIExPT1BTIGNvbW11bml0eSBjYW4ndCBsaXZlIHdpdGhvdXQgaG9zdC10by1ub2RlLCB0 aGUgY29tbXVuaXR5DQogc2hvdWxkIGFkZCBpdC4gSWYgdGhlIGNvbW11bml0eSBjYW4gbWFrZSB1 c2Ugb2YgTE9PUFMgd2l0aG91dCBob3N0LXRvLW5vZGUgYW5kIGFkZCBpdCBsYXRlciwgdGhlIGNv bW11bml0eSBtaWdodCBjb25zaWRlciB3aGV0aGVyIHRoYXQgcmVkdWNlcyB0aGUgc2NvcGUgb2Yg dGhlIGluaXRpYWwgcHJvcG9zZWQgY2hhcnRlciBlbm91Z2ggdG8gaGVscCBNYWdudXMgYXBwcm92 ZSBpdCA6LSkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QmVzdCB3aXNoZXMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZW5jZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B9330312ECCEBOPEXCAUBMA2corp_-- From nobody Wed Jul 31 07:02:31 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4B120077 for ; Wed, 31 Jul 2019 07:02:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gVih4yUgZaJ for ; Wed, 31 Jul 2019 07:02:26 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FABB120018 for ; Wed, 31 Jul 2019 07:02:26 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id g20so136464058ioc.12 for ; Wed, 31 Jul 2019 07:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=2smVf2bU6OuwOnCMKPhkC6U+OESTot+bN8/Uyc8EW9A=; b=VNidYw28vgw4SG2uL5VKff1CjdEeuDyrDHZFhcmhRImRehFuwnuQbQtIbO0WCG7/5c PCvsL7y53QJMkWonp4RMihrmSnN3tthJbTGlRnHM74qESy/OZZvtaAZGbEEEmdX6HonS Y98UCDljdo9TjpXwDQXVnFi/nDk9iXqSDxxCHO/MCr/yhhrDLHDLJgLQE/eRJXyyP1ru G+6kbFiIKF9tgsBWvJs2x7BBvP/zlhTRRdSHnOvsmTEO6cxaDWa4ERPmr49iTDGCI5DD qZyylIqRwu+U14J73nZ/guP1duVPs/O+oHHq9BXL0b4YKX96vvxepg1IDytZGOBnhuUa zDTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=2smVf2bU6OuwOnCMKPhkC6U+OESTot+bN8/Uyc8EW9A=; b=YEd+mAHjUIVOaiWOBOmcRt87VU3spKf3Ho97FFwKLoK3cVgMWaKbMIGOKafrQc7Bel 9tuptt57h8CrFRGHOdM6kTsHZbHs0DW8HHfL9Vj5Ac1oVEzhPeu2qLAHef3P3gdZo8DX xiBzUrpIznnWvmrwp/42B3ZrKBJa3YZHjvtvdOZa4H8BIBV3Ap/q871PdqOWstVNKSBl uhHZGss0I/iWjz7dHPLAmgOVw1e/7PU089af/Vyk6xaomQd77YQSZ8GtOybeP4OyW1nw jIWFrPRgFv9ImLLmt8N2hehiRf+5Lhnix7Cs9WRxzLLbqtWxzxtzwAVbt3Th7SkMCC8X vn5g== X-Gm-Message-State: APjAAAX9B3QLQOPF1Fl0OMX6xB3JxoYSeNAJqR5ddm/XFTcgOkudIYT1 y41TdNwF31+lE0UNOYdV8iuZm9dV+oLu7M/oeOw= X-Google-Smtp-Source: APXvYqzUlV/AoZNRKsiinimk9t1KACD1RjOP5Pgv+egtvt0OecWkDJbh8zvKjk7Ov1eZ8H9d/Y+RSV5ab7qhkEe7e4I= X-Received: by 2002:a6b:6e01:: with SMTP id d1mr37830881ioh.156.1564581745598; Wed, 31 Jul 2019 07:02:25 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2019 10:02:25 -0400 From: Marie-Jose Montpetit In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Wed, 31 Jul 2019 10:02:25 -0400 Message-ID: To: mohamed.boucadair@orange.com, Spencer Dawkins at IETF Cc: Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , "loops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b461b058efa9370" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 14:02:29 -0000 --0000000000002b461b058efa9370 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a very wide scope that covers many existing groups. Can you focus on a narrower scope? Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com ( mohamed.boucadair@orange.com) wrote: Hi Spencer, all, I would restrict the host-to-network interaction to the minimum (read ECN) in the initial scope of the this proposed work. FWIW, below a tentative scope we included in the use-cases I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D investigate to what extent a network-assisted approach can contribute to increase the overall perceived quality of experience in specific situations (e.g., Sections 3.5 and 3.6 of [RFC8517 ]) without requiring access to internal transport primitives. The rationale beneath this approach is that some information (loss detection, better visibility on available paths and their characteristics, etc.) can be used to trigger local actions while avoiding as much as possible undesired side effects (e.g., expose a behavior that would be interpreted by an endpoint as an anomaly (corrupt data) and which would lead to exacerbate end-to-end recovery. Such local actions would have a faster effect (e.g., faster recovery, used multiple paths simultaneously). To that aim, the work is structured into two (2) phased stages: o Stage 1: Network-assisted optimization. This one assumes that optimizations (e.g., support latency-sensitive applications) can be implemented at the network without requiring defining new interaction with the endpoint. Existing tools such as ECN will be used. Some of these optimizations may be valuable in deployments where communications are established over paths that are not exposing the same performance characteristics. o Stage 2: Collaborative networking optimization. This one requires more interaction between the network and an endpoint to implement coordinated and more surgical network-assisted optimizations based on information/instructions shared by an endpoint or sharing locally-visible information with endpoint for better and faster recovery. Effort related to the second stage is out of scope of the initial planned work. Nevertheless, future work will be planned once progress is (hopefully) made on the first stage. =3D=3D=3D=3D=3D Cheers, Med *De :* LOOPS [mailto:loops-bounces@ietf.org] *De la part de* Spencer Dawkins at IETF *Envoy=C3=A9 :* jeudi 25 juillet 2019 20:59 *=C3=80 :* Carsten Bormann *Cc :* Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; loops@ietf.org; Suresh Krishnan *Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps Still wearing no hats, because I no longer have any dots ... On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann wrote: On Jul 24, 2019, at 18:17, Marie-Jose Montpetit wrote: > > Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies? Hi Marie-Jos=C3=A9, details of the thinking that was developed in the side meetings that happened at the previous two IETF meetings can be found at https://github.com/loops-wg/charter The BOF actually added one piece of information I didn=E2=80=99t previously perceive that way: People seem to really want to tackle the host-to-node case (as needed, e.g., for going through WiFi access clouds) right away, not just the in-network (node-to-node) case. That would be the one thing I would change based on my recollection of the BOF. But of course there may be other things; it may be worth to now have another round of discussion of the proposed charter. Communication is good, but one thing I mentioned in my summary of my chat with the ADs was - Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D So, it's reasonable for the LOOPS community to consider adding host-to-node, but it's worth checking whether this would expand the scope of the requested charter, and whether excluding host-to-node makes the initial work easier to complete. My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) Best wishes, Spencer --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --0000000000002b461b058efa9370 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    This= is a very wide scope that covers many existing groups. Can you focus on a = narrower scope?

    Marie-Jos=C3=A9 M= ontpetit, Ph.D.
    Research Affiliate, MIT Media Laboratory
    <= div>mariejo@mit.edu

    On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com (mohamed.boucadair@orange.com)= wrote:

    Hi Spencer, all,

    =C2=A0

    I would restrict the host-to-ne= twork interaction to the minimum (read ECN) in the initial scope of the thi= s proposed work. FWIW, below a tentative scope we included in the use-cases I-D:

    =C2=A0

    =3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0=C2=A0 investigate to what extent a n= etwork-assisted approach can contribute

    =C2=A0=C2=A0 to increase the overall percei= ved quality of experience in specific

    =C2=A0=C2=A0 situations (e.g., Sections 3.5 and 3.6 of [RFC8517]= ) without

    =C2=A0=C2=A0 requiring access to internal t= ransport primitives.=C2=A0 The rationale

    =C2=A0=C2=A0 beneath this approach is that = some information (loss detection,

    =C2=A0=C2=A0 better visibility on available= paths and their characteristics, etc.)

    =C2=A0=C2=A0 can be used to trigger local a= ctions while avoiding as much as

    =C2=A0=C2=A0 possible undesired side effect= s (e.g., expose a behavior that would

    =C2=A0=C2=A0 be interpreted by an endpoint = as an anomaly (corrupt data) and which

    =C2=A0=C2=A0 would lead to exacerbate end-t= o-end recovery.=C2=A0 Such local actions

    =C2=A0=C2=A0 would have a faster effect (e.= g., faster recovery, used multiple

    =C2=A0=C2=A0 paths simultaneously).<= /p>

    =C2=A0

    =C2=A0=C2=A0 To that aim, the work is struc= tured into two (2) phased stages:

    =C2=A0

    =C2=A0=C2=A0 o=C2=A0 Stage 1: Network-assis= ted optimization.=C2=A0 This one assumes that

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 optimization= s (e.g., support latency-sensitive applications) can

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be implement= ed at the network without requiring defining new

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interaction = with the endpoint.=C2=A0 Existing tools such as ECN will be

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 used.=C2=A0 = Some of these optimizations may be valuable in deployments

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where commun= ications are established over paths that are not

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exposing the= same performance characteristics.

    =C2=A0

    =C2=A0=C2=A0 o=C2=A0 Stage 2: Collaborative= networking optimization.=C2=A0 This one requires

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 more interac= tion between the network and an endpoint to implement

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 coordinated = and more surgical network-assisted optimizations based

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on informati= on/instructions shared by an endpoint or sharing

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locally-visi= ble information with endpoint for better and faster

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recovery.

    =C2=A0

    =C2=A0=C2=A0 Effort related to the

    =C2=A0=C2=A0 second stage is out of scope o= f the initial planned work.

    =C2=A0=C2=A0 Nevertheless, future work will= be planned once progress is

    =C2=A0=C2=A0 (hopefully) made on the first = stage.

    =3D=3D=3D=3D=3D

    =C2=A0

    Cheers,

    Med

    =C2=A0

    =C2=A0

    Still wearing no hats, because I no longer have any = dots ...

    =C2=A0

    On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <= ;cabo@tzi.org> wrote:

    On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <= marie@mjmontpeti= t.com> wrote:
    >
    > Standardisation of what? The architecture? The protocols (beware there= is already FECFRAME and others)? The proxies?

    Hi Marie-Jos=C3=A9,

    details of the thinking that was developed in the side meetings that happen= ed at the previous two IETF meetings can be found at

    https://g= ithub.com/loops-wg/charter

    The BOF actually added one piece of information I didn=E2=80=99t previously= perceive that way:
    People seem to really want to tackle the host-to-node case (as needed, e.g.= , for going through WiFi access clouds) right away, not just the in-network= (node-to-node) case.=C2=A0 That would be the one thing I would change base= d on my recollection of the BOF.=C2=A0 But of course there may be other things; it may be worth to now have another r= ound of discussion of the proposed charter.

    =C2=A0

    Communication is good, but one thing I mentioned in = my summary of my chat with the ADs was

    • Here's a hint from the ADs - if the proponents can come up with a clear= charter, limited in scope, that will make their lives easier, and make it = easier for them to charter this work :D=C2=A0

    So, it's reasonable for the LOOPS community to c= onsider adding host-to-node, but it's worth checking whether this would= expand the scope of the requested charter, and whether excluding host-to-n= ode makes the initial work easier to complete.=C2=A0

    =C2=A0

    My impression, and Magnus might say I'm insane, = was that Magnus is right on the edge of whether this work can be chartered = without a second, working group-forming BOF. If the LOOPS community can'= ;t live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node= and add it later, the community might consider whether that reduces the sc= ope of the initial proposed charter enough to help Magnus approve it :-)=C2= =A0

    =C2=A0

    Best wishes,=C2=A0

    =C2=A0

    Spencer

    -- =20
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.iet= f.org/mailman/listinfo/loops
    --0000000000002b461b058efa9370-- From nobody Wed Jul 31 07:06:17 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532CD120018 for ; Wed, 31 Jul 2019 07:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YHeycXm44wT0 for ; Wed, 31 Jul 2019 07:06:14 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E532F12000E for ; Wed, 31 Jul 2019 07:06:13 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 45zFZr1Gytz5vQd; Wed, 31 Jul 2019 16:06:12 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 45zFZr16dpzDq80; Wed, 31 Jul 2019 16:06:12 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 16:06:11 +0200 From: To: Marie-Jose Montpetit , Spencer Dawkins at IETF CC: Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , "loops@ietf.org" Thread-Topic: [LOOPS] BOF co-chairs thinking on LOOPS next steps Thread-Index: AQHVR6iWG5o9/Vm4nkqLC/HSohgY7abkwoQg Date: Wed, 31 Jul 2019 14:06:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330312ECFCFOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 14:06:17 -0000 --_000_787AE7BB302AE849A7480A190F8B9330312ECFCFOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpMb2NhbCByZWNvdmVyeS9sb2NhbCBtZWFzdXJlbWVudCBpc27igJl0IHNwZWNpZmlj IGVub3VnaD8NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogTWFyaWUtSm9zZSBNb250cGV0aXQgW21h aWx0bzptYXJpZUBtam1vbnRwZXRpdC5jb21dDQpFbnZvecOpIDogbWVyY3JlZGkgMzEganVpbGxl dCAyMDE5IDE2OjAyDQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IFNwZW5jZXIgRGF3 a2lucyBhdCBJRVRGDQpDYyA6IFN1cmVzaCBLcmlzaG5hbjsgTWFnbnVzIFdlc3Rlcmx1bmQ7IE1p cmphIEt1ZWhsZXdpbmQ7IGxvb3BzQGlldGYub3JnDQpPYmpldCA6IFJlOiBbTE9PUFNdIEJPRiBj by1jaGFpcnMgdGhpbmtpbmcgb24gTE9PUFMgbmV4dCBzdGVwcw0KDQpUaGlzIGlzIGEgdmVyeSB3 aWRlIHNjb3BlIHRoYXQgY292ZXJzIG1hbnkgZXhpc3RpbmcgZ3JvdXBzLiBDYW4geW91IGZvY3Vz IG9uIGEgbmFycm93ZXIgc2NvcGU/DQoNCk1hcmllLUpvc8OpIE1vbnRwZXRpdCwgUGguRC4NClJl c2VhcmNoIEFmZmlsaWF0ZSwgTUlUIE1lZGlhIExhYm9yYXRvcnkNCm1hcmllam9zZUBtam1vbnRw ZXRpdC5jb208bWFpbHRvOm1hcmllam9zZUBtam1vbnRwZXRpdC5jb20+DQptYXJpZWpvQG1pdC5l ZHU8bWFpbHRvOm1hcmllam9AbWl0LmVkdT4NCg0KDQpPbiBKdWx5IDMxLCAyMDE5IGF0IDk6NTU6 MzcgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+IChtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPikgd3JvdGU6DQpIaSBTcGVuY2VyLCBhbGwsDQoNCkkg d291bGQgcmVzdHJpY3QgdGhlIGhvc3QtdG8tbmV0d29yayBpbnRlcmFjdGlvbiB0byB0aGUgbWlu aW11bSAocmVhZCBFQ04pIGluIHRoZSBpbml0aWFsIHNjb3BlIG9mIHRoZSB0aGlzIHByb3Bvc2Vk IHdvcmsuIEZXSVcsIGJlbG93IGEgdGVudGF0aXZlIHNjb3BlIHdlIGluY2x1ZGVkIGluIHRoZSB1 c2UtY2FzZXMgSS1EOg0KDQo9PT09PT09PT0NCiAgIGludmVzdGlnYXRlIHRvIHdoYXQgZXh0ZW50 IGEgbmV0d29yay1hc3Npc3RlZCBhcHByb2FjaCBjYW4gY29udHJpYnV0ZQ0KICAgdG8gaW5jcmVh c2UgdGhlIG92ZXJhbGwgcGVyY2VpdmVkIHF1YWxpdHkgb2YgZXhwZXJpZW5jZSBpbiBzcGVjaWZp Yw0KICAgc2l0dWF0aW9ucyAoZS5nLiwgU2VjdGlvbnMgMy41PGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMtMDMjc2Vj dGlvbi0zLjU+IGFuZCAzLjY8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLXRz dndnLWxvb3BzLXByb2JsZW0tb3Bwb3J0dW5pdGllcy0wMyNzZWN0aW9uLTMuNj4gb2YgW1JGQzg1 MTc8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg1MTc+XSkgd2l0aG91dA0KICAgcmVx dWlyaW5nIGFjY2VzcyB0byBpbnRlcm5hbCB0cmFuc3BvcnQgcHJpbWl0aXZlcy4gIFRoZSByYXRp b25hbGUNCiAgIGJlbmVhdGggdGhpcyBhcHByb2FjaCBpcyB0aGF0IHNvbWUgaW5mb3JtYXRpb24g KGxvc3MgZGV0ZWN0aW9uLA0KICAgYmV0dGVyIHZpc2liaWxpdHkgb24gYXZhaWxhYmxlIHBhdGhz IGFuZCB0aGVpciBjaGFyYWN0ZXJpc3RpY3MsIGV0Yy4pDQogICBjYW4gYmUgdXNlZCB0byB0cmln Z2VyIGxvY2FsIGFjdGlvbnMgd2hpbGUgYXZvaWRpbmcgYXMgbXVjaCBhcw0KICAgcG9zc2libGUg dW5kZXNpcmVkIHNpZGUgZWZmZWN0cyAoZS5nLiwgZXhwb3NlIGEgYmVoYXZpb3IgdGhhdCB3b3Vs ZA0KICAgYmUgaW50ZXJwcmV0ZWQgYnkgYW4gZW5kcG9pbnQgYXMgYW4gYW5vbWFseSAoY29ycnVw dCBkYXRhKSBhbmQgd2hpY2gNCiAgIHdvdWxkIGxlYWQgdG8gZXhhY2VyYmF0ZSBlbmQtdG8tZW5k IHJlY292ZXJ5LiAgU3VjaCBsb2NhbCBhY3Rpb25zDQogICB3b3VsZCBoYXZlIGEgZmFzdGVyIGVm ZmVjdCAoZS5nLiwgZmFzdGVyIHJlY292ZXJ5LCB1c2VkIG11bHRpcGxlDQogICBwYXRocyBzaW11 bHRhbmVvdXNseSkuDQoNCiAgIFRvIHRoYXQgYWltLCB0aGUgd29yayBpcyBzdHJ1Y3R1cmVkIGlu dG8gdHdvICgyKSBwaGFzZWQgc3RhZ2VzOg0KDQogICBvICBTdGFnZSAxOiBOZXR3b3JrLWFzc2lz dGVkIG9wdGltaXphdGlvbi4gIFRoaXMgb25lIGFzc3VtZXMgdGhhdA0KICAgICAgb3B0aW1pemF0 aW9ucyAoZS5nLiwgc3VwcG9ydCBsYXRlbmN5LXNlbnNpdGl2ZSBhcHBsaWNhdGlvbnMpIGNhbg0K ICAgICAgYmUgaW1wbGVtZW50ZWQgYXQgdGhlIG5ldHdvcmsgd2l0aG91dCByZXF1aXJpbmcgZGVm aW5pbmcgbmV3DQogICAgICBpbnRlcmFjdGlvbiB3aXRoIHRoZSBlbmRwb2ludC4gIEV4aXN0aW5n IHRvb2xzIHN1Y2ggYXMgRUNOIHdpbGwgYmUNCiAgICAgIHVzZWQuICBTb21lIG9mIHRoZXNlIG9w dGltaXphdGlvbnMgbWF5IGJlIHZhbHVhYmxlIGluIGRlcGxveW1lbnRzDQogICAgICB3aGVyZSBj b21tdW5pY2F0aW9ucyBhcmUgZXN0YWJsaXNoZWQgb3ZlciBwYXRocyB0aGF0IGFyZSBub3QNCiAg ICAgIGV4cG9zaW5nIHRoZSBzYW1lIHBlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcy4NCg0KICAg byAgU3RhZ2UgMjogQ29sbGFib3JhdGl2ZSBuZXR3b3JraW5nIG9wdGltaXphdGlvbi4gIFRoaXMg b25lIHJlcXVpcmVzDQogICAgICBtb3JlIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIG5ldHdvcmsg YW5kIGFuIGVuZHBvaW50IHRvIGltcGxlbWVudA0KICAgICAgY29vcmRpbmF0ZWQgYW5kIG1vcmUg c3VyZ2ljYWwgbmV0d29yay1hc3Npc3RlZCBvcHRpbWl6YXRpb25zIGJhc2VkDQogICAgICBvbiBp bmZvcm1hdGlvbi9pbnN0cnVjdGlvbnMgc2hhcmVkIGJ5IGFuIGVuZHBvaW50IG9yIHNoYXJpbmcN CiAgICAgIGxvY2FsbHktdmlzaWJsZSBpbmZvcm1hdGlvbiB3aXRoIGVuZHBvaW50IGZvciBiZXR0 ZXIgYW5kIGZhc3Rlcg0KICAgICAgcmVjb3ZlcnkuDQoNCiAgIEVmZm9ydCByZWxhdGVkIHRvIHRo ZQ0KICAgc2Vjb25kIHN0YWdlIGlzIG91dCBvZiBzY29wZSBvZiB0aGUgaW5pdGlhbCBwbGFubmVk IHdvcmsuDQogICBOZXZlcnRoZWxlc3MsIGZ1dHVyZSB3b3JrIHdpbGwgYmUgcGxhbm5lZCBvbmNl IHByb2dyZXNzIGlzDQogICAoaG9wZWZ1bGx5KSBtYWRlIG9uIHRoZSBmaXJzdCBzdGFnZS4NCj09 PT09DQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IExPT1BTIFttYWlsdG86bG9vcHMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bG9vcHMtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUgU3Bl bmNlciBEYXdraW5zIGF0IElFVEYNCkVudm95w6kgOiBqZXVkaSAyNSBqdWlsbGV0IDIwMTkgMjA6 NTkNCsOAIDogQ2Fyc3RlbiBCb3JtYW5uDQpDYyA6IE1hZ251cyBXZXN0ZXJsdW5kOyBNYXJpZS1K b3NlIE1vbnRwZXRpdDsgTWlyamEgS3VlaGxld2luZDsgbG9vcHNAaWV0Zi5vcmc8bWFpbHRvOmxv b3BzQGlldGYub3JnPjsgU3VyZXNoIEtyaXNobmFuDQpPYmpldCA6IFJlOiBbTE9PUFNdIEJPRiBj by1jaGFpcnMgdGhpbmtpbmcgb24gTE9PUFMgbmV4dCBzdGVwcw0KDQpTdGlsbCB3ZWFyaW5nIG5v IGhhdHMsIGJlY2F1c2UgSSBubyBsb25nZXIgaGF2ZSBhbnkgZG90cyAuLi4NCg0KT24gVGh1LCBK dWwgMjUsIDIwMTkgYXQgMTI6NTYgQU0gQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFp bHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KT24gSnVsIDI0LCAyMDE5LCBhdCAxODoxNywgTWFy aWUtSm9zZSBNb250cGV0aXQgPG1hcmllQG1qbW9udHBldGl0LmNvbTxtYWlsdG86bWFyaWVAbWpt b250cGV0aXQuY29tPj4gd3JvdGU6DQo+DQo+IFN0YW5kYXJkaXNhdGlvbiBvZiB3aGF0PyBUaGUg YXJjaGl0ZWN0dXJlPyBUaGUgcHJvdG9jb2xzIChiZXdhcmUgdGhlcmUgaXMgYWxyZWFkeSBGRUNG UkFNRSBhbmQgb3RoZXJzKT8gVGhlIHByb3hpZXM/DQoNCkhpIE1hcmllLUpvc8OpLA0KDQpkZXRh aWxzIG9mIHRoZSB0aGlua2luZyB0aGF0IHdhcyBkZXZlbG9wZWQgaW4gdGhlIHNpZGUgbWVldGlu Z3MgdGhhdCBoYXBwZW5lZCBhdCB0aGUgcHJldmlvdXMgdHdvIElFVEYgbWVldGluZ3MgY2FuIGJl IGZvdW5kIGF0DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9sb29wcy13Zy9jaGFydGVyDQoNClRoZSBC T0YgYWN0dWFsbHkgYWRkZWQgb25lIHBpZWNlIG9mIGluZm9ybWF0aW9uIEkgZGlkbuKAmXQgcHJl dmlvdXNseSBwZXJjZWl2ZSB0aGF0IHdheToNClBlb3BsZSBzZWVtIHRvIHJlYWxseSB3YW50IHRv IHRhY2tsZSB0aGUgaG9zdC10by1ub2RlIGNhc2UgKGFzIG5lZWRlZCwgZS5nLiwgZm9yIGdvaW5n IHRocm91Z2ggV2lGaSBhY2Nlc3MgY2xvdWRzKSByaWdodCBhd2F5LCBub3QganVzdCB0aGUgaW4t bmV0d29yayAobm9kZS10by1ub2RlKSBjYXNlLiAgVGhhdCB3b3VsZCBiZSB0aGUgb25lIHRoaW5n IEkgd291bGQgY2hhbmdlIGJhc2VkIG9uIG15IHJlY29sbGVjdGlvbiBvZiB0aGUgQk9GLiAgQnV0 IG9mIGNvdXJzZSB0aGVyZSBtYXkgYmUgb3RoZXIgdGhpbmdzOyBpdCBtYXkgYmUgd29ydGggdG8g bm93IGhhdmUgYW5vdGhlciByb3VuZCBvZiBkaXNjdXNzaW9uIG9mIHRoZSBwcm9wb3NlZCBjaGFy dGVyLg0KDQpDb21tdW5pY2F0aW9uIGlzIGdvb2QsIGJ1dCBvbmUgdGhpbmcgSSBtZW50aW9uZWQg aW4gbXkgc3VtbWFyeSBvZiBteSBjaGF0IHdpdGggdGhlIEFEcyB3YXMNCg0KICAqICAgSGVyZSdz IGEgaGludCBmcm9tIHRoZSBBRHMgLSBpZiB0aGUgcHJvcG9uZW50cyBjYW4gY29tZSB1cCB3aXRo IGEgY2xlYXIgY2hhcnRlciwgbGltaXRlZCBpbiBzY29wZSwgdGhhdCB3aWxsIG1ha2UgdGhlaXIg bGl2ZXMgZWFzaWVyLCBhbmQgbWFrZSBpdCBlYXNpZXIgZm9yIHRoZW0gdG8gY2hhcnRlciB0aGlz IHdvcmsgOkQNClNvLCBpdCdzIHJlYXNvbmFibGUgZm9yIHRoZSBMT09QUyBjb21tdW5pdHkgdG8g Y29uc2lkZXIgYWRkaW5nIGhvc3QtdG8tbm9kZSwgYnV0IGl0J3Mgd29ydGggY2hlY2tpbmcgd2hl dGhlciB0aGlzIHdvdWxkIGV4cGFuZCB0aGUgc2NvcGUgb2YgdGhlIHJlcXVlc3RlZCBjaGFydGVy LCBhbmQgd2hldGhlciBleGNsdWRpbmcgaG9zdC10by1ub2RlIG1ha2VzIHRoZSBpbml0aWFsIHdv cmsgZWFzaWVyIHRvIGNvbXBsZXRlLg0KDQpNeSBpbXByZXNzaW9uLCBhbmQgTWFnbnVzIG1pZ2h0 IHNheSBJJ20gaW5zYW5lLCB3YXMgdGhhdCBNYWdudXMgaXMgcmlnaHQgb24gdGhlIGVkZ2Ugb2Yg d2hldGhlciB0aGlzIHdvcmsgY2FuIGJlIGNoYXJ0ZXJlZCB3aXRob3V0IGEgc2Vjb25kLCB3b3Jr aW5nIGdyb3VwLWZvcm1pbmcgQk9GLiBJZiB0aGUgTE9PUFMgY29tbXVuaXR5IGNhbid0IGxpdmUg d2l0aG91dCBob3N0LXRvLW5vZGUsIHRoZSBjb21tdW5pdHkgc2hvdWxkIGFkZCBpdC4gSWYgdGhl IGNvbW11bml0eSBjYW4gbWFrZSB1c2Ugb2YgTE9PUFMgd2l0aG91dCBob3N0LXRvLW5vZGUgYW5k IGFkZCBpdCBsYXRlciwgdGhlIGNvbW11bml0eSBtaWdodCBjb25zaWRlciB3aGV0aGVyIHRoYXQg cmVkdWNlcyB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwgcHJvcG9zZWQgY2hhcnRlciBlbm91Z2gg dG8gaGVscCBNYWdudXMgYXBwcm92ZSBpdCA6LSkNCg0KQmVzdCB3aXNoZXMsDQoNClNwZW5jZXIN Ci0tDQpMT09QUyBtYWlsaW5nIGxpc3QNCkxPT1BTQGlldGYub3JnPG1haWx0bzpMT09QU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHMNCg== --_000_787AE7BB302AE849A7480A190F8B9330312ECFCFOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5haXJtYWlsb24sIGxpLmFpcm1haWxvbiwgZGl2LmFpcm1haWxvbg0KCXttc28tc3R5 bGUtbmFtZTphaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0 IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcwMDkz NjcwNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NzExNjIyMzg7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TG9jYWwgcmVjb3Zl cnkvbG9jYWwgbWVhc3VyZW1lbnQgaXNu4oCZdCBzcGVjaWZpYyBlbm91Z2g/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IE1hcmllLUpvc2UgTW9udHBldGl0IFttYWlsdG86bWFyaWVAbWptb250cGV0aXQuY29tXQ0KPGJy Pg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDMxIGp1aWxsZXQgMjAxOSAxNjowMjxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgU3BlbmNlciBE YXdraW5zIGF0IElFVEY8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFN1cmVzaCBLcmlzaG5hbjsgTWFn bnVzIFdlc3Rlcmx1bmQ7IE1pcmphIEt1ZWhsZXdpbmQ7IGxvb3BzQGlldGYub3JnPGJyPg0KPGI+ T2JqZXQmbmJzcDs6PC9iPiBSZTogW0xPT1BTXSBCT0YgY28tY2hhaXJzIHRoaW5raW5nIG9uIExP T1BTIG5leHQgc3RlcHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBpcyBhIHZlcnkg d2lkZSBzY29wZSB0aGF0IGNvdmVycyBtYW55IGV4aXN0aW5nIGdyb3Vwcy4gQ2FuIHlvdSBmb2N1 cyBvbiBhIG5hcnJvd2VyIHNjb3BlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPk1hcmllLUpvc8OpIE1vbnRwZXRpdCwgUGguRC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+UmVzZWFyY2ggQWZmaWxpYXRlLCBNSVQgTWVkaWEgTGFib3JhdG9y eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86bWFyaWVqb3NlQG1qbW9u dHBldGl0LmNvbSI+bWFyaWVqb3NlQG1qbW9udHBldGl0LmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86bWFyaWVqb0BtaXQuZWR1Ij5tYXJpZWpv QG1pdC5lZHU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gSnVseSAzMSwgMjAxOSBhdCA5OjU1OjM3IEFNLA0KPGEg aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb208L2E+ICg8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4pIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgU3BlbmNlciwgYWxsLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHdvdWxkIHJlc3RyaWN0IHRoZSBob3N0LXRv LW5ldHdvcmsgaW50ZXJhY3Rpb24gdG8gdGhlIG1pbmltdW0gKHJlYWQgRUNOKSBpbiB0aGUgaW5p dGlhbCBzY29wZQ0KIG9mIHRoZSB0aGlzIHByb3Bvc2VkIHdvcmsuIEZXSVcsIGJlbG93IGEgdGVu dGF0aXZlIHNjb3BlIHdlIGluY2x1ZGVkIGluIHRoZSB1c2UtY2FzZXMgSS1EOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT09PT09PT09PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpbnZlc3RpZ2F0ZSB0byB3aGF0IGV4dGVudCBhIG5ldHdv cmstYXNzaXN0ZWQgYXBwcm9hY2ggY2FuIGNvbnRyaWJ1dGU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IHRvIGluY3JlYXNlIHRoZSBvdmVyYWxsIHBlcmNlaXZlZCBxdWFsaXR5IG9mIGV4cGVyaWVu Y2UgaW4gc3BlY2lmaWM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHNpdHVhdGlvbnMgKGUuZy4s IFNlY3Rpb25zDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVuaXRpZXMtMDMjc2Vj dGlvbi0zLjUiPjxzcGFuIGxhbmc9IkVOLVVTIj4zLjU8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPg0KIGFuZCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS10c3Z3Zy1sb29wcy1wcm9ibGVtLW9wcG9ydHVu aXRpZXMtMDMjc2VjdGlvbi0zLjYiPjxzcGFuIGxhbmc9IkVOLVVTIj4zLjY8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KIG9mIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NTE3IiB0aXRsZT0iJnF1b3Q7QW4g SW52ZW50b3J5IG9mIFRyYW5zcG9ydC1DZW50cmljIEZ1bmN0aW9ucyBQcm92aWRlZCBieSBNaWRk bGVib3hlczogQW4gT3BlcmF0b3IgUGVyc3BlY3RpdmUmcXVvdDsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SRkM4NTE3PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5dKQ0KIHdp dGhvdXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmluZyBhY2Nlc3MgdG8gaW50ZXJu YWwgdHJhbnNwb3J0IHByaW1pdGl2ZXMuJm5ic3A7IFRoZSByYXRpb25hbGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IGJlbmVhdGggdGhpcyBhcHByb2FjaCBpcyB0aGF0IHNvbWUgaW5mb3JtYXRp b24gKGxvc3MgZGV0ZWN0aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmV0dGVyIHZpc2li aWxpdHkgb24gYXZhaWxhYmxlIHBhdGhzIGFuZCB0aGVpciBjaGFyYWN0ZXJpc3RpY3MsIGV0Yy4p PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjYW4gYmUgdXNlZCB0byB0cmlnZ2VyIGxvY2FsIGFj dGlvbnMgd2hpbGUgYXZvaWRpbmcgYXMgbXVjaCBhczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg cG9zc2libGUgdW5kZXNpcmVkIHNpZGUgZWZmZWN0cyAoZS5nLiwgZXhwb3NlIGEgYmVoYXZpb3Ig dGhhdCB3b3VsZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmUgaW50ZXJwcmV0ZWQgYnkgYW4g ZW5kcG9pbnQgYXMgYW4gYW5vbWFseSAoY29ycnVwdCBkYXRhKSBhbmQgd2hpY2g8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHdvdWxkIGxlYWQgdG8gZXhhY2VyYmF0ZSBlbmQtdG8tZW5kIHJlY292 ZXJ5LiZuYnNwOyBTdWNoIGxvY2FsIGFjdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdv dWxkIGhhdmUgYSBmYXN0ZXIgZWZmZWN0IChlLmcuLCBmYXN0ZXIgcmVjb3ZlcnksIHVzZWQgbXVs dGlwbGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhdGhzIHNpbXVsdGFuZW91c2x5KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUbyB0aGF0IGFpbSwgdGhl IHdvcmsgaXMgc3RydWN0dXJlZCBpbnRvIHR3byAoMikgcGhhc2VkIHN0YWdlczo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFN0YWdlIDE6IE5ldHdv cmstYXNzaXN0ZWQgb3B0aW1pemF0aW9uLiZuYnNwOyBUaGlzIG9uZSBhc3N1bWVzIHRoYXQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wdGltaXphdGlvbnMgKGUu Zy4sIHN1cHBvcnQgbGF0ZW5jeS1zZW5zaXRpdmUgYXBwbGljYXRpb25zKSBjYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGltcGxlbWVudGVkIGF0IHRoZSBu ZXR3b3JrIHdpdGhvdXQgcmVxdWlyaW5nIGRlZmluaW5nIG5ldzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJhY3Rpb24gd2l0aCB0aGUgZW5kcG9pbnQuJm5i c3A7IEV4aXN0aW5nIHRvb2xzIHN1Y2ggYXMgRUNOIHdpbGwgYmU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWQuJm5ic3A7IFNvbWUgb2YgdGhlc2Ugb3B0aW1p emF0aW9ucyBtYXkgYmUgdmFsdWFibGUgaW4gZGVwbG95bWVudHM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlIGNvbW11bmljYXRpb25zIGFyZSBlc3RhYmxp c2hlZCBvdmVyIHBhdGhzIHRoYXQgYXJlIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZXhwb3NpbmcgdGhlIHNhbWUgcGVyZm9ybWFuY2UgY2hhcmFjdGVyaXN0 aWNzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsg U3RhZ2UgMjogQ29sbGFib3JhdGl2ZSBuZXR3b3JraW5nIG9wdGltaXphdGlvbi4mbmJzcDsgVGhp cyBvbmUgcmVxdWlyZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1vcmUgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUgbmV0d29yayBhbmQgYW4gZW5kcG9pbnQgdG8g aW1wbGVtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb29y ZGluYXRlZCBhbmQgbW9yZSBzdXJnaWNhbCBuZXR3b3JrLWFzc2lzdGVkIG9wdGltaXphdGlvbnMg YmFzZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9uIGluZm9y bWF0aW9uL2luc3RydWN0aW9ucyBzaGFyZWQgYnkgYW4gZW5kcG9pbnQgb3Igc2hhcmluZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9jYWxseS12aXNpYmxlIGlu Zm9ybWF0aW9uIHdpdGggZW5kcG9pbnQgZm9yIGJldHRlciBhbmQgZmFzdGVyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWNvdmVyeS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBFZmZvcnQgcmVsYXRlZCB0byB0aGU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IHNlY29uZCBzdGFnZSBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIGlu aXRpYWwgcGxhbm5lZCB3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgTmV2ZXJ0aGVsZXNz LCBmdXR1cmUgd29yayB3aWxsIGJlIHBsYW5uZWQgb25jZSBwcm9ncmVzcyBpczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgKGhvcGVmdWxseSkgbWFkZSBvbiB0aGUgZmlyc3Qgc3RhZ2UuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTE9PUFMgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9vcHMtYm91bmNlc0BpZXRmLm9yZyI+bG9vcHMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURjxicj4N CjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAyNSBqdWlsbGV0IDIwMTkgMjA6NTk8YnI+DQo8 Yj7DgCZuYnNwOzo8L2I+IENhcnN0ZW4gQm9ybWFubjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gTWFn bnVzIFdlc3Rlcmx1bmQ7IE1hcmllLUpvc2UgTW9udHBldGl0OyBNaXJqYSBLdWVobGV3aW5kOyA8 YSBocmVmPSJtYWlsdG86bG9vcHNAaWV0Zi5vcmciPg0KbG9vcHNAaWV0Zi5vcmc8L2E+OyBTdXJl c2ggS3Jpc2huYW48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbTE9PUFNdIEJPRiBjby1j aGFpcnMgdGhpbmtpbmcgb24gTE9PUFMgbmV4dCBzdGVwczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0aWxsIHdlYXJpbmcg bm8gaGF0cywgYmVjYXVzZSBJIG5vIGxvbmdlciBoYXZlIGFueSBkb3RzIC4uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBK dWwgMjUsIDIwMTkgYXQgMTI6NTYgQU0gQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWls dG86Y2Fib0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwgMjQsIDIwMTksIGF0IDE4 OjE3LCBNYXJpZS1Kb3NlIE1vbnRwZXRpdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmllQG1qbW9u dHBldGl0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcmllQG1qbW9udHBldGl0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBTdGFuZGFyZGlzYXRpb24gb2Ygd2hhdD8gVGhl IGFyY2hpdGVjdHVyZT8gVGhlIHByb3RvY29scyAoYmV3YXJlIHRoZXJlIGlzIGFscmVhZHkgRkVD RlJBTUUgYW5kIG90aGVycyk/IFRoZSBwcm94aWVzPzxicj4NCjxicj4NCkhpIE1hcmllLUpvc8Op LDxicj4NCjxicj4NCmRldGFpbHMgb2YgdGhlIHRoaW5raW5nIHRoYXQgd2FzIGRldmVsb3BlZCBp biB0aGUgc2lkZSBtZWV0aW5ncyB0aGF0IGhhcHBlbmVkIGF0IHRoZSBwcmV2aW91cyB0d28gSUVU RiBtZWV0aW5ncyBjYW4gYmUgZm91bmQgYXQ8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL2dp dGh1Yi5jb20vbG9vcHMtd2cvY2hhcnRlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHVi LmNvbS9sb29wcy13Zy9jaGFydGVyPC9hPjxicj4NCjxicj4NClRoZSBCT0YgYWN0dWFsbHkgYWRk ZWQgb25lIHBpZWNlIG9mIGluZm9ybWF0aW9uIEkgZGlkbuKAmXQgcHJldmlvdXNseSBwZXJjZWl2 ZSB0aGF0IHdheTo8YnI+DQpQZW9wbGUgc2VlbSB0byByZWFsbHkgd2FudCB0byB0YWNrbGUgdGhl IGhvc3QtdG8tbm9kZSBjYXNlIChhcyBuZWVkZWQsIGUuZy4sIGZvciBnb2luZyB0aHJvdWdoIFdp RmkgYWNjZXNzIGNsb3VkcykgcmlnaHQgYXdheSwgbm90IGp1c3QgdGhlIGluLW5ldHdvcmsgKG5v ZGUtdG8tbm9kZSkgY2FzZS4mbmJzcDsgVGhhdCB3b3VsZCBiZSB0aGUgb25lIHRoaW5nIEkgd291 bGQgY2hhbmdlIGJhc2VkIG9uIG15IHJlY29sbGVjdGlvbiBvZiB0aGUgQk9GLiZuYnNwOyBCdXQN CiBvZiBjb3Vyc2UgdGhlcmUgbWF5IGJlIG90aGVyIHRoaW5nczsgaXQgbWF5IGJlIHdvcnRoIHRv IG5vdyBoYXZlIGFub3RoZXIgcm91bmQgb2YgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvcG9zZWQgY2hh cnRlci48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Db21tdW5pY2F0aW9uIGlzIGdvb2QsIGJ1dCBvbmUgdGhpbmcgSSBtZW50 aW9uZWQgaW4gbXkgc3VtbWFyeSBvZiBteSBjaGF0IHdpdGggdGhlIEFEcyB3YXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SGVyZSdzIGEgaGludCBmcm9tIHRoZSBBRHMgLSBpZiB0aGUgcHJvcG9uZW50cyBjYW4g Y29tZSB1cCB3aXRoIGEgY2xlYXIgY2hhcnRlciwgbGltaXRlZCBpbiBzY29wZSwgdGhhdCB3aWxs IG1ha2UgdGhlaXIgbGl2ZXMgZWFzaWVyLCBhbmQgbWFrZSBpdCBlYXNpZXIgZm9yIHRoZW0gdG8g Y2hhcnRlciB0aGlzIHdvcmsgOkQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbywgaXQncyByZWFzb25hYmxlIGZvciB0aGUg TE9PUFMgY29tbXVuaXR5IHRvIGNvbnNpZGVyIGFkZGluZyBob3N0LXRvLW5vZGUsIGJ1dCBpdCdz IHdvcnRoIGNoZWNraW5nIHdoZXRoZXIgdGhpcyB3b3VsZCBleHBhbmQgdGhlIHNjb3BlIG9mIHRo ZSByZXF1ZXN0ZWQgY2hhcnRlciwgYW5kIHdoZXRoZXIgZXhjbHVkaW5nDQogaG9zdC10by1ub2Rl IG1ha2VzIHRoZSBpbml0aWFsIHdvcmsgZWFzaWVyIHRvIGNvbXBsZXRlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5NeSBpbXByZXNzaW9uLCBhbmQgTWFnbnVzIG1pZ2h0IHNheSBJJ20gaW5zYW5lLCB3YXMgdGhh dCBNYWdudXMgaXMgcmlnaHQgb24gdGhlIGVkZ2Ugb2Ygd2hldGhlciB0aGlzIHdvcmsgY2FuIGJl IGNoYXJ0ZXJlZCB3aXRob3V0IGEgc2Vjb25kLCB3b3JraW5nIGdyb3VwLWZvcm1pbmcgQk9GLiBJ ZiB0aGUgTE9PUFMNCiBjb21tdW5pdHkgY2FuJ3QgbGl2ZSB3aXRob3V0IGhvc3QtdG8tbm9kZSwg dGhlIGNvbW11bml0eSBzaG91bGQgYWRkIGl0LiBJZiB0aGUgY29tbXVuaXR5IGNhbiBtYWtlIHVz ZSBvZiBMT09QUyB3aXRob3V0IGhvc3QtdG8tbm9kZSBhbmQgYWRkIGl0IGxhdGVyLCB0aGUgY29t bXVuaXR5IG1pZ2h0IGNvbnNpZGVyIHdoZXRoZXIgdGhhdCByZWR1Y2VzIHRoZSBzY29wZSBvZiB0 aGUgaW5pdGlhbCBwcm9wb3NlZCBjaGFydGVyIGVub3VnaCB0byBoZWxwDQogTWFnbnVzIGFwcHJv dmUgaXQgOi0pJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5CZXN0IHdpc2hlcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZW5jZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLQ0KPGJyPg0KTE9PUFMgbWFp bGluZyBsaXN0IDxicj4NCjxhIGhyZWY9Im1haWx0bzpMT09QU0BpZXRmLm9yZyI+TE9PUFNAaWV0 Zi5vcmc8L2E+IDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbG9vcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbG9vcHM8 L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B9330312ECFCFOPEXCAUBMA2corp_-- From nobody Wed Jul 31 07:15:03 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAD1120077; Wed, 31 Jul 2019 07:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X40L-9cRSKnd; Wed, 31 Jul 2019 07:14:51 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 C4CB112006D; Wed, 31 Jul 2019 07:14:50 -0700 (PDT) Received: from [130.209.157.54] (port=50825 helo=glaroam2-179-133.wireless.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hspNM-0003fg-Ix; Wed, 31 Jul 2019 15:14:48 +0100 From: Colin Perkins Message-Id: <591523D9-D5C0-4FAB-A835-7472B2907544@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_7498BA51-6778-4399-85E0-FC48ECF9CA7E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 31 Jul 2019 15:14:42 +0100 In-Reply-To: Cc: Marie-Jose Montpetit , Magnus Westerlund , "nwcrg@irtf.org" , loops@ietf.org, Mirja Kuehlewind , Carsten Bormann , Suresh Krishnan To: Spencer Dawkins at IETF References: <2342D6E9-FF90-4D51-9647-0F7ABDA47268@csperkins.org> X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [LOOPS] [nwcrg] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 14:14:55 -0000 --Apple-Mail=_7498BA51-6778-4399-85E0-FC48ECF9CA7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Agree - thanks, Spencer. Colin > On 31 Jul 2019, at 14:18, Spencer Dawkins at IETF = wrote: >=20 > Hi, Colin, >=20 > On Wed, Jul 31, 2019, 07:36 Colin Perkins > wrote: >> On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF = > = wrote: >>=20 >> I'm going to be replying to two or three e-mail in this thread, so = I'll try to be coherent over my replies ....=20 >>=20 >> On Tue, Jul 30, 2019 at 9:42 AM Marie-Jose Montpetit = > wrote: >> Since most of your questions are related to FEC I copy the nwcrg. See = below >>=20 >> mjm >>=20 >> Marie-Jos=C3=A9 Montpetit, Ph.D. >> Research Affiliate, MIT Media Laboratory >> mariejose@mjmontpetit.com >> mariejo@mit.edu >> On July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF = (spencerdawkins.ietf@gmail.com ) = wrote: >>=20 >>> Hi, Mirja,=20 >>>=20 >>> On Tue, Jul 30, 2019 at 5:34 AM Mirja Kuehlewind = > wrote: >>> Hi Carsten, hi Spencer, >>>=20 >>> > On 25. Jul 2019, at 20:59, Spencer Dawkins at IETF = > = wrote: >>> > >>> > My impression, and Magnus might say I'm insane, was that Magnus is = right on the edge of whether this work can be chartered without a = second, working group-forming BOF. If the LOOPS community can't live = without host-to-node, the community should add it. If the community can = make use of LOOPS without host-to-node and add it later, the community = might consider whether that reduces the scope of the initial proposed = charter enough to help Magnus approve it :-) >>>=20 >>> Yes, it would be possible to charter without another BoF a small and = well-scoped group, however, it also would be possible to work on small = and well-defined pieces of work without a new working group. This was = one of the reasons why this was not a non-wg-forming BoF because it is = not clear yet if a new group is needed or the resulting pieces of = standardization work are small enough to fit into an existing group. >>>=20 >>> Therefore, I really recommend focus on defining the standardising = work items that you think are needed rather than trying to do any = word-smithing of a potential charter (that eventually is not needed). >>>=20 >>> Thanks for giving me the chance to clarify - I really was talking = about chartering work, not just chartering a working group, but that = wasn't clear from my note. As you said, knowing what the work is, in = more detail, will help you and Magnus know what to do next.=20 >>>=20 >>> So, my suggestion for the interested community is to nail down >>> In order to "do LOOPS", what already exists, that can be used = without changes? >>> what already exists, but needs to be extended for LOOPS? >>> what needs to be created, because nothing exists that meets the = needs? >>> I'm not a LOOPS proponent (the ADs asked me to chair the BOF about = a month before IETF 105), but speaking as someone who hasn't been = involved in depth, I wonder about >>> How a sender tunes FEC dynamically - is that automatic, based on FEC = mechanisms people are thinking about, or is there work to do there? >>=20 >> There are FEC mechanisms to adapt coding dynamically based on = acknowledgments for example. In the QUICK implementation we will have = flag a RECOVERED packet that could be used to adapt the coding rate. = Other implementations or code-specific protocols are also available. >>=20 >>>=20 >>> How a sender knows whether to do FEC, retransmission, or both FEC = and retransmission, dynamically? >>=20 >> Well the use of FEC (or not) is a design decision. Of course = you need the code (and the libraries). And then the decision will be = based on known link condition, goodput, expected performance, type of = traffic (video, time sensitive etc.). And finding a tunnel and PEPs if = you need to. And it can depend on path statistics and not being end to = end. I am not sure you could standardize that decision. >>=20 >>=20 >> So, speaking with no dots because I don't have any, I agree with what = Marie-Jose is saying here, but my understanding is that LOOPS endpoints = might turn LOOPS off completely if local optimizations aren't needed. So = I'm thinking about how a sender makes that decision, and how a sender = might do trade-offs.=20 >>=20 >> I think one point in discussions with Marie-Jose might be that she's = thinking in terms of Technical Specifications = (https://tools.ietf.org/html/rfc2026#section-3.1 = ), which are necessary, = but discussions are making me think that proponents might usefully also = think in terms of Applicability Statements = (https://tools.ietf.org/html/rfc2026#section-3.2 = ), which (quoting)=20 >>=20 >> An Applicability Statement specifies how, and under what >> circumstances, one or more TSs may be applied to support a = particular >> Internet capability. An AS may specify uses for TSs that are not >> Internet Standards, as discussed in Section 7. >>=20 >> An AS identifies the relevant TSs and the specific way in which = they >> are to be combined, and may also specify particular values or = ranges >> of TS parameters or subfunctions of a TS protocol that must be >> implemented.. An AS also specifies the circumstances in which the = use >> of a particular TS is required, recommended, or elective (see = section >> 3.3). >>=20 >> An AS may describe particular methods of using a TS in a = restricted >> "domain of applicability", such as Internet routers, terminal >> servers, Internet systems that interface to Ethernets, or = datagram- >> based database servers. >>=20 >> So, if Applicability Statements (also standards-track documents) = would be helpful for LOOPS deployment and operation, the proponents = might think about whether they want to do work in that space.=20 >>=20 >> If decisions about what senders do turn out to be entirely up to the = sender, that's great, but if the proponents want to bound the possible = behaviors of implementations to improve deployment and operation, that = might also be appropriate in BCPs = (https://tools.ietf.org/html/rfc2026#section-5 = ). >> =20 >>>=20 >>> How a sender knows that it shouldn't be doing anything, because = anything it does won't help ("first, do no harm")? >>=20 >> Of course in a congested network doing nothing is probably = best. Again there is a lot of work on the interaction of coding and = congestion control. >>=20 >> Not everyone knows the things but there has been a lot of work = in FECFRAME (in IETF) and NWCRG. Someone did mention that a lot of the = work was done in a research group not a working group. But real = implementations exist in famous =E2=80=9Cnetworks".=20 >>=20 >> Right - so one possibility is publishing work from NWCRG in the IETF = stream, and especially standards-track, with appropriate review by the = IETF community. That could take a lot of forms (RGs and WGs can interact = in a lot of different ways).=20 >=20 > An IETF WG could have a work item to develop a standards track FEC = scheme based on the research previously done in NWCRG, certainly. >> Since most of your questions are about erasure coding (coding = for packet loss) is that a direction LOOPS wants to take? Somekind of = nwcWG? >>=20 >>=20 >> See Mirja's note about chartering work, and only chartering working = groups when that's needed. But as you note, the FECFRAME extensions = happened in TSVWG, so that would be a reasonable conversation to have = with TSVWG chairs (and I note that Wes Eddy, who popped up further down = in this thread, is a TSVWG co-chair). If it fits, TSVWG could be a plan. = If it doesn't fit in an existing working group, NWCWG could be a plan. =20= >=20 > I perhaps misunderstood LOOPS, but I=E2=80=99d assumed that =E2=80=93 = to the extent is uses FEC and not retransmission =E2=80=93 it=E2=80=99d = pull in one of the schemes developed in FECFRAME. Has there been any = requirements analysis to show if anything further is needed? >=20 > That's the analysis that I'm suggesting the proponents work on now. I = didn't talk to all the proponents in Montreal, but at least a couple = were pretty sure they wanted to use FEC, but were still figuring out = details on that usage.=20 >=20 > Marie-Jose and some other nice people from NWCRG are providing = pointers to help with that analysis. For which, I'm grateful. I was the = responsible AD for the recent sliding window FECFRAME extensions that = migrated through TSVWG, and I understand FECFRAME at a 10,000-meter = level, but the proponents (and interested parties) need to work through = the next level of details. >=20 > This is separate to the question of whether there's work in NWCRG = that=E2=80=99s ready to move into IETF for standardisation, of course.=20= >=20 > The nice thing about the existing relationship between NWCRG and TSVWG = is that if there's more stuff from NWCRG that's ready to standardize in = the IETF, we know how to do that, and Wes Eddy (one of the TSVWG = co-chairs) is already helping with congestion discussion on this mailing = list. >=20 > I think the non-working group-forming BOF did a good job at flushing = out the questions and the resources needed to answer them. Thanks, = Magnus and Mirja, for making that easy. >=20 > Spencer >=20 > Colin >=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ = --Apple-Mail=_7498BA51-6778-4399-85E0-FC48ECF9CA7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Agree= - thanks, Spencer.
    Colin



    On 31 = Jul 2019, at 14:18, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

    Hi, Colin,

    On Wed, Jul = 31, 2019, 07:36 Colin Perkins <csp@csperkins.org> wrote:
    On 30 Jul 2019, at 18:43, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:

    I'm = going to be replying to two or three e-mail in this thread, so I'll try = to be coherent over my replies .... 

    On Tue, Jul = 30, 2019 at 9:42 AM Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
    Since most of your questions are related to FEC I copy = the nwcrg. See <mjm> below

    mjm

    M= arie-Jos=C3=A9 Montpetit, Ph.D.
    Research Affiliate, MIT = Media Laboratory
    mariejose@mjmontpetit.com
    mariejo@mit.edu

    On = July 30, 2019 at 10:23:04 AM, Spencer Dawkins at IETF (spencerdawkins.ietf@gmail.com) = wrote:

    Hi, = Mirja, 

    On Tue, Jul 30, 2019 at 5:34 AM Mirja = Kuehlewind <ietf@kuehlewind.net> wrote:
    Hi Carsten, = hi Spencer,

    > On 25. Jul 2019, at 20:59, = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> = wrote:
    >
    > My impression, and Magnus = might say I'm insane, was that Magnus is right on the edge of whether = this work can be chartered without a second, working group-forming BOF. = If the LOOPS community can't live without host-to-node, the community = should add it. If the community can make use of LOOPS without = host-to-node and add it later, the community might consider whether that = reduces the scope of the initial proposed charter enough to help Magnus = approve it :-)

    Yes, it would be possible to = charter without another BoF a small and well-scoped group, however, it = also would be possible to work on small and well-defined pieces of work = without a new working group. This was one of the reasons why this was = not a non-wg-forming BoF because it is not clear yet if a new group is = needed or the resulting pieces of standardization work are small enough = to fit into an existing group.

    Therefore, I = really recommend focus on defining the standardising work items that you = think are needed rather than trying to do any word-smithing of a = potential charter (that eventually is not needed).

    Thanks for giving me the chance to clarify - I really was = talking about chartering work, not just chartering a working group, but = that wasn't clear from my note. As you said, knowing what the work is, = in more detail, will help you and Magnus know what to do = next. 

    So, = my suggestion for the interested community is to nail down
    1. In order to "do LOOPS", what = already exists, that can be used without changes?
    2. what = already exists, but needs to be extended for LOOPS?
    3. what needs to be created, because nothing exists that meets = the needs?
     I'm not a LOOPS proponent (the ADs asked me to = chair the BOF about a month before IETF 105), but speaking as someone = who hasn't been involved in depth, I wonder about
    1. How a sender tunes FEC = dynamically - is that automatic, based on FEC mechanisms people are = thinking about, or is there work to do = there?
    <mjm> There are FEC mechanisms to adapt coding = dynamically based on acknowledgments for example. In the QUICK = implementation we will have flag a RECOVERED packet that could be used = to adapt the coding rate. Other implementations or code-specific = protocols are also available.


    1. How a sender knows whether to do FEC, retransmission, or both = FEC and retransmission, = dynamically?

    <mjm> Well the use of FEC (or not) is a design = decision.  Of course you need the code (and the libraries). And = then the decision will be based on known link condition, goodput, = expected performance, type of traffic (video, time sensitive etc.). And = finding a tunnel and PEPs if you need to. And it can depend on path = statistics and not being end to end. I am not sure you could standardize = that decision.


    So, speaking with no dots because I = don't have any, I agree with what Marie-Jose is saying here, but my = understanding is that LOOPS endpoints might turn LOOPS off completely if = local optimizations aren't needed. So I'm thinking about how a sender = makes that decision, and how a sender might do = trade-offs. 

    I think one point in discussions with Marie-Jose might be = that she's thinking in terms of Technical Specifications (https://tools.ietf.org/html/rfc2026#section-3.1), which = are necessary, but discussions are making me think that proponents might = usefully also think in terms of Applicability Statements (https://tools.ietf.org/html/rfc2026#section-3.2), which = (quoting) 

       An Applicability Statement specifies how, and = under what
       circumstances, one or more TSs may = be applied to support a particular
       Internet = capability.  An AS may specify uses for TSs that are not
       Internet Standards, as discussed in Section = 7.

       An AS identifies the = relevant TSs and the specific way in which they
      =  are to be combined, and may also specify particular values or = ranges
       of TS parameters or subfunctions of a = TS protocol that must be
       implemented..  = An AS also specifies the circumstances in which the use
       of a particular TS is required, recommended, or = elective (see section
       3.3).

       An AS may describe particular methods of using a = TS in a restricted
       "domain of applicability", = such as Internet routers, terminal
       servers, = Internet systems that interface to Ethernets, or datagram-
       based database servers.

    So, if Applicability = Statements (also standards-track documents) would be helpful for LOOPS = deployment and operation, the proponents might think about whether they = want to do work in that space. 

    If decisions about what senders do turn = out to be entirely up to the sender, that's great, but if the proponents = want to bound the possible behaviors of implementations to improve = deployment and operation, that might also be appropriate in BCPs (https://tools.ietf.org/html/rfc2026#section-5).
     

    1. How a sender knows that it shouldn't be doing anything, because = anything it does won't help ("first, do no = harm")?
    <= p class=3D""><mjm> Of course in a congested network doing nothing = is probably best. Again there is a lot of work on the interaction of = coding and congestion control.

    <mjm> Not everyone = knows the things but there has been a lot of work in FECFRAME (in IETF) = and NWCRG. Someone did mention that a lot of the work was done in a = research group not a working group. But real implementations exist in = famous =E2=80=9Cnetworks". 

    Right - so one possibility is publishing work from NWCRG in = the IETF stream, and especially standards-track, with appropriate review = by the IETF community. That could take a lot of forms (RGs and WGs can = interact in a lot of different = ways). 

    An IETF WG could have a work item to develop a = standards track FEC scheme based on the research previously done in = NWCRG, certainly.

    <mjm> = Since most of your questions are about erasure coding (coding for packet = loss) is that a direction LOOPS wants to take? Somekind of = nwcWG?


    See Mirja's note about chartering work, = and only chartering working groups when that's needed. But as you note, = the FECFRAME extensions happened in TSVWG, so that would be a reasonable = conversation to have with TSVWG chairs (and I note that Wes Eddy, who = popped up further down in this thread, is a TSVWG co-chair). If it fits, = TSVWG could be a plan. If it doesn't fit in an existing working group, = NWCWG could be a = plan.  

    I perhaps misunderstood LOOPS, but I=E2=80=99d assumed = that =E2=80=93 to the extent is uses FEC and not retransmission =E2=80=93 = it=E2=80=99d pull in one of the schemes developed in FECFRAME. Has there = been any requirements analysis to show if anything further is = needed?

    That's the = analysis that I'm suggesting the proponents work on now. I didn't talk = to all the proponents in Montreal, but at least a couple were pretty = sure they wanted to use FEC, but were still figuring out details on that = usage. 

    Marie-Jose and some other nice people from NWCRG = are providing pointers to help with that analysis. For which, I'm = grateful. I was the responsible AD for the recent sliding window = FECFRAME extensions that migrated through TSVWG, and I understand = FECFRAME at a 10,000-meter level, but the proponents (and interested = parties) need to work through the next level of details.

    This is separate to the = question of whether there's work in NWCRG that=E2=80=99s ready to move = into IETF for standardisation, of course. 

    The nice = thing about the existing relationship between NWCRG and TSVWG is that if = there's more stuff from NWCRG that's ready to standardize in the IETF, = we know how to do that, and Wes Eddy (one of the TSVWG co-chairs) is = already helping with congestion discussion on this mailing = list.

    I think the non-working group-forming BOF did a = good job at flushing out the questions and the resources needed to = answer them. Thanks, Magnus and Mirja, for making that easy.

    Spencer

    Colin




    -- 
    Colin Perkins
    https://csperkins.org/
    = = --Apple-Mail=_7498BA51-6778-4399-85E0-FC48ECF9CA7E-- From nobody Wed Jul 31 07:18:23 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723DC12006D for ; Wed, 31 Jul 2019 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9bb3IqgM7GMj for ; Wed, 31 Jul 2019 07:18:20 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4896612004F for ; Wed, 31 Jul 2019 07:18:20 -0700 (PDT) Received: from client-0158.vpn.uni-bremen.de (client-0158.vpn.uni-bremen.de [134.102.107.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45zFrp5mJ1z10Xl; Wed, 31 Jul 2019 16:18:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Wed, 31 Jul 2019 16:18:18 +0200 Cc: mohamed.boucadair@orange.com, Spencer Dawkins at IETF , Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , "loops@ietf.org" X-Mao-Original-Outgoing-Id: 586275490.653143-3df77ee1bcac8e2f10fa8e99c37f1d41 Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 14:18:22 -0000 On Jul 31, 2019, at 16:02, Marie-Jose Montpetit = wrote: >=20 > This is a very wide scope that covers many existing groups. Can you = focus on a narrower scope? Hi Marie-Jos=C3=A9, the scope of LOOPS as we went into IETF105 is written up at https://github.com/loops-wg/charter I=E2=80=99m not going to paraphrase this here, but the main elements = are: * Local recovery between cooperating LOOPS nodes that do not span the = entire end-to-end path * Related measurement mechanisms * Congestion feedback that doesn=E2=80=99t cause the loss recovery to = derail the end-to-end congestion control * Scope restriction: No involvement of end hosts needed * Scope restriction: Don=E2=80=99t look, don=E2=80=99t touch * Scope restriction: Setup via controller model * Technical approach: Don=E2=80=99t invent another tunnel encapsulation, = use existing ones (probably more than one) where they make sense The host-to-node discussion we had in IETF105 may be a bit confusing. = This was not about changing the transport protocols at the hosts so they = work better with in-network friends (this could also be done, but would = not be LOOPS as proposed). This is about using e.g. a VPN layer in a = host as one of the two cooperating LOOPS nodes. So the actual protocol = will be essentially the same, but there may be a modified setup model. The other need for modification that became apparent during IETF105 is = that we probably should ship a retransmission-only version of the = protocol before nailing down all the FEC-related parts. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 31 10:02:07 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6562C12051D for ; Wed, 31 Jul 2019 10:02:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRtk_xKRsn1Z for ; Wed, 31 Jul 2019 10:02:03 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 235931204C3 for ; Wed, 31 Jul 2019 10:02:03 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id o9so34248216iom.3 for ; Wed, 31 Jul 2019 10:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=PWWzSt/aFVVcFWLRyDdY7reLz8ZV9z2RsHUtHuFddGA=; b=Mp4VeVcvfMzSIg/Yr4SCE7vhQodD9KLoAtCAredGfZt4P+/l9hzXOk3u4g/2/Nlp4E zDOwcJXmgmtameX9xhBlMQvsjwj1vvo4Fb+jeDoF2VHQG58UwbpcYJrPYkwMsC3uLWCC IdoFzKaV0uzhWihiOkCzLBbrEHSJTt4s7DQIyP20hz5DCUer4/fQSZU1gROMtBbjooPB MKekzRVyi+9BDYih+PJChnhUGMmHS3V6jeiomKXX/frq+0quxavvXwXhOzfrnW2grVAk xYykRuB4LWc45hDsKln3RIp8iETIfPKhB/tKmDPh5MO9X2/sYYi4BCx+jTU5bdVFk5U+ edjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PWWzSt/aFVVcFWLRyDdY7reLz8ZV9z2RsHUtHuFddGA=; b=Pxf5nn6lDGD5TFpkhYtvP7XqvZvBF8W0l8VS1XGrZjIR9QsCNra957Sk0uneW4ZOX3 Iq2nmX3Ks4D5YIhZtYTrLWjE+VDLyneRTZ5MzSLv/AHhHOFHi9weWjOcAszM/yLOa2gM l++vHmWteuaJP9zFUdIfuyoq0bGeFO70VmGWOXJjvRmAjYpKgd0B/Xe5JQ7BgcxaCCcf RCjdREIaTnsww5D+6In9SOB1RID6JPdUJTXFiBPiJRbqwZOiMfgbf1vwjQpqU3SPReHM kqbO6fiPXkTA1hM7EGSjbp9JfvFLNvpWRBoyyVri/ABiYJgG6PVaFGWNMTr8/FjBlMT8 pbvg== X-Gm-Message-State: APjAAAVoUlaVurHM/2NEbKJvrUkzOsG6ipFt2m869oB7qudFvRW8vBT4 FU4tbEQEEUtcg5MVdZW0n6F4RkU50C75LLKI7N4= X-Google-Smtp-Source: APXvYqxAraJ3yfEoqT84ccatAKW0z9Du65xf1+AyQwrXkCwMhbttgIRFxFVoh0pAtRmZPGUcWcd4RYwz+bEVqAHP0OI= X-Received: by 2002:a02:85c7:: with SMTP id d65mr13462349jai.8.1564592522269; Wed, 31 Jul 2019 10:02:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2019 12:02:00 -0500 From: Marie-Jose Montpetit In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Wed, 31 Jul 2019 12:02:00 -0500 Message-ID: To: mohamed.boucadair@orange.com, Spencer Dawkins at IETF Cc: Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , "loops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008238bd058efd150b" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 17:02:06 -0000 --0000000000008238bd058efd150b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had read the charter :) And local/recovery and measurements is not very specific :) But ok I guess it will evolve. And as regard retransmission I am looking forward to see the results vs. a true erasure recovery mechanism in terms of efficiency and complexity. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com ( mohamed.boucadair@orange.com) wrote: Re-, Local recovery/local measurement isn=E2=80=99t specific enough? Cheers, Med *De :* Marie-Jose Montpetit [mailto:marie@mjmontpetit.com] *Envoy=C3=A9 :* mercredi 31 juillet 2019 16:02 *=C3=80 :* BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF *Cc :* Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; loops@ietf.org *Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps This is a very wide scope that covers many existing groups. Can you focus on a narrower scope? Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com ( mohamed.boucadair@orange.com) wrote: Hi Spencer, all, I would restrict the host-to-network interaction to the minimum (read ECN) in the initial scope of the this proposed work. FWIW, below a tentative scope we included in the use-cases I-D: =3D=3D=3D=3D=3D=3D=3D=3D=3D investigate to what extent a network-assisted approach can contribute to increase the overall perceived quality of experience in specific situations (e.g., Sections 3.5 and 3.6 of [RFC8517 ]) without requiring access to internal transport primitives. The rationale beneath this approach is that some information (loss detection, better visibility on available paths and their characteristics, etc.) can be used to trigger local actions while avoiding as much as possible undesired side effects (e.g., expose a behavior that would be interpreted by an endpoint as an anomaly (corrupt data) and which would lead to exacerbate end-to-end recovery. Such local actions would have a faster effect (e.g., faster recovery, used multiple paths simultaneously). To that aim, the work is structured into two (2) phased stages: o Stage 1: Network-assisted optimization. This one assumes that optimizations (e.g., support latency-sensitive applications) can be implemented at the network without requiring defining new interaction with the endpoint. Existing tools such as ECN will be used. Some of these optimizations may be valuable in deployments where communications are established over paths that are not exposing the same performance characteristics. o Stage 2: Collaborative networking optimization. This one requires more interaction between the network and an endpoint to implement coordinated and more surgical network-assisted optimizations based on information/instructions shared by an endpoint or sharing locally-visible information with endpoint for better and faster recovery. Effort related to the second stage is out of scope of the initial planned work. Nevertheless, future work will be planned once progress is (hopefully) made on the first stage. =3D=3D=3D=3D=3D Cheers, Med *De :* LOOPS [mailto:loops-bounces@ietf.org] *De la part de* Spencer Dawkins at IETF *Envoy=C3=A9 :* jeudi 25 juillet 2019 20:59 *=C3=80 :* Carsten Bormann *Cc :* Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; loops@ietf.org; Suresh Krishnan *Objet :* Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps Still wearing no hats, because I no longer have any dots ... On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann wrote: On Jul 24, 2019, at 18:17, Marie-Jose Montpetit wrote: > > Standardisation of what? The architecture? The protocols (beware there is already FECFRAME and others)? The proxies? Hi Marie-Jos=C3=A9, details of the thinking that was developed in the side meetings that happened at the previous two IETF meetings can be found at https://github.com/loops-wg/charter The BOF actually added one piece of information I didn=E2=80=99t previously perceive that way: People seem to really want to tackle the host-to-node case (as needed, e.g., for going through WiFi access clouds) right away, not just the in-network (node-to-node) case. That would be the one thing I would change based on my recollection of the BOF. But of course there may be other things; it may be worth to now have another round of discussion of the proposed charter. Communication is good, but one thing I mentioned in my summary of my chat with the ADs was - Here's a hint from the ADs - if the proponents can come up with a clear charter, limited in scope, that will make their lives easier, and make it easier for them to charter this work :D So, it's reasonable for the LOOPS community to consider adding host-to-node, but it's worth checking whether this would expand the scope of the requested charter, and whether excluding host-to-node makes the initial work easier to complete. My impression, and Magnus might say I'm insane, was that Magnus is right on the edge of whether this work can be chartered without a second, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it. If the community can make use of LOOPS without host-to-node and add it later, the community might consider whether that reduces the scope of the initial proposed charter enough to help Magnus approve it :-) Best wishes, Spencer --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --0000000000008238bd058efd150b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    I ha= d read the charter :)=C2=A0

    And local/recovery and measurements is not very specific :) But ok= I guess it will evolve.

    And as regard retransmission I am looking forward to see the results = vs. a true erasure recovery mechanism in terms of efficiency and complexity= .

    =
    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Research = Affiliate, MIT Media Laboratory

    On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com (mohamed.boucadair@orange.com) wrote:

    Re-,

    =C2=A0

    Local recovery/local measuremen= t isn=E2=80=99t specific enough?

    =C2=A0

    Cheers,

    Med

    =C2=A0

    De=C2=A0: Mari= e-Jose Montpetit [mailto:marie@mjm= ontpetit.com]
    Envoy=C3=A9=C2=A0: mercredi 31 juillet 2019 16:02
    =C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF
    Cc=C2=A0: Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; loops@ietf.org
    Objet=C2=A0: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps<= /span>

    =C2=A0

    This is a very wide scope that covers = many existing groups. Can you focus on a narrower scope?

    =C2=A0

    Marie-Jos=C3=A9 Montpetit, Ph.D.

    Research Affiliate, MIT Media Laborato= ry

    =C2=A0

    On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.co= m (mohamed.boucadair@or= ange.com) wrote:

    Hi Spencer, all,

    =C2=A0

    I would restrict the host-to-network interact= ion to the minimum (read ECN) in the initial scope of the this proposed work. FWIW, below a tentative scope we included in th= e use-cases I-D:

    =C2=A0

    =3D=3D=3D=3D=3D=3D=3D=3D=3D

    =C2=A0=C2=A0 investigate to what extent a network-assiste= d approach can contribute

    =C2=A0=C2=A0 to increase the overall perceived quality of= experience in specific

    =C2=A0=C2=A0 situations (e.g., Sections 3.5 and 3.6 of [RFC8517]= ) without

    =C2=A0=C2=A0 requiring access to internal transport primi= tives.=C2=A0 The rationale

    =C2=A0=C2=A0 beneath this approach is that some informati= on (loss detection,

    =C2=A0=C2=A0 better visibility on available paths and the= ir characteristics, etc.)

    =C2=A0=C2=A0 can be used to trigger local actions while a= voiding as much as

    =C2=A0=C2=A0 possible undesired side effects (e.g., expos= e a behavior that would

    =C2=A0=C2=A0 be interpreted by an endpoint as an anomaly = (corrupt data) and which

    =C2=A0=C2=A0 would lead to exacerbate end-to-end recovery= .=C2=A0 Such local actions

    =C2=A0=C2=A0 would have a faster effect (e.g., faster rec= overy, used multiple

    =C2=A0=C2=A0 paths simultaneously).

    =C2=A0

    =C2=A0=C2=A0 To that aim, the work is structured into two= (2) phased stages:

    =C2=A0

    =C2=A0=C2=A0 o=C2=A0 Stage 1: Network-assisted optimizati= on.=C2=A0 This one assumes that

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 optimizations (e.g., suppo= rt latency-sensitive applications) can

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be implemented at the netw= ork without requiring defining new

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interaction with the endpo= int.=C2=A0 Existing tools such as ECN will be

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 used.=C2=A0 Some of these = optimizations may be valuable in deployments

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where communications are e= stablished over paths that are not

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 exposing the same performa= nce characteristics.

    =C2=A0

    =C2=A0=C2=A0 o=C2=A0 Stage 2: Collaborative networking op= timization.=C2=A0 This one requires

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 more interaction between t= he network and an endpoint to implement

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 coordinated and more surgi= cal network-assisted optimizations based

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on information/instruction= s shared by an endpoint or sharing

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 locally-visible informatio= n with endpoint for better and faster

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recovery.

    =C2=A0

    =C2=A0=C2=A0 Effort related to the

    =C2=A0=C2=A0 second stage is out of scope of the initial = planned work.

    =C2=A0=C2=A0 Nevertheless, future work will be planned on= ce progress is

    =C2=A0=C2=A0 (hopefully) made on the first stage.<= /p>

    =3D=3D=3D=3D=3D

    =C2=A0

    Cheers,

    Med

    =C2=A0

    De=C2=A0: LOOPS [mailto:loops-bounces@ietf.org] De la part de Spencer Dawkins at IETF
    Envoy=C3=A9=C2=A0: jeudi 25 juillet 2019 20:59
    =C3=80=C2=A0: Carsten Bormann
    Cc=C2=A0: Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind;= loops@ietf.org; Suresh Krishnan
    Objet=C2=A0: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps<= /span>

    =C2=A0

    Still wearing no hats, because I no longer have any dots ...

    =C2=A0

    On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann <cabo@tzi.org> wrote:

    On Jul 24, 2019, at 18:17, Marie-Jose Montpetit <marie@mjmontpetit.com> = wrote:
    >
    > Standardisation of what? The architecture? The protocols (beware there= is already FECFRAME and others)? The proxies?

    Hi Marie-Jos=C3=A9,

    details of the thinking that was developed in the side meetings that happen= ed at the previous two IETF meetings can be found at

    https://g= ithub.com/loops-wg/charter

    The BOF actually added one piece of information I didn=E2=80=99t previously= perceive that way:
    People seem to really want to tackle the host-to-node case (as needed, e.g.= , for going through WiFi access clouds) right away, not just the in-network= (node-to-node) case.=C2=A0 That would be the one thing I would change base= d on my recollection of the BOF.=C2=A0 But of course there may be other things; it may be worth to now have another r= ound of discussion of the proposed charter.

    =C2=A0

    Communication is good, but one thing I mentioned in my summary of = my chat with the ADs was

    • Here's a hint from the ADs - if the proponents can come u= p with a clear charter, limited in scope, that will make their lives easier= , and make it easier for them to charter this work :D=C2=A0

      • So, it's reasonable for the LOOPS community to consider adding= host-to-node, but it's worth checking whether this would expand the sc= ope of the requested charter, and whether excluding host-to-node makes the initial work easier to complete.=C2=A0

    =C2=A0

    My impression, and Magnus might say I'm insane, was that Magnu= s is right on the edge of whether this work can be chartered without a seco= nd, working group-forming BOF. If the LOOPS community can't live without host-to-node, the community should add it= . If the community can make use of LOOPS without host-to-node and add it la= ter, the community might consider whether that reduces the scope of the ini= tial proposed charter enough to help Magnus approve it :-)=C2=A0

    =C2=A0

    Best wishes,=C2=A0

    =C2=A0

    Spencer

    --
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.or= g/mailman/listinfo/loops

    --0000000000008238bd058efd150b-- From nobody Wed Jul 31 15:18:41 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211412001E for ; Wed, 31 Jul 2019 15:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w_3AVdGz1cB for ; Wed, 31 Jul 2019 15:18:36 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 931F9120046 for ; Wed, 31 Jul 2019 15:18:35 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1hswvU-0005Gf-0q; Thu, 01 Aug 2019 00:18:28 +0200 Received: from 178.115.130.27.wireless.dyn.drei.com ([178.115.130.27] helo=[192.168.1.162]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92) (envelope-from ) id 1hswvQ-000EGr-KF; Thu, 01 Aug 2019 00:18:27 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_23746E50-1248-4942-97F7-AFE17F78500D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 1 Aug 2019 00:18:20 +0200 In-Reply-To: Cc: mohamed.boucadair@orange.com, Spencer Dawkins , Magnus Westerlund , Mirja Kuehlewind , Suresh Krishnan , "loops@ietf.org" To: Marie-Jose Montpetit References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 178.115.130.27 is neither permitted nor denied by domain of ifi.uio.no) client-ip=178.115.130.27; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.162]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 115C52AAEDBAF633DFBEF7DCBEE74A5351B778C7 Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 22:18:40 -0000 --Apple-Mail=_23746E50-1248-4942-97F7-AFE17F78500D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, About the retransmission vs FEC (erasure coding) point, I don=E2=80=99t = think anyone would suggest a comparison? Isn=E2=80=99t it clear to everybody that FEC is strictly better than = retransmission if the packet loss ratio is known and it=E2=80=99s = possible to add forward information? (else, why would FEC exist?) But I agree with Carsten that we should probably do retransmission-only = first - it makes things simpler. For one, a pure retransmission-based mechanism can work without adding = any forward information. And, when one *can* add forward information, = FEC is an obvious =E2=80=9C++" that shouldn=E2=80=99t change anything = about the architecture but simply make things better. Just my 2c Cheers, Michael > On Jul 31, 2019, at 7:02 PM, Marie-Jose Montpetit = wrote: >=20 > I had read the charter :)=20 >=20 > And local/recovery and measurements is not very specific :) But ok I = guess it will evolve. >=20 > And as regard retransmission I am looking forward to see the results = vs. a true erasure recovery mechanism in terms of efficiency and = complexity.. >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu > On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com = (mohamed.boucadair@orange.com = ) wrote: >=20 >> Re-, >>=20 >> =20 >> Local recovery/local measurement isn=E2=80=99t specific enough? >>=20 >> =20 >> Cheers, >>=20 >> Med >>=20 >> =20 >> De : Marie-Jose Montpetit [mailto:marie@mjmontpetit.com = ]=20 >> Envoy=C3=A9 : mercredi 31 juillet 2019 16:02 >> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Spencer Dawkins at IETF >> Cc : Suresh Krishnan; Magnus Westerlund; Mirja Kuehlewind; = loops@ietf.org >> Objet : Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps >>=20 >> =20 >> This is a very wide scope that covers many existing groups. Can you = focus on a narrower scope? >>=20 >> =20 >> Marie-Jos=C3=A9 Montpetit, Ph.D. >>=20 >> Research Affiliate, MIT Media Laboratory >>=20 >> mariejose@mjmontpetit.com >> mariejo@mit.edu >> =20 >> On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com = (mohamed.boucadair@orange.com = ) wrote: >>=20 >> Hi Spencer, all, >>=20 >> =20 >> I would restrict the host-to-network interaction to the minimum (read = ECN) in the initial scope of the this proposed work. FWIW, below a = tentative scope we included in the use-cases I-D: >>=20 >> =20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> investigate to what extent a network-assisted approach can = contribute >>=20 >> to increase the overall perceived quality of experience in = specific >>=20 >> situations (e.g., Sections 3.5 = and 3.6 = of [RFC8517 ]) = without >>=20 >> requiring access to internal transport primitives. The rationale >>=20 >> beneath this approach is that some information (loss detection, >>=20 >> better visibility on available paths and their characteristics, = etc.) >>=20 >> can be used to trigger local actions while avoiding as much as >>=20 >> possible undesired side effects (e.g., expose a behavior that = would >>=20 >> be interpreted by an endpoint as an anomaly (corrupt data) and = which >>=20 >> would lead to exacerbate end-to-end recovery.. Such local actions >>=20 >> would have a faster effect (e.g., faster recovery, used multiple >>=20 >> paths simultaneously). >>=20 >> =20 >> To that aim, the work is structured into two (2) phased stages: >>=20 >> =20 >> o Stage 1: Network-assisted optimization. This one assumes that >>=20 >> optimizations (e.g., support latency-sensitive applications) = can >>=20 >> be implemented at the network without requiring defining new >>=20 >> interaction with the endpoint. Existing tools such as ECN will = be >>=20 >> used. Some of these optimizations may be valuable in = deployments >>=20 >> where communications are established over paths that are not >>=20 >> exposing the same performance characteristics. >>=20 >> =20 >> o Stage 2: Collaborative networking optimization. This one = requires >>=20 >> more interaction between the network and an endpoint to = implement >>=20 >> coordinated and more surgical network-assisted optimizations = based >>=20 >> on information/instructions shared by an endpoint or sharing >>=20 >> locally-visible information with endpoint for better and faster >>=20 >> recovery. >>=20 >> =20 >> Effort related to the >>=20 >> second stage is out of scope of the initial planned work. >>=20 >> Nevertheless, future work will be planned once progress is >>=20 >> (hopefully) made on the first stage. >>=20 >> =3D=3D=3D=3D=3D >>=20 >> =20 >> Cheers, >>=20 >> Med >>=20 >> =20 >> De : LOOPS [mailto:loops-bounces@ietf.org = ] De la part de Spencer Dawkins at IETF >> Envoy=C3=A9 : jeudi 25 juillet 2019 20:59 >> =C3=80 : Carsten Bormann >> Cc : Magnus Westerlund; Marie-Jose Montpetit; Mirja Kuehlewind; = loops@ietf.org ; Suresh Krishnan >> Objet : Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps >>=20 >> =20 >> Still wearing no hats, because I no longer have any dots ... >>=20 >> =20 >> On Thu, Jul 25, 2019 at 12:56 AM Carsten Bormann > wrote: >>=20 >> On Jul 24, 2019, at 18:17, Marie-Jose Montpetit = > wrote: >> >=20 >> > Standardisation of what? The architecture? The protocols (beware = there is already FECFRAME and others)? The proxies? >>=20 >> Hi Marie-Jos=C3=A9, >>=20 >> details of the thinking that was developed in the side meetings that = happened at the previous two IETF meetings can be found at >>=20 >> https://github.com/loops-wg/charter = >>=20 >> The BOF actually added one piece of information I didn=E2=80=99t = previously perceive that way: >> People seem to really want to tackle the host-to-node case (as = needed, e.g., for going through WiFi access clouds) right away, not just = the in-network (node-to-node) case. That would be the one thing I would = change based on my recollection of the BOF. But of course there may be = other things; it may be worth to now have another round of discussion of = the proposed charter. >>=20 >> =20 >> Communication is good, but one thing I mentioned in my summary of my = chat with the ADs was >>=20 >> Here's a hint from the ADs - if the proponents can come up with a = clear charter, limited in scope, that will make their lives easier, and = make it easier for them to charter this work :D=20 >> So, it's reasonable for the LOOPS community to consider adding = host-to-node, but it's worth checking whether this would expand the = scope of the requested charter, and whether excluding host-to-node makes = the initial work easier to complete.=20 >>=20 >> =20 >> My impression, and Magnus might say I'm insane, was that Magnus is = right on the edge of whether this work can be chartered without a = second, working group-forming BOF. If the LOOPS community can't live = without host-to-node, the community should add it.. If the community can = make use of LOOPS without host-to-node and add it later, the community = might consider whether that reduces the scope of the initial proposed = charter enough to help Magnus approve it :-)=20 >>=20 >> =20 >> Best wishes,=20 >>=20 >> =20 >> Spencer >>=20 >> --=20 >> LOOPS mailing list=20 >> LOOPS@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/loops = --=20 > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops --Apple-Mail=_23746E50-1248-4942-97F7-AFE17F78500D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

    About = the retransmission vs FEC (erasure coding) point, I don=E2=80=99t think = anyone would suggest a comparison?
    Isn=E2=80=99t it = clear to everybody that FEC is strictly better than retransmission if = the packet loss ratio is known and it=E2=80=99s possible to add forward = information?
    (else, why would FEC exist?)

    But I agree with Carsten = that we should probably do retransmission-only first - it makes things = simpler.
    For one, a pure retransmission-based = mechanism can work without adding any forward information. And, when one = *can* add forward information, FEC is an obvious =E2=80=9C++" that = shouldn=E2=80=99t change anything about the architecture but simply make = things better.

    Just my 2c

    Cheers,
    Michael


    On Jul 31, 2019, at 7:02 PM, Marie-Jose = Montpetit <marie@mjmontpetit.com> wrote:

    I had read the charter :) 

    And local/recovery and measurements = is not very specific :) But ok I guess it will evolve.

    And as regard retransmission I am = looking forward to see the results vs. a true erasure recovery mechanism = in terms of efficiency and complexity..

    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Research Affiliate, MIT Media Laboratory
    mariejose@mjmontpetit.com
    mariejo@mit.edu

    On July 31, 2019 at 10:06:12 AM, mohamed.boucadair@orange.com (mohamed.boucadair@orange.com) wrote:

    Re-,

     

    Local recovery/local measurement isn=E2=80=99t = specific enough?

     

    Cheers,

    Med

     
    De : Marie-Jose = Montpetit [mailto:marie@mjmontpetit.com] 
    Envoy=C3=A9 : mercredi 31 juillet 2019 = 16:02
    =C3=80 : BOUCADAIR Mohamed TGI/OLN; = Spencer Dawkins at IETF
    Cc : Suresh Krishnan; Magnus = Westerlund; Mirja Kuehlewind; loops@ietf.org
    Objet : Re: [LOOPS] BOF co-chairs = thinking on LOOPS next steps

     

    This is a very wide = scope that covers many existing groups. Can you focus on a narrower = scope?

     

    Marie-Jos=C3=A9 Montpetit, = Ph.D.

    Research Affiliate, MIT Media Laboratory

    mariejose@mjmontpetit.com

    mariejo@mit.edu

     

    On July 31, 2019 at 9:55:37 AM, mohamed.boucadair@orange.com (mohamed.boucadair@orange.com) = wrote:

    Hi Spencer, all,

     

    I would restrict the host-to-network interaction = to the minimum (read ECN) in the initial scope of the this proposed = work. FWIW, below a tentative scope we included in the use-cases = I-D:

     

    =3D=3D=3D=3D=3D=3D=3D=3D=3D

       investigate to what extent = a network-assisted approach can contribute

       to increase the overall = perceived quality of experience in specific

       situations (e.g., = Sections 3.5 and 3.6 of [RFC8517]) without

       requiring access to = internal transport primitives.  The rationale

       beneath this approach is = that some information (loss detection,

       better visibility on = available paths and their characteristics, etc.)

       can be used to trigger = local actions while avoiding as much as

       possible undesired side = effects (e.g., expose a behavior that would

       be interpreted by an = endpoint as an anomaly (corrupt data) and which

       would lead to exacerbate = end-to-end recovery..  Such local actions

       would have a faster effect = (e.g., faster recovery, used multiple

       paths = simultaneously).

     

       To that aim, the work is = structured into two (2) phased stages:

     

       o  Stage 1: = Network-assisted optimization.  This one assumes that

          optimizations (e.g., = support latency-sensitive applications) can

          be implemented at the = network without requiring defining new

          interaction with the = endpoint.  Existing tools such as ECN will be

          used.  Some of these = optimizations may be valuable in deployments

          where communications are = established over paths that are not

          exposing the same = performance characteristics.

     

       o  Stage 2: = Collaborative networking optimization.  This one = requires

          more interaction between = the network and an endpoint to implement

          coordinated and more = surgical network-assisted optimizations based

          on information/instructions = shared by an endpoint or sharing

          locally-visible information = with endpoint for better and faster

          recovery.

     

       Effort related to = the

       second stage is out of = scope of the initial planned work.

       Nevertheless, future work = will be planned once progress is

       (hopefully) made on the = first stage.

    =3D=3D=3D=3D=3D

     

    Cheers,

    Med

     

    De : LOOPS [mailto:loops-bounces@ietf.org] De la part = de Spencer Dawkins = at IETF
    Envoy=C3=A9 : jeudi 25 juillet 2019 = 20:59
    =C3=80 : Carsten Bormann
    Cc : Magnus Westerlund; = Marie-Jose Montpetit; Mirja Kuehlewind; loops@ietf.org; Suresh = Krishnan
    Objet : Re: [LOOPS] BOF co-chairs = thinking on LOOPS next steps

     

    Still wearing no hats, = because I no longer have any dots ...

     

    On Thu, Jul 25, 2019 at 12:56 AM = Carsten Bormann <cabo@tzi.org> wrote:

    On Jul 24, 2019, at 18:17, Marie-Jose Montpetit = <marie@mjmontpetit.com> wrote:
    > 
    > = Standardisation of what? The architecture? The protocols (beware there = is already FECFRAME and others)? The proxies?

    Hi Marie-Jos=C3=A9,

    details of = the thinking that was developed in the side meetings that happened at = the previous two IETF meetings can be found at

    https://github.com/loops-wg/charter

    The BOF actually added one piece of = information I didn=E2=80=99t previously perceive that way:
    People seem to really want to tackle the host-to-node case = (as needed, e.g., for going through WiFi access clouds) right away, not = just the in-network (node-to-node) case.  That would be the one = thing I would change based on my recollection of the BOF.  But of = course there may be other things; it may be worth to now have another = round of discussion of the proposed charter.

     

    Communication is good, but one thing I mentioned in = my summary of my chat with the ADs was

    • Here's a hint from = the ADs - if the proponents can come up with a clear charter, limited in = scope, that will make their lives easier, and make it easier for them to = charter this work :D 

    So, it's reasonable for the LOOPS community to = consider adding host-to-node, but it's worth checking whether this would = expand the scope of the requested charter, and whether excluding = host-to-node makes the initial work easier to = complete. 

     

    My impression, and Magnus might say I'm insane, was = that Magnus is right on the edge of whether this work can be chartered = without a second, working group-forming BOF. If the LOOPS community = can't live without host-to-node, the community should add it.. If the = community can make use of LOOPS without host-to-node and add it later, = the community might consider whether that reduces the scope of the = initial proposed charter enough to help Magnus approve it = :-) 

     

    Best wishes, 

     

    Spencer

    -- 
    LOOPS = mailing list 
    LOOPS@ietf.org 
    https://www.ietf.org/mailman/listinfo/loops

    -- 
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.org/mailman/listinfo/loops

    = --Apple-Mail=_23746E50-1248-4942-97F7-AFE17F78500D-- From nobody Wed Jul 31 16:11:39 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA61200FF for ; Wed, 31 Jul 2019 16:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5Oddn8LqioCl for ; Wed, 31 Jul 2019 16:11:36 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087311200B5 for ; Wed, 31 Jul 2019 16:11:36 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45zTh62x0NzytS; Thu, 1 Aug 2019 01:11:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: Date: Thu, 1 Aug 2019 01:11:33 +0200 Cc: "loops@ietf.org" X-Mao-Original-Outgoing-Id: 586307491.903236-80bc30139cd2f3674bc4fd0056d6fe6e Content-Transfer-Encoding: quoted-printable Message-Id: <7C016290-2FB9-4DCF-9213-749B2B27D4D0@tzi.org> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Michael Welzl X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 23:11:37 -0000 On Aug 1, 2019, at 00:18, Michael Welzl wrote: >=20 > if the packet loss ratio is known Conversely, retransmission can be better to handle random, bursty = losses. (For a definition of =E2=80=9Cbetter=E2=80=9D, which may depend on your = needs.) But more importantly, for retransmission, the ingress node needs to = store copies of packets for a while (and retransmit from this cache), = and the egress node needs to send ACKs. This is much less work per = packet than doing FEC, which needs processing of the contents of each = packet. So nodes may be able to do retransmission LOOPS at a higher = rate than they would be able to do FEC LOOPS. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 31 16:28:09 2019 Return-Path: X-Original-To: loops@ietfa.amsl.com Delivered-To: loops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6F120105 for ; Wed, 31 Jul 2019 16:28:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 787V3ZQetuNG for ; Wed, 31 Jul 2019 16:28:06 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 9384E1200B5 for ; Wed, 31 Jul 2019 16:28:06 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id j6so20361916ioa.5 for ; Wed, 31 Jul 2019 16:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=vohNMMoETPqenNm2LO57QhS95jCY1DBwIhiCIAVdKaE=; b=j6MrUh6uHEwiX22BJPm7zcoopgVlKGY38FLXteqXqsOeJNUvlmGonQzlAXqvugexq6 2BaTY7eVKo+nxXaI7BehYli66SOB0/qAaMMmg7uawMjFeLy/Oa18QdrHJeAsbdoa+Un+ IZvHfZVr55VglGDDHYkGeXNy+Gc3ako/xW1d2LgXWKeeRoSwagUwrjDpBlUPihpW3N81 22QPiiUHD9NJ1c0G9TQt9XzwbB54rk5It4Me8+gpWSJ/wYDrOW23wOLfboyyVXH/lBn0 pCIQR9LlgUUXhT1SR1tSozdfDTpm9w2vleXHLCHyKFrdZoBhyv3FPr+YeL4w4tqvwAmP xKNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=vohNMMoETPqenNm2LO57QhS95jCY1DBwIhiCIAVdKaE=; b=EGN/wyC6YHLM0thtv1UPJc+JJYgbRDq65FKAuR5GDr2qFcgpqtxv3liXVOuLK6oSQf r3jjHzbuYMvXnK594CLie5mRyzZbPZo8COvJzd77oJgtpteE/iaCCuB87dbbEqNu7pxS Jt2gzyhr2mG80Gw3d9amrIb8tAbrWOv5Na3kEil93h20Q4CzOvoaxX0a6clRbuWFx+bu xTLeILBDVrwAN9zDWW5IxCc7IC8FC3qEAN8TILVkPPWMErfjTcTfhBSSkzd3NRRR6DbS HfsExdif/Tn2fJaRGXZzBuVV7/b5ZCEoJaig0mxNiduU+ggm4w0mrGz6qND6UXBG+/Tb UkZw== X-Gm-Message-State: APjAAAUW6LaUs5JKFfFZRaV18gNA9oLCTBRLkA+U+IemOBA10CCD7ZJL Ew9VIlaCLWqgfyZC8ag7aB8oKjpTZ4+GEDykSSxIEIJR X-Google-Smtp-Source: APXvYqzCRD+oqeRjx8bEFOEcbZGiio7ZDuRoZEZ5IUkik8hK9VQMTKVNjL1pPR9n2gJfcu6hKVZ4E+cVTOpUarSCvKQ= X-Received: by 2002:a6b:6e01:: with SMTP id d1mr40151312ioh.156.1564615685718; Wed, 31 Jul 2019 16:28:05 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2019 18:28:04 -0500 From: Marie-Jose Montpetit In-Reply-To: <7C016290-2FB9-4DCF-9213-749B2B27D4D0@tzi.org> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7C016290-2FB9-4DCF-9213-749B2B27D4D0@tzi.org> MIME-Version: 1.0 Date: Wed, 31 Jul 2019 18:28:04 -0500 Message-ID: To: Michael Welzl , Carsten Bormann Cc: "loops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000285f89058f027afa" Archived-At: Subject: Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps X-BeenThere: loops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Local Optimizations on Path Segments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 23:28:08 -0000 --000000000000285f89058f027afa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually in FEC you do not process every packet. In what is called =E2=80=9Csystematic mode=E2=80=9D you send all the packets in the buffer (w= indow) followed by the coded packet(s). If everything goes well you never process anything. And if something is lost then you use the recovery packets. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On July 31, 2019 at 7:11:41 PM, Carsten Bormann (cabo@tzi.org) wrote: On Aug 1, 2019, at 00:18, Michael Welzl wrote: > > if the packet loss ratio is known Conversely, retransmission can be better to handle random, bursty losses. (For a definition of =E2=80=9Cbetter=E2=80=9D, which may depend on your nee= ds.) But more importantly, for retransmission, the ingress node needs to store copies of packets for a while (and retransmit from this cache), and the egress node needs to send ACKs. This is much less work per packet than doing FEC, which needs processing of the contents of each packet. So nodes may be able to do retransmission LOOPS at a higher rate than they would be able to do FEC LOOPS. Gr=C3=BC=C3=9Fe, Carsten --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000285f89058f027afa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    Actu= ally in FEC you do not process every packet. In what is called =E2=80=9Csys= tematic mode=E2=80=9D you send all the packets in the buffer (window) follo= wed by the coded packet(s). If everything goes well you never process anyth= ing. And if something is lost then you use the recovery packets.


    mjm

    Marie-Jos=C3=A9 Montpetit, Ph.D.
    Research Affiliate, MIT Me= dia Laboratory

    On July 31, 2019= at 7:11:41 PM, Carsten Bormann (cabo@tzi.o= rg) wrote:

    =
    On Aug 1, 2019, at 00:18, Michael Welzl <michawe@ifi.uio.no> wrote:
    >
    > i= f the packet loss ratio is known

    Conversely, retransmission can be b= etter to handle random, bursty losses.
    (For a definition of =E2=80=9Cbet= ter=E2=80=9D, which may depend on your needs.)

    But more importantly,= for retransmission, the ingress node needs to store copies of packets for = a while (and retransmit from this cache), and the egress node needs to send= ACKs. This is much less work per packet than doing FEC, which needs proce= ssing of the contents of each packet. So nodes may be able to do retransmi= ssion LOOPS at a higher rate than they would be able to do FEC LOOPS.
    Gr=C3=BC=C3=9Fe, Carsten

    --
    LOOPS mailing list
    LOOPS@ietf.org
    https://www.ietf.org/mailman/listinfo/loops
    --000000000000285f89058f027afa--