Subject: [6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-on-the-fly-03.txt

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 4 Jul 2014 16:06:23 -0400

A new version of I-D, draft-dujovne-6tisch-on-the-fly-03.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:           draft-dujovne-6tisch-on-the-fly
Revision:       03
Title:          6TiSCH On-the-Fly Scheduling
Document date:  2014-07-04
Group:          Individual Submission
Pages:          13
URL:
http://www.ietf.org/internet-drafts/draft-dujovne-6tisch-on-the-fly-03.txt
Status:
https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/
Htmlized:
http://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-dujovne-6tisch-on-the-fly-03

Abstract:
   This document describes the environment, problem statement, and goals
   of On-The-Fly (OTF) scheduling, a Layer-3 mechanism for 6TiSCH
   networks.  The purpose of OTF is to dynamically adapt the aggregate
   bandwidth, i.e., the number of reserved soft cells between neighbor
   nodes, based on the specific application constraints to be satisfied.
   When using OTF, softcell and bundle reservation is distributed:
   through the 6top interface, neighbor nodes negotiate the cell(s) to
   be (re)allocated/deleted, with no intervention needed of a
   centralized entity.  This document aims at defining a module which
   uses the functionalities provided by the 6top sublayer to (i) extract
   statistics and (ii) determine when to reserve/delete soft cells in
   the schedule.  The exact reservation and deletion algorithm, and the
   number and type of statistics to be used in the algorithm are out of
   scope.  OTF deals only with the number of softcells to be reserved/
   deleted; it is up to 6top to select the specific soft cells within
   the TSCH schedule.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jul 2014 17:19:41 +0000

Hi Diego and all;

Please find some review comments/questions:

1)      The Abstract is too long. I'd keep this first 5 lines, and avoid referring to soft cell

2)      The terminology defines "soft cell", so better avoid "softcell" throughout

3)      “All the softcells allocated are part of best effort track, i.e. with  TrackID=00, as defined i [I-D.wang-6tisch-6top].”. The reference needs to be updated. Also, I’d suggest we discuss the use of the term track. We use trackID 00 to refer to the L3 bundle, and it is probably misleading to call that a track.

4)       “With the soft cell allocation method, OTF has 6top reserve a single  soft cell on the best effort track, for allowing a given node to exchange traffic with a specific neighbor.” There can be tons of neighbors and we might now have the resources to spend a dedicated cell per. Before we know better it makes sense to communicate over shared cells. Also, the RPL based communication will be between parent and children. Parent-child is probably where soft cells / bundles will be allocated. And yes, a pair of bundles (one for in one for out) is allocated for the IPv6 link between parent and child, so I expect that OTF works on the outgoing bundle.

5)      “In detail, OTF includes two distinct allocation methods: soft cell  and bundle allocation methods”; I’m unclear why OTF should work on soft cells as opposed to bundles. Aren’t we making things complicated?

6)      “it may asks 6top to delete a softcell from the best effort track” would thus become something like ‘it requests to 6top to remove a soft cell from the outgoing L3 bundle”

7)      Related question: should OTF be aware of the cell granularity or just capable to ask for more bandwidth (in % or in Kbps) unbeknownst of the cell aspect?

Let’s talk in Toronto!

Typos: interchageably interchangeably ;  implementor implementer ;

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: vendredi 4 juillet 2014 22:06
To: [email-masked]
Subject: [6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-on-the-fly-03.txt

Name:           draft-dujovne-6tisch-on-the-fly
Revision:       03
Title:          6TiSCH On-the-Fly Scheduling
Document date:  2014-07-04
Group:          Individual Submission
Pages:          13
URL:            http://www.ietf.org/internet-drafts/draft-dujovne-6tisch-on-the-fly-03.txt
Status:         https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/
Htmlized:       http://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-dujovne-6tisch-on-the-fly-03

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 9 Jul 2014 08:47:07 +0000

Dear Pascal,
Many thanks for having reviewed the draft.
Please, find inline my comments/answers.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, July 08, 2014 7:20 PM
To: Prof. Diego Dujovne; [email-masked]
Subject: Re: [6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-on-the-fly-03.txt

Hi Diego and all;

1)      The Abstract is too long. I'd keep this first 5 lines, and avoid referring to soft cell +1

2)      The terminology defines "soft cell", so better avoid "softcell" throughout +1

3)      “All the softcells allocated are part of best effort track, i.e. with  TrackID=00, as defined i [I-D.wang-6tisch-6top].”. The reference needs to be updated. +1 Also, I’d suggest we discuss the use of the term track. We use trackID 00 to refer to the L3 bundle, and it is probably misleading to call that a track. I agree we will need to discuss and clarify the meaning of track, L2bundle and L3bundle

4)       “With the soft cell allocation method, OTF has 6top reserve a single  soft cell on the best effort track, for allowing a given node to exchange traffic with a specific neighbor.” There can be tons of neighbors and we might now have the resources to spend a dedicated cell per. Before we know better it makes sense to communicate over shared cells.  Right, I agree. Also, the RPL based communication will be between parent and children. Parent-child is probably where soft cells / bundles will be allocated. And yes, a pair of bundles (one for in one for out) is allocated for the IPv6 link between parent and child, so I expect that OTF works on the outgoing bundle.  Right. Maybe, we will need also to clarify the concept of in and out bundle somewhere, either in the terminology, or in the tsch draft.

5)      “In detail, OTF includes two distinct allocation methods: soft cell  and bundle allocation methods”; I’m unclear why OTF should work on soft cells as opposed to bundles. Aren’t we making things complicated? I had  this in mind too, but due to time constrains (we were too close to the cut-off date for submitting draft) I did not suggest the change. Actually, there is no big or real difference between soft cell and bundle allocation method, knowing that a bundle will be allocated using the same commands used for allocating soft cells. Thus, +1 for keeping things easier, and not talk about two different methods.

6)      “it may asks 6top to delete a softcell from the best effort track” would thus become something like ‘it requests to 6top to remove a soft cell from the outgoing L3 bundle” Right

7)      Related question: should OTF be aware of the cell granularity or just capable to ask for more bandwidth (in % or in Kbps) unbeknownst of the cell aspect? Well, OTF has been designed for dealing only with BW, and thus, it doesn’t know about cell granularity. But, of course, if we found out that it may be useful, then, we may include also this functionality.

Let’s talk in Toronto! Not be able to be there ☹

Typos: interchageably interchangeably ;  implementor implementer ; Thanks.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: vendredi 4 juillet 2014 22:06
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-on-the-fly-03.txt

Abstract:

The IETF Secretariat