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

Wesley Eddy <wes@mti-systems.com> Tue, 30 July 2019 16:16 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575B512016F for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 09:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diAUS83lzNxd for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 09:15:59 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B8D12015C for <loops@ietf.org>; Tue, 30 Jul 2019 09:15:59 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id s7so129276540iob.11 for <loops@ietf.org>; Tue, 30 Jul 2019 09:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=lQ9b/HG9RWw2I7ZpBy8qSQrPsAclxrChp/vJWlAgss4=; b=voL35qH9WTGXzX8D4FLIiWm+zd9jKyRnNA20nFOFEfWECdPAGRlXf1pQ6Gz4za15G1 lKyAw9dg51H2QZqhoYMYv9tJADyfZoLvbohXhypG6hSTmTtCVyFOH+yBSF/3JM92PiaT ZlYyGxo4xoklTu0qDt2tNJ9TAkpn5L9vfbpJ/1uFLTza/wpwZa5lKRGnLN2t5t+FfOMZ XBwXd2T6IoOqh/unGUn0g+bqbG6OiFWMyLv3WcEp2zH3fADerSGwTg8MeF3ZVG6zcBsZ M+C5AjUvIEGg6OwGNJSZek1Ahw1RSKSMeHlmY4zYuDxD46vCeG2wi1tOuv5FnmAPv/tG dcLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lQ9b/HG9RWw2I7ZpBy8qSQrPsAclxrChp/vJWlAgss4=; b=ZQRq18MpKwlVHmpez3+X0cOvz+g0/DKddTSHu40eAfKn3/765xULCzS9aenL7t7LyM S+nuZPzv8OhhIaDjjM1mjfmZ4rAEmcdt+rea/R6beJossu6DQDNhdFjEpXXYwnSEJngW ObycJ1/k/gMrd8jXFFve4v4+Id8F3SB5phlw1wfUQWG3pJ8vF0NhdzQt7G/Z0PjTeIz5 AIxGljDOHgyNKQe6DLByuYX3DS90pM8juYdGj7/drphhWBD0om2rB6UHJbEYP27mov+W U8wDqTtcNPjRvncZ/VwpFqbsZOkDK4XYQ/1H+D6DUGk0h99MV4TEE0XdayflnyaVMQF6 drFw==
X-Gm-Message-State: APjAAAWeChuDZNYumg0ws9ECRbbnrrGfPVZdlccn4VIGm5kbPQLgAvPT fgJ0T9xsKUTTZ1pew3nNIgAaNSEF
X-Google-Smtp-Source: APXvYqyzB/M98+5ZnqckiEOLMzaD03vrZxJBxi8YbIY8o76YyBPIA31Guee8heMPnIEgyejZWLx8uw==
X-Received: by 2002:a6b:f910:: with SMTP id j16mr36696512iog.256.1564503358121; Tue, 30 Jul 2019 09:15:58 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id a1sm51306520ioo.5.2019.07.30.09.15.56 for <loops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 09:15:57 -0700 (PDT)
To: loops@ietf.org
References: <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> <A4576796-AACA-4BE1-9EF8-9422E1BAB9F3@kuehlewind.net> <CAKKJt-dCeJVhofU8eO=TXu6CVez5g9ZTdLnp206gx6X3YTx9tA@mail.gmail.com>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <c8c5332d-a41d-7750-5605-285b9c449b8a@mti-systems.com>
Date: Tue, 30 Jul 2019 12:15:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-dCeJVhofU8eO=TXu6CVez5g9ZTdLnp206gx6X3YTx9tA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------52299EE2264D59214376781E"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/f5S2-XJbmSzRiw3P-Kb66hfOaRg>
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: Tue, 30 Jul 2019 16:16:01 -0000

On 7/30/2019 10:22 AM, Spencer Dawkins at IETF wrote:
>
> Thanks for giving me the chance to clarify - I really was talking 
> about chartering work, not just chartering a working group, but that 
> wasn't clear from my note. As you said, knowing what the work is, in 
> more detail, will help you and Magnus know what to do next.
>
> So, my suggestion for the interested community is to nail down
>
>  1. In order to "do LOOPS", what already exists, that can be used
>     without changes?
>  2. what already exists, but needs to be extended for LOOPS?
>  3. what needs to be created, because nothing exists that meets the needs?
>
>  I'm not a LOOPS proponent (the ADs asked me to chair the BOF about a 
> month before IETF 105), but speaking as someone who hasn't been 
> involved in depth, I wonder about
>
>  1. How a sender tunes FEC dynamically - is that automatic, based on
>     FEC mechanisms people are thinking about, or is there work to do
>     there?
>  2. How a sender knows whether to do FEC, retransmission, or both FEC
>     and retransmission, dynamically?
>  3. How a sender knows that it shouldn't be doing anything, because
>     anything it does won't help ("first, do no harm")?
>
> Does everyone know how to do those three things, except me? :-)
>
I skimmed the drafts, but might be missing some context still ... LOOPS 
seems like it is intended for "dumb" subnetworks, but could be 
potentially harmful over "smarter" subnetworks.

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