Subject: [6tisch] Issue #34 of draft-dujovne-6tisch-on-the-fly

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Sat, 9 May 2015 15:13:39 -0400

All,
     Although we discussed briefly about this issue,
we did not arrive to a conclusion on this topic:

"And I have not found requiring cells with specific link option (i.e., Tx
only or Rx only). Is there any plan to add this feature into OTF? IMHO, I
think it may be useful to take advantage of TSCH that can make contention
free links between nodes. (From Jongsoo Jeong)"

I do agree that with OTF we are working with bandwidth requests for data
traffic,
so dedicated TX or RX links should be preferred. I have not found any
specific restrictions on the link options available for the Best Effort
track which is the
one we are using for dynamic allocation. It is only mentioned on the 6top
sublayer draft as follows:

If the TrackID is set to (0,0), the cell can be used by the best-
   effort QoS configuration or as a Shared cell.  If the TrackID is not
   set to (0,0), i.e., the cell belongs to a specific track, the cell
   MUST not be set as Shared cell.

But it does not say that a best effort track MUST use Shared cells.

We also discussed tracks for OTF in June 2014, but there were no comments
on
dedicated cells:

http://www.ietf.org/mail-archive/web/6tisch/current/msg02335.html

Any thoughts?

Thanks,

                               Diego

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 May 2015 06:52:03 +0200

Diego,

I dont Fully understand what you are proposing, hence some clarifying
questions.

Currently, the OTF algorithm triggers when a node should schedule one cells
TO its neighbor. Since all nodes run the OTF algorithm, the current
node can also receive requests to schedule cells FROM any of its neighbors.

Each cell is associated (this is not OTF specific):
- one or more flags: TX, RX, SHARED
- a neighbor, optional
- a type: hard or soft

What does the draft say now about the qualifiers, and what are you
proposing to change those to?

Thomas

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Sun, 10 May 2015 06:57:28 -0400

Thomas,
            The only unknown here are the attributes supported
by the best-effort track. Since we are using best-effort, and
from the references I have cited, I think it must be specified
on the 6top draft whether dedicated (TX and RX) cells can
be used on the best-effort track. We have also replaced the
track references to bundle references, so it is clear OTF
is a L3 mechanism, so we specify now "best-effort bundle"
instead of "best-effort track".
            AFAIK, we say nothing on the draft about the
cell attributes (shared, TX or RX), and we shall keep saying
nothing, since I think track and bundle attributes are outside
OTF scope.
             Regards,

                                                Diego

2015-05-10 1:52 GMT-03:00 Thomas Watteyne <[email-masked]>:

> Currently, the OTF algorithm triggers when a node should schedule
> one cells TO its neighbor. Since all nodes run the OTF algorithm, the
> current node can also receive requests to schedule cells FROM any of its
> neighbors.
>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 11 May 2015 03:54:25 +0200

Diego,
I agree with you that OTF is orthogonal to the flags, but I also believe we
should be as precise as possible. Let's forget for a second in which draft
what goes and think only about the end result. What flags would you put on
the OTF cells, and would they be dedicated/shared? I have some weak
opinion, but I'd love to hear your pros/cons.
Thomas

On Sunday, May 10, 2015, Prof. Diego Dujovne <[email-masked]>
wrote:

> 2015-05-10 1:52 GMT-03:00 Thomas Watteyne <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
>> Diego,
>>
>> On Saturday, May 9, 2015, Prof. Diego Dujovne <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> All,
>>> "And I have not found requiring cells with specific link option (i.e.,
>>> Tx only or Rx only). Is there any plan to add this feature into OTF? IMHO,
>>> I think it may be useful to take advantage of TSCH that can make contention
>>> one we are using for dynamic allocation. It is only mentioned on the
>>> 6top sublayer draft as follows:
>>>
>>> We also discussed tracks for OTF in June 2014, but there were no
>>> comments on
>>> dedicated cells:
>>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Sun, 10 May 2015 22:31:59 -0400

Thomas,
             From my point of view, regarding the dedicated/shared
discussion,
I vote for dedicated TX and RX.

I think the main goal of OTF is to dynamically manage bandwidth allocation
for data transmission purposes; then it is essential to guarantee that this
bandwidth is available with no contention. If contention is enabled (as in
shared cells), bandwidth access becomes statistic, then neither the
bandwidth
availability nor the delay can be guaranteed.

If OTF can also be used for management or non-priority traffic, that is,
what
I should call, real best-effort traffic, then shared cells can be an
option. As
far as I can remember, we have not considered specifically this type of
traffic
in our draft discussions to date.

So, I see three options:
-narrow the type of traffic to that requiring only dedicated cells,
-keep OTF traffic-agnostic,
-allow the upper layers (an application, for example) to send a
dedicated/shared flag
together with each bandwidth request. I think that a bandwidth request
accounting
service may be required in this case.

Any thoughts?

                                         Diego

2015-05-10 22:54 GMT-03:00 Thomas Watteyne <[email-masked]>:

> Diego,
> I agree with you that OTF is orthogonal to the flags, but I also believe
> we should be as precise as possible. Let's forget for a second in which
> draft what goes and think only about the end result. What flags would you
> put on the OTF cells, and would they be dedicated/shared? I have some weak
>>>> I do agree that with OTF we are working with bandwidth requests for
>>>> data traffic,

---

From: Qin Wang <[email-masked]>
Date: Mon, 11 May 2015 14:10:56 +0000 (UTC)

Hi Diego and Thomas,
Firstly, I want to go through the combination of {Tx, Rx, Shared} and {Hard, Soft}. I think Tx or Rx can go with both Hard and Soft, but Shared can only go with Hard. The reason is Shared cell could be used by more than a pair of nodes, so monitoring function (i.e. self monitoring cell quality and re-allocate accordingly ) of soft cell will not work. Do you agree?
Secondly, regarding to the cell used for best-effort track, I think both dedicated Tx/Rx and Shared cell are fine. But, specially, the cells reserved by OTF for best-effort track should be dedicated Tx/Rx cells. The reason is that OTF basically focuses on a pair of nodes and wants to get some guaranteed bandwidth. Make sense?
ThanksQin

     On Monday, May 11, 2015 10:32 AM, Prof. Diego Dujovne <[email-masked]> wrote:

 Thomas,
             From my point of view, regarding the dedicated/shared discussion,
I vote for dedicated TX and RX. 

shared cells), bandwidth access becomes statistic, then neither the bandwidth 

If OTF can also be used for management or non-priority traffic, that is, what
I should call, real best-effort traffic, then shared cells can be an option. As
far as I can remember, we have not considered specifically this type of traffic 
in our draft discussions to date.

So, I see three options:
-narrow the type of traffic to that requiring only dedicated cells,
-keep OTF traffic-agnostic,
-allow the upper layers (an application, for example) to send a dedicated/shared flag
together with each bandwidth request. I think that a bandwidth request accounting
service may be required in this case. 

Any thoughts?

                                         Diego

Diego,I agree with you that OTF is orthogonal to the flags, but I also believe we should be as precise as possible. Let's forget for a second in which draft what goes and think only about the end result. What flags would you put on the OTF cells, and would they be dedicated/shared? I have some weak opinion, but I'd love to hear your pros/cons.Thomas

On Sunday, May 10, 2015, Prof. Diego Dujovne <[email-masked]> wrote:

Thomas,

                                                Diego

Diego,
I dont Fully understand what you are proposing, hence some clarifying questions.
Currently, the OTF algorithm triggers when a node should schedule one cells TO its neighbor. Since all nodes run the OTF algorithm, the current node can also receive requests to schedule cells FROM any of its neighbors.
Each cell is associated (this is not OTF specific):- one or more flags: TX, RX, SHARED- a neighbor, optional- a type: hard or soft
What does the draft say now about the qualifiers, and what are you proposing to change those to?
Thomas

On Saturday, May 9, 2015, Prof. Diego Dujovne <[email-masked]> wrote:

All,

"And I have not found requiring cells with specific link option (i.e., Tx only or Rx only).Is there any plan to add this feature into OTF?IMHO, I think it may be useful to take advantage of TSCH that can make contention free links between nodes.(From Jongsoo Jeong)"

I do agree that with OTF we are working with bandwidth requests for data traffic,
so dedicated TX or RX links should be preferred. I have not found any specific restrictions on the link options available for the Best Effort track which is the
one we are using for dynamic allocation. It is only mentioned on the 6top sublayer draft as follows:

We also discussed tracks for OTF in June 2014, but there were no comments on 
dedicated cells:

Any thoughts?

Thanks,

                               Diego

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

---

From: Kris Pister <[email-masked]>
Date: Mon, 11 May 2015 10:54:41 -0700

Diego -
  +1 on this paragraph.  I'm not sure what that means for your three 
options.

ksjp