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

[Brian E Carpenter <[e-mail]>]

Hi David,
On 17/02/2015 04:16, Black, David wrote:
> Brian,
> 
>> 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).
> 
> In private discussion w/Shitanshu, it looks like the better path forward
> 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.,
> there is in fact "no free lunch").

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

> 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).

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

> 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/

Sure.

   Brian

> 
> Thanks,
> --David
> 
> 
>> -----Original Message-----
>> From: tsvwg [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: Sunday, February 15, 2015 9:11 PM
>> To: [e-mail]
>> Subject: Re: [tsvwg] I-D Action: draft-svshah-tsvwg-lln-diffserv-
>> recommendations-04.txt
>>
>>>
>>> 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
>