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

[Gorry Fairhurst <[e-mail]>]

See below.

> On 30 Jul 2020, at 16:33, Carsten Bormann <[e-mail]> wrote:
> 
> 
>> 
>>> 
>>>> (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).
> 
> I’m lost.  Where is (a)?

Ah sorry my mistake, I truncates my message to focus on talking about the scope.

>>> 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.
> 
> Pessimization is “harm”.  Not really a lot of harm.
> 
On the contrary. Pessimism is important in protecting infrastructure. Please supply data and discuss operational practice.

>>>> (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?
> 
> In the MVP, the tunnel ingress can only provide recovery to ECT-marked packets.
> Any non-ECT traffic needs to be handled without LOOPS support (until we go beyond the MVP, which in the current proposal requires rechartering).
> 
>> 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?)
> 
> The tunnel that implements LOOPS segment might also move non-ECT traffic, but LOOPS cannot help that in the MVP.  The SDN controller could be better off to configure the tunnel ends to direct ECT traffic to the LOOPS segment, not so much non-ECT traffic (unless the tunneling needs to happen anyway).
> 
> Grüße, Carsten

I’ve appreciated the discussion, and I wish this was more clear in the drafts. 

To me, the scope and intention expressing in  the problem statement is itself problematic to understanding the proposed work, and the impact of this service.

GOrry