Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well?

[Liyizhou <[e-mail]>]

Hi Gorry and Carsten,

Please see inlines with [yz]

-----Original Message-----
From: LOOPS [mailto:[e-mail]] On Behalf Of Gorry Fairhurst
Sent: Wednesday, July 8, 2020 12:46 AM
To: Carsten Bormann <[e-mail]>
Cc: loops <[e-mail]>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - why do traffic engineering at the overlay as well?

Hi Carsten,

OK, so if multipath operation is out of scope for the proposed LOOPS activity, what in scenario 3 of the problem statement remains in scope, relative to figure 2.

[yz] Current text of multi-pathing basically provided why multi-pathing existed in the scenario. Applying in-network recovery to segments of one of the paths is no much difference from the segments of a single path in current text. Consideration of the operations on the fork point of multi-paths would expose additional requirements but it is out of scope for now. So a separate section 3.4 seems not very necessary. Will edit it for next revision.  

While this scenario  is in focus, can you explain section 3.1, this seems a discussion of TLP. Is this an “issue” fixed by RACK or have I missed something?

[yz] Yes, it talks about negative impact of tail loss. TLP in RACK tries to fix it. In my understanding, In-network recovery (LOOPS) can help in the cases of: 1) sender has not used the time based loss detection in TCP, or not a TCP sender. 2) Segment detects the loss and then recover it faster, fire of TLP timer at the sender is reduced when RACK is in use.  

I'm curious why you split RTP, bulk and other transfers apart in this case - to be sure, is this just to explain different merits of the same advocated approach, or is it that you see differentiation within the network based on flow type?

[yz] This tries to show that in-network recovery brings benefits to different types of transported data. Current doc structure seems a bit confusing. Could be interpreted as those merits only applicable to one scenario. Indeed they are common to all scenarios. Will re-structure the section alignment. Thank you.   

Gorry

On 07/07/2020 16:59, Carsten Bormann wrote:
> Hi Gorry,
>
> On 2020-07-07, at 17:28, Gorry Fairhurst <[e-mail]> wrote:
>> I have a few quetsions about then problem draft:
>>
>> Section 3.4 provides a use-case, which I would like to understand better:
>>
>> “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".
> Multipath operation is out of scope for the LOOPS activity that we are presenting at the IETF108 BOF.  Multipath is a valid use case for in-network recovery, but I would expect we would want to combine the considerable knowledge gained with MPTCP and various other multipathing approaches (e.g., MPDCCP) before even defining the outline of a standardizable solution.
>
> (Running LOOPS on a segment that is internally multipathed, or within 
> a single segment contributing to a multipath arrangement, should be 
> considerably simpler.)
>
>> - This seems in part to rely upon measuring and the choosing which “disjoint segments” to forward over. A previous discussion asked how this would operate when the network itself implemented methods such as BGP and ECMP to do some form of traffic engineerinfg, and whether this introduced additional level of automatic re-routing would in some way conflict?
> For LOOPS at IETF108, we are trying to avoid control loops fighting against each other.  For people who enjoy those fights, we can always ask to add it later.
>
>> - Is this decision within the network a good idea for stable oeprations? Is this a decision better made at the edge?
> I’m not sure we know the answer to that.  A vantage point within the 
> network may have better data, both with respect to the speed of reaction (shorter RTTs for a partial path) and with respect to the aggregated traffic volume providing better measurements.  But you said “at the edge”, which is in the network… In any case, getting this right, over a wide range of operating points, would be quite an accomplishment.
>
> Grüße, Carsten

--
LOOPS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/loops