Re: [6tisch] new term: 6top "Scheduling Function"

[Wang, Chonggang]

Agree too.

Chonggang

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: Monday, October 12, 2015 2:04 PM
To: Xavier Vilajosana 
Cc: Thomas Watteyne ; 6tisch@ietf.org
Subject: Re: [6tisch] new term: 6top "Scheduling Function"

Dear all,
  I agree on the term "Scheduling Function"
Regards,
 Diego Dujovne

2015-10-12 13:24 GMT-03:00 Xavier Vilajosana 
mailto:xvilajos...@eecs.berkeley.edu>>:
Hello,

I support the term Scheduling Function (SF) and once we reach consensus I will 
update the draft.

regards,
Xavi

2015-10-12 13:41 GMT+02:00 Thomas Watteyne 
mailto:watte...@eecs.berkeley.edu>>:
All,

At the call on Friday, some of your indicated that the term "6top Objective 
Function" (6OF) introduced in 
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 is too close to 
RPL's OF, and might lead to confusion.

During the call, we agreed on the term "Scheduling Function" (SF).

I hence ask the authors of 
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 to change the 
term. Please raise further comments about this terminology in the next 24h.

Thomas

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-wang-6tisch-6top-sublayer-02: call for reviews

[Wang, Chonggang]

Hi Thomas,

Just a head-up. I will volunteer to review this draft and post feedback to the 
group sometime this week.

Thanks,
Chonggang

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Thomas Watteyne
Sent: Monday, October 12, 2015 6:23 PM
To: 6tisch@ietf.org
Subject: [6tisch] draft-wang-6tisch-6top-sublayer-02: call for reviews

All,

https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 was publshed a 
couple of days ago and was actively presented/discussed during the 6TiSCH 
interim meeting on 9 Oct. Since it will likely be presented as well in 
Yokohama, we are calling for reviews.

Please read the draft and post comments to the ML. Authors, please capture 
suggestions in the issue tracker at 
https://bitbucket.org/6tisch/draft-wang-6tisch-6top-sublayer/wiki/Home.

Thomas
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] ChongGang's point on item 3 to specify P2P operations

[Wang, Chonggang]

I share the same question as Qin raised below.

Chonggang

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Qin Wang
Sent: Friday, October 09, 2015 3:42 PM
To: Pascal Thubert (pthubert) ; 6tisch@ietf.org
Subject: Re: [6tisch] ChongGang's point on item 3 to specify P2P operations

Hi Pascal,

Can you explain more about "with the capability
for IoT routers to appropriate chunks of the Time/frequency matrix without
starving, or interfering with, other 6TiSCH nodes."?

Thanks
Qin


On Friday, October 9, 2015 11:57 AM, Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:

Dear all :

ChongGang pointed out that the charter text for item 3 (OTF) was not specific 
that we address L2 peer operation, not and end to end reservation ala RSVP.

I modified item 3 again as follwos:


3. Produce an “On-the-fly" (OTF) specification to enable a distributed dynamic
scheduling of time slots, negotiated between adjacent peers, with the capability
for IoT routers to appropriate chunks of the Time/frequency matrix without
starving, or interfering with, other 6TiSCH nodes.
This particular work will focus on IP traffic since the work on tracks is not
yet advanced enough to specify their requirements for OTF operations.

What do you think?

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] OTF: IP or not IP?

[Wang, Chonggang]

Hi Pascal,

"This particular work will focus on IP traffic since the work on tracks is not
yet advanced enough to specify their requirements for OTF operations.
"
It seems we still limit OTF to IP traffic. My previous concern still holds and 
I tend to disagree with the sentence above from charter2.0 description for the 
following reasons:

* First, in 6tisch architecture draft, it is mentioned that a track can 
be built on soft cells.

* Second, if OTF is limited to IP traffic, OTF appears to me a purely 
layer-3 (or IP layer) mechanism. Then, why 6TiSCH WG handles IP-layer-only 
mechanism? Should it be beyond the scope of 6TiSCH WG?

* Third, Charter2.0 implies some work to be done and/or 
work-in-progress. I feel whether we can use "this work is not fully done" as a 
reason to exclude it from the charter 2.0.

Just my 2 cents.

Thanks,
Chonggang

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Pascal Thubert 
(pthubert)
Sent: Friday, October 09, 2015 11:49 AM
To: 6tisch@ietf.org
Subject: [6tisch] OTF: IP or not IP?

Dear all:

Following up on the comments at the interim, My suggestion is to update item 3 
as follows:


3. Produce an "On-the-fly" (OTF) specification to enable a distributed dynamic
scheduling of time slots with the capability for IoT routers to appropriate
chunks of the matrix without starving, or interfering with, other 6TiSCH nodes.
This particular work will focus on IP traffic since the work on tracks is not
yet advanced enough to specify their requirements for OTF operations.

I remove the 'for IP traffic' within the main text to indicate that the initial 
focus is
N IP traffic but I hope that now it is more clear that future work on tracks is 
not precluded.
Does that address the comment?

Cheers,

Pascal

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

[Abhijan Bhattacharyya]

Hi Rafa,
The application layer driven approach is really interesting in the 
constrained environment context. We had a similar approach for secure 
session establishment (assuming that boot-strapping is already done) which 
performs the session establishment in CoAP but uses the DTLS encryption 
and header-structure for secure exchange of the application-layer message. 
Coincidentally we have also defined an option called "Auth" .

Here is the link to the draft: 
https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00 (Had 
an older work in progress: 
https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. 
But this one did not provide channel security).
I submitted this draft to dice, however, dice was not really the place to 
discuss this. Our draft is due to expire in about 4 days.



Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattachar...@tcs.com
Website: http://www.tcs.com

Experience certainty.   IT Services
Business Solutions
Consulting



"Ace"  wrote on 10/13/2015 12:11:46 AM:

> From: Rafa Marin Lopez 
> To: Alexander Pelov 
> Cc: 6tisch@ietf.org, Dan Garcia , Rafa Marin Lopez
> , a...@ietf.org
> Date: 10/13/2015 12:16 AM
> Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> Sent by: "Ace" 
> 
> Dear Alexander:
> 
> Thanks for your comments 
> 
> > El 8 oct 2015, a las 10:53, Alexander Pelov  escribió:
> > 
> > Dear Rafa,
> > 
> > I've been reading the latest version of your draft ( draft-marin-
> ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding
> some of the payload options, which could be optimized even further:
> > 
> > 1) Use shorter name for the /auth resource
> > 2) Mandate the use of zero-length CoAP token
> > 
> > The first, and the more simple one, is - would it be possible to 
> change the name of the authentication resource from /auth to a 
> shorter one (like /a)? Maybe it could be an option to change the 
> name of this resource, based on the underlaying architecture, e.g. 
> an RFC could mandate that in a specific network the resource could 
> be named /a, whereas the default value could remain /auth?
> 
> [Rafa] I do not see any problem to shorten the resource name.
> 
> > 
> > The second, which is a little bit more subtle. Tokens are used to 
> match responses to requests, but during the authentication/
> authorization phase a single peer (endpoint) would communicate with 
> a single authenticator. Moreover, the communication happens in a 
> serial fashion, and responses are piggybacked. This falls in the 
> case when zero-length token is also advised by RFC7252. Do you think
> that it would be appropriate to make the use of zero-length token 
> mandatory for EAP-over-CoAP?
> 
> [Rafa] I guess you are referring to this text: 
> 
> "An empty token value is appropriate e.g., when
>no other tokens are in use to a destination, "or when requests are
>made serially per destination and receive piggybacked responses.”
> 
> I would say that using zero-length token is possible. What I am not 
> sure is whether make it mandatory or not. I mean we could say that 
> if the client sends a zero-length token the server can consider it 
> OK as per the text above. If there is a non-zero length token value 
> should be also fine.
> 
> What do you think?
> 
> Best Regards.
> 
> > 
> > Best,
> > Alexander
> > 
> > ___
> > Ace mailing list
> > a...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
> 
> ---
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
> ---
> 
> 
> 
> 
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] minute ad-hoc meeting SF0, 13 October 2015

[Thomas Watteyne]

In an effort to prepare the re-factoring of
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into what
will become the SF0, we had an ad-hoc meeting with the authors of that
draft.

Minutes below.

Thomas




Minutes, 13 October 2015, ad-hoc meeting SF0

Note: times in CET

NO recording was made, since this is an ad-hoc (no WG interim) meeting.
Present

   - Diego Dujovne
   - Nicola Accettura
   - Alfredo Grieco
   - Maria Rita Palattella
   - Thomas Watteyne

action items

   - *Diego* to rename repo, create skeleton of SF0 document, and assign
   tasks
   - *Nicola* to write down exact formula for calculating the timeout
   - *Nicola* and *Thomas* to be available to write parts of the document
   - *Maria Rita* and *Alfredo* to proof-read documents before publication

goal

discuss how to re-factor
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into the SF0
draft, so fits nicely on top of
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02
minutes

   - meeting starts at 11.00 AM
   - Intro
  - *Thomas* details the idea of 6P+SF0
  - *Maria Rita*: Define mechanism to select the cell. Give basic rule
  on how to pick the cell. For example, how to pick the cells. We were
  relying on the monitoring already there, but now it should be done by the
  SF0.
  - *Thomas* agreed. Cells could be selected randomly. We need to align
  the two drafts. Look at what is written in the sublayer draft. Sec. 4.2
  lists what a SF must do.
  - *Maria Rita*: what is the timeout?
  - *Thomas* timeout value depends on the RTT between neighbors. We can
  put a high value, nevertheless the scheduler function knows the cells
  already with the neighbor, so it may calculate a timeout value.
  - *Maria Rita*: what is the container field?
  - *Thomas* allows us to use multiple SFs on the same node, and use
  them on different slotframes/chunks.
  - *Maria Rita*: what is a cell identified with?
  - *Thomas* 4-byte cell identifier. Container generic. e.g. always
  from container 0, or the container is a set of flags, or the
container can
  be the chunk number.
  - *Nicola* The cell selection a request a block of cells, so the
  receiver can choose the channel offset. Maybe identified by
boundaries (set
  of cells) for allocating one or more cells. Indicate many: the
whole block
  offset can be allocated, but also the channel offset.
  - *Thomas* great idea, but maybe more an extension for the simple
  mechanism, with cell boundaries. We can evolve to a new version.
So we can
  say that two cells can mean the beginning and the end.
  - *Nicola* both must understand the same meaning on both ends. If a
  bigger set of cells is proposed, there is a higher chance to have a
  successful allocation. All the available cells on the transmitter side.
  - *Thomas* agreed that in that case it's more efficient to encode it
  as a range rather than a list of discrete cells. But maintains
that this is
  an optimization for cases where the schedule is very dense
  - *Nicola* agrees that better for other scheduling functions apart
  from SF0. Even just saying the channel offset. Slot offset may generate
  more conflicts than channel offset.
  - *Thomas* We are not aiming to put the complete list of cells. Not
  exhaustive. If the first don't work, try others. We are talking of the
  probability to choose from the ones proposed, which is very high, given
  that schedule is mostly empty. Some optimizations can be proposed in case
  the schedule is filled. What you describe is a more efficient way of
  describing a range of cells. This can be described using by using what is
  specified on 3.1.5 of the sublayer draft.
   - Go over the requirements for an SF in
   https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02#section-4.2
  - MUST specify an identifier for that 6OF.
 - IANA_SF0_ID. In IANA Consideration section, ask IANA to allocate
 a number. We recommend "0".
  - MUST specify a set of rules for a node to decide when to add one or
  more cells to a neighbor.
 - contents of
 
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-2
  and
 
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-7
  combined
 - *Maria Rita* we can distinguish 2 phases:
- estimation (section 7)
- based on estimation, comparison and decide to ADD/DELETE
(section 2)
 - *Nicola*: issue: exchange add/remove cells
 - *Thomas* creates an issue on the OTF issue tracker.
  - MUST specify a set of rules for a node to decide when to delete one
  or more cells to a neighbor.
 - same as above
  - MUST specify a value for the timeout, or a rule to calculate it.
 - *Nicola* desc

Re: [6tisch] new term: 6top "Scheduling Function"

[Maria Rita PALATTELLA]

It works for me too.
Thanks!
Maria Rita

-Original Message-
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Alfredo Grieco
Sent: Tuesday, October 13, 2015 7:18 AM
To: 6tisch@ietf.org
Subject: Re: [6tisch] new term: 6top "Scheduling Function"

Dear all,

I agree too.

Alfredo
> Il giorno 13/ott/2015, alle ore 06:44, S.V.R.Anand  
> ha scritto:
> 
> Dear All,
> 
> The term "Scheduling Function" is fine with me too! 
> 
> It might be slightly hiding the intent though :) But that is fine.
> 
> Anand
> 
> 
> On Monday 12 October 2015 11:34 PM, Prof. Diego Dujovne wrote:
> > Dear all,
> 
>   >   I agree on the term "Scheduling Function"
> 
> 
>   > Regards,
> 
> 
>   >
> 
> 
>   >  Diego Dujovne
> 
> 
>   >
> 
> 
>   > 2015-10-12 13:24 GMT-03:00 Xavier Vilajosana
>   
> :
> 
>   >
> 
> 
>   > Hello,
> 
> 
>   >
> 
> 
>   > I support the term Scheduling Function (SF) and once we
>   reach consensus I will update the draft.
> 
> 
>   >
> 
> 
>   > regards,
> 
> 
>   > Xavi
> 
> 
>   >
> 
> 
>   > 2015-10-12 13:41 GMT+02:00 Thomas Watteyne
>   
> :
> 
>   >
> 
> 
>   > All,
> 
> 
>   >
> 
> 
>   > At the call on Friday, some of your indicated that
>   the term "6top Objective Function" (6OF) introduced in
>   
> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02
>  is
>   too close to RPL's OF, and might lead to confusion.
> 
> 
>   >
> 
> 
>   > During the call, we agreed on the term "Scheduling
>   Function" (SF).
> 
> 
>   >
> 
> 
>   > I hence ask the authors of
>   
> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02
>  to
>   change the term. Please raise further comments about this
>   terminology in the next 24h.
> 
> 
>   >
> 
> 
>   > Thomas
> 
> 
>   >
> 
> 
>   > ___
> 
> 
>   > 6tisch mailing list
> 
> 
>   > 
> 6tisch@ietf.org
> 
>   > 
> https://www.ietf.org/mailman/listinfo/6tisch
> 
>   >
> 
> 
>   >
> 
> 
>   >
> 
> 
>   > ___
> 
> 
>   > 6tisch mailing list
> 
> 
>   > 
> 6tisch@ietf.org
> 
>   > 
> https://www.ietf.org/mailman/listinfo/6tisch
> 
>   >
> 
> 
>   >
> 
> 
>   >
> 
> 
>   >
> 
> 
>   > --
> 
> 
>   > DIEGO DUJOVNE
> 
> 
>   > Académico Escuela de Ingeniería en Informática y
>   Telecomunicaciones
> 
> 
>   > Facultad de Ingeniería UDP
> 
> 
>   >
> www.ingenieria.udp.cl
> 
>   > (56 2) 676 8125
> 
> 
>   >
> 
> 
>   > --
> 
> 
>   > This message has been scanned for viruses and
> 
> 
>   > dangerous content by MailScanner, and is
> 
> 
>   > believed to be clean.
> 
> 
>   >
> 
> 
>   > ___
> 
> 
>   > 6tisch mailing list
> 
> 
>   >
> 6tisch@ietf.org
> 
>   >
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean. 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

--
Luigi Alfredo Grieco, PhD
Associate Professor
Dep. of Electrical and Information Engineering (DEI) Politecnico di Bari Via 
Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: alfredo.gri...@poliba.it
linkedin: it.linkedin.com/in/alfredogrieco

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch