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

[Carsten Bormann <[e-mail]>]

Hi Spencer,

Interesting questions.

> On 2020-07-17, at 14:03, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> I'm thinking about "first, do no harm". 
> 	• If a path has a large number of short flows that respond to CE, that's awesome.

Indeed.  Let’s talk about short + transactional (“chatty”) flows, though.

> 	• If a path has a large number of short flows that don't respond to CE markings, but do respond to drops, the senders should slow down as much as you can slow down an exchange with less than a dozen packers, when they see drops. Is LOOPS making that situation better, or worse?

Until countermeasures such as circuit breakers hit, worse.  Since LOOPS is converting drops to marks, it is converting observed congestion events into ignored congestion events for these flows.

So where do you get those flows that don’t respond to CE markings?  And how did you avoid them breaking other CE-marking places in the Internet already?  I think the argument really boils down to “we can’t have LOOPS adding CE-marking places because CE-marking is bad”, and I’m not sure we have consensus on the latter.

I know about the case where a middle box somwhere on the path outside the LOOPS segment removes ECE markings from TCP headers; this is about the worst case I can think about (but it is already bad without LOOPS).

For short flows, it may be worth to consider what “respond to drops” means.  For a short flow, the drop can be (1) in the establishment phase (where LOOPS cannot help TCP flows), essentially acting as a flow-delayer or flow-preventer (in the presence of racing).  LOOPS is not changing that picture.  Or it can be (2) in the IW10 phase, and there LOOPS is likely to react to a drop by adding a packet or two to the ones that already are flowing.  Doesn’t help with any congestion in the LOOPS-controlled path segment, but doesn’t really hurt that much.

> 	• If a path has a large number of short flows that don't respond to CE markings or drops, I THINK an aggregate circuit breaker would cover that situation. Is LOOPS making that situation better, or worse? 

LOOPS is introducing a circuit breaker where there might not have been one before, so it is making the situation better.

The question of course is how fast does it trip (i.e., what is the damage until it does), and what exactly does it circuit-break.  I would have designed it to just stop expending packets on recovery (i.e., stop LOOPS), but not to stop traffic at all.  That would mean there would be no benefit, but also no lasting damage.

I think in the end we will need to limit any damage from misbehaving endpoints (whether doing that on their own or due to some bad interventions from middle boxes) by limiting the amount of repair that is being done by LOOPS.

Grüße, Carsten