Subject: Re: [tsvwg] I-D Action: draft-svshah-tsvwg-lln-diffserv-recommendations-04.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Feb 2015 15:10:56 +1300

> 
> 4.2.1. Deterministic Control Signals
> 
> 
>    PHB for this class of traffic is defined as forwarding of a packet at
>    determined/scheduled time providing no jitter service.
> 
>    Recommended DSCP code-point for this class of traffic is EF.  Since
>    this class of traffic is not expected to co-exist with voice like
>    traffic, that implements EF code-point as used in traditional Campus
>    and WAN networks, the same code-point is re-used here for the purpose
>    of deterministic control signals.  However, a note to be made for
>    defined PHB for this code-point as deterministic forwarding behavior
>    as defined in this document.
> 
>    Scheduling MUST pre-empt service of any other class of traffic during
>    the scheduled time for this class of traffic.

I am confused. This seems to have nothing to do with EF; in fact
it violates the definition of EF, which certainly does not allow
for absolute pre-emption (or "no jitter", which is physically impossible).

It seems closer to CS7 than anything else. But if you are asking for
absolute preemption, it's a new PHB that is not defined anywhere
today. (Dropping the reference to draft-svshah-tsvwg-deterministic-forwarding
makes no difference: in practice the current draft defines a new PHB.)

Any new PHB could in principle be mapped to any DSCP value, such as
the recommended values for EF or CS7, but that doesn't mean it
can be named EF or CS7, because they already have precise meanings.

   Brian

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Feb 2015 15:16:11 +0000

Brian,

> for absolute pre-emption (or "no jitter", which is physically impossible).

In private discussion w/Shitanshu, it looks like the better path forward
is to define a new PHB.  It is possible to implement the described
behavior with no jitter, but at the cost of additional latency (i.e.,
there is in fact "no free lunch").

The basic idea is fixed transmission slots (e.g., for a 1 sec transmission
cycle, there's a reserved slot 100ms after the start of each cycle).  The
downside is that if a packet arrives early, it waits for its transmission
slot (which is also not EF-like, and another reason for a new PHB).

Note that this is intended for low-bandwidth control traffic; if one
overruns what is provisioned for deterministic forwarding, the expected
result is that the excess is dropped.  The alternative of queuing until
the next transmission slot comes around is not good for the control
traffic involved/

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Sunday, February 15, 2015 9:11 PM
> To: [email-masked]
> Subject: Re: [tsvwg] I-D Action: draft-svshah-tsvwg-lln-diffserv-
> recommendations-04.txt
> 
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Feb 2015 08:27:49 +1300

Hi David,
On 17/02/2015 04:16, Black, David wrote:
> is to define a new PHB.  

Yes.

> It is possible to implement the described
> behavior with no jitter,

Well, no, quantum theory if nothing else tells you that there will
always be jitter. You can aim for jitter below some finite limit
(half a bit period comes to mind) but that's all.

> but at the cost of additional latency (i.e.,

Indeed. I always say "You can't beat queueing theory."

> slot (which is also not EF-like, and another reason for a new PHB).

Yes, that's how deadline schedulers have worked in real-time control systems
for many years. (I used to work in real-time controls.)

> the next transmission slot comes around is not good for the control

Sure.

   Brian