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

[Gorry Fairhurst <[e-mail]>]

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.

  “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