Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Ben
´
> Le 3 avr. 2020 à 05:37, Benjamin Kaduk <[e-mail]> a écrit :
> 
> Hi Pascal,
> 
>> On Thu, Apr 02, 2020 at 09:57:07AM +0000, Pascal Thubert (pthubert) wrote:
>> Hello Benjamin and authors:
>> 
>> Thomas is really the MAC expert, (virtually) collocated with him, and more fluent in English than I'll ever be. But I'll take a chance at it.
>> 
>> I understand that the problem you're concerned with happens when the automatic slot offset for node A ends up the same as that for node B. Note that it does not take a hash collision, because the problem is independent of the 
>> channel offset. All it takes is a collision in time, because if I'm busy transmitting I cannot receive on a half duplex radio. The chance of this to occur is 1/slotframe_size for a random pick for which the hash is an approximation.  
>> 
>> In that case (same auto slot for A and B), an arbitrary node  C (which could be A or any other node) will fail to talk to B if B has something to transmit to A, because if B xmit has precedence, and when B's radio is busy and it will not to receive from C, even on a different channel (it's half duplex). So if B keeps talking a lot to A, that will make it mostly deaf. But if B is a relay as opposed to the generator of traffic, the xmit queue will dry out and B will listen again. 
>> 
>> If C is A, meaning that A sends to B and B sends to A at the same time, and in the absence of other traffic, the retries will happen at different times and will not collide, all good. If the traffic in both direction becomes intense, the retries will cause even more collisions and we'll end in congestion collapse.
> 
> The "retries will happen at different times" is the part that I was
> missing, and Tengfei just added a description of that in the -16, so I
> think I'm all set as far as this goes.
> 
> Thanks for the detailed explanation!
> 

All good then; I misunderstood and thought you expected a finer description of the case in the spec.

>> Potential defenses include:
>> - MSF could be more aggressive at establishing cells to nodes that end with the same automatic slotOffset as self
>> - In densely used networks (which are unusual for battery operated networks), define multiple timeslots with different auto slotOffset for each node, using different seeds for the hash (like a nmber 1 ..n),  and have the sender use a random one for Tx.
>> 
>> Is that what you are after?
> 
> It's not clear to me that we need to mandate either of these as part of a
> *minimal* scheduling function, though having a description of the potential
> issues would be reasonable.

This is what I expected, though it is not a security issue per say, it is still a pitfall that the deployment should be aware of. Also the reader may have the same intuition as you did and having the description handy makes sense to me. That could be an annex though. I did not expect to mandate solutions just to express them like we do in a security section. Note that renumbering is another remediation and still an open question in your COMMENTS.


>  (Should we expect higher-layer protocols to
> eventually back off and remedy the congestion collapse?)
> 

I’d not suggest that. It would work but misuse the network and waste energy.

 The root issue is not the load between A and B but the MAC addresses that they picked and the shape If the mesh. IMHO this should be addressed under IP.

> I'm going to go clear my Discuss now, as those points are resolved, which
> of course does not preclude making further changes.
> 

Many thanks Ben!



> -Ben
> 
>> Thomas (or Simon): I'm sure I'm missing stuff, what more is there?
>> 
>> You all keep safe
>> 
>> Pascal
>> 
>> 
>> 
>>>>>>     DISCUSS:
>>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> --
>>>>>> 
>>>>>>     I'm concerned that the scheduling function for autonomous cells can
>>>>>>     cause an infinite loop in the case of hash collision -- Section 3
>>>>>>     specifies that AutoTxCell always takes precedence over
>>>>>> AutoRxCell,
>>>>> but
>>>>>>     if those two cells collide, the corresponding cells on the peer in
>>>>>>     question will also collide.  If both peers try to send at the
>>>>>> same
>>>>> time
>>>>>>     and the hashes collide, they will both attempt to transmit
>>>>> indefinitely
>>>>>>     and never be received.
>>>>>> 
>>>>>> 
>>>>>>> . Notice that the AutoTxCell  is a shared cell, where the back-off
>>>>>>   mechanism is applied.
>>>>>>> In case there is a collision on that cell, a back-off with different
>>>>>>   exponent will be used on each side.
>>>>>>> The cell will be used AutoTxCell on each side at different timing.
>>>>> 
>>>>> Ah, it seems I was misinterpreting "take precedence over" to apply
>>>>> to the entire local scheduling, not merely the case when independent
>>>>> tx and rx scheduling land on the same cell.  Thanks for clarifying
>>>>> here; is there anything useful to say in the document about how even
>>>>> if there is a collision in the assigned slot there's still a Tx
>>>>> backoff, so the cell is usable for Rx some of the time?
>>>>> 
>>>> 
>>>> * RESPONSE: * We could add the following sentence right after the
>>>> hashing collision statement:
>>>> 
>>>> Notice AutoTxCell is a shared type cell which applies back off mechanism.
>>>> When the AutoTxCell and AutoRxCell are collided,  AutoTxCell takes
>>>> precedence if there is a packet to transmit.
>>>> In case in a back-off period, AutoRxCell is used.
>>> 
>> 
>>