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

Speaking as an individual,

On Mon, Jul 27, 2020 at 10:22 AM 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.
>
> (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.
>

I've probably been using "satellite" as a mental shorthand for "long
haul/large RTT" without meaning to, for years (plus Gorry's mention of
another path segment with shorter RTT and losses). I think that's an
important thing to remember when we're talking about use cases - we need to
focus on the problematic aspects of the path, rather than focusing on why a
specific path has those problems, in order to identify the problems we're
trying to solve.

There are many more kinds of problematic paths than kinds of problems with
paths :-)

Thanks, Gorry, for the comment.

Best,

Spencer

>   “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.”
>
> (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)? How does the LOOPS path segment know this?
>
> (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.
>
> Gorry
>
>
> --
> LOOPS mailing list
> LOOPS@ietf.org
> https://www.ietf.org/mailman/listinfo/loops
>