Subject: [Detnet] draft-finn-detnet-bounded-latency: regulator questions

From: Toerless Eckert <[email-masked]>
Date: Wed, 12 Sep 2018 00:39:40 +0200

1. Some of the slides in https://datatracker.ietf.org/meeting/102/materials/slides-102-detnet-5-detnet-bounded-latency-00 really look crappy, probably due to PPTX->PDF conversion issues. Would be great if we could get a fixed PDF. Especially because the slides curently cover more detail AFAIK than the -01 draft (slides 3, 5, 9, 10).

2. I've been trying to figure out from the two papers cited in the slides the requirements for the interleaved regulators in hardware, but have to wing it: The way i understand it: I have 100 flows from input port A to output port B in the same class, so i set up one interleaved regulator. That interleaved regulator still needs to have the parameters of all 100 flows aggregated into it, and whenever it tries to figure out how to delay the first packet in the FIFO, look up the appropriate flow and its parameters. True ? False ?

3. I am curious as to how close to existing HW realities these interleaved regulators are. I guess they are being considered for TSN, but have they been implemented in hardware and is there some comparison in terms of HW complexity over let's say 100 independent shapers ?

4. Is there any mathematical model for asynchronuous deterministic latency, where i do not assume such an ?advanced? interleaved regulator, but just a simple shaper for the aggregate of the flows ? E.g.: I think i can easily hold the per-flow state in the control plane. I then add up the appropriate per-flow parameters to form the aggregate parameters (e.g.: CBR and maximum burst-size), and then simply operate an existing shaper instead of the more complex interleaved regulator. Sure, i can guess that the absolute worst-case delay with this approach might be somewhat higher than with interleaved regulators, but shouldn't this approach be an easier immediately applicable baseline for HW platforms ? That total number of simple shapers today would likely be well inline with #ingres-ports * #traffic-classes (per-output port).

Cheers
    Toerless

---

From: Norman Finn <[email-masked]>
Date: Wed, 12 Sep 2018 06:34:44 +0000

1. The slides got messed up somehow, perhaps when they were collected into a single deck; I don't know.  Better version attached.

2. Right. 

3. I don't know about implementations.  But, the usual one-queue-per-flow+IntServ-shaper does essentially the same job and has been extensively implemented.

4. IntServ works just fine.  The math may be slightly different, because the shaper is characterized with slightly different parameters, but it works.  (Don't ask me to show you the math -- I can't.)  However, if you try to use fewer than one state machine per flow -- e.g. the same number of queues as for interleaved regulators, but only one shaper per queue -- then you get much more complex mathematical problem to solve when making each reservation, much larger latency, and much larger latency variation.

The reason is that the interdependencies between flows are localized to a single node with the interleaved or IntServ scheme, and span multiple nodes when flows share a single shaper.  My usual example: Any time multiple flows share a single shaper, then if all flows except one suddenly stop, the one flow gets all of the shaper's bandwidth and is transmitted in a burst.  If a similar event happens in other nodes along the "lucky" flow's path at the same time, the result is equivalent to that flow having no shapers in any node.

Yes, there are good mathematical models for the shared shaper; it's DiffServ.

-- Norm
________________________________________
From: Toerless Eckert [[email-masked]]
Sent: Tuesday, September 11, 2018 3:39 PM
To: [email-masked]
Cc: [email-masked]
Subject: draft-finn-detnet-bounded-latency: regulator questions

Cheers
    Toerless