Subject: Re: [tsvwg] Deterministic Forwarding PHB

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

Hi Ruediger,

De-jittering buffers would be possible by end-point only if packets
arrived in time to allow to do so. If not managed in intermediate nodes,
there will not be any guarantee of making packet in time. Thus making in
time and de-jittering both are important.

This is what we had wondered before, can we overload EF and use of them in
intermediate node to assume that packets will always arrive in time at the
destination and then receiver to de-jitter. We feel doing so is not
reasonable and feel un-comfortable as well to assume that EF will always
do superior in terms of delivery to destination in time.

Regards,
Shitanshu

On 3/7/14 9:39 AM, "[email-masked]" <[email-masked]>
wrote:

>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
>
>
>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:
>
>>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
>>
>>
>>
>>
>>On 04/03/2014 00:09, Shitanshu Shah (svshah) wrote:
>>> In the past discussion on LLN Diffserv recommendation
>>>(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
>>>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-recommendat
>>>ion
>>>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.
>>> 
>>>http://tools.ietf.org/html/draft-svshah-tsvwg-deterministic-forwarding
>>>-01
>>> 
>>> Thoughts from the wg? Comments/feed-back/suggestions?
>>> 
>>> Regards,
>>> Shitanshu
>>> 
>>
>