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

Wesley Eddy <wes@mti-systems.com> Tue, 30 July 2019 18:21 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 D52561201E2 for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 11:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU0G7w-0FKSI for <loops@ietfa.amsl.com>; Tue, 30 Jul 2019 11:21:17 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC6A1201D5 for <loops@ietf.org>; Tue, 30 Jul 2019 11:21:16 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id o9so26756997iom.3 for <loops@ietf.org>; Tue, 30 Jul 2019 11:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=HiXgzd3xDeCu33++J3vyLkmpIbqENCwLb+3r2/ejLyw=; b=Q3NpBJzWZSMKO8xfBW1sxiaec29ztvWQ02IAXZ40bHtepDZmDE36GFymuM5TjdnZh9 PFbhMkLxBqgB+kw1xr7eEIV1mcGRCxh7TQST2YkJ1b7zc5IfiCQXxuaystbO6prJKU8X 5c9vNjrDOQTtNun0QX4kcxjEyOH/aYtgcgvNX4zLy0MAFMbTSjbCWkRcW8eXSt+9YiIA LIo8cGYm1Qe/Xay+3pdiSVy9pw+OENHd4Npb6GeIByNj1UuiN0h+4t6EpaNjv5vJKQTU Ke89VaSviByvieWM/ah2uNZfPhRjdNh7IqXq7FO7pPb6Z4Ep/Ni8aNnzcTlyUBhk/T3R 78kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HiXgzd3xDeCu33++J3vyLkmpIbqENCwLb+3r2/ejLyw=; b=AuZ3T/oazsVpUxjyBFv2eoMQvAVKj7+b/4jEdSN5beNGrkctEDcUUZbKX63aL5sUGl 0g/Vbevefop6OAYR7MaIyZSglG+5pCTefpg1Hs6xGL6te3/d076mHQqjlZo5B4hDEk5F dWUOYEcmfooomsUHJATZuHj2JKWbOHxwf/cg4PyJm2wvpuoux/A1W0qPYubv8OJnYxUx lisxLgFdRYwAAynfV6mEX7VahDR/AxklrxbdsbHx5Gp+lyPAqBetAlrGObq1T3jNeWgo 3ddQKXtuloXdeSOPfpmRJnIn+yBEJtgIEZRV5wuh2n1ONytVy3Z5xn4ad42mjkQjJv3x u/+A==
X-Gm-Message-State: APjAAAV3SFmBYFL9s4jiS0JYYnMpRxjzi7z6m9tdMICHYnMF2BDLYwxf KBOmjyaNo+e6uM5NAT8vuodrCqX7
X-Google-Smtp-Source: APXvYqyXKzmIv6K476uFU8YJZJTNKSdxg2ITxwHlSXVkKi4R7yXAnqBgtt8yABzlQs+u0H353uD+Gw==
X-Received: by 2002:a5d:9d42:: with SMTP id k2mr60530054iok.45.1564510876032; Tue, 30 Jul 2019 11:21:16 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id l5sm118896991ioq.83.2019.07.30.11.21.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 11:21:15 -0700 (PDT)
To: Carsten Bormann <cabo@tzi.org>
Cc: 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> <c8c5332d-a41d-7750-5605-285b9c449b8a@mti-systems.com> <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <6e81559d-2e7e-7c7c-c94d-b712ab264102@mti-systems.com>
Date: Tue, 30 Jul 2019 14:21:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <989AE262-118E-479B-A3FF-1964166F8A32@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/9mtpYH2IB8aKDbEON2qJ63FYqQ4>
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 18:21:19 -0000

On 7/30/2019 12:30 PM, Carsten Bormann wrote:
>> I skimmed the drafts, but might be missing some context still ... LOOPS seems like it is intended for “dumb" subnetworks, but could be potentially harmful over "smarter" subnetworks.
> If the path segment already tries to be “helpful”, there might indeed be an adverse interaction.  Or the “help” might only be available or effective for certain transport protocols, and LOOPS can still do something useful for those not (yet!) covered (for instance, this could be QUIC).  Also, the “help” might be geared towards close interaction with the transport, and adding a tunnel layer could interfere with this.  So whether running LOOPS on a Sat PEP is useful in any way or even detrimental depends a lot on how up-to-date that PEP is.  Note that the entity running LOOPS may not be the entity running the Sat PEP, so it may not have control over the PEP situation.
>
> Running LOOPS on the path segments from host to Sat and from the Sat to host can remove the need for some costly (in bandwidth and latency) retransmissions on the Sat link itself.
>
>> For satellite links, there is the capability to do per-frame adaptive coding and modulation (based on traffic classification).  When the lower layer offers service tailored for the needs of each packet already, LOOPS doing something up above is possibly at odds with this.  It’s easy to imagine scenarios where this leads to actual performance degradation, positive feedback loops, or other problems, so I'm interested in what people have done or been thinking about in this regard.
> LOOPS is not meant as pixie dust that you sprinkle indiscriminately over your network.
> The cost is not entirely trivial and the benefits depend on the characteristics of both the path and the traffic.
> You should have a reason to use LOOPS.
> See above for some potential reasons to use LOOPS on top of Sat PEPs.


You mention PEP a few times, but I didn't mention PEP, but rather the 
modulation and coding in satellite modems.  The framing and selection of 
MODCOD done by a modem is a lower layer function that's not related to 
PEP techniques at higher layers.