Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases.

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 30 July 2020 08:25 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 CF9CE3A0FA2 for <loops@ietfa.amsl.com>; Thu, 30 Jul 2020 01:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 P85o9ZGzuTym for <loops@ietfa.amsl.com>; Thu, 30 Jul 2020 01:25:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id B65333A0FA3 for <loops@ietf.org>; Thu, 30 Jul 2020 01:25:03 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 56FA61B001C2; Thu, 30 Jul 2020 09:24:45 +0100 (BST)
To: Carsten Bormann <cabo@tzi.org>
Cc: loops <loops@ietf.org>
References: <fb709277-50a8-26ad-b925-38f153805d70@erg.abdn.ac.uk> <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <ef474296-1bcc-ddf2-7d44-22d3dcd4cdba@erg.abdn.ac.uk>
Date: Thu, 30 Jul 2020 09:24:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <9DE9734F-E0D1-4B19-834C-CA10EDD97DC7@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/inNaM3_eSLCJDC21Kz0MInc-J54>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities and use-cases.
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, 30 Jul 2020 08:25:08 -0000

Hi Carston,

On 29/07/2020 22:52, Carsten Bormann wrote:
> Hi Gorry,
>
> thank you for these comments.
>
> One of the shortcomings that this document has is that, in describing scenarios, it does not always make perfectly clear which part is solved by LOOPS and which parts need to be solved by other means so the scenario works and LOOPS is effective.

I think this is exactly my feeling, and to me this is important to 
understand any WG BoF. It helps to be able to separate specific 
applicability for general use and focussed on specific problems; and 
separate the proposed technology, from dependent technology and 
separable technologies.

> On 2020-07-27, at 17:21, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>> Thank you for the scenarios update in draft-li-tsvwg-loops-problem-opportunities, I see you have updated the text relating to satellite network segments. I now have some more questions on scenarios based on the what is said in the most recent ID:
>>
>> (1) The text says:
>>
>> "By continuously measuring the
>>     delay of path segments and use them as metrics for path selection,
>>     when the number of overlay nodes is sufficiently large, there is a
>>     high chance that a better path could be found
>>     [DOI_10.1109_ICDCS.2016.49] [DOI_10.1145_3038912.3052560].
>>     [DOI_10.1145_3038912.3052560] further shows all cloud providers
>>    experience random loss episodes and random loss accounts for more
>>     than 35% of total loss."
>>
>> - I think this use case was presented in previuous meetings, and one of the questions was how to react appropiately to route changes and traffic engineering by the physical network operator. This doesn't come across to me in the latest text.
> The document is not explicit about that, but path selection is not something LOOPS would be doing.  The SDN controller that sets up these paths would add LOOPS support to those segments that need it (which is what the last sentence is about: These segments exist!).
See below [GF].
> LOOPS is really just about loss recovery.  Some of the measurements that LOOPS carries out will be useful for the SDN controller to make path selection decisions; we would expect a management interface will make these measurements available to the SDN controller.
>
OK.
>> (2) I will argue there is not a satellite-specific use case really, there is a use case for any reliable long-haul path (large RTT) that is concatenated with another segment with a lossy segment with lower RTT.
> Yes!
> (For a definition of “reliable”.)
OK.
>>   “Enhanced error recovery at the satellite link layer
>>     helps for the loss on the satellite link but doesn't help for the
>>     terrestrial links.  Even when the terrestrial segments are short, any
>>     loss must be recovered across the satellite link delay.”
>> -  I think the argument is really that the end-to-end internet path using a satellite network segment can be long (large RTT), and therefore that loss experienced at any point outside the satellite network segment still suffers performance because of the larger RTT.
>> - If that is the case, then I think a GEO satellite path is an **example** of such a path.
>> is this a “long terrestrial” path? or a long Internet path?
>> - “Faster recovery over such
>>     long terrestrial segments is desirable.”
> A long Internet path (that is still not at the level of RTT a GEO sat gives you.)
>
>> (3) The previous revision mentioned the specific case where the “network is long-haul”, but I think this aspect was removed in the latest rev?. Maybe I don’t fully see - is it expected (or somehow known) that the delay for the LOOPS path segment is much less than the end-to-end path (in Section 1)?
> That is the configuration where you get the most benefit.
And the converse appears also the case where LOOPS has the potential for 
most negative interactions with end-to-end recovery?
>> How does the LOOPS path segment know this?
> It can’t.
That's an issue.
> The aggregate that LOOPS is repairing may be mixed out of quite different end-to-end paths.
See (a).
> LOOPS does not have a way to measure the RTT of those paths (*).  A recommendation for the proper use of LOOPS would be that it is not very useful to run LOOPS on a segment that covers most of the span of the end-to-end path, but LOOPS cannot know that this was done, and it is not going to dramatically break traffic that has such a mix.  If LOOPS does little good, due to its cost (additional reverse packets, processing/memory, tunneling if that wasn’t already in use) it is a pessimization; many optimizations have regions of operation in which they don't.
I would like to understand the potential for harm... to.
>> (4) I see you also mention in the latest rev adds a use case for a "fleet of drones" - I'm not quite sure what this is describing, maybe you could expand how this works, and add some text to the draft.
> I think Med answered that — I don’t think that is a use case the operators interested in this have today :-)
That thread was interesting, but it seemed to create additional issues - 
it might be worth deciding whether that is included in the next rev of 
the document.
> Grüße, Carsten
>
> (*) Well, vendors could add some secret sauce to actually do this, for certain cases.  But it is not the LOOPS protocol that will do that for them, and LOOPS does not depend on it.

:-).

[GF] I'm now trying to understand how the "SDN" controller can know 
which flows in the aggregates support ECN:  At what point can an 
aggregated tunnel egress assume that it is safe to translate a tunnel 
loss into a flow ECN CE-mark?

Example: (Would only established ECN-capable flows added to the 
aggregate? ... Translating loss at the start of a flow into a CE-mark 
has a strange effect when the sender is probing for support, but a 
recipient doesn't report CE-marks?)

Gorry