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

["Black, David" <[e-mail]>]

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.  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:[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