From twatteyne@gmail.com Tue Oct 1 11:23:38 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4211E81FA for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cteoquKU1IC3 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:23:22 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD6311E81E2 for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:23:09 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kp14so7796125pab.6 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=QtETQzYUh/guwe0k+k2xQnKEJ83Mpl8qKTUoNYuejJg=; b=aBaf8YqtQ1DRSyEzgq1srIgM7VEhj0c2p4g1r4hjM+xOkxGfByZ4IJ1ZcjvU6wahb+ TJuF2tWAi6rWGrINPyxSUonJ9bitfXQN8nK0/mySzNdfusIGJPXwCD5PCxSqCt4YI+Nk gS7vWgkSE3GJa+fX/jf2P+hdECqe2zCoInn9+A67z8Del4K7EaS3sOitweIkCEiTKCDq jlCvjc+TalCGQB5bSTECSYLmwSZuOXrcZ+gei6iBUtH+n+UQ3Cvt5yxyep6hRzmo55tY H0XGXnruu8+yclo0qop7+ByUctjHkIQdVb6FtjXzSXWwf8spvwEozm2jhnosHmG3dv/A I9OA== X-Received: by 10.67.4.227 with SMTP id ch3mr35873428pad.74.1380651788728; Tue, 01 Oct 2013 11:23:08 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:22:48 -0700 (PDT) From: Thomas Watteyne Date: Tue, 1 Oct 2013 11:22:48 -0700 X-Google-Sender-Auth: hi30PNRMp-icxPOzZjQubVT7ptk Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b16018d6d030604e7b20b33 Subject: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:23:38 -0000 --047d7b16018d6d030604e7b20b33 Content-Type: text/plain; charset=ISO-8859-1 All, You will find the minutes of the discussion about the models draft from this morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes *(using Etherpad)* 1. Thomas Watteyne 2. Raghuram Sudhaakar Present *(alphabetically)* 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda - Present pre-draft ToC *[Raghuram/Pouria]* - Discuss ToC - Define contents of each section Minutes - *[08.05]* meeting starts. - *Raghuram* shares pre-draft through Webex - goals for today: define ToC, define contents of each section, pick title - Scope is to include data and interaction model for CoAP. At a later stage, extract information model as separate draft. - "6TiSCH data model" or "6TiSCH CoAP data model"? - *[Thomas]* personal opinion: have CoAP in title - *[Qin]* why interaction model on top of information model? - *[Raghuram]* we want to define message flows between PCE and nodes. Data model is exact definition of payload. We had rough consensus on using name-value pairs. Interaction model for CoAP or RSVP in future drafts. Interaction model provides abstract model of interaction between entities. - *[Qin]* RFC3444, interaction flows should be part of the data model? We should not conflict with RFC3444. - *[Thomas]* We may want to split the interaction from this (data model) draft. - *[Qin]* Data definition and coding is common part. For me, experience with different definitions. Don't want another terminology. - *[Dan]* Not extremely familiar with 6TiSCH but experience with data and information model. In the IETF, we have clear definitions about data and information model. RFC3444 accepted and used as reference. There are differences, i.e. interaction model. We need to stick with RFC3444 as close as possible. - *[Raghuram]* Goal of interaction model is try to extract information model at a later stage. CoAP is one of the transports we are using today, but we can use other protocol at a later stage. We can name it differently later "interaction method". - *[Dan]* If we are inventing a new name, it does not matter too much. We are looking at mapping different transports. - *[Raghuram]* Goal of interaction model is to extract the information model. - *[Raghuram]* Change to ToC: remove interaction? - *[Thomas]* Could be replaced by example scenarios. - *[Pascal]* We have identified interaction at L2, L3 and L5. We need to have discussion about the models. - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example interactions". Message formats would be moved up to 3.3, name-value pairs proposed. - *[Thomas]* Rough consensus? - *[Qin]* what's the different between management and informational resources? - *[Raghuram]* management resources are R/W, informational resources are R (e.g. DAGrank). - *[Thomas]* We could walk through ToC? - *[Raghuram]* - 3.1 naming convention for URI schemes. For example, root resource "6t". Includes naming convention for resources under root resource. - 3.2 resource of 6top we want to expose, i.e. management and informational resource. - 3.2.4 user installed resources, e.g. subscribe for particular implementation. - *[Raghuram]* Should we have extensible resources? - *[Thomas]* Yes. - *[Qin]* What the functional description of a resource? Related to not only management but also informational resources. Should we put every description attached to every resource? Looking at the content, I can imagine a resource list, with a description for each one. Suggestion is to put description just following the resource list. - *[Raghuram]* Fine with that. - *[Pouria]* Other change "functional description of resources" will fold into 3.2.1 and 3.2.2. - *[Raghuram]* Resource is just the URI, linked to particular 6top variable. Methods would fall under description of resource. - *[Qin]* Description of the MIB? - *[Raghuram]* End-user should be able to get a specific parameters. Returned as name-value pairs. If an entity wants the entire MIB, we will have a separate resource. - *[Thomas]* Mapping of 6top commands included? - *[Raghuram]* Yes. Mapping of table of 6top commands presented in previous calls. - *[Pouria]* In resource management, information that can be written by PCE, or commands to be executed. - *[Raghuram]* Everything that change the TSCH schedule falls under the management resource. - *[Raghuram]* Section 4 will be moved up. A message format will be attached to each URI. - *[Thomas]* Map the attributes from minimal draft and the commands from 6top draft. - *[Raghuram]* That is the plan. - *[Thomas]* What are extensions? - *[Raghuram]* We don't want to define the URI for every attribute, we want to enable people to install a new resource with a definition. - *[Raghuram]* In that context, what are profiles? - *[Thomas]* Profile is overarching modification to basic behavior: e.g. adding resources or adding method to existing resource. - *[Qin]* Understanding about profile: resource is fixed, behavior of resource can be configurable. - *[Pascal]* +1 it's very important we are able to do add to basic behavior. - *[Diego]* How can we describe a trigger, e.g. number of measurements to average over. - *[Thomas]* Do we have a solution? - *[Raghuram]* Yes, complex triggers are defined using well-known formats. RFC already defines how to encode several thresholds. Output would be sent on CoAP response or observe notification. One generic method for any kind of trigger. - *[Raghuram]* In profiles, modify or add behavior. Add is easy. Profiles as a way to define extra sets of complex triggers. Discovery. What we could express as profiles are extra complex triggers. - *[Thomas]* What are the next steps? - *[Raghuram]* Updated version of draft by next week to discuss progress. Invite contributors. - *[Thomas]* Name of draft? - *[Raghuram]* What about "6TiSCH CoAP data model". - *[Thomas]* We need to know editor to create repository. - *[Raghuram]* AOB? No other business raised. - *[09.05]* meeting ends. --047d7b16018d6d030604e7b20b33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

You will find the minutes of the d= iscussion about the models draft from this morning at=A0https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft= =A0(also copy-pasted below).

Thomas

---

Minutes Webex 1 October 2013, 6TiSCH group, models draft team

Note: timestamps in PDT.

Taking notes=A0(using Etherpad)

  1. Thomas Watte= yne
  2. Ragh= uram Sudhaakar

Present=A0(alphabetically)

  1. Alaeddine We= slati
  2. Da= n Romascanu
  3. Diego Dujovne
  4. Pascal Thubert
  5. Pouria Zand
  6. Qin Wang
  7. R. Nabati
  8. Raghuram Sudhaakar
  9. Thomas Watteyne

Agenda

  • Present pre-draft ToC=A0[R= aghuram/Pouria]
  • Discuss ToC
  • Define contents of each section

Minutes

  • [08.05]=A0meeting starts.
  • Raghuram=A0shares pre-draft thr= ough Webex
    • goals for today: define ToC, define contents of each section, pick title
    • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
    • "6TiSCH= data model" or "6TiSCH CoAP data model"?
  • [Thomas]= =A0personal opinion: have CoAP in title
  • [Qin= ]=A0why interaction model on top of information model?
  • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
  • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
  • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
  • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
  • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
  • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
  • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
  • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
  • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
  • [Tho= mas]=A0Could be replaced by example scenarios.
  • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
  • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
  • [Tho= mas]=A0Rough consensus?
  • [Qin]=A0what's the different = between management and informational resources?
  • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
  • [Thomas]=A0We could walk through ToC?
  • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
  • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
    • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
  • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
=
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.

    • --047d7b16018d6d030604e7b20b33-- From xvilajosana@berkeley.edu Tue Oct 1 11:42:51 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E5221E8203 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y83RIZENKfh for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:42:47 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDE11E821E for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:42:45 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so7843733pab.13 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:42:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mBjHBaDdnRy5qcUKmGx252KoKQvrYEYfr9iCY6riaYw=; b=HfUkxOtqnYFLvGetW36q2sz44FT7oqrKA/wUfrmNd4iWABuWND73dTcXsbBM4/xJzI REB5ZlIJsWKa0FcxFnFho+MmD9OI5reqdoRIfRXHJCNn+iWBBzcnP4eaPrxRBl/ZfeBt rUbpDWGjALH/QGF0ropECCyO8iRoCJ4DXVIihSw16noL5BlrjWWTnKIpjwre1uEDE9kI YQpISS6ZxGeEU3wOMgMTXXcX1J8LPILGTkxi++cr4F97OmCAOCHhcOCuYo62ouRxQ6Xi DdJ/JNAkh30yz7MdAHoyxWRFwgj7QtuokFfXARRglTcigS3pfH1Qv1gBgFCO7oTtbhL4 E3NQ== X-Gm-Message-State: ALoCoQlr5R5/DJDvi3IW5QzzyhQBs9PO3Ung6s1AcjKTUPFl+yR/Ys5lF/awrUgZU+tQ+PwuOA83 MIME-Version: 1.0 X-Received: by 10.66.249.231 with SMTP id yx7mr35563181pac.116.1380652964745; Tue, 01 Oct 2013 11:42:44 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 11:42:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Oct 2013 11:42:44 -0700 Message-ID: From: Xavier Vilajosana Guillen To: Thomas Watteyne Content-Type: multipart/alternative; boundary=047d7b15a1cb85a30904e7b25126 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:42:51 -0000 --047d7b15a1cb85a30904e7b25126 Content-Type: text/plain; charset=ISO-8859-1 HI all, I have a question raising from the minutes (sorry I could not connect today). If title of the draft is "6TiSCH CoAP data Model" this means that in the future we will have "6TiSCH *foo *data Model". Is that the direction we want? Data Model is the way to represent message content (i.e what goes in the payload and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discussed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne wrote: > All, > > You will find the minutes of the discussion about the models draft from > this morning at > https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also > copy-pasted below). > > Thomas > > --- > > Minutes Webex 1 October 2013, 6TiSCH group, models draft team > > Note: timestamps in PDT. > Taking notes *(using Etherpad)* > > 1. Thomas Watteyne > 2. Raghuram Sudhaakar > > Present *(alphabetically)* > > 1. Alaeddine Weslati > 2. Dan Romascanu > 3. Diego Dujovne > 4. Pascal Thubert > 5. Pouria Zand > 6. Qin Wang > 7. R. Nabati > 8. Raghuram Sudhaakar > 9. Thomas Watteyne > > Agenda > > - Present pre-draft ToC *[Raghuram/Pouria]* > - Discuss ToC > - Define contents of each section > > Minutes > > - *[08.05]* meeting starts. > - *Raghuram* shares pre-draft through Webex > - goals for today: define ToC, define contents of each section, > pick title > - Scope is to include data and interaction model for CoAP. At a > later stage, extract information model as separate draft. > - "6TiSCH data model" or "6TiSCH CoAP data model"? > - *[Thomas]* personal opinion: have CoAP in title > - *[Qin]* why interaction model on top of information model? > - *[Raghuram]* we want to define message flows between PCE and nodes. > Data model is exact definition of payload. We had rough consensus on using > name-value pairs. Interaction model for CoAP or RSVP in future drafts. > Interaction model provides abstract model of interaction between entities. > - *[Qin]* RFC3444, interaction flows should be part of the data model? > We should not conflict with RFC3444. > - *[Thomas]* We may want to split the interaction from this (data > model) draft. > - *[Qin]* Data definition and coding is common part. For me, > experience with different definitions. Don't want another terminology. > - *[Dan]* Not extremely familiar with 6TiSCH but experience with data > and information model. In the IETF, we have clear definitions about data > and information model. RFC3444 accepted and used as reference. There are > differences, i.e. interaction model. We need to stick with RFC3444 as close > as possible. > - *[Raghuram]* Goal of interaction model is try to extract information > model at a later stage. CoAP is one of the transports we are using today, > but we can use other protocol at a later stage. We can name it differently > later "interaction method". > - *[Dan]* If we are inventing a new name, it does not matter too much. > We are looking at mapping different transports. > - *[Raghuram]* Goal of interaction model is to extract the information > model. > - *[Raghuram]* Change to ToC: remove interaction? > - *[Thomas]* Could be replaced by example scenarios. > - *[Pascal]* We have identified interaction at L2, L3 and L5. We need > to have discussion about the models. > - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example > interactions". Message formats would be moved up to 3.3, name-value pairs > proposed. > - *[Thomas]* Rough consensus? > - *[Qin]* what's the different between management and informational > resources? > - *[Raghuram]* management resources are R/W, informational resources > are R (e.g. DAGrank). > - *[Thomas]* We could walk through ToC? > - *[Raghuram]* > - 3.1 naming convention for URI schemes. For example, root resource > "6t". Includes naming convention for resources under root resource. > - 3.2 resource of 6top we want to expose, i.e. management and > informational resource. > - 3.2.4 user installed resources, e.g. subscribe for particular > implementation. > - *[Raghuram]* Should we have extensible resources? > - *[Thomas]* Yes. > - *[Qin]* What the functional description of a resource? Related to > not only management but also informational resources. Should we put every > description attached to every resource? Looking at the content, I can > imagine a resource list, with a description for each one. Suggestion is to > put description just following the resource list. > - *[Raghuram]* Fine with that. > - *[Pouria]* Other change "functional description of resources" will > fold into 3.2.1 and 3.2.2. > - *[Raghuram]* Resource is just the URI, linked to particular 6top > variable. Methods would fall under description of resource. > - *[Qin]* Description of the MIB? > - *[Raghuram]* End-user should be able to get a specific parameters. > Returned as name-value pairs. If an entity wants the entire MIB, we will > have a separate resource. > - *[Thomas]* Mapping of 6top commands included? > - *[Raghuram]* Yes. Mapping of table of 6top commands presented in > previous calls. > - *[Pouria]* In resource management, information that can be written > by PCE, or commands to be executed. > - *[Raghuram]* Everything that change the TSCH schedule falls under > the management resource. > - *[Raghuram]* Section 4 will be moved up. A message format will be > attached to each URI. > - *[Thomas]* Map the attributes from minimal draft and the commands > from 6top draft. > - *[Raghuram]* That is the plan. > - *[Thomas]* What are extensions? > - *[Raghuram]* We don't want to define the URI for every attribute, we > want to enable people to install a new resource with a definition. > - *[Raghuram]* In that context, what are profiles? > - *[Thomas]* Profile is overarching modification to basic behavior: > e.g. adding resources or adding method to existing resource. > - *[Qin]* Understanding about profile: resource is fixed, behavior of > resource can be configurable. > - *[Pascal]* +1 it's very important we are able to do add to basic > behavior. > - *[Diego]* How can we describe a trigger, e.g. number of measurements > to average over. > - *[Thomas]* Do we have a solution? > - *[Raghuram]* Yes, complex triggers are defined using well-known > formats. RFC already defines how to encode several thresholds. Output would > be sent on CoAP response or observe notification. One generic method for > any kind of trigger. > - *[Raghuram]* In profiles, modify or add behavior. Add is easy. > Profiles as a way to define extra sets of complex triggers. Discovery. What > we could express as profiles are extra complex triggers. > - *[Thomas]* What are the next steps? > - *[Raghuram]* Updated version of draft by next week to discuss > progress. Invite contributors. > - *[Thomas]* Name of draft? > - *[Raghuram]* What about "6TiSCH CoAP data model". > - *[Thomas]* We need to know editor to create repository. > - *[Raghuram]* AOB? > > No other business raised. > > - *[09.05]* meeting ends. > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7b15a1cb85a30904e7b25126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    HI all,

    I have a question raising f= rom the minutes (sorry I could not connect today).

    If tit= le of the draft is "6TiSCH CoAP data Model" this means that in th= e future we will have "6TiSCH foo data Model". Is that the= direction we want? Data Model is the way to represent message content (i.e= what goes in the payload and is used by 6top commands). Why is this specif= ic to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <<= a href=3D"mailto:watteyne@eecs.berkeley.edu" target=3D"_blank">watteyne@eec= s.berkeley.edu> wrote:
    All,

    You= will find the minutes of the discussion about the models draft from this m= orning at=A0https://bitbucket.org/6tsch/meetings/wik= i/131001_webex_models_draft=A0(also copy-pasted below).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --047d7b15a1cb85a30904e7b25126-- From twatteyne@gmail.com Tue Oct 1 11:51:30 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2295611E8227 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JUYpF3f2tX8 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:51:27 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DB0FE11E8222 for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:51:26 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id q10so7663674pdj.34 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JoQiMwgUQYrMrtRl1OusmDVDokzKCnLI8Ftv4Byrfy8=; b=D1xPshbH12ry0Swe1Tf4tzONd5VOiur7UQu70uolui+/sXvmL1e64GUGjNNMl8hMJd gudTfpZhoRkxf4w5Pu8WdWMANE07HJvhrH//PSKCOe1fDpfJhCDIsxbed5biP22oWoIk sDU9fsgbbDL+vaLNYWaRLwjYu3Rm11C1DO+kwPU/w4Ec8v9lCDqxAPpv/KCskPju/7ix oqpG7hMNNJPihSe0+hie+NkZ1uxSYNY48i9pba3eQ4QyGeVlpU7j6M5quXMDIj7p2XNz pqszPBTsoJ/SzfXJzYhupaRbZORBh0sh3Yq1gCpb9CoDjdQioBN6Ni4fiCgFTTbcUBO5 lX0A== X-Received: by 10.68.76.65 with SMTP id i1mr31172287pbw.37.1380653486510; Tue, 01 Oct 2013 11:51:26 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:51:06 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 1 Oct 2013 11:51:06 -0700 X-Google-Sender-Auth: Pz2rfnKqV5rYQqwOaB7WlHPKdpI Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=e89a8f923c649f1ad304e7b270b8 Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:51:30 -0000 --e89a8f923c649f1ad304e7b270b8 Content-Type: text/plain; charset=ISO-8859-1 Xavi, Quick reply: - the term CoAP is in the title to follow RFC3444. - we decided to put some examples in this draft about different ways of using this data model (e.g. a node GETting the state of some other node in the network). We had some discussion about the difference between information and interaction models; we decided to have those as a different document to not loose any of the "generic" nature of this data model. Thomas On Tue, Oct 1, 2013 at 11:42 AM, Xavier Vilajosana Guillen < xvilajosana@eecs.berkeley.edu> wrote: > HI all, > > I have a question raising from the minutes (sorry I could not connect > today). > > If title of the draft is "6TiSCH CoAP data Model" this means that in the > future we will have "6TiSCH *foo *data Model". Is that the direction we > want? Data Model is the way to represent message content (i.e what goes in > the payload and is used by 6top commands). Why is this specific to CoAP? > > Another aspect is interaction models, i.e message flows which in that case > they are related to the capabilities of the transport mechanism. > > just thoughts.. Sorry if I really go back to something you already > discussed and it is really clear. > > X > > > > > On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > >> All, >> >> You will find the minutes of the discussion about the models draft from >> this morning at >> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >> copy-pasted below). >> >> Thomas >> >> --- >> >> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >> >> Note: timestamps in PDT. >> Taking notes *(using Etherpad)* >> >> 1. Thomas Watteyne >> 2. Raghuram Sudhaakar >> >> Present *(alphabetically)* >> >> 1. Alaeddine Weslati >> 2. Dan Romascanu >> 3. Diego Dujovne >> 4. Pascal Thubert >> 5. Pouria Zand >> 6. Qin Wang >> 7. R. Nabati >> 8. Raghuram Sudhaakar >> 9. Thomas Watteyne >> >> Agenda >> >> - Present pre-draft ToC *[Raghuram/Pouria]* >> - Discuss ToC >> - Define contents of each section >> >> Minutes >> >> - *[08.05]* meeting starts. >> - *Raghuram* shares pre-draft through Webex >> - goals for today: define ToC, define contents of each section, >> pick title >> - Scope is to include data and interaction model for CoAP. At a >> later stage, extract information model as separate draft. >> - "6TiSCH data model" or "6TiSCH CoAP data model"? >> - *[Thomas]* personal opinion: have CoAP in title >> - *[Qin]* why interaction model on top of information model? >> - *[Raghuram]* we want to define message flows between PCE and nodes. >> Data model is exact definition of payload. We had rough consensus on using >> name-value pairs. Interaction model for CoAP or RSVP in future drafts. >> Interaction model provides abstract model of interaction between entities. >> - *[Qin]* RFC3444, interaction flows should be part of the data >> model? We should not conflict with RFC3444. >> - *[Thomas]* We may want to split the interaction from this (data >> model) draft. >> - *[Qin]* Data definition and coding is common part. For me, >> experience with different definitions. Don't want another terminology. >> - *[Dan]* Not extremely familiar with 6TiSCH but experience with data >> and information model. In the IETF, we have clear definitions about data >> and information model. RFC3444 accepted and used as reference. There are >> differences, i.e. interaction model. We need to stick with RFC3444 as close >> as possible. >> - *[Raghuram]* Goal of interaction model is try to extract >> information model at a later stage. CoAP is one of the transports we are >> using today, but we can use other protocol at a later stage. We can name it >> differently later "interaction method". >> - *[Dan]* If we are inventing a new name, it does not matter too >> much. We are looking at mapping different transports. >> - *[Raghuram]* Goal of interaction model is to extract the >> information model. >> - *[Raghuram]* Change to ToC: remove interaction? >> - *[Thomas]* Could be replaced by example scenarios. >> - *[Pascal]* We have identified interaction at L2, L3 and L5. We need >> to have discussion about the models. >> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >> interactions". Message formats would be moved up to 3.3, name-value pairs >> proposed. >> - *[Thomas]* Rough consensus? >> - *[Qin]* what's the different between management and informational >> resources? >> - *[Raghuram]* management resources are R/W, informational resources >> are R (e.g. DAGrank). >> - *[Thomas]* We could walk through ToC? >> - *[Raghuram]* >> - 3.1 naming convention for URI schemes. For example, root >> resource "6t". Includes naming convention for resources under root resource. >> - 3.2 resource of 6top we want to expose, i.e. management and >> informational resource. >> - 3.2.4 user installed resources, e.g. subscribe for particular >> implementation. >> - *[Raghuram]* Should we have extensible resources? >> - *[Thomas]* Yes. >> - *[Qin]* What the functional description of a resource? Related to >> not only management but also informational resources. Should we put every >> description attached to every resource? Looking at the content, I can >> imagine a resource list, with a description for each one. Suggestion is to >> put description just following the resource list. >> - *[Raghuram]* Fine with that. >> - *[Pouria]* Other change "functional description of resources" will >> fold into 3.2.1 and 3.2.2. >> - *[Raghuram]* Resource is just the URI, linked to particular 6top >> variable. Methods would fall under description of resource. >> - *[Qin]* Description of the MIB? >> - *[Raghuram]* End-user should be able to get a specific parameters. >> Returned as name-value pairs. If an entity wants the entire MIB, we will >> have a separate resource. >> - *[Thomas]* Mapping of 6top commands included? >> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >> previous calls. >> - *[Pouria]* In resource management, information that can be written >> by PCE, or commands to be executed. >> - *[Raghuram]* Everything that change the TSCH schedule falls under >> the management resource. >> - *[Raghuram]* Section 4 will be moved up. A message format will be >> attached to each URI. >> - *[Thomas]* Map the attributes from minimal draft and the commands >> from 6top draft. >> - *[Raghuram]* That is the plan. >> - *[Thomas]* What are extensions? >> - *[Raghuram]* We don't want to define the URI for every attribute, >> we want to enable people to install a new resource with a definition. >> - *[Raghuram]* In that context, what are profiles? >> - *[Thomas]* Profile is overarching modification to basic behavior: >> e.g. adding resources or adding method to existing resource. >> - *[Qin]* Understanding about profile: resource is fixed, behavior of >> resource can be configurable. >> - *[Pascal]* +1 it's very important we are able to do add to basic >> behavior. >> - *[Diego]* How can we describe a trigger, e.g. number of >> measurements to average over. >> - *[Thomas]* Do we have a solution? >> - *[Raghuram]* Yes, complex triggers are defined using well-known >> formats. RFC already defines how to encode several thresholds. Output would >> be sent on CoAP response or observe notification. One generic method for >> any kind of trigger. >> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >> Profiles as a way to define extra sets of complex triggers. Discovery. What >> we could express as profiles are extra complex triggers. >> - *[Thomas]* What are the next steps? >> - *[Raghuram]* Updated version of draft by next week to discuss >> progress. Invite contributors. >> - *[Thomas]* Name of draft? >> - *[Raghuram]* What about "6TiSCH CoAP data model". >> - *[Thomas]* We need to know editor to create repository. >> - *[Raghuram]* AOB? >> >> No other business raised. >> >> - *[09.05]* meeting ends. >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > --e89a8f923c649f1ad304e7b270b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Xavi,

    Quick reply:
    - the term= CoAP is in the title to follow RFC3444.
    - we decided to put some= examples in this draft about different ways of using this data model (e.g.= a node GETting the state of some other node in the network). We had some d= iscussion about the difference between information and interaction models; = we decided to have those as a different document to not loose any of the &q= uot;generic" nature of this data model.

    Thomas


    On Tue, Oct 1, 2013 at 11:42 AM, Xavier Vilajosana= Guillen <xvilajosana@eecs.berkeley.edu> wrote:<= br>
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne = <watteyne@eecs.berkeley.edu> wrote:
    All,

    You will find the minutes of the discussio= n about the models draft from this morning at=A0http= s://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also= copy-pasted below).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    --e89a8f923c649f1ad304e7b270b8-- From qinwang@berkeley.edu Tue Oct 1 11:56:25 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12AB11E8238 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmhDrLtbIXdw for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:56:15 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id 476B211E81AD for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:56:15 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so14779680iec.41 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:56:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=78jlrqKds4ihLku4M8Mh8Q+fVulxJM6nEzD8gNHkJ2A=; b=jByy7K13rdcIj1JYOUMZ2uhnei1V35/aA1f0egQojM4OhcQynr1lOi5KLMYRjVUBdC p4QxJL8HTuspqvpVqbhfC65no2iA5G/IrKEi0kO9yzBugUoAY1HHFxqDOF7Zse1d4hyH /Yam6oHvo5MpYyciRl4sLxyTPbJHJq0AsH5bZu+ZYCCH13RbmEppT5N0e4riXfF84nus tsdr48QFQO6HGSuQQyWtwQMHh+pEZLZS9bb2MIW5PGTUNnOr5mJkxzOZmCE+9RAT6mXs hnScElJQdRb/N0qh3C3ym42VgxsY+VcHrTAaAkRzOQFnAfF6dnI58WrjaewslyVUfjiW wunw== X-Gm-Message-State: ALoCoQnTkoZnKSn2Q0wH37YM2P4jWpdNH14vG9ogFmaRKNgF/Bt7CHri2XIqfVtAqWXwjE08QOl3 MIME-Version: 1.0 X-Received: by 10.50.60.5 with SMTP id d5mr19338233igr.26.1380653773683; Tue, 01 Oct 2013 11:56:13 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 11:56:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Oct 2013 02:56:13 +0800 Message-ID: From: Qin Wang To: Xavier Vilajosana Guillen Content-Type: multipart/alternative; boundary=047d7b10c77fbd083e04e7b281a2 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:56:25 -0000 --047d7b10c77fbd083e04e7b281a2 Content-Type: text/plain; charset=ISO-8859-1 Xavi and all, When we talk about data model (DM), there are likely several points of view. For example: (1) DM is a set of messages, their format, and the behavior caused by the messages. (2) Besides (1), also includes the interface with specific protocol, e.g. URI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so, it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol specific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen < xvilajosana@eecs.berkeley.edu> wrote: > HI all, > > I have a question raising from the minutes (sorry I could not connect > today). > > If title of the draft is "6TiSCH CoAP data Model" this means that in the > future we will have "6TiSCH *foo *data Model". Is that the direction we > want? Data Model is the way to represent message content (i.e what goes in > the payload and is used by 6top commands). Why is this specific to CoAP? > > Another aspect is interaction models, i.e message flows which in that case > they are related to the capabilities of the transport mechanism. > > just thoughts.. Sorry if I really go back to something you already > discussed and it is really clear. > > X > > > > > On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > >> All, >> >> You will find the minutes of the discussion about the models draft from >> this morning at >> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >> copy-pasted below). >> >> Thomas >> >> --- >> >> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >> >> Note: timestamps in PDT. >> Taking notes *(using Etherpad)* >> >> 1. Thomas Watteyne >> 2. Raghuram Sudhaakar >> >> Present *(alphabetically)* >> >> 1. Alaeddine Weslati >> 2. Dan Romascanu >> 3. Diego Dujovne >> 4. Pascal Thubert >> 5. Pouria Zand >> 6. Qin Wang >> 7. R. Nabati >> 8. Raghuram Sudhaakar >> 9. Thomas Watteyne >> >> Agenda >> >> - Present pre-draft ToC *[Raghuram/Pouria]* >> - Discuss ToC >> - Define contents of each section >> >> Minutes >> >> - *[08.05]* meeting starts. >> - *Raghuram* shares pre-draft through Webex >> - goals for today: define ToC, define contents of each section, >> pick title >> - Scope is to include data and interaction model for CoAP. At a >> later stage, extract information model as separate draft. >> - "6TiSCH data model" or "6TiSCH CoAP data model"? >> - *[Thomas]* personal opinion: have CoAP in title >> - *[Qin]* why interaction model on top of information model? >> - *[Raghuram]* we want to define message flows between PCE and nodes. >> Data model is exact definition of payload. We had rough consensus on using >> name-value pairs. Interaction model for CoAP or RSVP in future drafts. >> Interaction model provides abstract model of interaction between entities. >> - *[Qin]* RFC3444, interaction flows should be part of the data >> model? We should not conflict with RFC3444. >> - *[Thomas]* We may want to split the interaction from this (data >> model) draft. >> - *[Qin]* Data definition and coding is common part. For me, >> experience with different definitions. Don't want another terminology. >> - *[Dan]* Not extremely familiar with 6TiSCH but experience with data >> and information model. In the IETF, we have clear definitions about data >> and information model. RFC3444 accepted and used as reference. There are >> differences, i.e. interaction model. We need to stick with RFC3444 as close >> as possible. >> - *[Raghuram]* Goal of interaction model is try to extract >> information model at a later stage. CoAP is one of the transports we are >> using today, but we can use other protocol at a later stage. We can name it >> differently later "interaction method". >> - *[Dan]* If we are inventing a new name, it does not matter too >> much. We are looking at mapping different transports. >> - *[Raghuram]* Goal of interaction model is to extract the >> information model. >> - *[Raghuram]* Change to ToC: remove interaction? >> - *[Thomas]* Could be replaced by example scenarios. >> - *[Pascal]* We have identified interaction at L2, L3 and L5. We need >> to have discussion about the models. >> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >> interactions". Message formats would be moved up to 3.3, name-value pairs >> proposed. >> - *[Thomas]* Rough consensus? >> - *[Qin]* what's the different between management and informational >> resources? >> - *[Raghuram]* management resources are R/W, informational resources >> are R (e.g. DAGrank). >> - *[Thomas]* We could walk through ToC? >> - *[Raghuram]* >> - 3.1 naming convention for URI schemes. For example, root >> resource "6t". Includes naming convention for resources under root resource. >> - 3.2 resource of 6top we want to expose, i.e. management and >> informational resource. >> - 3.2.4 user installed resources, e.g. subscribe for particular >> implementation. >> - *[Raghuram]* Should we have extensible resources? >> - *[Thomas]* Yes. >> - *[Qin]* What the functional description of a resource? Related to >> not only management but also informational resources. Should we put every >> description attached to every resource? Looking at the content, I can >> imagine a resource list, with a description for each one. Suggestion is to >> put description just following the resource list. >> - *[Raghuram]* Fine with that. >> - *[Pouria]* Other change "functional description of resources" will >> fold into 3.2.1 and 3.2.2. >> - *[Raghuram]* Resource is just the URI, linked to particular 6top >> variable. Methods would fall under description of resource. >> - *[Qin]* Description of the MIB? >> - *[Raghuram]* End-user should be able to get a specific parameters. >> Returned as name-value pairs. If an entity wants the entire MIB, we will >> have a separate resource. >> - *[Thomas]* Mapping of 6top commands included? >> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >> previous calls. >> - *[Pouria]* In resource management, information that can be written >> by PCE, or commands to be executed. >> - *[Raghuram]* Everything that change the TSCH schedule falls under >> the management resource. >> - *[Raghuram]* Section 4 will be moved up. A message format will be >> attached to each URI. >> - *[Thomas]* Map the attributes from minimal draft and the commands >> from 6top draft. >> - *[Raghuram]* That is the plan. >> - *[Thomas]* What are extensions? >> - *[Raghuram]* We don't want to define the URI for every attribute, >> we want to enable people to install a new resource with a definition. >> - *[Raghuram]* In that context, what are profiles? >> - *[Thomas]* Profile is overarching modification to basic behavior: >> e.g. adding resources or adding method to existing resource. >> - *[Qin]* Understanding about profile: resource is fixed, behavior of >> resource can be configurable. >> - *[Pascal]* +1 it's very important we are able to do add to basic >> behavior. >> - *[Diego]* How can we describe a trigger, e.g. number of >> measurements to average over. >> - *[Thomas]* Do we have a solution? >> - *[Raghuram]* Yes, complex triggers are defined using well-known >> formats. RFC already defines how to encode several thresholds. Output would >> be sent on CoAP response or observe notification. One generic method for >> any kind of trigger. >> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >> Profiles as a way to define extra sets of complex triggers. Discovery. What >> we could express as profiles are extra complex triggers. >> - *[Thomas]* What are the next steps? >> - *[Raghuram]* Updated version of draft by next week to discuss >> progress. Invite contributors. >> - *[Thomas]* Name of draft? >> - *[Raghuram]* What about "6TiSCH CoAP data model". >> - *[Thomas]* We need to know editor to create repository. >> - *[Raghuram]* AOB? >> >> No other business raised. >> >> - *[09.05]* meeting ends. >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7b10c77fbd083e04e7b281a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Xavi and all,

    When we talk about data m= odel (DM), there are likely several points of view. For example:
    = (1) DM is a set of messages, their format, and the behavior caused by the m= essages.
    (2) Besides (1), also includes the interface with specific protocol, e= .g. URI in CoAP.

    From the point (1) of view, I agr= ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

    So, can we separate the common part of DM, i.e. point (= 1) from protocol specific part of DM, i.e. something like URI?
    What do you think?

    Qin



    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen <= xvilajosana@eecs.berkeley.edu> wrote:
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne = <watteyne@eecs.berkeley.edu> wrote:
    All,

    You will find the minutes of the discussio= n about the models draft from this morning at=A0http= s://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also= copy-pasted below).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --047d7b10c77fbd083e04e7b281a2-- From twatteyne@gmail.com Tue Oct 1 11:58:48 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A181611E81B9 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzPkRq2mcxHT for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 11:58:47 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2911511E81AD for <6tsch@ietf.org>; Tue, 1 Oct 2013 11:58:47 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lf10so7904416pab.17 for <6tsch@ietf.org>; Tue, 01 Oct 2013 11:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=p/vA8FY3WHHlRSC+4QQWiFQtIDH+qN818wUp3PLnUSI=; b=PUsuWEO6833Smc0byrZA/+mu1II7acu+lgRgQk9fwO3ElTuq0xIpnjuSnFPPq291sA dQSq1hzDQIatoUtOb2o3R7wAs2rhHcj+qYtU97gDR1KK7JL/h6myJlTPgTsM+jddd7Ml 1MhDW5E1OiRqMJiatLlkNCT6OQpXWoAVzURL44th9Sc7OF2bkTuqG7AyPDECx8D8UCux lcEYrYidmLfha3CVH9anWzaOz1P51VEzgjnEcaej0lABbL2BOPilAPHxG7WKQtEuWpOC IzWx1jLT8sWURdR5W2AkjAfaEwRSsa1iwjgtCAkOtIB13eRlBf1BEyWLALFak2C+BeeD dhKw== X-Received: by 10.66.150.41 with SMTP id uf9mr35681035pab.108.1380653926850; Tue, 01 Oct 2013 11:58:46 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Tue, 1 Oct 2013 11:58:26 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Tue, 1 Oct 2013 11:58:26 -0700 X-Google-Sender-Auth: dB4hjZihYzSwYsSdLEsOu9qzM-c Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b6d7f14de2cac04e7b28a24 Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:58:48 -0000 --047d7b6d7f14de2cac04e7b28a24 Content-Type: text/plain; charset=ISO-8859-1 I don't believe we want to split this draft even more, right? On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang wrote: > Xavi and all, > > When we talk about data model (DM), there are likely several points of > view. For example: > (1) DM is a set of messages, their format, and the behavior caused by the > messages. > (2) Besides (1), also includes the interface with specific protocol, e.g. > URI in CoAP. > > From the point (1) of view, I agree Xavi. But, because URI is involved, > so, it becomes CoAP Data Model. > > So, can we separate the common part of DM, i.e. point (1) from protocol > specific part of DM, i.e. something like URI? > > What do you think? > > Qin > > > > On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen < > xvilajosana@eecs.berkeley.edu> wrote: > >> HI all, >> >> I have a question raising from the minutes (sorry I could not connect >> today). >> >> If title of the draft is "6TiSCH CoAP data Model" this means that in the >> future we will have "6TiSCH *foo *data Model". Is that the direction we >> want? Data Model is the way to represent message content (i.e what goes in >> the payload and is used by 6top commands). Why is this specific to CoAP? >> >> Another aspect is interaction models, i.e message flows which in that >> case they are related to the capabilities of the transport mechanism. >> >> just thoughts.. Sorry if I really go back to something you already >> discussed and it is really clear. >> >> X >> >> >> >> >> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < >> watteyne@eecs.berkeley.edu> wrote: >> >>> All, >>> >>> You will find the minutes of the discussion about the models draft from >>> this morning at >>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >>> copy-pasted below). >>> >>> Thomas >>> >>> --- >>> >>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >>> >>> Note: timestamps in PDT. >>> Taking notes *(using Etherpad)* >>> >>> 1. Thomas Watteyne >>> 2. Raghuram Sudhaakar >>> >>> Present *(alphabetically)* >>> >>> 1. Alaeddine Weslati >>> 2. Dan Romascanu >>> 3. Diego Dujovne >>> 4. Pascal Thubert >>> 5. Pouria Zand >>> 6. Qin Wang >>> 7. R. Nabati >>> 8. Raghuram Sudhaakar >>> 9. Thomas Watteyne >>> >>> Agenda >>> >>> - Present pre-draft ToC *[Raghuram/Pouria]* >>> - Discuss ToC >>> - Define contents of each section >>> >>> Minutes >>> >>> - *[08.05]* meeting starts. >>> - *Raghuram* shares pre-draft through Webex >>> - goals for today: define ToC, define contents of each section, >>> pick title >>> - Scope is to include data and interaction model for CoAP. At a >>> later stage, extract information model as separate draft. >>> - "6TiSCH data model" or "6TiSCH CoAP data model"? >>> - *[Thomas]* personal opinion: have CoAP in title >>> - *[Qin]* why interaction model on top of information model? >>> - *[Raghuram]* we want to define message flows between PCE and >>> nodes. Data model is exact definition of payload. We had rough consensus on >>> using name-value pairs. Interaction model for CoAP or RSVP in future >>> drafts. Interaction model provides abstract model of interaction between >>> entities. >>> - *[Qin]* RFC3444, interaction flows should be part of the data >>> model? We should not conflict with RFC3444. >>> - *[Thomas]* We may want to split the interaction from this (data >>> model) draft. >>> - *[Qin]* Data definition and coding is common part. For me, >>> experience with different definitions. Don't want another terminology. >>> - *[Dan]* Not extremely familiar with 6TiSCH but experience with >>> data and information model. In the IETF, we have clear definitions about >>> data and information model. RFC3444 accepted and used as reference. There >>> are differences, i.e. interaction model. We need to stick with RFC3444 as >>> close as possible. >>> - *[Raghuram]* Goal of interaction model is try to extract >>> information model at a later stage. CoAP is one of the transports we are >>> using today, but we can use other protocol at a later stage. We can name it >>> differently later "interaction method". >>> - *[Dan]* If we are inventing a new name, it does not matter too >>> much. We are looking at mapping different transports. >>> - *[Raghuram]* Goal of interaction model is to extract the >>> information model. >>> - *[Raghuram]* Change to ToC: remove interaction? >>> - *[Thomas]* Could be replaced by example scenarios. >>> - *[Pascal]* We have identified interaction at L2, L3 and L5. We >>> need to have discussion about the models. >>> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >>> interactions". Message formats would be moved up to 3.3, name-value pairs >>> proposed. >>> - *[Thomas]* Rough consensus? >>> - *[Qin]* what's the different between management and informational >>> resources? >>> - *[Raghuram]* management resources are R/W, informational resources >>> are R (e.g. DAGrank). >>> - *[Thomas]* We could walk through ToC? >>> - *[Raghuram]* >>> - 3.1 naming convention for URI schemes. For example, root >>> resource "6t". Includes naming convention for resources under root resource. >>> - 3.2 resource of 6top we want to expose, i.e. management and >>> informational resource. >>> - 3.2.4 user installed resources, e.g. subscribe for particular >>> implementation. >>> - *[Raghuram]* Should we have extensible resources? >>> - *[Thomas]* Yes. >>> - *[Qin]* What the functional description of a resource? Related to >>> not only management but also informational resources. Should we put every >>> description attached to every resource? Looking at the content, I can >>> imagine a resource list, with a description for each one. Suggestion is to >>> put description just following the resource list. >>> - *[Raghuram]* Fine with that. >>> - *[Pouria]* Other change "functional description of resources" will >>> fold into 3.2.1 and 3.2.2. >>> - *[Raghuram]* Resource is just the URI, linked to particular 6top >>> variable. Methods would fall under description of resource. >>> - *[Qin]* Description of the MIB? >>> - *[Raghuram]* End-user should be able to get a specific parameters. >>> Returned as name-value pairs. If an entity wants the entire MIB, we will >>> have a separate resource. >>> - *[Thomas]* Mapping of 6top commands included? >>> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >>> previous calls. >>> - *[Pouria]* In resource management, information that can be written >>> by PCE, or commands to be executed. >>> - *[Raghuram]* Everything that change the TSCH schedule falls under >>> the management resource. >>> - *[Raghuram]* Section 4 will be moved up. A message format will be >>> attached to each URI. >>> - *[Thomas]* Map the attributes from minimal draft and the commands >>> from 6top draft. >>> - *[Raghuram]* That is the plan. >>> - *[Thomas]* What are extensions? >>> - *[Raghuram]* We don't want to define the URI for every attribute, >>> we want to enable people to install a new resource with a definition. >>> - *[Raghuram]* In that context, what are profiles? >>> - *[Thomas]* Profile is overarching modification to basic behavior: >>> e.g. adding resources or adding method to existing resource. >>> - *[Qin]* Understanding about profile: resource is fixed, behavior >>> of resource can be configurable. >>> - *[Pascal]* +1 it's very important we are able to do add to basic >>> behavior. >>> - *[Diego]* How can we describe a trigger, e.g. number of >>> measurements to average over. >>> - *[Thomas]* Do we have a solution? >>> - *[Raghuram]* Yes, complex triggers are defined using well-known >>> formats. RFC already defines how to encode several thresholds. Output would >>> be sent on CoAP response or observe notification. One generic method for >>> any kind of trigger. >>> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >>> Profiles as a way to define extra sets of complex triggers. Discovery. What >>> we could express as profiles are extra complex triggers. >>> - *[Thomas]* What are the next steps? >>> - *[Raghuram]* Updated version of draft by next week to discuss >>> progress. Invite contributors. >>> - *[Thomas]* Name of draft? >>> - *[Raghuram]* What about "6TiSCH CoAP data model". >>> - *[Thomas]* We need to know editor to create repository. >>> - *[Raghuram]* AOB? >>> >>> No other business raised. >>> >>> - *[09.05]* meeting ends. >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > --047d7b6d7f14de2cac04e7b28a24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I don't believe we want to split this draft even more,= right?


    = On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu>= wrote:
    Xavi and all,

    When we talk about data model (DM), there are likely several points o= f view. For example:
    (1) DM is a set of messages, their format, and the behavior caused by = the messages.
    (2) Besides (1), also includes the interface with specific protocol, e= .g. URI in CoAP.

    From the point (1) of view, I agr= ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

    So, can we separate the common part of DM, i.e. point (= 1) from protocol specific part of DM, i.e. something like URI?
    What do you think?

    Qin



    On Wed, Oct 2, 201= 3 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs.berk= eley.edu> wrote:
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <wa= tteyne@eecs.berkeley.edu> wrote:
    All,<= div>
    You will find the minutes of the discussion about the mo= dels draft from this morning at=A0https://bitbucket.= org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also copy-pasted b= elow).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    --047d7b6d7f14de2cac04e7b28a24-- From xvilajosana@berkeley.edu Tue Oct 1 12:01:22 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209D311E824E for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgwkHPtPIyyw for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:01:18 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDB021F9DF6 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:01:12 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so7609228pdj.40 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:01:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VF/lQGjABJ8CKMs7vMPuBprh07sczidh/TNpgLQmQZ4=; b=XBkiwqKsssOiGr+TIp1aHv62MSgEKIFfpmAfNTlh+2bjvhfKxNfbViNuLq2joME5Ki NeIwf2sdq8PrhX/a2+hdscPdFa7H2BQAdeQ7rEa3SYPhVzVrxp4YghJLE88RDwoMZjND w7Qs0P7q+lvFT3w2xc7rX73NkaUDew9ul7FruFomNDu/Cy2dJeICEDImdDHFTJAIs4tU gnMcqQd8JyXLxPvKaH66MLfoQVE+DO+e3BTMDquuWx62y8dzWRQzCNpEgJDe9kpmZe8f XBzcO0Pr4Ek+XXfuVUm2sx1BXLuHaxteJoXys36BxQU7/rj5NWEfIz0SzQtQmIqCtnyO UIAw== X-Gm-Message-State: ALoCoQnmRxNzq/gkefw3+jgZb/EO5WSP+/QT0ha3YZZLC75qb3NcULR1xZN1CSmHHZcpwSkdGEBN MIME-Version: 1.0 X-Received: by 10.68.192.195 with SMTP id hi3mr31309617pbc.18.1380654070224; Tue, 01 Oct 2013 12:01:10 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 12:01:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Oct 2013 12:01:10 -0700 Message-ID: From: Xavier Vilajosana Guillen To: Qin Wang Content-Type: multipart/alternative; boundary=047d7ba970e669e64104e7b293ca Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:01:22 -0000 --047d7ba970e669e64104e7b293ca Content-Type: text/plain; charset=ISO-8859-1 Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access a particular service offered by the management layer, I agree that this should have CoAP name on it if this is bound to URI. then the data model( the content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang wrote: > Xavi and all, > > When we talk about data model (DM), there are likely several points of > view. For example: > (1) DM is a set of messages, their format, and the behavior caused by the > messages. > (2) Besides (1), also includes the interface with specific protocol, e.g. > URI in CoAP. > > From the point (1) of view, I agree Xavi. But, because URI is involved, > so, it becomes CoAP Data Model. > > So, can we separate the common part of DM, i.e. point (1) from protocol > specific part of DM, i.e. something like URI? > > What do you think? > > Qin > > > > On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen < > xvilajosana@eecs.berkeley.edu> wrote: > >> HI all, >> >> I have a question raising from the minutes (sorry I could not connect >> today). >> >> If title of the draft is "6TiSCH CoAP data Model" this means that in the >> future we will have "6TiSCH *foo *data Model". Is that the direction we >> want? Data Model is the way to represent message content (i.e what goes in >> the payload and is used by 6top commands). Why is this specific to CoAP? >> >> Another aspect is interaction models, i.e message flows which in that >> case they are related to the capabilities of the transport mechanism. >> >> just thoughts.. Sorry if I really go back to something you already >> discussed and it is really clear. >> >> X >> >> >> >> >> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < >> watteyne@eecs.berkeley.edu> wrote: >> >>> All, >>> >>> You will find the minutes of the discussion about the models draft from >>> this morning at >>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >>> copy-pasted below). >>> >>> Thomas >>> >>> --- >>> >>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >>> >>> Note: timestamps in PDT. >>> Taking notes *(using Etherpad)* >>> >>> 1. Thomas Watteyne >>> 2. Raghuram Sudhaakar >>> >>> Present *(alphabetically)* >>> >>> 1. Alaeddine Weslati >>> 2. Dan Romascanu >>> 3. Diego Dujovne >>> 4. Pascal Thubert >>> 5. Pouria Zand >>> 6. Qin Wang >>> 7. R. Nabati >>> 8. Raghuram Sudhaakar >>> 9. Thomas Watteyne >>> >>> Agenda >>> >>> - Present pre-draft ToC *[Raghuram/Pouria]* >>> - Discuss ToC >>> - Define contents of each section >>> >>> Minutes >>> >>> - *[08.05]* meeting starts. >>> - *Raghuram* shares pre-draft through Webex >>> - goals for today: define ToC, define contents of each section, >>> pick title >>> - Scope is to include data and interaction model for CoAP. At a >>> later stage, extract information model as separate draft. >>> - "6TiSCH data model" or "6TiSCH CoAP data model"? >>> - *[Thomas]* personal opinion: have CoAP in title >>> - *[Qin]* why interaction model on top of information model? >>> - *[Raghuram]* we want to define message flows between PCE and >>> nodes. Data model is exact definition of payload. We had rough consensus on >>> using name-value pairs. Interaction model for CoAP or RSVP in future >>> drafts. Interaction model provides abstract model of interaction between >>> entities. >>> - *[Qin]* RFC3444, interaction flows should be part of the data >>> model? We should not conflict with RFC3444. >>> - *[Thomas]* We may want to split the interaction from this (data >>> model) draft. >>> - *[Qin]* Data definition and coding is common part. For me, >>> experience with different definitions. Don't want another terminology. >>> - *[Dan]* Not extremely familiar with 6TiSCH but experience with >>> data and information model. In the IETF, we have clear definitions about >>> data and information model. RFC3444 accepted and used as reference. There >>> are differences, i.e. interaction model. We need to stick with RFC3444 as >>> close as possible. >>> - *[Raghuram]* Goal of interaction model is try to extract >>> information model at a later stage. CoAP is one of the transports we are >>> using today, but we can use other protocol at a later stage. We can name it >>> differently later "interaction method". >>> - *[Dan]* If we are inventing a new name, it does not matter too >>> much. We are looking at mapping different transports. >>> - *[Raghuram]* Goal of interaction model is to extract the >>> information model. >>> - *[Raghuram]* Change to ToC: remove interaction? >>> - *[Thomas]* Could be replaced by example scenarios. >>> - *[Pascal]* We have identified interaction at L2, L3 and L5. We >>> need to have discussion about the models. >>> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >>> interactions". Message formats would be moved up to 3.3, name-value pairs >>> proposed. >>> - *[Thomas]* Rough consensus? >>> - *[Qin]* what's the different between management and informational >>> resources? >>> - *[Raghuram]* management resources are R/W, informational resources >>> are R (e.g. DAGrank). >>> - *[Thomas]* We could walk through ToC? >>> - *[Raghuram]* >>> - 3.1 naming convention for URI schemes. For example, root >>> resource "6t". Includes naming convention for resources under root resource. >>> - 3.2 resource of 6top we want to expose, i.e. management and >>> informational resource. >>> - 3.2.4 user installed resources, e.g. subscribe for particular >>> implementation. >>> - *[Raghuram]* Should we have extensible resources? >>> - *[Thomas]* Yes. >>> - *[Qin]* What the functional description of a resource? Related to >>> not only management but also informational resources. Should we put every >>> description attached to every resource? Looking at the content, I can >>> imagine a resource list, with a description for each one. Suggestion is to >>> put description just following the resource list. >>> - *[Raghuram]* Fine with that. >>> - *[Pouria]* Other change "functional description of resources" will >>> fold into 3.2.1 and 3.2.2. >>> - *[Raghuram]* Resource is just the URI, linked to particular 6top >>> variable. Methods would fall under description of resource. >>> - *[Qin]* Description of the MIB? >>> - *[Raghuram]* End-user should be able to get a specific parameters. >>> Returned as name-value pairs. If an entity wants the entire MIB, we will >>> have a separate resource. >>> - *[Thomas]* Mapping of 6top commands included? >>> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >>> previous calls. >>> - *[Pouria]* In resource management, information that can be written >>> by PCE, or commands to be executed. >>> - *[Raghuram]* Everything that change the TSCH schedule falls under >>> the management resource. >>> - *[Raghuram]* Section 4 will be moved up. A message format will be >>> attached to each URI. >>> - *[Thomas]* Map the attributes from minimal draft and the commands >>> from 6top draft. >>> - *[Raghuram]* That is the plan. >>> - *[Thomas]* What are extensions? >>> - *[Raghuram]* We don't want to define the URI for every attribute, >>> we want to enable people to install a new resource with a definition. >>> - *[Raghuram]* In that context, what are profiles? >>> - *[Thomas]* Profile is overarching modification to basic behavior: >>> e.g. adding resources or adding method to existing resource. >>> - *[Qin]* Understanding about profile: resource is fixed, behavior >>> of resource can be configurable. >>> - *[Pascal]* +1 it's very important we are able to do add to basic >>> behavior. >>> - *[Diego]* How can we describe a trigger, e.g. number of >>> measurements to average over. >>> - *[Thomas]* Do we have a solution? >>> - *[Raghuram]* Yes, complex triggers are defined using well-known >>> formats. RFC already defines how to encode several thresholds. Output would >>> be sent on CoAP response or observe notification. One generic method for >>> any kind of trigger. >>> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >>> Profiles as a way to define extra sets of complex triggers. Discovery. What >>> we could express as profiles are extra complex triggers. >>> - *[Thomas]* What are the next steps? >>> - *[Raghuram]* Updated version of draft by next week to discuss >>> progress. Invite contributors. >>> - *[Thomas]* Name of draft? >>> - *[Raghuram]* What about "6TiSCH CoAP data model". >>> - *[Thomas]* We need to know editor to create repository. >>> - *[Raghuram]* AOB? >>> >>> No other business raised. >>> >>> - *[09.05]* meeting ends. >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > --047d7ba970e669e64104e7b293ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi Qin,

    I agree with you .. URI= is to indentify the resource, i.e how do we access a particular service of= fered by the management layer, I agree that this should have CoAP name on i= t if this is bound to URI. then the data model( the content of what we sent= on the payload) this should be generic right?

    so I see it in two separete things.

    1-interaction mo= del using CoAP
    2-content/data model generic..

    <= br>
    X




    On Tue,= Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu>= wrote:
    Xavi and all,

    When we talk about data model (DM), there are likely several points o= f view. For example:
    (1) DM is a set of messages, their format, and the behavior caused by = the messages.
    (2) Besides (1), also includes the interface with specific protocol, e= .g. URI in CoAP.

    From the point (1) of view, I agr= ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

    So, can we separate the common part of DM, i.e. point (= 1) from protocol specific part of DM, i.e. something like URI?
    What do you think?

    Qin



    On Wed, Oct 2, 201= 3 at 2:42 AM, Xavier Vilajosana Guillen <xvilajosana@eecs.berk= eley.edu> wrote:
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <wa= tteyne@eecs.berkeley.edu> wrote:
    All,<= div>
    You will find the minutes of the discussion about the mo= dels draft from this morning at=A0https://bitbucket.= org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also copy-pasted b= elow).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    --047d7ba970e669e64104e7b293ca-- From qinwang@berkeley.edu Tue Oct 1 12:03:37 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8587D21E826C for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XYFs6IFQlbe for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:03:33 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id C25C221E8286 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:03:19 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so14851579iej.38 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:03:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rCQp3TCDX+UjhiI6qnPq6XAkI6HtuTB28IjHT5z2tXU=; b=Ptwdqk/wJch4QLqYRifxJvFgSFPd6c5U5BJFMpL9ecg6zZGThJJy37v59Mi9v7daCT eifCbfsRkg90IrTEjR7RXPuDRN+hW3KT4R4ljnwd7vMLDb0RYy9fOPmybeXe/Z3QSTcg yTsAFXyETPhFZ1gUUVa3EaHLK7su9FEyapEOyIDZ9NY96kbTAbPkSktXQXgEB61Zzhxy zfNeTKST7uPbdajUIepPuNupQjD0OAQlzB3s6/D0JmZyAf6X+Mg/ZWmIgPBiDZj399vc ryP/o8on8SjUJUNID6pob0KEvk2y2hO0XAhP7AhbbfgTosPzK9N5IEz6l0GAbtZ06Xs2 ntOw== X-Gm-Message-State: ALoCoQneZeHSBYXnM94+FYnOWHUUjXGom4d22U9YE9+e0clcCuzytJsnFmF8iIIAXp35ecrqEBXl MIME-Version: 1.0 X-Received: by 10.50.66.101 with SMTP id e5mr19362286igt.26.1380654199113; Tue, 01 Oct 2013 12:03:19 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:03:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Oct 2013 03:03:19 +0800 Message-ID: From: Qin Wang To: Thomas Watteyne Content-Type: multipart/alternative; boundary=001a1135ec0c189af904e7b29bc5 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:03:38 -0000 --001a1135ec0c189af904e7b29bc5 Content-Type: text/plain; charset=ISO-8859-1 Just change sections, e.g. separate current section 3 into 3. messages and format 4. Mapping to URI Just thought. Qin On Wed, Oct 2, 2013 at 2:58 AM, Thomas Watteyne wrote: > I don't believe we want to split this draft even more, right? > > > On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang wrote: > >> Xavi and all, >> >> When we talk about data model (DM), there are likely several points of >> view. For example: >> (1) DM is a set of messages, their format, and the behavior caused by the >> messages. >> (2) Besides (1), also includes the interface with specific protocol, e.g. >> URI in CoAP. >> >> From the point (1) of view, I agree Xavi. But, because URI is involved, >> so, it becomes CoAP Data Model. >> >> So, can we separate the common part of DM, i.e. point (1) from protocol >> specific part of DM, i.e. something like URI? >> >> What do you think? >> >> Qin >> >> >> >> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen < >> xvilajosana@eecs.berkeley.edu> wrote: >> >>> HI all, >>> >>> I have a question raising from the minutes (sorry I could not connect >>> today). >>> >>> If title of the draft is "6TiSCH CoAP data Model" this means that in the >>> future we will have "6TiSCH *foo *data Model". Is that the direction we >>> want? Data Model is the way to represent message content (i.e what goes in >>> the payload and is used by 6top commands). Why is this specific to CoAP? >>> >>> Another aspect is interaction models, i.e message flows which in that >>> case they are related to the capabilities of the transport mechanism. >>> >>> just thoughts.. Sorry if I really go back to something you already >>> discussed and it is really clear. >>> >>> X >>> >>> >>> >>> >>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote: >>> >>>> All, >>>> >>>> You will find the minutes of the discussion about the models draft from >>>> this morning at >>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >>>> copy-pasted below). >>>> >>>> Thomas >>>> >>>> --- >>>> >>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >>>> >>>> Note: timestamps in PDT. >>>> Taking notes *(using Etherpad)* >>>> >>>> 1. Thomas Watteyne >>>> 2. Raghuram Sudhaakar >>>> >>>> Present *(alphabetically)* >>>> >>>> 1. Alaeddine Weslati >>>> 2. Dan Romascanu >>>> 3. Diego Dujovne >>>> 4. Pascal Thubert >>>> 5. Pouria Zand >>>> 6. Qin Wang >>>> 7. R. Nabati >>>> 8. Raghuram Sudhaakar >>>> 9. Thomas Watteyne >>>> >>>> Agenda >>>> >>>> - Present pre-draft ToC *[Raghuram/Pouria]* >>>> - Discuss ToC >>>> - Define contents of each section >>>> >>>> Minutes >>>> >>>> - *[08.05]* meeting starts. >>>> - *Raghuram* shares pre-draft through Webex >>>> - goals for today: define ToC, define contents of each section, >>>> pick title >>>> - Scope is to include data and interaction model for CoAP. At a >>>> later stage, extract information model as separate draft. >>>> - "6TiSCH data model" or "6TiSCH CoAP data model"? >>>> - *[Thomas]* personal opinion: have CoAP in title >>>> - *[Qin]* why interaction model on top of information model? >>>> - *[Raghuram]* we want to define message flows between PCE and >>>> nodes. Data model is exact definition of payload. We had rough consensus on >>>> using name-value pairs. Interaction model for CoAP or RSVP in future >>>> drafts. Interaction model provides abstract model of interaction between >>>> entities. >>>> - *[Qin]* RFC3444, interaction flows should be part of the data >>>> model? We should not conflict with RFC3444. >>>> - *[Thomas]* We may want to split the interaction from this (data >>>> model) draft. >>>> - *[Qin]* Data definition and coding is common part. For me, >>>> experience with different definitions. Don't want another terminology. >>>> - *[Dan]* Not extremely familiar with 6TiSCH but experience with >>>> data and information model. In the IETF, we have clear definitions about >>>> data and information model. RFC3444 accepted and used as reference. There >>>> are differences, i.e. interaction model. We need to stick with RFC3444 as >>>> close as possible. >>>> - *[Raghuram]* Goal of interaction model is try to extract >>>> information model at a later stage. CoAP is one of the transports we are >>>> using today, but we can use other protocol at a later stage. We can name it >>>> differently later "interaction method". >>>> - *[Dan]* If we are inventing a new name, it does not matter too >>>> much. We are looking at mapping different transports. >>>> - *[Raghuram]* Goal of interaction model is to extract the >>>> information model. >>>> - *[Raghuram]* Change to ToC: remove interaction? >>>> - *[Thomas]* Could be replaced by example scenarios. >>>> - *[Pascal]* We have identified interaction at L2, L3 and L5. We >>>> need to have discussion about the models. >>>> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >>>> interactions". Message formats would be moved up to 3.3, name-value pairs >>>> proposed. >>>> - *[Thomas]* Rough consensus? >>>> - *[Qin]* what's the different between management and informational >>>> resources? >>>> - *[Raghuram]* management resources are R/W, informational >>>> resources are R (e.g. DAGrank). >>>> - *[Thomas]* We could walk through ToC? >>>> - *[Raghuram]* >>>> - 3.1 naming convention for URI schemes. For example, root >>>> resource "6t". Includes naming convention for resources under root resource. >>>> - 3.2 resource of 6top we want to expose, i.e. management and >>>> informational resource. >>>> - 3.2.4 user installed resources, e.g. subscribe for particular >>>> implementation. >>>> - *[Raghuram]* Should we have extensible resources? >>>> - *[Thomas]* Yes. >>>> - *[Qin]* What the functional description of a resource? Related to >>>> not only management but also informational resources. Should we put every >>>> description attached to every resource? Looking at the content, I can >>>> imagine a resource list, with a description for each one. Suggestion is to >>>> put description just following the resource list. >>>> - *[Raghuram]* Fine with that. >>>> - *[Pouria]* Other change "functional description of resources" >>>> will fold into 3.2.1 and 3.2.2. >>>> - *[Raghuram]* Resource is just the URI, linked to particular 6top >>>> variable. Methods would fall under description of resource. >>>> - *[Qin]* Description of the MIB? >>>> - *[Raghuram]* End-user should be able to get a specific >>>> parameters. Returned as name-value pairs. If an entity wants the entire >>>> MIB, we will have a separate resource. >>>> - *[Thomas]* Mapping of 6top commands included? >>>> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >>>> previous calls. >>>> - *[Pouria]* In resource management, information that can be >>>> written by PCE, or commands to be executed. >>>> - *[Raghuram]* Everything that change the TSCH schedule falls under >>>> the management resource. >>>> - *[Raghuram]* Section 4 will be moved up. A message format will be >>>> attached to each URI. >>>> - *[Thomas]* Map the attributes from minimal draft and the commands >>>> from 6top draft. >>>> - *[Raghuram]* That is the plan. >>>> - *[Thomas]* What are extensions? >>>> - *[Raghuram]* We don't want to define the URI for every attribute, >>>> we want to enable people to install a new resource with a definition. >>>> - *[Raghuram]* In that context, what are profiles? >>>> - *[Thomas]* Profile is overarching modification to basic behavior: >>>> e.g. adding resources or adding method to existing resource. >>>> - *[Qin]* Understanding about profile: resource is fixed, behavior >>>> of resource can be configurable. >>>> - *[Pascal]* +1 it's very important we are able to do add to basic >>>> behavior. >>>> - *[Diego]* How can we describe a trigger, e.g. number of >>>> measurements to average over. >>>> - *[Thomas]* Do we have a solution? >>>> - *[Raghuram]* Yes, complex triggers are defined using well-known >>>> formats. RFC already defines how to encode several thresholds. Output would >>>> be sent on CoAP response or observe notification. One generic method for >>>> any kind of trigger. >>>> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >>>> Profiles as a way to define extra sets of complex triggers. Discovery. What >>>> we could express as profiles are extra complex triggers. >>>> - *[Thomas]* What are the next steps? >>>> - *[Raghuram]* Updated version of draft by next week to discuss >>>> progress. Invite contributors. >>>> - *[Thomas]* Name of draft? >>>> - *[Raghuram]* What about "6TiSCH CoAP data model". >>>> - *[Thomas]* We need to know editor to create repository. >>>> - *[Raghuram]* AOB? >>>> >>>> No other business raised. >>>> >>>> - *[09.05]* meeting ends. >>>> >>>> >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch >>>> >>>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --001a1135ec0c189af904e7b29bc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Just change sections, e.g. separate current section 3 into= =A0

    3. messages and format
    4. Mapping to URI

    Just thought.

    Qin


    On Wed, Oct 2= , 2013 at 2:58 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
    I don't believe we want= to split this draft even more, right?


    On Tue, Oct 1= , 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote= :
    Xavi and all,

    When we talk about data model (DM), there are likely several points o= f view. For example:
    (1) DM is a set of messages, their format, and the behavior caused by = the messages.
    (2) Besides (1), also includes the interface with specific protocol, e= .g. URI in CoAP.

    From the point (1) of view, I agr= ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

    So, can we separate the common part of DM, i.e. point (= 1) from protocol specific part of DM, i.e. something like URI?
    What do you think?

    Qin



    =
    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosan= a Guillen <xvilajosana@eecs.berkeley.edu> wrote:=
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <wa= tteyne@eecs.berkeley.edu> wrote:
    All,<= div>
    You will find the minutes of the discussion about the mo= dels draft from this morning at=A0https://bitbucket.= org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also copy-pasted b= elow).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch




    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --001a1135ec0c189af904e7b29bc5-- From qinwang@berkeley.edu Tue Oct 1 12:06:47 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FC521E80C5 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBtQWmF5sfwC for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 12:06:38 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95411E8273 for <6tsch@ietf.org>; Tue, 1 Oct 2013 12:06:30 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so14873225iet.33 for <6tsch@ietf.org>; Tue, 01 Oct 2013 12:06:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9KyLaIMu4CcYq4ToHuKfVAsCLe3jYlsFiGKJr8p40lQ=; b=YUgw5b5wioEjEOMjGyhql9QDJGtNI/W2OXXOLs+eFNyvgbO+bzeKpI2X/+sw/QiLlv niklwtSjZsu5cOo1CQTRgSPue/uX1f3R1ak+Tz1NLlPvpcXXwkvwlLtL3nGKwn6hCYI/ D7qR3uvlJuk1L/ieM8odaB+Gg4Ove1ab2jnRkRFcH811VA9a4eAkrz06QUpWfHTyVrt3 ZrISGzV3pFqMZR05AptqlhlNpa7gjK8BdW6Qt8OL1ldjUGGGReMSYEAnxIgkG8xn3J1d F4SlQ3hP84B5FMuomm85tEPworSaso2DNrpiQGfxE3ZYoNzanNTVA4renxG1TXQ0ugFA BCFA== X-Gm-Message-State: ALoCoQlJaCEjEQxbdsB12F4b3muEO0PfQSjOnsitmMthpXdNp5DG07m0cHap8UDPHZx6EU87RlLa MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr19263241igl.45.1380654389356; Tue, 01 Oct 2013 12:06:29 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Tue, 1 Oct 2013 12:06:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Oct 2013 03:06:29 +0800 Message-ID: From: Qin Wang To: Xavier Vilajosana Guillen Content-Type: multipart/alternative; boundary=089e01176cad6fa79404e7b2a677 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:06:47 -0000 --089e01176cad6fa79404e7b2a677 Content-Type: text/plain; charset=ISO-8859-1 Xavi, Agree! Qin On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen < xvilajosana@eecs.berkeley.edu> wrote: > Hi Qin, > > I agree with you .. URI is to indentify the resource, i.e how do we access > a particular service offered by the management layer, I agree that this > should have CoAP name on it if this is bound to URI. then the data model( > the content of what we sent on the payload) this should be generic right? > > so I see it in two separete things. > > 1-interaction model using CoAP > 2-content/data model generic.. > > > X > > > > > On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang wrote: > >> Xavi and all, >> >> When we talk about data model (DM), there are likely several points of >> view. For example: >> (1) DM is a set of messages, their format, and the behavior caused by the >> messages. >> (2) Besides (1), also includes the interface with specific protocol, e.g. >> URI in CoAP. >> >> From the point (1) of view, I agree Xavi. But, because URI is involved, >> so, it becomes CoAP Data Model. >> >> So, can we separate the common part of DM, i.e. point (1) from protocol >> specific part of DM, i.e. something like URI? >> >> What do you think? >> >> Qin >> >> >> >> On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen < >> xvilajosana@eecs.berkeley.edu> wrote: >> >>> HI all, >>> >>> I have a question raising from the minutes (sorry I could not connect >>> today). >>> >>> If title of the draft is "6TiSCH CoAP data Model" this means that in the >>> future we will have "6TiSCH *foo *data Model". Is that the direction we >>> want? Data Model is the way to represent message content (i.e what goes in >>> the payload and is used by 6top commands). Why is this specific to CoAP? >>> >>> Another aspect is interaction models, i.e message flows which in that >>> case they are related to the capabilities of the transport mechanism. >>> >>> just thoughts.. Sorry if I really go back to something you already >>> discussed and it is really clear. >>> >>> X >>> >>> >>> >>> >>> On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote: >>> >>>> All, >>>> >>>> You will find the minutes of the discussion about the models draft from >>>> this morning at >>>> https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also >>>> copy-pasted below). >>>> >>>> Thomas >>>> >>>> --- >>>> >>>> Minutes Webex 1 October 2013, 6TiSCH group, models draft team >>>> >>>> Note: timestamps in PDT. >>>> Taking notes *(using Etherpad)* >>>> >>>> 1. Thomas Watteyne >>>> 2. Raghuram Sudhaakar >>>> >>>> Present *(alphabetically)* >>>> >>>> 1. Alaeddine Weslati >>>> 2. Dan Romascanu >>>> 3. Diego Dujovne >>>> 4. Pascal Thubert >>>> 5. Pouria Zand >>>> 6. Qin Wang >>>> 7. R. Nabati >>>> 8. Raghuram Sudhaakar >>>> 9. Thomas Watteyne >>>> >>>> Agenda >>>> >>>> - Present pre-draft ToC *[Raghuram/Pouria]* >>>> - Discuss ToC >>>> - Define contents of each section >>>> >>>> Minutes >>>> >>>> - *[08.05]* meeting starts. >>>> - *Raghuram* shares pre-draft through Webex >>>> - goals for today: define ToC, define contents of each section, >>>> pick title >>>> - Scope is to include data and interaction model for CoAP. At a >>>> later stage, extract information model as separate draft. >>>> - "6TiSCH data model" or "6TiSCH CoAP data model"? >>>> - *[Thomas]* personal opinion: have CoAP in title >>>> - *[Qin]* why interaction model on top of information model? >>>> - *[Raghuram]* we want to define message flows between PCE and >>>> nodes. Data model is exact definition of payload. We had rough consensus on >>>> using name-value pairs. Interaction model for CoAP or RSVP in future >>>> drafts. Interaction model provides abstract model of interaction between >>>> entities. >>>> - *[Qin]* RFC3444, interaction flows should be part of the data >>>> model? We should not conflict with RFC3444. >>>> - *[Thomas]* We may want to split the interaction from this (data >>>> model) draft. >>>> - *[Qin]* Data definition and coding is common part. For me, >>>> experience with different definitions. Don't want another terminology. >>>> - *[Dan]* Not extremely familiar with 6TiSCH but experience with >>>> data and information model. In the IETF, we have clear definitions about >>>> data and information model. RFC3444 accepted and used as reference. There >>>> are differences, i.e. interaction model. We need to stick with RFC3444 as >>>> close as possible. >>>> - *[Raghuram]* Goal of interaction model is try to extract >>>> information model at a later stage. CoAP is one of the transports we are >>>> using today, but we can use other protocol at a later stage. We can name it >>>> differently later "interaction method". >>>> - *[Dan]* If we are inventing a new name, it does not matter too >>>> much. We are looking at mapping different transports. >>>> - *[Raghuram]* Goal of interaction model is to extract the >>>> information model. >>>> - *[Raghuram]* Change to ToC: remove interaction? >>>> - *[Thomas]* Could be replaced by example scenarios. >>>> - *[Pascal]* We have identified interaction at L2, L3 and L5. We >>>> need to have discussion about the models. >>>> - *[Raghuram]* Conclusion: in ToC, new section 3.4 with "example >>>> interactions". Message formats would be moved up to 3.3, name-value pairs >>>> proposed. >>>> - *[Thomas]* Rough consensus? >>>> - *[Qin]* what's the different between management and informational >>>> resources? >>>> - *[Raghuram]* management resources are R/W, informational >>>> resources are R (e.g. DAGrank). >>>> - *[Thomas]* We could walk through ToC? >>>> - *[Raghuram]* >>>> - 3.1 naming convention for URI schemes. For example, root >>>> resource "6t". Includes naming convention for resources under root resource. >>>> - 3.2 resource of 6top we want to expose, i.e. management and >>>> informational resource. >>>> - 3.2.4 user installed resources, e.g. subscribe for particular >>>> implementation. >>>> - *[Raghuram]* Should we have extensible resources? >>>> - *[Thomas]* Yes. >>>> - *[Qin]* What the functional description of a resource? Related to >>>> not only management but also informational resources. Should we put every >>>> description attached to every resource? Looking at the content, I can >>>> imagine a resource list, with a description for each one. Suggestion is to >>>> put description just following the resource list. >>>> - *[Raghuram]* Fine with that. >>>> - *[Pouria]* Other change "functional description of resources" >>>> will fold into 3.2.1 and 3.2.2. >>>> - *[Raghuram]* Resource is just the URI, linked to particular 6top >>>> variable. Methods would fall under description of resource. >>>> - *[Qin]* Description of the MIB? >>>> - *[Raghuram]* End-user should be able to get a specific >>>> parameters. Returned as name-value pairs. If an entity wants the entire >>>> MIB, we will have a separate resource. >>>> - *[Thomas]* Mapping of 6top commands included? >>>> - *[Raghuram]* Yes. Mapping of table of 6top commands presented in >>>> previous calls. >>>> - *[Pouria]* In resource management, information that can be >>>> written by PCE, or commands to be executed. >>>> - *[Raghuram]* Everything that change the TSCH schedule falls under >>>> the management resource. >>>> - *[Raghuram]* Section 4 will be moved up. A message format will be >>>> attached to each URI. >>>> - *[Thomas]* Map the attributes from minimal draft and the commands >>>> from 6top draft. >>>> - *[Raghuram]* That is the plan. >>>> - *[Thomas]* What are extensions? >>>> - *[Raghuram]* We don't want to define the URI for every attribute, >>>> we want to enable people to install a new resource with a definition. >>>> - *[Raghuram]* In that context, what are profiles? >>>> - *[Thomas]* Profile is overarching modification to basic behavior: >>>> e.g. adding resources or adding method to existing resource. >>>> - *[Qin]* Understanding about profile: resource is fixed, behavior >>>> of resource can be configurable. >>>> - *[Pascal]* +1 it's very important we are able to do add to basic >>>> behavior. >>>> - *[Diego]* How can we describe a trigger, e.g. number of >>>> measurements to average over. >>>> - *[Thomas]* Do we have a solution? >>>> - *[Raghuram]* Yes, complex triggers are defined using well-known >>>> formats. RFC already defines how to encode several thresholds. Output would >>>> be sent on CoAP response or observe notification. One generic method for >>>> any kind of trigger. >>>> - *[Raghuram]* In profiles, modify or add behavior. Add is easy. >>>> Profiles as a way to define extra sets of complex triggers. Discovery. What >>>> we could express as profiles are extra complex triggers. >>>> - *[Thomas]* What are the next steps? >>>> - *[Raghuram]* Updated version of draft by next week to discuss >>>> progress. Invite contributors. >>>> - *[Thomas]* Name of draft? >>>> - *[Raghuram]* What about "6TiSCH CoAP data model". >>>> - *[Thomas]* We need to know editor to create repository. >>>> - *[Raghuram]* AOB? >>>> >>>> No other business raised. >>>> >>>> - *[09.05]* meeting ends. >>>> >>>> >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch >>>> >>>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> > --089e01176cad6fa79404e7b2a677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Xavi,

    Agree!

    Q= in


    On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen <xv= ilajosana@eecs.berkeley.edu> wrote:
    Hi Qin,=

    I agree with you .. URI is to indentify the resource, i.e how do we= access a particular service offered by the management layer, I agree that = this should have CoAP name on it if this is bound to URI. then the data mod= el( the content of what we sent on the payload) this should be generic righ= t?

    so I see it in two separete things.

    1-interaction mo= del using CoAP
    2-content/data model generic..


    X




    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qin= wang@berkeley.edu> wrote:
    Xavi and all,

    When we talk about data model (DM), ther= e are likely several points of view. For example:
    (1) DM is a set of messages, their format, and the behavior caused by = the messages.
    (2) Besides (1), also includes the interface with specific protocol, e= .g. URI in CoAP.

    From the point (1) of view, I agr= ee Xavi. But, because URI is involved, so, it becomes CoAP Data Model.

    So, can we separate the common part of DM, i.e. point (= 1) from protocol specific part of DM, i.e. something like URI?
    What do you think?

    Qin



    =
    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosan= a Guillen <xvilajosana@eecs.berkeley.edu> wrote:=
    HI all,

    <= div>I have a question raising from the minutes (sorry I could not connect t= oday).

    If title of the draft is "6TiSCH CoAP data Model" = this means that in the future we will have "6TiSCH foo data Mod= el". Is that the direction we want? Data Model is the way to represent= message content (i.e what goes in the payload and is used by 6top commands= ). Why is this specific to CoAP?

    Another aspect is interaction models, i.e message flows whic= h in that case they are related to the capabilities of the transport mechan= ism.

    just thoughts..=A0 Sorry if I really go back to som= ething you already discussed and it is really clear.

    X




    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <wa= tteyne@eecs.berkeley.edu> wrote:
    All,<= div>
    You will find the minutes of the discussion about the mo= dels draft from this morning at=A0https://bitbucket.= org/6tsch/meetings/wiki/131001_webex_models_draft=A0(also copy-pasted b= elow).

    Thomas

    ---

    Minutes Webex 1 October 2013, 6TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Thomas Watte= yne
    2. Ragh= uram Sudhaakar

    Present=A0(alphabetically)

    1. Alaeddine We= slati
    2. Da= n Romascanu
    3. Diego Dujovne
    4. Pascal Thubert
    5. Pouria Zand
    6. Qin Wang
    7. R. Nabati
    8. Raghuram Sudhaakar
    9. Thomas Watteyne

    Agenda

    • Present pre-draft ToC=A0[R= aghuram/Pouria]
    • Discuss ToC
    • Define contents of each section

    Minutes

    • [08.05]=A0meeting starts.
    • Raghuram=A0shares pre-draft thr= ough Webex
      • goals for today: define ToC, define contents of each section, pick title
      • Scope is t= o include data and interaction model for CoAP. At a later stage, extract in= formation model as separate draft.
      • "6TiSCH= data model" or "6TiSCH CoAP data model"?
    • [Thomas]= =A0personal opinion: have CoAP in title
    • [Qin= ]=A0why interaction model on top of information model?
    • [Raghuram]<= /strong>=A0we want to define message flows between PCE and nodes. Data mode= l is exact definition of payload. We had rough consensus on using name-valu= e pairs. Interaction model for CoAP or RSVP in future drafts. Interaction m= odel provides abstract model of interaction between entities.
    • [Qin= ]=A0RFC3444, interaction flows should be part of the data model? W= e should not conflict with RFC3444.
    • [Thomas]=A0We may want to split the interaction from this = (data model) draft.
    • [Qin]=A0Data definition and coding is common p= art. For me, experience with different definitions. Don't want another = terminology.
    • [Dan= ]=A0Not extremely familiar with 6TiSCH but experience with data an= d information model. In the IETF, we have clear definitions about data and = information model. RFC3444 accepted and used as reference. There are differ= ences, i.e. interaction model. We need to stick with RFC3444 as close as po= ssible.
    • [Rag= huram]=A0Goal of interaction model is try to extract information m= odel at a later stage. CoAP is one of the transports we are using today, bu= t we can use other protocol at a later stage. We can name it differently la= ter "interaction method".
    • [Dan= ]=A0If we are inventing a new name, it does not matter too much. W= e are looking at mapping different transports.
    • [Raghuram]=A0Goal of interaction model is to extract the i= nformation model.
    • [Raghuram]=A0Change to ToC: remove interaction?<= /li>
    • [Tho= mas]=A0Could be replaced by example scenarios.
    • [Pascal]= =A0We have identified interaction at L2, L3 and L5. We need to have discuss= ion about the models.
    • [Rag= huram]=A0Conclusion: in ToC, new section 3.4 with "example in= teractions". Message formats would be moved up to 3.3, name-value pair= s proposed.
    • [Tho= mas]=A0Rough consensus?
    • [Qin]=A0what's the different = between management and informational resources?
    • [Rag= huram]=A0management resources are R/W, informational resources are= R (e.g. DAGrank).
    • [Thomas]=A0We could walk through ToC?
    • [Raghuram]<= ul style=3D"margin:0px;list-style-type:disc">
    • 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.
      • 3.2 resource o= f 6top we want to expose, i.e. management and informational resource.
    • 3.2.4 user i= nstalled resources, e.g. subscribe for particular implementation.
    =
  • [Raghuram]=A0Should we have extensible resources?
  • [Tho= mas]=A0Yes.
  • [Qin]=A0What the functional description of a = resource? Related to not only management but also informational resources. = Should we put every description attached to every resource? Looking at the = content, I can imagine a resource list, with a description for each one. Su= ggestion is to put description just following the resource list.
  • [Rag= huram]=A0Fine with that.
  • [Pouria]=A0Other change "fu= nctional description of resources" will fold into 3.2.1 and 3.2.2.
  • [Rag= huram]=A0Resource is just the URI, linked to particular 6top varia= ble. Methods would fall under description of resource.
  • [Qin]=A0Description of the MIB?
  • [Raghuram]=A0End-= user should be able to get a specific parameters. Returned as name-value pa= irs. If an entity wants the entire MIB, we will have a separate resource.
  • [Tho= mas]=A0Mapping of 6top commands included?
  • [Raghuram]=A0Ye= s. Mapping of table of 6top commands presented in previous calls.
  • [Pou= ria]=A0In resource management, information that can be written by = PCE, or commands to be executed.
  • [Raghuram]=A0Everything that change the TSCH schedule fall= s under the management resource.
  • [Raghuram]=A0Section 4 will be mo= ved up. A message format will be attached to each URI.
  • [Tho= mas]=A0Map the attributes from minimal draft and the commands from= 6top draft.
  • [Raghuram]=A0That is the plan.
  • [Thomas]=A0What ar= e extensions?
  • [Raghuram]=A0We don't want to define the URI for every= attribute, we want to enable people to install a new resource with a defin= ition.
  • [Raghuram]=A0In that context, what are profiles?
  • [Tho= mas]=A0Profile is overarching modification to basic behavior: e.g.= adding resources or adding method to existing resource.
  • [Qin]=A0Understanding about profile: resource is fixed, be= havior of resource can be configurable.
  • [Pascal]=A0+1 it's ver= y important we are able to do add to basic behavior.
  • [Die= go]=A0How can we describe a trigger, e.g. number of measurements t= o average over.
  • [Thomas]=A0Do we have a solution?
  • [Raghuram]=A0Ye= s, complex triggers are defined using well-known formats. RFC already defin= es how to encode several thresholds. Output would be sent on CoAP response = or observe notification. One generic method for any kind of trigger.
  • [Rag= huram]=A0In profiles, modify or add behavior. Add is easy. Profile= s as a way to define extra sets of complex triggers. Discovery. What we cou= ld express as profiles are extra complex triggers.
  • [Tho= mas]=A0What are the next steps?
  • [Raghuram]=A0Updated vers= ion of draft by next week to discuss progress. Invite contributors.
  • [Tho= mas]=A0Name of draft?
  • [Raghuram]=A0What about "6TiSC= H CoAP data model".
  • [Tho= mas]=A0We need to know editor to create repository.
  • [Raghuram]=A0AOB?

    No other business = raised.

  • [09.05]=A0meeting ends.


    • _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch




    --089e01176cad6fa79404e7b2a677-- From xvilajosana@berkeley.edu Tue Oct 1 14:51:21 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAA21E80C7 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 14:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmnfJtEeEu-7 for <6tsch@ietfa.amsl.com>; Tue, 1 Oct 2013 14:51:10 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7021E81FF for <6tsch@ietf.org>; Tue, 1 Oct 2013 14:51:01 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so93366pab.26 for <6tsch@ietf.org>; Tue, 01 Oct 2013 14:51:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=00ELp9K1vhoKPcJH5/E1tNTpaRApDJA/9q0bndnQxJs=; b=hPoO5Jp9F8mxzAARaa9LHfyiy/Xq8xRE5uCkExai5URV4YfjOyxw3Q9HX6uEqE0uDe oLaSKVcvk4ev6T537zbfSsbCYyhhAAmnBnjdlVSsLJ4VVaCNsXPvtcDpBHFUJyoKMhjQ 16CzRSjCXMcD+l+5/HTCYqoB6/ZZOUy8boJiJ7ErbAlsSO/JDN1CnelDhA1LQu1rgfHd JmHg6aAOTcL33CWVTOFxSLTUC1afnZu+kghpCNzm3CJ5gP6hAcv++LkEp+jIohpDgxVV xZLMKscxE0xtZYxSjN3OqzWnoOeEjqwJy9ChwzZwBhFR5G6oFGGQlqDxDPX6W7sSwlve QxUw== X-Gm-Message-State: ALoCoQn0KLnr1/EwTsbDhSyPu1YAbN0TM0xmjD6mHSKj+rrPBCB0qhwVoZipl5U6rioEHwPbM1q9 MIME-Version: 1.0 X-Received: by 10.68.170.133 with SMTP id am5mr31686590pbc.104.1380664260744; Tue, 01 Oct 2013 14:51:00 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Tue, 1 Oct 2013 14:51:00 -0700 (PDT) Date: Tue, 1 Oct 2013 14:51:00 -0700 Message-ID: From: Xavier Vilajosana Guillen To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b6d8ea4d0e7c304e7b4f26e Subject: [6tsch] renaming of minimal draft repository X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:51:21 -0000 --047d7b6d8ea4d0e7c304e7b4f26e Content-Type: text/plain; charset=ISO-8859-1 Hello, I renamed the minimal draft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please use the new URL from now on. https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Home I also addressed Thomas comments. thanks! Xavi --047d7b6d8ea4d0e7c304e7b4f26e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hello,

    I renamed the minimal d= raft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please use = the new URL from now on.

    https://bitbucket.org/6tsch/draft-vi= lajosana-6tisch-minimal/wiki/Home

    I also addressed Thomas comments.

    thanks!
    Xavi


    --047d7b6d8ea4d0e7c304e7b4f26e-- From maria-rita.palattella@uni.lu Wed Oct 2 01:05:45 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13E621E82C7 for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 01:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4sh2xqABHLT for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 01:05:35 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7421E8281 for <6tsch@ietf.org>; Wed, 2 Oct 2013 01:03:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1017,1371074400"; d="scan'208,217";a="26970244" Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 02 Oct 2013 10:03:22 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 10:03:21 +0200 From: Maria Rita PALATTELLA To: Qin Wang , Xavier Vilajosana Guillen Thread-Topic: [6tsch] minutes discussion models draft 1 October Thread-Index: AQHOvtNdjcYjZ8sjLkakmym5OyVZJJngDNoAgAADxICAAAFiAIAAAXyAgAD4MTA= Date: Wed, 2 Oct 2013 08:03:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.97] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_" MIME-Version: 1.0 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 08:05:45 -0000 --_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, Xavi, I do agree too about having separated sections within the same draft. As Thomas pointed out, it is better to not split things too much.. and keep= them together. It makes sense in this way. Maria Rita From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Q= in Wang Sent: Tuesday, October 01, 2013 9:06 PM To: Xavier Vilajosana Guillen Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Xavi, Agree! Qin On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Guillen > wrote: Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang > wrote: Xavi and all, When we talk about data model (DM), there are likely several points of view= . For example: (1) DM is a set of messages, their format, and the behavior caused by the m= essages. (2) Besides (1), also includes the interface with specific protocol, e.g. U= RI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol spe= cific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen > wrote: HI all, I have a question raising from the minutes (sorry I could not connect today= ). If title of the draft is "6TiSCH CoAP data Model" this means that in the fu= ture we will have "6TiSCH foo data Model". Is that the direction we want? D= ata Model is the way to represent message content (i.e what goes in the pay= load and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case = they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discuss= ed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne > wrote: All, You will find the minutes of the discussion about the models draft from thi= s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_= draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes (using Etherpad) 1. Thomas Watteyne 2. Raghuram Sudhaakar Present (alphabetically) 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda * Present pre-draft ToC [Raghuram/Pouria] * Discuss ToC * Define contents of each section Minutes * [08.05] meeting starts. * Raghuram shares pre-draft through Webex * goals for today: define ToC, define contents of each section, pick= title * Scope is to include data and interaction model for CoAP. At a late= r stage, extract information model as separate draft. * "6TiSCH data model" or "6TiSCH CoAP data model"? * [Thomas] personal opinion: have CoAP in title * [Qin] why interaction model on top of information model? * [Raghuram] we want to define message flows between PCE and nodes. = Data model is exact definition of payload. We had rough consensus on using = name-value pairs. Interaction model for CoAP or RSVP in future drafts. Inte= raction model provides abstract model of interaction between entities. * [Qin] RFC3444, interaction flows should be part of the data model?= We should not conflict with RFC3444. * [Thomas] We may want to split the interaction from this (data mode= l) draft. * [Qin] Data definition and coding is common part. For me, experienc= e with different definitions. Don't want another terminology. * [Dan] Not extremely familiar with 6TiSCH but experience with data = and information model. In the IETF, we have clear definitions about data an= d information model. RFC3444 accepted and used as reference. There are diff= erences, i.e. interaction model. We need to stick with RFC3444 as close as = possible. * [Raghuram] Goal of interaction model is try to extract information= model at a later stage. CoAP is one of the transports we are using today, = but we can use other protocol at a later stage. We can name it differently = later "interaction method". * [Dan] If we are inventing a new name, it does not matter too much.= We are looking at mapping different transports. * [Raghuram] Goal of interaction model is to extract the information= model. * [Raghuram] Change to ToC: remove interaction? * [Thomas] Could be replaced by example scenarios. * [Pascal] We have identified interaction at L2, L3 and L5. We need = to have discussion about the models. * [Raghuram] Conclusion: in ToC, new section 3.4 with "example inter= actions". Message formats would be moved up to 3.3, name-value pairs propos= ed. * [Thomas] Rough consensus? * [Qin] what's the different between management and informational re= sources? * [Raghuram] management resources are R/W, informational resources a= re R (e.g. DAGrank). * [Thomas] We could walk through ToC? * [Raghuram] * 3.1 naming convention for URI schemes. For example, root resource = "6t". Includes naming convention for resources under root resource. * 3.2 resource of 6top we want to expose, i.e. management and inform= ational resource. * 3.2.4 user installed resources, e.g. subscribe for particular impl= ementation. * [Raghuram] Should we have extensible resources? * [Thomas] Yes. * [Qin] What the functional description of a resource? Related to no= t only management but also informational resources. Should we put every des= cription attached to every resource? Looking at the content, I can imagine = a resource list, with a description for each one. Suggestion is to put desc= ription just following the resource list. * [Raghuram] Fine with that. * [Pouria] Other change "functional description of resources" will f= old into 3.2.1 and 3.2.2. * [Raghuram] Resource is just the URI, linked to particular 6top var= iable. Methods would fall under description of resource. * [Qin] Description of the MIB? * [Raghuram] End-user should be able to get a specific parameters. R= eturned as name-value pairs. If an entity wants the entire MIB, we will hav= e a separate resource. * [Thomas] Mapping of 6top commands included? * [Raghuram] Yes. Mapping of table of 6top commands presented in pre= vious calls. * [Pouria] In resource management, information that can be written b= y PCE, or commands to be executed. * [Raghuram] Everything that change the TSCH schedule falls under th= e management resource. * [Raghuram] Section 4 will be moved up. A message format will be at= tached to each URI. * [Thomas] Map the attributes from minimal draft and the commands fr= om 6top draft. * [Raghuram] That is the plan. * [Thomas] What are extensions? * [Raghuram] We don't want to define the URI for every attribute, we= want to enable people to install a new resource with a definition. * [Raghuram] In that context, what are profiles? * [Thomas] Profile is overarching modification to basic behavior: e.= g. adding resources or adding method to existing resource. * [Qin] Understanding about profile: resource is fixed, behavior of = resource can be configurable. * [Pascal] +1 it's very important we are able to do add to basic beh= avior. * [Diego] How can we describe a trigger, e.g. number of measurements= to average over. * [Thomas] Do we have a solution? * [Raghuram] Yes, complex triggers are defined using well-known form= ats. RFC already defines how to encode several thresholds. Output would be = sent on CoAP response or observe notification. One generic method for any k= ind of trigger. * [Raghuram] In profiles, modify or add behavior. Add is easy. Profi= les as a way to define extra sets of complex triggers. Discovery. What we c= ould express as profiles are extra complex triggers. * [Thomas] What are the next steps? * [Raghuram] Updated version of draft by next week to discuss progre= ss. Invite contributors. * [Thomas] Name of draft? * [Raghuram] What about "6TiSCH CoAP data model". * [Thomas] We need to know editor to create repository. * [Raghuram] AOB? No other business raised. * [09.05] meeting ends. _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Qin, Xavi,<= /span>

    I do agree too about havi= ng separated sections within the same draft.

    As Thomas pointed out, it= is better to not split things too much.. and keep them together. It makes = sense in this way.

    Maria Rita

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Qin Wang
    Sent: Tuesday, October 01, 2013 9:06 PM
    To: Xavier Vilajosana Guillen
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Xavi,

     

    Agree!

     

    Qin

     

    On Wed, Oct 2, 2013 at 3:01 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    Hi Qin,

    I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right?

    so I see it in two se= parete things.

    1-interaction model using CoAP

    2-content/data model = generic..

     

    X

     

     

    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote:

    Xavi and all,

     

    When we talk about data model (DM), there are likely= several points of view. For example:

    (1) DM is a set of messages, their format, and the b= ehavior caused by the messages.

    (2) Besides (1), also includes the interface with sp= ecific protocol, e.g. URI in CoAP.

     

    From the point (1) of view, I agree Xavi. But, becau= se URI is involved, so, it becomes CoAP Data Model.

     

    So, can we separate the common part of DM, i.e. poin= t (1) from protocol specific part of DM, i.e. something like URI?

     

    What do you think?

     

    Qin<= /p>

     

     

    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    HI all,

    I have a question rai= sing from the minutes (sorry I could not connect today).

    If title of the draft= is "6TiSCH CoAP data Model" this means that in the future we wil= l have "6TiSCH foo data Model". Is that the direction we want? Data Model is t= he way to represent message content (i.e what goes in the payload and is us= ed by 6top commands). Why is this specific to CoAP?

    Another aspect is int= eraction models, i.e message flows which in that case they are related to t= he capabilities of the transport mechanism.

    just thoughts.. = Sorry if I really go back to something you already discussed and it is rea= lly clear.

    X

     

     

     

    All,

     

    You will find the minutes of the discussion about th= e models draft from this morning at https://bit= bucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below).

     

    Thomas

     

    ---

     

    Minutes Webex 1 October 2013, 6= TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes (using Etherpad= )

    1.     = Thomas Watteyne

    2.     = Raghuram Sudhaakar

    Present (alphabetically)

    1.     = Alaeddine Weslati

    2.     = Dan Romascanu

    3.     = Diego Dujovne

    4.     = Pascal Thubert

    5.     = Pouria Zand

    6.     = Qin Wang

    7.     = R. Nabati

    8.     = Raghuram Sudhaakar

    9.     = Thomas Watteyne

    Agenda

    ·    =     = Present pre-draft ToC [Raghuram/Pouria]

    ·    =     = Discuss ToC

    ·    =     = Define contents of each section

    Minutes

    ·    =     [08.05] me= eting starts.

    ·    =     Raghuram shares pre-d= raft through Webex

    ·    =     = goals for today: define ToC, define contents of each section, pick title

    ·    =     = Scope is to include data and interaction model for CoAP. At a later stage, = extract information model as separate draft.

    ·    =     = "6TiSCH data model" or "6TiSCH CoAP data model"?

    ·    =     [Thomas] personal opi= nion: have CoAP in title

    ·    =     [Qin] why interaction= model on top of information model?

    ·    =     [Raghuram]<= /span> we want to= define message flows between PCE and nodes. Data model is exact definition of pay= load. We had rough consensus on using name-value pairs. Interaction model f= or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.

    ·    =     [Qin] RFC3444, intera= ction flows should be part of the data model? We should not conflict with RFC344= 4.

    ·    =     [Thomas] We may want = to split the interaction from this (data model) draft.

    ·    =     [Qin] Data definition= and coding is common part. For me, experience with different definitions. Don't want = another terminology.

    ·    =     [Dan] Not extremely f= amiliar with 6TiSCH but experience with data and information model. In the IETF, w= e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n= eed to stick with RFC3444 as close as possible.

    ·    =     [Raghuram]<= /span> Goal of in= teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late= r stage. We can name it differently later "interaction method".

    ·    =     [Dan] If we are inven= ting a new name, it does not matter too much. We are looking at mapping different= transports.

    ·    =     [Raghuram]<= /span> Goal of in= teraction model is to extract the information model.

    ·    =     [Raghuram]<= /span> Change to = ToC: remove interaction?

    ·    =     [Thomas] Could be rep= laced by example scenarios.

    ·    =     [Pascal] We have iden= tified interaction at L2, L3 and L5. We need to have discussion about the models.=

    ·    =     [Raghuram]<= /span> Conclusion= : in ToC, new section 3.4 with "example interactions". Message formats wou= ld be moved up to 3.3, name-value pairs proposed.

    ·    =     [Thomas] Rough consen= sus?

    ·    =     [Qin] what's the diff= erent between management and informational resources?

    ·    =     [Raghuram]<= /span> management= resources are R/W, informational resources are R (e.g. DAGrank).

    ·    =     [Thomas] We could wal= k through ToC?

    ·    =     [Raghuram]<= /span>

    ·    =     = 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.

    ·    =     = 3.2 resource of 6top we want to expose, i.e. management and informational r= esource.

    ·    =     = 3.2.4 user installed resources, e.g. subscribe for particular implementatio= n.

    ·    =     [Raghuram]<= /span> Should we = have extensible resources?

    ·    =     [Thomas] Yes.

    ·    =     [Qin] What the functi= onal description of a resource? Related to not only management but also informational resou= rces. Should we put every description attached to every resource? Looking a= t the content, I can imagine a resource list, with a description for each o= ne. Suggestion is to put description just following the resource list.

    ·    =     [Raghuram]<= /span> Fine with = that.

    ·    =     [Pouria] Other change= "functional description of resources" will fold into 3.2.1 and 3.2.2.<= /span>

    ·    =     [Raghuram]<= /span> Resource i= s just the URI, linked to particular 6top variable. Methods would fall under desc= ription of resource.

    ·    =     [Qin] Description of = the MIB?

    ·    =     [Raghuram]<= /span> End-user s= hould be able to get a specific parameters. Returned as name-value pairs. If an = entity wants the entire MIB, we will have a separate resource.

    ·    =     [Thomas] Mapping of 6= top commands included?

    ·    =     [Raghuram]<= /span> Yes. Mappi= ng of table of 6top commands presented in previous calls.

    ·    =     [Pouria] In resource = management, information that can be written by PCE, or commands to be executed.

    ·    =     [Raghuram]<= /span> Everything= that change the TSCH schedule falls under the management resource.

    ·    =     [Raghuram]<= /span> Section 4 = will be moved up. A message format will be attached to each URI.=

    ·    =     [Thomas] Map the attr= ibutes from minimal draft and the commands from 6top draft.

    ·    =     [Raghuram]<= /span> That is th= e plan.

    ·    =     [Thomas] What are ext= ensions?

    ·    =     [Raghuram]<= /span> We don't w= ant to define the URI for every attribute, we want to enable people to install a = new resource with a definition.

    ·    =     [Raghuram]<= /span> In that co= ntext, what are profiles?

    ·    =     [Thomas] Profile is o= verarching modification to basic behavior: e.g. adding resources or adding method to = existing resource.

    ·    =     [Qin] Understanding a= bout profile: resource is fixed, behavior of resource can be configurable.

    ·    =     [Pascal] +1 it's = very important we are able to do add to basic behavior.

    ·    =     [Diego] How can we de= scribe a trigger, e.g. number of measurements to average over.<= /h1>

    ·    =     [Thomas] Do we have a= solution?

    ·    =     [Raghuram]<= /span> Yes, compl= ex triggers are defined using well-known formats. RFC already defines how to encode se= veral thresholds. Output would be sent on CoAP response or observe notifica= tion. One generic method for any kind of trigger.

    ·    =     [Raghuram]<= /span> In profile= s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co= mplex triggers. Discovery. What we could express as profiles are extra comp= lex triggers.

    ·    =     [Thomas] What are the= next steps?

    ·    =     [Raghuram]<= /span> Updated ve= rsion of draft by next week to discuss progress. Invite contributors.=

    ·    =     [Thomas] Name of draf= t?

    ·    =     [Raghuram]<= /span> What about= "6TiSCH CoAP data model".

    ·    =     [Thomas] We need to k= now editor to create repository.

    ·    =     [Raghuram]<= /span> AOB?<= /o:p>

    No other business raised.

    ·    =     [09.05] me= eting ends.

     

    _____________________= __________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

     

    --_000_F085911F642A6847987ADA23E611780D1859D09Choshiunilux_-- From dromasca@avaya.com Wed Oct 2 04:07:56 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D429211E820E for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 04:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2lfcngo9pK9 for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 04:07:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5A521F9AE3 for <6tsch@ietf.org>; Wed, 2 Oct 2013 04:07:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOr9S1KHCzI1/2dsb2JhbABYDoI1IyE4UsEVgRgWdIIlAQEBAQMBAQEPG0EEAgUQAgEIDQQEAQELAhQBBgcnCxQJCAIEAQ0FCBMHh2QBC6AEnGcTBI8gLQQGAQaDGYEEA55ZiyGCZT+CKg X-IronPort-AV: E=Sophos;i="4.90,1018,1371096000"; d="scan'208,217";a="30260466" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Oct 2013 07:07:14 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Oct 2013 06:58:23 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Wed, 2 Oct 2013 13:07:05 +0200 From: "Romascanu, Dan (Dan)" To: "xvilajosana@eecs.berkeley.edu" , Qin Wang Thread-Topic: [6tsch] minutes discussion models draft 1 October Thread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2Q Date: Wed, 2 Oct 2013 11:07:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128EF169@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_" MIME-Version: 1.0 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 11:07:57 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I made this observation in the call yesterday. It would be good to use the = terminology as defined in RFC 3444 in what concerns information models and = data models. Information models define objects and the relation between the= m in a generic manner and are protocol neutral. Data models are less abstra= ct, include implementation- and protocol-specific details, and are usually = associated to data modeling languages. Using other terms, or worse - the sa= me terms in a different manner - is confusing. I suggest to add to the document a section of terminology which either poin= ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'. Regards, Dan From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X= avier Vilajosana Guillen Sent: Tuesday, October 01, 2013 10:01 PM To: Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang > wrote: Xavi and all, When we talk about data model (DM), there are likely several points of view= . For example: (1) DM is a set of messages, their format, and the behavior caused by the m= essages. (2) Besides (1), also includes the interface with specific protocol, e.g. U= RI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol spe= cific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen > wrote: HI all, I have a question raising from the minutes (sorry I could not connect today= ). If title of the draft is "6TiSCH CoAP data Model" this means that in the fu= ture we will have "6TiSCH foo data Model". Is that the direction we want? D= ata Model is the way to represent message content (i.e what goes in the pay= load and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case = they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discuss= ed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne > wrote: All, You will find the minutes of the discussion about the models draft from thi= s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_= draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes (using Etherpad) 1. Thomas Watteyne 2. Raghuram Sudhaakar Present (alphabetically) 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda * Present pre-draft ToC [Raghuram/Pouria] * Discuss ToC * Define contents of each section Minutes * [08.05] meeting starts. * Raghuram shares pre-draft through Webex * goals for today: define ToC, define contents of each section, pic= k title * Scope is to include data and interaction model for CoAP. At a lat= er stage, extract information model as separate draft. * "6TiSCH data model" or "6TiSCH CoAP data model"? * [Thomas] personal opinion: have CoAP in title * [Qin] why interaction model on top of information model? * [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int= eraction model provides abstract model of interaction between entities. * [Qin] RFC3444, interaction flows should be part of the data model= ? We should not conflict with RFC3444. * [Thomas] We may want to split the interaction from this (data mod= el) draft. * [Qin] Data definition and coding is common part. For me, experien= ce with different definitions. Don't want another terminology. * [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a= nd information model. RFC3444 accepted and used as reference. There are dif= ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible. * [Raghuram] Goal of interaction model is try to extract informatio= n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method". * [Dan] If we are inventing a new name, it does not matter too much= . We are looking at mapping different transports. * [Raghuram] Goal of interaction model is to extract the informatio= n model. * [Raghuram] Change to ToC: remove interaction? * [Thomas] Could be replaced by example scenarios. * [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models. * [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte= ractions". Message formats would be moved up to 3.3, name-value pairs propo= sed. * [Thomas] Rough consensus? * [Qin] what's the different between management and informational r= esources? * [Raghuram] management resources are R/W, informational resources = are R (e.g. DAGrank). * [Thomas] We could walk through ToC? * [Raghuram] * 3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource. * 3.2 resource of 6top we want to expose, i.e. management and infor= mational resource. * 3.2.4 user installed resources, e.g. subscribe for particular imp= lementation. * [Raghuram] Should we have extensible resources? * [Thomas] Yes. * [Qin] What the functional description of a resource? Related to n= ot only management but also informational resources. Should we put every de= scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des= cription just following the resource list. * [Raghuram] Fine with that. * [Pouria] Other change "functional description of resources" will = fold into 3.2.1 and 3.2.2. * [Raghuram] Resource is just the URI, linked to particular 6top va= riable. Methods would fall under description of resource. * [Qin] Description of the MIB? * [Raghuram] End-user should be able to get a specific parameters. = Returned as name-value pairs. If an entity wants the entire MIB, we will ha= ve a separate resource. * [Thomas] Mapping of 6top commands included? * [Raghuram] Yes. Mapping of table of 6top commands presented in pr= evious calls. * [Pouria] In resource management, information that can be written = by PCE, or commands to be executed. * [Raghuram] Everything that change the TSCH schedule falls under t= he management resource. * [Raghuram] Section 4 will be moved up. A message format will be a= ttached to each URI. * [Thomas] Map the attributes from minimal draft and the commands f= rom 6top draft. * [Raghuram] That is the plan. * [Thomas] What are extensions? * [Raghuram] We don't want to define the URI for every attribute, w= e want to enable people to install a new resource with a definition. * [Raghuram] In that context, what are profiles? * [Thomas] Profile is overarching modification to basic behavior: e= .g. adding resources or adding method to existing resource. * [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable. * [Pascal] +1 it's very important we are able to do add to basic be= havior. * [Diego] How can we describe a trigger, e.g. number of measurement= s to average over. * [Thomas] Do we have a solution? * [Raghuram] Yes, complex triggers are defined using well-known for= mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any = kind of trigger. * [Raghuram] In profiles, modify or add behavior. Add is easy. Prof= iles as a way to define extra sets of complex triggers. Discovery. What we = could express as profiles are extra complex triggers. * [Thomas] What are the next steps? * [Raghuram] Updated version of draft by next week to discuss progr= ess. Invite contributors. * [Thomas] Name of draft? * [Raghuram] What about "6TiSCH CoAP data model". * [Thomas] We need to know editor to create repository. * [Raghuram] AOB? No other business raised. * [09.05] meeting ends. _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

     <= /p> 

    I made this observation in the call yesterd=
ay. It would be good to use the terminology as defined in RFC 3444 in what =
concerns information models and data models. Information models define obje=
cts and the relation between them in a generic manner and are protocol neut=
ral. Data models are less abstract, inclu=
de implementation- and protocol-specific details, and are usually associate=
d to data modeling languages. Using other terms, or worse – the same =
terms in a different manner – is confusing. 
     
    I suggest to add to the document a section =
of terminology which either points to RFC 3444, or describes the difference=
s from what is described in 3444 and also explains other terms like ‘=
interaction model’. 
     
    Regards,
     
    Dan
     

     <= /p>

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 10:01 PM
    To: Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi Qin,

    I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right?

    so I see it in two se= parete things.

    1-interaction model using CoAP

    2-content/data model = generic..

     

    X

     

     

    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote:

    Xavi and all,

     

    When we talk about data model (DM), there are likely= several points of view. For example:

    (1) DM is a set of messages, their format, and the b= ehavior caused by the messages.

    (2) Besides (1), also includes the interface with sp= ecific protocol, e.g. URI in CoAP.

     

    From the point (1) of view, I agree Xavi. But, becau= se URI is involved, so, it becomes CoAP Data Model.

     

    So, can we separate the common part of DM, i.e. poin= t (1) from protocol specific part of DM, i.e. something like URI?

     

    What do you think?

     

    Qin<= /p>

     

     

    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    HI all,

    I have a question rai= sing from the minutes (sorry I could not connect today).

    If title of the draft= is "6TiSCH CoAP data Model" this means that in the future we wil= l have "6TiSCH foo data Model". Is that the direction we want? Data Model is t= he way to represent message content (i.e what goes in the payload and is us= ed by 6top commands). Why is this specific to CoAP?

    Another aspect is int= eraction models, i.e message flows which in that case they are related to t= he capabilities of the transport mechanism.

    just thoughts.. = Sorry if I really go back to something you already discussed and it is rea= lly clear.

    X

     

     

     

    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    All,

     

    You will find the minutes of the discussion about th= e models draft from this morning at https://bit= bucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below).

     

    Thomas

     

    ---

     

    Minutes Webex 1 October 2013, 6= TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes (using Etherpad= )

    1.    Thomas Watteyne

    2.    Raghuram Sudhaakar

    Present (alphabetically)

    1.    Alaeddine Weslati

    2.    Dan Romascanu

    3.    Diego Dujovne

    4.    Pascal Thubert

    5.    Pouria Zand

    6.    Qin Wang

    7.    R. Nabati

    8.    Raghuram Sudhaakar

    9.    Thomas Watteyne

    Agenda

    ·    =      Present pre-draft ToC [Raghuram/Pouria]<= /em>

    ·    =      Discuss ToC

    ·    =      Define contents of each section<= /h1>

    Minutes

    ·    =      [08.05] meeting starts.

    ·    =      Raghuram shares pre-draft through Webex

    ·    =      goals for today: define ToC, define contents of ea= ch section, pick title

    ·    =      Scope is to include data and interaction model for= CoAP. At a later stage, extract information model as separate draft.

    ·    =      "6TiSCH data model" or "6TiSCH CoAP= data model"?

    ·    =      [Thomas] personal opinion: have CoAP in title

    ·    =      [Qin] why interaction model on top of information model?

    ·    =      [Raghuram] we want to define message flows between PCE and nodes. Data model is exact de= finition of payload. We had rough consensus on using name-value pairs. Inte= raction model for CoAP or RSVP in future drafts. Interaction model provides= abstract model of interaction between entities.

    ·    =      [Qin] RFC3444, interaction flows should be part of the data model? We should not conflict= with RFC3444.

    ·    =      [Thomas] We may want to split the interaction from this (data model) draft.=

    ·    =      [Qin] Data definition and coding is common part. For me, experience with different de= finitions. Don't want another terminology.

    ·    =      [Dan] Not extremely familiar with 6TiSCH but experience with data and information mo= del. In the IETF, we have clear definitions about data and information mode= l. RFC3444 accepted and used as reference. There are differences, i.e. inte= raction model. We need to stick with RFC3444 as close as possible.

    ·    =      [Raghuram] Goal of interaction model is try to extract information model at a later stage.= CoAP is one of the transports we are using today, but we can use other pro= tocol at a later stage. We can name it differently later "interaction = method".

    ·    =      [Dan] If we are inventing a new name, it does not matter too much. We are looking a= t mapping different transports.

    ·    =      [Raghuram] Goal of interaction model is to extract the information model.

    ·    =      [Raghuram] Change to ToC: remove interaction?

    ·    =      [Thomas] Could be replaced by example scenarios.

    ·    =      [Pascal] We have identified interaction at L2, L3 and L5. We need to have discussion a= bout the models.

    ·    =      [Raghuram] Conclusion: in ToC, new section 3.4 with "example interactions". Message for= mats would be moved up to 3.3, name-value pairs proposed.=

    ·    =      [Thomas] Rough consensus?

    ·    =      [Qin] what's the different between management and informational resources?

    ·    =      [Raghuram] management resources are R/W, informational resources are R (e.g. DAGrank).

    ·    =      [Thomas] We could walk through ToC?

    ·    =      [Raghuram]

    ·    =      3.1 naming convention for URI schemes. For example= , root resource "6t". Includes naming convention for resources under root resource.

    ·    =      3.2 resource of 6top we want to expose, i.e. manag= ement and informational resource.

    ·    =      3.2.4 user installed resources, e.g. subscribe for= particular implementation.

    ·    =      [Raghuram] Should we have extensible resources?

    ·    =      [Thomas] Yes.

    ·    =      [Qin] What the functional description of a resource? Related to not only management b= ut also informational resources. Should we put every description attached t= o every resource? Looking at the content, I can imagine a resource list, wi= th a description for each one. Suggestion is to put description just following the resource list.<= /h1>

    ·    =      [Raghuram] Fine with that.

    ·    =      [Pouria] Other change "functional description of resources" will fold into 3.2.= 1 and 3.2.2.

    ·    =      [Raghuram] Resource is just the URI, linked to particular 6top variable. Methods would fall un= der description of resource.

    ·    =      [Qin] Description of the MIB?

    ·    =      [Raghuram] End-user should be able to get a specific parameters. Returned as name-value pairs.= If an entity wants the entire MIB, we will have a separate resource.<= /o:p>

    ·    =      [Thomas] Mapping of 6top commands included?

    ·    =      [Raghuram] Yes. Mapping of table of 6top commands presented in previous calls.<= /span>

    ·    =      [Pouria] In resource management, information that can be written by PCE, or commands t= o be executed.

    ·    =      [Raghuram] Everything that change the TSCH schedule falls under the management resource.

    ·    =      [Raghuram] Section 4 will be moved up. A message format will be attached to each URI.

    ·    =      [Thomas] Map the attributes from minimal draft and the commands from 6top draft.

    ·    =      [Raghuram] That is the plan.

    ·    =      [Thomas] What are extensions?

    ·    =      [Raghuram] We don't want to define the URI for every attribute, we want to enable people= to install a new resource with a definition.

    ·    =      [Raghuram] In that context, what are profiles?

    ·    =      [Thomas] Profile is overarching modification to basic behavior: e.g. adding resources or ad= ding method to existing resource.

    ·    =      [Qin] Understanding about profile: resource is fixed, behavior of resource can be configurable= .

    ·    =      [Pascal] +1 it's very important we are able to do add to basic behavior.

    ·    =      [Diego] How can we describe a trigger, e.g. number of measurements to average over.

    ·    =      [Thomas] Do we have a solution?

    ·    =      [Raghuram] Yes, complex triggers are defined using well-known formats. RFC already defines= how to encode several thresholds. Output would be sent on CoAP response or= observe notification. One generic method for any kind of trigger.

    ·    =      [Raghuram] In profiles, modify or add behavior. Add is easy. Profiles as a way to define= extra sets of complex triggers. Discovery. What we could express as profil= es are extra complex triggers.

    ·    =      [Thomas] What are the next steps?

    ·    =      [Raghuram] Updated version of draft by next week to discuss progress. Invite contributors.

    ·    =      [Thomas] Name of draft?

    ·    =      [Raghuram] What about "6TiSCH CoAP data model".

    ·    =      [Thomas] We need to know editor to create repository.

    ·    =      [Raghuram] AOB?

    No other business raised.

    ·    =      [09.05] meeting ends.

     

    _____________________= __________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA128EF169AZFFEXMB04globa_-- From pthubert@cisco.com Wed Oct 2 07:14:19 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EC021F898A for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 07:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ1n0Hc+5EeJ for <6tsch@ietfa.amsl.com>; Wed, 2 Oct 2013 07:14:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 853CD21F8C20 for <6tsch@ietf.org>; Wed, 2 Oct 2013 07:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=95049; q=dns/txt; s=iport; t=1380723164; x=1381932764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z+eVV/22rqvQ10grDoGFcW+SzIL9kRPUlgURiONyVlQ=; b=PpSmiXVHfQwh2x/dndUyxnsOeXzQ4sDRKeBiuKK+8HloGaeLkb+iqAte BTFftJvTC+0SLGy2ra1bq1WTBSThrdq6MpgJ22LZx/h7wyqSe8DGx4AG5 FsqzJ06gMm0qJBj8BYyhokoSj4rpTCWDH3ZxC9N9JtUQirXMteE1sj1Pe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAAcpTFKtJXG8/2dsb2JhbABYDoI1RDhSwRaBGBZ0giUBAQEEAQEBFxNBBAIFEAIBCBEEAQELAhQBBgcnCxQJCAIEAQ0FCBOHawy9SwSOE4ENLQQGAQaDGYEEA4VPpDGCZT+BaUE X-IronPort-AV: E=Sophos;i="4.90,1019,1371081600"; d="scan'208,217";a="266933762" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 02 Oct 2013 14:12:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r92ECXTI016129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 14:12:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 2 Oct 2013 09:12:33 -0500 From: "Pascal Thubert (pthubert)" To: "Romascanu, Dan (Dan)" , "xvilajosana@eecs.berkeley.edu" , Qin Wang Thread-Topic: [6tsch] minutes discussion models draft 1 October Thread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2QgAATqCA= Date: Wed, 2 Oct 2013 14:12:32 +0000 Deferred-Delivery: Wed, 2 Oct 2013 14:12:00 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA128EF169@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128EF169@AZ-FFEXMB04.global.avaya.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.17] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:14:19 -0000 --_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dan; I understand that we want to stick to RFC 3444 for Data and Information mod= els. The limit to overcome is probably our understanding and practice of th= at specification. In addition to the static representation, we have a need to discuss the dyn= amic view of the 6TiSCH operation and we are looking for appropriate terms. At ISA100.11a this abstraction is often referred to as a "communication par= adigm". Examples there are client-server, publish-subscribe and source-sink= , which is a MP to MP distribution for alarms and alerts. We could reuse th= at terminology, with, in our case, the additions of classes for end-to-end = (app layer), hop-by-hop (network layer) and one hop (Link layer) interactio= ns. It seems from the discussion that the applied model for a "communication pa= radigm" could be called an "interaction model". For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de= vices. Additionally, we would propose a layer 5 interaction model to transport tha= t data. That interaction model would probably implement the client-server a= nd eventually the source-sink paradigms with CoAP methods. But that would b= e an example not a limitation, since there can be other ways to transport t= hat data, and other ways for format the bits and bytes. Does that make sense? Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of R= omascanu, Dan (Dan) Sent: mercredi 2 octobre 2013 13:07 To: xvilajosana@eecs.berkeley.edu; Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi, I made this observation in the call yesterday. It would be good to use the = terminology as defined in RFC 3444 in what concerns information models and = data models. Information models define objects and the relation between the= m in a generic manner and are protocol neutral. Data models are less abstra= ct, include implementation- and protocol-specific details, and are usually = associated to data modeling languages. Using other terms, or worse - the sa= me terms in a different manner - is confusing. I suggest to add to the document a section of terminology which either poin= ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'. Regards, Dan From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen Sent: Tuesday, October 01, 2013 10:01 PM To: Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang > wrote: Xavi and all, When we talk about data model (DM), there are likely several points of view= . For example: (1) DM is a set of messages, their format, and the behavior caused by the m= essages. (2) Besides (1), also includes the interface with specific protocol, e.g. U= RI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol spe= cific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen > wrote: HI all, I have a question raising from the minutes (sorry I could not connect today= ). If title of the draft is "6TiSCH CoAP data Model" this means that in the fu= ture we will have "6TiSCH foo data Model". Is that the direction we want? D= ata Model is the way to represent message content (i.e what goes in the pay= load and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case = they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discuss= ed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne > wrote: All, You will find the minutes of the discussion about the models draft from thi= s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_= draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes (using Etherpad) 1. Thomas Watteyne 2. Raghuram Sudhaakar Present (alphabetically) 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda * Present pre-draft ToC [Raghuram/Pouria] * Discuss ToC * Define contents of each section Minutes * [08.05] meeting starts. * Raghuram shares pre-draft through Webex * goals for today: define ToC, define contents of each section, pic= k title * Scope is to include data and interaction model for CoAP. At a lat= er stage, extract information model as separate draft. * "6TiSCH data model" or "6TiSCH CoAP data model"? * [Thomas] personal opinion: have CoAP in title * [Qin] why interaction model on top of information model? * [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int= eraction model provides abstract model of interaction between entities. * [Qin] RFC3444, interaction flows should be part of the data model= ? We should not conflict with RFC3444. * [Thomas] We may want to split the interaction from this (data mod= el) draft. * [Qin] Data definition and coding is common part. For me, experien= ce with different definitions. Don't want another terminology. * [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a= nd information model. RFC3444 accepted and used as reference. There are dif= ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible. * [Raghuram] Goal of interaction model is try to extract informatio= n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method". * [Dan] If we are inventing a new name, it does not matter too much= . We are looking at mapping different transports. * [Raghuram] Goal of interaction model is to extract the informatio= n model. * [Raghuram] Change to ToC: remove interaction? * [Thomas] Could be replaced by example scenarios. * [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models. * [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte= ractions". Message formats would be moved up to 3.3, name-value pairs propo= sed. * [Thomas] Rough consensus? * [Qin] what's the different between management and informational r= esources? * [Raghuram] management resources are R/W, informational resources = are R (e.g. DAGrank). * [Thomas] We could walk through ToC? * [Raghuram] * 3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource. * 3.2 resource of 6top we want to expose, i.e. management and infor= mational resource. * 3.2.4 user installed resources, e.g. subscribe for particular imp= lementation. * [Raghuram] Should we have extensible resources? * [Thomas] Yes. * [Qin] What the functional description of a resource? Related to n= ot only management but also informational resources. Should we put every de= scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des= cription just following the resource list. * [Raghuram] Fine with that. * [Pouria] Other change "functional description of resources" will = fold into 3.2.1 and 3.2.2. * [Raghuram] Resource is just the URI, linked to particular 6top va= riable. Methods would fall under description of resource. * [Qin] Description of the MIB? * [Raghuram] End-user should be able to get a specific parameters. = Returned as name-value pairs. If an entity wants the entire MIB, we will ha= ve a separate resource. * [Thomas] Mapping of 6top commands included? * [Raghuram] Yes. Mapping of table of 6top commands presented in pr= evious calls. * [Pouria] In resource management, information that can be written = by PCE, or commands to be executed. * [Raghuram] Everything that change the TSCH schedule falls under t= he management resource. * [Raghuram] Section 4 will be moved up. A message format will be a= ttached to each URI. * [Thomas] Map the attributes from minimal draft and the commands f= rom 6top draft. * [Raghuram] That is the plan. * [Thomas] What are extensions? * [Raghuram] We don't want to define the URI for every attribute, w= e want to enable people to install a new resource with a definition. * [Raghuram] In that context, what are profiles? * [Thomas] Profile is overarching modification to basic behavior: e= .g. adding resources or adding method to existing resource. * [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable. * [Pascal] +1 it's very important we are able to do add to basic be= havior. * [Diego] How can we describe a trigger, e.g. number of measurement= s to average over. * [Thomas] Do we have a solution? * [Raghuram] Yes, complex triggers are defined using well-known for= mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any = kind of trigger. * [Raghuram] In profiles, modify or add behavior. Add is easy. Prof= iles as a way to define extra sets of complex triggers. Discovery. What we = could express as profiles are extra complex triggers. * [Thomas] What are the next steps? * [Raghuram] Updated version of draft by next week to discuss progr= ess. Invite contributors. * [Thomas] Name of draft? * [Raghuram] What about "6TiSCH CoAP data model". * [Thomas] We need to know editor to create repository. * [Raghuram] AOB? No other business raised. * [09.05] meeting ends. _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Dan;

     <= /p>

    I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom= e is probably our understanding and practice of that specification.

     <= /p>

    In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o= peration and we are looking for appropriate terms.   <= /span>

     <= /p>

    At ISA100.11a this abstra= ction is often referred to as a “communication paradigm”. Examp= les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term= inology, with, in our case, the additions of classes for end-to-end (app la= yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb= sp;

     <= /p>

    It seems from the discuss= ion that the applied model for a “communication paradigm” could= be called an “interaction model”.

     <= /p>

    For this particular draft= , I’d then expect something like a Yang data model that can be trivia= lly translated in CBOR for consumption by constrained devices.

     <= /p>

    Additionally, we would pr= opose a layer 5 interaction model to transport that data. That interaction = model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example = not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.

     <= /p>

    Does that make sense?

     <= /p>

    Pascal

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
    Sent: mercredi 2 octobre 2013 13:07
    To: xvilajosana@eecs.berkeley.edu; Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi,

     <= /p> 

    I made this observation in the call yesterd=
ay. It would be good to use the terminology as defined in RFC 3444 in what =
concerns information models and data models. Information models define obje=
cts and the relation between them in a generic manner and are protocol neut=
ral. Data models are less abstract, include implementation- and protocol-sp=
ecific details, and are usually associated to data modeling languages. Usin=
g other terms, or worse – the same terms in a different manner –=
; is confusing. 
     
    I suggest to add to the document a section =
of terminology which either points to RFC 3444, or describes the difference=
s from what is described in 3444 and also explains other terms like ‘=
interaction model’. 
     
    Regards,
     
    Dan
     

     <= /p>

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 10:01 PM
    To: Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi Qin,

    I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right?

    so I see it in two se= parete things.

    1-interaction model using CoAP

    2-content/data model = generic..

     

    X

     

     

    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote:

    Xavi and all,

     

    When we talk about data model (DM), there are likely= several points of view. For example:

    (1) DM is a set of messages, their format, and the b= ehavior caused by the messages.

    (2) Besides (1), also includes the interface with sp= ecific protocol, e.g. URI in CoAP.

     

    From the point (1) of view, I agree Xavi. But, becau= se URI is involved, so, it becomes CoAP Data Model.

     

    So, can we separate the common part of DM, i.e. poin= t (1) from protocol specific part of DM, i.e. something like URI?

     

    What do you think?

     

    Qin<= /p>

     

     

    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    HI all,

    I have a question rai= sing from the minutes (sorry I could not connect today).

    If title of the draft= is "6TiSCH CoAP data Model" this means that in the future we wil= l have "6TiSCH foo data Model". Is that the direction we want? Data Model is t= he way to represent message content (i.e what goes in the payload and is us= ed by 6top commands). Why is this specific to CoAP?

    Another aspect is int= eraction models, i.e message flows which in that case they are related to t= he capabilities of the transport mechanism.

    just thoughts.. = Sorry if I really go back to something you already discussed and it is rea= lly clear.

    X

     

     

     

    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    All,

     

    You will find the minutes of the discussion about th= e models draft from this morning at https://bit= bucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below).

     

    Thomas

     

    ---

     

    Minutes Webex 1 October 2013, 6= TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes (using Etherpad= )

    1.    = Thomas Watteyne

    2.    = Raghuram Sudhaakar

    Present (alphabetically)

    1.    = Alaeddine Weslati

    2.    = Dan Romascanu

    3.    = Diego Dujovne

    4.    = Pascal Thubert

    5.    = Pouria Zand

    6.    = Qin Wang

    7.    = R. Nabati

    8.    = Raghuram Sudhaakar

    9.    = Thomas Watteyne

    Agenda

    ·    =      = Present pre-draft ToC [Raghuram/Pouria]

    ·    =      = Discuss ToC

    ·    =      = Define contents of each section

    Minutes

    ·    =      [08.05] me= eting starts.

    ·    =      Raghuram shares pre-d= raft through Webex

    ·    =      = goals for today: define ToC, define contents of each section, pick title

    ·    =      = Scope is to include data and interaction model for CoAP. At a later stage, = extract information model as separate draft.

    ·    =      = "6TiSCH data model" or "6TiSCH CoAP data model"?

    ·    =      [Thomas] personal opi= nion: have CoAP in title

    ·    =      [Qin] why interaction= model on top of information model?

    ·    =      [Raghuram]<= /span> we want to= define message flows between PCE and nodes. Data model is exact definition of pay= load. We had rough consensus on using name-value pairs. Interaction model f= or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.

    ·    =      [Qin] RFC3444, intera= ction flows should be part of the data model? We should not conflict with RFC344= 4.

    ·    =      [Thomas] We may want = to split the interaction from this (data model) draft.

    ·    =      [Qin] Data definition= and coding is common part. For me, experience with different definitions. Don't want = another terminology.

    ·    =      [Dan] Not extremely f= amiliar with 6TiSCH but experience with data and information model. In the IETF, w= e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n= eed to stick with RFC3444 as close as possible.

    ·    =      [Raghuram]<= /span> Goal of in= teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late= r stage. We can name it differently later "interaction method".

    ·    =      [Dan] If we are inven= ting a new name, it does not matter too much. We are looking at mapping different= transports.

    ·    =      [Raghuram]<= /span> Goal of in= teraction model is to extract the information model.

    ·    =      [Raghuram]<= /span> Change to = ToC: remove interaction?

    ·    =      [Thomas] Could be rep= laced by example scenarios.

    ·    =      [Pascal] We have iden= tified interaction at L2, L3 and L5. We need to have discussion about the models.=

    ·    =      [Raghuram]<= /span> Conclusion= : in ToC, new section 3.4 with "example interactions". Message formats wou= ld be moved up to 3.3, name-value pairs proposed.

    ·    =      [Thomas] Rough consen= sus?

    ·    =      [Qin] what's the diff= erent between management and informational resources?

    ·    =      [Raghuram]<= /span> management= resources are R/W, informational resources are R (e.g. DAGrank).

    ·    =      [Thomas] We could wal= k through ToC?

    ·    =      [Raghuram]<= /span>

    ·    =      = 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.

    ·    =      = 3.2 resource of 6top we want to expose, i.e. management and informational r= esource.

    ·    =      = 3.2.4 user installed resources, e.g. subscribe for particular implementatio= n.

    ·    =      [Raghuram]<= /span> Should we = have extensible resources?

    ·    =      [Thomas] Yes.

    ·    =      [Qin] What the functi= onal description of a resource? Related to not only management but also informational resou= rces. Should we put every description attached to every resource? Looking a= t the content, I can imagine a resource list, with a description for each o= ne. Suggestion is to put description just following the resource list.

    ·    =      [Raghuram]<= /span> Fine with = that.

    ·    =      [Pouria] Other change= "functional description of resources" will fold into 3.2.1 and 3.2.2.<= /span>

    ·    =      [Raghuram]<= /span> Resource i= s just the URI, linked to particular 6top variable. Methods would fall under desc= ription of resource.

    ·    =      [Qin] Description of = the MIB?

    ·    =      [Raghuram]<= /span> End-user s= hould be able to get a specific parameters. Returned as name-value pairs. If an = entity wants the entire MIB, we will have a separate resource.

    ·    =      [Thomas] Mapping of 6= top commands included?

    ·    =      [Raghuram]<= /span> Yes. Mappi= ng of table of 6top commands presented in previous calls.

    ·    =      [Pouria] In resource = management, information that can be written by PCE, or commands to be executed.

    ·    =      [Raghuram]<= /span> Everything= that change the TSCH schedule falls under the management resource.

    ·    =      [Raghuram]<= /span> Section 4 = will be moved up. A message format will be attached to each URI.=

    ·    =      [Thomas] Map the attr= ibutes from minimal draft and the commands from 6top draft.

    ·    =      [Raghuram]<= /span> That is th= e plan.

    ·    =      [Thomas] What are ext= ensions?

    ·    =      [Raghuram]<= /span> We don't w= ant to define the URI for every attribute, we want to enable people to install a = new resource with a definition.

    ·    =      [Raghuram]<= /span> In that co= ntext, what are profiles?

    ·    =      [Thomas] Profile is o= verarching modification to basic behavior: e.g. adding resources or adding method to = existing resource.

    ·    =      [Qin] Understanding a= bout profile: resource is fixed, behavior of resource can be configurable.

    ·    =      [Pascal] +1 it's = very important we are able to do add to basic behavior.

    ·    =      [Diego] How can we de= scribe a trigger, e.g. number of measurements to average over.<= /h1>

    ·    =      [Thomas] Do we have a= solution?

    ·    =      [Raghuram]<= /span> Yes, compl= ex triggers are defined using well-known formats. RFC already defines how to encode se= veral thresholds. Output would be sent on CoAP response or observe notifica= tion. One generic method for any kind of trigger.

    ·    =      [Raghuram]<= /span> In profile= s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co= mplex triggers. Discovery. What we could express as profiles are extra comp= lex triggers.

    ·    =      [Thomas] What are the= next steps?

    ·    =      [Raghuram]<= /span> Updated ve= rsion of draft by next week to discuss progress. Invite contributors.=

    ·    =      [Thomas] Name of draf= t?

    ·    =      [Raghuram]<= /span> What about= "6TiSCH CoAP data model".

    ·    =      [Thomas] We need to k= now editor to create repository.

    ·    =      [Raghuram]<= /span> AOB?<= /o:p>

    No other business raised.

    ·    =      [09.05] me= eting ends.

     

    _____________________= __________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_E045AECD98228444A58C61C200AE1BD8414CA4BBxmbrcdx01ciscoc_-- From dromasca@avaya.com Thu Oct 3 01:40:41 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE72621F96E4 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF4LSP1vO-Cf for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 01:40:19 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0335321F88DD for <6tsch@ietf.org>; Thu, 3 Oct 2013 01:39:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAO8sTVKHCzI1/2dsb2JhbABaDoI1IyE4UsE4gR8WdIIlAQEBAQMBAQEPCBNBBAIFEAIBCA0EBAEBCwIUAQYHJwsUCQgCBAENBQgTB4dkAQugH5xXEwSOE4ENLQQGAQaDGYEEA4VPjlWKOYsjgmU/gWlB X-IronPort-AV: E=Sophos;i="4.90,1024,1371096000"; d="scan'208,217";a="31001450" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Oct 2013 04:39:05 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Oct 2013 04:30:16 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 10:38:59 +0200 From: "Romascanu, Dan (Dan)" To: "Pascal Thubert (pthubert)" , "xvilajosana@eecs.berkeley.edu" , Qin Wang Thread-Topic: [6tsch] minutes discussion models draft 1 October Thread-Index: AQHOvtNe0SkzQ1hGZ0yfEWd1nWRn5pngDNoAgABoWYD//5zNAIABLW2QgAATqCCAAVbEYA== Date: Thu, 3 Oct 2013 08:38:58 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128F11A1@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128EF169@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_" MIME-Version: 1.0 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 08:40:42 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, I *think* that it makes sense, but I would like to see text in a terminolog= y section of the document defining the terms and providing references where= relevant in order to make sure. Regards, Dan From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, October 02, 2013 5:13 PM To: Romascanu, Dan (Dan); xvilajosana@eecs.berkeley.edu; Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: RE: [6tsch] minutes discussion models draft 1 October Hello Dan; I understand that we want to stick to RFC 3444 for Data and Information mod= els. The limit to overcome is probably our understanding and practice of th= at specification. In addition to the static representation, we have a need to discuss the dyn= amic view of the 6TiSCH operation and we are looking for appropriate terms. At ISA100.11a this abstraction is often referred to as a "communication par= adigm". Examples there are client-server, publish-subscribe and source-sink= , which is a MP to MP distribution for alarms and alerts. We could reuse th= at terminology, with, in our case, the additions of classes for end-to-end = (app layer), hop-by-hop (network layer) and one hop (Link layer) interactio= ns. It seems from the discussion that the applied model for a "communication pa= radigm" could be called an "interaction model". For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de= vices. Additionally, we would propose a layer 5 interaction model to transport tha= t data. That interaction model would probably implement the client-server a= nd eventually the source-sink paradigms with CoAP methods. But that would b= e an example not a limitation, since there can be other ways to transport t= hat data, and other ways for format the bits and bytes. Does that make sense? Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: mercredi 2 octobre 2013 13:07 To: xvilajosana@eecs.berkeley.edu; Qi= n Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi, I made this observation in the call yesterday. It would be good to use the = terminology as defined in RFC 3444 in what concerns information models and = data models. Information models define objects and the relation between the= m in a generic manner and are protocol neutral. Data models are less abstra= ct, include implementation- and protocol-specific details, and are usually = associated to data modeling languages. Using other terms, or worse - the sa= me terms in a different manner - is confusing. I suggest to add to the document a section of terminology which either poin= ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'. Regards, Dan From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen Sent: Tuesday, October 01, 2013 10:01 PM To: Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang > wrote: Xavi and all, When we talk about data model (DM), there are likely several points of view= . For example: (1) DM is a set of messages, their format, and the behavior caused by the m= essages. (2) Besides (1), also includes the interface with specific protocol, e.g. U= RI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol spe= cific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen > wrote: HI all, I have a question raising from the minutes (sorry I could not connect today= ). If title of the draft is "6TiSCH CoAP data Model" this means that in the fu= ture we will have "6TiSCH foo data Model". Is that the direction we want? D= ata Model is the way to represent message content (i.e what goes in the pay= load and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case = they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discuss= ed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne > wrote: All, You will find the minutes of the discussion about the models draft from thi= s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_= draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes (using Etherpad) 1. Thomas Watteyne 2. Raghuram Sudhaakar Present (alphabetically) 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda * Present pre-draft ToC [Raghuram/Pouria] * Discuss ToC * Define contents of each section Minutes * [08.05] meeting starts. * Raghuram shares pre-draft through Webex * goals for today: define ToC, define contents of each section, pic= k title * Scope is to include data and interaction model for CoAP. At a lat= er stage, extract information model as separate draft. * "6TiSCH data model" or "6TiSCH CoAP data model"? * [Thomas] personal opinion: have CoAP in title * [Qin] why interaction model on top of information model? * [Raghuram] we want to define message flows between PCE and nodes.= Data model is exact definition of payload. We had rough consensus on using= name-value pairs. Interaction model for CoAP or RSVP in future drafts. Int= eraction model provides abstract model of interaction between entities. * [Qin] RFC3444, interaction flows should be part of the data model= ? We should not conflict with RFC3444. * [Thomas] We may want to split the interaction from this (data mod= el) draft. * [Qin] Data definition and coding is common part. For me, experien= ce with different definitions. Don't want another terminology. * [Dan] Not extremely familiar with 6TiSCH but experience with data= and information model. In the IETF, we have clear definitions about data a= nd information model. RFC3444 accepted and used as reference. There are dif= ferences, i.e. interaction model. We need to stick with RFC3444 as close as= possible. * [Raghuram] Goal of interaction model is try to extract informatio= n model at a later stage. CoAP is one of the transports we are using today,= but we can use other protocol at a later stage. We can name it differently= later "interaction method". * [Dan] If we are inventing a new name, it does not matter too much= . We are looking at mapping different transports. * [Raghuram] Goal of interaction model is to extract the informatio= n model. * [Raghuram] Change to ToC: remove interaction? * [Thomas] Could be replaced by example scenarios. * [Pascal] We have identified interaction at L2, L3 and L5. We need= to have discussion about the models. * [Raghuram] Conclusion: in ToC, new section 3.4 with "example inte= ractions". Message formats would be moved up to 3.3, name-value pairs propo= sed. * [Thomas] Rough consensus? * [Qin] what's the different between management and informational r= esources? * [Raghuram] management resources are R/W, informational resources = are R (e.g. DAGrank). * [Thomas] We could walk through ToC? * [Raghuram] * 3.1 naming convention for URI schemes. For example, root resource= "6t". Includes naming convention for resources under root resource. * 3.2 resource of 6top we want to expose, i.e. management and infor= mational resource. * 3.2.4 user installed resources, e.g. subscribe for particular imp= lementation. * [Raghuram] Should we have extensible resources? * [Thomas] Yes. * [Qin] What the functional description of a resource? Related to n= ot only management but also informational resources. Should we put every de= scription attached to every resource? Looking at the content, I can imagine= a resource list, with a description for each one. Suggestion is to put des= cription just following the resource list. * [Raghuram] Fine with that. * [Pouria] Other change "functional description of resources" will = fold into 3.2.1 and 3.2.2. * [Raghuram] Resource is just the URI, linked to particular 6top va= riable. Methods would fall under description of resource. * [Qin] Description of the MIB? * [Raghuram] End-user should be able to get a specific parameters. = Returned as name-value pairs. If an entity wants the entire MIB, we will ha= ve a separate resource. * [Thomas] Mapping of 6top commands included? * [Raghuram] Yes. Mapping of table of 6top commands presented in pr= evious calls. * [Pouria] In resource management, information that can be written = by PCE, or commands to be executed. * [Raghuram] Everything that change the TSCH schedule falls under t= he management resource. * [Raghuram] Section 4 will be moved up. A message format will be a= ttached to each URI. * [Thomas] Map the attributes from minimal draft and the commands f= rom 6top draft. * [Raghuram] That is the plan. * [Thomas] What are extensions? * [Raghuram] We don't want to define the URI for every attribute, w= e want to enable people to install a new resource with a definition. * [Raghuram] In that context, what are profiles? * [Thomas] Profile is overarching modification to basic behavior: e= .g. adding resources or adding method to existing resource. * [Qin] Understanding about profile: resource is fixed, behavior of= resource can be configurable. * [Pascal] +1 it's very important we are able to do add to basic be= havior. * [Diego] How can we describe a trigger, e.g. number of measurement= s to average over. * [Thomas] Do we have a solution? * [Raghuram] Yes, complex triggers are defined using well-known for= mats. RFC already defines how to encode several thresholds. Output would be= sent on CoAP response or observe notification. One generic method for any = kind of trigger. * [Raghuram] In profiles, modify or add behavior. Add is easy. Prof= iles as a way to define extra sets of complex triggers. Discovery. What we = could express as profiles are extra complex triggers. * [Thomas] What are the next steps? * [Raghuram] Updated version of draft by next week to discuss progr= ess. Invite contributors. * [Thomas] Name of draft? * [Raghuram] What about "6TiSCH CoAP data model". * [Thomas] We need to know editor to create repository. * [Raghuram] AOB? No other business raised. * [09.05] meeting ends. _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Pascal,

     <= /p>

    I *think* that it = makes sense, but I would like to see text in a terminology section of the d= ocument defining the terms and providing references where relevant in order to make sure.

     <= /p>

    Regards,

     <= /p>

    Dan

     <= /p>

     <= /p>

     <= /p>

    From: Pascal T= hubert (pthubert) [mailto:pthubert@cisco.com]
    Sent: Wednesday, October 02, 2013 5:13 PM
    To: Romascanu, Dan (Dan); xvilajosana@eecs.berkeley.edu; Qin Wang Cc: Thomas Watteyne; 6TSCH
    Subject: RE: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hello Dan;

     <= /p>

    I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom= e is probably our understanding and practice of that specification.

     <= /p>

    In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o= peration and we are looking for appropriate terms.   <= /span>

     <= /p>

    At ISA100.11a this abstra= ction is often referred to as a “communication paradigm”. Examp= les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term= inology, with, in our case, the additions of classes for end-to-end (app la= yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb= sp;

     <= /p>

    It seems from the discuss= ion that the applied model for a “communication paradigm” could= be called an “interaction model”.

     <= /p>

    For this particular draft= , I’d then expect something like a Yang data model that can be trivia= lly translated in CBOR for consumption by constrained devices.

     <= /p>

    Additionally, we would pr= opose a layer 5 interaction model to transport that data. That interaction = model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example = not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.

     <= /p>

    Does that make sense?

     <= /p>

    Pascal

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
    Sent: mercredi 2 octobre 2013 13:07
    To: xvilajosana@eec= s.berkeley.edu; Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi,

     <= /p> 

    I made this observation in the call yesterd=
ay. It would be good to use the terminology as defined in RFC 3444 in what =
concerns information models and data models. Information models define obje=
cts and the relation between them in a generic manner and are protocol neut=
ral. Data models are less abstract, include implementation- and protocol-sp=
ecific details, and are usually associated to data modeling languages. Usin=
g other terms, or worse – the same terms in a different manner –=
; is confusing. 
     
    I suggest to add to the document a section =
of terminology which either points to RFC 3444, or describes the difference=
s from what is described in 3444 and also explains other terms like ‘=
interaction model’. 
     
    Regards,
     
    Dan
     

     <= /p>

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 10:01 PM
    To: Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi Qin,

    I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right?

    so I see it in two se= parete things.

    1-interaction model using CoAP

    2-content/data model = generic..

     

    X

     

     

    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote:

    Xavi and all,

     

    When we talk about data model (DM), there are likely= several points of view. For example:

    (1) DM is a set of messages, their format, and the b= ehavior caused by the messages.

    (2) Besides (1), also includes the interface with sp= ecific protocol, e.g. URI in CoAP.

     

    From the point (1) of view, I agree Xavi. But, becau= se URI is involved, so, it becomes CoAP Data Model.

     

    So, can we separate the common part of DM, i.e. poin= t (1) from protocol specific part of DM, i.e. something like URI?

     

    What do you think?

     

    Qin<= /p>

     

     

    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    HI all,

    I have a question rai= sing from the minutes (sorry I could not connect today).

    If title of the draft= is "6TiSCH CoAP data Model" this means that in the future we wil= l have "6TiSCH foo data Model". Is that the direction we want? Data Model is t= he way to represent message content (i.e what goes in the payload and is us= ed by 6top commands). Why is this specific to CoAP?

    Another aspect is int= eraction models, i.e message flows which in that case they are related to t= he capabilities of the transport mechanism.

    just thoughts.. = Sorry if I really go back to something you already discussed and it is rea= lly clear.

    X

     

     

     

    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    All,

     

    You will find the minutes of the discussion about th= e models draft from this morning at https://bit= bucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below).

     

    Thomas

     

    ---

     

    Minutes Webex 1 October 2013, 6= TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes (using Etherpad= )

    1.    Thomas Watteyne

    2.    Raghuram Sudhaakar

    Present (alphabetically)

    1.    Alaeddine Weslati

    2.    Dan Romascanu

    3.    Diego Dujovne

    4.    Pascal Thubert

    5.    Pouria Zand

    6.    Qin Wang

    7.    R. Nabati

    8.    Raghuram Sudhaakar

    9.    Thomas Watteyne

    Agenda

    ·    =      Present pre-draft ToC [Raghuram/Pouria]<= /em>

    ·    =      Discuss ToC

    ·    =      Define contents of each section<= /h1>

    Minutes

    ·    =      [08.05] meeting starts.

    ·    =      Raghuram shares pre-draft through Webex

    ·    =      goals for today: define ToC, define contents of ea= ch section, pick title

    ·    =      Scope is to include data and interaction model for= CoAP. At a later stage, extract information model as separate draft.

    ·    =      "6TiSCH data model" or "6TiSCH CoAP= data model"?

    ·    =      [Thomas] personal opinion: have CoAP in title

    ·    =      [Qin] why interaction model on top of information model?

    ·    =      [Raghuram] we want to define message flows between PCE and nodes. Data model is exact de= finition of payload. We had rough consensus on using name-value pairs. Inte= raction model for CoAP or RSVP in future drafts. Interaction model provides= abstract model of interaction between entities.

    ·    =      [Qin] RFC3444, interaction flows should be part of the data model? We should not conflict= with RFC3444.

    ·    =      [Thomas] We may want to split the interaction from this (data model) draft.=

    ·    =      [Qin] Data definition and coding is common part. For me, experience with different de= finitions. Don't want another terminology.

    ·    =      [Dan] Not extremely familiar with 6TiSCH but experience with data and information mo= del. In the IETF, we have clear definitions about data and information mode= l. RFC3444 accepted and used as reference. There are differences, i.e. inte= raction model. We need to stick with RFC3444 as close as possible.

    ·    =      [Raghuram] Goal of interaction model is try to extract information model at a later stage.= CoAP is one of the transports we are using today, but we can use other pro= tocol at a later stage. We can name it differently later "interaction = method".

    ·    =      [Dan] If we are inventing a new name, it does not matter too much. We are looking a= t mapping different transports.

    ·    =      [Raghuram] Goal of interaction model is to extract the information model.

    ·    =      [Raghuram] Change to ToC: remove interaction?

    ·    =      [Thomas] Could be replaced by example scenarios.

    ·    =      [Pascal] We have identified interaction at L2, L3 and L5. We need to have discussion a= bout the models.

    ·    =      [Raghuram] Conclusion: in ToC, new section 3.4 with "example interactions". Message for= mats would be moved up to 3.3, name-value pairs proposed.=

    ·    =      [Thomas] Rough consensus?

    ·    =      [Qin] what's the different between management and informational resources?

    ·    =      [Raghuram] management resources are R/W, informational resources are R (e.g. DAGrank).

    ·    =      [Thomas] We could walk through ToC?

    ·    =      [Raghuram]

    ·    =      3.1 naming convention for URI schemes. For example= , root resource "6t". Includes naming convention for resources under root resource.

    ·    =      3.2 resource of 6top we want to expose, i.e. manag= ement and informational resource.

    ·    =      3.2.4 user installed resources, e.g. subscribe for= particular implementation.

    ·    =      [Raghuram] Should we have extensible resources?

    ·    =      [Thomas] Yes.

    ·    =      [Qin] What the functional description of a resource? Related to not only management b= ut also informational resources. Should we put every description attached t= o every resource? Looking at the content, I can imagine a resource list, wi= th a description for each one. Suggestion is to put description just following the resource list.<= /h1>

    ·    =      [Raghuram] Fine with that.

    ·    =      [Pouria] Other change "functional description of resources" will fold into 3.2.= 1 and 3.2.2.

    ·    =      [Raghuram] Resource is just the URI, linked to particular 6top variable. Methods would fall un= der description of resource.

    ·    =      [Qin] Description of the MIB?

    ·    =      [Raghuram] End-user should be able to get a specific parameters. Returned as name-value pairs.= If an entity wants the entire MIB, we will have a separate resource.<= /o:p>

    ·    =      [Thomas] Mapping of 6top commands included?

    ·    =      [Raghuram] Yes. Mapping of table of 6top commands presented in previous calls.<= /span>

    ·    =      [Pouria] In resource management, information that can be written by PCE, or commands t= o be executed.

    ·    =      [Raghuram] Everything that change the TSCH schedule falls under the management resource.

    ·    =      [Raghuram] Section 4 will be moved up. A message format will be attached to each URI.

    ·    =      [Thomas] Map the attributes from minimal draft and the commands from 6top draft.

    ·    =      [Raghuram] That is the plan.

    ·    =      [Thomas] What are extensions?

    ·    =      [Raghuram] We don't want to define the URI for every attribute, we want to enable people= to install a new resource with a definition.

    ·    =      [Raghuram] In that context, what are profiles?

    ·    =      [Thomas] Profile is overarching modification to basic behavior: e.g. adding resources or ad= ding method to existing resource.

    ·    =      [Qin] Understanding about profile: resource is fixed, behavior of resource can be configurable= .

    ·    =      [Pascal] +1 it's very important we are able to do add to basic behavior.

    ·    =      [Diego] How can we describe a trigger, e.g. number of measurements to average over.

    ·    =      [Thomas] Do we have a solution?

    ·    =      [Raghuram] Yes, complex triggers are defined using well-known formats. RFC already defines= how to encode several thresholds. Output would be sent on CoAP response or= observe notification. One generic method for any kind of trigger.

    ·    =      [Raghuram] In profiles, modify or add behavior. Add is easy. Profiles as a way to define= extra sets of complex triggers. Discovery. What we could express as profil= es are extra complex triggers.

    ·    =      [Thomas] What are the next steps?

    ·    =      [Raghuram] Updated version of draft by next week to discuss progress. Invite contributors.

    ·    =      [Thomas] Name of draft?

    ·    =      [Raghuram] What about "6TiSCH CoAP data model".

    ·    =      [Thomas] We need to know editor to create repository.

    ·    =      [Raghuram] AOB?

    No other business raised.

    ·    =      [09.05] meeting ends.

     

    _____________________= __________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_9904FB1B0159DA42B0B887B7FA8119CA128F11A1AZFFEXMB04globa_-- From maria-rita.palattella@uni.lu Thu Oct 3 01:51:52 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE3121F9767 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 01:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc5pwUI9FEZf for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 01:51:39 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id B7EBE21E804D for <6tsch@ietf.org>; Thu, 3 Oct 2013 01:49:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1024,1371074400"; d="scan'208,217";a="27002637" Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 03 Oct 2013 10:49:51 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 10:49:50 +0200 From: Maria Rita PALATTELLA To: "Romascanu, Dan (Dan)" , "Pascal Thubert (pthubert)" , "xvilajosana@eecs.berkeley.edu" , Qin Wang Thread-Topic: [6tsch] minutes discussion models draft 1 October Thread-Index: AQHOvtNdjcYjZ8sjLkakmym5OyVZJJngDNoAgAADxICAAAFiAIABDeCAgAAz0ACAATUjAIAAI+tw Date: Thu, 3 Oct 2013 08:49:50 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA128EF169@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA128F11A1@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128F11A1@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.61] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_" MIME-Version: 1.0 Cc: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] minutes discussion models draft 1 October X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 08:51:52 -0000 --_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Dan, We actually have a terminology draft for 6TiSCH... Shouldn't we define the terms we need in that terminology draft, and refer = to it in the model draft? Instead of having a terminology section? It is ju= st a thought... What do you think? Maria Rita From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of R= omascanu, Dan (Dan) Sent: Thursday, October 03, 2013 10:39 AM To: Pascal Thubert (pthubert); xvilajosana@eecs.berkeley.edu; Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi Pascal, I *think* that it makes sense, but I would like to see text in a terminolog= y section of the document defining the terms and providing references where= relevant in order to make sure. Regards, Dan From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Wednesday, October 02, 2013 5:13 PM To: Romascanu, Dan (Dan); xvilajosana@eecs.berkeley.edu; Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: RE: [6tsch] minutes discussion models draft 1 October Hello Dan; I understand that we want to stick to RFC 3444 for Data and Information mod= els. The limit to overcome is probably our understanding and practice of th= at specification. In addition to the static representation, we have a need to discuss the dyn= amic view of the 6TiSCH operation and we are looking for appropriate terms. At ISA100.11a this abstraction is often referred to as a "communication par= adigm". Examples there are client-server, publish-subscribe and source-sink= , which is a MP to MP distribution for alarms and alerts. We could reuse th= at terminology, with, in our case, the additions of classes for end-to-end = (app layer), hop-by-hop (network layer) and one hop (Link layer) interactio= ns. It seems from the discussion that the applied model for a "communication pa= radigm" could be called an "interaction model". For this particular draft, I'd then expect something like a Yang data model= that can be trivially translated in CBOR for consumption by constrained de= vices. Additionally, we would propose a layer 5 interaction model to transport tha= t data. That interaction model would probably implement the client-server a= nd eventually the source-sink paradigms with CoAP methods. But that would b= e an example not a limitation, since there can be other ways to transport t= hat data, and other ways for format the bits and bytes. Does that make sense? Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: mercredi 2 octobre 2013 13:07 To: xvilajosana@eecs.berkeley.edu; Qi= n Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi, I made this observation in the call yesterday. It would be good to use the = terminology as defined in RFC 3444 in what concerns information models and = data models. Information models define objects and the relation between the= m in a generic manner and are protocol neutral. Data models are less abstra= ct, include implementation- and protocol-specific details, and are usually = associated to data modeling languages. Using other terms, or worse - the sa= me terms in a different manner - is confusing. I suggest to add to the document a section of terminology which either poin= ts to RFC 3444, or describes the differences from what is described in 3444= and also explains other terms like 'interaction model'. Regards, Dan From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen Sent: Tuesday, October 01, 2013 10:01 PM To: Qin Wang Cc: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] minutes discussion models draft 1 October Hi Qin, I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right? so I see it in two separete things. 1-interaction model using CoAP 2-content/data model generic.. X On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang > wrote: Xavi and all, When we talk about data model (DM), there are likely several points of view= . For example: (1) DM is a set of messages, their format, and the behavior caused by the m= essages. (2) Besides (1), also includes the interface with specific protocol, e.g. U= RI in CoAP. >From the point (1) of view, I agree Xavi. But, because URI is involved, so,= it becomes CoAP Data Model. So, can we separate the common part of DM, i.e. point (1) from protocol spe= cific part of DM, i.e. something like URI? What do you think? Qin On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Guillen > wrote: HI all, I have a question raising from the minutes (sorry I could not connect today= ). If title of the draft is "6TiSCH CoAP data Model" this means that in the fu= ture we will have "6TiSCH foo data Model". Is that the direction we want? D= ata Model is the way to represent message content (i.e what goes in the pay= load and is used by 6top commands). Why is this specific to CoAP? Another aspect is interaction models, i.e message flows which in that case = they are related to the capabilities of the transport mechanism. just thoughts.. Sorry if I really go back to something you already discuss= ed and it is really clear. X On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne > wrote: All, You will find the minutes of the discussion about the models draft from thi= s morning at https://bitbucket.org/6tsch/meetings/wiki/131001_webex_models_= draft (also copy-pasted below). Thomas --- Minutes Webex 1 October 2013, 6TiSCH group, models draft team Note: timestamps in PDT. Taking notes (using Etherpad) 1. Thomas Watteyne 2. Raghuram Sudhaakar Present (alphabetically) 1. Alaeddine Weslati 2. Dan Romascanu 3. Diego Dujovne 4. Pascal Thubert 5. Pouria Zand 6. Qin Wang 7. R. Nabati 8. Raghuram Sudhaakar 9. Thomas Watteyne Agenda * Present pre-draft ToC [Raghuram/Pouria] * Discuss ToC * Define contents of each section Minutes * [08.05] meeting starts. * Raghuram shares pre-draft through Webex * goals for today: define ToC, define contents of each section, pick= title * Scope is to include data and interaction model for CoAP. At a late= r stage, extract information model as separate draft. * "6TiSCH data model" or "6TiSCH CoAP data model"? * [Thomas] personal opinion: have CoAP in title * [Qin] why interaction model on top of information model? * [Raghuram] we want to define message flows between PCE and nodes. = Data model is exact definition of payload. We had rough consensus on using = name-value pairs. Interaction model for CoAP or RSVP in future drafts. Inte= raction model provides abstract model of interaction between entities. * [Qin] RFC3444, interaction flows should be part of the data model?= We should not conflict with RFC3444. * [Thomas] We may want to split the interaction from this (data mode= l) draft. * [Qin] Data definition and coding is common part. For me, experienc= e with different definitions. Don't want another terminology. * [Dan] Not extremely familiar with 6TiSCH but experience with data = and information model. In the IETF, we have clear definitions about data an= d information model. RFC3444 accepted and used as reference. There are diff= erences, i.e. interaction model. We need to stick with RFC3444 as close as = possible. * [Raghuram] Goal of interaction model is try to extract information= model at a later stage. CoAP is one of the transports we are using today, = but we can use other protocol at a later stage. We can name it differently = later "interaction method". * [Dan] If we are inventing a new name, it does not matter too much.= We are looking at mapping different transports. * [Raghuram] Goal of interaction model is to extract the information= model. * [Raghuram] Change to ToC: remove interaction? * [Thomas] Could be replaced by example scenarios. * [Pascal] We have identified interaction at L2, L3 and L5. We need = to have discussion about the models. * [Raghuram] Conclusion: in ToC, new section 3.4 with "example inter= actions". Message formats would be moved up to 3.3, name-value pairs propos= ed. * [Thomas] Rough consensus? * [Qin] what's the different between management and informational re= sources? * [Raghuram] management resources are R/W, informational resources a= re R (e.g. DAGrank). * [Thomas] We could walk through ToC? * [Raghuram] * 3.1 naming convention for URI schemes. For example, root resource = "6t". Includes naming convention for resources under root resource. * 3.2 resource of 6top we want to expose, i.e. management and inform= ational resource. * 3.2.4 user installed resources, e.g. subscribe for particular impl= ementation. * [Raghuram] Should we have extensible resources? * [Thomas] Yes. * [Qin] What the functional description of a resource? Related to no= t only management but also informational resources. Should we put every des= cription attached to every resource? Looking at the content, I can imagine = a resource list, with a description for each one. Suggestion is to put desc= ription just following the resource list. * [Raghuram] Fine with that. * [Pouria] Other change "functional description of resources" will f= old into 3.2.1 and 3.2.2. * [Raghuram] Resource is just the URI, linked to particular 6top var= iable. Methods would fall under description of resource. * [Qin] Description of the MIB? * [Raghuram] End-user should be able to get a specific parameters. R= eturned as name-value pairs. If an entity wants the entire MIB, we will hav= e a separate resource. * [Thomas] Mapping of 6top commands included? * [Raghuram] Yes. Mapping of table of 6top commands presented in pre= vious calls. * [Pouria] In resource management, information that can be written b= y PCE, or commands to be executed. * [Raghuram] Everything that change the TSCH schedule falls under th= e management resource. * [Raghuram] Section 4 will be moved up. A message format will be at= tached to each URI. * [Thomas] Map the attributes from minimal draft and the commands fr= om 6top draft. * [Raghuram] That is the plan. * [Thomas] What are extensions? * [Raghuram] We don't want to define the URI for every attribute, we= want to enable people to install a new resource with a definition. * [Raghuram] In that context, what are profiles? * [Thomas] Profile is overarching modification to basic behavior: e.= g. adding resources or adding method to existing resource. * [Qin] Understanding about profile: resource is fixed, behavior of = resource can be configurable. * [Pascal] +1 it's very important we are able to do add to basic beh= avior. * [Diego] How can we describe a trigger, e.g. number of measurements= to average over. * [Thomas] Do we have a solution? * [Raghuram] Yes, complex triggers are defined using well-known form= ats. RFC already defines how to encode several thresholds. Output would be = sent on CoAP response or observe notification. One generic method for any k= ind of trigger. * [Raghuram] In profiles, modify or add behavior. Add is easy. Profi= les as a way to define extra sets of complex triggers. Discovery. What we c= ould express as profiles are extra complex triggers. * [Thomas] What are the next steps? * [Raghuram] Updated version of draft by next week to discuss progre= ss. Invite contributors. * [Thomas] Name of draft? * [Raghuram] What about "6TiSCH CoAP data model". * [Thomas] We need to know editor to create repository. * [Raghuram] AOB? No other business raised. * [09.05] meeting ends. _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Dan,

    We actually have a termin= ology draft for 6TiSCH…

    Shouldn’t we define= the terms we need in that terminology draft, and refer to it in the model = draft? Instead of having a terminology section? It is just a thought…=

    What do you think?

    Maria Rita

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
    Sent: Thursday, October 03, 2013 10:39 AM
    To: Pascal Thubert (pthubert); xvilajosana@eecs.berkeley.edu; Qin Wa= ng
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi Pascal,

     <= /p>

    I *think* that it = makes sense, but I would like to see text in a terminology section of the d= ocument defining the terms and providing references where relevant in order to make sure.

     <= /p>

    Regards,

     <= /p>

    Dan

     <= /p>

     <= /p>

     <= /p>

    From: Pascal T= hubert (pthubert) [mailto:pthubert@ci= sco.com]
    Sent: Wednesday, October 02, 2013 5:13 PM
    To: Romascanu, Dan (Dan); xvilajosana@eecs.berkeley.edu; Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: RE: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hello Dan;

     <= /p>

    I understand that we want= to stick to RFC 3444 for Data and Information models. The limit to overcom= e is probably our understanding and practice of that specification.

     <= /p>

    In addition to the static= representation, we have a need to discuss the dynamic view of the 6TiSCH o= peration and we are looking for appropriate terms.   <= /span>

     <= /p>

    At ISA100.11a this abstra= ction is often referred to as a “communication paradigm”. Examp= les there are client-server, publish-subscribe and source-sink, which is a MP to MP distribution for alarms and alerts. We could reuse that term= inology, with, in our case, the additions of classes for end-to-end (app la= yer), hop-by-hop (network layer) and one hop (Link layer) interactions. &nb= sp;

     <= /p>

    It seems from the discuss= ion that the applied model for a “communication paradigm” could= be called an “interaction model”.

     <= /p>

    For this particular draft= , I’d then expect something like a Yang data model that can be trivia= lly translated in CBOR for consumption by constrained devices.

     <= /p>

    Additionally, we would pr= opose a layer 5 interaction model to transport that data. That interaction = model would probably implement the client-server and eventually the source-sink paradigms with CoAP methods. But that would be an example = not a limitation, since there can be other ways to transport that data, and= other ways for format the bits and bytes.

     <= /p>

    Does that make sense?

     <= /p>

    Pascal

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
    Sent: mercredi 2 octobre 2013 13:07
    To: xvilajosana@eec= s.berkeley.edu; Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi,

     <= /p> 

    I made this observation in the call yesterd=
ay. It would be good to use the terminology as defined in RFC 3444 in what =
concerns information models and data models. Information models define obje=
cts and the relation between them in a generic manner and are protocol neut=
ral. Data models are less abstract, include implementation- and protocol-sp=
ecific details, and are usually associated to data modeling languages. Usin=
g other terms, or worse – the same terms in a different manner –=
; is confusing. 
     
    I suggest to add to the document a section =
of terminology which either points to RFC 3444, or describes the difference=
s from what is described in 3444 and also explains other terms like ‘=
interaction model’. 
     
    Regards,
     
    Dan
     

     <= /p>

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 10:01 PM
    To: Qin Wang
    Cc: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] minutes discussion models draft 1 October<= /o:p>

     

    Hi Qin,

    I agree with you .. URI is to indentify the resource, i.e how do we access = a particular service offered by the management layer, I agree that this sho= uld have CoAP name on it if this is bound to URI. then the data model( the = content of what we sent on the payload) this should be generic right?

    so I see it in two se= parete things.

    1-interaction model using CoAP

    2-content/data model = generic..

     

    X

     

     

    On Tue, Oct 1, 2013 at 11:56 AM, Qin Wang <qinwang@berkeley.edu> wrote:

    Xavi and all,

     

    When we talk about data model (DM), there are likely= several points of view. For example:

    (1) DM is a set of messages, their format, and the b= ehavior caused by the messages.

    (2) Besides (1), also includes the interface with sp= ecific protocol, e.g. URI in CoAP.

     

    From the point (1) of view, I agree Xavi. But, becau= se URI is involved, so, it becomes CoAP Data Model.

     

    So, can we separate the common part of DM, i.e. poin= t (1) from protocol specific part of DM, i.e. something like URI?

     

    What do you think?

     

    Qin<= /p>

     

     

    On Wed, Oct 2, 2013 at 2:42 AM, Xavier Vilajosana Gu= illen <xvilajosana@eecs.berkeley.edu> wrote:

    HI all,

    I have a question rai= sing from the minutes (sorry I could not connect today).

    If title of the draft= is "6TiSCH CoAP data Model" this means that in the future we wil= l have "6TiSCH foo data Model". Is that the direction we want? Data Model is t= he way to represent message content (i.e what goes in the payload and is us= ed by 6top commands). Why is this specific to CoAP?

    Another aspect is int= eraction models, i.e message flows which in that case they are related to t= he capabilities of the transport mechanism.

    just thoughts.. = Sorry if I really go back to something you already discussed and it is rea= lly clear.

    X

     

     

     

    On Tue, Oct 1, 2013 at 11:22 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    All,

     

    You will find the minutes of the discussion about th= e models draft from this morning at https://bit= bucket.org/6tsch/meetings/wiki/131001_webex_models_draft (also copy-pasted below).

     

    Thomas

     

    ---

     

    Minutes Webex 1 October 2013, 6= TiSCH group, models draft team

    Note: timestamps in PDT.

    Taking notes (using Etherpad= )

    1.     = Thomas Watteyne

    2.     = Raghuram Sudhaakar

    Present (alphabetically)

    1.     = Alaeddine Weslati

    2.     = Dan Romascanu

    3.     = Diego Dujovne

    4.     = Pascal Thubert

    5.     = Pouria Zand

    6.     = Qin Wang

    7.     = R. Nabati

    8.     = Raghuram Sudhaakar

    9.     = Thomas Watteyne

    Agenda

    ·    =     = Present pre-draft ToC [Raghuram/Pouria]

    ·    =     = Discuss ToC

    ·    =     = Define contents of each section

    Minutes

    ·    =     [08.05] me= eting starts.

    ·    =     Raghuram shares pre-d= raft through Webex

    ·    =     = goals for today: define ToC, define contents of each section, pick title

    ·    =     = Scope is to include data and interaction model for CoAP. At a later stage, = extract information model as separate draft.

    ·    =     = "6TiSCH data model" or "6TiSCH CoAP data model"?

    ·    =     [Thomas] personal opi= nion: have CoAP in title

    ·    =     [Qin] why interaction= model on top of information model?

    ·    =     [Raghuram]<= /span> we want to= define message flows between PCE and nodes. Data model is exact definition of pay= load. We had rough consensus on using name-value pairs. Interaction model f= or CoAP or RSVP in future drafts. Interaction model provides abstract model= of interaction between entities.

    ·    =     [Qin] RFC3444, intera= ction flows should be part of the data model? We should not conflict with RFC344= 4.

    ·    =     [Thomas] We may want = to split the interaction from this (data model) draft.

    ·    =     [Qin] Data definition= and coding is common part. For me, experience with different definitions. Don't want = another terminology.

    ·    =     [Dan] Not extremely f= amiliar with 6TiSCH but experience with data and information model. In the IETF, w= e have clear definitions about data and information model. RFC3444 accepted= and used as reference. There are differences, i.e. interaction model. We n= eed to stick with RFC3444 as close as possible.

    ·    =     [Raghuram]<= /span> Goal of in= teraction model is try to extract information model at a later stage. CoAP is one of= the transports we are using today, but we can use other protocol at a late= r stage. We can name it differently later "interaction method".

    ·    =     [Dan] If we are inven= ting a new name, it does not matter too much. We are looking at mapping different= transports.

    ·    =     [Raghuram]<= /span> Goal of in= teraction model is to extract the information model.

    ·    =     [Raghuram]<= /span> Change to = ToC: remove interaction?

    ·    =     [Thomas] Could be rep= laced by example scenarios.

    ·    =     [Pascal] We have iden= tified interaction at L2, L3 and L5. We need to have discussion about the models.=

    ·    =     [Raghuram]<= /span> Conclusion= : in ToC, new section 3.4 with "example interactions". Message formats wou= ld be moved up to 3.3, name-value pairs proposed.

    ·    =     [Thomas] Rough consen= sus?

    ·    =     [Qin] what's the diff= erent between management and informational resources?

    ·    =     [Raghuram]<= /span> management= resources are R/W, informational resources are R (e.g. DAGrank).

    ·    =     [Thomas] We could wal= k through ToC?

    ·    =     [Raghuram]<= /span>

    ·    =     = 3.1 naming convention for URI schemes. For example, root resource "6t&= quot;. Includes naming convention for resources under root resource.

    ·    =     = 3.2 resource of 6top we want to expose, i.e. management and informational r= esource.

    ·    =     = 3.2.4 user installed resources, e.g. subscribe for particular implementatio= n.

    ·    =     [Raghuram]<= /span> Should we = have extensible resources?

    ·    =     [Thomas] Yes.

    ·    =     [Qin] What the functi= onal description of a resource? Related to not only management but also informational resou= rces. Should we put every description attached to every resource? Looking a= t the content, I can imagine a resource list, with a description for each o= ne. Suggestion is to put description just following the resource list.

    ·    =     [Raghuram]<= /span> Fine with = that.

    ·    =     [Pouria] Other change= "functional description of resources" will fold into 3.2.1 and 3.2.2.<= /span>

    ·    =     [Raghuram]<= /span> Resource i= s just the URI, linked to particular 6top variable. Methods would fall under desc= ription of resource.

    ·    =     [Qin] Description of = the MIB?

    ·    =     [Raghuram]<= /span> End-user s= hould be able to get a specific parameters. Returned as name-value pairs. If an = entity wants the entire MIB, we will have a separate resource.

    ·    =     [Thomas] Mapping of 6= top commands included?

    ·    =     [Raghuram]<= /span> Yes. Mappi= ng of table of 6top commands presented in previous calls.

    ·    =     [Pouria] In resource = management, information that can be written by PCE, or commands to be executed.

    ·    =     [Raghuram]<= /span> Everything= that change the TSCH schedule falls under the management resource.

    ·    =     [Raghuram]<= /span> Section 4 = will be moved up. A message format will be attached to each URI.=

    ·    =     [Thomas] Map the attr= ibutes from minimal draft and the commands from 6top draft.

    ·    =     [Raghuram]<= /span> That is th= e plan.

    ·    =     [Thomas] What are ext= ensions?

    ·    =     [Raghuram]<= /span> We don't w= ant to define the URI for every attribute, we want to enable people to install a = new resource with a definition.

    ·    =     [Raghuram]<= /span> In that co= ntext, what are profiles?

    ·    =     [Thomas] Profile is o= verarching modification to basic behavior: e.g. adding resources or adding method to = existing resource.

    ·    =     [Qin] Understanding a= bout profile: resource is fixed, behavior of resource can be configurable.

    ·    =     [Pascal] +1 it's = very important we are able to do add to basic behavior.

    ·    =     [Diego] How can we de= scribe a trigger, e.g. number of measurements to average over.<= /h1>

    ·    =     [Thomas] Do we have a= solution?

    ·    =     [Raghuram]<= /span> Yes, compl= ex triggers are defined using well-known formats. RFC already defines how to encode se= veral thresholds. Output would be sent on CoAP response or observe notifica= tion. One generic method for any kind of trigger.

    ·    =     [Raghuram]<= /span> In profile= s, modify or add behavior. Add is easy. Profiles as a way to define extra sets of co= mplex triggers. Discovery. What we could express as profiles are extra comp= lex triggers.

    ·    =     [Thomas] What are the= next steps?

    ·    =     [Raghuram]<= /span> Updated ve= rsion of draft by next week to discuss progress. Invite contributors.=

    ·    =     [Thomas] Name of draf= t?

    ·    =     [Raghuram]<= /span> What about= "6TiSCH CoAP data model".

    ·    =     [Thomas] We need to k= now editor to create repository.

    ·    =     [Raghuram]<= /span> AOB?<= /o:p>

    No other business raised.

    ·    =     [09.05] me= eting ends.

     

    _____________________= __________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_F085911F642A6847987ADA23E611780D1859F574hoshiunilux_-- From diego.dujovne@mail.udp.cl Thu Oct 3 03:23:52 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515521F8459 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 03:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5cItG+bZCBA for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 03:23:42 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id E2AEA21F9FCE for <6tsch@ietf.org>; Thu, 3 Oct 2013 03:23:31 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k14so2177299wgh.1 for <6tsch@ietf.org>; Thu, 03 Oct 2013 03:23:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=6E4K5cJEtLGjaQxxeIqLZno7KSEdNMG8jpVoODeOa2Q=; b=N4dHdOJIiOCmYyR1TWwJu8wtr0jEcXkDzXn41O/voW0TYXJolEz7mNGj6DiMsdL7nB +mxPSc4BIv+L9HxpEWdEFuFLv3TwM1YJMSehHCMDp4RzPO+L6WJT1YlASSDEwTgUXlOT yfhWUCfCEJEQQiNsxkJPQAXEcEFITAgM5s+Q0kD1ZgnYHXflBryb98+WI0iV4Z2Tp+oU X2I2kMVecTbptCeGQGF8d2soOM40Q8zDJE9i69+akj8SsZcqfConBLFTgFQ3GqfdeRTP ZQcSj+hDQEdAFy/10JwcVFcxizde6eWrwbOhtmOr7ue3NwcWrWLMdzTGxWze+xXwEa0f S5lg== X-Gm-Message-State: ALoCoQlDTeArFT4jvZ9fH8kK7Xrn2oseh33b0CPeBmHLGkkqdDZ/lXM0k86zWVOQ6RqRpZagUIBl MIME-Version: 1.0 X-Received: by 10.180.89.225 with SMTP id br1mr1785101wib.50.1380795809570; Thu, 03 Oct 2013 03:23:29 -0700 (PDT) Received: by 10.194.122.103 with HTTP; Thu, 3 Oct 2013 03:23:29 -0700 (PDT) Date: Thu, 3 Oct 2013 07:23:29 -0300 Message-ID: From: "Prof. Diego Dujovne" To: 6TSCH <6tsch@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 10:23:52 -0000 Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego --=20 DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 From xvilajosana@berkeley.edu Thu Oct 3 06:49:36 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BE21F89FF for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YQGXzcoNfDs for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 06:49:20 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF14121F8E97 for <6tsch@ietf.org>; Thu, 3 Oct 2013 06:45:40 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so2634592pab.18 for <6tsch@ietf.org>; Thu, 03 Oct 2013 06:45:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4o+2UeXIWG3n7+7m2xsBN/DZZr1Pwp3vVUkj9HPWOQE=; b=MGdqg3198WTz3J+lurYw+F4mBkQcZZF4m30RnsZZ2nFoViG7uq95cJSbs1Gk1OOrBy PPM5r5C9TSLk5AE0Fk39CaVeFvfg5NwV/y80j65Shuj/HEvlRhDsrKajSvP6tn2IApwQ K9YAGLm4fKLLiSC6z6P44xVKXWxvkqoZbnZh73Z/DqW158MMI8BIBVYFE4JYjQQBLNf4 R9bWU/lh7t/u5z4n2jstchRVUWFRYvqJxGL8loQlYq30bheJZICeqtQtRbQH8GXA7wzn ctAPJo3tJ0fHI6iUs8Mqv5YeUv3WPmEr4i//Rx/JkHLfHU9caqXOBQ7oAjM9YR7bpEit rLTA== X-Gm-Message-State: ALoCoQklkrnYLRMiLn3dYCGl3PmcjHs2MdG5XUOC+VG9lLeEC8te4n/67067B3hfw3uTahHXIbMo MIME-Version: 1.0 X-Received: by 10.68.11.41 with SMTP id n9mr584452pbb.164.1380807940433; Thu, 03 Oct 2013 06:45:40 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Thu, 3 Oct 2013 06:45:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Oct 2013 06:45:40 -0700 Message-ID: From: Xavier Vilajosana Guillen To: "Prof. Diego Dujovne" Content-Type: multipart/alternative; boundary=bcaec5215955caf54c04e7d6667c Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 13:49:36 -0000 --bcaec5215955caf54c04e7d6667c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start putting some rules of this mechanism on the table and prepare a simulation. I am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis -- i.e how do you maintain certain stability in the schedule (so you don't start installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual link requirements 3-how you recover from link collisions in case of multiple nodes schedule the same cells. 4-how to decide to who (what neighbor) install more links according to queue size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < diego.dujovne@mail.udp.cl> wrote: > Dear all, > I've been looking into the idea of "on the fly scheduling", > presented on the Sept 27th webex call as "on-the-fly decentralized > reservation". > The basic mechanism would be based on analysing the queue size > on a node and dynamically adapt the number of reserved > cells to satisfy queue size, delay and/or power > consumption thresholds. > This mechanism would work inside 6top, between pairs of nodes= . > As a first approach, it would be based on the minimal draft. > What do you think on this starting point? > I (gladly) receive comments to add or modify this proposal. > > Diego > > > > > -- > DIEGO DUJOVNE > Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones > Facultad de Ingenier=EDa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > --bcaec5215955caf54c04e7d6667c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Diego,

    +1

    it seems to a me a= very interesting idea to explore. Maybe we can start putting some rules of= this mechanism on the table and prepare a simulation. I am completely in w= ith that idea.

    Some questions arise:
    1-how fast do you react = to changes on the queue size to avoid hysteresis -- i.e how do you maintain= certain stability in the schedule (so you don't start installing and r= emoving links very often)
    2-how you map queue size (only one or if more than one queue) to actua= l link requirements
    3-how you recover from link collisions in= case of multiple nodes schedule the same cells.
    4-how to dec= ide to who (what neighbor) install more links according to queue size?

    cheers!
    Xavi
    =A0
    =


    On Thu, Oct 3= , 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl<= /a>> wrote:
    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    --bcaec5215955caf54c04e7d6667c-- From pthubert@cisco.com Thu Oct 3 07:16:42 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5BA21F9360 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 07:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVNE5eTnHF2k for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 07:16:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0D20421F942D for <6tsch@ietf.org>; Thu, 3 Oct 2013 07:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13042; q=dns/txt; s=iport; t=1380809425; x=1382019025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ot5HA0BoiVoYGo2R25NMRpMaLuygL+8MHNet9jmQK/k=; b=UXJzfxV/b6ZyDrdFdKvCAIfAET5nqB1ft6eY8bkcZPzUFEjLCGZ/9PM9 oxPACa5qOobL0i714/niIVu7FgDXVjd87KsNwId+DNnIe3mzpjdBN4PKt vi8wmogy9dTjbwagYuO8AbLFfB+6VRitPZxElmN5EYlzv90LVyOV5oEhM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAJ15TVKtJV2b/2dsb2JhbABZDoI1RDhSwT2BHhZ0giUBAQEEAQEBKhwlCxACAQgRAQMBAQsdBycLFAMGCAIEAQ0FCId+DLx0jhgBgQctAQMGAQYDgxaBBAOFT4MyoH+CZT+BcTk X-IronPort-AV: E=Sophos;i="4.90,1026,1371081600"; d="scan'208,217";a="267610215" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2013 14:09:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r93E9mte028258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 14:09:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 09:09:48 -0500 From: "Pascal Thubert (pthubert)" To: "xvilajosana@eecs.berkeley.edu" , "Prof. Diego Dujovne" Thread-Topic: [6tsch] On the fly scheduling Thread-Index: AQHOwD9pCGpYFOrKdkqRzVbO14Ql1ZnjAIxA Date: Thu, 3 Oct 2013 14:09:48 +0000 Deferred-Delivery: Thu, 3 Oct 2013 14:09:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.19] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:16:42 -0000 --_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 too. I think that the queue size matters at enqueue but the latency is really wh= at we care for at dequeue, that is how long did this device keep this messa= ge in queue (even if we are far from buffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre= ased. I agree with Xavi that we want to avoid changing the bundle size all the ti= me. We discussed that with Qin and others earlier on the ML. One way of inc= reasing the bundle dynamically at a very low cost (not even a hysteresis) = is to have it large amount of cells from the start but used like 10% by def= ault (xmit/listen happens only once in 10 time slots). A bit in the frame i= ndicates whether the next (normally unused) slot will indeed be used. The b= it can be present in the data and acked in the ack. This can also implicitl= y be triggered for retries. Please keep us tuned! Cheers, PS Note that Cisco has IPR on chaining time slots and flagging whether the = next is used or not. We already declared our IPR against the architecture d= raft and provided terms. Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X= avier Vilajosana Guillen Sent: jeudi 3 octobre 2013 15:46 To: Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start put= ting some rules of this mechanism on the table and prepare a simulation. I = am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st= art installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual lin= k requirements 3-how you recover from link collisions in case of multiple nodes schedule t= he same cells. 4-how to decide to who (what neighbor) install more links according to queu= e size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne > wrote: Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    +1 too.

     <= /p>

    I think that the queue si= ze matters at enqueue but the latency is really what we care for at dequeue= , that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions i= n such a device). If one of the 2 conditions (size at enqueue, latency at d= equeue) is reached then the bundle should be increased.

     <= /p>

    I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit= h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis)  is= to have it large amount of cells from the start but used like 10% by defau= lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind= icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

     <= /p>

    Please keep us tuned!

     <= /p>

    Cheers,=

     <= /p>

    PS Note that Cisco has IP= R on chaining time slots and flagging whether the next is used or not. We a= lready declared our IPR against the architecture draft and provided terms.

     <= /p>

    Pascal

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

     

    cheers!
    Xavi

     

     

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
                I've been looking into the idea o= f "on the fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
                This mechanism would work inside = 6top, between pairs of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

                  &nb= sp;                     &= nbsp;Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones
    Facultad de Ingenier=EDa UDP
    www.ingenieria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org=
    https://www.ietf.org/mailman/listinfo/6tsch

     

    --_000_E045AECD98228444A58C61C200AE1BD8414CEBBDxmbrcdx01ciscoc_-- From maria-rita.palattella@uni.lu Thu Oct 3 09:25:12 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6321E80F9 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 09:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp07KokIuMGT for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 09:25:01 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D021E811D for <6tsch@ietf.org>; Thu, 3 Oct 2013 09:11:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1026,1371074400"; d="scan'208,217";a="27020441" Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 03 Oct 2013 18:11:51 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 18:11:50 +0200 From: Maria Rita PALATTELLA To: "Pascal Thubert (pthubert)" , "xvilajosana@eecs.berkeley.edu" , "Prof. Diego Dujovne" Thread-Topic: [6tsch] On the fly scheduling Thread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gog== Date: Thu, 3 Oct 2013 16:11:49 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_" MIME-Version: 1.0 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:25:12 -0000 --_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Diego,( all) what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm). TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while buildin= g the schedule it minimizes the number of scheduled cells in order to reduc= e the network duty cycle. TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt. With a "on the fly solution", we will not need to know all this info a prio= ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells. Btw, I agree with all the points raised up by Xavi. We will have to addres= s his questions. And I support Pascal's suggestions about how to deal with bundle. Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal T= hubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling +1 too. I think that the queue size matters at enqueue but the latency is really wh= at we care for at dequeue, that is how long did this device keep this messa= ge in queue (even if we are far from buffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre= ased. I agree with Xavi that we want to avoid changing the bundle size all the ti= me. We discussed that with Qin and others earlier on the ML. One way of inc= reasing the bundle dynamically at a very low cost (not even a hysteresis) = is to have it large amount of cells from the start but used like 10% by def= ault (xmit/listen happens only once in 10 time slots). A bit in the frame i= ndicates whether the next (normally unused) slot will indeed be used. The b= it can be present in the data and acked in the ack. This can also implicitl= y be triggered for retries. Please keep us tuned! Cheers, PS Note that Cisco has IPR on chaining time slots and flagging whether the = next is used or not. We already declared our IPR against the architecture d= raft and provided terms. Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X= avier Vilajosana Guillen Sent: jeudi 3 octobre 2013 15:46 To: Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start put= ting some rules of this mechanism on the table and prepare a simulation. I = am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st= art installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual lin= k requirements 3-how you recover from link collisions in case of multiple nodes schedule t= he same cells. 4-how to decide to who (what neighbor) install more links according to queu= e size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne > wrote: Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Diego,( all)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, gene= rated by children). It gives priority to nodes with longer queues and it ai= ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.  We will have to a= ddress his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita


    From: 6tsch-bounces@ietf.org [6tsch-bounc= es@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    +1 too.

     

    I think that the queue = size matters at enqueue but the latency is really what we care for at deque= ue, that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions= in such a device). If one of the 2 conditions (size at enqueue, latency at= dequeue) is reached then the bundle should be increased.

     

    I agree with Xavi that = we want to avoid changing the bundle size all the time. We discussed that w= ith Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis)  is= to have it large amount of cells from the start but used like 10% by defau= lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind= icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

     

    Please keep us tuned!

     

    Cheers,

     

    PS Note that Cisco has = IPR on chaining time slots and flagging whether the next is used or not. We= already declared our IPR against the architecture draft and provided terms.

     

    Pascal

     

    From: 6tsch-= bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

     

    cheers!
    Xavi

     

     

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
                I've been looking into the idea o= f "on the fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
                This mechanism would work inside = 6top, between pairs of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

                  &nb= sp;                     &= nbsp;Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica= y Telecomunicaciones
    Facultad de Ingenier=EDa UDP
    www.ingenieria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    = 6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

     

    --_000_F085911F642A6847987ADA23E611780D1859FA68hoshiunilux_-- From twatteyne@gmail.com Thu Oct 3 10:03:08 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F921E80E9 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 10:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIe1moXvqOLO for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 10:03:00 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49511E8150 for <6tsch@ietf.org>; Thu, 3 Oct 2013 09:45:38 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so2715575pdj.36 for <6tsch@ietf.org>; Thu, 03 Oct 2013 09:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=4raz8HtuaTDmPWWjRAQCV5jmKzhKd2yC1t63I2gRVmg=; b=jUx/35iZaatxaHRFvDxmJ6DWUCIN9f7+sj7IR50mYoTYs5bD7ypjKoODjnwo8qOF2y KcS/geMGA9Ka3xMR/AK/c8veFiA823dmF2PbgJvPaqZWZk/c7bqrjNtrLPDy7tI2AT3I 5lqmHl695aia9ir2s9lM8DTWPjEI0mezp77eHMhVvcWovidV+UIv2u7PHbn4fHw6tOxt naqPekUix9Ae7qzFcQke6dDxgEE6p8T9hKEH4FAC9bk+DH/kR2WdXWFxIXZD8+YUcUWG 4kUupVb7YuJRvZkOzQ3nQqF/Y8XrMHoIJiH1sltBA7SFIyHkrQ53pMjZEi1iKxpzMbe7 SXTA== X-Received: by 10.66.121.201 with SMTP id lm9mr10556108pab.80.1380818738773; Thu, 03 Oct 2013 09:45:38 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 09:45:17 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Thu, 3 Oct 2013 09:45:17 -0700 X-Google-Sender-Auth: R0SsSS2s1EVoyv3VZOnwIbNbnIE Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b2e4ca46c859904e7d8eae5 Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:03:08 -0000 --047d7b2e4ca46c859904e7d8eae5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for the proposal. I believe it could be a very simple and powerful approach. Diego, would you agree that this can be considered a distributed mechanism sitting on top of 6top? That is, 6top provides: - commands to modify the number of soft cells in a bundle - commands to retrieve usage statistics of the cells/bundles The way I see it, your proposal consists of an algorithm which feeds from the usage statistics and triggers changes in the number of soft cells in a bundle. Correct? The questions to answer for now is whether 6top provides the right statistics. Maria Rita, one big difference with TASA is that OTF scheduling is distributed. Thomas On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < maria-rita.palattella@uni.lu> wrote: > Diego,( all) > > what you are suggesting (i.e., reserve cells based on queue size, delay) > is actually the main idea behind TASA (Traffic Aware Scheduling Algorithm= ). > > TASA builds the schedule based on the local (number of pkt generated by > the node) and global queue level ( i.e., local + pkt to be forwarded, > generated by children). It gives priority to nodes with longer queues and > it aims to reduce the latency for delivering the pkt. At the same time > while building the schedule it minimizes the number of scheduled cells in > order to reduce the network duty cycle. > TASA is centralized and thus it assumes that the PCE has all the info > needed for setting up the schedule. in other words, it knows the traffic > generated by each nodes, and the paths followed by each pkt. > With a "on the fly solution", we will not need to know all this info a > priori. but we will use 6top monitoring functions and the control flows > message for scheduling the cells. > > Btw, I agree with all the points raised up by Xavi. We will have to > address his questions. > > And I support Pascal's suggestions about how to deal with bundle. > > Maria Rita > > > ------------------------------ > *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of > Pascal Thubert (pthubert) [pthubert@cisco.com] > *Sent:* Thursday, October 03, 2013 4:09 PM > *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne > > *Cc:* 6TSCH > *Subject:* Re: [6tsch] On the fly scheduling > > +1 too. > > > > I think that the queue size matters at enqueue but the latency is really > what we care for at dequeue, that is how long did this device keep this > message in queue (even if we are far from > > buffer bloat conditions in such a device). If one of the 2 conditions > (size at enqueue, latency at dequeue) is reached then the bundle should b= e > increased. > > > > I agree with Xavi that we want to avoid changing the bundle size all the > time. We discussed that with Qin and others earlier on the ML. One way of > increasing the bundle dynamically at a very low cost (not even a > hysteresis) is to have it large amount of cells from the start but used > like 10% by default (xmit/listen happens only once in 10 time slots). A b= it > in the frame indicates whether the next (normally unused) slot will indee= d > be used. The bit can be present in the data and acked in the ack. This ca= n > also implicitly be triggered for retries. > > > > Please keep us tuned! > > > > Cheers, > > > > PS Note that Cisco has IPR on chaining time slots and flagging whether th= e > next is used or not. We already declared our IPR against the architecture > draft and provided terms. > > > > Pascal > > > > *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf > Of *Xavier Vilajosana Guillen > *Sent:* jeudi 3 octobre 2013 15:46 > *To:* Prof. Diego Dujovne > *Cc:* 6TSCH > *Subject:* Re: [6tsch] On the fly scheduling > > > > Diego, > > +1 > > it seems to a me a very interesting idea to explore. Maybe we can start > putting some rules of this mechanism on the table and prepare a simulatio= n. > I am completely in with that idea. > > Some questions arise: > > 1-how fast do you react to changes on the queue size to avoid hysteresis > -- i.e how do you maintain certain stability in the schedule (so you don'= t > start installing and removing links very often) > > 2-how you map queue size (only one or if more than one queue) to actual > link requirements > > 3-how you recover from link collisions in case of multiple nodes schedule > the same cells. > > 4-how to decide to who (what neighbor) install more links according to > queue size? > > > > cheers! > Xavi > > > > > > On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < > diego.dujovne@mail.udp.cl> wrote: > > Dear all, > I've been looking into the idea of "on the fly scheduling", > presented on the Sept 27th webex call as "on-the-fly decentralized > reservation". > The basic mechanism would be based on analysing the queue size > on a node and dynamically adapt the number of reserved > cells to satisfy queue size, delay and/or power > consumption thresholds. > This mechanism would work inside 6top, between pairs of nodes= . > As a first approach, it would be based on the minimal draft. > What do you think on this starting point? > I (gladly) receive comments to add or modify this proposal. > > Diego > > > > > -- > DIEGO DUJOVNE > Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones > Facultad de Ingenier=EDa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7b2e4ca46c859904e7d8eae5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    +1 for the proposal.

    I believe it could= be a very simple and powerful approach. Diego, would you agree that this c= an be considered a distributed mechanism sitting on top of 6top?

    That is, 6top provides:
    • commands to modify= the number of soft cells in a bundle
    • commands to retrieve usag= e statistics of the cells/bundles
    The way I see it, your prop= osal consists of an algorithm which feeds from the usage statistics and tri= ggers changes in the number of soft cells in a bundle. Correct?

    The questions to answer for now is whether 6top p= rovides the right statistics.

    Maria Rita, one big = difference with TASA is that OTF scheduling is distributed.

    Thomas

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <ma= ria-rita.palattella@uni.lu> wrote:
    Diego,( all)=

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita


    Fro= m: 6tsch-bo= unces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com]
    Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne

    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    +1 too.

    =A0

    I think that the queue si= ze matters at enqueue but the latency is really what we care for at dequeue= , that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions i= n such a device). If one of the 2 conditions (size at enqueue, latency at d= equeue) is reached then the bundle should be increased.

    =A0

    I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit= h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default = (xmit/listen happens only once in 10 time slots). A bit in the frame indica= tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IP= R on chaining time slots and flagging whether the next is used or not. We a= lready declared our IPR against the architecture draft and provided terms.

    =A0

    Pascal=

    =A0

    From: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci= ones
    Facultad de Ingenier=EDa UDP
    www.ingeni= eria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --047d7b2e4ca46c859904e7d8eae5-- From maria-rita.palattella@uni.lu Thu Oct 3 10:40:05 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4F11E8115 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7ojBKQRkI-4 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 10:39:55 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id DD9D011E8114 for <6tsch@ietf.org>; Thu, 3 Oct 2013 10:21:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1027,1371074400"; d="scan'208,217";a="27021821" Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 03 Oct 2013 19:21:24 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 19:21:24 +0200 From: Maria Rita PALATTELLA To: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Thread-Topic: [6tsch] On the fly scheduling Thread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAp3Ik= Date: Thu, 3 Oct 2013 17:21:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.9] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:40:05 -0000 --_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, of course! the idea behind is similar, but the approach is differen= t (centralized vs distributed). -------------------------------------------- Maria Rita, one big difference with TASA is that OTF scheduling is distribu= ted. Thomas On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA > wrote: Diego,( all) what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm). TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while buildin= g the schedule it minimizes the number of scheduled cells in order to reduc= e the network duty cycle. TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt. With a "on the fly solution", we will not need to know all this info a prio= ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells. Btw, I agree with all the points raised up by Xavi. We will have to addres= s his questions. And I support Pascal's suggestions about how to deal with bundle. Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@= ietf.org] on behalf of Pascal Thubert (pthub= ert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM To: xvilajosana@eecs.berkeley.edu; Pr= of. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling +1 too. I think that the queue size matters at enqueue but the latency is really wh= at we care for at dequeue, that is how long did this device keep this messa= ge in queue (even if we are far from buffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre= ased. I agree with Xavi that we want to avoid changing the bundle size all the ti= me. We discussed that with Qin and others earlier on the ML. One way of inc= reasing the bundle dynamically at a very low cost (not even a hysteresis) = is to have it large amount of cells from the start but used like 10% by def= ault (xmit/listen happens only once in 10 time slots). A bit in the frame i= ndicates whether the next (normally unused) slot will indeed be used. The b= it can be present in the data and acked in the ack. This can also implicitl= y be triggered for retries. Please keep us tuned! Cheers, PS Note that Cisco has IPR on chaining time slots and flagging whether the = next is used or not. We already declared our IPR against the architecture d= raft and provided terms. Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajos= ana Guillen Sent: jeudi 3 octobre 2013 15:46 To: Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start put= ting some rules of this mechanism on the table and prepare a simulation. I = am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st= art installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual lin= k requirements 3-how you recover from link collisions in case of multiple nodes schedule t= he same cells. 4-how to decide to who (what neighbor) install more links according to queu= e size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne > wrote: Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Thomas, of course! the idea behind is similar, but the app= roach is different (centralized vs distributed).

    --------------------------------------------

    Maria Rita, one big difference with TASA is that OTF scheduling is dis= tributed.

    Thomas

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALAT= TELLA <maria= -rita.palattella@uni.lu> wrote:
    Diego,( al= l)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, gene= rated by children). It gives priority to nodes with longer queues and it ai= ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.  We will have to a= ddress his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita


    Fro= m: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal Thubert (pthub= ert) [pthubert@cisc= o.com]
    Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne

    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    +1 too.

     

    I think that the queue = size matters at enqueue but the latency is really what we care for at deque= ue, that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions= in such a device). If one of the 2 conditions (size at enqueue, latency at= dequeue) is reached then the bundle should be increased.

     

    I agree with Xavi that = we want to avoid changing the bundle size all the time. We discussed that w= ith Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis)  is= to have it large amount of cells from the start but used like 10% by defau= lt (xmit/listen happens only once in 10 time slots). A bit in the frame ind= icates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

     

    Please keep us tuned!

     

    Cheers,

     

    PS Note that Cisco has = IPR on chaining time slots and flagging whether the next is used or not. We= already declared our IPR against the architecture draft and provided terms.

     

    Pascal

     

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

     

    cheers!
    Xavi

     

     

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
                I've been looking into the idea o= f "on the fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
                This mechanism would work inside = 6top, between pairs of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

                       =                  Diego=




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci= ones
    Facultad de Ingenier=EDa UDP
    www.ingeni= eria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --_000_F085911F642A6847987ADA23E611780D185A30FDhoshiunilux_-- From qinwang@berkeley.edu Thu Oct 3 12:50:09 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0318721F8D62 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 12:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqPHGTQCN4qA for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 12:49:57 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id E072121F9396 for <6tsch@ietf.org>; Thu, 3 Oct 2013 12:33:08 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id e14so6782017iej.34 for <6tsch@ietf.org>; Thu, 03 Oct 2013 12:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tJkFhg5IV7QtobbThcZz8GWSguZcOMPdcwpKtwkE4k0=; b=Kib0Yig6KWoQFx2AviLqYCtcfgX/RyHzPKJUFOh8CQxtNjwJWLeeT7U1DXjQfNxWLc bu2XCXqkVQLsfyhlGSUIjCuGYu/PV+gGLTyVHG2Cx7byI5Yjc9vzhUHlqVKgTNiJm1UB JPBJt8WGFWmHGucMZLhyKcUjnHGCRjJHAWbvomk6XU4B7G1p4o5M2Y2JZFNBNh8TQ8Lz gtdoHbsVoPmqxpw4xfQnowS9yrCrSoUXZTXuMPmF+g0AxSGHA0ycmqOr64HsS4CQhYZ4 MjPU2Y7ftZgJ4PBECBCJQbDSfq4B3iKz9D2wFnPs4qYNSbjtzBs1L2dUMvFi3iAc1O68 j/ig== X-Gm-Message-State: ALoCoQmQixMHm7RSB+tYG6PsbuKvbFqU825cKQPx2cs0yg52FfCvKL0ES8rtkk3QX6//XnMsLrxP MIME-Version: 1.0 X-Received: by 10.50.13.104 with SMTP id g8mr3539899igc.30.1380828788221; Thu, 03 Oct 2013 12:33:08 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Thu, 3 Oct 2013 12:33:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 03:33:08 +0800 Message-ID: From: Qin Wang To: Thomas Watteyne Content-Type: multipart/alternative; boundary=089e013c69c66af5ac04e7db4114 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:50:09 -0000 --089e013c69c66af5ac04e7db4114 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, +1 for the proposal. Regarding to how to approach, I agree with Thomas. There is an entity running on top of 6top, which reads queue information and other statistics information from 6top, sends instruction like create/delete softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the statistics information and the interface to/from 6top, and leave the specific algorithm open. What do you think? Qin On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne wrote: > +1 for the proposal. > > I believe it could be a very simple and powerful approach. Diego, would > you agree that this can be considered a distributed mechanism sitting on > top of 6top? > > That is, 6top provides: > > - commands to modify the number of soft cells in a bundle > - commands to retrieve usage statistics of the cells/bundles > > The way I see it, your proposal consists of an algorithm which feeds from > the usage statistics and triggers changes in the number of soft cells in = a > bundle. Correct? > > The questions to answer for now is whether 6top provides the right > statistics. > > Maria Rita, one big difference with TASA is that OTF scheduling is > distributed. > > Thomas > > On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < > maria-rita.palattella@uni.lu> wrote: > >> Diego,( all) >> >> what you are suggesting (i.e., reserve cells based on queue size, delay) >> is actually the main idea behind TASA (Traffic Aware Scheduling Algorith= m). >> >> TASA builds the schedule based on the local (number of pkt generated by >> the node) and global queue level ( i.e., local + pkt to be forwarded, >> generated by children). It gives priority to nodes with longer queues an= d >> it aims to reduce the latency for delivering the pkt. At the same time >> while building the schedule it minimizes the number of scheduled cells i= n >> order to reduce the network duty cycle. >> TASA is centralized and thus it assumes that the PCE has all the info >> needed for setting up the schedule. in other words, it knows the traffic >> generated by each nodes, and the paths followed by each pkt. >> With a "on the fly solution", we will not need to know all this info a >> priori. but we will use 6top monitoring functions and the control flows >> message for scheduling the cells. >> >> Btw, I agree with all the points raised up by Xavi. We will have to >> address his questions. >> >> And I support Pascal's suggestions about how to deal with bundle. >> >> Maria Rita >> >> >> ------------------------------ >> *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of >> Pascal Thubert (pthubert) [pthubert@cisco.com] >> *Sent:* Thursday, October 03, 2013 4:09 PM >> *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne >> >> *Cc:* 6TSCH >> *Subject:* Re: [6tsch] On the fly scheduling >> >> +1 too. >> >> >> >> I think that the queue size matters at enqueue but the latency is really >> what we care for at dequeue, that is how long did this device keep this >> message in queue (even if we are far from >> >> buffer bloat conditions in such a device). If one of the 2 conditions >> (size at enqueue, latency at dequeue) is reached then the bundle should = be >> increased. >> >> >> >> I agree with Xavi that we want to avoid changing the bundle size all the >> time. We discussed that with Qin and others earlier on the ML. One way o= f >> increasing the bundle dynamically at a very low cost (not even a >> hysteresis) is to have it large amount of cells from the start but used >> like 10% by default (xmit/listen happens only once in 10 time slots). A = bit >> in the frame indicates whether the next (normally unused) slot will inde= ed >> be used. The bit can be present in the data and acked in the ack. This c= an >> also implicitly be triggered for retries. >> >> >> >> Please keep us tuned! >> >> >> >> Cheers, >> >> >> >> PS Note that Cisco has IPR on chaining time slots and flagging whether >> the next is used or not. We already declared our IPR against the >> architecture draft and provided terms. >> >> >> >> Pascal >> >> >> >> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >> Behalf Of *Xavier Vilajosana Guillen >> *Sent:* jeudi 3 octobre 2013 15:46 >> *To:* Prof. Diego Dujovne >> *Cc:* 6TSCH >> *Subject:* Re: [6tsch] On the fly scheduling >> >> >> >> Diego, >> >> +1 >> >> it seems to a me a very interesting idea to explore. Maybe we can start >> putting some rules of this mechanism on the table and prepare a simulati= on. >> I am completely in with that idea. >> >> Some questions arise: >> >> 1-how fast do you react to changes on the queue size to avoid hysteresis >> -- i.e how do you maintain certain stability in the schedule (so you don= 't >> start installing and removing links very often) >> >> 2-how you map queue size (only one or if more than one queue) to actual >> link requirements >> >> 3-how you recover from link collisions in case of multiple nodes schedul= e >> the same cells. >> >> 4-how to decide to who (what neighbor) install more links according to >> queue size? >> >> >> >> cheers! >> Xavi >> >> >> >> >> >> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < >> diego.dujovne@mail.udp.cl> wrote: >> >> Dear all, >> I've been looking into the idea of "on the fly scheduling", >> presented on the Sept 27th webex call as "on-the-fly decentralized >> reservation". >> The basic mechanism would be based on analysing the queue size >> on a node and dynamically adapt the number of reserved >> cells to satisfy queue size, delay and/or power >> consumption thresholds. >> This mechanism would work inside 6top, between pairs of node= s. >> As a first approach, it would be based on the minimal draft. >> What do you think on this starting point? >> I (gladly) receive comments to add or modify this proposal. >> >> Diego >> >> >> >> >> -- >> DIEGO DUJOVNE >> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione= s >> Facultad de Ingenier=EDa UDP >> www.ingenieria.udp.cl >> (56 2) 676 8125 >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --089e013c69c66af5ac04e7db4114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi all,

    +1 for the proposal.=A0

    Regarding to how to approach, I agree with Thomas. There = is an entity running on top of 6top, which reads queue information and othe= r statistics information from 6top, sends instruction like create/delete so= ftcells to 6top. I think we can use the design methodology of Objective Fun= ction in RPL, i.e. define the statistics information and the interface to/f= rom 6top, and leave the specific algorithm open.

    What do you think?

    Qin=A0




    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu> wrote:
    +1 for the proposal.
    I believe it could be a very simple and powerful approach. Die= go, would you agree that this can be considered a distributed mechanism sit= ting on top of 6top?

    That is, 6top provides:
    • commands to modify= the number of soft cells in a bundle
    • commands to retrieve usag= e statistics of the cells/bundles
    The way I see it, your prop= osal consists of an algorithm which feeds from the usage statistics and tri= ggers changes in the number of soft cells in a bundle. Correct?

    The questions to answer for now is whether 6top p= rovides the right statistics.

    Maria Rita, one big = difference with TASA is that OTF scheduling is distributed.

    Thomas

    On Thu, Oct 3, 2013 at 9:11 AM, = Maria Rita PALATTELLA <maria-rita.palattella@uni.lu> wrote:
    Diego,( all)=

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita


    Fro= m: 6tsch-bo= unces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com]
    Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne

    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    +1 too.

    =A0

    I think that the queue si= ze matters at enqueue but the latency is really what we care for at dequeue= , that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions i= n such a device). If one of the 2 conditions (size at enqueue, latency at d= equeue) is reached then the bundle should be increased.

    =A0

    I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit= h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default = (xmit/listen happens only once in 10 time slots). A bit in the frame indica= tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IP= R on chaining time slots and flagging whether the next is used or not. We a= lready declared our IPR against the architecture draft and provided terms.

    =A0

    Pascal=

    =A0

    From: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci= ones
    Facultad de Ingenier=EDa UDP
    www.ingeni= eria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --089e013c69c66af5ac04e7db4114-- From twatteyne@gmail.com Thu Oct 3 13:27:48 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7210921E80C9 for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 13:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6k3-uvtdp9u for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 13:27:39 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E28B321F9AE3 for <6tsch@ietf.org>; Thu, 3 Oct 2013 13:11:35 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so2957087pbc.17 for <6tsch@ietf.org>; Thu, 03 Oct 2013 13:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=QPjeQyv5Tc9RVw39/cTACPlwYfI1ZjohVQEmmbB2QT4=; b=sWPsEvje1npUOOVeoRSxLutq+nfGoA4tjJ2wqTqHNzKezOu/1mGXI7cbGk7vGwksZF +nKeyFo28YQ8s253CQIB6MHrBLiqEBj9XEqnSJ3feLWlLcpQ8zSceiLuNpnqDHb1JEJW u0Ab/NtupTZ0272BEV2thRUM0r51y9te/GdasYjvoiNVHph3GVgMQbXvXr+P0DxNFs5L /g6Z7lr2aSZ+gUAJ7tKyQp6zG42AODoFXdZUVMH7BdhC2yguYNrz4sajZL3o1Elw8R6J URgimBsop1pnrVeeszM/EWzvauz/V/hNd9cJHAWvnlktY4l9dbQ3ZK6jGpEOxnZDyUBx YmnQ== X-Received: by 10.66.121.201 with SMTP id lm9mr11433584pab.80.1380831095570; Thu, 03 Oct 2013 13:11:35 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 13:11:15 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Thu, 3 Oct 2013 13:11:15 -0700 X-Google-Sender-Auth: l4spyEsYLTu5HqbT-zgdvjiao_E Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b2e4ca4f2491604e7dbca87 Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:27:48 -0000 --047d7b2e4ca4f2491604e7dbca87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That would indeed be clean. On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang wrote: > Hi all, > > +1 for the proposal. > > Regarding to how to approach, I agree with Thomas. There is an entity > running on top of 6top, which reads queue information and other statistic= s > information from 6top, sends instruction like create/delete softcells to > 6top. I think we can use the design methodology of Objective Function in > RPL, i.e. define the statistics information and the interface to/from 6to= p, > and leave the specific algorithm open. > > What do you think? > > Qin > > > > > On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote: > >> +1 for the proposal. >> >> I believe it could be a very simple and powerful approach. Diego, would >> you agree that this can be considered a distributed mechanism sitting on >> top of 6top? >> >> That is, 6top provides: >> >> - commands to modify the number of soft cells in a bundle >> - commands to retrieve usage statistics of the cells/bundles >> >> The way I see it, your proposal consists of an algorithm which feeds fro= m >> the usage statistics and triggers changes in the number of soft cells in= a >> bundle. Correct? >> >> The questions to answer for now is whether 6top provides the right >> statistics. >> >> Maria Rita, one big difference with TASA is that OTF scheduling is >> distributed. >> >> Thomas >> >> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < >> maria-rita.palattella@uni.lu> wrote: >> >>> Diego,( all) >>> >>> what you are suggesting (i.e., reserve cells based on queue size, delay= ) >>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorit= hm). >>> >>> TASA builds the schedule based on the local (number of pkt generated by >>> the node) and global queue level ( i.e., local + pkt to be forwarded, >>> generated by children). It gives priority to nodes with longer queues a= nd >>> it aims to reduce the latency for delivering the pkt. At the same time >>> while building the schedule it minimizes the number of scheduled cells = in >>> order to reduce the network duty cycle. >>> TASA is centralized and thus it assumes that the PCE has all the info >>> needed for setting up the schedule. in other words, it knows the traffi= c >>> generated by each nodes, and the paths followed by each pkt. >>> With a "on the fly solution", we will not need to know all this info a >>> priori. but we will use 6top monitoring functions and the control flows >>> message for scheduling the cells. >>> >>> Btw, I agree with all the points raised up by Xavi. We will have to >>> address his questions. >>> >>> And I support Pascal's suggestions about how to deal with bundle. >>> >>> Maria Rita >>> >>> >>> ------------------------------ >>> *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of >>> Pascal Thubert (pthubert) [pthubert@cisco.com] >>> *Sent:* Thursday, October 03, 2013 4:09 PM >>> *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne >>> >>> *Cc:* 6TSCH >>> *Subject:* Re: [6tsch] On the fly scheduling >>> >>> +1 too. >>> >>> >>> >>> I think that the queue size matters at enqueue but the latency is reall= y >>> what we care for at dequeue, that is how long did this device keep this >>> message in queue (even if we are far from >>> >>> buffer bloat conditions in such a device). If one of the 2 conditions >>> (size at enqueue, latency at dequeue) is reached then the bundle should= be >>> increased. >>> >>> >>> >>> I agree with Xavi that we want to avoid changing the bundle size all th= e >>> time. We discussed that with Qin and others earlier on the ML. One way = of >>> increasing the bundle dynamically at a very low cost (not even a >>> hysteresis) is to have it large amount of cells from the start but use= d >>> like 10% by default (xmit/listen happens only once in 10 time slots). A= bit >>> in the frame indicates whether the next (normally unused) slot will ind= eed >>> be used. The bit can be present in the data and acked in the ack. This = can >>> also implicitly be triggered for retries. >>> >>> >>> >>> Please keep us tuned! >>> >>> >>> >>> Cheers, >>> >>> >>> >>> PS Note that Cisco has IPR on chaining time slots and flagging whether >>> the next is used or not. We already declared our IPR against the >>> architecture draft and provided terms. >>> >>> >>> >>> Pascal >>> >>> >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Xavier Vilajosana Guillen >>> *Sent:* jeudi 3 octobre 2013 15:46 >>> *To:* Prof. Diego Dujovne >>> *Cc:* 6TSCH >>> *Subject:* Re: [6tsch] On the fly scheduling >>> >>> >>> >>> Diego, >>> >>> +1 >>> >>> it seems to a me a very interesting idea to explore. Maybe we can start >>> putting some rules of this mechanism on the table and prepare a simulat= ion. >>> I am completely in with that idea. >>> >>> Some questions arise: >>> >>> 1-how fast do you react to changes on the queue size to avoid hysteresi= s >>> -- i.e how do you maintain certain stability in the schedule (so you do= n't >>> start installing and removing links very often) >>> >>> 2-how you map queue size (only one or if more than one queue) to actual >>> link requirements >>> >>> 3-how you recover from link collisions in case of multiple nodes >>> schedule the same cells. >>> >>> 4-how to decide to who (what neighbor) install more links according to >>> queue size? >>> >>> >>> >>> cheers! >>> Xavi >>> >>> >>> >>> >>> >>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < >>> diego.dujovne@mail.udp.cl> wrote: >>> >>> Dear all, >>> I've been looking into the idea of "on the fly scheduling", >>> presented on the Sept 27th webex call as "on-the-fly decentralized >>> reservation". >>> The basic mechanism would be based on analysing the queue size >>> on a node and dynamically adapt the number of reserved >>> cells to satisfy queue size, delay and/or power >>> consumption thresholds. >>> This mechanism would work inside 6top, between pairs of >>> nodes. >>> As a first approach, it would be based on the minimal draft. >>> What do you think on this starting point? >>> I (gladly) receive comments to add or modify this proposal. >>> >>> Diego >>> >>> >>> >>> >>> -- >>> DIEGO DUJOVNE >>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion= es >>> Facultad de Ingenier=EDa UDP >>> www.ingenieria.udp.cl >>> (56 2) 676 8125 >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > --047d7b2e4ca4f2491604e7dbca87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    That would indeed be clean.


    On Thu, Oct 3, 2013 at 12:33 PM, Qin W= ang <qinwang@berkeley.edu> wrote:
    Hi all,

    = +1 for the proposal.=A0

    Regarding to how to approa= ch, I agree with Thomas. There is an entity running on top of 6top, which r= eads queue information and other statistics information from 6top, sends in= struction like create/delete softcells to 6top. I think we can use the desi= gn methodology of Objective Function in RPL, i.e. define the statistics inf= ormation and the interface to/from 6top, and leave the specific algorithm o= pen.

    What do you think?

    Qin=A0




    On Fri, Oct 4, 2013 at 12:45 AM, Thomas = Watteyne <watteyne@eecs.berkeley.edu> wrote:
    +1 for the proposal.
    I believe it could be a very simple and powerful approach. Die= go, would you agree that this can be considered a distributed mechanism sit= ting on top of 6top?

    That is, 6top provides:
    • commands to modify= the number of soft cells in a bundle
    • commands to retrieve usag= e statistics of the cells/bundles
    The way I see it, your prop= osal consists of an algorithm which feeds from the usage statistics and tri= ggers changes in the number of soft cells in a bundle. Correct?

    The questions to answer for now is whether 6top p= rovides the right statistics.

    Maria Rita, one big = difference with TASA is that OTF scheduling is distributed.

    Thomas
    <= br>
    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PA= LATTELLA <maria-rita.palattella@uni.lu> wrote:
    Diego,( all)=

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita


    Fro= m: 6tsch-bo= unces@ietf.org [6tsch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com]
    Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne

    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    +1 t= oo.

    =A0

    I think that the queue si= ze matters at enqueue but the latency is really what we care for at dequeue= , that is how long did this device keep this message in queue (even if we are far from

    buffer bloat conditions i= n such a device). If one of the 2 conditions (size at enqueue, latency at d= equeue) is reached then the bundle should be increased.

    =A0

    I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that wit= h Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis) =A0is to= have it large amount of cells from the start but used like 10% by default = (xmit/listen happens only once in 10 time slots). A bit in the frame indica= tes whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in = the ack. This can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IP= R on chaining time slots and flagging whether the next is used or not. We a= lready declared our IPR against the architecture draft and provided terms.

    =A0

    Pascal=

    =A0

    From: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaci= ones
    Facultad de Ingenier=EDa UDP
    www.ingeni= eria.udp.cl
    (56 2) 676 8125
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    --047d7b2e4ca4f2491604e7dbca87-- From jsimon@linear.com Thu Oct 3 15:13:57 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1721F92DA for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.739 X-Spam-Level: X-Spam-Status: No, score=-6.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqcdzT14icuo for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 15:13:47 -0700 (PDT) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) by ietfa.amsl.com (Postfix) with ESMTP id B706221E8088 for <6tsch@ietf.org>; Thu, 3 Oct 2013 15:13:26 -0700 (PDT) Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c11o145.mxlogic.net(mxl_mta-7.1.0-4) with ESMTP id ffbed425.0.159700.00-053.396319.p02c11o145.mxlogic.net (envelope-from ); Thu, 03 Oct 2013 16:13:26 -0600 (MDT) X-MXL-Hash: 524dec062a554bca-da9f2939d14a10981b3cf599af4e42ea6d9c5285 Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 24679740AA; Thu, 3 Oct 2013 15:13:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-86-951820348 From: Jonathan Simon In-Reply-To: Date: Thu, 3 Oct 2013 15:14:22 -0700 Message-Id: References: <7BC11E20-73E1-4A12-A227-02558705D01D@cisco.com> To: Thomas Watteyne X-Mailer: Apple Mail (2.1085) X-AnalysisOut: [v=2.0 cv=cbJlWA/M c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a] X-AnalysisOut: [=NzX3aWOS2tcA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqD] X-AnalysisOut: [INYqSAAAA:8 a=3-S2OSv7bqcA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVA] X-AnalysisOut: [AAA:8 a=zSnbybKbuWQXWYc7Ru4A:9 a=wPNLvfGTeEIA:10 a=19wCD08] X-AnalysisOut: [tTksA:10 a=vsVyj9psLt0A:10 a=w2H99WI3CKEA:10 a=qVizmW-ZYBI] X-AnalysisOut: [A:10 a=p-HxVa_ds0YA:10 a=N7QUBrEu1AEA:10 a=xLpt9-x9cSEA:10] X-AnalysisOut: [ a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=UdSnxWA8gpzTEcn2:21] X-AnalysisOut: [ a=qbXaAVqyAC118Fpf:21 a=tAZaB_pG_LsiCG7Dk-sA:9 a=_W_S_7Ve] X-AnalysisOut: [coQA:10 a=tXsnliwV7b4A:10 a=GBCknQyC7I178siX:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [12.218.215.72] Cc: 6tsch@ietf.org Subject: Re: [6tsch] set DAGRank to Join Priority X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 22:13:58 -0000 --Apple-Mail-86-951820348 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thomas - looking back at the various drafts of the standard, it was = changed from 0x00-0xFF to 0x00-0x3F between draft 1 and draft 2. There = are no ballot comments or instructions to the editor to make this = change, so it looks like a mistake that I never noticed and corrected. = The intention, if not the letter of the spec, was to use the full byte. --=20 Jonathan Simon, Ph. D Director of Systems Engineering Linear Technology, Dust Networks product group 30695 Huntwood Ave Hayward, CA 94544-7021 (510) 400-2936 (510) 489-3799 FAX jsimon@linear.com **LINEAR TECHNOLOGY CORPORATION**=20 *****Internet Email Confidentiality Notice*****=20 This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2936, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you.=20 On Sep 28, 2013, at 12:45 PM, Thomas Watteyne wrote: > Jonathan, >=20 > A clarifying question from the 6TiSCH group about the join priority = field. Any thoughts? I'm copy-pasting the figures in question: >=20 > Here, joinPriority seems to be capped at 0x3f, i.e. forcing two MSb to = 0. >=20 > >=20 > But in the packet, it takes up an entire byte. >=20 > >=20 > Why capping its internal value to 0x3f if there is space in the packet = to carry the complete byte? >=20 > Thanks, > Thomas >=20 > ---------- Forwarded message ---------- > From: Thomas Watteyne > Date: Sat, Sep 28, 2013 at 12:42 PM > Subject: Re: [6tsch] set DAGRank to Join Priority > To: "6tsch@ietf.org" <6tsch@ietf.org> >=20 >=20 > Qin, >=20 > In IEEE802.15.4e, Table 52b indeed shows a range of 0x00-0x3f. Yet, = Figure 48ee shows a 1-byte field. I'll go on a little hunt to understand = where those 2 bits went, will let you know. >=20 > Thomas >=20 >=20 > On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert (pthubert) = wrote: > Agreed >=20 > Say the rule is as discussed earlier: > Rank =3D sigma (etx*2*mh) where mh is 256. > Thus dagrank <=3D 2*sigma(etx) >=20 > Let us be honest, even with an etx of 3 this gives us 8 hops, which = leaves very little chances to deliver in time. >=20 > For a classical mesh we are shooting at 4 or 5 hops so 3f should be = enough. >=20 > For long and static lines, we may resort to hop count though.=20 > =20 > What do others think? >=20 > Pascal >=20 > Le 27 sept. 2013 =E0 23:34, "Xavier Vilajosana Guillen" = a =E9crit : >=20 >> Hi Qin, >>=20 >> well the rank is 2Byte, what i suggest is to divide it by 256 and = take this number as Join Priority (1Byte). If this number is bigger than = 0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a = strict requirement. >>=20 >> regards, >> Xavi >>=20 >>=20 >> On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang = wrote: >> Xavi, >>=20 >> You mean: >> if rank <=3D 0x3f then JoinPriority=3Drank else JoinPriority=3D0x3f >>=20 >> Correct? I think it could be a solution. >>=20 >> Thanks >> Qin >>=20 >>=20 >> On Sat, Sep 28, 2013 at 5:07 AM, Xavier Vilajosana Guillen = wrote: >> Hi Qin,=20 >>=20 >> my suggestion is to use JoinPriority[5:0] =3D (rank[15:8]&0x3F) or = 0x3F if bigger -- having a 0x3F would be like having INFINITE Join = Priority as in the case of RPL with ranks>65535. >>=20 >> would that not work? >> X >>=20 >>=20 >> On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang = wrote: >> Xavi, >>=20 >> Let's take the example in your draft to see what the problem is. = Please point out if I'm wrong. >> +-------+ >> | 0 | R(0)=3D0 >> | | DAGRank(R(0)) =3D 0 >> +-------+ >> | >> | >> +-------+ >> | 1 | R(1)=3DR(0)+683=3D683 >> | | DAGRank(R(1)) =3D 2 >> +-------+ >> | >> | >> +-------+ >> | 2 | R(2)=3DR(1)+683=3D1366 >> | | DAGRank(R(2)) =3D 5 >> +-------+ >> | >> | >> +-------+ >> | 3 | R(3)=3DR(2)+683=3D2049 >> | | DAGRank(R(3)) =3D 8 >> +-------+ >> | >> | >> +-------+ >> | 4 | R(4)=3DR(3)+683=3D2732 >> | | DAGRank(R(4)) =3D 10 >> +-------+ >> | >> | >> +-------+ >> | 5 | R(5)=3DR(4)+683=3D3415 >> | | DAGRank(R(5)) =3D 13 >> +-------+ >>=20 >> =46rom the example, you can see R(n) is a 2-byte integer, and DAGRank = is always the higher byte of the 2byte integer, because = minHopRankIncrease =3D 256. >>=20 >> If set JoinPriority =3D DAGRank, then it is possible JoinPriority> = 0x3f (although it unlikely happens often), out of its range.=20 >> If set JoinPriority[5:0] =3D DAGRank[7:2], (Is it your suggestion?), = a new node may found many existing nodes with same JoinPriority in = received EB. In another word, the JoinPriority can not provide = information about preferring joining. Right? >>=20 >> I haven't had good solution for it. So, I hope the range 0x00~0x3f is = not a "MUST" in IEEE802.15.4e. >>=20 >> What do you think? >> Qin=20 >>=20 >>=20 >>=20 >>=20 >> On Sat, Sep 28, 2013 at 2:30 AM, Xavier Vilajosana Guillen = wrote: >> Hi Qin, >>=20 >> after thinking a little bit on that maybe we can use the higher byte = of the rank for that. that is rank>>8, the higher byte is a = monotonically increasing counter. As each hop is <<8 (due to = minhopRankIncrease) we can have the sense of higher join priority as = higher the rank.=20 >>=20 >> In addition having if we have the limitation of 0x3F, this means that = we will support Join priorities up to 0x3F that translated to ranks are = 0x3F<<8 (big number) .. >>=20 >> just thoughts... >> X >>=20 >>=20 >> On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang = wrote: >> Hi Thomas, >>=20 >> I think with OF0 the DAGRank is uint8. But, in the Table 52b of = IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is = a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a = JoinPriority in 0x00~0x3f. Correct? >>=20 >> Would you please confirm with some expertise in IEEE802.15.4e if the = range 0x00~0x3f is a MUST or not? >>=20 >> Thanks >> Qin >>=20 >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >=20 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch >=20 >=20 >=20 >=20 >=20 > --=20 > Thomas Watteyne, Ph. D > Sr. Networking Design Engineer > Dust Networks / Linear Technology > 30695 Huntwood Ave > Hayward, CA 94544-7021 > +1 (510) 400-2978 > twatteyne@linear.com >=20 > This e-mail transmission, and any documents, files or previous e-mail = messages attached to it may contain confidential information that is = legally privileged. If you are not the intended recipient, or a person = responsible for delivering it to the intended recipient, you are hereby = notified that any disclosure, copying, distribution or use of any of the = information contained in or attached to this transmission is STRICTLY = PROHIBITED. If you have received this transmission in error, please = immediately notify me by reply e-mail, or by telephone at (510) = 400-2978, and destroy the original transmission and its attachments = without reading or saving in any manner. Thank you. --Apple-Mail-86-951820348 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    -- 
    Jonathan Simon, Ph. = D
    Director of Systems Engineering
    Linear Technology, Dust Networks = product group
    30695 Huntwood Ave
    Hayward, CA 94544-7021
    (510) = 400-2936
    (510) 489-3799 FAX
    jsimon@linear.com

    **LINEAR = TECHNOLOGY CORPORATION** 
    *****Internet Email = Confidentiality Notice***** 
     This e-mail = transmission, and any documents, files or previous = e-mail messages attached to it may contain confidential = information that is legally privileged. If you are not = the intended recipient, or a person responsible for delivering = it to the intended recipient, you are hereby notified that any = disclosure, copying, distribution or use of any of = the information contained in or attached to this transmission = is STRICTLY PROHIBITED. If you have received this transmission = in error, please immediately notify me by reply e-mail, or by = telephone at (510) 400-2936, and destroy the original transmission = and its attachments without reading or saving in any manner. = Thank you. 
    On Sep 28, 2013, at 12:45 PM, Thomas Watteyne = wrote:

    Jonathan,

    A clarifying = question from the 6TiSCH group about the join priority field. Any = thoughts? I'm copy-pasting the figures in = question:

    Here, joinPriority seems to be capped = at 0x3f, i.e. forcing two MSb to 0.
    =

    <image.png>

    But in the packet, it takes up an entire = byte.

    <image.png>

    Why capping its internal value to 0x3f if there is space in the = packet to carry the complete = byte?

    Thanks,
    Thomas

    ---------- Forwarded message ----------
    From: Thomas Watteyne <watteyne@eecs.berkeley.edu&= gt;
    Date: Sat, Sep 28, 2013 at 12:42 PM
    Subject: Re: = [6tsch] set DAGRank to Join Priority
    To: "6tsch@ietf.org" <6tsch@ietf.org>


    Qin,

    In IEEE802.15.4e, = Table 52b indeed shows a range of 0x00-0x3f. Yet, Figure 48ee shows a = 1-byte field. I'll go on a little hunt to understand where those 2 bits = went, will let you know.

    Thomas


    On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert = (pthubert) <pthubert@cisco.com> wrote:
    Agreed

    Say the rule is as discussed earlier:
    Rank =3D sigma (etx*2*mh) where mh is 256.
    Thus dagrank <=3D 2*sigma(etx)

    Let us be honest, even with an etx of 3 this gives us 8 hops, which = leaves very little chances to deliver in time.

    For a classical mesh we are shooting at 4 or 5 hops so 3f should be = enough.

    For long and static lines, we may resort to hop count = though. 
     
    What do others think?

    Pascal

    Le 27 sept. 2013 =E0 23:34, "Xavier Vilajosana Guillen" <xvilajosana@eecs.berkeley.edu> a = =E9crit :

    Hi Qin,

    well the rank is 2Byte, what i suggest is to divide it by 256 and = take this number as Join Priority (1Byte). If this number is bigger than = 0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a = strict requirement.

    regards,
    Xavi


    On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang = <qinwang@berkeley.edu> wrote:
    Xavi,

    You mean:
    if rank <=3D 0x3f then JoinPriority=3Drank else = JoinPriority=3D0x3f

    Correct? I think it could be a solution.

    Thanks
    Qin


    On Sat, Sep 28, 2013 at 5:07 AM, Xavier = Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> = wrote:
    Hi Qin, 

    my suggestion is to use JoinPriority[5:0] = =3D (rank[15:8]&0x3F) or 0x3F if bigger -- having a 0x3F would be = like having INFINITE Join Priority as in the case of RPL with = ranks>65535.

    would = that not work?
    X


    On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang = <qinwang@berkeley.edu> wrote:
    Xavi,

    Let's take the example in your draft to see what the problem is. = Please point out if I'm wrong.
    +-------+
         |   0   | R(0)=3D0
         |       | DAGRank(R(0)) =3D = 0
         +-------+
             |
             |
         +-------+
         |   1   | R(1)=3DR(0)+683=3D683
         |       | DAGRank(R(1)) =3D = 2
         +-------+
             |
             |
         +-------+
         |   2   | R(2)=3DR(1)+683=3D1366
         |       | DAGRank(R(2)) =3D = 5
         +-------+
             |
             |
         +-------+
         |   3   | R(3)=3DR(2)+683=3D2049
         |       | DAGRank(R(3)) =3D = 8
         +-------+
             |
             |
         +-------+
         |   4   | R(4)=3DR(3)+683=3D2732
         |       | DAGRank(R(4)) =3D = 10
         +-------+
             |
             |
         +-------+
         |   5   | R(5)=3DR(4)+683=3D3415
         |       | DAGRank(R(5)) =3D = 13
         +-------+

    =46rom the example, you can see R(n) is a 2-byte integer, and = DAGRank is always the higher byte of the 2byte integer, = because minHopRankIncrease =3D 256.

    If set JoinPriority =3D DAGRank, then it is possible = JoinPriority> 0x3f (although it unlikely happens often), out of its = range. 
    If set JoinPriority[5:0] =3D DAGRank[7:2], (Is it your = suggestion?), a new node may found many existing nodes with same = JoinPriority in received EB. In another word, the JoinPriority can not = provide information about preferring joining. Right?

    I haven't had good solution for it. So, I hope the range 0x00~0x3f = is not a "MUST" in IEEE802.15.4e.

    What  do you think?
    Qin 




    On Sat, Sep 28, 2013 at 2:30 AM, Xavier = Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> = wrote:
    Hi Qin,

    after thinking a little bit on that maybe we can use the higher byte of = the rank for that. that is  rank>>8, the higher byte is a = monotonically increasing counter. As each hop is <<8 (due to = minhopRankIncrease) we can have the sense of higher join priority as higher the rank.

    In addition having if we have the limitation of 0x3F, this means that we = will support Join priorities up to 0x3F that translated to ranks are = 0x3F<<8 (big number) ..

    just thoughts...
    X


    On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <qinwang@berkeley.edu> wrote:
    Hi Thomas,

    I think with OF0 the DAGRank is uint8. But, in the Table 52b of = IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is = a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a = JoinPriority in 0x00~0x3f. Correct?

    Would you please confirm with some expertise in IEEE802.15.4e if = the range 0x00~0x3f is a MUST or not?

    Thanks
    Qin

    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    = https://www.ietf.org/mailman/listinfo/6tsch






    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    https://www.ietf.org/mailman/listinfo/6tsch

    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    = https://www.ietf.org/mailman/listinfo/6tsch





    -- =
    Thomas Watteyne, Ph. D
    Sr. Networking Design = Engineer
    Dust Networks / Linear Technology
    30695 = Huntwood Ave
    Hayward, CA 94544-7021
    +1 (510) 400-2978

    This e-mail transmission, and any = documents, files or previous e-mail messages attached to it may contain = confidential information that is legally privileged. If you are not the = intended recipient, or a person responsible for delivering it to the = intended recipient, you are hereby notified that any disclosure, = copying, distribution or use of any of the information contained in or = attached to this transmission is STRICTLY PROHIBITED. If you have = received this transmission in error, please immediately notify me by = reply e-mail, or by telephone at (510) 400-2978, and destroy the = original transmission and its attachments without reading or saving in = any manner. Thank you.

    = --Apple-Mail-86-951820348-- From twatteyne@gmail.com Thu Oct 3 15:47:00 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2329221F923D for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 15:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhIpGATYKY3p for <6tsch@ietfa.amsl.com>; Thu, 3 Oct 2013 15:46:53 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7221E8082 for <6tsch@ietf.org>; Thu, 3 Oct 2013 15:45:59 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so3104532pdj.39 for <6tsch@ietf.org>; Thu, 03 Oct 2013 15:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=pEpqsnjQbPsNSZZNh2cQjsOHQYbBJ0ye9ZNZdsMc2b0=; b=0f8J/xn0XEiNxelyWQQafcvy3qQzCyltpQCzoRySiPG3q4CEROXAzxp7e/n/hPJDnb nF9akGBY8f4Qj+VvIU36+Fu6GSaRqW6gGE51ZM3W1AlzG8MYt8k9HWeE7Mk7kqE/O2sZ JqTI91w/dZ0OrugWlm2C4timeQ+6yPUG0JHr57NUZrnR412slYcOz9Xbiw5swTvm7ffR ue8Arg9G0kUa/YMr+RYFOM7DtRCBs519RGPNCU9rE8grCTUfrstTNKfMCTPKxRu5xTVM q2GH9d6FJNrKs/uIzRY4do/ToBPS9mpXzh1XqUGqgh51vErNkvvPVXoXmmPPdScTK3qK VS3w== X-Received: by 10.66.155.102 with SMTP id vv6mr12058942pab.89.1380840359405; Thu, 03 Oct 2013 15:45:59 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Thu, 3 Oct 2013 15:45:39 -0700 (PDT) From: Thomas Watteyne Date: Thu, 3 Oct 2013 15:45:39 -0700 X-Google-Sender-Auth: j5t0Qopm8_38NWbrguwmSOi2CIA Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b86e3a81d316504e7ddf334 Subject: [6tsch] Agenda webex 4 October 2013 X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 22:47:00 -0000 --047d7b86e3a81d316504e7ddf334 Content-Type: text/plain; charset=ISO-8859-1 All, The proposed agenda for the 6TiSCH call is: - Administrivia [3min] - Approval agenda - Approval minutes last call - IETF88: preliminary agenda - minimal draft [5min] - join priority width - comments/changes - update models draft [35min] - summary Tuesday discussion - proposed ToC - 6lo thread on monitoring - communication paradigms - on-the-fly scheduling [15min] - overview - discussion - goals and next steps? - AOB [2min] You will find a detailed agenda at https://bitbucket.org/6tsch/meetings/wiki/131004_webex. As usual, feel free to propose any changes to the agenda, also at the beginning of the call. Remember that this call will be recorded. Pascal & Thomas ---- Topic: 6TSCH Weekly Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 206 802 913 Meeting Password: sixtus ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D 2. Log in to your account. 3. Click "Start Now". 4. Follow the instructions that appear on your screen. ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ciscosales.webex.com/ciscosales/systemdiagnosis.php http://www.webex.com CCM:+14085256800x206802913 --047d7b86e3a81d316504e7ddf334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    All,

    The proposed agenda for= the 6TiSCH call is:
    • Administrivia [3min]
      • App= roval agenda
      • Approval minutes last call
      • IETF88: preliminary= agenda
    • minimal draft=A0[5min]
      • join priority width
      • comments/changes
    • update models draft [35min]
      • = summary Tuesday discussion
      • proposed ToC
      • 6lo thread on monit= oring
      • communication paradigms
    • on-the-fly scheduling [15min]
      • =
      • overview
      • discussion
      • goals and next steps?
      =
    • AOB [2min]

    You will find a detai= led agenda at https://bitbucket.org/6tsch/meetings/wiki/131004_webex.

    As usual, feel free to propose any changes to the= agenda, also at the beginning of the call.

    Rememb= er that this call will be recorded.

    Pascal & T= homas

    ----

    Topic: 6TSCH Weekly
    =
    Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=A0
    Meeting Number: 206 802 913=A0
    Meeting Password: sixtus=A0=

    -------------------------------------------------------= =A0
    To start the online meeting=A0
    --------------------= -----------------------------------=A0
    2. Log in to your account.=A0
    3. Click "Start Now"= .=A0
    4. Follow the instructions that appear on your screen.=A0

    ----------------------------------------------------= ------------=A0
    ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=A0
    ----------------------------------------------------------------=A0=

    The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.=A0

    Please dial the local access number for your area from = the list below:=A0
    - San Jose/Milpitas (408) area: 525-6800=A0
    - RTP (919) area: 392-3330=A0

    ------------= -------------------------------------------=A0
    To join the teleconference only=A0
    -------------------------= ------------------------------=A0
    1. Dial into Cisco WebEx (view = all Global Access Numbers at=A0
    2. Follow the prompts to enter the Meeting Number (listed above) or Ac= cess Code followed by the # sign.=A0

    San Jose, CA:= +1.40= 8.525.6800 RTP: +1.919.392.3330=A0

    US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824= .0117=A0

    India: +91.80.4350.1111 Germany: +49.619.= 6773.9002=A0

    Japan: +81.3.5763.9394 China: +86.10.8515.5666=A0
    =

    To check whether you have the appropriate players insta= lled for UCF (Universal Communications Format) rich media files, go to https:/= /ciscosales.webex.com/ciscosales/systemdiagnosis.php=A0


    --047d7b86e3a81d316504e7ddf334-- From maria-rita.palattella@uni.lu Fri Oct 4 00:19:54 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8367421F963F for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 00:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d6pgFy2-NW3 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 00:19:34 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0061121F9AD8 for <6tsch@ietf.org>; Fri, 4 Oct 2013 00:19:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1031,1371074400"; d="scan'208,217";a="27030876" Received: from unknown (HELO Travis.uni.lux) ([10.21.2.19]) by hercules.uni.lu with ESMTP; 04 Oct 2013 09:18:58 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 09:18:57 +0200 From: Maria Rita PALATTELLA To: Thomas Watteyne , 6TSCH <6tsch@ietf.org> Thread-Topic: [6tsch] On the fly scheduling Thread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAu5gCAAAqmgIAA2b5g Date: Fri, 4 Oct 2013 07:18:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.70] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 07:19:54 -0000 --_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 for me too. For sure, according to the specific requirements of the applications, diffe= rent algorithms may be used for building the schedule. But the functionalit= ies offers by 6top (i.e., collect statist. Info, send commands for scheduli= ng cells) will be still the same (no matter which algorithm is used). The statistics needed could change because different algorithms may use dif= ferent input as parameters. So, we will have to include a set of statistic= information, or anyway, make sure it is possible to extend them. Maria Rita From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of T= homas Watteyne Sent: Thursday, October 03, 2013 10:11 PM To: 6TSCH Subject: Re: [6tsch] On the fly scheduling That would indeed be clean. On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang > wrote: Hi all, +1 for the proposal. Regarding to how to approach, I agree with Thomas. There is an entity runni= ng on top of 6top, which reads queue information and other statistics infor= mation from 6top, sends instruction like create/delete softcells to 6top. I= think we can use the design methodology of Objective Function in RPL, i.e.= define the statistics information and the interface to/from 6top, and leav= e the specific algorithm open. What do you think? Qin On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne > wrote: +1 for the proposal. I believe it could be a very simple and powerful approach. Diego, would you= agree that this can be considered a distributed mechanism sitting on top o= f 6top? That is, 6top provides: * commands to modify the number of soft cells in a bundle * commands to retrieve usage statistics of the cells/bundles The way I see it, your proposal consists of an algorithm which feeds from t= he usage statistics and triggers changes in the number of soft cells in a b= undle. Correct? The questions to answer for now is whether 6top provides the right statisti= cs. Maria Rita, one big difference with TASA is that OTF scheduling is distribu= ted. Thomas On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA > wrote: Diego,( all) what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm). TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while buildin= g the schedule it minimizes the number of scheduled cells in order to reduc= e the network duty cycle. TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt. With a "on the fly solution", we will not need to know all this info a prio= ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells. Btw, I agree with all the points raised up by Xavi. We will have to addres= s his questions. And I support Pascal's suggestions about how to deal with bundle. Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@= ietf.org] on behalf of Pascal Thubert (pthub= ert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM To: xvilajosana@eecs.berkeley.edu; Pr= of. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling +1 too. I think that the queue size matters at enqueue but the latency is really wh= at we care for at dequeue, that is how long did this device keep this messa= ge in queue (even if we are far from buffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre= ased. I agree with Xavi that we want to avoid changing the bundle size all the ti= me. We discussed that with Qin and others earlier on the ML. One way of inc= reasing the bundle dynamically at a very low cost (not even a hysteresis) = is to have it large amount of cells from the start but used like 10% by def= ault (xmit/listen happens only once in 10 time slots). A bit in the frame i= ndicates whether the next (normally unused) slot will indeed be used. The b= it can be present in the data and acked in the ack. This can also implicitl= y be triggered for retries. Please keep us tuned! Cheers, PS Note that Cisco has IPR on chaining time slots and flagging whether the = next is used or not. We already declared our IPR against the architecture d= raft and provided terms. Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajos= ana Guillen Sent: jeudi 3 octobre 2013 15:46 To: Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start put= ting some rules of this mechanism on the table and prepare a simulation. I = am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st= art installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual lin= k requirements 3-how you recover from link collisions in case of multiple nodes schedule t= he same cells. 4-how to decide to who (what neighbor) install more links according to queu= e size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne > wrote: Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    +1 for me too.

     <= /p>

    For sure, according to th= e specific requirements of the applications, different algorithms may be us= ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

     <= /p>

    The statistics needed cou= ld change because different algorithms may use different input as parameter= s.  So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.

     <= /p>

    Maria Rita

     <= /p>

     <= /p>

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    That would indeed be clean.

     

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wrote:

    Hi all,

     

    +1 for the proposal. 

     

    Regarding to how to approach, I agree with Thomas. T= here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele= te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

     

    What do you think?

     

    Qin 

     

     

     

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    +1 for the proposal.

     

    I believe it could be a very simple and powerful app= roach. Diego, would you agree that this can be considered a distributed mec= hanism sitting on top of 6top?

     

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
    • commands to retrieve usage statistics of the cells/bundles
      • <= /ul>

      The way I see it, your proposal consists of an algor= ithm which feeds from the usage statistics and triggers changes in the numb= er of soft cells in a bundle. Correct?

     

    The questions to answer for now is whether 6top prov= ides the right statistics.

     

    Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.

     

    Thomas

     

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL= A <mar= ia-rita.palattella@uni.lu> wrote:

    Diego,( a= ll)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, gene= rated by children). It gives priority to nodes with longer queues and it ai= ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.  We will have to a= ddress his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From: 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne    =


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    +1 too.

     

    I think that the queue size matters at = enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions in such a devic= e). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased.

     

    I agree with Xavi that we want to avoid= changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis)  is to have it la= rge amount of cells from the start but used like 10% by default (xmit/liste= n happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

     

    Please keep us tuned!=

     

    Cheers,

     

    PS Note that Cisco has IPR on chaining = time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

     

    Pascal

     

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    Diego,

    +1

    it seems to a me a very interesting idea to explore. Maybe we can start = putting some rules of this mechanism on the table and prepare a simulation.= I am completely in with that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size to avoid hyst= eresis -- i.e how do you maintain certain stability in the schedule (so you= don't start installing and removing links very often)

    2-how you map queue size (only one or if more than one queue) to a= ctual link requirements

    3-how you recover from link collisions in case of multiple nodes s= chedule the same cells.

    4-how to decide to who (what neighbor) install more links accordin= g to queue size?

     

    cheers!
    Xavi

     

     

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp= .cl> wrote:

    Dear all,
                I've been looking into the idea o= f "on the fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
                This mechanism would work inside = 6top, between pairs of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

                         = ;                Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_-- From maria-rita.palattella@uni.lu Fri Oct 4 00:58:04 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D6421F9A5F for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 00:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyf2MwZsRI8T for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 00:57:50 -0700 (PDT) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC121F9BA4 for <6tsch@ietf.org>; Fri, 4 Oct 2013 00:52:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1031,1371074400"; d="scan'208,217";a="27031923" Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 04 Oct 2013 09:52:51 +0200 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 09:52:51 +0200 From: Maria Rita PALATTELLA To: "xvilajosana@eecs.berkeley.edu" , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] renaming of minimal draft repository Thread-Index: AQHOvvBgscfDNrr66EqkfEuHbUvgSZnkLPxQ Date: Fri, 4 Oct 2013 07:52:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.91.0.70] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] renaming of minimal draft repository X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 07:58:04 -0000 --_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Xavi, I have gone through the draft, and I have *really minor* comments (most of = the points were already fixed by Thomas' review). Sorry for not having provided my feedback before. Typos: Timming -> timing (there is an extra m) In the terminology draft and lln-tsch draft, please replace P= alattella M., with Palattella M.R. Comment1: we have renamed the draft Minimal 6TSCH configuration, but you st= ill have 6tsch-basic as short title in the draft header, and you referee to= basic schedule within the draft (there are several occurrences). Shouldn't we talk of Minimal schedule, in order to be coherent? It is just a thought... Comment2: I agree with Thomas that we have to specify clearly that empty sl= ots (from 6 to 100) can be scheduled dynamically if needed. Otherwise, we c= annot use this minimal configuration for running distributed algorithms, li= ke the "on the fly scheduling" one. Maria Rita From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of X= avier Vilajosana Guillen Sent: Tuesday, October 01, 2013 11:51 PM To: 6tsch@ietf.org Subject: [6tsch] renaming of minimal draft repository Hello, I renamed the minimal draft repository at bitbucket (draft-vilajosana-6tisc= h-minimal). Please use the new URL from now on. https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Home I also addressed Thomas comments. thanks! Xavi --_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Xavi,

    I have gone through the d= raft, and I have *really minor* comments (most of the points were al= ready fixed by Thomas’ review).

    Sorry for not having prov= ided my feedback before.

     <= /p>

    Typos: Timming -> timing (there is an extra m)

        &= nbsp;         In the terminology dr= aft and lln-tsch draft, please replace Palattella M., with Palattella M.= R.

     <= /p>

    Comment1: we have renamed the draft Minimal 6TSCH configuration, but you still have 6tsch-basic a= s short title in the draft header, and you referee to basic schedule within the draft (there are several occurrences).

    Shouldn’t we talk o= f Minimal schedule, in order to be coherent?

    It is just a thought̷= 0;

     <= /p>

    Comment2: I agree with Thomas that we have to specify clear= ly that empty slots (from 6 to 100) can be scheduled dynamically if needed. O= therwise, we cannot use this minimal configuration for running distributed = algorithms, like the “on the fly scheduling” one.

     <= /p>

    Maria Rita

     <= /p>

     <= /p>

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 11:51 PM
    To: 6tsch@ietf.org
    Subject: [6tsch] renaming of minimal draft repository

     

    Hello,

    I renamed the minimal= draft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please us= e the new URL from now on.

    https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Hom= e

    I also addressed Thom= as comments.

    thanks!
    Xavi

     

    --_000_F085911F642A6847987ADA23E611780D185A39D8hoshiunilux_-- From pthubert@cisco.com Fri Oct 4 02:32:17 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E721F9BF3 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 02:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkRS1dCM+EUy for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 02:32:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2422921F99F3 for <6tsch@ietf.org>; Fri, 4 Oct 2013 02:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41548; q=dns/txt; s=iport; t=1380879029; x=1382088629; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Mdi0iYDT3uUoXDKZqqO/EtRZrG+3ECvDs8h8M4iOGl4=; b=K6S5dKavAgfeGO+7Z7mqt4KT4BkVouUR3HDhVWkPSxESJ1VnxT9dM2aQ 4Jti+/xFpq7GMziVFjaB1AjDlZ7gAz+ucDzjm1ZgGhB+BOLYLT2AuPh+y /CLw8b+QlZdjyPmcHm8LB2jyrKoUKqBVk2zBmRUWqAbllh3OMh9kRQu3x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAHKJTlKtJV2c/2dsb2JhbABZDoI1RDhSwUiBGxZ0giUBAQEEAQEBKhwlGwIBCBEBAwEBCxYBBgcnCxQDBggCBAESCBOHawy8Bo4YAYEHBCMGAQkBBoMZgQQDhU+DMosjlVyCZT+BaAcCFyI X-IronPort-AV: E=Sophos;i="4.90,1031,1371081600"; d="scan'208,217";a="268100345" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 04 Oct 2013 09:30:25 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r949UPGO010724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 09:30:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 04:30:25 -0500 From: "Pascal Thubert (pthubert)" To: Maria Rita PALATTELLA , Thomas Watteyne , 6TSCH <6tsch@ietf.org> Thread-Topic: [6tsch] On the fly scheduling Thread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAu5gCAAAqmgIAA2b5ggAAYjzA= Date: Fri, 4 Oct 2013 09:30:24 +0000 Deferred-Delivery: Fri, 4 Oct 2013 09:30:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.19] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:32:18 -0000 --_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: Statistics and hysteresis can be costly in terms of memory and CPU, may not= be the best strategy to address bursts of traffic in a stochastic IP netwo= rk, and the strategy to derive the allocation from the past observation may= be hard to determine in a particular case and even harder to generalize. The needs of bandwidth may be very dynamic for instance in the case of alar= ms/alerts, or in the case of a brutal variation of monitored data. Changes = in the network topology impacting the rank of a node within the DAG may als= o impact brutally its needs of bandwidth. So we cannot only rely on past ob= servations and but also need to maintain some capabilities that rely on cur= rent needs that operate efficiently in terms of control and yet very dynami= cally to accept both brutal bursts of traffic and longer term variations. Considering that we have ample room in a SlotFrame, a simple strategy, deri= ved from traditional memory management, could be to augment the number of c= ells in a bundle each time it is saturated. As an image, GNU's obstack seem= to grow linearly one chunk at a time, but I know of chunk implementations = that double the size of a dynamic chunk each time it is saturated and a geo= metrical growth may a better approach for us. In a bundle, a portion of the cells is always on. The rest can stay idle (n= o wake to send or listen) unless a previous cell indicates that there is mo= re to come. If we agree on a strategy like this then we can start working o= ut the details, in particular how handle lazy release or one-shot override,= how we observe unallocated slots to make them candidate for allocation, et= c... As you see, even implementing such a simple strategy can already be quite s= ome work in a constrained device. Cheers, Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of M= aria Rita PALATTELLA Sent: vendredi 4 octobre 2013 09:19 To: Thomas Watteyne; 6TSCH Subject: Re: [6tsch] On the fly scheduling +1 for me too. For sure, according to the specific requirements of the applications, diffe= rent algorithms may be used for building the schedule. But the functionalit= ies offers by 6top (i.e., collect statist. Info, send commands for scheduli= ng cells) will be still the same (no matter which algorithm is used). The statistics needed could change because different algorithms may use dif= ferent input as parameters. So, we will have to include a set of statistic= information, or anyway, make sure it is possible to extend them. Maria Rita From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Thomas Watteyne Sent: Thursday, October 03, 2013 10:11 PM To: 6TSCH Subject: Re: [6tsch] On the fly scheduling That would indeed be clean. On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang > wrote: Hi all, +1 for the proposal. Regarding to how to approach, I agree with Thomas. There is an entity runni= ng on top of 6top, which reads queue information and other statistics infor= mation from 6top, sends instruction like create/delete softcells to 6top. I= think we can use the design methodology of Objective Function in RPL, i.e.= define the statistics information and the interface to/from 6top, and leav= e the specific algorithm open. What do you think? Qin On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne > wrote: +1 for the proposal. I believe it could be a very simple and powerful approach. Diego, would you= agree that this can be considered a distributed mechanism sitting on top o= f 6top? That is, 6top provides: * commands to modify the number of soft cells in a bundle * commands to retrieve usage statistics of the cells/bundles The way I see it, your proposal consists of an algorithm which feeds from t= he usage statistics and triggers changes in the number of soft cells in a b= undle. Correct? The questions to answer for now is whether 6top provides the right statisti= cs. Maria Rita, one big difference with TASA is that OTF scheduling is distribu= ted. Thomas On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA > wrote: Diego,( all) what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm). TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while buildin= g the schedule it minimizes the number of scheduled cells in order to reduc= e the network duty cycle. TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt. With a "on the fly solution", we will not need to know all this info a prio= ri. but we will use 6top monitoring functions and the control flows message= for scheduling the cells. Btw, I agree with all the points raised up by Xavi. We will have to addres= s his questions. And I support Pascal's suggestions about how to deal with bundle. Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@= ietf.org] on behalf of Pascal Thubert (pthub= ert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM To: xvilajosana@eecs.berkeley.edu; Pr= of. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling +1 too. I think that the queue size matters at enqueue but the latency is really wh= at we care for at dequeue, that is how long did this device keep this messa= ge in queue (even if we are far from buffer bloat conditions in such a device). If one of the 2 conditions (size= at enqueue, latency at dequeue) is reached then the bundle should be incre= ased. I agree with Xavi that we want to avoid changing the bundle size all the ti= me. We discussed that with Qin and others earlier on the ML. One way of inc= reasing the bundle dynamically at a very low cost (not even a hysteresis) = is to have it large amount of cells from the start but used like 10% by def= ault (xmit/listen happens only once in 10 time slots). A bit in the frame i= ndicates whether the next (normally unused) slot will indeed be used. The b= it can be present in the data and acked in the ack. This can also implicitl= y be triggered for retries. Please keep us tuned! Cheers, PS Note that Cisco has IPR on chaining time slots and flagging whether the = next is used or not. We already declared our IPR against the architecture d= raft and provided terms. Pascal From: 6tsch-bounces@ietf.org [mailto:6tsch-b= ounces@ietf.org] On Behalf Of Xavier Vilajos= ana Guillen Sent: jeudi 3 octobre 2013 15:46 To: Prof. Diego Dujovne Cc: 6TSCH Subject: Re: [6tsch] On the fly scheduling Diego, +1 it seems to a me a very interesting idea to explore. Maybe we can start put= ting some rules of this mechanism on the table and prepare a simulation. I = am completely in with that idea. Some questions arise: 1-how fast do you react to changes on the queue size to avoid hysteresis --= i.e how do you maintain certain stability in the schedule (so you don't st= art installing and removing links very often) 2-how you map queue size (only one or if more than one queue) to actual lin= k requirements 3-how you recover from link collisions in case of multiple nodes schedule t= he same cells. 4-how to decide to who (what neighbor) install more links according to queu= e size? cheers! Xavi On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne > wrote: Dear all, I've been looking into the idea of "on the fly scheduling", presented on the Sept 27th webex call as "on-the-fly decentralized reservat= ion". The basic mechanism would be based on analysing the queue size on a node and dynamically adapt the number of reserved cells to satisfy queue size, delay and/or power consumption thresholds. This mechanism would work inside 6top, between pairs of nodes. As a first approach, it would be based on the minimal draft. What do you think on this starting point? I (gladly) receive comments to add or modify this proposal. Diego -- DIEGO DUJOVNE Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Dear all:

     <= /p>

    Statistics and hysteresis= can be costly in terms of memory and CPU, may not be the best strategy to = address bursts of traffic in a stochastic IP network, and the strategy to derive the allocation from the past observation may be har= d to determine in a particular case and even harder to generalize.

     <= /p>

    The needs of bandwidth ma= y be very dynamic for instance in the case of alarms/alerts, or in the case= of a brutal variation of monitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa= ct brutally its needs of bandwidth. So we cannot only rely on past observat= ions and but also need to maintain some capabilities that rely on current n= eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of = traffic and longer term variations.

     <= /p>

    Considering that we have = ample room in a SlotFrame, a simple strategy, derived from traditional memo= ry management, could be to augment the number of cells in a bundle each time it is saturated. As an image, GNU’s obstack seem = to grow linearly one chunk at a time, but I know of chunk implementations t= hat double the size of a dynamic chunk each time it is saturated and a geom= etrical growth may a better approach for us.

     <= /p>

    In a bundle, a portion of= the cells is always on. The rest can stay idle (no wake to send or listen)= unless a previous cell indicates that there is more to come. If we agree on a strategy like this then we can start working out th= e details, in particular how handle lazy release or one-shot override, how = we observe unallocated slots to make them candidate for allocation, etc...<= o:p>

     <= /p>

    As you see, even implemen= ting such a simple strategy can already be quite some work in a constrained= device.

     <= /p>

    Cheers,=

     <= /p>

    Pascal<= /p>

     <= /p>

    From: 6tsch-bo= unces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
    Sent: vendredi 4 octobre 2013 09:19
    To: Thomas Watteyne; 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    +1 for me too.

     <= /p>

    For sure, according to th= e specific requirements of the applications, different algorithms may be us= ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

     <= /p>

    The statistics needed cou= ld change because different algorithms may use different input as parameter= s.  So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.

     <= /p>

    Maria Rita

     <= /p>

     <= /p>

     <= /p>

    From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    That would indeed be clean.

     

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wrote:

    Hi all,

     

    +1 for the proposal. 

     

    Regarding to how to approach, I agree with Thomas. T= here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele= te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

     

    What do you think?

     

    Qin 

     

     

     

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    +1 for the proposal.

     

    I believe it could be a very simple and powerful app= roach. Diego, would you agree that this can be considered a distributed mec= hanism sitting on top of 6top?

     

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
    • commands to retrieve usage statistics of the cells/bundles
      • <= /ul>

      The way I see it, your proposal consists of an algor= ithm which feeds from the usage statistics and triggers changes in the numb= er of soft cells in a bundle. Correct?

     

    The questions to answer for now is whether 6top prov= ides the right statistics.

     

    Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.

     

    Thomas

     

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL= A <mar= ia-rita.palattella@uni.lu> wrote:

    Diego,( a= ll)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, gene= rated by children). It gives priority to nodes with longer queues and it ai= ms to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.  We will have to a= ddress his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From: 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne    =


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    +1 too.

     

    I think that the queue size matters at = enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions in such a devic= e). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased.

     

    I agree with Xavi that we want to avoid= changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis)  is to have it la= rge amount of cells from the start but used like 10% by default (xmit/liste= n happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

     

    Please keep us tuned!=

     

    Cheers,

     

    PS Note that Cisco has IPR on chaining = time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

     

    Pascal

     

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

     

    Diego,

    +1

    it seems to a me a very interesting idea to explore. Maybe we can start = putting some rules of this mechanism on the table and prepare a simulation.= I am completely in with that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size to avoid hyst= eresis -- i.e how do you maintain certain stability in the schedule (so you= don't start installing and removing links very often)

    2-how you map queue size (only one or if more than one queue) to a= ctual link requirements

    3-how you recover from link collisions in case of multiple nodes s= chedule the same cells.

    4-how to decide to who (what neighbor) install more links accordin= g to queue size?

     

    cheers!
    Xavi

     

     

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp= .cl> wrote:

    Dear all,
                I've been looking into the idea o= f "on the fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
                This mechanism would work inside = 6top, between pairs of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

                         = ;                Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

     

     

    --_000_E045AECD98228444A58C61C200AE1BD8414D2118xmbrcdx01ciscoc_-- From qinwang@berkeley.edu Fri Oct 4 07:23:48 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014E21F9C7B for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqJi3nkrZFm7 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:23:32 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 131A821F9A50 for <6tsch@ietf.org>; Fri, 4 Oct 2013 07:17:45 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so9279038ief.1 for <6tsch@ietf.org>; Fri, 04 Oct 2013 07:17:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u7ikrU1Op7aRmA6iMmj//NPIre9X63b/b9YifOMARqM=; b=hJwen8RPShlf/I8V5Govk2EynXltTV8K87ooF3zJ48E3CpIhARfVoEzx5LofBLZaZw 2r+ZWkJIbLmAj5+YnHhfPpE/k0LKWZMeRli+WtS0M/eEzsnQ94+rqFmYORmrX+DR8WvL XmnC4EWbURs5vyYC7A31bvRLxmMrFvGWyKHJsEwpBjObI47zcWHmmUEFK7ejFBfSVaWn w19B6Rvy5D+r2030NgJTLHr5HORBYSS/99DkzCcyROm4Hz3w88TMle3IwS5ZiDfWrBKh 4MM452K9jpxbcnB5qHcFBda+whnW4gTscy1QFFmt4tFH5afCTyZLGwZ8Tpfo6LsUga94 N9BA== X-Gm-Message-State: ALoCoQnIgdWZHhqgPEPyJvKOPxq/fkyHpFhZULYqdPu3OpyVvuFsYg13bNhHYvLvQSwKepdXE6Uw MIME-Version: 1.0 X-Received: by 10.50.60.5 with SMTP id d5mr6735222igr.26.1380896264009; Fri, 04 Oct 2013 07:17:44 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Fri, 4 Oct 2013 07:17:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 22:17:43 +0800 Message-ID: From: Qin Wang To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7b10c77f49cf9a04e7eaf77a Cc: Maria Rita PALATTELLA , Thomas Watteyne , 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:23:48 -0000 --047d7b10c77f49cf9a04e7eaf77a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal and all, It is a interesting approach. I would like to put different approaches above together. Objective: meet some QoS requirement. Tool 1: pre-allocation, like what Pascal suggested, assign number of cells to a bundle, and on/off them on demand. Tool 2: post-allocation, like discussed in other emails in this thread, adjust the number of cells in a bundle according to statistics information. In reality, I think a mote may use the combination of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells for a bundle, and use them in the mode of on/off on demand; when statistics information show 2 more cells needed, then mote is triggered to allocates 3 more cells for the bundle, and then also use them in the mode of on/off on demand. If it is the case, a solution should include the the following parts: (1) mechanism to create/delete softcells (2) mechanism to provide statistics information (3) mechanism to on/off cell on demand (4) algorithm to determine how many cells needed for a QoS requirement like (dataflow/burst-feature, delay-tolerance, {statistics info}, ...) What do you think? Qin On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Dear all:**** > > ** ** > > Statistics and hysteresis can be costly in terms of memory and CPU, may > not be the best strategy to address bursts of traffic in a stochastic IP > network, and the strategy to derive the allocation from the past > observation may be hard to determine in a particular case and even harder > to generalize.**** > > ** ** > > The needs of bandwidth may be very dynamic for instance in the case of > alarms/alerts, or in the case of a brutal variation of monitored data. > Changes in the network topology impacting the rank of a node within the D= AG > may also impact brutally its needs of bandwidth. So we cannot only rely o= n > past observations and but also need to maintain some capabilities that re= ly > on current needs that operate efficiently in terms of control and yet ver= y > dynamically to accept both brutal bursts of traffic and longer term > variations.**** > > ** ** > > Considering that we have ample room in a SlotFrame, a simple strategy, > derived from traditional memory management, could be to augment the numbe= r > of cells in a bundle each time it is saturated. As an image, GNU=92s obst= ack > seem to grow linearly one chunk at a time, but I know of chunk > implementations that double the size of a dynamic chunk each time it is > saturated and a geometrical growth may a better approach for us. **** > > ** ** > > In a bundle, a portion of the cells is always on. The rest can stay idle > (no wake to send or listen) unless a previous cell indicates that there i= s > more to come. If we agree on a strategy like this then we can start worki= ng > out the details, in particular how handle lazy release or one-shot > override, how we observe unallocated slots to make them candidate for > allocation, etc...**** > > ** ** > > As you see, even implementing such a simple strategy can already be quite > some work in a constrained device. **** > > ** ** > > Cheers,**** > > ** ** > > Pascal**** > > ** ** > > *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf > Of *Maria Rita PALATTELLA > *Sent:* vendredi 4 octobre 2013 09:19 > *To:* Thomas Watteyne; 6TSCH > > *Subject:* Re: [6tsch] On the fly scheduling**** > > ** ** > > +1 for me too.**** > > ** ** > > For sure, according to the specific requirements of the applications, > different algorithms may be used for building the schedule. But the > functionalities offers by 6top (i.e., collect statist. Info, send command= s > for scheduling cells) will be still the same (no matter which algorithm i= s > used). **** > > ** ** > > The statistics needed could change because different algorithms may use > different input as parameters. So, we will have to include a set of > statistic information, or anyway, make sure it is possible to extend them= . > **** > > ** ** > > Maria Rita**** > > ** ** > > ** ** > > ** ** > > *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bounc= es@ietf.org>] > *On Behalf Of *Thomas Watteyne > *Sent:* Thursday, October 03, 2013 10:11 PM > *To:* 6TSCH > *Subject:* Re: [6tsch] On the fly scheduling**** > > ** ** > > That would indeed be clean.**** > > ** ** > > On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang wrote:**= * > * > > Hi all,**** > > ** ** > > +1 for the proposal. **** > > ** ** > > Regarding to how to approach, I agree with Thomas. There is an entity > running on top of 6top, which reads queue information and other statistic= s > information from 6top, sends instruction like create/delete softcells to > 6top. I think we can use the design methodology of Objective Function in > RPL, i.e. define the statistics information and the interface to/from 6to= p, > and leave the specific algorithm open.**** > > ** ** > > What do you think?**** > > ** ** > > Qin **** > > ** ** > > ** ** > > ** ** > > On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne < > watteyne@eecs.berkeley.edu> wrote:**** > > +1 for the proposal.**** > > ** ** > > I believe it could be a very simple and powerful approach. Diego, would > you agree that this can be considered a distributed mechanism sitting on > top of 6top?**** > > ** ** > > That is, 6top provides:**** > > - commands to modify the number of soft cells in a bundle**** > - commands to retrieve usage statistics of the cells/bundles**** > > The way I see it, your proposal consists of an algorithm which feeds > from the usage statistics and triggers changes in the number of soft cell= s > in a bundle. Correct?**** > > ** ** > > The questions to answer for now is whether 6top provides the right > statistics.**** > > ** ** > > Maria Rita, one big difference with TASA is that OTF scheduling is > distributed.**** > > ** ** > > Thomas**** > > ** ** > > On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < > maria-rita.palattella@uni.lu> wrote:**** > > Diego,( all) > > what you are suggesting (i.e., reserve cells based on queue size, delay) > is actually the main idea behind TASA (Traffic Aware Scheduling Algorithm= ). > > TASA builds the schedule based on the local (number of pkt generated by > the node) and global queue level ( i.e., local + pkt to be forwarded, > generated by children). It gives priority to nodes with longer queues and > it aims to reduce the latency for delivering the pkt. At the same time > while building the schedule it minimizes the number of scheduled cells in > order to reduce the network duty cycle. > TASA is centralized and thus it assumes that the PCE has all the info > needed for setting up the schedule. in other words, it knows the traffic > generated by each nodes, and the paths followed by each pkt. > With a "on the fly solution", we will not need to know all this info a > priori. but we will use 6top monitoring functions and the control flows > message for scheduling the cells. > > Btw, I agree with all the points raised up by Xavi. We will have to > address his questions. > > And I support Pascal's suggestions about how to deal with bundle. > > Maria Rita**** > ------------------------------ > > *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of > Pascal Thubert (pthubert) [pthubert@cisco.com] > *Sent:* Thursday, October 03, 2013 4:09 PM > *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne**** > > > *Cc:* 6TSCH > *Subject:* Re: [6tsch] On the fly scheduling**** > > ** ** > > +1 too.**** > > **** > > I think that the queue size matters at enqueue but the latency is really > what we care for at dequeue, that is how long did this device keep this > message in queue (even if we are far from **** > > buffer bloat conditions in such a device). If one of the 2 conditions > (size at enqueue, latency at dequeue) is reached then the bundle should b= e > increased. **** > > **** > > I agree with Xavi that we want to avoid changing the bundle size all the > time. We discussed that with Qin and others earlier on the ML. One way of > increasing the bundle dynamically at a very low cost (not even a > hysteresis) is to have it large amount of cells from the start but used > like 10% by default (xmit/listen happens only once in 10 time slots). A b= it > in the frame indicates whether the next (normally unused) slot will indee= d > be used. The bit can be present in the data and acked in the ack. This ca= n > also implicitly be triggered for retries.**** > > **** > > Please keep us tuned!**** > > **** > > Cheers,**** > > **** > > PS Note that Cisco has IPR on chaining time slots and flagging whether th= e > next is used or not. We already declared our IPR against the architecture > draft and provided terms.**** > > **** > > Pascal**** > > **** > > *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf > Of *Xavier Vilajosana Guillen > *Sent:* jeudi 3 octobre 2013 15:46 > *To:* Prof. Diego Dujovne > *Cc:* 6TSCH > *Subject:* Re: [6tsch] On the fly scheduling**** > > **** > > Diego, > > +1**** > > it seems to a me a very interesting idea to explore. Maybe we can start > putting some rules of this mechanism on the table and prepare a simulatio= n. > I am completely in with that idea.**** > > Some questions arise:**** > > 1-how fast do you react to changes on the queue size to avoid hysteresis > -- i.e how do you maintain certain stability in the schedule (so you don'= t > start installing and removing links very often)**** > > 2-how you map queue size (only one or if more than one queue) to actual > link requirements**** > > 3-how you recover from link collisions in case of multiple nodes schedule > the same cells.**** > > 4-how to decide to who (what neighbor) install more links according to > queue size?**** > > **** > > cheers! > Xavi**** > > **** > > **** > > On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < > diego.dujovne@mail.udp.cl> wrote:**** > > Dear all, > I've been looking into the idea of "on the fly scheduling", > presented on the Sept 27th webex call as "on-the-fly decentralized > reservation". > The basic mechanism would be based on analysing the queue size > on a node and dynamically adapt the number of reserved > cells to satisfy queue size, delay and/or power > consumption thresholds. > This mechanism would work inside 6top, between pairs of nodes= . > As a first approach, it would be based on the minimal draft. > What do you think on this starting point? > I (gladly) receive comments to add or modify this proposal. > > Diego > > > > > -- > DIEGO DUJOVNE > Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones > Facultad de Ingenier=EDa UDP > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch**** > > **** > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch**** > > ** ** > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch**** > > ** ** > > ** ** > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7b10c77f49cf9a04e7eaf77a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Pascal and all,

    It is a interesting = approach. I would like to put different approaches above together.

    Objective: meet some QoS requirement.
    Tool 1: pr= e-allocation, like what Pascal suggested, assign number of cells to a bundl= e, and on/off them on demand.
    Tool 2: post-allocation, like discussed in other emails in this thread= , adjust the number of cells in a bundle according to statistics informatio= n.

    In reality, I think a mote may use the combinat= ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells = for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates = 3 more cells for the bundle, and then also use them in the mode of on/off o= n demand.=A0

    If it is the case, a solution should include the the fo= llowing parts:
    (1) mechanism to create/delete softcells
    (2) mechanism to provide statistics information
    (3) mechanism to= on/off cell on demand
    (4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)= =A0

    What do you think?

    Qi= n
    =A0



    On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthub= ert) <pthubert@cisco.com> wrote:

    Dear all:

    =A0<= /p>

    Statistics and hysteresis= can be costly in terms of memory and CPU, may not be the best strategy to = address bursts of traffic in a stochastic IP network, and the strategy to derive the allocation from the past observation may be har= d to determine in a particular case and even harder to generalize.

    =A0<= /p>

    The needs of bandwidth ma= y be very dynamic for instance in the case of alarms/alerts, or in the case= of a brutal variation of monitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa= ct brutally its needs of bandwidth. So we cannot only rely on past observat= ions and but also need to maintain some capabilities that rely on current n= eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of = traffic and longer term variations.

    =A0<= /p>

    Considering that we have = ample room in a SlotFrame, a simple strategy, derived from traditional memo= ry management, could be to augment the number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g= row linearly one chunk at a time, but I know of chunk implementations that = double the size of a dynamic chunk each time it is saturated and a geometri= cal growth may a better approach for us.

    =A0<= /p>

    In a bundle, a portion of= the cells is always on. The rest can stay idle (no wake to send or listen)= unless a previous cell indicates that there is more to come. If we agree on a strategy like this then we can start working out th= e details, in particular how handle lazy release or one-shot override, how = we observe unallocated slots to make them candidate for allocation, etc...<= u>

    =A0<= /p>

    As you see, even implemen= ting such a simple strategy can already be quite some work in a constrained= device.

    =A0<= /p>

    Cheers,

    =A0<= /p>

    Pascal

    =A0<= /p>

    From: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
    Sent: vendredi 4 octobre 2013 09:19
    To: Thomas Watteyne; 6TSCH


    Subject: Re: [6tsch] On the fly scheduling
    =

    =A0

    +1 for me too.<= /u>

    =A0<= /p>

    For sure, according to th= e specific requirements of the applications, different algorithms may be us= ed for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

    =A0<= /p>

    The statistics needed cou= ld change because different algorithms may use different input as parameter= s. =A0So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.

    =A0<= /p>

    Maria Rita<= /span>

    =A0<= /p>

    =A0<= /p>

    =A0<= /p>

    From: 6tsch-bounces@i= etf.org [ma= ilto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    That would indeed be clean.

    =A0

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wrote:

    Hi all,

    =A0

    +1 for the proposal.=A0

    =A0

    Regarding to how to approach, I agree with Thomas. T= here is an entity running on top of 6top, which reads queue information and= other statistics information from 6top, sends instruction like create/dele= te softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

    =A0

    What do you think?

    =A0

    Qin=A0

    =A0

    =A0

    =A0

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <= ;watteyne@e= ecs.berkeley.edu> wrote:

    +1 for the proposal.

    =A0

    I believe it could be a very simple and powerful app= roach. Diego, would you agree that this can be considered a distributed mec= hanism sitting on top of 6top?

    =A0

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
      • <= li class=3D"MsoNormal"> commands to retrieve usage statistics of the cells/bundles

    The way I see it, your proposal consists of an algor= ithm which feeds from the usage statistics and triggers changes in the numb= er of soft cells in a bundle. Correct?

    =A0

    The questions to answer for now is whether 6top prov= ides the right statistics.

    =A0

    Maria Rita, one big difference with TASA is that OTF= scheduling is distributed.

    =A0

    Thomas

    =A0

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELL= A <mar= ia-rita.palattella@uni.lu> wrote:

    Diego,( a= ll)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From: 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    +1 too.

    =A0<= /p>

    I think that the queue si= ze matters at enqueue but the latency is really what we care for at dequeue= , that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions i= n such a device). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. =

    =A0<= /p>

    I agree with Xavi that we= want to avoid changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h= appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

    =A0<= /p>

    Please keep us tuned!

    =A0<= /p>

    Cheers,<= /u>

    =A0<= /p>

    PS Note that Cisco has IP= R on chaining time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

    =A0<= /p>

    Pascal=

    =A0<= /p>

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a ve= ry interesting idea to explore. Maybe we can start putting some rules of th= is mechanism on the table and prepare a simulation. I am completely in with= that idea.

    Some questions arise:

    1-how fast do you react to changes on the queue size= to avoid hysteresis -- i.e how do you maintain certain stability in the sc= hedule (so you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than o= ne queue) to actual link requirements

    3-how you recover from link collisions in case of mu= ltiple nodes schedule the same cells.

    4-how to decide to who (what neighbor) install more = links according to queue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne = <diego.du= jovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --047d7b10c77f49cf9a04e7eaf77a-- From ksjp@berkeley.edu Fri Oct 4 07:57:07 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9DB21F9E11 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7gl8zfoUNVL for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:56:52 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6964F21F9396 for <6tsch@ietf.org>; Fri, 4 Oct 2013 07:54:21 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so4107661pbc.31 for <6tsch@ietf.org>; Fri, 04 Oct 2013 07:54:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=8xV6nQPUypTRnt+AnpHxeXROD3u7KL7qdGMEhphtM5E=; b=I3uJf4dp0rK1aOUr7o5yeYMmj2qGhlyHqSAkZvHFfl8jZyZq4cyBWLU9jbjEIc+NmT zRRi2SzBLEMoJEQGprFgbD2MdiQ+lJ15UQGvhmC/o/Tqlc8tUmyCqZ7KLzdXx6X26hrF STkByCTGP9huWXmo0RFxqEPAPTM7h9DIHdVs4EjqDBQz8IlFW/tuxSSAfIOPINwnu1Fu nMIbGabMl7O3S3YKw1fbkqeh2msB1viSs/eG8EwG+HhiF0cCiJKhuSgzDvRokkFQ1cEn irF8sn3L/v6+O7mEsiEtvdcL+vGcGfBa+6yB3JvxVi3Cem/mFQzWrhpaMjmv0P8wGopn ruTw== X-Gm-Message-State: ALoCoQlKcAm6KH2gjRYrdDvBBUaY0c36jRRDr374lGizBbFmLjrwNi9pB6jpYD82HMOtcbatfbd0 X-Received: by 10.66.246.229 with SMTP id xz5mr15948475pac.128.1380898460006; Fri, 04 Oct 2013 07:54:20 -0700 (PDT) Received: from [128.32.32.89] (dhcp-32-89.EECS.Berkeley.EDU. [128.32.32.89]) by mx.google.com with ESMTPSA id iu7sm15208101pbc.45.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 07:54:19 -0700 (PDT) Message-ID: <524ED6A0.2030702@berkeley.edu> Date: Fri, 04 Oct 2013 07:54:24 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: 6tsch@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000703060406070106070906" Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:57:08 -0000 This is a multi-part message in MIME format. --------------000703060406070106070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote: > As you see, even implementing such a simple strategy can already be > quite some work in a constrained device. Or it can be really really simple and still quite effective for 90% of use cases. One very simple algorithm: * each node knows its own desired bandwidth (in cells/sec) to the destination. * each node knows how many cells/sec it has as inputs from children * each node knows how many cells/sec it has as outputs to parents Here's my super-sophisticated proposal: if (outputs < inputs+self) pick the best parent and add a new cell. if (outputs > inputs+self + 1) pick the worst cell and delete it This is not optimal. It guarantees some wasted bandwidth. But it works great in most situations, and is pretty easy to implement. If the number "1" is open to some interpretation (should be in cells/superframe, possibly include some time delay) you can minimize churn. Desired bandwidth can change based on application performance (e.g. round-trip latency) or MAC performance (measured cell PDR, queue length). But none of that is really necessary to get a good network up and running. Lance Doherty did some simulations of this in matlab back in 2004. I'll see if I can dig those up. ksjp --------------000703060406070106070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/4/2013 2:30 AM, Pascal Thubert (pthubert) wrote:
    As you see, even implementing such a simple strategy can already be quite some work in a constrained device.

    Or it can be really really simple and still quite effective for 90% of use cases.

    One very simple algorithm:
     * each node knows its own desired bandwidth (in cells/sec) to the destination.
     * each node knows how many cells/sec it has as inputs from children
     * each node knows how many cells/sec it has as outputs to parents

    Here's my super-sophisticated proposal:
    if (outputs <  inputs+self) pick the best parent and add a new cell.
    if (outputs > inputs+self + 1) pick the worst cell and delete it

    This is not optimal.  It guarantees some wasted bandwidth.  But it works great in most situations,
    and is pretty easy to implement.  If the number "1" is open to some interpretation (should be in
    cells/superframe, possibly include some time delay) you can minimize churn. 
    Desired bandwidth can change based on application performance (e.g. round-trip latency)
    or MAC performance (measured cell PDR, queue length).  But none of that is really necessary to get
    a good network up and running.

    Lance Doherty did some simulations of this in matlab back in 2004.  I'll see if I can dig those up.

    ksjp

    --------------000703060406070106070906-- From guillaume.gaillard.maze@gmail.com Fri Oct 4 07:57:52 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A921F9E51 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH6s6qRdWugC for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 07:57:20 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA721F9CA6 for <6tsch@ietf.org>; Fri, 4 Oct 2013 07:54:41 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so3228737wes.15 for <6tsch@ietf.org>; Fri, 04 Oct 2013 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dep9M2eYCRTa3O8Eu+fvxDaCeawxuJOlw/k+7TWRAYg=; b=M3q1ngqNEj7c6Z7NpwnLmEhWH68U/+Yy6OHsqQYPgMQsXC9R0TOCIqCl78+T2eU8Wy G/ivMJzY/z0G1fNBDbk9eJX2Dw68x41h07MbpSwCqjNA465lyGWSPrdDaSAotgvI+uiv 9msEOOxNdwSx/m3885FZ0m2OGHECg0yAHyt9EaVaz2lP+9fc56Y6efpIjEMyAgeBnwDC /fv9ZqnHyY/3pzDf28xgRAOSuIVfSrkfg5cRVyCVFkWML7bLztM/1KzCpQYqrufMgo90 QbsE8jNNX1I2+C/IrWrtvXDAiht6WKeeSeeNYc+c3j1HI/wPTDH95b5HHD68wq5igJCd jtVg== MIME-Version: 1.0 X-Received: by 10.194.71.72 with SMTP id s8mr2121980wju.52.1380898481170; Fri, 04 Oct 2013 07:54:41 -0700 (PDT) Received: by 10.217.10.199 with HTTP; Fri, 4 Oct 2013 07:54:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 16:54:41 +0200 Message-ID: From: Guillaume Gaillard To: Qin Wang Content-Type: multipart/alternative; boundary=047d7bd91a0470f08d04e7eb7b46 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 14:57:52 -0000 --047d7bd91a0470f08d04e7eb7b46 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Qin and all, I agree with your separation into two tools (pre-allocation vs post-allocation). When one wants to meet a new QoS requirement, it is possible: - (1) to over-provision cells in the schedule in order to be "sure" to meet the requirement (pre-allocation); - (2) to adapt the cell allocation to the variations of the network parameters (post-allocation); - (3) to do both things. When solution (2) is adopted, one should tolerate a time of degraded QoS, before the requirement is restored. I agree on your list of mechanisms a solution requires. Is the algorithm (4) (matching number of cell with QoS requirements) implementation-specific ? Regards, Guillaume Gaillard Orange Labs Meylan/CITI INRIA-INSA Lyon PhD student "SLA pour R=E9seaux de Capteurs Multi-Services" Advisors D. Barthel, F. Valois, F. Theoleyre 2013/10/4 Qin Wang > Hi Pascal and all, > > It is a interesting approach. I would like to put different approaches > above together. > > Objective: meet some QoS requirement. > Tool 1: pre-allocation, like what Pascal suggested, assign number of cell= s > to a bundle, and on/off them on demand. > Tool 2: post-allocation, like discussed in other emails in this thread, > adjust the number of cells in a bundle according to statistics informatio= n. > > In reality, I think a mote may use the combination of tool 1 and tool 2, > e.g. at the beginning, mote allocates some cells for a bundle, and use th= em > in the mode of on/off on demand; when statistics information show 2 more > cells needed, then mote is triggered to allocates 3 more cells for the > bundle, and then also use them in the mode of on/off on demand. > > If it is the case, a solution should include the the following parts: > (1) mechanism to create/delete softcells > (2) mechanism to provide statistics information > (3) mechanism to on/off cell on demand > (4) algorithm to determine how many cells needed for a QoS requirement > like (dataflow/burst-feature, delay-tolerance, {statistics info}, ...) > > What do you think? > > Qin > > > > > On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > >> Dear all:**** >> >> ** ** >> >> Statistics and hysteresis can be costly in terms of memory and CPU, may >> not be the best strategy to address bursts of traffic in a stochastic IP >> network, and the strategy to derive the allocation from the past >> observation may be hard to determine in a particular case and even harde= r >> to generalize.**** >> >> ** ** >> >> The needs of bandwidth may be very dynamic for instance in the case of >> alarms/alerts, or in the case of a brutal variation of monitored data. >> Changes in the network topology impacting the rank of a node within the = DAG >> may also impact brutally its needs of bandwidth. So we cannot only rely = on >> past observations and but also need to maintain some capabilities that r= ely >> on current needs that operate efficiently in terms of control and yet ve= ry >> dynamically to accept both brutal bursts of traffic and longer term >> variations.**** >> >> ** ** >> >> Considering that we have ample room in a SlotFrame, a simple strategy, >> derived from traditional memory management, could be to augment the numb= er >> of cells in a bundle each time it is saturated. As an image, GNU=92s obs= tack >> seem to grow linearly one chunk at a time, but I know of chunk >> implementations that double the size of a dynamic chunk each time it is >> saturated and a geometrical growth may a better approach for us. **** >> >> ** ** >> >> In a bundle, a portion of the cells is always on. The rest can stay idle >> (no wake to send or listen) unless a previous cell indicates that there = is >> more to come. If we agree on a strategy like this then we can start work= ing >> out the details, in particular how handle lazy release or one-shot >> override, how we observe unallocated slots to make them candidate for >> allocation, etc...**** >> >> ** ** >> >> As you see, even implementing such a simple strategy can already be quit= e >> some work in a constrained device. **** >> >> ** ** >> >> Cheers,**** >> >> ** ** >> >> Pascal**** >> >> ** ** >> >> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >> Behalf Of *Maria Rita PALATTELLA >> *Sent:* vendredi 4 octobre 2013 09:19 >> *To:* Thomas Watteyne; 6TSCH >> >> *Subject:* Re: [6tsch] On the fly scheduling**** >> >> ** ** >> >> +1 for me too.**** >> >> ** ** >> >> For sure, according to the specific requirements of the applications, >> different algorithms may be used for building the schedule. But the >> functionalities offers by 6top (i.e., collect statist. Info, send comman= ds >> for scheduling cells) will be still the same (no matter which algorithm = is >> used). **** >> >> ** ** >> >> The statistics needed could change because different algorithms may use >> different input as parameters. So, we will have to include a set of >> statistic information, or anyway, make sure it is possible to extend the= m. >> **** >> >> ** ** >> >> Maria Rita**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-boun= ces@ietf.org>] >> *On Behalf Of *Thomas Watteyne >> *Sent:* Thursday, October 03, 2013 10:11 PM >> *To:* 6TSCH >> *Subject:* Re: [6tsch] On the fly scheduling**** >> >> ** ** >> >> That would indeed be clean.**** >> >> ** ** >> >> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang wrote:*= * >> ** >> >> Hi all,**** >> >> ** ** >> >> +1 for the proposal. **** >> >> ** ** >> >> Regarding to how to approach, I agree with Thomas. There is an entity >> running on top of 6top, which reads queue information and other statisti= cs >> information from 6top, sends instruction like create/delete softcells to >> 6top. I think we can use the design methodology of Objective Function in >> RPL, i.e. define the statistics information and the interface to/from 6t= op, >> and leave the specific algorithm open.**** >> >> ** ** >> >> What do you think?**** >> >> ** ** >> >> Qin **** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne < >> watteyne@eecs.berkeley.edu> wrote:**** >> >> +1 for the proposal.**** >> >> ** ** >> >> I believe it could be a very simple and powerful approach. Diego, would >> you agree that this can be considered a distributed mechanism sitting on >> top of 6top?**** >> >> ** ** >> >> That is, 6top provides:**** >> >> - commands to modify the number of soft cells in a bundle**** >> - commands to retrieve usage statistics of the cells/bundles**** >> >> The way I see it, your proposal consists of an algorithm which feeds >> from the usage statistics and triggers changes in the number of soft cel= ls >> in a bundle. Correct?**** >> >> ** ** >> >> The questions to answer for now is whether 6top provides the right >> statistics.**** >> >> ** ** >> >> Maria Rita, one big difference with TASA is that OTF scheduling is >> distributed.**** >> >> ** ** >> >> Thomas**** >> >> ** ** >> >> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < >> maria-rita.palattella@uni.lu> wrote:**** >> >> Diego,( all) >> >> what you are suggesting (i.e., reserve cells based on queue size, delay) >> is actually the main idea behind TASA (Traffic Aware Scheduling Algorith= m). >> >> TASA builds the schedule based on the local (number of pkt generated by >> the node) and global queue level ( i.e., local + pkt to be forwarded, >> generated by children). It gives priority to nodes with longer queues an= d >> it aims to reduce the latency for delivering the pkt. At the same time >> while building the schedule it minimizes the number of scheduled cells i= n >> order to reduce the network duty cycle. >> TASA is centralized and thus it assumes that the PCE has all the info >> needed for setting up the schedule. in other words, it knows the traffic >> generated by each nodes, and the paths followed by each pkt. >> With a "on the fly solution", we will not need to know all this info a >> priori. but we will use 6top monitoring functions and the control flows >> message for scheduling the cells. >> >> Btw, I agree with all the points raised up by Xavi. We will have to >> address his questions. >> >> And I support Pascal's suggestions about how to deal with bundle. >> >> Maria Rita**** >> ------------------------------ >> >> *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of >> Pascal Thubert (pthubert) [pthubert@cisco.com] >> *Sent:* Thursday, October 03, 2013 4:09 PM >> *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne**** >> >> >> *Cc:* 6TSCH >> *Subject:* Re: [6tsch] On the fly scheduling**** >> >> ** ** >> >> +1 too.**** >> >> **** >> >> I think that the queue size matters at enqueue but the latency is really >> what we care for at dequeue, that is how long did this device keep this >> message in queue (even if we are far from **** >> >> buffer bloat conditions in such a device). If one of the 2 conditions >> (size at enqueue, latency at dequeue) is reached then the bundle should = be >> increased. **** >> >> **** >> >> I agree with Xavi that we want to avoid changing the bundle size all the >> time. We discussed that with Qin and others earlier on the ML. One way o= f >> increasing the bundle dynamically at a very low cost (not even a >> hysteresis) is to have it large amount of cells from the start but used >> like 10% by default (xmit/listen happens only once in 10 time slots). A = bit >> in the frame indicates whether the next (normally unused) slot will inde= ed >> be used. The bit can be present in the data and acked in the ack. This c= an >> also implicitly be triggered for retries.**** >> >> **** >> >> Please keep us tuned!**** >> >> **** >> >> Cheers,**** >> >> **** >> >> PS Note that Cisco has IPR on chaining time slots and flagging whether >> the next is used or not. We already declared our IPR against the >> architecture draft and provided terms.**** >> >> **** >> >> Pascal**** >> >> **** >> >> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >> Behalf Of *Xavier Vilajosana Guillen >> *Sent:* jeudi 3 octobre 2013 15:46 >> *To:* Prof. Diego Dujovne >> *Cc:* 6TSCH >> *Subject:* Re: [6tsch] On the fly scheduling**** >> >> **** >> >> Diego, >> >> +1**** >> >> it seems to a me a very interesting idea to explore. Maybe we can start >> putting some rules of this mechanism on the table and prepare a simulati= on. >> I am completely in with that idea.**** >> >> Some questions arise:**** >> >> 1-how fast do you react to changes on the queue size to avoid hysteresis >> -- i.e how do you maintain certain stability in the schedule (so you don= 't >> start installing and removing links very often)**** >> >> 2-how you map queue size (only one or if more than one queue) to actual >> link requirements**** >> >> 3-how you recover from link collisions in case of multiple nodes schedul= e >> the same cells.**** >> >> 4-how to decide to who (what neighbor) install more links according to >> queue size?**** >> >> **** >> >> cheers! >> Xavi**** >> >> **** >> >> **** >> >> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < >> diego.dujovne@mail.udp.cl> wrote:**** >> >> Dear all, >> I've been looking into the idea of "on the fly scheduling", >> presented on the Sept 27th webex call as "on-the-fly decentralized >> reservation". >> The basic mechanism would be based on analysing the queue size >> on a node and dynamically adapt the number of reserved >> cells to satisfy queue size, delay and/or power >> consumption thresholds. >> This mechanism would work inside 6top, between pairs of node= s. >> As a first approach, it would be based on the minimal draft. >> What do you think on this starting point? >> I (gladly) receive comments to add or modify this proposal. >> >> Diego >> >> >> >> >> -- >> DIEGO DUJOVNE >> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacione= s >> Facultad de Ingenier=EDa UDP >> www.ingenieria.udp.cl >> (56 2) 676 8125 >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch**** >> >> **** >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch**** >> >> ** ** >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch**** >> >> ** ** >> >> ** ** >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --047d7bd91a0470f08d04e7eb7b46 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Qin and all,

    I agree with your separ= ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:
    - (1) to over-provis= ion cells in the schedule in order to be "sure" to meet the requi= rement (pre-allocation);
    - (2) to adapt the cell allocation to the variations of the network pa= rameters (post-allocation);
    - (3) to do both things.
    When solution (2) is adopted, one should tolerate a time of de= graded QoS, before the requirement is restored.

    I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple= mentation-specific ?

    Regards,

    Guillaume Gaillard

    Orange Labs Meylan/CI= TI INRIA-INSA Lyon
    PhD student "SLA pour R=E9seaux de Capteu= rs Multi-Services"
    Advisors D. Barthel, F. Valois, F. Theole= yre



    2013/10/4 Qin Wang <qinwang@berkeley.edu>
    Hi Pascal and all,

    It = is a interesting approach. I would like to put different approaches above t= ogether.

    Objective: meet some QoS requirement.
    Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu= ndle, and on/off them on demand.
    Tool 2: post-allocation, like discussed in other emails in this thread= , adjust the number of cells in a bundle according to statistics informatio= n.

    In reality, I think a mote may use the combinat= ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells = for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates = 3 more cells for the bundle, and then also use them in the mode of on/off o= n demand.=A0

    If it is the case, a solution should include the the fo= llowing parts:
    (1) mechanism to create/delete softcells
    (2) mechanism to provide statistics information
    (3) mechanism to= on/off cell on demand
    (4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)= =A0

    What do you think?

    Qin
    =A0



    On Fri, Oct 4, 2013 at 5:30 PM, Pasca= l Thubert (pthubert) <pthubert@cisco.com> wrote:

    Dear all:

    =A0

    Statistics and hysteresis can be costly in terms of m= emory and CPU, may not be the best strategy to address bursts of traffic in= a stochastic IP network, and the strategy to derive the allocation from the past observation may be har= d to determine in a particular case and even harder to generalize.

    =A0

    The needs of bandwidth may be very dynamic for instan= ce in the case of alarms/alerts, or in the case of a brutal variation of mo= nitored data. Changes in the network topology impacting the rank of a node within the DAG may also impa= ct brutally its needs of bandwidth. So we cannot only rely on past observat= ions and but also need to maintain some capabilities that rely on current n= eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of = traffic and longer term variations.

    =A0

    Considering that we have ample room in a SlotFrame, a= simple strategy, derived from traditional memory management, could be to a= ugment the number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g= row linearly one chunk at a time, but I know of chunk implementations that = double the size of a dynamic chunk each time it is saturated and a geometri= cal growth may a better approach for us.

    =A0

    In a bundle, a portion of the cells is always on. The= rest can stay idle (no wake to send or listen) unless a previous cell indi= cates that there is more to come. If we agree on a strategy like this then we can start working out th= e details, in particular how handle lazy release or one-shot override, how = we observe unallocated slots to make them candidate for allocation, etc...<= u>

    =A0

    As you see, even implementing such a simple strategy = can already be quite some work in a constrained device.

    =A0

    Cheers,

    =A0

    Pascal

    =A0

    From: 6tsch-bou= nces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
    Sent: vendredi 4 octobre 2013 09:19
    To: Thomas Watteyne; 6TSCH


    Subject: Re: [6tsch] On the fly scheduling
    =

    =A0

    +1 for me too.

    =A0

    For sure, according to the specific requirements of t= he applications, different algorithms may be used for building the schedule= . But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

    =A0

    The statistics needed could change because different = algorithms may use different input as parameters. =A0So, we will have to in= clude a set of statistic information, or anyway, make sure it is possible to extend them.

    =A0

    Maria Rita

    =A0

    =A0

    =A0

    From: 6tsch-bounces@i= etf.org [ma= ilto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    That would indeed be clean.

    =A0

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wro= te:

    Hi all,

    =A0

    +1 for the proposal.=A0

    =A0

    Regarding to how to approach, I agree with Thomas. There is a= n entity running on top of 6top, which reads queue information and other st= atistics information from 6top, sends instruction like create/delete softce= lls to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

    =A0

    What do you think?

    =A0

    Qin=A0

    =A0

    =A0

    =A0

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <watteyne@eecs.berk= eley.edu> wrote:

    +1 for the proposal.

    =A0

    I believe it could be a very simple and powerful approach. Di= ego, would you agree that this can be considered a distributed mechanism si= tting on top of 6top?

    =A0

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
      • <= li class=3D""> commands to retrieve usage statistics of the cells/bundles

    The way I see it, your proposal consists of an algorithm whic= h feeds from the usage statistics and triggers changes in the number of sof= t cells in a bundle. Correct?

    =A0

    The questions to answer for now is whether 6top provides the = right statistics.

    =A0

    Maria Rita, one big difference with TASA is that OTF scheduli= ng is distributed.

    =A0

    Thomas

    =A0

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.p= alattella@uni.lu> wrote:

    Diego,( all)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From:= 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    +1 too.

    =A0

    I think that the queue size matters at enqueue but th= e latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions in such a device). If one of = the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. =

    =A0

    I agree with Xavi that we want to avoid changing the = bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h= appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IPR on chaining time slots and= flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

    =A0

    Pascal

    =A0

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a very interest= ing idea to explore. Maybe we can start putting some rules of this mechanis= m on the table and prepare a simulation. I am completely in with that idea.=

    Some questions arise:

    1-how fast do you react to changes on the queue size to avoid= hysteresis -- i.e how do you maintain certain stability in the schedule (s= o you don't start installing and removing links very often)

    2-how you map queue size (only one or if more than one queue)= to actual link requirements

    3-how you recover from link collisions in case of multiple no= des schedule the same cells.

    4-how to decide to who (what neighbor) install more links acc= ording to queue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mai= l.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch


    --047d7bd91a0470f08d04e7eb7b46-- From qinwang@berkeley.edu Fri Oct 4 08:01:24 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF5E21F9D96 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya1iwcrxdtyn for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 08:01:08 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8884021F9E85 for <6tsch@ietf.org>; Fri, 4 Oct 2013 07:57:59 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id e14so9148225iej.20 for <6tsch@ietf.org>; Fri, 04 Oct 2013 07:57:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/5rFGGwOhjsXKai6qhxhPJ5cdyk3ZNRi0wxYHGZ5YT0=; b=GuqnnOZklBPW/5s6YTDQlmQ2iHfaFTpyfh3FyuKRe99chE5MZ1sGTUMHGfPzE6XAkL 3WOHYsb9KeSqoYMNpQeQlCc2GLTpBuC1sD+Wf2Zo4nAKi5+78wZ7unj1MaeHQ/xr1CtC 4QRenjnsHSw64vWekwQHdz9O4I4KW5wQsGboyDwcAoFLCsQ4ouizujcTrmatec129k0u i4RQgCG3ZQbVH5bXGAvKz9RAgALDfxK6XjyHHl0GSyFYC5TR9O4yG12oM0MxA8CFxDaL ekjFxGCZruEGzPbW3ZL63ppWlZhFz0LMlwxdVxuP2pl3wjnfKzsl3tjeL/IEvjVK6G3r UxNQ== X-Gm-Message-State: ALoCoQlwUyHrlHrQ8/ZLdOkeEMwiO/LeJPGfu67EVu25jlP2PK3y7UFIe17lmRO9PEccNj6uUuo/ MIME-Version: 1.0 X-Received: by 10.43.114.6 with SMTP id ey6mr571122icc.87.1380898678749; Fri, 04 Oct 2013 07:57:58 -0700 (PDT) Received: by 10.64.130.234 with HTTP; Fri, 4 Oct 2013 07:57:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 22:57:58 +0800 Message-ID: From: Qin Wang To: Guillaume Gaillard Content-Type: multipart/alternative; boundary=bcaec5171c2937d0e204e7eb8763 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 15:01:24 -0000 --bcaec5171c2937d0e204e7eb8763 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Guillaume, I would like to keep the algorithm (4) open, something like Objective Function in RPL. Make sense? Qin On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard < guillaume.gaillard.maze@gmail.com> wrote: > Hi Qin and all, > > I agree with your separation into two tools (pre-allocation vs > post-allocation). When one wants to meet a new QoS requirement, it is > possible: > - (1) to over-provision cells in the schedule in order to be "sure" to > meet the requirement (pre-allocation); > - (2) to adapt the cell allocation to the variations of the network > parameters (post-allocation); > - (3) to do both things. > > When solution (2) is adopted, one should tolerate a time of degraded QoS, > before the requirement is restored. > > I agree on your list of mechanisms a solution requires. Is the algorithm > (4) (matching number of cell with QoS requirements) implementation-specif= ic > ? > > Regards, > > Guillaume Gaillard > > Orange Labs Meylan/CITI INRIA-INSA Lyon > PhD student "SLA pour R=E9seaux de Capteurs Multi-Services" > Advisors D. Barthel, F. Valois, F. Theoleyre > > > > 2013/10/4 Qin Wang > >> Hi Pascal and all, >> >> It is a interesting approach. I would like to put different approaches >> above together. >> >> Objective: meet some QoS requirement. >> Tool 1: pre-allocation, like what Pascal suggested, assign number of >> cells to a bundle, and on/off them on demand. >> Tool 2: post-allocation, like discussed in other emails in this thread, >> adjust the number of cells in a bundle according to statistics informati= on. >> >> In reality, I think a mote may use the combination of tool 1 and tool 2, >> e.g. at the beginning, mote allocates some cells for a bundle, and use t= hem >> in the mode of on/off on demand; when statistics information show 2 more >> cells needed, then mote is triggered to allocates 3 more cells for the >> bundle, and then also use them in the mode of on/off on demand. >> >> If it is the case, a solution should include the the following parts: >> (1) mechanism to create/delete softcells >> (2) mechanism to provide statistics information >> (3) mechanism to on/off cell on demand >> (4) algorithm to determine how many cells needed for a QoS requirement >> like (dataflow/burst-feature, delay-tolerance, {statistics info}, ...) >> >> What do you think? >> >> Qin >> >> >> >> >> On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) < >> pthubert@cisco.com> wrote: >> >>> Dear all:**** >>> >>> ** ** >>> >>> Statistics and hysteresis can be costly in terms of memory and CPU, may >>> not be the best strategy to address bursts of traffic in a stochastic I= P >>> network, and the strategy to derive the allocation from the past >>> observation may be hard to determine in a particular case and even hard= er >>> to generalize.**** >>> >>> ** ** >>> >>> The needs of bandwidth may be very dynamic for instance in the case of >>> alarms/alerts, or in the case of a brutal variation of monitored data. >>> Changes in the network topology impacting the rank of a node within the= DAG >>> may also impact brutally its needs of bandwidth. So we cannot only rely= on >>> past observations and but also need to maintain some capabilities that = rely >>> on current needs that operate efficiently in terms of control and yet v= ery >>> dynamically to accept both brutal bursts of traffic and longer term >>> variations.**** >>> >>> ** ** >>> >>> Considering that we have ample room in a SlotFrame, a simple strategy, >>> derived from traditional memory management, could be to augment the num= ber >>> of cells in a bundle each time it is saturated. As an image, GNU=92s ob= stack >>> seem to grow linearly one chunk at a time, but I know of chunk >>> implementations that double the size of a dynamic chunk each time it is >>> saturated and a geometrical growth may a better approach for us. **** >>> >>> ** ** >>> >>> In a bundle, a portion of the cells is always on. The rest can stay idl= e >>> (no wake to send or listen) unless a previous cell indicates that there= is >>> more to come. If we agree on a strategy like this then we can start wor= king >>> out the details, in particular how handle lazy release or one-shot >>> override, how we observe unallocated slots to make them candidate for >>> allocation, etc...**** >>> >>> ** ** >>> >>> As you see, even implementing such a simple strategy can already be >>> quite some work in a constrained device. **** >>> >>> ** ** >>> >>> Cheers,**** >>> >>> ** ** >>> >>> Pascal**** >>> >>> ** ** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Maria Rita PALATTELLA >>> *Sent:* vendredi 4 octobre 2013 09:19 >>> *To:* Thomas Watteyne; 6TSCH >>> >>> *Subject:* Re: [6tsch] On the fly scheduling**** >>> >>> ** ** >>> >>> +1 for me too.**** >>> >>> ** ** >>> >>> For sure, according to the specific requirements of the applications, >>> different algorithms may be used for building the schedule. But the >>> functionalities offers by 6top (i.e., collect statist. Info, send comma= nds >>> for scheduling cells) will be still the same (no matter which algorithm= is >>> used). **** >>> >>> ** ** >>> >>> The statistics needed could change because different algorithms may use >>> different input as parameters. So, we will have to include a set of >>> statistic information, or anyway, make sure it is possible to extend th= em. >>> **** >>> >>> ** ** >>> >>> Maria Rita**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bou= nces@ietf.org>] >>> *On Behalf Of *Thomas Watteyne >>> *Sent:* Thursday, October 03, 2013 10:11 PM >>> *To:* 6TSCH >>> *Subject:* Re: [6tsch] On the fly scheduling**** >>> >>> ** ** >>> >>> That would indeed be clean.**** >>> >>> ** ** >>> >>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang wrote:= * >>> *** >>> >>> Hi all,**** >>> >>> ** ** >>> >>> +1 for the proposal. **** >>> >>> ** ** >>> >>> Regarding to how to approach, I agree with Thomas. There is an entity >>> running on top of 6top, which reads queue information and other statist= ics >>> information from 6top, sends instruction like create/delete softcells t= o >>> 6top. I think we can use the design methodology of Objective Function i= n >>> RPL, i.e. define the statistics information and the interface to/from 6= top, >>> and leave the specific algorithm open.**** >>> >>> ** ** >>> >>> What do you think?**** >>> >>> ** ** >>> >>> Qin **** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne < >>> watteyne@eecs.berkeley.edu> wrote:**** >>> >>> +1 for the proposal.**** >>> >>> ** ** >>> >>> I believe it could be a very simple and powerful approach. Diego, would >>> you agree that this can be considered a distributed mechanism sitting o= n >>> top of 6top?**** >>> >>> ** ** >>> >>> That is, 6top provides:**** >>> >>> - commands to modify the number of soft cells in a bundle**** >>> - commands to retrieve usage statistics of the cells/bundles**** >>> >>> The way I see it, your proposal consists of an algorithm which feeds >>> from the usage statistics and triggers changes in the number of soft ce= lls >>> in a bundle. Correct?**** >>> >>> ** ** >>> >>> The questions to answer for now is whether 6top provides the right >>> statistics.**** >>> >>> ** ** >>> >>> Maria Rita, one big difference with TASA is that OTF scheduling is >>> distributed.**** >>> >>> ** ** >>> >>> Thomas**** >>> >>> ** ** >>> >>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < >>> maria-rita.palattella@uni.lu> wrote:**** >>> >>> Diego,( all) >>> >>> what you are suggesting (i.e., reserve cells based on queue size, delay= ) >>> is actually the main idea behind TASA (Traffic Aware Scheduling Algorit= hm). >>> >>> TASA builds the schedule based on the local (number of pkt generated by >>> the node) and global queue level ( i.e., local + pkt to be forwarded, >>> generated by children). It gives priority to nodes with longer queues a= nd >>> it aims to reduce the latency for delivering the pkt. At the same time >>> while building the schedule it minimizes the number of scheduled cells = in >>> order to reduce the network duty cycle. >>> TASA is centralized and thus it assumes that the PCE has all the info >>> needed for setting up the schedule. in other words, it knows the traffi= c >>> generated by each nodes, and the paths followed by each pkt. >>> With a "on the fly solution", we will not need to know all this info a >>> priori. but we will use 6top monitoring functions and the control flows >>> message for scheduling the cells. >>> >>> Btw, I agree with all the points raised up by Xavi. We will have to >>> address his questions. >>> >>> And I support Pascal's suggestions about how to deal with bundle. >>> >>> Maria Rita**** >>> ------------------------------ >>> >>> *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of >>> Pascal Thubert (pthubert) [pthubert@cisco.com] >>> *Sent:* Thursday, October 03, 2013 4:09 PM >>> *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne**** >>> >>> >>> *Cc:* 6TSCH >>> *Subject:* Re: [6tsch] On the fly scheduling**** >>> >>> ** ** >>> >>> +1 too.**** >>> >>> **** >>> >>> I think that the queue size matters at enqueue but the latency is reall= y >>> what we care for at dequeue, that is how long did this device keep this >>> message in queue (even if we are far from **** >>> >>> buffer bloat conditions in such a device). If one of the 2 conditions >>> (size at enqueue, latency at dequeue) is reached then the bundle should= be >>> increased. **** >>> >>> **** >>> >>> I agree with Xavi that we want to avoid changing the bundle size all th= e >>> time. We discussed that with Qin and others earlier on the ML. One way = of >>> increasing the bundle dynamically at a very low cost (not even a >>> hysteresis) is to have it large amount of cells from the start but use= d >>> like 10% by default (xmit/listen happens only once in 10 time slots). A= bit >>> in the frame indicates whether the next (normally unused) slot will ind= eed >>> be used. The bit can be present in the data and acked in the ack. This = can >>> also implicitly be triggered for retries.**** >>> >>> **** >>> >>> Please keep us tuned!**** >>> >>> **** >>> >>> Cheers,**** >>> >>> **** >>> >>> PS Note that Cisco has IPR on chaining time slots and flagging whether >>> the next is used or not. We already declared our IPR against the >>> architecture draft and provided terms.**** >>> >>> **** >>> >>> Pascal**** >>> >>> **** >>> >>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>> Behalf Of *Xavier Vilajosana Guillen >>> *Sent:* jeudi 3 octobre 2013 15:46 >>> *To:* Prof. Diego Dujovne >>> *Cc:* 6TSCH >>> *Subject:* Re: [6tsch] On the fly scheduling**** >>> >>> **** >>> >>> Diego, >>> >>> +1**** >>> >>> it seems to a me a very interesting idea to explore. Maybe we can start >>> putting some rules of this mechanism on the table and prepare a simulat= ion. >>> I am completely in with that idea.**** >>> >>> Some questions arise:**** >>> >>> 1-how fast do you react to changes on the queue size to avoid hysteresi= s >>> -- i.e how do you maintain certain stability in the schedule (so you do= n't >>> start installing and removing links very often)**** >>> >>> 2-how you map queue size (only one or if more than one queue) to actual >>> link requirements**** >>> >>> 3-how you recover from link collisions in case of multiple nodes >>> schedule the same cells.**** >>> >>> 4-how to decide to who (what neighbor) install more links according to >>> queue size?**** >>> >>> **** >>> >>> cheers! >>> Xavi**** >>> >>> **** >>> >>> **** >>> >>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < >>> diego.dujovne@mail.udp.cl> wrote:**** >>> >>> Dear all, >>> I've been looking into the idea of "on the fly scheduling", >>> presented on the Sept 27th webex call as "on-the-fly decentralized >>> reservation". >>> The basic mechanism would be based on analysing the queue size >>> on a node and dynamically adapt the number of reserved >>> cells to satisfy queue size, delay and/or power >>> consumption thresholds. >>> This mechanism would work inside 6top, between pairs of >>> nodes. >>> As a first approach, it would be based on the minimal draft. >>> What do you think on this starting point? >>> I (gladly) receive comments to add or modify this proposal. >>> >>> Diego >>> >>> >>> >>> >>> -- >>> DIEGO DUJOVNE >>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacion= es >>> Facultad de Ingenier=EDa UDP >>> www.ingenieria.udp.cl >>> (56 2) 676 8125 >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> ** ** >>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch**** >>> >>> ** ** >>> >>> ** ** >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > --bcaec5171c2937d0e204e7eb8763 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Guillaume,

    I would like to keep the = algorithm (4) open, something like Objective Function in RPL. Make sense?

    Qin


    <= div class=3D"gmail_quote"> On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <<= a href=3D"mailto:guillaume.gaillard.maze@gmail.com" target=3D"_blank">guill= aume.gaillard.maze@gmail.com> wrote:
    Hi Qin and all,

    I agree with your separ= ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:
    - (1) to over-provis= ion cells in the schedule in order to be "sure" to meet the requi= rement (pre-allocation);
    - (2) to adapt the cell allocation to the variations of the network pa= rameters (post-allocation);
    - (3) to do both things.
    When solution (2) is adopted, one should tolerate a time of de= graded QoS, before the requirement is restored.

    I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple= mentation-specific ?

    Regards,

    Guillaume Gaillard

    Orange Labs Meylan/CI= TI INRIA-INSA Lyon
    PhD student "SLA pour R=E9seaux de Capteu= rs Multi-Services"
    Advisors D. Barthel, F. Valois, F. Theole= yre


    =
    2013/10/4 Qin Wang <qinwang@berkeley.edu= >
    Hi Pascal and all,

    It = is a interesting approach. I would like to put different approaches above t= ogether.

    Objective: meet some QoS requirement.
    Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu= ndle, and on/off them on demand.
    Tool 2: post-allocation, like discussed in other emails in this thread= , adjust the number of cells in a bundle according to statistics informatio= n.

    In reality, I think a mote may use the combinat= ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells = for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates = 3 more cells for the bundle, and then also use them in the mode of on/off o= n demand.=A0

    If it is the case, a solution should include the the fo= llowing parts:
    (1) mechanism to create/delete softcells
    (2) mechanism to provide statistics information
    (3) mechanism to= on/off cell on demand
    (4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)= =A0

    What do you think?

    Qin
    =A0



    On Fri, Oct 4, 2013 at 5:30 PM, Pasca= l Thubert (pthubert) <pthubert@cisco.com> wrote:

    Dear all:

    =A0

    Statistics and hysteresis can be costly in terms of memory and C= PU, may not be the best strategy to address bursts of traffic in a stochast= ic IP network, and the strategy to derive the allocation from the past observation may be har= d to determine in a particular case and even harder to generalize.

    =A0

    The needs of bandwidth may be very dynamic for instance in the c= ase of alarms/alerts, or in the case of a brutal variation of monitored dat= a. Changes in the network topology impacting the rank of a node within the DAG may also impa= ct brutally its needs of bandwidth. So we cannot only rely on past observat= ions and but also need to maintain some capabilities that rely on current n= eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of = traffic and longer term variations.

    =A0

    Considering that we have ample room in a SlotFrame, a simple str= ategy, derived from traditional memory management, could be to augment the = number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g= row linearly one chunk at a time, but I know of chunk implementations that = double the size of a dynamic chunk each time it is saturated and a geometri= cal growth may a better approach for us.

    =A0

    In a bundle, a portion of the cells is always on. The rest can s= tay idle (no wake to send or listen) unless a previous cell indicates that = there is more to come. If we agree on a strategy like this then we can start working out th= e details, in particular how handle lazy release or one-shot override, how = we observe unallocated slots to make them candidate for allocation, etc...<= u>

    =A0

    As you see, even implementing such a simple strategy can already= be quite some work in a constrained device.

    =A0

    Cheers,

    =A0

    Pascal

    =A0

    From: 6tsch-bounces@ietf.o= rg [mailto:= 6tsch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
    Sent: vendredi 4 octobre 2013 09:19
    To: Thomas Watteyne; 6TSCH


    Subject: Re: [6tsch] On the fly scheduling
    =

    =A0

    +1 for me too.

    =A0

    For sure, according to the specific requirements of the applicat= ions, different algorithms may be used for building the schedule. But the f= unctionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

    =A0

    The statistics needed could change because different algorithms = may use different input as parameters. =A0So, we will have to include a set= of statistic information, or anyway, make sure it is possible to extend them.

    =A0

    Maria Rita

    =A0

    =A0

    =A0

    From: 6tsch-bounces@i= etf.org [ma= ilto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    That would indeed be clean.

    =A0

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wrote:<= u>

    Hi all,

    =A0

    +1 for the proposal.=A0

    =A0

    Regarding to how to approach, I agree with Thomas. There is an entity ru= nning on top of 6top, which reads queue information and other statistics in= formation from 6top, sends instruction like create/delete softcells to 6top= . I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

    =A0

    What do you think?

    =A0

    Qin=A0

    =A0

    =A0

    =A0

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu= > wrote:

    +1 for the proposal.

    =A0

    I believe it could be a very simple and powerful approach. Diego, would = you agree that this can be considered a distributed mechanism sitting on to= p of 6top?

    =A0

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
      • <= li> commands to retrieve usage statistics of the cells/bundles

    The way I see it, your proposal consists of an algorithm which feeds fro= m the usage statistics and triggers changes in the number of soft cells in = a bundle. Correct?

    =A0

    The questions to answer for now is whether 6top provides the right stati= stics.

    =A0

    Maria Rita, one big difference with TASA is that OTF scheduling is distr= ibuted.

    =A0

    Thomas

    =A0

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.palattella@u= ni.lu> wrote:

    Diego,( all)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From: 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    +1 too.=

    =A0

    I think that the queue size matters at enqueue but the latency i= s really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions in such a device). If one of the 2 condi= tions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. =

    =A0

    I agree with Xavi that we want to avoid changing the bundle size= all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h= appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IPR on chaining time slots and flagging w= hether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

    =A0

    Pascal

    =A0

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a very interesting idea to= explore. Maybe we can start putting some rules of this mechanism on the ta= ble and prepare a simulation. I am completely in with that idea.<= /u>

    Some questions arise:

    1-how fast do you react to changes on the queue size to avoid hysteresis= -- i.e how do you maintain certain stability in the schedule (so you don&#= 39;t start installing and removing links very often)

    2-how you map queue size (only one or if more than one queue) to actual = link requirements

    3-how you recover from link collisions in case of multiple nodes schedul= e the same cells.

    4-how to decide to who (what neighbor) install more links according to q= ueue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    --bcaec5171c2937d0e204e7eb8763-- From guillaume.gaillard.maze@gmail.com Fri Oct 4 08:07:05 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E467121F9D68 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 08:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwWpDStJ61Cs for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 08:06:54 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CD5F121F9D2C for <6tsch@ietf.org>; Fri, 4 Oct 2013 08:03:43 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so796584wes.33 for <6tsch@ietf.org>; Fri, 04 Oct 2013 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ZeoRIEsh0wYfZyBlWiSVCr6rhZn3yGMh+cbhadGIE0=; b=FrIQw4XVVOLqw1M64+/S0V48VR9rH1KyKjw4DY7jEltdsAOmeh3qHpf1khsNNB7KRY A7S4xUuaNcYAs17PvXD8vRDqf2dN1L6bDJuHTauf6Z3SdljBQiPISjLKcsQi1jzmaAWD YYcNrL+c2bY8GsLk21McEH/dWKcrw6TbZHOODHG8eRj7u75ijfQSdLq1QSVLncxlD5J/ ewgEX8tY8psr+z/WXwLEAIFIivySCCAdH9CVvR3ctoitVfGnjB3yeadPVdNnbuKjNZgP Zqbr1VS3bJoYsr5zgv8fc8tEvrYBddzLbFwmukKYDfmyu9V9lhXfdq+xgKxgPXwRtDYJ xmjA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr2052770wjb.55.1380899021360; Fri, 04 Oct 2013 08:03:41 -0700 (PDT) Received: by 10.217.10.199 with HTTP; Fri, 4 Oct 2013 08:03:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 17:03:41 +0200 Message-ID: From: Guillaume Gaillard To: Qin Wang Content-Type: multipart/alternative; boundary=089e010d8574a396ad04e7eb9b16 Cc: 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] On the fly scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 15:07:05 -0000 --089e010d8574a396ad04e7eb9b16 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Qin, It makes sense for me, Guillaume 2013/10/4 Qin Wang > Hi Guillaume, > > I would like to keep the algorithm (4) open, something like Objective > Function in RPL. Make sense? > > Qin > > > On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard < > guillaume.gaillard.maze@gmail.com> wrote: > >> Hi Qin and all, >> >> I agree with your separation into two tools (pre-allocation vs >> post-allocation). When one wants to meet a new QoS requirement, it is >> possible: >> - (1) to over-provision cells in the schedule in order to be "sure" to >> meet the requirement (pre-allocation); >> - (2) to adapt the cell allocation to the variations of the network >> parameters (post-allocation); >> - (3) to do both things. >> >> When solution (2) is adopted, one should tolerate a time of degraded QoS= , >> before the requirement is restored. >> >> I agree on your list of mechanisms a solution requires. Is the algorithm >> (4) (matching number of cell with QoS requirements) implementation-speci= fic >> ? >> >> Regards, >> >> Guillaume Gaillard >> >> Orange Labs Meylan/CITI INRIA-INSA Lyon >> PhD student "SLA pour R=E9seaux de Capteurs Multi-Services" >> Advisors D. Barthel, F. Valois, F. Theoleyre >> >> >> >> 2013/10/4 Qin Wang >> >>> Hi Pascal and all, >>> >>> It is a interesting approach. I would like to put different approaches >>> above together. >>> >>> Objective: meet some QoS requirement. >>> Tool 1: pre-allocation, like what Pascal suggested, assign number of >>> cells to a bundle, and on/off them on demand. >>> Tool 2: post-allocation, like discussed in other emails in this thread, >>> adjust the number of cells in a bundle according to statistics informat= ion. >>> >>> In reality, I think a mote may use the combination of tool 1 and tool 2= , >>> e.g. at the beginning, mote allocates some cells for a bundle, and use = them >>> in the mode of on/off on demand; when statistics information show 2 mor= e >>> cells needed, then mote is triggered to allocates 3 more cells for the >>> bundle, and then also use them in the mode of on/off on demand. >>> >>> If it is the case, a solution should include the the following parts: >>> (1) mechanism to create/delete softcells >>> (2) mechanism to provide statistics information >>> (3) mechanism to on/off cell on demand >>> (4) algorithm to determine how many cells needed for a QoS requirement >>> like (dataflow/burst-feature, delay-tolerance, {statistics info}, ...) >>> >>> What do you think? >>> >>> Qin >>> >>> >>> >>> >>> On Fri, Oct 4, 2013 at 5:30 PM, Pascal Thubert (pthubert) < >>> pthubert@cisco.com> wrote: >>> >>>> Dear all:**** >>>> >>>> ** ** >>>> >>>> Statistics and hysteresis can be costly in terms of memory and CPU, ma= y >>>> not be the best strategy to address bursts of traffic in a stochastic = IP >>>> network, and the strategy to derive the allocation from the past >>>> observation may be hard to determine in a particular case and even har= der >>>> to generalize.**** >>>> >>>> ** ** >>>> >>>> The needs of bandwidth may be very dynamic for instance in the case of >>>> alarms/alerts, or in the case of a brutal variation of monitored data. >>>> Changes in the network topology impacting the rank of a node within th= e DAG >>>> may also impact brutally its needs of bandwidth. So we cannot only rel= y on >>>> past observations and but also need to maintain some capabilities that= rely >>>> on current needs that operate efficiently in terms of control and yet = very >>>> dynamically to accept both brutal bursts of traffic and longer term >>>> variations.**** >>>> >>>> ** ** >>>> >>>> Considering that we have ample room in a SlotFrame, a simple strategy, >>>> derived from traditional memory management, could be to augment the nu= mber >>>> of cells in a bundle each time it is saturated. As an image, GNU=92s o= bstack >>>> seem to grow linearly one chunk at a time, but I know of chunk >>>> implementations that double the size of a dynamic chunk each time it i= s >>>> saturated and a geometrical growth may a better approach for us. **** >>>> >>>> ** ** >>>> >>>> In a bundle, a portion of the cells is always on. The rest can stay >>>> idle (no wake to send or listen) unless a previous cell indicates that >>>> there is more to come. If we agree on a strategy like this then we can >>>> start working out the details, in particular how handle lazy release o= r >>>> one-shot override, how we observe unallocated slots to make them candi= date >>>> for allocation, etc...**** >>>> >>>> ** ** >>>> >>>> As you see, even implementing such a simple strategy can already be >>>> quite some work in a constrained device. **** >>>> >>>> ** ** >>>> >>>> Cheers,**** >>>> >>>> ** ** >>>> >>>> Pascal**** >>>> >>>> ** ** >>>> >>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>>> Behalf Of *Maria Rita PALATTELLA >>>> *Sent:* vendredi 4 octobre 2013 09:19 >>>> *To:* Thomas Watteyne; 6TSCH >>>> >>>> *Subject:* Re: [6tsch] On the fly scheduling**** >>>> >>>> ** ** >>>> >>>> +1 for me too.**** >>>> >>>> ** ** >>>> >>>> For sure, according to the specific requirements of the applications, >>>> different algorithms may be used for building the schedule. But the >>>> functionalities offers by 6top (i.e., collect statist. Info, send comm= ands >>>> for scheduling cells) will be still the same (no matter which algorith= m is >>>> used). **** >>>> >>>> ** ** >>>> >>>> The statistics needed could change because different algorithms may us= e >>>> different input as parameters. So, we will have to include a set of >>>> statistic information, or anyway, make sure it is possible to extend t= hem. >>>> **** >>>> >>>> ** ** >>>> >>>> Maria Rita**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org<6tsch-bo= unces@ietf.org>] >>>> *On Behalf Of *Thomas Watteyne >>>> *Sent:* Thursday, October 03, 2013 10:11 PM >>>> *To:* 6TSCH >>>> *Subject:* Re: [6tsch] On the fly scheduling**** >>>> >>>> ** ** >>>> >>>> That would indeed be clean.**** >>>> >>>> ** ** >>>> >>>> On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang wrote= : >>>> **** >>>> >>>> Hi all,**** >>>> >>>> ** ** >>>> >>>> +1 for the proposal. **** >>>> >>>> ** ** >>>> >>>> Regarding to how to approach, I agree with Thomas. There is an entity >>>> running on top of 6top, which reads queue information and other statis= tics >>>> information from 6top, sends instruction like create/delete softcells = to >>>> 6top. I think we can use the design methodology of Objective Function = in >>>> RPL, i.e. define the statistics information and the interface to/from = 6top, >>>> and leave the specific algorithm open.**** >>>> >>>> ** ** >>>> >>>> What do you think?**** >>>> >>>> ** ** >>>> >>>> Qin **** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne < >>>> watteyne@eecs.berkeley.edu> wrote:**** >>>> >>>> +1 for the proposal.**** >>>> >>>> ** ** >>>> >>>> I believe it could be a very simple and powerful approach. Diego, woul= d >>>> you agree that this can be considered a distributed mechanism sitting = on >>>> top of 6top?**** >>>> >>>> ** ** >>>> >>>> That is, 6top provides:**** >>>> >>>> - commands to modify the number of soft cells in a bundle**** >>>> - commands to retrieve usage statistics of the cells/bundles**** >>>> >>>> The way I see it, your proposal consists of an algorithm which feeds >>>> from the usage statistics and triggers changes in the number of soft c= ells >>>> in a bundle. Correct?**** >>>> >>>> ** ** >>>> >>>> The questions to answer for now is whether 6top provides the right >>>> statistics.**** >>>> >>>> ** ** >>>> >>>> Maria Rita, one big difference with TASA is that OTF scheduling is >>>> distributed.**** >>>> >>>> ** ** >>>> >>>> Thomas**** >>>> >>>> ** ** >>>> >>>> On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA < >>>> maria-rita.palattella@uni.lu> wrote:**** >>>> >>>> Diego,( all) >>>> >>>> what you are suggesting (i.e., reserve cells based on queue size, >>>> delay) is actually the main idea behind TASA (Traffic Aware Scheduling >>>> Algorithm). >>>> >>>> TASA builds the schedule based on the local (number of pkt generated b= y >>>> the node) and global queue level ( i.e., local + pkt to be forwarded, >>>> generated by children). It gives priority to nodes with longer queues = and >>>> it aims to reduce the latency for delivering the pkt. At the same time >>>> while building the schedule it minimizes the number of scheduled cells= in >>>> order to reduce the network duty cycle. >>>> TASA is centralized and thus it assumes that the PCE has all the info >>>> needed for setting up the schedule. in other words, it knows the traff= ic >>>> generated by each nodes, and the paths followed by each pkt. >>>> With a "on the fly solution", we will not need to know all this info a >>>> priori. but we will use 6top monitoring functions and the control flow= s >>>> message for scheduling the cells. >>>> >>>> Btw, I agree with all the points raised up by Xavi. We will have to >>>> address his questions. >>>> >>>> And I support Pascal's suggestions about how to deal with bundle. >>>> >>>> Maria Rita**** >>>> ------------------------------ >>>> >>>> *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of >>>> Pascal Thubert (pthubert) [pthubert@cisco.com] >>>> *Sent:* Thursday, October 03, 2013 4:09 PM >>>> *To:* xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne**** >>>> >>>> >>>> *Cc:* 6TSCH >>>> *Subject:* Re: [6tsch] On the fly scheduling**** >>>> >>>> ** ** >>>> >>>> +1 too.**** >>>> >>>> **** >>>> >>>> I think that the queue size matters at enqueue but the latency is >>>> really what we care for at dequeue, that is how long did this device k= eep >>>> this message in queue (even if we are far from **** >>>> >>>> buffer bloat conditions in such a device). If one of the 2 conditions >>>> (size at enqueue, latency at dequeue) is reached then the bundle shoul= d be >>>> increased. **** >>>> >>>> **** >>>> >>>> I agree with Xavi that we want to avoid changing the bundle size all >>>> the time. We discussed that with Qin and others earlier on the ML. One= way >>>> of increasing the bundle dynamically at a very low cost (not even a >>>> hysteresis) is to have it large amount of cells from the start but us= ed >>>> like 10% by default (xmit/listen happens only once in 10 time slots). = A bit >>>> in the frame indicates whether the next (normally unused) slot will in= deed >>>> be used. The bit can be present in the data and acked in the ack. This= can >>>> also implicitly be triggered for retries.**** >>>> >>>> **** >>>> >>>> Please keep us tuned!**** >>>> >>>> **** >>>> >>>> Cheers,**** >>>> >>>> **** >>>> >>>> PS Note that Cisco has IPR on chaining time slots and flagging whether >>>> the next is used or not. We already declared our IPR against the >>>> architecture draft and provided terms.**** >>>> >>>> **** >>>> >>>> Pascal**** >>>> >>>> **** >>>> >>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On >>>> Behalf Of *Xavier Vilajosana Guillen >>>> *Sent:* jeudi 3 octobre 2013 15:46 >>>> *To:* Prof. Diego Dujovne >>>> *Cc:* 6TSCH >>>> *Subject:* Re: [6tsch] On the fly scheduling**** >>>> >>>> **** >>>> >>>> Diego, >>>> >>>> +1**** >>>> >>>> it seems to a me a very interesting idea to explore. Maybe we can star= t >>>> putting some rules of this mechanism on the table and prepare a simula= tion. >>>> I am completely in with that idea.**** >>>> >>>> Some questions arise:**** >>>> >>>> 1-how fast do you react to changes on the queue size to avoid >>>> hysteresis -- i.e how do you maintain certain stability in the schedul= e (so >>>> you don't start installing and removing links very often)**** >>>> >>>> 2-how you map queue size (only one or if more than one queue) to actua= l >>>> link requirements**** >>>> >>>> 3-how you recover from link collisions in case of multiple nodes >>>> schedule the same cells.**** >>>> >>>> 4-how to decide to who (what neighbor) install more links according to >>>> queue size?**** >>>> >>>> **** >>>> >>>> cheers! >>>> Xavi**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne < >>>> diego.dujovne@mail.udp.cl> wrote:**** >>>> >>>> Dear all, >>>> I've been looking into the idea of "on the fly scheduling"= , >>>> presented on the Sept 27th webex call as "on-the-fly decentralized >>>> reservation". >>>> The basic mechanism would be based on analysing the queue size >>>> on a node and dynamically adapt the number of reserved >>>> cells to satisfy queue size, delay and/or power >>>> consumption thresholds. >>>> This mechanism would work inside 6top, between pairs of >>>> nodes. >>>> As a first approach, it would be based on the minimal draft. >>>> What do you think on this starting point? >>>> I (gladly) receive comments to add or modify this proposal. >>>> >>>> Diego >>>> >>>> >>>> >>>> >>>> -- >>>> DIEGO DUJOVNE >>>> Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicacio= nes >>>> Facultad de Ingenier=EDa UDP >>>> www.ingenieria.udp.cl >>>> (56 2) 676 8125 >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch**** >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch**** >>>> >>>> ** ** >>>> >>>> >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> _______________________________________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tsch >>>> >>>> >>> >>> _______________________________________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tsch >>> >>> >> > --089e010d8574a396ad04e7eb9b16 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Qin,

    It makes sense for me,

    Guillaume


    2013/10/4 Qin Wang <qinwang@berkeley.edu= >
    Hi Guillaume,

    I would like to keep the algorithm (4) open, something like Objective= Function in RPL. Make sense?

    Qin


    On Fri, Oct 4, 2013 at 10:54 PM, Guillaume Gaillard <<= a href=3D"mailto:guillaume.gaillard.maze@gmail.com" target=3D"_blank">guill= aume.gaillard.maze@gmail.com> wrote:
    Hi Qin and all,

    I agree with your separ= ation into two tools (pre-allocation vs post-allocation). When one wants to= meet a new QoS requirement, it is possible:
    - (1) to over-provis= ion cells in the schedule in order to be "sure" to meet the requi= rement (pre-allocation);
    - (2) to adapt the cell allocation to the variations of the network pa= rameters (post-allocation);
    - (3) to do both things.
    When solution (2) is adopted, one should tolerate a time of de= graded QoS, before the requirement is restored.

    I agree on your list of mechanisms a solution requires.= Is the algorithm (4) (matching number of cell with QoS requirements) imple= mentation-specific ?

    Regards,

    Guillaume Gaillard

    Orange Labs Meylan/CI= TI INRIA-INSA Lyon
    PhD student "SLA pour R=E9seaux de Capteu= rs Multi-Services"
    Advisors D. Barthel, F. Valois, F. Theole= yre



    2013/10/4 Qin Wang <qinwang@berkeley.edu>
    Hi Pascal and all,

    It = is a interesting approach. I would like to put different approaches above t= ogether.

    Objective: meet some QoS requirement.
    Tool 1:= pre-allocation, like what Pascal suggested, assign number of cells to a bu= ndle, and on/off them on demand.
    Tool 2: post-allocation, like discussed in other emails in this thread= , adjust the number of cells in a bundle according to statistics informatio= n.

    In reality, I think a mote may use the combinat= ion of tool 1 and tool 2, e.g. at the beginning, mote allocates some cells = for a bundle, and use them in the mode of on/off on demand; when statistics= information show 2 more cells needed, then mote is triggered to allocates = 3 more cells for the bundle, and then also use them in the mode of on/off o= n demand.=A0

    If it is the case, a solution should include the the fo= llowing parts:
    (1) mechanism to create/delete softcells
    (2) mechanism to provide statistics information
    (3) mechanism to= on/off cell on demand
    (4) algorithm to determine how many cells needed for a QoS requirement= like (dataflow/burst-feature, delay-tolerance, {statistics info}, =A0...)= =A0

    What do you think?

    Qin
    =A0



    On Fri, Oct 4, 2013 at 5:30 PM, Pasca= l Thubert (pthubert) <pthubert@cisco.com> wrote:

    Dear all:

    =A0

    Statistics and hysteresis can be costly in terms of memory and C= PU, may not be the best strategy to address bursts of traffic in a stochast= ic IP network, and the strategy to derive the allocation from the past observation may be har= d to determine in a particular case and even harder to generalize.

    =A0

    The needs of bandwidth may be very dynamic for instance in the c= ase of alarms/alerts, or in the case of a brutal variation of monitored dat= a. Changes in the network topology impacting the rank of a node within the DAG may also impa= ct brutally its needs of bandwidth. So we cannot only rely on past observat= ions and but also need to maintain some capabilities that rely on current n= eeds that operate efficiently in terms of control and yet very dynamically to accept both brutal bursts of = traffic and longer term variations.

    =A0

    Considering that we have ample room in a SlotFrame, a simple str= ategy, derived from traditional memory management, could be to augment the = number of cells in a bundle each time it is saturated. As an image, GNU=92s obstack seem to g= row linearly one chunk at a time, but I know of chunk implementations that = double the size of a dynamic chunk each time it is saturated and a geometri= cal growth may a better approach for us.

    =A0

    In a bundle, a portion of the cells is always on. The rest can s= tay idle (no wake to send or listen) unless a previous cell indicates that = there is more to come. If we agree on a strategy like this then we can start working out th= e details, in particular how handle lazy release or one-shot override, how = we observe unallocated slots to make them candidate for allocation, etc...<= u>

    =A0

    As you see, even implementing such a simple strategy can already= be quite some work in a constrained device.

    =A0

    Cheers,

    =A0

    Pascal

    =A0

    From: 6tsch-bounces@ietf.o= rg [mailto:= 6tsch-bounces@ietf.org] On Behalf Of Maria Rita PALATTELLA
    Sent: vendredi 4 octobre 2013 09:19
    To: Thomas Watteyne; 6TSCH


    Subject: Re: [6tsch] On the fly scheduling
    =

    =A0

    +1 for me too.

    =A0

    For sure, according to the specific requirements of the applicat= ions, different algorithms may be used for building the schedule. But the f= unctionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) = will be still the same (no matter which algorithm is used).

    =A0

    The statistics needed could change because different algorithms = may use different input as parameters. =A0So, we will have to include a set= of statistic information, or anyway, make sure it is possible to extend them.

    =A0

    Maria Rita

    =A0

    =A0

    =A0

    From: 6tsch-bounces@i= etf.org [ma= ilto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne
    Sent: Thursday, October 03, 2013 10:11 PM
    To: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    That would indeed be clean.

    =A0

    On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <qinwang@berkeley.edu> wrote:<= u>

    Hi all,

    =A0

    +1 for the proposal.=A0

    =A0

    Regarding to how to approach, I agree with Thomas. There is an entity ru= nning on top of 6top, which reads queue information and other statistics in= formation from 6top, sends instruction like create/delete softcells to 6top= . I think we can use the design methodology of Objective Function in RPL, i.e. define the s= tatistics information and the interface to/from 6top, and leave the specifi= c algorithm open.

    =A0

    What do you think?

    =A0

    Qin=A0

    =A0

    =A0

    =A0

    On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu= > wrote:

    +1 for the proposal.

    =A0

    I believe it could be a very simple and powerful approach. Diego, would = you agree that this can be considered a distributed mechanism sitting on to= p of 6top?

    =A0

    That is, 6top provides:

    • commands to modify the number of soft cells in a bundle
      • <= li> commands to retrieve usage statistics of the cells/bundles

    The way I see it, your proposal consists of an algorithm which feeds fro= m the usage statistics and triggers changes in the number of soft cells in = a bundle. Correct?

    =A0

    The questions to answer for now is whether 6top provides the right stati= stics.

    =A0

    Maria Rita, one big difference with TASA is that OTF scheduling is distr= ibuted.

    =A0

    Thomas

    =A0

    On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <maria-rita.palattella@u= ni.lu> wrote:

    Diego,( all)

    what you are suggesting (i.e., reserve cells based on queue size, delay) is= actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).
    TASA builds the schedule based on the local (number of pkt generated by the= node) and global queue level ( i.e., local + pkt to be forwarded, generate= d by children). It gives priority to nodes with longer queues and it aims t= o reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the num= ber of scheduled cells in order to reduce the network duty cycle.
    TASA is centralized and thus it assumes that the PCE has all the info neede= d for setting up the schedule. in other words, it knows the traffic generat= ed by each nodes, and the paths followed by each pkt.
    With a "on the fly solution", we will not need to know all this i= nfo a priori. but we will use 6top monitoring functions and the control flo= ws message for scheduling the cells.

    Btw, I agree with all the points raised up by Xavi.=A0 We will have to addr= ess his questions.

    And I support Pascal's suggestions about how to deal with bundle.

    Maria Rita

    From: 6tsch-bounces@i= etf.org [6t= sch-bounces@ietf.org] on behalf of Pascal Thubert (pthubert) [pthubert@cisco.com] Sent: Thursday, October 03, 2013 4:09 PM
    To: xvilajosana@eecs.berkeley.edu; Prof. Diego Dujovne


    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    += 1 too.

    =A0

    I think that the queue size matters at enqueue but the latency i= s really what we care for at dequeue, that is how long did this device keep this message in queue (even if we ar= e far from

    buffer bloat conditions in such a device). If one of the 2 condi= tions (size at enqueue, latency at dequeue) is reached then the bundle should be increased. =

    =A0

    I agree with Xavi that we want to avoid changing the bundle size= all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dy= namically at a very low cost (not even a hysteresis) =A0is to have it large= amount of cells from the start but used like 10% by default (xmit/listen h= appens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will = indeed be used. The bit can be present in the data and acked in the ack. Th= is can also implicitly be triggered for retries.

    =A0

    Please keep us tuned!

    =A0

    Cheers,

    =A0

    PS Note that Cisco has IPR on chaining time slots and flagging w= hether the next is used or not. We already declared our IPR against the architecture draft and provided terms= .

    =A0

    Pascal

    =A0

    From: 6tsch-bounces@i= etf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: jeudi 3 octobre 2013 15:46
    To: Prof. Diego Dujovne
    Cc: 6TSCH
    Subject: Re: [6tsch] On the fly scheduling

    =A0

    Diego,

    +1

    it seems to a me a very interesting idea to= explore. Maybe we can start putting some rules of this mechanism on the ta= ble and prepare a simulation. I am completely in with that idea.<= /u>

    Some questions arise:

    1-how fast do you react to changes on the queue size to avoid hysteresis= -- i.e how do you maintain certain stability in the schedule (so you don&#= 39;t start installing and removing links very often)

    2-how you map queue size (only one or if more than one queue) to actual = link requirements

    3-how you recover from link collisions in case of multiple nodes schedul= e the same cells.

    4-how to decide to who (what neighbor) install more links according to q= ueue size?

    =A0

    cheers!
    Xavi

    =A0

    =A0

    On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:

    Dear all,
    =A0 =A0 =A0 =A0 =A0 =A0 I've been looking into the idea of "on the= fly scheduling",
    presented on the Sept 27th webex call as "on-the-fly decentralized res= ervation".
    The basic mechanism would be based on analysing the queue size
    on a node and dynamically adapt the number of reserved
    cells to satisfy queue size, delay and/or power
    consumption thresholds.
    =A0 =A0 =A0 =A0 =A0 =A0 This mechanism would work inside 6top, between pair= s of nodes.
    As a first approach, it would be based on the minimal draft.
    What do you think on this starting point?
    I (gladly) receive comments to add or modify this proposal.

    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Diego




    --
    DIEGO DUJOVNE
    Acad=E9mico Escuela de Ingenier=EDa en Inform=E1tica y Telecomunicaciones Facultad de Ingenier=EDa UDP
    www.ingenieria.u= dp.cl
    (56 2) 676 8125=
    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    =A0

    =A0


    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch



    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch




    --089e010d8574a396ad04e7eb9b16-- From twatteyne@gmail.com Fri Oct 4 09:16:18 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED5A21F9C42 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR2DqNqOR8Sj for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 09:16:11 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4746121F9A2E for <6tsch@ietf.org>; Fri, 4 Oct 2013 09:10:15 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so4221950pdj.31 for <6tsch@ietf.org>; Fri, 04 Oct 2013 09:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=cJI0tTnJwqKTu23sNhC+4HAbJwixDIDU1i+qnKrG3Bw=; b=hPWnkv4QUiFKp9XU0+7yhIzRn0fLlRk9wOe6gO13SKZYsXwdY6Jcu1oFYRKXC/v8fF sYizBxEG5djKf58oDv5P3a38RIpEcSm7v4VZotxFWkSrA2rcc9xDJRMXZNyP2eKO2vWf 1FjUGEXzZ4wt7MpREyv6n84vqvmevrJ86GxXvHKqbPhtukhOvzHHgOjxr0iJvacPGmin jdJk0YVmzCZzCTENJbWFZciLK8pfkkBCDIYHGT2tEX+iSkua5ZBtv892Rvc0cRJmoACw WVR5v/N5RIPzNkngqJ2pG6sVMP02gb266WN/WBimeYCHP5ZdG5WqsN7BMAGo3dnXQRp2 t7EA== X-Received: by 10.67.4.227 with SMTP id ch3mr16849527pad.74.1380903014964; Fri, 04 Oct 2013 09:10:14 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Fri, 4 Oct 2013 09:09:53 -0700 (PDT) From: Thomas Watteyne Date: Fri, 4 Oct 2013 09:09:53 -0700 X-Google-Sender-Auth: PgMxwjZ8uZfkrBoXtoVLYyBaUts Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=047d7b16018dad235904e7ec89cb Subject: [6tsch] extra note taker at today's 6TiSCH call? X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:16:18 -0000 --047d7b16018dad235904e7ec89cb Content-Type: text/plain; charset=ISO-8859-1 Quick "administrative" question: who joined Xavi and myself taking notes on Etherpad at the 6TiSCH call today? Thanks! I'd like to make sure your name appears in the minutes. Thomas --047d7b16018dad235904e7ec89cb Content-Type: text/html; charset=ISO-8859-1
    Quick "administrative" question: who joined Xavi and myself taking notes on Etherpad at the 6TiSCH call today? Thanks! I'd like to make sure your name appears in the minutes.

    Thomas
    --047d7b16018dad235904e7ec89cb-- From twatteyne@gmail.com Fri Oct 4 11:04:33 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D1221F9D92 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vDGMsn80MQX for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:04:31 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D8EA221F9C6A for <6tsch@ietf.org>; Fri, 4 Oct 2013 11:04:28 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so4479770pad.19 for <6tsch@ietf.org>; Fri, 04 Oct 2013 11:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=AowsAxleWJJPhkBYJ5iZxzFIgv/jHA8dWfTCQZl1XDQ=; b=o924ItKKPXaEY8jCnZQXmk41HWnagfHCeC8lX1BM6K8Tb9HizkzRg4PSDsS/GdkhLQ GblVDuSL127ih5gBtXITGdoxQqxAJRfb5sqFfS6ntw6ErmqZ6MzBDptXaelIWIsWS3C1 y01jqq6yOcnlC0TNaRiRH9Q4TlG5ePwgjEQiqxBHsSPE6Igp52TSL+RNJJMaeAJTQ8hx SByP0oSYg+/xFzVjdklvOiwZ4D8sf6uumCnrpweIyX/TxnTuQ3SfCxazN32uI8+wWAom fCD7eA21R87HPKHUNVy0EppZVqNxmU1l7RUdvNibyXyH6zAmYcOuOWuU83SqAiJppwVb uehw== X-Received: by 10.68.76.65 with SMTP id i1mr15903576pbw.37.1380909867543; Fri, 04 Oct 2013 11:04:27 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.147.193 with HTTP; Fri, 4 Oct 2013 11:04:06 -0700 (PDT) From: Thomas Watteyne Date: Fri, 4 Oct 2013 11:04:06 -0700 X-Google-Sender-Auth: 9vacumROkuPsKfUDKPTMXm1C_3Q Message-ID: To: 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=e89a8f923c641f359904e7ee22a9 Subject: [6tsch] minutes webex 4 October 2013 X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:04:33 -0000 --e89a8f923c641f359904e7ee22a9 Content-Type: text/plain; charset=ISO-8859-1 All, You will find the minutes of this week's webex below. FYI, all the minutes and slides are archived a https://bitbucket.org/6tsch/meetings/. Thanks to Xavi and Pascal for taking notes! As usual, please fix anything we might have missed directly in the e-mail and reply. We will approve and adopt the minutes at the beginning of the next call. Thomas ----- Minutes Webex 4 October 2013, 6TiSCH group Note: timestamps in PDT. Taking notes *(using Etherpad)* 1. Xavi Vilajosana 2. Pascal Thubert 3. Thomas Watteyne Present *(alphabetically)* 1. Thomas Watteyne 2. Pascal Thubert 3. Diego Dujovne 4. Geraldine Texier 5. Guillaume Gaillard 6. Ken Bannister 7. Maria Rita Palattella 8. Nicola Accettura 9. Patrick Wetterwald 10. Pouria Zand 11. Qin Wang 12. R. Nabati 13. Raghuram Sudhaakar 14. Tom Phinney 15. Xavi Vilajosana Recording - Webex recording (audio+slides,streaming) - https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=71974457&rKey=be427b317053fc31 *[63min]* Slides - slides_131004_webex.ppt: slides shared during the call Agenda - Administrivia *[3min]* - Approval agenda - Approval minutes last call - IETF88: preliminary agenda - minimal draft *[5min]* - join priority width - comments/changes - update models draft *[35min]* - summary Tuesday discussion - proposed ToC - separate payload format from CoAP resource mapping? - 6lo thread on monitoring - "[6lo] [coman] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)" - YANG/NETCONF vs. SMIv2/SNMP - information model in English, turned into YANG? - communication paradigms - 5-6 communication paradigms in architecture draft? - terminology: interaction model and communication paradigm - On-the-fly scheduling *[15min]* - overview - discussion - implementation - hysteresis - TASA - queue size vs. bundle usage - bit - separating algorithm from mechanism - goals and next steps? - AOB *[2min]* Minutes - *[08.04]* Meeting starts - *[08.05]* Administrivia - Approval agenda No issues raised. Agenda approved. - Approval minutes last call No issues raised. Minutes approved. - IETF88: preliminary agenda - IETF preliminary agenda has been delayed 1 day. Should appear today at http://www.ietf.org/meeting/88/. - Until Monday to request a change in meeting schedule (hopefully don't need to). - Final agenda published 11 October. - Cut-off date for draft submission (including -00) is 21 October. - minimal draft - join priority width - range of join priority is defined as 0x3f - answer from IEEE802.15.4e editor is that 0x3f might be an error and the byte is intended to be used as a complete byte. - this most probably means that using 0x00-0xff as the range (rather than 0x00-0x3f) is OK. - *[Qin]* This is good news. - comments/changes - Thanks to *Xavi* for incorporating all the changes! - *[Xavi]* Will incorporate Maria Rita's comments today. - update models draft - summary Tuesday discussion *[Raghuram]* - discuss contents of the data model draft - great input (including from Dan Romascanu) on how we can be consistent with the terminology to fit a data model as RFC3444 defines. - include: - naming convention to URI - mapping of URI to 6top resources - Message formats - Extensible resources - profile based definition? - how do we discover the profile, i.e. what messages will be exchange for that discovery methods? - custom uri to send back messages when event is detected - profile based definitions - including set of extensible resources e.g. PCE could install a profile that it needs for its computation - *Raghuram* to push current version on bitbucket repository today. - see https://bitbucket.org/6tsch/draft-sudhaakar-6tisch-coap - Discussion - *[Xavi]* The data model should be reused. Draft seems to bind it with CoAP. Should be separated for use e.g. by RSVP to be described in another draft? - *[Raghuram]* agreed. But there is limited time. - *[Pascal]* why is the content so tightly bound to CoAP? - *[Raghuram]* define the data model to be reusable in different transport. - *[Pouria]* presents 6TiSCH MIB. - *[Qin]* Indicate for fields that can be read what observable trigger can be used. - *[Thomas]* Are there any fields which can be read for not observed? - *[Qin]* Having that option might enable a better handling of registration to observe, triggers, etc. - 6lo thread on monitoring - *[Thomas]* 6lo discusses the proposed charter of 6lo. Related MIB modules, they are looking for a way to monitor the state of a 6lo/6LowPAN network. - YANG/NETCONF vs. SMIv2/SNMP - Encourage editors of this draft to follow the 6lo discussion. - *[Thomas]* Clarifying question: NVP vs TLV? - *[Raghuram]* Name Value Pair: human readable ASCII format. - communication paradigms *[Pascal]* - ISA100 has 3 comm paradigms. - client/server - pub/sub - source/sink - abstract concept. - *[Tom]* based on IEC61158 - we have similar approach, but more options - point to point model (CoAP REST model) - At L3, multihop along track (RSVP-like) - At l2, single hop (6top) - Mapping of comm paradigm to protocol: - *[Thomas]* why SNMP? - *[Pascal]* way to implement Client/server. Just examples of protocols that can be used to implement the communication paradigms. - what document is the right place: - informational model: high level overview. - data model: YANG seems the direction to define the data model. - implement the data model in different data formats (CBOR, NVP, TLV, etc.) - data and command do not need to be tightly bound. - *[Raghuram]* in terms of CoAP cannot separate payload than URI and method, so the implementation is tight to the communication model. - *[Thomas]* do not see source/sink model as needed per-see. CoAP provides the observe and notifications. - *[Tom]* Source/sink is a application communication paradigm and there is no reason that it needs to be modelled that way in the communication layers. Most people end up with wireless running alerts to a single device (e.g. gateway, BBR). n-to-1 at the low layers. Source/sink applies to the application, and how you model it in the lower layers is really the responsibility of the implementers. - *[08.56]* on-the-fly scheduling - overview *[Diego]* - Idea is to adapt the number of cells according to the traffic constrains (queue size, etc.) on the fly. - This is a distributed approach. - discussion - implementation - run on top of 6top - define statistics and interface, algorithm is independent - hysteresis - map queue sizes to link requirements. - reaction time to avoid hysteresis - handle collisions with other neighbors scheduling same cell (not a global picture) - TASA - Distributed TASA? - IPR Cisco: - *[Diego]* what is covered? - *[Pascal]* Ciscp IPR does not matter as it covers many aspects, also in RPL. - *[Pascal]* Mentioning the IPR is mandatory, mentioned it in ML for that reason. - goals and next steps? - *[Thomas]* Good exercise to detect missing aspects on 6top as it is a use case on top of 6top. - *[Diego]* Yes, will do. - *[09.07]* AOB No other business raised. - *[09.08]* Meeting ends --e89a8f923c641f359904e7ee22a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable     --047d7b2e3d9e81aa1304e7eee24c-- From rsudhaak@cisco.com Sat Oct 5 08:29:43 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C580721F8F4A for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+7sYx6H1Hcg for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 08:29:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2721F8F09 for <6tsch@ietf.org>; Sat, 5 Oct 2013 08:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2327; q=dns/txt; s=iport; t=1380986979; x=1382196579; h=from:to:subject:date:message-id:mime-version; bh=XIAkGrxPGs4yAzZN+8UYjKyPTxW4faIGLGGN9jcrIUo=; b=VORg4nvAZcZ3oe7GiBG0UJB05fecsa4E2mpYlxQSdkMSQyv18LBXqss1 Srd0FC9u1Rr4ZH0HYy5+EAbRKzeHBIAVKxeCQei2bVw3vefXV0X6jhkNh 3u3FzRpJojcCkZ6QcBdGK0z8Ut8iv3Y8Rcu7elQzYTXc8yzvg89qatXOe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAFovUFKtJV2Y/2dsb2JhbABZgkNEgQrBGYEWFm0HgicBBIELAQwBHVYnBBuHfppaoSKPIINXgQQDqgGDJIIq X-IronPort-AV: E=Sophos;i="4.90,1039,1371081600"; d="scan'208,217";a="265464357" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Oct 2013 15:29:38 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r95FTb1H016390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <6tsch@ietf.org>; Sat, 5 Oct 2013 15:29:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.47]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Sat, 5 Oct 2013 10:29:37 -0500 From: "Raghuram Sudhaakar (rsudhaak)" To: "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: payload format for CoAP Thread-Index: AQHOwd+yn7Flwv2d9kmwyX3VZ2vcbA== Date: Sat, 5 Oct 2013 15:29:36 +0000 Message-ID: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.78.198] Content-Type: multipart/alternative; boundary="_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [6tsch] payload format for CoAP X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 15:29:43 -0000 --_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as the= possible CoAP payload formats. The line of discussion was 1. Obvious advantages of CBOR are related to control overhead. However t= he percentage advantage of CBOR over NVP is not established. 2. Constrained devices may not be able to handle the additional overhead= of a CBOR parser. NVPs are easy to parse. 3. But, the CoAP messages are typically layer 5 transactions and the pro= cessing constraint may not be applicable. 4. There is a clear tradeoff w.r.t simplicity vs efficiency in making th= e choice. I would like to call upon the group for more discussion on this topic so we= can reach a consensus. -raghuram --_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <27F6F12902716C48B340CEDE1CFBC35B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR a= s the possible CoAP payload formats.

    The line of discussion was
    1. Obvious advantages of CBOR are related to control overhead. However the= percentage advantage of CBOR over NVP is not established. 
    2. Co= nstrained devices may not be able to handle the additional overhead of a CB= OR parser. NVPs are easy to parse.
    3. But, the CoAP messages are typic= ally layer 5 transactions and the processing constraint may not be applicab= le.
    4. There is a clear tradeoff w.r.t simplicity vs efficiency in mak= ing the choice.
    I would like to call upon the group for more discussion on this topic = so we can reach a consensus.

    -raghuram
    --_000_2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCDxmbrcdx04ciscoc_-- From cabo@tzi.org Sat Oct 5 09:02:56 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB921F90AC for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNftY36lm6Sm for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 09:02:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 23AED21F8D12 for <6tsch@ietf.org>; Sat, 5 Oct 2013 09:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95G2jEM008854; Sat, 5 Oct 2013 18:02:45 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BE235C94; Sat, 5 Oct 2013 18:02:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com> Date: Sat, 5 Oct 2013 18:02:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com> To: "Raghuram Sudhaakar (rsudhaak)" X-Mailer: Apple Mail (2.1510) Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] payload format for CoAP X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:02:56 -0000 On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" = wrote: > =95 the additional overhead of a CBOR parser. NVPs are easy to = parse. CBOR is easy to parse, too. To inject some data here, if you are talking about code size overhead: size -m cn-cbor.o Section (__TEXT, __text): 880 If all you need is name-value pairs, a tailored CBOR parser will be even = less than those 880 bytes, which is armv7 code for a fully generic = parser (for instance, this code includes an implementation of = half-precision floating point.). For every single application, it is of course easy to come up with a = bespoke format that has some advantages over CBOR but only works for = this application, and we engineers of course like doing that :-). Your node may need to do other things in addition to exchanging 6tisch = data. So you already may have a CBOR parser in your constrained device, which = could make the incremental cost for using it with 6tisch near zero. Gr=FC=DFe, Carsten From cabo@tzi.org Sat Oct 5 09:31:27 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B821F8616; Sat, 5 Oct 2013 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7XAJn+DN-u; Sat, 5 Oct 2013 09:31:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1521F8447; Sat, 5 Oct 2013 09:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r95GVIrR013568; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58C9ECAC; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 5 Oct 2013 18:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, "dtls-iot@ietf.org" , "6lo@ietf.org WG" <6lo@ietf.org>, IETF 6TSCH <6tsch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [6tsch] Constrained Node/Network Cluster @ IETF88, early draft version X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:31:27 -0000 A first draft version of the IETF88 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 All times are PST (UTC-0800). The Constrained Node/Network group meetings are nicely spread out over = the week. The lwig/6tisch conflict is unfortunate; this will split the audience. The oauth conflict on Monday is survivable, we'll do all = security-related CoRE work on Thursday then. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency A INT *** lwig Light-Weight Implementation Guidance WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Regency D RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG From xvilajosana@berkeley.edu Sat Oct 5 13:45:14 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681021F9CC5 for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 13:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYmQZtYVGYRr for <6tsch@ietfa.amsl.com>; Sat, 5 Oct 2013 13:45:10 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 592AE21F9CB5 for <6tsch@ietf.org>; Sat, 5 Oct 2013 13:45:09 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so5416449pbb.5 for <6tsch@ietf.org>; Sat, 05 Oct 2013 13:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2KAxgJE+S5EBJlYHLf6RT44dGoeAWoHumYaAKdBNqAE=; b=YvQloFhiwB9rkArs+CVcJvBfsVASCxxfGSeaa+1MOFiW0CMp4TtpK40G4COb6Pav5z 7dBV8wuwBGAhEpXbo+dREe/b+DCZGEpRBsVguUQJSbFQYqrw/G7vY8F86C6OsFFZXgFI gFKGStea4CDXkyzZS7WrssONgQIQcfKmRbLAxQWv/w2eWbfd2FaD7VnP1KL6FN1GcWse g/Qq4vcoRNLfy/qp7/HBovkkaInULJLXgJXx+f9XaenQN2CNiDUVgETpgJkqR7yr/HVu QkZy6reqMsdhGiJ4hxd0TQVBE8CbpIGCaBl+66cus3SVoDtL0ORIOtcwk1d6CCT26nkV OJUg== X-Gm-Message-State: ALoCoQkL9bI0fmF0Mm+2Gz8gAY4kvN0Swl4skuKqfs86fnbDVqyUeOTN160Ogvk1uJH2yPqZsYHk MIME-Version: 1.0 X-Received: by 10.68.215.38 with SMTP id of6mr21842890pbc.14.1381005901737; Sat, 05 Oct 2013 13:45:01 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Sat, 5 Oct 2013 13:45:01 -0700 (PDT) In-Reply-To: References: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com> Date: Sat, 5 Oct 2013 13:45:01 -0700 Message-ID: From: Xavier Vilajosana Guillen To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11346638357c4104e8047e93 Cc: "Raghuram Sudhaakar \(rsudhaak\)" , "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] payload format for CoAP X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 20:45:14 -0000 --001a11346638357c4104e8047e93 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Carsten can we have access to a cbor parser implementation to do some testing in a very small microcontroller (e.g msp430). thanks! Xavi On Sat, Oct 5, 2013 at 9:02 AM, Carsten Bormann wrote: > On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" < > rsudhaak@cisco.com> wrote: > > > =95 the additional overhead of a CBOR parser. NVPs are easy to pa= rse. > > CBOR is easy to parse, too. > > To inject some data here, if you are talking about code size overhead: > size -m cn-cbor.o > Section (__TEXT, __text): 880 > > If all you need is name-value pairs, a tailored CBOR parser will be even > less than those 880 bytes, which is armv7 code for a fully generic parser > (for instance, this code includes an implementation of half-precision > floating point.). > > For every single application, it is of course easy to come up with a > bespoke format that has some advantages over CBOR but only works for this > application, and we engineers of course like doing that :-). > Your node may need to do other things in addition to exchanging 6tisch > data. > So you already may have a CBOR parser in your constrained device, which > could make the incremental cost for using it with 6tisch near zero. > > Gr=FC=DFe, Carsten > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > --001a11346638357c4104e8047e93 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Carsten

    can we have access = to a cbor parser implementation to do some testing in a very small microcon= troller (e.g msp430).

    thanks!
    Xavi




    On Sat, Oct 5, 2013 at 9:02 AM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
    On Oct 5, 2013, at 17:29, = "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com> wrote:

    > =A0 =A0 =A0 =95 the additional overhead of a CBOR parser. NVPs are eas= y to parse.

    CBOR is easy to parse, too.

    To inject some data here, if you are talking about code size overhead:
    size -m cn-cbor.o
    =A0 =A0 =A0 =A0 Section (__TEXT, __text): 880

    If all you need is name-value pairs, a tailored CBOR parser will be even le= ss than those 880 bytes, which is armv7 code for a fully generic parser (fo= r instance, this code includes an implementation of half-precision floating= point.).

    For every single application, it is of course easy to come up with a bespok= e format that has some advantages over CBOR but only works for this applica= tion, and we engineers of course like doing that :-).
    Your node may need to do other things in addition to exchanging 6tisch data= .
    So you already may have a CBOR parser in your constrained device, which cou= ld make the incremental cost for using it with 6tisch near zero.

    Gr=FC=DFe, Carsten

    _______________________________________________
    6tsch mailing list
    6tsch@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/6tsch

    --001a11346638357c4104e8047e93-- From xvilajosana@berkeley.edu Mon Oct 7 12:51:32 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ABE11E8116 for <6tsch@ietfa.amsl.com>; Mon, 7 Oct 2013 12:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tnaU7E5NsVt for <6tsch@ietfa.amsl.com>; Mon, 7 Oct 2013 12:51:26 -0700 (PDT) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id AF3EC11E8152 for <6tsch@ietf.org>; Mon, 7 Oct 2013 12:51:17 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so7527948pbc.30 for <6tsch@ietf.org>; Mon, 07 Oct 2013 12:51:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=Cym37pgle2GOpMOPUuRBbByxVG1og/xlH/eUhk88m6A=; b=MwMKPG2H92+/LHQKYVQpM41+DHVuH+kka9LrVdx/FKog2UAdGbz+1ZneWaFzgnIB2o bKp3zb/yRsBuXS9d8gkk87e/QAB/5+6e1V69j5Hf6DKiq7Vtu2eEg6Y+evwtkviFxHt8 R5Rwjg4Xp2LNR4OjgTIuJcLA6/1f7CuNZ4AMymLmjoJch5/CLTNHZRg8VeKq7WMF2BTa pBNNj8tcsF4fo9havzc4IYK+HyNDHEuf5YCljVYiuhYdx1s0gZI+wG0SpYM43Gyp6T/X MrgjfeuCYNekcTBqNXudd03Mfr+5NM8FjExhfSgZYS3uH6fOLdw1LqR9w8kHCb7+C6Da bnhA== X-Gm-Message-State: ALoCoQkWhtefhH0f5n/ZlMvhmrIXh12bpGuoPLKl7L1fm0z4zipu2NaVVmxtAF4PTujryYh1Cilk MIME-Version: 1.0 X-Received: by 10.68.0.101 with SMTP id 5mr11504141pbd.106.1381175477272; Mon, 07 Oct 2013 12:51:17 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Mon, 7 Oct 2013 12:51:17 -0700 (PDT) Date: Mon, 7 Oct 2013 12:51:17 -0700 Message-ID: From: Xavier Vilajosana Guillen To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=bcaec5215e9db21a7004e82bf973 Subject: [6tsch] rank, Dagrank(rank) and Join Priority X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 19:51:32 -0000 --bcaec5215e9db21a7004e82bf973 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am reviewing the minimal draft and I want to clarify one thing: according to RFC6550 DAGRank(rank) = floor(rank/MinHopRankIncrease) the RFC does not specify whether DAGRank(rank) is a 16bit integer or a 8bit integer (or another type) but if MinHopRankIncrease is 256, then for sure that the result of DAGRank(rank) will be smaller than 256 and hence will fit in an 8bit variable. If that is the case then the join priority field can be exactly DAGRank(rank) and we do not need to do this shifting that we've been discussing so far. Now the minimal draft states that Join Priority == DAGRank(rank) should I clarify there that this assumes that DAGRank(rank) is an 8bit integer. In case it is not an 8bit integer then we need to shift it to consider the most significant 8 bits. Do you agree on that? sorry to come back again to the topic but I want to close it asap :-) X --bcaec5215e9db21a7004e82bf973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Hi,

    I am reviewing the minim= al draft and I want to clarify one thing:

    accordin= g to RFC6550

    DAGRank(rank) =3D floor(rank/MinHopRa= nkIncrease)

    the RFC does not specify whether DAGRank(rank) is a 16b= it integer or a 8bit integer (or another type) but if MinHopRankIncrease is= 256, then for sure that the result of DAGRank(rank) will be smaller than 2= 56 and hence will fit in an 8bit variable.

    If that is the case then the join priority field can be= exactly DAGRank(rank) and we do not need to do this shifting that we'v= e been discussing so far.

    Now the minimal draft st= ates that Join Priority =3D=3D DAGRank(rank)

    should I clarify there that this assumes that DAGRank(r= ank) is an 8bit integer. In case it is not an 8bit integer then we need to = shift it to consider the most significant 8 bits.=A0

    Do you agree on that?=A0

    sorry to come back a= gain to the topic but I want to close it asap :-)
    X
    --bcaec5215e9db21a7004e82bf973-- From pthubert@cisco.com Mon Oct 7 15:25:29 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA9221E8207 for <6tsch@ietfa.amsl.com>; Mon, 7 Oct 2013 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqS4+VGR34oI for <6tsch@ietfa.amsl.com>; Mon, 7 Oct 2013 15:25:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 762B621E8202 for <6tsch@ietf.org>; Mon, 7 Oct 2013 15:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1381184724; x=1382394324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/n2JqfwAEibJ41WDRqCW4cuVPXEEYAnosoU+M0tkD/o=; b=hq48Vs4VEztNBNVYje5fG/Q5/8BJcqS78OUp6c+tiUOlpfpVNtgCdel0 7cQ5zpukaBm6qyi7I8opcpxujb1SPiMm759an046ZDIxDOTwETw2P3OFK ympi9/phYi8kSu92/4DHHGZ5IK0E3+pky7CB0I8g8usargS1dp7vN2r/B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFABY0U1KtJV2a/2dsb2JhbABZDoJ5OIN6vXkXgQcWdIIlAQEBAwEBAQEgEToLBQsCAQYCGgImAgICJQsVEAIEDgWIAAYMjRubXJItBIEpjXUzB4JqgTkDmAGSAIJlPw X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="269206899" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 07 Oct 2013 22:25:17 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r97MPFDU002958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 22:25:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 17:25:15 -0500 From: "Pascal Thubert (pthubert)" To: "" Thread-Topic: [6tsch] rank, Dagrank(rank) and Join Priority Thread-Index: AQHOw5bLQ7tgxIQ9hUuYpowdqQw8KJnp0QOu Date: Mon, 7 Oct 2013 22:25:15 +0000 Message-ID: <16AA9E8A-B91F-40C9-BF6E-83521741653F@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] rank, Dagrank(rank) and Join Priority X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 22:25:29 -0000 SGVsbG8gWGF2aQ0KDQpZZXMgeW91IGNhbiBzYWZlbHkgaW5zaXN0IHRoYXQgdGhlIGZsb29yIGlz IG9uZSBvY3RldCBiZWNhdXNlIHdlIGZvcmNlIG1pbiBpbmNyZWFlIHRvIDI1Niwgbm8gcHJvYmxl bSB0aGVyZSwgaW4gZmFjdCBpdCBpcyBhIGRlc2lnbiBwb2ludCDwn5iKDQoNCkNoZWVycw0KDQpQ YXNjYWwNCg0KPiBMZSA3IG9jdC4gMjAxMyDDoCAyMTo1MiwgIlhhdmllciBWaWxham9zYW5hIEd1 aWxsZW4iIDx4dmlsYWpvc2FuYUBlZWNzLmJlcmtlbGV5LmVkdT4gYSDDqWNyaXQgOg0KPiANCj4g SGksDQo+IA0KPiBJIGFtIHJldmlld2luZyB0aGUgbWluaW1hbCBkcmFmdCBhbmQgSSB3YW50IHRv IGNsYXJpZnkgb25lIHRoaW5nOg0KPiANCj4gYWNjb3JkaW5nIHRvIFJGQzY1NTANCj4gDQo+IERB R1JhbmsocmFuaykgPSBmbG9vcihyYW5rL01pbkhvcFJhbmtJbmNyZWFzZSkNCj4gDQo+IHRoZSBS RkMgZG9lcyBub3Qgc3BlY2lmeSB3aGV0aGVyIERBR1JhbmsocmFuaykgaXMgYSAxNmJpdCBpbnRl Z2VyIG9yIGEgOGJpdCBpbnRlZ2VyIChvciBhbm90aGVyIHR5cGUpIGJ1dCBpZiBNaW5Ib3BSYW5r SW5jcmVhc2UgaXMgMjU2LCB0aGVuIGZvciBzdXJlIHRoYXQgdGhlIHJlc3VsdCBvZiBEQUdSYW5r KHJhbmspIHdpbGwgYmUgc21hbGxlciB0aGFuIDI1NiBhbmQgaGVuY2Ugd2lsbCBmaXQgaW4gYW4g OGJpdCB2YXJpYWJsZS4NCj4gDQo+IElmIHRoYXQgaXMgdGhlIGNhc2UgdGhlbiB0aGUgam9pbiBw cmlvcml0eSBmaWVsZCBjYW4gYmUgZXhhY3RseSBEQUdSYW5rKHJhbmspIGFuZCB3ZSBkbyBub3Qg bmVlZCB0byBkbyB0aGlzIHNoaWZ0aW5nIHRoYXQgd2UndmUgYmVlbiBkaXNjdXNzaW5nIHNvIGZh ci4NCj4gDQo+IE5vdyB0aGUgbWluaW1hbCBkcmFmdCBzdGF0ZXMgdGhhdCBKb2luIFByaW9yaXR5 ID09IERBR1JhbmsocmFuaykNCj4gDQo+IHNob3VsZCBJIGNsYXJpZnkgdGhlcmUgdGhhdCB0aGlz IGFzc3VtZXMgdGhhdCBEQUdSYW5rKHJhbmspIGlzIGFuIDhiaXQgaW50ZWdlci4gSW4gY2FzZSBp dCBpcyBub3QgYW4gOGJpdCBpbnRlZ2VyIHRoZW4gd2UgbmVlZCB0byBzaGlmdCBpdCB0byBjb25z aWRlciB0aGUgbW9zdCBzaWduaWZpY2FudCA4IGJpdHMuIA0KPiANCj4gRG8geW91IGFncmVlIG9u IHRoYXQ/IA0KPiANCj4gc29ycnkgdG8gY29tZSBiYWNrIGFnYWluIHRvIHRoZSB0b3BpYyBidXQg SSB3YW50IHRvIGNsb3NlIGl0IGFzYXAgOi0pDQo+IFgNCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gNnRzY2ggbWFpbGluZyBsaXN0DQo+IDZ0c2No QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRzY2gN Cg==
    All,

    You will find the minut= es of this week's webex below.

    FYI, all the mi= nutes and slides are archived a https://bitbucket.org/6tsch/meetings/.

    Thanks to Xavi and Pascal for taking notes!
    <= br>
    As usual, please fix anything we might have missed directly i= n the e-mail and reply. We will approve and adopt the minutes at the beginn= ing of the next call.

    Thomas

    -----

    Minutes Webex 4 October 2013, 6TiSCH group

    Note: timestamps in PDT.

    Taking notes=A0(using Etherpad)

    1. Xavi Vilajo= sana
    2. Pascal Thube= rt
    3. Thoma= s Watteyne

    Present=A0(alphabetically)

    1. Thomas Watteyne<= /li>
    2. Pascal Thube= rt
    3. Diego= Dujovne
    4. Geraldine Texier
    5. Guillaume Ga= illard
    6. K= en Bannister
    7. Maria Rita Palattella
    8. Nicola Accettura
    9. Patrick Wetterwald
    10. Pouria Zand
    11. Qin Wang
    12. R. Nabati
    13. Raghuram Sudhaakar
    14. Tom Phinney
    15. Xavi Vilajosana

    Recording

    Slides

    Agenda

    • Administrivi= a=A0[3min]
      • Approval agenda
        • <= li style=3D"margin:10px 0px;padding:0px;word-wrap:break-word"> Approval minutes last call
      • IETF88: preliminary agenda
    • minimal draft=A0[5min]<= /em>
      • join priorit= y width
      • = comments/changes
    • update models draft=A0[35min]
      • sum= mary Tuesday discussion
      • proposed ToC
        • separate payload format from = CoAP resource mapping?
      • 6lo thread on monitoring
        • "[6lo] [coma= n] WG Review: IPv6 over Networks of Resource-constrained Nodes (6lo)"<= /li>
        • YANG/NETCONF= vs. SMIv2/SNMP
        • information model in English, turned into YANG?
      • communication paradigms
        • 5-6 communication = paradigms in architecture draft?
        • terminology: interaction model and communication paradigm
      • On-th= e-fly scheduling=A0[15min]
        • overview
        • discussion<= ul style=3D"margin:0px;list-style-type:disc">
        • implementation
        • hysteresis
        • TASA
        • queue size vs. bundle usage
        • bit
        • separating algorithm from mechanism
      • goals and next steps?
    • AOB=A0[2min]

    Minutes

    • [08.04]=A0Meeting starts
    • [08.05]=A0Administrivia
      • Approval = agenda

        No issues raised. = Agenda approved.

      • Approval minutes last call

        No issues raised. = Minutes approved.

      • IETF88: preliminary agenda
        • IETF prelimi= nary agenda has been delayed 1 day. Should appear today at=A0http://www.ietf.org/meeting/88/.
        • Until Monday= to request a change in meeting schedule (hopefully don't need to).
        • Final agend= a published 11 October.
        • Cut-off date= for draft submission (including -00) is 21 October.
    • minimal dr= aft
      • join priorit= y width
        • range of join priority is defined = as=A00x3f
        • answer from = IEEE802.15.4e editor is that=A00x3f=A0might be= an error and the byte is intended to be used as a complete byte.
        • this most pr= obably means that using=A00x00-0xff=A0as the r= ange (rather than=A00x00-0x3f) is OK.
        • [Qin= ]=A0This is good news.
      • comments/changes
        • Thanks to=A0= Xavi=A0for incorporating all the changes!
        • [Xavi]= =A0Will incorporate Maria Rita's comments today.
    • update models draft
        summary Tuesda= y discussion=A0[Raghuram]
      • discuss cont= ents of the data model draft
      • great input (including from Dan Romascanu) on how we c= an be consistent with the terminology to fit a data model as RFC3444 define= s.
      • include:
        • naming convention to URI
        • mapping of URI to 6top resources
        • Message formats
        • Extensible resources
          • profile base= d definition?
          • how do we discover the profile, i.e. what messages will be exchange f= or that discovery methods?
          • custom uri t= o send back messages when event is detected
          • profile based definitions
          • including set of extensible resources e.g. PCE could install a profile that= it needs for its computation
      • Raghuram=A0to pu= sh current version on bitbucket repository today.
      • see=A0https://bitbucket.= org/6tsch/draft-sudhaakar-6tisch-coap
      • Discussion
      • [Xavi]=A0The data model sh= ould be reused. Draft seems to bind it with CoAP. Should be separated for u= se e.g. by RSVP to be described in another draft?
      • [Rag= huram]=A0agreed. But there is limited time.
      • [Pascal]=A0wh= y is the content so tightly bound to CoAP?
      • [Rag= huram]=A0define the data model to be reusable in different transpo= rt.
      • [Pouria]=A0presents 6TiSCH MIB.
      • [Qin= ]=A0Indicate for fields that can be read what observable trigger c= an be used.
      • [Thomas]=A0Are there any fields which can be read for not = observed?
      • 6l= o thread on monitoring
        • [Thomas]=A06lo discusses the proposed charter of 6lo. Related MIB modules, th= ey are looking for a way to monitor the state of a 6lo/6LowPAN network.
        • YANG/NETCONF= vs. SMIv2/SNMP
        • Encourage editors of this draft to follow the 6lo discussion.
        • [Thomas]=A0Clarifying question: NVP vs TLV?
        • [Raghuram]=A0Name Value Pair: human readable ASCII format.
      • communication paradigms=A0[Pascal]
        • ISA100 has 3 comm paradigms.
          • client/serve= r
          • pub/su= b
          • source= /sink
        • ab= stract concept.
          • [Tom]=A0b= ased on IEC61158
        • we= have similar approach, but more options
          • p= oint to point model (CoAP REST model)
          • At L3, multi= hop along track (RSVP-like)
          • At l2, single hop (6top)
        • Mapping of comm paradigm to protocol:
          • [Thomas]=A0why SNMP?
          • [Pascal]=A0way to implement Client/server. Just examples o= f protocols that can be used to implement the communication paradigms.
            • =
        • wh= at document is the right place:
          • informationa= l model: high level overview.
          • data model: YANG seems the direction to define the da= ta model.
          • implement th= e data model in different data formats (CBOR, NVP, TLV, etc.)
          • data and command do n= ot need to be tightly bound.
        • [Raghuram]=A0in terms of CoAP cannot separate payload than U= RI and method, so the implementation is tight to the communication model.
        • [Tho= mas]=A0do not see source/sink model as needed per-see. CoAP provid= es the observe and notifications.
        • [Tom]=A0Source/sink is a application communication paradig= m and there is no reason that it needs to be modelled that way in the commu= nication layers. Most people end up with wireless running alerts to a singl= e device (e.g. gateway, BBR). n-to-1 at the low layers. Source/sink applies= to the application, and how you model it in the lower layers is really the= responsibility of the implementers.
    • [08.56]=A0on-the-fly scheduling
      • overview=A0[Diego]
        • Idea i= s to adapt the number of cells according to the traffic constrains (queue s= ize, etc.) on the fly.
        • This is a di= stributed approach.
      • discussion
        • implementati= on
          • run on top of 6top
          • define statistics and interface, algorithm is independent
          • hysteresis
          • map queue sizes to link requirements.
          • reaction time to avoid hysteresis
          • handle collisions w= ith other neighbors scheduling same cell (not a global picture)
        • TA= SA
          • Distributed TASA?
        • IPR Cisco:
          • [Diego]=A0what= is covered?
          • [Pascal]=A0Ciscp IPR does not matter as it covers many asp= ects, also in RPL.
          • [Pascal]=A0Mentioning the IPR is mandatory, men= tioned it in ML for that reason.
      • goals and next steps?
          =
        • [Tho= mas]=A0Good exercise to detect missing aspects on 6top as it is a = use case on top of 6top.
        • [Die= go]=A0Yes, will do.
    • [09.07]=A0AOB

      No other business = raised.

    • [09.08]=A0Meeting ends
    --e89a8f923c641f359904e7ee22a9-- From xvilajosana@berkeley.edu Fri Oct 4 11:58:33 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4251D21F9DB4 for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pk1cdtf76Mf for <6tsch@ietfa.amsl.com>; Fri, 4 Oct 2013 11:58:28 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2B79B21F9A37 for <6tsch@ietf.org>; Fri, 4 Oct 2013 11:58:16 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so4567807pad.0 for <6tsch@ietf.org>; Fri, 04 Oct 2013 11:58:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8rzHKq+viOtKVDvDxvGTJ/ZXmi1TFVfbMxC8T0sfTKU=; b=gSGLwwMqyOY6AwBnd+F5RAkpnVNfA6SgMdiAQWrJ3Ux6+jSjhRDuyUhNp5SVV/6bLG uk3OPMfrv1VMhXq94qeAsFJTOQxOfWmdgYE05dODDAGGc3+sFr/LBQ/j18T3rWnWXJtu 6bQUS6nBya3ulv6ZorLgj1ZXGMkTj74r2vNBsZxEgc9HGloo1QcVkozpaij3hbGwxdQo wvD6ATxD+g4onN01r+6Z5toFrQxVaesDD0i5wy3q7rksYlKks2NaiXy1QXpha8xApx4N Wzzuz7FUpXYo1gTfGKkpFlDuZDLmDTntNaGk9wdvNYhnToNTPLH5NC4sl7vzLz4xMePt CYYg== X-Gm-Message-State: ALoCoQmRDLnIbCml2T2nKGDXnxDNUaRqGe4E/hQ5kYJeYIOaCINxXsDfn3I/qVmS6g3K1dADk2lc MIME-Version: 1.0 X-Received: by 10.68.244.130 with SMTP id xg2mr16231948pbc.13.1380913095219; Fri, 04 Oct 2013 11:58:15 -0700 (PDT) Received: by 10.70.34.44 with HTTP; Fri, 4 Oct 2013 11:58:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 11:58:15 -0700 Message-ID: From: Xavier Vilajosana Guillen To: Maria Rita PALATTELLA Content-Type: multipart/alternative; boundary=047d7b2e3d9e81aa1304e7eee24c Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] renaming of minimal draft repository X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xvilajosana@eecs.berkeley.edu List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:58:33 -0000 --047d7b2e3d9e81aa1304e7eee24c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Maria Rita, thanks so much. I already addressed your comments. I will wait until next week in order to see if I get any more comments. If not I will proceed to publish the new version of the draft. regards, Xavi On Fri, Oct 4, 2013 at 12:52 AM, Maria Rita PALATTELLA < maria-rita.palattella@uni.lu> wrote: > Hello Xavi,**** > > I have gone through the draft, and I have **really minor** comments (most > of the points were already fixed by Thomas=92 review).**** > > Sorry for not having provided my feedback before.**** > > ** ** > > *Typos:* Timming -> timing (there is an *extra m*)**** > > In the terminology draft and lln-tsch draft, please replace > Palattella M., with Palattella M.*R.* > > ** ** > > *Comment1:* we have renamed the draft *Minimal 6TSCH configuration*, but > you still have *6tsch-basic* as short title in the draft header, and you > referee to *basic schedule* within the draft (there are several > occurrences). **** > > Shouldn=92t we talk of *Minimal schedule*, in order to be coherent? **** > > It is just a thought=85**** > > ** ** > > *Comment2:* I agree with Thomas that we have to specify clearly that > empty slots (from 6 to 100) can be scheduled dynamically if needed. > Otherwise, we cannot use this minimal configuration for running distribut= ed > algorithms, like the =93on the fly scheduling=94 one.**** > > ** ** > > Maria Rita**** > > ** ** > > ** ** > > ** ** > > *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf > Of *Xavier Vilajosana Guillen > *Sent:* Tuesday, October 01, 2013 11:51 PM > *To:* 6tsch@ietf.org > *Subject:* [6tsch] renaming of minimal draft repository**** > > ** ** > > Hello,**** > > I renamed the minimal draft repository at bitbucket > (draft-vilajosana-6tisch-minimal). Please use the new URL from now on. > > https://bitbucket.org/6tsch/draft-vilajosana-6tisch-minimal/wiki/Home**** > > I also addressed Thomas comments.**** > > thanks! > Xavi**** > > ** ** > --047d7b2e3d9e81aa1304e7eee24c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Hi Maria Rita, thanks so much. I already address= ed your comments.

    I will wait until next week in order to see= if I get any more comments. If not I will proceed to publish the new versi= on of the draft.

    regards,
    Xavi


    On Fri, Oct 4, 2013 at 12:52 AM, Maria Rita PALATTEL= LA <maria-rita.palattella@uni.lu> wrote:

    Hello Xavi,=

    I have gone through the d= raft, and I have *really minor* comments (most of the points were al= ready fixed by Thomas=92 review).

    Sorry for not having prov= ided my feedback before.

    =A0<= /p>

    Typos: Timming -> timing (there is an extra m)

    =A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0In the terminology draft and lln-tsch draft, please replace= Palattella M., with Palattella M.R.

    =A0<= /p>

    Comment1: we have renamed the draft Minimal 6TSCH configuration, but you still have 6tsch-basic a= s short title in the draft header, and you referee to basic schedule within the draft (there are several occurrences). =

    Shouldn=92t we talk of Minimal schedule, in order to be coherent?

    It is just a thought=85

    =A0<= /p>

    Comment2: I agree with Thomas that we have to specify clear= ly that empty slots (from 6 to 100) can be scheduled dynamically if needed. O= therwise, we cannot use this minimal configuration for running distributed = algorithms, like the =93on the fly scheduling=94 one.<= /p>

    =A0<= /p>

    Maria Rita<= /span>

    =A0<= /p>

    =A0<= /p>

    =A0<= /p>

    From: 6tsch-bounces@ietf.org= [mailto:6t= sch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
    Sent: Tuesday, October 01, 2013 11:51 PM
    To: 6tsch@ietf.o= rg
    Subject: [6tsch] renaming of minimal draft repository<= /span>

    =A0

    Hello,<= /p>

    I renamed the minimal= draft repository at bitbucket (draft-vilajosana-6tisch-minimal). Please us= e the new URL from now on.

    https://bitbucket.org/6tsch/draft-vilajosana-6tisc= h-minimal/wiki/Home

    I also addressed Thom= as comments.

    thanks!
    Xavi

    =A0