Pascal, all,
The SF is part of 6top.
"May be" is more appropriate.
My 2c

On Tuesday, June 7, 2016, Pascal Thubert (pthubert) <[email protected]>
wrote:

> Fine with me Qin
>
>
>
> Or we could just say “service” and elide the repetition of the term
> “logic”?
>
>
>
> Pascal
>
>
>
> *From:* Qin Wang [mailto:[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>]
> *Sent:* lundi 6 juin 2016 22:54
> *To:* Pascal Thubert (pthubert) <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>; Xavier Vilajosana <
> [email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>; Thomas
> Watteyne <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>
> *Cc:* [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>
> *Subject:* Re: [6tisch] proposed text to describe SF and 6P in archie
>
>
>
> Hi Pascal
>
>
>
> In the paragraph
>
> "The SF may be seen as divided between an upper bandwidth adaptation
>
>    logic that is not aware of the particular technology that is used to
>
>    obtain and release bandwidth, and an underlying service sublayer that
>
>    maps those needs in the actual technology, which means mapping the
>
>    bandwidth onto cells in the case of TSCH."
>
>
>
> You use two different term to expression the sub-modules of SF, i.e.
> "logic" and "sublayer". I propose to consistently use one. I prefer
> "logic".  Then, the new text will be:
>
>
>
> "The SF may be seen as divided between an upper bandwidth adaptation
>
>    logic that is not aware of the particular technology that is used to
>
>    obtain and release bandwidth, and an underlying service *logic* that
>
>    maps those needs in the actual technology, which means mapping the
>
>    bandwidth onto cells in the case of TSCH."
>
>
>
> what do you think?
>
>
>
> Thanks
>
> Qin
>
>
>
> On Monday, June 6, 2016 12:04 PM, Pascal Thubert (pthubert) <
> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>
> wrote:
>
>
>
> Hello Xavi:
>
>
>
> Not sure what you want me to add?
>
> At the moment the text reads:
>
>
>
> “
>
>
>
> 4.2.2.  Scheduling Functions and the 6P protocol
>
>
>
>    In the case of soft cells, the cell management entity that controls
>
>    the dynamic attribution of cells to adapt to the dynamics of variable
>
>    rate flows is called a Scheduling Function (SF).  There may be
>
>    multiple SFs with more or less aggressive reaction to the dynamics of
>
>    the network.  The 6TiSCH 6top Scheduling Function Zero (SF0)
>
>    [I-D.ietf-6tisch-6top-sf0] provides a simple scheduling function that
>
>    can be used by default by devices that support dynamic scheduling of
>
>    soft cells.
>
>
>
>    The SF may be seen as divided between an upper bandwidth adaptation
>
>    logic that is not aware of the particular technology that is used to
>
>    obtain and release bandwidth, and an underlying service sublayer that
>
>    maps those needs in the actual technology, which means mapping the
>
>    bandwidth onto cells in the case of TSCH.
>
>
>
>     +------------------------+          +------------------------+
>
>     |  Scheduling Function   |          |  Scheduling Function   |
>
>     |  Bandwidth adaptation  |          |  Bandwidth adaptation  |
>
>     +------------------------+          +------------------------+
>
>     |  Scheduling Function   |          |  Scheduling Function   |
>
>     | TSCH mapping to cells  |          | TSCH mapping to cells  |
>
>     +------------------------+          +------------------------+
>
>     | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
>
>     +------------------------+          +------------------------+
>
>
>
>
>
>                        Figure 6: SF/6P stack in 6top
>
>
>
>    The SF relies on 6top services that implement the 6top Protocol (6P)
>
>    [I-D.ietf-6tisch-6top-protocol] to negotiate the precise cells that
>
>    will be allocated or freed based on the schedules of the peer.  It
>
>    may be for instance that a peer wants to use a particular time slot
>
>    that is free in its schedule, but that timeslot is already in use by
>
>    the other peer for a communication with a third party on a different
>
>    cell.  The 6P protocol enables the peers to find an agreement in a
>
>    transactional manner that ensures the final consistency of the nodes
>
>    state.
>
>
>
> “
>
>
>
> In fact, I realize I’m not 100% clear what whether people think that SF
> belongs to 6top or sits over it as a service user.
>
> Part of the confusion is the name of the SF0 draft “6TiSCH 6top Scheduling
> Function Zero (SF0)” which tends to indicate that it is part of it.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* [email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');> [
> mailto:[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* samedi 4 juin 2016 06:26
> *To:* Thomas Watteyne <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>
> *Cc:* Pascal Thubert (pthubert) <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>; [email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>
> *Subject:* Re: [6tisch] proposed text to describe SF and 6P in archie
>
>
>
> Hi Pascal, Thomas, all
>
>
>
> inline too (see changes in *foo*)
>
>
>
> regards,
>
> X
>
> 2016-06-03 20:41 GMT+02:00 Thomas Watteyne <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>>:
>
> Pascal,
>
>
>
> Some typos and suggestions below.
>
>
>
> 4.2.2.  Scheduling Functions and the 6P Protocol (6P)
>
>
>
>    In the case of soft cells, the cell management entity that controls
>
>    the dynamic attribution of cells to adapt to *varying*
>
>    rate flows *in the network* is called Scheduling Function (SF).  There
> may be
>
>    multiple SFs, each implementing a different policy to adapt to varying
>
>    network traffic.  The 6TiSCH 6top Scheduling Function Zero (SF0)
>
>    [I-D.ietf-6tisch-6top-sf0] provides a simple scheduling function that
>
>    can be used by default by devices that support dynamic scheduling of
>
>    soft cells.
>
>
>
>    The SF is logically divided in a bandwidth adaptation policy
>
>    which is *independent* to the particular *mechanism* used to obtain and
>
>    release bandwidth,
>
> TW> I don't understand the previous sentence
>
>    and a underlying service sublayer which identifies
>
>     XV> Only identifies? For me we need to stress the difference between
> 6top protocol and this sublayer
>
>  the
>
>    appropriate TSCH cells to use.
>
>
>
>     +------------------------+          +------------------------+
>
>     |  Scheduling Function   |          |  Scheduling Function   |
>
>     |  Bandwidth adaptation  |          |  Bandwidth adaptation  |
>
>     +------------------------+          +------------------------+
>
>     |  Scheduling Function   |          |  Scheduling Function   |
>
>     |   TSCH cell mapping    |          |   TSCH cell mapping    |
>
>     +------------------------+          +------------------------+
>
>     | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
>
>     +------------------------+          +------------------------+
>
>
>
>
>
>                        Figure 6: SF/6P stack in 6top
>
>
>
>    The SF relies on the 6top Protocol (6P)
>
>    [I-D.ietf-6tisch-6top-protocol] to negotiate the cells between
>
>    neighbor nodes.  It
>
>    may be for instance that a node wants to use a particular time slot
>
>    that is free in its schedule, but which is already in use by
>
>    its neighbor.  The 6P protocol enables the neighbor nodes to find
>
>    an agreement on which cells to use.
>
>
>
>
> On Friday, June 3, 2016, Pascal Thubert (pthubert) <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>
> Dear all:
>
> As discussed at the last Interim, please find proposed text in the 6TiSCH
> architecture below.
>
> What do you think?
>
> Pascal
>
> 4.2.2.  Scheduling Functions and the 6P protocol
>
>    In the case of soft cells, the cell management entity that controls
>    the dynamic attribution of cells to adapt to the dynamics of variable
>    rate flows is called a Scheduling Function (SF).  There may be
>    multiple SFs with more or less aggressive reaction to the dynamics of
>    the network.  The 6TiSCH 6top Scheduling Function Zero (SF0)
>    [I-D.ietf-6tisch-6top-sf0] provides a simple scheduling function that
>    can be used by default by devices that support dynamic scheduling of
>    soft cells.
>
>    The SF is logically divided in an abstract bandwidth adaptation logic
>    that is abstract to the particular technology used to obtain and
>    release bandwidth, and a underlying service sublayer that maps those
>    needs in the actual technology, which means identifying the
>    appropriate cells in the context of TSCH.
>
>     +------------------------+          +------------------------+
>     |  Scheduling Function   |          |  Scheduling Function   |
>     |  Bandwidth adaptation  |          |  Bandwidth adaptation  |
>     +------------------------+          +------------------------+
>     |  Scheduling Function   |          |  Scheduling Function   |
>     | TSCH mapping to cells  |          | TSCH mapping to cells  |
>     +------------------------+          +------------------------+
>     | 6top cells negotiation | <- 6P -> | 6top cells negotiation |
>     +------------------------+          +------------------------+
>
>
>                        Figure 6: SF/6P stack in 6top
>
>    The SF relies on 6top services that implement the 6top Protocol (6P)
>    [I-D.ietf-6tisch-6top-protocol] to negotiate the precise cells that
>    will be allocated or freed based on the schedules of the peer.  It
>    may be for instance that a peer wants to use a particular time slot
>    that is free in its schedule, but that timeslot is already in use by
>    the other peer for a communication with a third party on a different
>    cell.  The 6P protocol enables the peers to find an agreement in a
>    transactional manner that ensures the final consistency of the nodes
>    state.
>
> _______________________________________________
> 6tisch mailing list
> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --
>
> _______________________________________
>
>
>
> Thomas Watteyne, PhD
>
> Research Scientist & Innovator, Inria
>
> Sr Networking Design Eng, Linear Tech
>
> Founder & co-lead, UC Berkeley OpenWSN
>
> Co-chair, IETF 6TiSCH
>
>
>
> www.thomaswatteyne.com
>
> _______________________________________
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>


-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to