From nobody Thu Aug 1 00:03:24 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 7790C120141 for ; Thu, 1 Aug 2019 00:03:23 -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 M1DbrtmoRLbw for ; Thu, 1 Aug 2019 00:03:21 -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 C0C0312000F for ; Thu, 1 Aug 2019 00:03:16 -0700 (PDT) Received: from client-0111.vpn.uni-bremen.de (client-0111.vpn.uni-bremen.de [134.102.107.111]) (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 45zh8M27FQz10cy; Thu, 1 Aug 2019 09:03:15 +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 09:03:14 +0200 Cc: Michael Welzl , "loops@ietf.org" X-Mao-Original-Outgoing-Id: 586335792.573873-c64335b5fabe7558912c6f547c03c6bc Content-Transfer-Encoding: quoted-printable Message-Id: <6B546B62-2399-427D-B99F-118FED2CC04F@tzi.org> References: <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7C016290-2FB9-4DCF-9213-749B2B27D4D0@tzi.org> 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, 01 Aug 2019 07:03:24 -0000 On Aug 1, 2019, at 01:28, Marie-Jose Montpetit = wrote: >=20 > 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 = (window) followed by the coded packet(s). To generate the coded packets, you need to process every packet (ingress = node). Obviously, you can send on the unchanged packets before you do = that (see also Appendix B of gen-info why that may be a very good = thing). > If everything goes well you never process anything. At the egress node. > And if something is lost then you use the recovery packets. Right. So, at the egress node, you have to provide the processing = capability for this worse [sic] case, even if you don=E2=80=99t need it = in the better case. (Of course, you can always decide to start losing = badly if there is a cluster of losses that overwhelms insufficient = egress processing capacity, but that is not normally what you=E2=80=99ll = want to do.) This is not a theoretical concern; processing speed is a make-or-break = consideration for many applications of LOOPS. Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit, Ph.D. > Research Affiliate, MIT Media Laboratory > mariejose@mjmontpetit.com > mariejo@mit.edu >=20 > On July 31, 2019 at 7:11:41 PM, Carsten Bormann (cabo@tzi.org) wrote: >=20 >> On Aug 1, 2019, at 00:18, Michael Welzl wrote: >> >=20 >> > if the packet loss ratio is known >>=20 >> 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.) >>=20 >> 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. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=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 Aug 20 02:47:20 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 74D99120930 for ; Tue, 20 Aug 2019 02:47:19 -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 2zO73sQf0U_n for ; Tue, 20 Aug 2019 02:47:17 -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 C2E3E12092E for ; Tue, 20 Aug 2019 02:47:16 -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 46CQtp5GBqzydx; Tue, 20 Aug 2019 11:47:14 +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, 20 Aug 2019 11:47:14 +0200 Cc: Mirja Kuehlewind , Magnus Westerlund , loops@ietf.org, Suresh Krishnan X-Mao-Original-Outgoing-Id: 587987232.805657-23b5bdf76f9228e1b81eb8ecf0e02b1e Content-Transfer-Encoding: quoted-printable Message-Id: <08D42FCB-DBC5-488B-A0E4-08230843E173@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: Tue, 20 Aug 2019 09:47:20 -0000 Hi Spencer, It is probably not too easy to generate a lot of excitement on this list = while most people are still on vacation, but let me try to answer your = questions. > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF = wrote: >=20 > [=E2=80=A6] > So, my suggestion for the interested community is to nail down > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, = that can be used without changes? Most of IP :-) Seriously, the idea behind LOOPS is to use existing tunnel encapsulation = protocols with few additions, capitalizing on that work, and also making = use of ASIC support already present in devices =E2=80=94 it helps to be = encapsulation-agnostic for this. It is unlikely that we=E2=80=99ll have to invent another FEC scheme for = LOOPS, so existing schemes can probably be used unchanged. I=E2=80=99m = not so sure the WG won=E2=80=99t want to improve on the FECFRAME = framework, though. I don=E2=80=99t want to design much of the protocol = while we are still in a WG-forming stage, so I=E2=80=99ll refrain from = delving too much on why I think that may be a good thing. Basically, = think about packet size distributions in general aggregated IP flows vs. = those in the RTP flows or even single transport flows that FECFRAME = schemes are being used with. Most likely, the time stamp formats (and even some algorithms around = those) we need can be stolen from existing work. Not much else can probably be used unchanged. =20 > =E2=80=A2 what already exists, but needs to be extended for = LOOPS? The encapsulation schemes may need to have their extension points = exercised to actually send the forward and reverse information in the = best way. Some of the encapsulation protocols already define how to = carry a sequence number, but other elements (such as block 1 and block 2 = reverse information [1]) may need some encoding decisions. > =E2=80=A2 what needs to be created, because nothing exists that = meets the needs? The actual protocol, i.e., the rules of action. (A best-effort, not = fully reliable retransmit scheme; FEC parameter control loops; = measurement schemes that go into these and into congestion feedback = mechanisms.) > 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 > =E2=80=A2 How a sender tunes FEC dynamically - is that = automatic, based on FEC mechanisms people are thinking about, or is = there work to do there? I=E2=80=99m not aware of such a control loop in existing IETF standards, = but I would love to be surprised. > =E2=80=A2 How a sender knows whether to do FEC, retransmission, = or both FEC and retransmission, dynamically? In most cases, this will be setup information (controller model). > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing = anything, because anything it does won't help ("first, do no harm")? Again, probably setup information. The protocol could also define some = thresholds for switching components on an off, on a relatively long time = scale. > Does everyone know how to do those three things, except me? :-) I hope the WG can find out once it exists=E2=80=A6 I would also like to avoid the FEC tail wagging with the LOOPS dog too = much. (I know, if you are standing very close to the tail, it may seem larger = than the dog :-) Yes, the sheer bulk and complexity of the specifications is larger in = the FEC part than in the rest of the specifications. But then, FEC is = relatively well understood, a lot of (re-)usable specifications are out = there, and we even have a whole RG for that which we can tap. On the = other hand, doing best-effort retransmissions (and FEC) on aggregate = flows while we are experiencing increased presence of new-style = end-to-end transports (encrypted, more reordering-tolerant) is a new = engineering problem that needs a bit more focus from the WG. .oOo. By the way, I have generated a post-ietf105 branch on the charter text = proposal [charter-0.3] that explicitly calls out focusing on = retransmission initially and adding FEC later (with or without a = rechartering needed); this version also adds milestones for a = (shim-layer-in-)host-to-network component that was requested so vividly = at the BOF. Gr=C3=BC=C3=9Fe, Carsten [1]: = https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 [2]: https://github.com/loops-wg/charter/tree/post-105 From nobody Tue Aug 20 03:42: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 BF78912001B for ; Tue, 20 Aug 2019 03:42:54 -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 98MfilmBhaxc for ; Tue, 20 Aug 2019 03:42:52 -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 DB0B212001A for ; Tue, 20 Aug 2019 03:42:51 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id t6so11150208ios.7 for ; Tue, 20 Aug 2019 03:42:51 -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=i1Bbb/lWYAQSE1MEG2JLancBNi6XqCJsGCHYT5/br8U=; b=ZnAXXrXX9r0YZq53wXub1n42qwZHQ1Cjf0fK2ciMV+dQFzD6eNFBKHNpg3tgMU65YI /Ie4QGODFzSAfrgVbCWzj5WuFVZS1JgkPGUPBRxrWCgDuFXOSln7nbuk7vXEDjW9FG0l idCI4CkzGHkMa18/TFus0d4NCsHnRxe+JDVyWrtPmqZnrW6G48MgH5lJsuB8UPSv6V7e fLtYQGCMh1+863VEJLjstRLHroK4H6aOFOmzK5mswfnm4voWFVfFaZmwblYk4PC+xqEi l3pihc+c7Cp6C1DScJDQuBP+W4qK7SNhg+8zMu7NCfgwcNv9N9mzxQ87qjY1Tr9fp0L8 zJnA== 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=i1Bbb/lWYAQSE1MEG2JLancBNi6XqCJsGCHYT5/br8U=; b=P8k74LScUgYtJiMv8pEtBuG0QG74d85eIwGGOR8QOBSmVv9cqD0Yh+Xt2KLUNoWA+e HweNhmnXdb0rHND/Ux+lbue7C01ufPS4PL02ryVxy4wLKE9knYYA7zsjI/oM4ULbC4il a2PyRAI/9fNz3XG6MXhycEKuRLuu+DM4cwaY7EgZ+6dbMRUyynsm33qpb2GHyAtMAtyJ /0IPc5ZSx2Qknqxv/ZjuoJjHNMIjwlw4F44IojS6dW/Sf7xTEbhoOO6nyPer27wYIcve +aQ8DgpRN0DnrPBcjpa3zcJbIR+ldt1cnBmpPyhvxvxGUX3/0F+c0lilkfLSnf0T0uZn i6PA== X-Gm-Message-State: APjAAAUyFmsoQXev2+2ch2Y/dWPT90vgqh8IbQo3CfPd5UHun+dWVavv H0IwgbvuazcaRl8xqC49Cud6iavpS7ba0qiyDrLMzw== X-Google-Smtp-Source: APXvYqz5G3h3Nogl4E4hbmA6xteuQVrnW5xJ+jo3NCgVhToeDvuHa6n+b/ZOIhpvNebNBDBLknciPdMI0ywVikHLwCk= X-Received: by 2002:a6b:6812:: with SMTP id d18mr2938907ioc.239.1566297770983; Tue, 20 Aug 2019 03:42:50 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2019 10:42:50 +0000 From: Marie-Jose Montpetit In-Reply-To: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> MIME-Version: 1.0 Date: Tue, 20 Aug 2019 10:42:50 +0000 Message-ID: To: Spencer Dawkins at IETF , Carsten Bormann Cc: Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Colin Perkins , Vincent Roca Content-Type: multipart/alternative; boundary="000000000000408b8605908a1efd" 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, 20 Aug 2019 10:42:55 -0000 --000000000000408b8605908a1efd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as well as = the encapsulation and aggregated flow protocols that you want to investigate are part of the work in the nwcrg (and yes not the IETF) and I would hope that they will be reused by LOOPS. mjm Marie-Jos=C3=A9 Montpetit On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote: Hi Spencer, It is probably not too easy to generate a lot of excitement on this list while most people are still on vacation, but let me try to answer your questions. > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > [=E2=80=A6] > So, my suggestion for the interested community is to nail down > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, that can b= e used without changes? Most of IP :-) Seriously, the idea behind LOOPS is to use existing tunnel encapsulation protocols with few additions, capitalizing on that work, and also making use of ASIC support already present in devices =E2=80=94 it helps to be encapsulation-agnostic for this. It is unlikely that we=E2=80=99ll have to invent another FEC scheme for LOO= PS, so existing schemes can probably be used unchanged. I=E2=80=99m not so sure th= e WG won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2= =80=99t want to design much of the protocol while we are still in a WG-forming stage, so I=E2=80=99ll refrain from delving too much on why I think that may be a goo= d thing. Basically, think about packet size distributions in general aggregated IP flows vs. those in the RTP flows or even single transport flows that FECFRAME schemes are being used with. Most likely, the time stamp formats (and even some algorithms around those) we need can be stolen from existing work. Not much else can probably be used unchanged. > =E2=80=A2 what already exists, but needs to be extended for LOOPS? The encapsulation schemes may need to have their extension points exercised to actually send the forward and reverse information in the best way. Some of the encapsulation protocols already define how to carry a sequence number, but other elements (such as block 1 and block 2 reverse information [1]) may need some encoding decisions. > =E2=80=A2 what needs to be created, because nothing exists that meets the= needs? The actual protocol, i.e., the rules of action. (A best-effort, not fully reliable retransmit scheme; FEC parameter control loops; measurement schemes that go into these and into congestion feedback mechanisms.) > 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 > =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based o= n FEC mechanisms people are thinking about, or is there work to do there? I=E2=80=99m not aware of such a control loop in existing IETF standards, bu= t I would love to be surprised. > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both F= EC and retransmission, dynamically? In most cases, this will be setup information (controller model). > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anything,= because anything it does won't help ("first, do no harm")? Again, probably setup information. The protocol could also define some thresholds for switching components on an off, on a relatively long time scale. > Does everyone know how to do those three things, except me? :-) I hope the WG can find out once it exists=E2=80=A6 I would also like to avoid the FEC tail wagging with the LOOPS dog too much= . (I know, if you are standing very close to the tail, it may seem larger than the dog :-) Yes, the sheer bulk and complexity of the specifications is larger in the FEC part than in the rest of the specifications. But then, FEC is relatively well understood, a lot of (re-)usable specifications are out there, and we even have a whole RG for that which we can tap. On the other hand, doing best-effort retransmissions (and FEC) on aggregate flows while we are experiencing increased presence of new-style end-to-end transports (encrypted, more reordering-tolerant) is a new engineering problem that needs a bit more focus from the WG. .oOo. By the way, I have generated a post-ietf105 branch on the charter text proposal [charter-0.3] that explicitly calls out focusing on retransmission initially and adding FEC later (with or without a rechartering needed); this version also adds milestones for a (shim-layer-in-)host-to-network component that was requested so vividly at the BOF. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 [2]: https://github.com/loops-wg/charter/tree/post-105 --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --000000000000408b8605908a1efd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Not = =E2=80=9Cexcitement" but some of the FEC control mechanisms as well as= the encapsulation and aggregated flow protocols that you want to investiga= te are part of the work in the nwcrg (and yes not the IETF) and I would hop= e that they will be reused by LOOPS.=C2=A0

mjm

Marie= -Jos=C3=A9 Montpetit

On August 20, 2019 a= t 5:47:24 AM, Carsten Bormann (cabo@tzi.org= ) wrote:

Hi Spencer,

It is probably not too easy to generate a = lot of excitement on this list while most people are still on vacation, but= let me try to answer your questions.

> On Jul 30, 2019, at 16:22= , Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>
> [=E2=80= =A6]
> So, my suggestion for the interested community is to nail down=
> =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exist= s, that can be used without changes?

Most of IP :-)

Seriously= , the idea behind LOOPS is to use existing tunnel encapsulation protocols w= ith few additions, capitalizing on that work, and also making use of ASIC s= upport already present in devices =E2=80=94 it helps to be encapsulation-ag= nostic for this.

It is unlikely that we=E2=80=99ll have to invent an= other FEC scheme for LOOPS, so existing schemes can probably be used unchan= ged. I=E2=80=99m not so sure the WG won=E2=80=99t want to improve on the F= ECFRAME framework, though. I don=E2=80=99t want to design much of the prot= ocol while we are still in a WG-forming stage, so I=E2=80=99ll refrain from= delving too much on why I think that may be a good thing. Basically, thin= k about packet size distributions in general aggregated IP flows vs. those = in the RTP flows or even single transport flows that FECFRAME schemes are b= eing used with.

Most likely, the time stamp formats (and even some a= lgorithms around those) we need can be stolen from existing work.

No= t much else can probably be used unchanged.

> =E2=80=A2 what a= lready exists, but needs to be extended for LOOPS?

The encapsulation= schemes may need to have their extension points exercised to actually send= the forward and reverse information in the best way. Some of the encapsul= ation protocols already define how to carry a sequence number, but other el= ements (such as block 1 and block 2 reverse information [1]) may need some = encoding decisions.

> =E2=80=A2 what needs to be created, becaus= e nothing exists that meets the needs?

The actual protocol, i.e., th= e rules of action. (A best-effort, not fully reliable retransmit scheme; FE= C parameter control loops; measurement schemes that go into these and into = congestion feedback mechanisms.)

> I'm not a LOOPS proponent = (the ADs asked me to chair the BOF about a month before IETF 105), but spea= king as someone who hasn't been involved in depth, I wonder about
&g= t; =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based= on FEC mechanisms people are thinking about, or is there work to do there?=

I=E2=80=99m not aware of such a control loop in existing IETF stand= ards, but I would love to be surprised.

> =E2=80=A2 How a sender= knows whether to do FEC, retransmission, or both FEC and retransmission, d= ynamically?

In most cases, this will be setup information (controlle= r model).

> =E2=80=A2 How a sender knows that it shouldn=E2=80= =99t be doing anything, because anything it does won't help ("firs= t, do no harm")?

Again, probably setup information. The protoc= ol could also define some thresholds for switching components on an off, on= a relatively long time scale.

> Does everyone know how to do tho= se three things, except me? :-)

I hope the WG can find out once it e= xists=E2=80=A6

I would also like to avoid the FEC tail wagging with = the LOOPS dog too much.
(I know, if you are standing very close to the t= ail, it may seem larger than the dog :-)

Yes, the sheer bulk and com= plexity of the specifications is larger in the FEC part than in the rest of= the specifications. But then, FEC is relatively well understood, a lot of= (re-)usable specifications are out there, and we even have a whole RG for = that which we can tap. On the other hand, doing best-effort retransmission= s (and FEC) on aggregate flows while we are experiencing increased presence= of new-style end-to-end transports (encrypted, more reordering-tolerant) i= s a new engineering problem that needs a bit more focus from the WG.
.oOo.

By the way, I have generated a post-ietf105 branch on the = charter text proposal [charter-0.3] that explicitly calls out focusing on r= etransmission initially and adding FEC later (with or without a recharterin= g needed); this version also adds milestones for a (shim-layer-in-)host-to-= network component that was requested so vividly at the BOF.

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

[1]: https://tools.ietf.org/html/draft-welzl= -loops-gen-info-00#section-4.3
[2]: https://github.com/loops-wg/charter/tree/post= -105

--
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops
--000000000000408b8605908a1efd-- From nobody Tue Aug 20 03:50: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 51A7312003E for ; Tue, 20 Aug 2019 03:50:57 -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 J35cSRkxjfWf for ; Tue, 20 Aug 2019 03:50:54 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82: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 2DAAF12001B for ; Tue, 20 Aug 2019 03:50:54 -0700 (PDT) Received: from [130.209.247.112] (port=61573 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i01is-0000Sy-K8; Tue, 20 Aug 2019 11:50:46 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6748BAA4-60BD-4525-840D-2FA20AFD0972" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 20 Aug 2019 11:50:32 +0100 In-Reply-To: Cc: Spencer Dawkins at IETF , Carsten Bormann , Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Vincent Roca To: Marie-Jose Montpetit References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 14 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, 20 Aug 2019 10:50:57 -0000 --Apple-Mail=_6748BAA4-60BD-4525-840D-2FA20AFD0972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the things we=E2=80=99d need to decide is what=E2=80=99s the path = from NWCRG into IETF to standardise such things before use by LOOPS. FECFRAME seemed to work quite well. Is the goal to revive it and move = some work from NWCRG? Or to bring work from NWCRG into TSVWG to do = FECFRAME extensions for LOOPS to reference? Or to bring work from NWCRG = into LOOPS?=20 I=E2=80=99d suggest either of the former two options make more sense = than the latter.=20 Colin > On 20 Aug 2019, at 11:42, Marie-Jose Montpetit = wrote: >=20 > Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as = well as the encapsulation and aggregated flow protocols that you want to = investigate are part of the work in the nwcrg (and yes not the IETF) and = I would hope that they will be reused by LOOPS.=20 >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit >=20 > On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org = ) wrote: >=20 >> Hi Spencer, >>=20 >> It is probably not too easy to generate a lot of excitement on this = list while most people are still on vacation, but let me try to answer = your questions. >>=20 >> > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF = > = wrote: >> >=20 >> > [=E2=80=A6] >> > So, my suggestion for the interested community is to nail down >> > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, that = can be used without changes? >>=20 >> Most of IP :-) >>=20 >> Seriously, the idea behind LOOPS is to use existing tunnel = encapsulation protocols with few additions, capitalizing on that work, = and also making use of ASIC support already present in devices =E2=80=94 = it helps to be encapsulation-agnostic for this. >>=20 >> It is unlikely that we=E2=80=99ll have to invent another FEC scheme = for LOOPS, so existing schemes can probably be used unchanged. I=E2=80=99m= not so sure the WG won=E2=80=99t want to improve on the FECFRAME = framework, though. I don=E2=80=99t want to design much of the protocol = while we are still in a WG-forming stage, so I=E2=80=99ll refrain from = delving too much on why I think that may be a good thing. Basically, = think about packet size distributions in general aggregated IP flows vs. = those in the RTP flows or even single transport flows that FECFRAME = schemes are being used with. >>=20 >> Most likely, the time stamp formats (and even some algorithms around = those) we need can be stolen from existing work. >>=20 >> Not much else can probably be used unchanged. =20 >>=20 >> > =E2=80=A2 what already exists, but needs to be extended for LOOPS? >>=20 >> The encapsulation schemes may need to have their extension points = exercised to actually send the forward and reverse information in the = best way. Some of the encapsulation protocols already define how to = carry a sequence number, but other elements (such as block 1 and block 2 = reverse information [1]) may need some encoding decisions. >>=20 >> > =E2=80=A2 what needs to be created, because nothing exists that = meets the needs? >>=20 >> The actual protocol, i.e., the rules of action. (A best-effort, not = fully reliable retransmit scheme; FEC parameter control loops; = measurement schemes that go into these and into congestion feedback = mechanisms.) >>=20 >> > 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 >> > =E2=80=A2 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 >> I=E2=80=99m not aware of such a control loop in existing IETF = standards, but I would love to be surprised. >>=20 >> > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or = both FEC and retransmission, dynamically? >>=20 >> In most cases, this will be setup information (controller model). >>=20 >> > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing = anything, because anything it does won't help ("first, do no harm")? >>=20 >> Again, probably setup information. The protocol could also define = some thresholds for switching components on an off, on a relatively long = time scale. >>=20 >> > Does everyone know how to do those three things, except me? :-) >>=20 >> I hope the WG can find out once it exists=E2=80=A6 >>=20 >> I would also like to avoid the FEC tail wagging with the LOOPS dog = too much. >> (I know, if you are standing very close to the tail, it may seem = larger than the dog :-) >>=20 >> Yes, the sheer bulk and complexity of the specifications is larger in = the FEC part than in the rest of the specifications. But then, FEC is = relatively well understood, a lot of (re-)usable specifications are out = there, and we even have a whole RG for that which we can tap. On the = other hand, doing best-effort retransmissions (and FEC) on aggregate = flows while we are experiencing increased presence of new-style = end-to-end transports (encrypted, more reordering-tolerant) is a new = engineering problem that needs a bit more focus from the WG. >>=20 >> .oOo. >>=20 >> By the way, I have generated a post-ietf105 branch on the charter = text proposal [charter-0.3] that explicitly calls out focusing on = retransmission initially and adding FEC later (with or without a = rechartering needed); this version also adds milestones for a = (shim-layer-in-)host-to-network component that was requested so vividly = at the BOF. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> [1]: = https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 = >> [2]: https://github.com/loops-wg/charter/tree/post-105 = >>=20 >> --=20 >> LOOPS mailing list >> LOOPS@ietf.org >> https://www.ietf.org/mailman/listinfo/loops = --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_6748BAA4-60BD-4525-840D-2FA20AFD0972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the things we=E2=80=99d need to decide is what=E2=80=99s the path = from NWCRG into IETF to standardise such things before use by LOOPS.

FECFRAME seemed to work = quite well. Is the goal to revive it and move some work from NWCRG? Or = to bring work from NWCRG into TSVWG to do FECFRAME extensions for LOOPS = to reference? Or to bring work from NWCRG into LOOPS? 

I=E2=80=99d suggest = either of the former two options make more sense than the = latter. 

Colin



On 20 Aug 2019, at 11:42, Marie-Jose = Montpetit <marie@mjmontpetit.com> wrote:

Not =E2=80=9Cexcitement" but some of the FEC control = mechanisms as well as the encapsulation and aggregated flow protocols = that you want to investigate are part of the work in the nwcrg (and yes = not the IETF) and I would hope that they will be reused by = LOOPS. 

mjm

Marie-Jos=C3=A9 Montpetit

On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) = wrote:

Hi Spencer,

It is probably not too easy to generate a lot of excitement = on this list while most people are still on vacation, but let me try to = answer your questions.

> On Jul 30, = 2019, at 16:22, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> [=E2=80=A6]
> So, my suggestion for the = interested community is to nail down
> =E2=80=A2 In = order to =E2=80=9Cdo LOOPS", what already exists, that can be used = without changes?

Most of IP :-)

Seriously, the idea behind LOOPS is to use = existing tunnel encapsulation protocols with few additions, capitalizing = on that work, and also making use of ASIC support already present in = devices =E2=80=94 it helps to be encapsulation-agnostic for this.

It is unlikely that we=E2=80=99ll have to = invent another FEC scheme for LOOPS, so existing schemes can probably be = used unchanged. I=E2=80=99m not so sure the WG won=E2=80=99t want to = improve on the FECFRAME framework, though. I don=E2=80=99t want to = design much of the protocol while we are still in a WG-forming stage, so = I=E2=80=99ll refrain from delving too much on why I think that may be a = good thing. Basically, think about packet size distributions in general = aggregated IP flows vs. those in the RTP flows or even single transport = flows that FECFRAME schemes are being used with.

Most likely, the time stamp formats (and even some algorithms = around those) we need can be stolen from existing work.

Not much else can probably be used unchanged.  

> =E2=80=A2 what already exists, but needs to be extended = for LOOPS?

The encapsulation schemes may = need to have their extension points exercised to actually send the = forward and reverse information in the best way. Some of the = encapsulation protocols already define how to carry a sequence number, = but other elements (such as block 1 and block 2 reverse information [1]) = may need some encoding decisions.

> =E2=80= =A2 what needs to be created, because nothing exists that meets the = needs?

The actual protocol, i.e., the rules = of action. (A best-effort, not fully reliable retransmit scheme; FEC = parameter control loops; measurement schemes that go into these and into = congestion feedback mechanisms.)

> 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
> =E2=80=A2 How a sender tunes = FEC dynamically - is that automatic, based on FEC mechanisms people are = thinking about, or is there work to do there?

I=E2=80=99m not aware of such a control loop in existing IETF = standards, but I would love to be surprised.

> =E2=80=A2 How a sender knows whether to do FEC, = retransmission, or both FEC and retransmission, dynamically?

In most cases, this will be setup information = (controller model).

> =E2=80=A2 How a = sender knows that it shouldn=E2=80=99t be doing anything, because = anything it does won't help ("first, do no harm")?

Again, probably setup information. The protocol could also = define some thresholds for switching components on an off, on a = relatively long time scale.

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

I hope the WG can find out once it = exists=E2=80=A6

I would also like to avoid = the FEC tail wagging with the LOOPS dog too much.
(I know, = if you are standing very close to the tail, it may seem larger than the = dog :-)

Yes, the sheer bulk and complexity = of the specifications is larger in the FEC part than in the rest of the = specifications. But then, FEC is relatively well understood, a lot of = (re-)usable specifications are out there, and we even have a whole RG = for that which we can tap. On the other hand, doing best-effort = retransmissions (and FEC) on aggregate flows while we are experiencing = increased presence of new-style end-to-end transports (encrypted, more = reordering-tolerant) is a new engineering problem that needs a bit more = focus from the WG.

.oOo.

By the way, I have generated a post-ietf105 branch on the = charter text proposal [charter-0.3] that explicitly calls out focusing = on retransmission initially and adding FEC later (with or without a = rechartering needed); this version also adds milestones for a = (shim-layer-in-)host-to-network component that was requested so vividly = at the BOF.

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

[1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#secti= on-4.3
[2]: https://github.com/loops-wg/charter/tree/post-105

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



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




= --Apple-Mail=_6748BAA4-60BD-4525-840D-2FA20AFD0972-- From nobody Tue Aug 20 03:56: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 4EC6812095A for ; Tue, 20 Aug 2019 03:56:27 -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 SKn7bA3ZkpoB for ; Tue, 20 Aug 2019 03:56:23 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 CEAC312098E for ; Tue, 20 Aug 2019 03:56:19 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id t6so11215212ios.7 for ; Tue, 20 Aug 2019 03:56:19 -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=1ohQk+6POE4PlCHHCmk7xAaP6NjQOoJ+SrKzEcC6UOs=; b=IHsa/LCD7sDJs9POtVq30uCneUiHJdfQYs2L2F2AAwlUkF0E0Vw3iWkTP61Co62P4y dyQGp7OqLKh9d74V5eR3Wf6n4yJf462aQb2tpPqavJJWC039fZ9fbS9sA/IG2BfY3CdW q/8nOM+hQFh1zPmbyZwAA8LL183weZ6Tj1oZ4wf68XZ6VgL7wL+QCSYYAo2pF/0VKahY shAHLiYYhoqLgURVu5SSZLnv8q5tEW8ghTaXawthsxyBDAAMNbfUqKgiNgC+Dd9hNVW5 QQw/fL0WeDP9XthECIqdAU3UAc+q7ZB35X8/ds9VVLjOxfYuDimzU2JKYFLHbhhNE+qd xkiQ== 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=1ohQk+6POE4PlCHHCmk7xAaP6NjQOoJ+SrKzEcC6UOs=; b=ayKOnsYagnrMAXNrM2rhnjMEUKrD7ahhdAvXnL8V1gBk41kYwmXx3fft3v5c/7LtKq au+wNdqVsq7jo0fhmz43L/JlKX6M49xEGiK1Tn/J0VbaEmYgNkOEtQb7DWpkyOGDVmZD PEUBV2TnvHFWLZKQbPlMhOanwff6ZAyPCfJaJbL3voCTluuBZSmSqFcK/Qha6By7pfSz np+SQKBQlghD7NEQvn8++URBTUMvs9c6e3snzOZmXNzYs33TkxCsW39qVfADHz2rgHuE HBzLEC9T5QGZiprN7S6c6Vn8IbsxMy6mkk+Y+vf51xpzNvCnVQMPKp6mePgkZB1rYI3q Kf0A== X-Gm-Message-State: APjAAAVKJesQ3/eTkag+6YK4KyZKJIV8ohwAbGEn0pCJRca7k00sgyNe YpcVjDDV7NIsChtKyML2qxh1f5CpWPTob3mxAXVWmg== X-Google-Smtp-Source: APXvYqxXJh/WzBqICCBDO19LeKRX+Lo563VZmICbfBWh8nkaf4rgWC+h3952oOCaQArKLZIyGFfy41W054saUzIQN3Q= X-Received: by 2002:a6b:cdc9:: with SMTP id d192mr31657903iog.132.1566298563699; Tue, 20 Aug 2019 03:56:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2019 10:56:03 +0000 From: Marie-Jose Montpetit In-Reply-To: References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> MIME-Version: 1.0 Date: Tue, 20 Aug 2019 10:56:02 +0000 Message-ID: To: Colin Perkins Cc: loops@ietf.org, Mirja Kuehlewind , Vincent Roca , Carsten Bormann , Suresh Krishnan , Magnus Westerlund , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="000000000000807ba705908a4d22" 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, 20 Aug 2019 10:56:29 -0000 --000000000000807ba705908a4d22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think within the nwcrg we could discuss what is the best path. Just bringing the work I agree is not the best way forward. Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On August 20, 2019 at 6:50:47 AM, Colin Perkins (csp@csperkins.org) wrote: One of the things we=E2=80=99d need to decide is what=E2=80=99s the path fr= om NWCRG into IETF to standardise such things before use by LOOPS. FECFRAME seemed to work quite well. Is the goal to revive it and move some work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS? I=E2=80=99d suggest either of the former two options make more sense than t= he latter. Colin On 20 Aug 2019, at 11:42, Marie-Jose Montpetit wrote: Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as well as = the encapsulation and aggregated flow protocols that you want to investigate are part of the work in the nwcrg (and yes not the IETF) and I would hope that they will be reused by LOOPS. mjm Marie-Jos=C3=A9 Montpetit On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote: Hi Spencer, It is probably not too easy to generate a lot of excitement on this list while most people are still on vacation, but let me try to answer your questions. > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > > [=E2=80=A6] > So, my suggestion for the interested community is to nail down > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, that can b= e used without changes? Most of IP :-) Seriously, the idea behind LOOPS is to use existing tunnel encapsulation protocols with few additions, capitalizing on that work, and also making use of ASIC support already present in devices =E2=80=94 it helps to be encapsulation-agnostic for this. It is unlikely that we=E2=80=99ll have to invent another FEC scheme for LOO= PS, so existing schemes can probably be used unchanged. I=E2=80=99m not so sure th= e WG won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2= =80=99t want to design much of the protocol while we are still in a WG-forming stage, so I=E2=80=99ll refrain from delving too much on why I think that may be a goo= d thing. Basically, think about packet size distributions in general aggregated IP flows vs. those in the RTP flows or even single transport flows that FECFRAME schemes are being used with. Most likely, the time stamp formats (and even some algorithms around those) we need can be stolen from existing work. Not much else can probably be used unchanged. > =E2=80=A2 what already exists, but needs to be extended for LOOPS? The encapsulation schemes may need to have their extension points exercised to actually send the forward and reverse information in the best way. Some of the encapsulation protocols already define how to carry a sequence number, but other elements (such as block 1 and block 2 reverse information [1]) may need some encoding decisions. > =E2=80=A2 what needs to be created, because nothing exists that meets the= needs? The actual protocol, i.e., the rules of action. (A best-effort, not fully reliable retransmit scheme; FEC parameter control loops; measurement schemes that go into these and into congestion feedback mechanisms.) > 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 > =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based o= n FEC mechanisms people are thinking about, or is there work to do there? I=E2=80=99m not aware of such a control loop in existing IETF standards, bu= t I would love to be surprised. > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both F= EC and retransmission, dynamically? In most cases, this will be setup information (controller model). > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anything,= because anything it does won't help ("first, do no harm")? Again, probably setup information. The protocol could also define some thresholds for switching components on an off, on a relatively long time scale. > Does everyone know how to do those three things, except me? :-) I hope the WG can find out once it exists=E2=80=A6 I would also like to avoid the FEC tail wagging with the LOOPS dog too much= . (I know, if you are standing very close to the tail, it may seem larger than the dog :-) Yes, the sheer bulk and complexity of the specifications is larger in the FEC part than in the rest of the specifications. But then, FEC is relatively well understood, a lot of (re-)usable specifications are out there, and we even have a whole RG for that which we can tap. On the other hand, doing best-effort retransmissions (and FEC) on aggregate flows while we are experiencing increased presence of new-style end-to-end transports (encrypted, more reordering-tolerant) is a new engineering problem that needs a bit more focus from the WG. .oOo. By the way, I have generated a post-ietf105 branch on the charter text proposal [charter-0.3] that explicitly calls out focusing on retransmission initially and adding FEC later (with or without a rechartering needed); this version also adds milestones for a (shim-layer-in-)host-to-network component that was requested so vividly at the BOF. Gr=C3=BC=C3=9Fe, Carsten [1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 [2]: https://github.com/loops-wg/charter/tree/post-105 --=20 LOOPS mailing list LOOPS@ietf.org https://www.ietf.org/mailman/listinfo/loops --=20 Colin Perkins https://csperkins.org/ --000000000000807ba705908a4d22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I th= ink within the nwcrg we could discuss what is the best path. Just bringing = the work I agree is not the best way forward.=C2=A0

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

On Augu= st 20, 2019 at 6:50:47 AM, Colin Perkins (csp@csperkins.org) wrote:

One of the things we=E2=80=99d need to decide is what=E2=80=99s the path fr= om NWCRG into IETF to standardise such things before use by LOOPS.

FECFRAME seemed to work quite well. Is the goal to revive it and move some work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS?=C2=A0

I=E2=80=99d suggest either of the former two options make more sense than the latter.=C2=A0

Colin



On 20 Aug 2019, at 11:42, Marie-Jose Montpetit <marie@mjmontpetit.c= om> wrote:

Not =E2=80=9Cexcitement" but som= e of the FEC control mechanisms as well as the encapsulation and aggregated flow protocols that you want to investigate are part of the work in the nwcrg (and yes not the IETF) and I would hope that they will be reused by LOOPS.=C2=A0

mjm

Marie-Jos=C3=A9 Montpetit

On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote:

Hi Spencer,

It is probably not too easy to generate a lot of excitement on this list while most people are still on vacation, but let me try to answer your questions.

> On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF <spencerdawk= ins.ietf@gmail.com> wrote:
>=C2=A0
> [=E2=80=A6]
> So, my suggestion for the interested community is to nail down
> =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, th= at can be used without changes?

Most of IP :-)

Seriously, the idea behind LOOPS is to use existing tunnel encapsulation protocols with few additions, capitalizing on that work, and also making use of ASIC support already present in devices =E2=80=94 it helps to be encapsulation-agnostic for this.

It is unlikely that we=E2=80=99ll have to invent another FEC scheme for LOOPS, so existing schemes can probably be used unchanged. I=E2=80=99m not so sure the WG won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2=80=99t want to design much of the protocol while we are still in a WG-forming stage, so I=E2=80=99ll refrain from delving too much on why I think that may be a good thing. Basically, think about packet size distributions in general aggregated IP flows vs. those in the RTP flows or even single transport flows that FECFRAME schemes are being used with.

Most likely, the time stamp formats (and even some algorithms around those) we need can be stolen from existing work.

Not much else can probably be used unchanged.=C2=A0=C2=A0
> =E2=80=A2 what already exists, but needs to be extended for LOOPS?

The encapsulation schemes may need to have their extension points exercised to actually send the forward and reverse information in the best way. Some of the encapsulation protocols already define how to carry a sequence number, but other elements (such as block 1 and block 2 reverse information [1]) may need some encoding decisions.

> =E2=80=A2 what needs to be created, because nothing exists that meets the needs?

The actual protocol, i.e., the rules of action. (A best-effort, not fully reliable retransmit scheme; FEC parameter control loops; measurement schemes that go into these and into congestion feedback mechanisms.)

> 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
> =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?

I=E2=80=99m not aware of such a control loop in existing IETF standards, but I would love to be surprised.

> =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?

In most cases, this will be setup information (controller model).

> =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anythi= ng, because anything it does won't help ("first, do no harm")?

Again, probably setup information. The protocol could also define some thresholds for switching components on an off, on a relatively long time scale.

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

I hope the WG can find out once it exists=E2=80=A6

I would also like to avoid the FEC tail wagging with the LOOPS dog too much.
(I know, if you are standing very close to the tail, it may seem larger than the dog :-)

Yes, the sheer bulk and complexity of the specifications is larger in the FEC part than in the rest of the specifications. But then, FEC is relatively well understood, a lot of (re-)usable specifications are out there, and we even have a whole RG for that which we can tap. On the other hand, doing best-effort retransmissions (and FEC) on aggregate flows while we are experiencing increased presence of new-style end-to-end transports (encrypted, more reordering-tolerant) is a new engineering problem that needs a bit more focus from the WG.

.oOo.

By the way, I have generated a post-ietf105 branch on the charter text proposal [charter-0.3] that explicitly calls out focusing on retransmission initially and adding FEC later (with or without a rechartering needed); this version also adds milestones for a (shim-layer-in-)host-to-network component that was requested so vividly at the BOF.

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

[1]:=C2=A0ht= tps://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3
[2]:=C2=A0https://github.com/loo= ps-wg/charter/tree/post-105

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



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



--000000000000807ba705908a4d22-- From nobody Wed Aug 21 21:24: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 169A812006F for ; Wed, 21 Aug 2019 21:24:29 -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 dw2aa9G3wkj4 for ; Wed, 21 Aug 2019 21:24:26 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A3382120018 for ; Wed, 21 Aug 2019 21:24:25 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id h15so4184161ljg.10 for ; Wed, 21 Aug 2019 21:24:25 -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=/UEhAmXAAVyD09WZfx8mriP8enRhMVFmoylMITu1jfI=; b=c37Sj6Xx3B5ANcyLOSCSTw7rDFmcNYAy8mL73mW0LuqfBVlORJlUjFhov02te5pJKE aLbsHdoqddEbZ3Q++EXY3yj2y29gfXvL4RCfoGFiCabyyI8LJ/QcfhpRQ7NX9sTMBACM vyAKj8pEsT0w73w5bX5hQdmmB0KfZB0ZrdGZEypowQkJvSgePEb6qcvOFzEM1+qLlKIT no3t8GSa5ciLhAsJ0H50lSBJEZtEdAP8rUAwqYPXK80IFIqjxZwUXMvLTs14p0lRg472 bUZK1cx2/WDh+CGD/Ev4LdUz5xjw2Nigh1jSlT4pfX55yICR59HRw1/gVj+PdhSJsxoM FpbQ== 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=/UEhAmXAAVyD09WZfx8mriP8enRhMVFmoylMITu1jfI=; b=FDm9qv/sGDS2+M8n8zxg1fPbdfviFvJAX8yYYzPK67redCB1CXRydcoYHsFSuyUd7O +UxM5a2r0jH2pX/MzONpB5OPcaHnF+hQpH9qWxexFAsOfaxyiUOlv5j/CVlnTxXuW5ve 3Akdx5/D80PttwMbFOIVA9lUVTjNKkqD7PkKaA5dqUgZbb5ZYquclj6LM+bkLYuC9BSQ 1dIPGnlQzqHdEKQUvPTZJHjwmJPVonhzbKMu0DUa0xTgPPULfew9hcYeBHjp8Rgw/eGm cEpG8RXUkkIjZh59dOCf/foNCPbMq7Njv7kMagflqlM/HqA10HzT4qmfW5M4I9jCdz9Z nJnA== X-Gm-Message-State: APjAAAVaspQirc9y+9yNOMUlHDtVeZ+NtYQVbwZWNl872Xtaz9GeXFZx motoRaSRU9jXQB1tq0RXoy6j8D5Xt9YdgEZxYyo= X-Google-Smtp-Source: APXvYqwsW4oNTaxeBJh/jzTfRhUX1YQhoWNbN7Q9qkvuKxSgdwfPSGr2wiKDdeXS8EhfKejJUl8G96gL08HgLa00Nyk= X-Received: by 2002:a2e:91c6:: with SMTP id u6mr20641538ljg.68.1566447863770; Wed, 21 Aug 2019 21:24:23 -0700 (PDT) MIME-Version: 1.0 References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 21 Aug 2019 23:23:56 -0500 Message-ID: To: Colin Perkins Cc: Marie-Jose Montpetit , Carsten Bormann , Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Vincent Roca Content-Type: multipart/alternative; boundary="0000000000007ab11c0590ad10ac" 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, 22 Aug 2019 04:24:29 -0000 --0000000000007ab11c0590ad10ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Colin, On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins wrote: > One of the things we=E2=80=99d need to decide is what=E2=80=99s the path = from NWCRG into > IETF to standardise such things before use by LOOPS. > > FECFRAME seemed to work quite well. Is the goal to revive it and move som= e > work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME > extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS= ? > It seemed to me that doing the sliding window FECFRAME extension in TSVWG worked well enough (modulo a really amazing kerfluffle on getting a PRNG implementation that we could publish in an IETF RFC), although that decision would be up to Magnus and Mirja, at this point in the process. But the TSVWG co-chairs are already trained on what would be required from them. Spencer > I=E2=80=99d suggest either of the former two options make more sense than= the > latter. > > Colin > > > > On 20 Aug 2019, at 11:42, Marie-Jose Montpetit > wrote: > > Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as well a= s the > encapsulation and aggregated flow protocols that you want to investigate > are part of the work in the nwcrg (and yes not the IETF) and I would hope > that they will be reused by LOOPS. > > mjm > > Marie-Jos=C3=A9 Montpetit > > On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote: > > Hi Spencer, > > It is probably not too easy to generate a lot of excitement on this list > while most people are still on vacation, but let me try to answer your > questions. > > > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > [=E2=80=A6] > > So, my suggestion for the interested community is to nail down > > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, that can= be used without > changes? > > Most of IP :-) > > Seriously, the idea behind LOOPS is to use existing tunnel encapsulation > protocols with few additions, capitalizing on that work, and also making > use of ASIC support already present in devices =E2=80=94 it helps to be > encapsulation-agnostic for this. > > It is unlikely that we=E2=80=99ll have to invent another FEC scheme for L= OOPS, so > existing schemes can probably be used unchanged. I=E2=80=99m not so sure = the WG > won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2= =80=99t want to > design much of the protocol while we are still in a WG-forming stage, so > I=E2=80=99ll refrain from delving too much on why I think that may be a g= ood thing. > Basically, think about packet size distributions in general aggregated IP > flows vs. those in the RTP flows or even single transport flows that > FECFRAME schemes are being used with. > > Most likely, the time stamp formats (and even some algorithms around > those) we need can be stolen from existing work. > > Not much else can probably be used unchanged. > > > =E2=80=A2 what already exists, but needs to be extended for LOOPS? > > The encapsulation schemes may need to have their extension points > exercised to actually send the forward and reverse information in the bes= t > way. Some of the encapsulation protocols already define how to carry a > sequence number, but other elements (such as block 1 and block 2 reverse > information [1]) may need some encoding decisions. > > > =E2=80=A2 what needs to be created, because nothing exists that meets t= he needs? > > The actual protocol, i.e., the rules of action. (A best-effort, not fully > reliable retransmit scheme; FEC parameter control loops; measurement > schemes that go into these and into congestion feedback mechanisms.) > > > 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 > > =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based= on FEC > mechanisms people are thinking about, or is there work to do there? > > I=E2=80=99m not aware of such a control loop in existing IETF standards, = but I > would love to be surprised. > > > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both= FEC and > retransmission, dynamically? > > In most cases, this will be setup information (controller model). > > > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anythin= g, because > anything it does won't help ("first, do no harm")? > > Again, probably setup information. The protocol could also define some > thresholds for switching components on an off, on a relatively long time > scale. > > > Does everyone know how to do those three things, except me? :-) > > I hope the WG can find out once it exists=E2=80=A6 > > I would also like to avoid the FEC tail wagging with the LOOPS dog too > much. > (I know, if you are standing very close to the tail, it may seem larger > than the dog :-) > > Yes, the sheer bulk and complexity of the specifications is larger in the > FEC part than in the rest of the specifications. But then, FEC is > relatively well understood, a lot of (re-)usable specifications are out > there, and we even have a whole RG for that which we can tap. On the othe= r > hand, doing best-effort retransmissions (and FEC) on aggregate flows whil= e > we are experiencing increased presence of new-style end-to-end transports > (encrypted, more reordering-tolerant) is a new engineering problem that > needs a bit more focus from the WG. > > .oOo. > > By the way, I have generated a post-ietf105 branch on the charter text > proposal [charter-0.3] that explicitly calls out focusing on retransmissi= on > initially and adding FEC later (with or without a rechartering needed); > this version also adds milestones for a (shim-layer-in-)host-to-network > component that was requested so vividly at the BOF. > > Gr=C3=BC=C3=9Fe, Carsten > > [1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.= 3 > [2]: https://github.com/loops-wg/charter/tree/post-105 > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --0000000000007ab11c0590ad10ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Colin,=C2=A0

On Tue, Aug 20, 2019 at 5= :50 AM Colin Perkins <csp@csperkins= .org> wrote:
One of the things we=E2=80=99= d need to decide is what=E2=80=99s the path from NWCRG into IETF to standar= dise such things before use by LOOPS.

FECFRAME seemed to= work quite well. Is the goal to revive it and move some work from NWCRG? O= r to bring work from NWCRG into TSVWG to do FECFRAME extensions for LOOPS t= o reference? Or to bring work from NWCRG into LOOPS?=C2=A0

It seemed to me that doing the sliding window F= ECFRAME extension in TSVWG worked well enough (modulo a really amazing kerf= luffle on getting a PRNG implementation that we could publish in an IETF RF= C), although that decision would be up to Magnus and Mirja, at this point i= n the process. But the TSVWG co-chairs are already trained on what would be= required from them.=C2=A0

Spencer
=C2= =A0
I=E2=80=99d suggest either of the former two= options make more sense than the latter.=C2=A0

Colin



On 20 Aug 2019, at 11:42, Marie-Jose Montpetit <marie@mjmontpetit.com> wro= te:

Not =E2=80=9Cexcitement" but some of= the FEC control mechanisms as well as the encapsulation and aggregated flo= w protocols that you want to investigate are part of the work in the nwcrg = (and yes not the IETF) and I would hope that they will be reused by LOOPS.= =C2=A0

mjm

Marie-Jos=C3=A9 Montpetit

On August 20, 2019 at 5:47:24 AM, Carsten Bormann (<= a href=3D"mailto:cabo@tzi.org" target=3D"_blank">cabo@tzi.org) wrote:

Hi Spencer,

It is p= robably not too easy to generate a lot of excitement on this list while mos= t people are still on vacation, but let me try to answer your questions.
> On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF <spencerdawkins.iet= f@gmail.com> wrote:
>=C2=A0
> [=E2=80=A6]
> So, my s= uggestion for the interested community is to nail down
> =E2=80=A2 In= order to =E2=80=9Cdo LOOPS", what already exists, that can be used wi= thout changes?

Most of IP :-)

Seriously, the idea behind LOOP= S is to use existing tunnel encapsulation protocols with few additions, cap= italizing on that work, and also making use of ASIC support already present= in devices =E2=80=94 it helps to be encapsulation-agnostic for this.
It is unlikely that we=E2=80=99ll have to invent another FEC scheme for L= OOPS, so existing schemes can probably be used unchanged. I=E2=80=99m not s= o sure the WG won=E2=80=99t want to improve on the FECFRAME framework, thou= gh. I don=E2=80=99t want to design much of the protocol while we are still = in a WG-forming stage, so I=E2=80=99ll refrain from delving too much on why= I think that may be a good thing. Basically, think about packet size distr= ibutions in general aggregated IP flows vs. those in the RTP flows or even = single transport flows that FECFRAME schemes are being used with.

Mo= st likely, the time stamp formats (and even some algorithms around those) w= e need can be stolen from existing work.

Not much else can probably = be used unchanged.=C2=A0=C2=A0

> =E2=80=A2 what already exists, but n= eeds to be extended for LOOPS?

The encapsulation schemes may need to= have their extension points exercised to actually send the forward and rev= erse information in the best way. Some of the encapsulation protocols alrea= dy define how to carry a sequence number, but other elements (such as block= 1 and block 2 reverse information [1]) may need some encoding decisions.
> =E2=80=A2 what needs to be created, because nothing exists that = meets the needs?

The actual protocol, i.e., the rules of action. (A = best-effort, not fully reliable retransmit scheme; FEC parameter control lo= ops; measurement schemes that go into these and into congestion feedback me= chanisms.)

> I'm not a LOOPS proponent (the ADs asked me to c= hair the BOF about a month before IETF 105), but speaking as someone who ha= sn't been involved in depth, I wonder about
> =E2=80=A2 How a sen= der tunes FEC dynamically - is that automatic, based on FEC mechanisms peop= le are thinking about, or is there work to do there?

I=E2=80=99m not= aware of such a control loop in existing IETF standards, but I would love = to be surprised.

> =E2=80=A2 How a sender knows whether to do FEC= , retransmission, or both FEC and retransmission, dynamically?

In mo= st cases, this will be setup information (controller model).

> = =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anything, b= ecause anything it does won't help ("first, do no harm")?
=
Again, probably setup information. The protocol could also define some = thresholds for switching components on an off, on a relatively long time sc= ale.

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

I hope the WG can find out once it exists=E2=80=A6

I wo= uld also like to avoid the FEC tail wagging with the LOOPS dog too much.(I know, if you are standing very close to the tail, it may seem larger th= an the dog :-)

Yes, the sheer bulk and complexity of the specificati= ons is larger in the FEC part than in the rest of the specifications. But t= hen, FEC is relatively well understood, a lot of (re-)usable specifications= are out there, and we even have a whole RG for that which we can tap. On t= he other hand, doing best-effort retransmissions (and FEC) on aggregate flo= ws while we are experiencing increased presence of new-style end-to-end tra= nsports (encrypted, more reordering-tolerant) is a new engineering problem = that needs a bit more focus from the WG.

.oOo.

By the way, I = have generated a post-ietf105 branch on the charter text proposal [charter-= 0.3] that explicitly calls out focusing on retransmission initially and add= ing FEC later (with or without a rechartering needed); this version also ad= ds milestones for a (shim-layer-in-)host-to-network component that was requ= ested so vividly at the BOF.

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

[1]:=C2=A0https://tools.ietf.org/html/draft-welzl-loops-gen= -info-00#section-4.3
[2]:=C2=A0https://github.com/loops-wg/charte= r/tree/post-105

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



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




--0000000000007ab11c0590ad10ac-- From nobody Thu Aug 22 01:29:24 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 995611201E5 for ; Thu, 22 Aug 2019 01:29:22 -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 rT-uz_GeBqzz for ; Thu, 22 Aug 2019 01:29:19 -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 2F08612006D for ; Thu, 22 Aug 2019 01:29:19 -0700 (PDT) Received: from [81.187.2.149] (port=47418 helo=[192.168.0.86]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i0iSw-0000ES-6j; Thu, 22 Aug 2019 09:29:10 +0100 From: Colin Perkins Message-Id: <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FFA63400-C8E9-4AAC-A10A-1FEFE1A443E4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 22 Aug 2019 09:28:57 +0100 In-Reply-To: Cc: Marie-Jose Montpetit , Carsten Bormann , Suresh Krishnan , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org, Vincent Roca To: Spencer Dawkins at IETF References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 14 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, 22 Aug 2019 08:29:23 -0000 --Apple-Mail=_FFA63400-C8E9-4AAC-A10A-1FEFE1A443E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Makes sense =E2=80=93 although as you say, it=E2=80=99s for Magnus and = Mirja to decide.=20 Colin > On 22 Aug 2019, at 05:23, Spencer Dawkins at IETF = wrote: >=20 > Hi, Colin,=20 >=20 > On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins > wrote: > One of the things we=E2=80=99d need to decide is what=E2=80=99s the = path from NWCRG into IETF to standardise such things before use by = LOOPS. >=20 > FECFRAME seemed to work quite well. Is the goal to revive it and move = some work from NWCRG? Or to bring work from NWCRG into TSVWG to do = FECFRAME extensions for LOOPS to reference? Or to bring work from NWCRG = into LOOPS?=20 >=20 > It seemed to me that doing the sliding window FECFRAME extension in = TSVWG worked well enough (modulo a really amazing kerfluffle on getting = a PRNG implementation that we could publish in an IETF RFC), although = that decision would be up to Magnus and Mirja, at this point in the = process. But the TSVWG co-chairs are already trained on what would be = required from them.=20 >=20 > Spencer > =20 > I=E2=80=99d suggest either of the former two options make more sense = than the latter.=20 >=20 > Colin >=20 >=20 >=20 >> On 20 Aug 2019, at 11:42, Marie-Jose Montpetit > wrote: >>=20 >> Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as = well as the encapsulation and aggregated flow protocols that you want to = investigate are part of the work in the nwcrg (and yes not the IETF) and = I would hope that they will be reused by LOOPS.=20 >>=20 >> mjm >>=20 >> Marie-Jos=C3=A9 Montpetit >>=20 >> On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org = ) wrote: >>=20 >>> Hi Spencer, >>>=20 >>> It is probably not too easy to generate a lot of excitement on this = list while most people are still on vacation, but let me try to answer = your questions. >>>=20 >>> > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF = > = wrote: >>> >=20 >>> > [=E2=80=A6] >>> > So, my suggestion for the interested community is to nail down >>> > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, = that can be used without changes? >>>=20 >>> Most of IP :-) >>>=20 >>> Seriously, the idea behind LOOPS is to use existing tunnel = encapsulation protocols with few additions, capitalizing on that work, = and also making use of ASIC support already present in devices =E2=80=94 = it helps to be encapsulation-agnostic for this. >>>=20 >>> It is unlikely that we=E2=80=99ll have to invent another FEC scheme = for LOOPS, so existing schemes can probably be used unchanged. I=E2=80=99m= not so sure the WG won=E2=80=99t want to improve on the FECFRAME = framework, though. I don=E2=80=99t want to design much of the protocol = while we are still in a WG-forming stage, so I=E2=80=99ll refrain from = delving too much on why I think that may be a good thing. Basically, = think about packet size distributions in general aggregated IP flows vs. = those in the RTP flows or even single transport flows that FECFRAME = schemes are being used with. >>>=20 >>> Most likely, the time stamp formats (and even some algorithms around = those) we need can be stolen from existing work. >>>=20 >>> Not much else can probably be used unchanged. =20 >>>=20 >>> > =E2=80=A2 what already exists, but needs to be extended for LOOPS? >>>=20 >>> The encapsulation schemes may need to have their extension points = exercised to actually send the forward and reverse information in the = best way. Some of the encapsulation protocols already define how to = carry a sequence number, but other elements (such as block 1 and block 2 = reverse information [1]) may need some encoding decisions. >>>=20 >>> > =E2=80=A2 what needs to be created, because nothing exists that = meets the needs? >>>=20 >>> The actual protocol, i.e., the rules of action. (A best-effort, not = fully reliable retransmit scheme; FEC parameter control loops; = measurement schemes that go into these and into congestion feedback = mechanisms.) >>>=20 >>> > 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 >>> > =E2=80=A2 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 >>> I=E2=80=99m not aware of such a control loop in existing IETF = standards, but I would love to be surprised. >>>=20 >>> > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or = both FEC and retransmission, dynamically? >>>=20 >>> In most cases, this will be setup information (controller model). >>>=20 >>> > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing = anything, because anything it does won't help ("first, do no harm")? >>>=20 >>> Again, probably setup information. The protocol could also define = some thresholds for switching components on an off, on a relatively long = time scale. >>>=20 >>> > Does everyone know how to do those three things, except me? :-) >>>=20 >>> I hope the WG can find out once it exists=E2=80=A6 >>>=20 >>> I would also like to avoid the FEC tail wagging with the LOOPS dog = too much. >>> (I know, if you are standing very close to the tail, it may seem = larger than the dog :-) >>>=20 >>> Yes, the sheer bulk and complexity of the specifications is larger = in the FEC part than in the rest of the specifications. But then, FEC is = relatively well understood, a lot of (re-)usable specifications are out = there, and we even have a whole RG for that which we can tap. On the = other hand, doing best-effort retransmissions (and FEC) on aggregate = flows while we are experiencing increased presence of new-style = end-to-end transports (encrypted, more reordering-tolerant) is a new = engineering problem that needs a bit more focus from the WG. >>>=20 >>> .oOo. >>>=20 >>> By the way, I have generated a post-ietf105 branch on the charter = text proposal [charter-0.3] that explicitly calls out focusing on = retransmission initially and adding FEC later (with or without a = rechartering needed); this version also adds milestones for a = (shim-layer-in-)host-to-network component that was requested so vividly = at the BOF. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> [1]: = https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.3 = >>> [2]: https://github.com/loops-wg/charter/tree/post-105 = >>>=20 >>> --=20 >>> LOOPS mailing list >>> LOOPS@ietf.org >>> https://www.ietf.org/mailman/listinfo/loops = >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_FFA63400-C8E9-4AAC-A10A-1FEFE1A443E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Makes= sense =E2=80=93 although as you say, it=E2=80=99s for Magnus and Mirja = to decide. 
Colin



On 22 = Aug 2019, at 05:23, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Colin, 

On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins = <csp@csperkins.org> wrote:
One of the things we=E2=80=99d need to decide is = what=E2=80=99s the path from NWCRG into IETF to standardise such things = before use by LOOPS.

FECFRAME seemed to work quite well. Is the goal to revive it = and move some work from NWCRG? Or to bring work from NWCRG into TSVWG to = do FECFRAME extensions for LOOPS to reference? Or to bring work from = NWCRG into LOOPS? 

It seemed to me that doing the sliding = window FECFRAME extension in TSVWG worked well enough (modulo a really = amazing kerfluffle on getting a PRNG implementation that we could = publish in an IETF RFC), although that decision would be up to Magnus = and Mirja, at this point in the process. But the TSVWG co-chairs are = already trained on what would be required from them. 

Spencer
 
I=E2=80=99d suggest either of = the former two options make more sense than the latter. 

Colin



On 20 Aug 2019, at 11:42, = Marie-Jose Montpetit <marie@mjmontpetit.com> = wrote:

Not =E2=80=9Cexcitement" but some of = the FEC control mechanisms as well as the encapsulation and aggregated = flow protocols that you want to investigate are part of the work in the = nwcrg (and yes not the IETF) and I would hope that they will be reused = by LOOPS. 

mjm

Marie-Jos=C3=A9 Montpetit

On August 20, 2019 at 5:47:24 AM, Carsten = Bormann (cabo@tzi.org) wrote:

Hi Spencer,

It is probably not too easy to generate a lot of excitement = on this list while most people are still on vacation, but let me try to = answer your questions.

> On Jul 30, = 2019, at 16:22, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> <= br class=3D"">> [=E2=80=A6]
> So, my suggestion for = the interested community is to nail down
> =E2=80=A2 In = order to =E2=80=9Cdo LOOPS", what already exists, that can be used = without changes?

Most of IP :-)

Seriously, the idea behind LOOPS is to use = existing tunnel encapsulation protocols with few additions, capitalizing = on that work, and also making use of ASIC support already present in = devices =E2=80=94 it helps to be encapsulation-agnostic for this.

It is unlikely that we=E2=80=99ll have to = invent another FEC scheme for LOOPS, so existing schemes can probably be = used unchanged. I=E2=80=99m not so sure the WG won=E2=80=99t want to = improve on the FECFRAME framework, though. I don=E2=80=99t want to = design much of the protocol while we are still in a WG-forming stage, so = I=E2=80=99ll refrain from delving too much on why I think that may be a = good thing. Basically, think about packet size distributions in general = aggregated IP flows vs. those in the RTP flows or even single transport = flows that FECFRAME schemes are being used with.

Most likely, the time stamp formats (and even some algorithms = around those) we need can be stolen from existing work.

Not much else can probably be used unchanged. <= span = class=3D"gmail-m_-7260910430368291340Apple-converted-space"> <= br class=3D"">
> =E2=80=A2 what already exists, but = needs to be extended for LOOPS?

The = encapsulation schemes may need to have their extension points exercised = to actually send the forward and reverse information in the best way. = Some of the encapsulation protocols already define how to carry a = sequence number, but other elements (such as block 1 and block 2 reverse = information [1]) may need some encoding decisions.

> =E2=80=A2 what needs to be created, because nothing = exists that meets the needs?

The actual = protocol, i.e., the rules of action. (A best-effort, not fully reliable = retransmit scheme; FEC parameter control loops; measurement schemes that = go into these and into congestion feedback mechanisms.)

> 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
> =E2=80=A2 How = a sender tunes FEC dynamically - is that automatic, based on FEC = mechanisms people are thinking about, or is there work to do there?

I=E2=80=99m not aware of such a control loop = in existing IETF standards, but I would love to be surprised.

> =E2=80=A2 How a sender knows whether to = do FEC, retransmission, or both FEC and retransmission, dynamically?

In most cases, this will be setup information = (controller model).

> =E2=80=A2 How a = sender knows that it shouldn=E2=80=99t be doing anything, because = anything it does won't help ("first, do no harm")?

Again, probably setup information. The protocol could also = define some thresholds for switching components on an off, on a = relatively long time scale.

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

I hope the WG can find out once it = exists=E2=80=A6

I would also like to avoid = the FEC tail wagging with the LOOPS dog too much.
(I know, = if you are standing very close to the tail, it may seem larger than the = dog :-)

Yes, the sheer bulk and complexity = of the specifications is larger in the FEC part than in the rest of the = specifications. But then, FEC is relatively well understood, a lot of = (re-)usable specifications are out there, and we even have a whole RG = for that which we can tap. On the other hand, doing best-effort = retransmissions (and FEC) on aggregate flows while we are experiencing = increased presence of new-style end-to-end transports (encrypted, more = reordering-tolerant) is a new engineering problem that needs a bit more = focus from the WG.

.oOo.

By the way, I have generated a post-ietf105 branch on the = charter text proposal [charter-0.3] that explicitly calls out focusing = on retransmission initially and adding FEC later (with or without a = rechartering needed); this version also adds milestones for a = (shim-layer-in-)host-to-network component that was requested so vividly = at the BOF.

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

[1]: <= a = href=3D"https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-= 4.3" target=3D"_blank" = class=3D"">https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#secti= on-4.3
[2]: <= a href=3D"https://github.com/loops-wg/charter/tree/post-105" = target=3D"_blank" = class=3D"">https://github.com/loops-wg/charter/tree/post-105

-- <= br class=3D"">LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops



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







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




= --Apple-Mail=_FFA63400-C8E9-4AAC-A10A-1FEFE1A443E4-- From nobody Thu Aug 22 04:22:56 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 A122312004E for ; Thu, 22 Aug 2019 04:22:54 -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 mKpsooR8E3fU for ; Thu, 22 Aug 2019 04:22:52 -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 3458A120026 for ; Thu, 22 Aug 2019 04:22:52 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id j4so2724083iog.11 for ; Thu, 22 Aug 2019 04:22: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=0xvNjYV0TV0SQI9BV7bQqO8M528qKnUR2Jyp9gZ5/RI=; b=zz/tO2mG7Lguh4trBzF9J1q5IfKNXKR8NfcSE2W3Wn7LX3nIeTI6L7+SnUEByj3yEd a6ruKct4ctwTItg1c8QGio6JRDZ/Mz0yVjvgWGSgLbgARWo/FRADReYis10azoOUcWNN B9OgMdPILk/JgLxsljChcD3RQ+YCAFJHAxQV5PapqzRRWv/MveJ0Q0BI5kUYdhLaoR3z 6o3nkHVt88fnkOTf3m6QPsIDwQjaZSNo3/AIfks1guO2QwKkLNV6u4Cgf3t4natHfB71 7VTZY5fzV78e+Yx8/E3Ub7j24djFrJ8SUTftXayL6+0YIqVDY+5OEacyuBVkg9QuK2gE r02g== 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=0xvNjYV0TV0SQI9BV7bQqO8M528qKnUR2Jyp9gZ5/RI=; b=YrXvTeHBmBVQgz/XirsSWnvvmm/jMlrlH1ueSVtmsQNDzEYM7lzH1sCIsEVIitRFpu d9WzcgRy9n/1nZysdRysmAGRGwK3uMon0XS4lC8by8nNlgIFvL5z0W+zLH9ierqz3JQM R/R67Hr2IGyJ617xW2lrosg0ZQL39SwoVz+gjqmaD0KqdQSFdg/6mYrLUeJ/qrzIM73y 2iV5dhKqFyILivFjbZkVmud2Kk8pQlkeaba4NvFEfTBcaffgtrptdqL1aNOSJZ+0nO+a hmEUvLmF1TGen6NhEItFiLPh2/fbR0Bp7crWljiJ8+wtwbTJYe0MXqTRxPM/1AAlsCPL Nzvw== X-Gm-Message-State: APjAAAUFTWU/UGJQg5HajI8eoITVWEshGIJm6P6IHm1hZEc946+PSFWW Bqm5ul5XPolSFreq2txL5537Be+5Z93WS+/GTsyNEQ== X-Google-Smtp-Source: APXvYqwecWC+OfKKR/iKXXf2s6MWOhlRNfcVAq3TWmtvEAqX9H2pIbmC7UyHfIL4Y6IagtuEvKp9bMAOw38Gw4xyAj4= X-Received: by 2002:a5e:a502:: with SMTP id 2mr19653273iog.269.1566472971380; Thu, 22 Aug 2019 04:22:51 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 22 Aug 2019 07:22:50 -0400 From: Marie-Jose Montpetit In-Reply-To: <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org> References: <08D42FCB-DBC5-488B-A0E4-08230843E173@tzi.org> <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org> <7A961B76-8193-43C4-96EC-379149BA6505@csperkins.org> MIME-Version: 1.0 Date: Thu, 22 Aug 2019 07:22:50 -0400 Message-ID: To: Colin Perkins , Spencer Dawkins at IETF Cc: Suresh Krishnan , Vincent Roca , Carsten Bormann , Magnus Westerlund , Mirja Kuehlewind , loops@ietf.org Content-Type: multipart/alternative; boundary="0000000000000282130590b2e931" 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, 22 Aug 2019 11:22:55 -0000 --0000000000000282130590b2e931 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just an add on: Besides the code that was presented within FECFRAME, NWCRG is also working on API for sliding window codes: https://datatracker.ietf.org/doc/draft-roca-nwcrg-generic-fec-api/ And of course we have a hackaton to develop an open source codec and the LOOPS community is more that welcome to participate. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. Research Affiliate, MIT Media Laboratory mariejose@mjmontpetit.com mariejo@mit.edu On August 22, 2019 at 4:29:11 AM, Colin Perkins (csp@csperkins.org) wrote: Makes sense =E2=80=93 although as you say, it=E2=80=99s for Magnus and Mirj= a to decide. Colin On 22 Aug 2019, at 05:23, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: Hi, Colin, On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins wrote: > One of the things we=E2=80=99d need to decide is what=E2=80=99s the path = from NWCRG into > IETF to standardise such things before use by LOOPS. > > FECFRAME seemed to work quite well. Is the goal to revive it and move som= e > work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME > extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS= ? > It seemed to me that doing the sliding window FECFRAME extension in TSVWG worked well enough (modulo a really amazing kerfluffle on getting a PRNG implementation that we could publish in an IETF RFC), although that decision would be up to Magnus and Mirja, at this point in the process. But the TSVWG co-chairs are already trained on what would be required from them. Spencer > I=E2=80=99d suggest either of the former two options make more sense than= the > latter. > > Colin > > > > On 20 Aug 2019, at 11:42, Marie-Jose Montpetit > wrote: > > Not =E2=80=9Cexcitement" but some of the FEC control mechanisms as well a= s the > encapsulation and aggregated flow protocols that you want to investigate > are part of the work in the nwcrg (and yes not the IETF) and I would hope > that they will be reused by LOOPS. > > mjm > > Marie-Jos=C3=A9 Montpetit > > On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote: > > Hi Spencer, > > It is probably not too easy to generate a lot of excitement on this list > while most people are still on vacation, but let me try to answer your > questions. > > > On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > [=E2=80=A6] > > So, my suggestion for the interested community is to nail down > > =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, that can= be used without > changes? > > Most of IP :-) > > Seriously, the idea behind LOOPS is to use existing tunnel encapsulation > protocols with few additions, capitalizing on that work, and also making > use of ASIC support already present in devices =E2=80=94 it helps to be > encapsulation-agnostic for this. > > It is unlikely that we=E2=80=99ll have to invent another FEC scheme for L= OOPS, so > existing schemes can probably be used unchanged. I=E2=80=99m not so sure = the WG > won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2= =80=99t want to > design much of the protocol while we are still in a WG-forming stage, so > I=E2=80=99ll refrain from delving too much on why I think that may be a g= ood thing. > Basically, think about packet size distributions in general aggregated IP > flows vs. those in the RTP flows or even single transport flows that > FECFRAME schemes are being used with. > > Most likely, the time stamp formats (and even some algorithms around > those) we need can be stolen from existing work. > > Not much else can probably be used unchanged. > > > =E2=80=A2 what already exists, but needs to be extended for LOOPS? > > The encapsulation schemes may need to have their extension points > exercised to actually send the forward and reverse information in the bes= t > way. Some of the encapsulation protocols already define how to carry a > sequence number, but other elements (such as block 1 and block 2 reverse > information [1]) may need some encoding decisions. > > > =E2=80=A2 what needs to be created, because nothing exists that meets t= he needs? > > The actual protocol, i.e., the rules of action. (A best-effort, not fully > reliable retransmit scheme; FEC parameter control loops; measurement > schemes that go into these and into congestion feedback mechanisms.) > > > 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 > > =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based= on FEC > mechanisms people are thinking about, or is there work to do there? > > I=E2=80=99m not aware of such a control loop in existing IETF standards, = but I > would love to be surprised. > > > =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both= FEC and > retransmission, dynamically? > > In most cases, this will be setup information (controller model). > > > =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anythin= g, because > anything it does won't help ("first, do no harm")? > > Again, probably setup information. The protocol could also define some > thresholds for switching components on an off, on a relatively long time > scale. > > > Does everyone know how to do those three things, except me? :-) > > I hope the WG can find out once it exists=E2=80=A6 > > I would also like to avoid the FEC tail wagging with the LOOPS dog too > much. > (I know, if you are standing very close to the tail, it may seem larger > than the dog :-) > > Yes, the sheer bulk and complexity of the specifications is larger in the > FEC part than in the rest of the specifications. But then, FEC is > relatively well understood, a lot of (re-)usable specifications are out > there, and we even have a whole RG for that which we can tap. On the othe= r > hand, doing best-effort retransmissions (and FEC) on aggregate flows whil= e > we are experiencing increased presence of new-style end-to-end transports > (encrypted, more reordering-tolerant) is a new engineering problem that > needs a bit more focus from the WG. > > .oOo. > > By the way, I have generated a post-ietf105 branch on the charter text > proposal [charter-0.3] that explicitly calls out focusing on retransmissi= on > initially and adding FEC later (with or without a rechartering needed); > this version also adds milestones for a (shim-layer-in-)host-to-network > component that was requested so vividly at the BOF. > > Gr=C3=BC=C3=9Fe, Carsten > > [1]: https://tools.ietf.org/html/draft-welzl-loops-gen-info-00#section-4.= 3 > [2]: https://github.com/loops-wg/charter/tree/post-105 > > -- > LOOPS mailing list > LOOPS@ietf.org > https://www.ietf.org/mailman/listinfo/loops > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --=20 Colin Perkins https://csperkins.org/ --0000000000000282130590b2e931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Just= an add on:
=
Besides= the code that was presented within FECFRAME, NWCRG is also working on API = for sliding window codes:=C2=A0https://datatracker.ietf.org/doc/draft-r= oca-nwcrg-generic-fec-api/
And of course we have a hackaton to develop an open sour= ce codec and the LOOPS community is more that welcome to participate.
=

mjm

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

On Aug= ust 22, 2019 at 4:29:11 AM, Colin Perkins (csp@csperkins.org) wrote:

Makes sense =E2=80=93 although as you say, it=E2=80=99s for Magnus and Mirj= a to decide.=C2=A0
Colin



On 22 Aug 2019, at 05:23, Spencer Dawkins at IETF <spencerdawk= ins.ietf@gmail.com> wrote:

Hi, Colin,=C2=A0

On Tue, Aug 20, 2019 at 5:50 AM Colin Perkins <csp@csper= kins.org> wrote:
One of the things we=E2=80=99d need to decide is what=E2=80=99s the path from NWCRG into IETF= to standardise such things before use by LOOPS.

FECFRAME seemed to work quite well. Is the goal to revive it and move some work from NWCRG? Or to bring work from NWCRG into TSVWG to do FECFRAME extensions for LOOPS to reference? Or to bring work from NWCRG into LOOPS?=C2=A0

It seemed to me that doing the sliding window FECFRAME extension in TSVWG worked well enough (modulo a really amazing kerfluffle on getting a PRNG implementation that we could publish in an IETF RFC), although that decision would be up to Magnus and Mirja, at this point in the process. But the TSVWG co-chairs are already trained on what would be required from them.=C2=A0

Spencer
=C2=A0
I=E2=80=99d suggest either of the former two options make more sense than the latter.=C2=A0

Colin



On 20 Aug 2019, at 11:42, Marie-Jose Montpetit <m= arie@mjmontpetit.com> wrote:

Not =E2=80=9Cexcitement" but som= e of the FEC control mechanisms as well as the encapsulation and aggregated flow protocols that you want to investigate are part of the work in the nwcrg (and yes not the IETF) and I would hope that they will be reused by LOOPS.=C2=A0

mjm

Marie-Jos=C3=A9 Montpetit

On August 20, 2019 at 5:47:24 AM, Carsten Bormann (cabo@tzi.org) wrote:

Hi Spencer,

It is probably not too easy to generate a lot of excitement on this list while most people are still on vacation, but let me try to answer your questions.

> On Jul 30, 2019, at 16:22, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>=C2= =A0
> [=E2=80=A6]
> So, my suggestion for the interested community is to nail down
> =E2=80=A2 In order to =E2=80=9Cdo LOOPS", what already exists, th= at can be used without changes?

Most of IP :-)

Seriously, the idea behind LOOPS is to use existing tunnel encapsulation protocols with few additions, capitalizing on that work, and also making use of ASIC support already present in devices =E2=80=94 it helps to be encapsulation-agnostic for this.

It is unlikely that we=E2=80=99ll have to invent another FEC scheme for LOOPS, so existing schemes can probably be used unchanged. I=E2=80=99m not so sure the WG won=E2=80=99t want to improve on the FECFRAME framework, though. I don=E2=80=99t want to design much of the protocol while we are still in a WG-forming stage, so I=E2=80=99ll refrain from delving too much on why I think that may be a good thing. Basically, think about packet size distributions in general aggregated IP flows vs. those in the RTP flows or even single transport flows that FECFRAME schemes are being used with.

Most likely, the time stamp formats (and even some algorithms around those) we need can be stolen from existing work.

Not much else can probably be used unchanged.=C2=A0=C2=A0

> =E2=80=A2 what already exists, but needs to be extended for LOOPS?

The encapsulation schemes may need to have their extension points exercised to actually send the forward and reverse information in the best way. Some of the encapsulation protocols already define how to carry a sequence number, but other elements (such as block 1 and block 2 reverse information [1]) may need some encoding decisions.

> =E2=80=A2 what needs to be created, because nothing exists that meets the needs?

The actual protocol, i.e., the rules of action. (A best-effort, not fully reliable retransmit scheme; FEC parameter control loops; measurement schemes that go into these and into congestion feedback mechanisms.)

> 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
> =E2=80=A2 How a sender tunes FEC dynamically - is that automatic, based on FEC mechanisms people are thinking about, or is there work to do there?

I=E2=80=99m not aware of such a control loop in existing IETF standards, but I would love to be surprised.

> =E2=80=A2 How a sender knows whether to do FEC, retransmission, or both FEC and retransmission, dynamically?

In most cases, this will be setup information (controller model).

> =E2=80=A2 How a sender knows that it shouldn=E2=80=99t be doing anythi= ng, because anything it does won't help ("first, do no harm")?

Again, probably setup information. The protocol could also define some thresholds for switching components on an off, on a relatively long time scale.

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

I hope the WG can find out once it exists=E2=80=A6

I would also like to avoid the FEC tail wagging with the LOOPS dog too much.
(I know, if you are standing very close to the tail, it may seem larger than the dog :-)

Yes, the sheer bulk and complexity of the specifications is larger in the FEC part than in the rest of the specifications. But then, FEC is relatively well understood, a lot of (re-)usable specifications are out there, and we even have a whole RG for that which we can tap. On the other hand, doing best-effort retransmissions (and FEC) on aggregate flows while we are experiencing increased presence of new-style end-to-end transports (encrypted, more reordering-tolerant) is a new engineering problem that needs a bit more focus from the WG.

.oOo.

By the way, I have generated a post-ietf105 branch on the charter text proposal [charter-0.3] that explicitly calls out focusing on retransmission initially and adding FEC later (with or without a rechartering needed); this version also adds milestones for a (shim-layer-in-)host-to-network component that was requested so vividly at the BOF.

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

[1]:=C2= =A0https://tools.ietf.org/html/d= raft-welzl-loops-gen-info-00#section-4.3
[2]:=C2= =A0https://github.com/loops-wg/charter/tree/post-105=

--=C2=A0<= /span>
LOOPS mailing list
LOOPS@ietf.o= rg
https://www.ietf.org/mailman/listinfo/loops



--=C2=A0
Colin Perkins
https://csp= erkins.org/







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



--0000000000000282130590b2e931--