Subject: [6tsch] attributes of data traffic flow

From: "Qin Wang" <[email-masked]>
Date: Thu, 14 Mar 2013 17:39:22 -0700

Hi all,

In the previous emails, there are several threads related with data
traffic flow or data flow. I think it is important to put them together
and see if there is missing pieces.

Attributes of data flow:

(1) Periodicity (T): a integer, T=0 means bursty,  T>0 means the timeslots
in one cycle.

(2) Bandwidth requirement: number of slots in one cycle if T>0; number of
frames in one burst if T=0.

(3) Jitters sensitivity : if the data flow is periodical (T >0), then it
reflects the deterministic requirement. if the data flow is bursty (T=0),
then it reflects the end-to-end latency requirement of the data flow.

(4)Reliability: e.g. one-hop Data Delivery Rate (PDR)

Anything else?

In addition, I think "priority of data flow" is function of these basic
attributes, maybe more. Make sense?

Qin

---

From: Grieco <[email-masked]>
Date: Fri, 15 Mar 2013 10:27:24 +0100

Hi Qin, and all

Do you think it could be useful to specify the minimum, maximum, average, and standard deviation of the bandwidth requirments for bursty flows ?

In this case, the PCE could have a clear picture of the bounds of the aggregated bandwidth demand of the network, thus improving the effectiveness of the schedule it will build.

What do you think about ?

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

On 15 Mar 2013, at 01:39, "Qin Wang" <[email-masked]> wrote:

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

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 15 Mar 2013 10:11:44 -0700

I agree!

Qin

> Hi Qin, and all
>
> Do you think it could be useful to specify the minimum, maximum, average,
> and standard deviation of the bandwidth requirments for bursty flows ?
>
> In this case, the PCE could have a clear picture of the bounds of the
> aggregated bandwidth demand of the network, thus improving the
> effectiveness of the schedule it will build.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 15 Mar 2013 18:19:15 +0000

Just to give a perspective, 

In frame relay, what a SLA provides for CIR is committed rate (guaranteed), excess rate (discard eligible), and a burst size.

Rates can be used to allocate things similar to cells.  Burst can be mapped into buffers to be reserved for a particular stream. As you see, the CIR expression is designed to be mapped easily by the switch into its operation.

Maybe it would be good to keep things simple for motes as well. Whatever we feed it to, we need to be clear on what 6TUS does of it. Something simple...

Cheers; 

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: vendredi 15 mars 2013 13:12
To: Grieco
Cc: IETF 6TSCH; Qin Wang
Subject: Re: [6tsch] attributes of data traffic flow

I agree!

Qin

> Hi Qin, and all
>
> Do you think it could be useful to specify the minimum, maximum, 
> average, and standard deviation of the bandwidth requirments for bursty flows ?
>
> Department of Electrical and Information Engineering Politecnico di 
> Bari Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
>> traffic flow or data flow. I think it is important to put them 
>> together and see if there is missing pieces.
>>
>> Attributes of data flow:
>>
>> (1) Periodicity (T): a integer, T=0 means bursty,  T>0 means the 
>> timeslots in one cycle.
>>
>> (2) Bandwidth requirement: number of slots in one cycle if T>0; 
>> number of frames in one burst if T=0.
>>
>> (3) Jitters sensitivity : if the data flow is periodical (T >0), then 
>> it reflects the deterministic requirement. if the data flow is bursty 
>> (T=0), then it reflects the end-to-end latency requirement of the 
>> data flow.
>>
>> In addition, I think "priority of data flow" is function of these 
>> basic attributes, maybe more. Make sense?
>>
>> Qin
>>
>>
>>

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 15 Mar 2013 15:46:52 -0700

Pascal,

Thanks for your input.

My motivation to raise the question is for the I-MUX and MUX in the data
convey model of 6tus. Right now, we only define the structure of the
model, but we leave the policy of controlling IMUX and MUX as open issues,
e.g. the rule to configure queues, how to dispatch data flows to queues,
which frame should be selected to feed TSCH.

Back one step, I'm not sure if 6tus should specify those policies or not.

Thought?

Qin

> In frame relay, what a SLA provides for CIR is committed rate
> (guaranteed), excess rate (discard eligible), and a burst size.
>
> Rates can be used to allocate things similar to cells.  Burst can be
> mapped into buffers to be reserved for a particular stream. As you see,
> the CIR expression is designed to be mapped easily by the switch into its
> operation.
>
> Maybe it would be good to keep things simple for motes as well. Whatever
> we feed it to, we need to be clear on what 6TUS does of it. Something
> simple...
>
> Cheers;
>
> Pascal
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 16 Mar 2013 10:58:00 +0000

Hi Qin:

This is really where I'd think Tom would be of the greatest help on your effort.

Since we are defining a layer, we should document the in/outs in terms of service access points and primitives, as well as the observable outcomes of triggering those services. 

The discussion of how things are done inside is of greatest interest between implementers but may not end up in the spec. I'm pushing that discussion because I want to make sure that what we require from the observable standpoint is easy to implement in the inside. Even though it would be neat to provide all sorts of expected statictics on a flow, the 6TUS layer cannot do much of it. 

So when it goes to how we express the track metrics to the 6TUS layer, I'd probably start from what the 6TUS layer can do. That is, allocate cells, add/remove cells dynamically, compute a latency between incoming and outgoing cells, buffer a burst pending forwarding, that sort of thing. From there, we can derive the metrics and constraints that 6TUS can manipulate and exchange that over RSVP or pcep.

When it comes to the PCE, yes, we could describe the flows in more complex and abstract fashion. But it will have to turn that into something that 6TUS can digest, that is the above.

Makes sense?

Pascal

-----Original Message-----
From: Qin Wang [mailto:[email-masked]] 
Sent: vendredi 15 mars 2013 18:47
To: Pascal Thubert (pthubert)
Cc: Qin Wang; Grieco; IETF 6TSCH
Subject: RE: [6tsch] attributes of data traffic flow

Pascal,

Thanks for your input.

My motivation to raise the question is for the I-MUX and MUX in the data convey model of 6tus. Right now, we only define the structure of the model, but we leave the policy of controlling IMUX and MUX as open issues, e.g. the rule to configure queues, how to dispatch data flows to queues, which frame should be selected to feed TSCH.

Thought?

Qin

> mapped into buffers to be reserved for a particular stream. As you 
> see, the CIR expression is designed to be mapped easily by the switch 
> into its operation.
>
> Maybe it would be good to keep things simple for motes as well. 
> Whatever we feed it to, we need to be clear on what 6TUS does of it. 
> Something simple...
>
> Cheers;
>
> Pascal
>
>
>>> (3) Jitters sensitivity : if the data flow is periodical (T >0), 
>>> then it reflects the deterministic requirement. if the data flow is 
>>> bursty (T=0), then it reflects the end-to-end latency requirement of 
>>> the data flow.
>>>