Subject: [6tisch] Deterministic DSCP

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 30 Jan 2014 16:15:04 +0000

Hi,

Does WG see any concern in definition of such DSCP for the purpose of Deterministic forwarding? If there are no concerns, we will put forward this proposal in front of TSVWG.

http://tools.ietf.org/id/draft-svshah-tsvwg-deterministic-forwarding-00.txt

Regards,
Shitanshu

---

From: Qin Wang <[email-masked]>
Date: Fri, 31 Jan 2014 02:35:02 +0800

Hi Shitanshu,

I'm trying to understand DF from 6top sublayer point of view. Here are some
questions.

(1) Should the DF Queue be implemented in 6top sublayer if TSCH is used as
MAC?
(2) In section 3.2, "The enqueued packet MUST also be checked against the
size of the data. ". Does the size here refer to the size of IP packet
payload or the size of MAC frame payload?
(3) For "absolute or relative time interval", can we use Slot as its unit?
For example, forwarding a packet every 100 slots, or forwarding a packet in
10 slots from the timeslot when it arrives.

Thanks
Qin

On Fri, Jan 31, 2014 at 12:15 AM, Shitanshu Shah (svshah)
<[email-masked]>wrote:

>
>  Hi,
>
>  Does WG see any concern in definition of such DSCP for the purpose of
> Deterministic forwarding? If there are no concerns, we will put forward
> this proposal in front of TSVWG.
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 31 Jan 2014 05:40:17 +0000

Hi Qin,

(1)
DF proposal is for a new DSCP code-point to classify traffic requiring a specific behavior (deterministic behavior) and thus such traffic to be en-queued in a  DF queue and follow PHB semantics defined for DF traffic. If 6top sublayer complies with those semantics then yes DF queue may be implemented in 6top sublayer. The Deterministic DSCP proposal does not mandate queuing to be implemented in any one specific way.

I just gone thru 6top proposal, and as it described if it honors priority field from the upper layer (here priority for deterministic traffic is DF) and honors defined semantics of forwarding behavior for such traffic (I assume why would it not)….

(2)
IMO ideally size should refer to frame that matters on transmission media. That is a whole MAC frame. I can update the document to clarify it.
Any reason why you suggest only MAC payload and not whole frame including header.

(3)
I think slot as a unit a valid provisioning parameter. Just that it becomes L2 specific property which may not be applicable to other L2 if it is implementing deterministic scheduling in a different way. Anyhow, that does not preclude "slot" unit from the possible provisioning option.

Thanks
Shitanshu

From: Qin Wang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 30, 2014 10:35 AM
To: Shitanshu Shah <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] Deterministic DSCP

Hi Shitanshu,

I'm trying to understand DF from 6top sublayer point of view. Here are some questions.

(1) Should the DF Queue be implemented in 6top sublayer if TSCH is used as MAC?
(2) In section 3.2, "The enqueued packet MUST also be checked against the size of the data. ". Does the size here refer to the size of IP packet payload or the size of MAC frame payload?
(3) For "absolute or relative time interval", can we use Slot as its unit? For example, forwarding a packet every 100 slots, or forwarding a packet in 10 slots from the timeslot when it arrives.

Thanks
Qin

On Fri, Jan 31, 2014 at 12:15 AM, Shitanshu Shah (svshah) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,
Shitanshu

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Fri, 31 Jan 2014 22:10:39 +0800

Hi Shitanshu,

Thank you for your explanation.

Regarding to (2), I don't have strong opinion on "suggest only MAC
payload". I said it just because in the document you say "The enqueued
packet MUST also be checked against the size of the data."  Then, I think
size of data refers to size of payload instead of size of frame/packet.
sorry!

Thanks
Qin

On Fri, Jan 31, 2014 at 1:40 PM, Shitanshu Shah (svshah)
<[email-masked]>wrote:

>
>  Hi Qin,
>
>  (1)
> DF proposal is for a new DSCP code-point to classify traffic requiring a
> specific behavior (deterministic behavior) and thus such traffic to be
> en-queued in a  DF queue and follow PHB semantics defined for DF
> traffic. If 6top sublayer complies with those semantics then yes DF queue
> may be implemented in 6top sublayer. The Deterministic DSCP proposal does
> not mandate queuing to be implemented in any one specific way.
>
>  I just gone thru 6top proposal, and as it described if it honors
> priority field from the upper layer (here priority for deterministic
> traffic is DF) and honors defined semantics of forwarding behavior for such
> traffic (I assume why would it not)....
>
>  (2)
> IMO ideally size should refer to frame that matters on transmission media.
> That is a whole MAC frame. I can update the document to clarify it.
> I think slot as a unit a valid provisioning parameter. Just that it
> becomes L2 specific property which may not be applicable to other L2 if it
> is implementing deterministic scheduling in a different way. Anyhow, that
> does not preclude "slot" unit from the possible provisioning option.
>
>  Thanks
> Shitanshu
>
>
>   From: Qin Wang <[email-masked]>
> To: Shitanshu Shah <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> (3) For "absolute or relative time interval", can we use Slot as its
> unit? For example, forwarding a packet every 100 slots, or forwarding a
> packet in 10 slots from the timeslot when it arrives.
>
>  Thanks
> Qin
>
>
>
> On Fri, Jan 31, 2014 at 12:15 AM, Shitanshu Shah (svshah) <
> [email-masked]> wrote:
>
>>
>>  Hi,
>>

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Fri, 31 Jan 2014 15:07:15 +0000

Yeah, current version of the text in the draft is not clear to be explicit. I'll update the draft to clarify.

Thanks for review and comments,
Shitanshu

Date: Friday, January 31, 2014 6:10 AM

Hi Shitanshu,

Regarding to (2), I don't have strong opinion on "suggest only MAC payload". I said it just because in the document you say "The enqueued packet MUST also be checked against the size of the data."  Then, I think size of data refers to size of payload instead of size of frame/packet. sorry!

Thanks
Qin

On Fri, Jan 31, 2014 at 1:40 PM, Shitanshu Shah (svshah) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Qin,

(1)

(2)

(3)

Thanks
Shitanshu

Hi Shitanshu,

Thanks
Qin

Hi,

Regards,
Shitanshu