Re: [LOOPS] BOF co-chairs thinking on LOOPS next steps

Carsten Bormann <cabo@tzi.org> Thu, 01 August 2019 07:03 UTC

Return-Path: <cabo@tzi.org>
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 <loops@ietfa.amsl.com>; 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 <loops@ietfa.amsl.com>; 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 <loops@ietf.org>; 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 <cabo@tzi.org>
In-Reply-To: <CAPjWiCRXs72=tDBmNyrnB0yXFB8H0pYqUZNjV2f5TWyeXLkQGw@mail.gmail.com>
Date: Thu, 01 Aug 2019 09:03:14 +0200
Cc: Michael Welzl <michawe@ifi.uio.no>, "loops@ietf.org" <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: <CAKKJt-eRGJe+9PtEC7xgFz+HA0zsr_sR0NUgKRmJ-P5Q3XBg-A@mail.gmail.com> <CAPjWiCSbPioTHkYBpX73qxzO=H1sJDZpCMCKzBKoU4rZLLhwMQ@mail.gmail.com> <E6659E42-D6D7-4033-B4D6-9305823063D2@tzi.org> <CAKKJt-c24RdPyZRoK-B6fXuN0xABUsU=p7Y6UFwAcENfjE3oOQ@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330312ECCEB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAPjWiCTo+TjgJ97TTyY3yF=9BAiEyqnyDNbaHjXdqzW5h3JjAw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B9330312ECFCF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAPjWiCQpZ_60XO8+5dFC4Gp8Jh=bjpQSOnVE85LZi=OtjwP=Uw@mail.gmail.com> <EDE4C911-86A2-4347-B623-4B0CEF26C5D4@ifi.uio.no> <7C016290-2FB9-4DCF-9213-749B2B27D4D0@tzi.org> <CAPjWiCRXs72=tDBmNyrnB0yXFB8H0pYqUZNjV2f5TWyeXLkQGw@mail.gmail.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/OCp2APxTnXN4Zly8tsanwMjQf4E>
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 <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 07:03:24 -0000

On Aug 1, 2019, at 01:28, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
> 
> Actually in FEC you do not process every packet. In what is called “systematic mode” 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’t 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’ll want to do.)

This is not a theoretical concern; processing speed is a make-or-break consideration for many applications of LOOPS.

Grüße, Carsten


> 
> 
> mjm
> 
> Marie-José Montpetit, Ph.D.
> Research Affiliate, MIT Media Laboratory
> mariejose@mjmontpetit.com
> mariejo@mit.edu
> 
> On July 31, 2019 at 7:11:41 PM, Carsten Bormann (cabo@tzi.org) wrote:
> 
>> On Aug 1, 2019, at 00:18, Michael Welzl <michawe@ifi.uio.no> wrote:
>> > 
>> > if the packet loss ratio is known
>> 
>> Conversely, retransmission can be better to handle random, bursty losses.
>> (For a definition of “better”, which may depend on your needs.)
>> 
>> But more importantly, for retransmission, the ingress node needs to store copies of packets for a while (and retransmit from this cache), and the egress node needs to send ACKs. This is much less work per packet than doing FEC, which needs processing of the contents of each packet. So nodes may be able to do retransmission LOOPS at a higher rate than they would be able to do FEC LOOPS.
>> 
>> Grüße, Carsten
>> 
>> -- 
>> LOOPS mailing list
>> LOOPS@ietf.org
>> https://www.ietf.org/mailman/listinfo/loops
> -- 
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops