Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

From: Qin Wang <[email-masked]>
Date: Wed, 1 Jul 2015 15:28:25 +0000 (UTC)

Hi Michel and Nicola,
I think Michel's idea is interesting. But, according to my understanding, the Frame Pending setting just means there is frame following, does not mean that the current bandwidth provided by TSCH schedule, including hard cells and soft cells, is not enough to convey those frames, and then needs more bandwidth (e.g. additional soft cells) . Right? Do I miss something?
ThanksQin 

     On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura <[email-masked]> wrote:

 Hi Michel,

your proposal is very interesting. 

However, OTF does not allocate cells directly: it just computes the estimated number of cells to add or delete into the schedule, and then sends this information to 6top. 6top is then in charge of negotiating cells among neighbors, and meybe perform the scheme you are proposing.

So, your proposal seems fitting more the 6top-to-6top communication.

Am I missing something? What others think about?

Sincerely
Nicola

2015-06-30 8:13 GMT-07:00 Michel Veillette <[email-masked]>:

Hi Diego It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not completely done yet) and I wandering if the concept of on the fly, in a single exchange, temporary allocation of a soft cell have already been discussed. For example, a node can use the Frame Pending subfield (IEEE 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready to be transmitted. Based on that knowledge, the target may add an IE in an enhanced acknowledgment to allocate a temporary soft cell (e.g. single cell). Each subsequent transmission may further re-allocate a temporary soft cell. It’s important to note that the default delay for a TSCH Acknowledgment is 1ms (macTsTxAckDelay) which seem sufficient for the processing of this new IE.  This scheme is very reactive and may help dealing with non-predictable communication patterns.What do you things? 
|  | Michel Veillette
System Architecture DirectorTrilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]    |

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

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

---

From: Michel Veillette <[email-masked]>
Date: Wed, 1 Jul 2015 17:09:47 +0000

Hi Qin

Yes, the Frame Pending flag is defined as follow:

IEEE 802.15.4-2006 section 7.2.1.1.3
“Frame Pending subfield is 1 bit in length and shall be set to one if the device sending the frame has more data for the recipient. This subfield shall be set to zero otherwise”

This feature can be especially useful for the upstream traffic in a RPL DODAG. In a scenario where a DAG parent have dozens of children, dedicated timeslot will be infrequent and share timeslots suffer from contention. If a subset of these children have ongoing traffic, the parent can use the Frame Pending flag information to schedule temporary soft cells and avoid contention or speedup transfer.

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com/>

From: Qin Wang [mailto:[email-masked]]
Sent: 1 juillet 2015 11:28
To: Nicola Accettura; Michel Veillette
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Michel and Nicola,

Thanks
Qin

On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura <[email-masked]<mailto:[email-masked]>> wrote:

Hi Michel,

2015-06-30 8:13 GMT-07:00 Michel Veillette <[email-masked]<mailto:[email-masked]>>:
Hi Diego

It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not completely done yet) and I wandering if the concept of on the fly, in a single exchange, temporary allocation of a soft cell have already been discussed. For example, a node can use the Frame Pending subfield (IEEE 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready to be transmitted. Based on that knowledge, the target may add an IE in an enhanced acknowledgment to allocate a temporary soft cell (e.g. single cell). Each subsequent transmission may further re-allocate a temporary soft cell. It’s important to note that the default delay for a TSCH Acknowledgment is 1ms (macTsTxAckDelay) which seem sufficient for the processing of this new IE.

This scheme is very reactive and may help dealing with non-predictable communication patterns.
What do you things?

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com/>

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

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

---

From: Nicola Accettura <[email-masked]>
Date: Wed, 1 Jul 2015 11:05:52 -0700

Qin,
you are pointing out that the bandwidth must be already provided if one
wants to use the Frame Pending setting. This is what we have discussed in
the past and is the state of the art in 6tisch.

Michele is proposing to use the Frame Pending jointly with a temporary cell
reservation in the ACK.

I guess this is not in the scope of OTF, but, in case, in that of
6top-to-6top. Why?

Currently 6top-to-6top could be used for allocating cells through a
negotiation:

   1. mote A sends a reservation request to mote B in a cell, and that
   signaling packet is unicast, so acknowledged in the same cell by B
   2. mote B answers A with a reservation response in a following cell,
   which is also a unicast packet acnowledged in that same cell

Michel is saying:

   1. mote A sends a Frame Pending to B in a cell, and B sends the ack to A
   in the same cell answering with a temporary allocation

So, Michel's proposal uses 1 cell to perform the negotiation that 6top does
(in the current version) by using 2 cells. I guess this is the reason for
defining this approach reactive.

At the same time, the current 6top negotiation allows to exchange more
information for reserving a common available cell. In Michel's approach I
figure out many cases of failures: what happens if the temporary cell given
by B to A was already busy in A (it was already part of the A's schedule,
but with another neighbor, say C)? I guess A will not be able to free its
memory, so leading to congestion. Right?

Nicola

2015-07-01 10:09 GMT-07:00 Michel Veillette <
[email-masked]>:

> “Frame Pending subfield is 1 bit in length and shall be set to one if the
> device sending the frame has more data for the recipient. This subfield
> shall be set to zero otherwise”
>
>
>
> This feature can be especially useful for the upstream traffic in a RPL
> DODAG. In a scenario where a DAG parent have dozens of children, dedicated
> timeslot will be infrequent and share timeslots suffer from contention. If
> a subset of these children have ongoing traffic, the parent can use the
> Frame Pending flag information to schedule temporary soft cells and avoid
> contention or speedup transfer.
>
>
>
>
>
>
> Michel Veillette
> [email-masked]
>
> www.trilliantinc.com
>
>
>
>
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* 1 juillet 2015 11:28
> *To:* Nicola Accettura; Michel Veillette
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
>
>
>
> Hi Michel and Nicola,
>
>
>
> I think Michel's idea is interesting. But, according to my understanding,
> the Frame Pending setting just means there is frame following, does not
> mean that the current bandwidth provided by TSCH schedule, including hard
> cells and soft cells, is not enough to convey those frames, and then needs
> more bandwidth (e.g. additional soft cells) . Right? Do I miss something?
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
> However, OTF does not allocate cells directly: it just computes the
> estimated number of cells to add or delete into the schedule, and then
> sends this information to 6top. 6top is then in charge of negotiating cells
> among neighbors, and meybe perform the scheme you are proposing.
>
> It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not
> completely done yet) and I wandering if the concept of on the fly, in a
> single exchange, temporary allocation of a soft cell have already been
> discussed. For example, a node can use the Frame Pending subfield (IEEE
> 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready
> to be transmitted. Based on that knowledge, the target may add an IE in an
> enhanced acknowledgment to allocate a temporary soft cell (e.g. single
> cell). Each subsequent transmission may further re-allocate a temporary
> soft cell. It’s important to note that the default delay for a TSCH
> Acknowledgment is 1ms (macTsTxAckDelay) which seem sufficient for the
> processing of this new IE.
>
>
>
>
>
>
>
> [email-masked]
>
> www.trilliantinc.com
>
>
>
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Wed, 1 Jul 2015 20:17:47 +0000 (UTC)

Michel and Nicola,
Firstly, I agree It could be a good idea to let DATA/ACK frames carry softcell negotiation information, and agree it belongs to 6top-to-6top negotiation procedure, instead of OTF. 
Secondly, I would like to compare the two following schemes to implement the idea.
(1) nodeA sends a data frame to nodeB with Frame Pending setting; nodeB reply a ACK frame, with a softcell request response IE to give nodeA additional softcell to send its following data frame.
(2) nodeA  send a data frame to nodeB, in which a softcell request IE is carried;  nodeB reply a ACK frame, with a softcell request response IE to give nodeA additional softcell to send its following data frame.

I prefer scheme (2) although it costs more bits of softcell request IE from nodeA to nodeB, because Frame Pending bit belongs to MAC layer, it indicates there is more data following, not necessarily more bandwidth will be needed. 
The remained issue for both of the schemes is if the time for nodeB to insert the softcell request response IE into ACK frame is too tight or not. I don't have clear answer to it. 
What do you think?
ThanksQin

     On Thursday, July 2, 2015 2:05 AM, Nicola Accettura <[email-masked]> wrote:

 Qin,
you are pointing out that the bandwidth must be already provided if one wants to use  the Frame Pending setting. This is what we have discussed in the past and is the state of the art in 6tisch.

Michele is proposing to use the Frame Pending jointly with a temporary cell reservation in the ACK.

I guess this is not in the scope of OTF, but, in case, in that of  6top-to-6top. Why?

Currently 6top-to-6top could be used for allocating cells through a negotiation:
   
   - mote A sends a reservation request to mote B in a cell, and that signaling packet is unicast, so acknowledged in the same cell by B   

   - mote B answers A with a reservation response in a following cell, which is also a unicast packet acnowledged in that same cell
Michel is saying:
   
   - mote A sends a Frame Pending to B in a cell, and B sends the ack to A in the same cell answering with a temporary allocation
So, Michel's proposal uses 1 cell to perform the negotiation that 6top does (in the current version) by using 2 cells. I guess this is the reason for defining this approach reactive.

At the same time, the current 6top negotiation allows to exchange more information for reserving a common available cell. In Michel's approach I figure out many cases of failures: what happens if the temporary cell given by B to A was already busy in A (it was already part of the A's schedule, but with another neighbor, say C)? I guess A will not be able to free its memory, so leading to congestion. Right?

Nicola

2015-07-01 10:09 GMT-07:00 Michel Veillette <[email-masked]>:

Hi Qin Yes, the Frame Pending flag is defined as follow: IEEE 802.15.4-2006 section 7.2.1.1.3“Frame Pending subfield is 1 bit in length and shall be set to one if the device sending the frame has more data for the recipient. This subfield shall be set to zero otherwise” This feature can be especially useful for the upstream traffic in a RPL DODAG. In a scenario where a DAG parent have dozens of children, dedicated timeslot will be infrequent and share timeslots suffer from contention. If a subset of these children have ongoing traffic, the parent can use the Frame Pending flag information to schedule temporary soft cells and avoid contention or speedup transfer.  
|  | Michel Veillette
System Architecture DirectorTrilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]   |

Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 Hi Michel and Nicola, I think Michel's idea is interesting. But, according to my understanding, the Frame Pending setting just means there is frame following, does not mean that the current bandwidth provided by TSCH schedule, including hard cells and soft cells, is not enough to convey those frames, and then needs more bandwidth (e.g. additional soft cells) . Right? Do I miss something? ThanksQin  On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura <[email-masked]> wrote: Hi Michel,your proposal is very interesting.

So, your proposal seems fitting more the 6top-to-6top communication.Am I missing something? What others think about?SincerelyNicola 2015-06-30 8:13 GMT-07:00 Michel Veillette <[email-masked]>:
|  |
| Michel Veillette

---

From: Nicola Accettura <[email-masked]>
Date: Wed, 1 Jul 2015 16:54:58 -0700

Qin, Michel,

I also prefer option (2). This feature can be considered as a faster
negotiation addressing "emergencies".

Usually a negotiation will require two cells (1 for reservation request, 1
for reservation response). Let's call this as DEFAULT_NEGOTIATION.

In the "emergency" case, we have a single cell used. I guess a single cell
would be reserved, there is not enough room in the ack. Let's call this as
EMERGENCY_NEGOTIATION.

Actually, I think that an in-band reservation should be possible also for
the DEFAULT_NEGOTIATION: a data packet is encapsulated in a 6top packet,
with 6top possibly carrying the IEs related to a reservation request. IEs
will be processed at the 6top layer, the payload will be dispatched to
upper layers on the receiver side. Then, node B will send a reservation
response to node A within another cell (in case, with the same piggybacking
approach, if there is a cell from B to A and a data packet to be sent in
that direction). This possibility for the DEFAULT_NEGOTIATION could save
energy, since a single packet will be able to address 6top needs and
deliver data packets. I point out again that this could be an option
working when there is enough room in the packet to accomodate both data and
6top IEs. When there is no room for 6top IEs in packets carrying data (data
occupies most of the frame space), the 6top IEs will be sent in a following
dedicated packet, as in the current 6top drafts.

For the EMERGENCY_NEGOTIATION, piggybacking 6top IEs with data packet is
the sole option available.

As you point out, the Frame Pending bit does not mean that there is an
"emergency", so if node A sends a data packet to node B with the Frame
Pending set and with a 6top reservation request, there is no way to
discriminate if this would be a DEFAULT_NEGOTIATION or an
EMERGENCY_NEGOTIATION.

My question is: would that be possible to have a 6top flag bit indicating
EMERGENCY_NEGOTIATION?

I would also say that the reservation request IEs for softcells could be
significantly reduced in size. Node A could send a subset of available
timeslots (note, I'm not talking about cells), maybe in the form:
starttimeslot3-endtimeslot7, starttimeslot15-endtimeslot25, meaning that
timeslots 3,4,5,6,7,15,16,17,18,19,20,21,22,23,24,25 are available in its
own schedule (only  2*4b ytes needed). Node A will also indicate the number
of cells required, e.g. 3. Node B will answer with 3 cells: timeslot4 on
channeloffset3, timeslot5 on channeloffset 10, timeslot20 on channeloffset5.
In many cases the node starting a negotiation (node A) won't have to
specify a preferred channel offset for each proposed timeslot (maybe will
specify only a single channel offset for all timeslots proposed). This
possibility would save a lot of space in the reservation request.

You wrote also: "The remained issue for both of the schemes is if the time
for nodeB to insert the softcell request response IE into ACK frame is too
tight or not. I don't have clear answer to it." This is a very good point
we need to verify.

What do you think?

Nicola

2015-07-01 13:17 GMT-07:00 Qin Wang <[email-masked]>:

> Michel and Nicola,
>
> Firstly, I agree It could be a good idea to let DATA/ACK frames carry
> softcell negotiation information, and agree it belongs to 6top-to-6top
> negotiation procedure, instead of OTF.
>
> (1) nodeA sends a data frame to nodeB with Frame Pending setting; nodeB
> reply a ACK frame, with a softcell request response IE to give nodeA
> additional softcell to send its following data frame.
>
> (2) nodeA  send a data frame to nodeB, in which a softcell request IE is
> carried;  nodeB reply a ACK frame, with a softcell request response IE to
> give nodeA additional softcell to send its following data frame.
>
> I prefer scheme (2) although it costs more bits of softcell request IE
> from nodeA to nodeB, because Frame Pending bit belongs to MAC layer, it
> indicates there is more data following, not necessarily more bandwidth will
> be needed.
>
> The remained issue for both of the schemes is if the time for nodeB to
> insert the softcell request response IE into ACK frame is too tight or not.
> I don't have clear answer to it.
>
> What do you think?
>
> Thanks
> Qin
>
>
>    1. mote A sends a Frame Pending to B in a cell, and B sends the ack to
>    A in the same cell answering with a temporary allocation
>
> So, Michel's proposal uses 1 cell to perform the negotiation that 6top
> does (in the current version) by using 2 cells. I guess this is the reason
> for defining this approach reactive.
>
>  I think Michel's idea is interesting. But, according to my
> understanding, the Frame Pending setting just means there is frame
> following, does not mean that the current bandwidth provided by TSCH
> schedule, including hard cells and soft cells, is not enough to convey
> those frames, and then needs more bandwidth (e.g. additional soft cells) .
> Right? Do I miss something?
>
>  Thanks
>  Qin
>
>

---

From: Michel Veillette <[email-masked]>
Date: Thu, 2 Jul 2015 04:14:49 +0000

Hi Nicola, Qin

About “Frame Pending bit does not mean that there is an emergency”

I agree, the Frame Pending bit was provided just as an example in my first email. The assumption was that the target was fully in control of the scheduling base on availability of soft cells and availability of buffers. If more information need to be transferred like this notion of emergency or priority, a list of cells, the Frame Pending bit just need to be replaced by an IE. The concept however stay the same, a temporary soft cell allocation within a single transmission without consuming any extra bandwidth (cells).

About “ACK frame is too tight or not”

In the context of IEEE 802.15.4, the ack turnaround time is certainly too tight (192 usec)
For TSCH, the macTsTxAckDelay is 1 msec which seem to be very doable.

Michel Veillette

From: Nicola Accettura [mailto:[email-masked]]
Sent: 1 juillet 2015 19:55
To: Qin Wang
Cc: Michel Veillette; [email-masked]; [email-masked]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Qin, Michel,
I also prefer option (2). This feature can be considered as a faster negotiation addressing "emergencies".

Usually a negotiation will require two cells (1 for reservation request, 1 for reservation response). Let's call this as DEFAULT_NEGOTIATION.

In the "emergency" case, we have a single cell used. I guess a single cell would be reserved, there is not enough room in the ack. Let's call this as EMERGENCY_NEGOTIATION.
Actually, I think that an in-band reservation should be possible also for the DEFAULT_NEGOTIATION: a data packet is encapsulated in a 6top packet, with 6top possibly carrying the IEs related to a reservation request. IEs will be processed at the 6top layer, the payload will be dispatched to upper layers on the receiver side. Then, node B will send a reservation response to node A within another cell (in case, with the same piggybacking approach, if there is a cell from B to A and a data packet to be sent in that direction). This possibility for the DEFAULT_NEGOTIATION could save energy, since a single packet will be able to address 6top needs and deliver data packets. I point out again that this could be an option working when there is enough room in the packet to accomodate both data and 6top IEs. When there is no room for 6top IEs in packets carrying data (data occupies most of the frame space), the 6top IEs will be sent in a following dedicated packet, as in the current 6top drafts.
For the EMERGENCY_NEGOTIATION, piggybacking 6top IEs with data packet is the sole option available.
As you point out, the Frame Pending bit does not mean that there is an "emergency", so if node A sends a data packet to node B with the Frame Pending set and with a 6top reservation request, there is no way to discriminate if this would be a DEFAULT_NEGOTIATION or an EMERGENCY_NEGOTIATION.
My question is: would that be possible to have a 6top flag bit indicating EMERGENCY_NEGOTIATION?
I would also say that the reservation request IEs for softcells could be significantly reduced in size. Node A could send a subset of available timeslots (note, I'm not talking about cells), maybe in the form: starttimeslot3-endtimeslot7, starttimeslot15-endtimeslot25, meaning that timeslots 3,4,5,6,7,15,16,17,18,19,20,21,22,23,24,25 are available in its own schedule (only  2*4b ytes needed). Node A will also indicate the number of cells required, e.g. 3. Node B will answer with 3 cells: timeslot4 on channeloffset3, timeslot5 on channeloffset 10, timeslot20 on channeloffset5.
In many cases the node starting a negotiation (node A) won't have to specify a preferred channel offset for each proposed timeslot (maybe will specify only a single channel offset for all timeslots proposed). This possibility would save a lot of space in the reservation request.
You wrote also: "The remained issue for both of the schemes is if the time for nodeB to insert the softcell request response IE into ACK frame is too tight or not. I don't have clear answer to it." This is a very good point we need to verify.
What do you think?
Nicola

2015-07-01 13:17 GMT-07:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Michel and Nicola,

What do you think?

Thanks
Qin

On Thursday, July 2, 2015 2:05 AM, Nicola Accettura <[email-masked]<mailto:[email-masked]>> wrote:

Qin,

  1.  mote A sends a reservation request to mote B in a cell, and that signaling packet is unicast, so acknowledged in the same cell by B
  2.  mote B answers A with a reservation response in a following cell, which is also a unicast packet acnowledged in that same cell
Michel is saying:

  1.  mote A sends a Frame Pending to B in a cell, and B sends the ack to A in the same cell answering with a temporary allocation
So, Michel's proposal uses 1 cell to perform the negotiation that 6top does (in the current version) by using 2 cells. I guess this is the reason for defining this approach reactive.
At the same time, the current 6top negotiation allows to exchange more information for reserving a common available cell. In Michel's approach I figure out many cases of failures: what happens if the temporary cell given by B to A was already busy in A (it was already part of the A's schedule, but with another neighbor, say C)? I guess A will not be able to free its memory, so leading to congestion. Right?
Nicola

2015-07-01 10:09 GMT-07:00 Michel Veillette <[email-masked]<mailto:[email-masked]>>:
Hi Qin

Michel Veillette

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 1 juillet 2015 11:28
To: Nicola Accettura; Michel Veillette
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Michel and Nicola,

Thanks
Qin

Hi Michel,

Michel Veillette

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 2 Jul 2015 09:11:46 +0200

For neighbor-to-neighbor negociation, we have been opting for
https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00, i.e. a
speciifc IE which carries the same payload as we use for CoAP-based
management. This draft just expired, maybe Qin could publish a revised
version so we can start discussing from there in Prague?

I don't believe we can standardize that the node needs to do something
between the DATA frame it received and the ACK frame. ACK is just
link-layer mechanism to indicate that the node got the packet. AFTER the
ACK is sent, the node hands the MAC payload to the upper layer. Out of the
numerous things that can go wrong if we have a node do something between
DATA and ACK, I'm most worried about a node not being able to ACK some
packets, because the DATA packet contains too much semantics.

Comments welcome.

On Thu, Jul 2, 2015 at 6:14 AM, Michel Veillette <
[email-masked]> wrote:

> I agree, the Frame Pending bit was provided just as an example in my first
> email. The assumption was that the target was fully in control of the
> scheduling base on availability of soft cells and availability of buffers.
> If more information need to be transferred like this notion of emergency or
> priority, a list of cells, the Frame Pending bit just need to be replaced
> by an IE. The concept however stay the same, a temporary soft cell
> allocation within a single transmission without consuming any extra
> bandwidth (cells).
>
>
>
> *From:* Nicola Accettura [mailto:[email-masked]]
> *Sent:* 1 juillet 2015 19:55
> *To:* Qin Wang
> *Cc:* Michel Veillette; [email-masked]; [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Jul 2015 14:39:49 +0000

Hello Michel:

We discussed an angle of this on the call of 22 Nov 2013 recording here<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=73307867&rKey=c4a9734628e9656e> :

https://bitbucket.org/6tisch/meetings/wiki/131122_webex at 8:13<https://bitbucket.org/6tisch/meetings/wiki/131122_webex%20at%208:13>
https://bitbucket.org/6tisch/meetings/src/master/131122_webex/slides_131122_webex.ppt

In short, if the schedule is rather not busy, we can have more timeSlots per child than they really need.

In that case, the peer would only listen to the first timeSlot of a sequence of say 4. If there is no traffic there, the peer would not listen for the other 3. But if there is traffic, then the sender can indicate whether there’s more till done, in which case all the timeSlots could be used on that round.

This avoids negotiation to allocate / deallocate time slots.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Michel Veillette
Sent: mercredi 1 juillet 2015 19:10
To: Qin Wang; Nicola Accettura
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hi Qin

Michel Veillette

Hi Michel and Nicola,

Thanks
Qin

Hi Michel,

Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Thu, 2 Jul 2015 15:25:37 +0000

Hi Pascal

I’m trying to address a different use case I thinks, when the  number of timeslots is limited. This use case is probably more relevant to large scale NAN networks (e.g. Zigbee NAN).

This use case is as follow.

Let say I have a RPL parent with 100 RPL children with a timeslot of 10 msec. If I want to assign a dedicated timeslot to each child, 100 timeslots need to be assigned. This means that a timeslot for uplink traffic will available to a child only each couple of seconds. The propose approach allows the RPL parent to reserve soft cells to allocate bandwidth dynamically to some of these 100 children when needed.

Is this make some sense?
Is there something already available if the drafts to accommodate this use case?

Michel Veillette

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 2 juillet 2015 10:40
To: Michel Veillette; Qin Wang; Nicola Accettura
Cc: [email-masked]; [email-masked]
Subject: RE: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Hello Michel:

Cheers,

Pascal

Hi Qin

Michel Veillette

Hi Michel and Nicola,

Thanks
Qin

Hi Michel,

Michel Veillette

---

From: Jonathan Simon <[email-masked]>
Date: Thu, 2 Jul 2015 12:14:50 -0700

+1   

The 15.4 spec only has a few criteria for not acknowledging a frame - mismatch PANID, mismatch destination address, or failing security processing.

— 
Jonathan

On Jul 2, 2015, at 12:11 AM, Thomas Watteyne <[email-masked]> wrote:

> For neighbor-to-neighbor negociation, we have been opting for https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00, i.e. a speciifc IE which carries the same payload as we use for CoAP-based management. This draft just expired, maybe Qin could publish a revised version so we can start discussing from there in Prague?
> 
> I don't believe we can standardize that the node needs to do something between the DATA frame it received and the ACK frame. ACK is just link-layer mechanism to indicate that the node got the packet. AFTER the ACK is sent, the node hands the MAC payload to the upper layer. Out of the numerous things that can go wrong if we have a node do something between DATA and ACK, I'm most worried about a node not being able to ACK some packets, because the DATA packet contains too much semantics.
> 
> Comments welcome.
> 
> On Thu, Jul 2, 2015 at 6:14 AM, Michel Veillette <[email-masked]> wrote:
> Hi Nicola, Qin
> 
>  
> 
> mote A sends a reservation request to mote B in a cell, and that signaling packet is unicast, so acknowledged in the same cell by B
> mote B answers A with a reservation response in a following cell, which is also a unicast packet acnowledged in that same cell
> Michel is saying:
> 
> mote A sends a Frame Pending to B in a cell, and B sends the ack to A in the same cell answering with a temporary allocation
> http://cp.mcafee.com/d/FZsSd2gwcxNJ5xBZVd55AsrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCXLIuMqenT-LOarzbP7nKnjp7cYCOesspVqWdAkRrK9YG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9CT9OFoCn8lrxrW0GnPtU02rsvod7bNI5-Aq83iSVelb4PiWq848WXcKwS8RcMYKVelb4OZo5VA_bKDByZTPr0USHhf0y2c43Xx

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 Jul 2015 12:38:27 +0000

Dear all:

The discussion seems to lean on the assumption that the remote peer allocates the cell, which is true for child to parent.

I’ll note that for a parent to child, the frame would already indicate the next cell that the parent allocates, and the child would acknowledge that it will listen there.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Nicola Accettura
Sent: jeudi 2 juillet 2015 01:55
To: Qin Wang
Cc: Michel Veillette; [email-masked]; [email-masked]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05

Qin, Michel,

What do you think?

Thanks
Qin

Qin,

Michel Veillette

Hi Michel and Nicola,

Thanks
Qin

Hi Michel,

Michel Veillette