Subject: [tsvwg] Deterministic Forwarding PHB

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Mon, 3 Mar 2014 11:09:04 +0000

In the past discussion on LLN Diffserv recommendation (http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-02), we've shown most of the traffic categories, from different types of LL Networks, sharing similar characteristics of traditional IP networks, except traffic class (certain control signals) requiring deterministic forwarding service.

Though it was thought, at the time, that such deterministic service may be overloaded with the use of EF PHB (as currently described in http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-02 - not yet revised to make use of DF PHB), since then different L2 technologies are working on enhancing their capabilities for deterministic scheduled forwarding service. We think it is not appropriate to overload EF PHB definition. Forwarding service requirement for deterministic service clearly differs from that of EF PHB. More and more use–cases for end to end deterministic service means a need for us to define appropriate PHB to be used.

Thus we propose DF PHB.
http://tools.ietf.org/html/draft-svshah-tsvwg-deterministic-forwarding-01

Thoughts from the wg? Comments/feed-back/suggestions?

Regards,
Shitanshu

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Mar 2014 21:36:47 +1300

Hi,

RFC 2475 provides 15 guidelines for new PHB specs. Can you
check that all of them have been considered in this draft?

One thing that is stated in RFC 2474 is that PHB specs should
be careful to describe behavior, not specify an algorithm. I think
that in a few places you actually start to specify an algorithm.

Whether a router that is handling many competing behaviors can
really respect your requirements (discard the packet if it
would be late) is not quite clear to me, but that is an
implementation issue. I would have thought you would always
have a small delta-T of uncertainty in the implementation.

    Brian

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 6 Mar 2014 22:40:55 +0000

Thanks Brian for your review and comments..

Yes, current status of the draft does not have all of those guidelines
covered including like proposal of a specific value of dscp. Will look
into them along with making description around requirements for PHB more
explicit and clearer. I had a conversation with David and have taken the
feed-back to make later clearer before delving into PHB details.

Regarding implementation examples, I've made it very clear in the draft,
<<<<
"Following are examples of potential implementations.  They are not any
form of guidelines or recommendations but simply a reference to potential
implementations."

I thought of describing potential implementations hoping to give more
details to reader to help them enough to implement their own algorithm but
not necessarily mandate them implement the same.
May be should I move them to later section or an Appendix? What do you
suggest?

Regarding discard action for non-compliant DF packets, I think is a MUST
to support DF PHB implementation. One of the reason, DF service is
required is to deliver packet end to end in timely manner. Loss is okay
but non-scheduled delivery is not ok. And if packet not discarded, it
would end up in non-timely deliver to an eventual receiver either through
packet re-directed through a different queue or potentially causing
consequences to subsequent packets if delivered through same DF queue.

Regards,
Shitanshu

On 3/6/14 8:36 AM, "Brian E Carpenter" <[email-masked]> wrote:

>> In the past discussion on LLN Diffserv recommendation
>>(http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendatio
>>ns-02), we've shown most of the traffic categories, from different types
>>of LL Networks, sharing similar characteristics of traditional IP
>>networks, except traffic class (certain control signals) requiring
>>deterministic forwarding service.
>> 
>> Though it was thought, at the time, that such deterministic service may
>>be overloaded with the use of EF PHB (as currently described in
>>http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendation
>>s-02 - not yet revised to make use of DF PHB), since then different L2
>>technologies are working on enhancing their capabilities for
>>deterministic scheduled forwarding service. We think it is not
>>appropriate to overload EF PHB definition. Forwarding service
>>requirement for deterministic service clearly differs from that of EF
>>PHB. More and more usecases for end to end deterministic service means
>>a need for us to define appropriate PHB to be used.
>> 
>> Thus we propose DF PHB.
>>

---

From: <[email-masked]>
Date: Fri, 7 Mar 2014 10:39:37 +0100

Shitansu,

Brian asks for a better description of the expected DF PHB and I agree with him. From what I read in your draft, I had the impression that you may be asking for synchronized forwarding. 

Did you consider end system mechanisms to deal with the in time delivery, like sender time stamps, play out time stamps and de-jitter buffers? I'm a backbone engineer, no expert on application and end system QoS, so I'll not be able to give you a detailed discussion.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Shitanshu Shah (svshah)
Gesendet: Donnerstag, 6. März 2014 23:41
An: Brian E Carpenter
Cc: Pascal Thubert (pthubert); [email-masked]
Betreff: Re: [tsvwg] Deterministic Forwarding PHB

Yes, current status of the draft does not have all of those guidelines covered including like proposal of a specific value of dscp. Will look into them along with making description around requirements for PHB more explicit and clearer. I had a conversation with David and have taken the feed-back to make later clearer before delving into PHB details.

Regarding implementation examples, I've made it very clear in the draft, <<<< "Following are examples of potential implementations.  They are not any form of guidelines or recommendations but simply a reference to potential implementations."

I thought of describing potential implementations hoping to give more details to reader to help them enough to implement their own algorithm but not necessarily mandate them implement the same.
May be should I move them to later section or an Appendix? What do you suggest?

Regarding discard action for non-compliant DF packets, I think is a MUST to support DF PHB implementation. One of the reason, DF service is required is to deliver packet end to end in timely manner. Loss is okay but non-scheduled delivery is not ok. And if packet not discarded, it would end up in non-timely deliver to an eventual receiver either through packet re-directed through a different queue or potentially causing consequences to subsequent packets if delivered through same DF queue.

Regards,
Shitanshu

On 3/6/14 8:36 AM, "Brian E Carpenter" <[email-masked]> wrote:

>Hi,
>
>RFC 2475 provides 15 guidelines for new PHB specs. Can you check that 
>all of them have been considered in this draft?
>
>One thing that is stated in RFC 2474 is that PHB specs should be 
>careful to describe behavior, not specify an algorithm. I think that in 
>a few places you actually start to specify an algorithm.
>
>Whether a router that is handling many competing behaviors can really 
>respect your requirements (discard the packet if it would be late) is 
>not quite clear to me, but that is an implementation issue. I would 
>have thought you would always have a small delta-T of uncertainty in 
>the implementation.
>
>    Brian
>
>Regards
>   Brian Carpenter
>>(http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommenda
>>tio ns-02), we've shown most of the traffic categories, from different 
>>types of LL Networks, sharing similar characteristics of traditional 
>>IP networks, except traffic class (certain control signals) requiring 
>> Though it was thought, at the time, that such deterministic service 
>>may be overloaded with the use of EF PHB (as currently described in 
>>PHB. More and more usecases for end to end deterministic service 
>>means a need for us to define appropriate PHB to be used.
>> 
>> Thus we propose DF PHB.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 22:47:34 +1300

Hi,

On 07/03/2014 11:40, Shitanshu Shah (svshah) wrote:
> but non-scheduled delivery is not ok. 

I understand that is the requirement. My point is more one of physics.
When a DF packet reaches the final queue for transmission, there is still
an uncertainty about when it will be transmitted. Maybe the interface
is still busy sending the previous (non-DF) packet, maybe there is a
delay for the MAC to be able to start transmitting. So logically the
deadline must have an associated uncertainty of +- some number of
microseconds. Doesn't that uncertainty need to be a parameter of
the PHB?

Also, David Black mentioned something to me yesterday - if the packet
goes through an intermediate L2 switch (or non-DV router), that changes
the behavior as seen by the receiver? Or would the variable switching
delay be part of the uncertainty I just mentioned?

   Brian

> And if packet not discarded, it

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 7 Mar 2014 21:22:14 +0000

Hi Brian,

Underlying L2, where use-cases are around and intended for, are enhancing
their capabilities to deliver packets on a schedule time (slot). Both
802.15.4/802.15.4e and 802.1 (I think 802.1 refers as Time Sensitive
Networking) are actively looking into supporting such capability. And I
would think them to be supporting it to the granularity of very little
delta (hopefully not micro-seconds or at the least very small
micro-seconds). Nonetheless, your point is correct that there is a
possibility of delta of +/- time unit (what-ever that unit can be in a
worst case). However, I think it should not be part of parameter. By
definition packets to be delivered during scheduled time and delta is
worst case variance what underlying L2 is able to provide or on top of
implemented infrastructure is able to make use of it.

Your point though I take is to have some text around it to highlight worst
case variance and what it means to end applications. I wonder for "EF"
code-point, do we have any latency bound parameter for provisioning and
anything stating what worst case latency makes it LLQ (EF behavior). I can
follow something similar here.

To answer second part of your question,
Ideally, for the purpose DF code-point to be used, it is in best interest
to have every nodes in the end to end path support DF code-point (The
use-cases we know today do not traverse over Internet or over domains
operating outside such networks). Though in the cases where use-case is ok
to have non-DF router in between given they can do so by conditioning
schedule of DF traffic at the DF-capable router that receives such packet
from previous non-DF capable router. I've highlighted that in the draft.

Regards,
Shitanshu

On 3/7/14 9:47 AM, "Brian E Carpenter" <[email-masked]> wrote:

>>>>may
>>>>means