Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

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

Hello Mirja

I missed this while working on yesterday's message.

Let's see below:


> Okay! :-)
> 
> About the use of ECN, I agree as you say there should only be a few fragments
> and not increasing might be okay. However, you would need to clarify that the
> window is reset for each new datagram, I guess, right? 

Agreed. Let's change appendix C, more below;

> Also I don’t think you
> necessarily need to reduce to 1 on CE marking but maybe halve the window or
> something. Or you leave this open like “If an E flag is received the window
> SHOULD be reduced, at least by 1 and at max to 1. Halving the window for
> each E flag received, could be a good compromise but needs further
> experimentation.”…

Thanks for this text! Appendix C now becomes:
"
   Congestion on the forward path can also be indicated by an Explicit
   Congestion Notification (ECN) mechanism.  Though whether and how ECN
   [RFC3168] is carried out over the LoWPAN is out of scope, this draft
   provides a way for the destination endpoint to echo an ECN indication
   back to the fragmenting endpoint in an acknowledgment message as
   represented in Figure 4 in Section 5.2.  While the support of echoing
   the ECN at the reassembling endpoint is mandatory, this specification
   only provides a minimalistic behaviour on the fragmenting endpoint.
   If an E flag is received the window SHOULD be reduced, at least by 1
   and at max to 1.  Halving the window for each E flag received, could
   be a good compromise but needs further experimentation.  A very
   simple implementation may just reset the window to 1 so the fragments
   are sent and acknowledged one by one.  Note that the action on ECN
   only applies till the end of the datagram and the next datagram uses
   the configured Window_Size again.

"

I'd like to fully converge before I publish again

> I wonder if it would be good to say a bit more about the recommended values
> for the window size, as I think 32 will usually in most network not limit
> transmission (and the limiting value will be IFG) while with a size of 3, that's
> very conservative to not overload the network (and will be slow than the limits
> induced by IFG). Is my understanding correct?

I'd believe so:

Note that the exact use of the ack and the window_size is left to implementation. The optimistic one could send all the fragments up to window_size and ask for an ack only on the last one, wait for the bitmap, which means a gap of RTT/2, and resend the losses.
Then again we want to leave room for learning. The pessimistic implementation could set the bit on the first fragment to check that the path works and open the window only upon receiving the ack. It could then set an ack bit again on the second fragment and then use the window as a credit to send up to window_size before it is blocked. In that case, if the ack comes back before the window starves, the gating factor is the IFG. If the ack does not arrive in time, the window_size is the gating factor.

If the sender uses the window_size as a credit, the window of 3 will be the gating factor that starves the sender and causes gaps longer than IFG as soon as you have more than 3 hops in a TSCH network and 5-6 hops in a single frequency mesh. I guess that's what you mean by slower. The more hops the more it will hurt.

I initially used nb_of_hops as a rule of a thumb. That was an approximation of RTT/(XMIT+IFG) in the case one fragment needs to progress only to the second hop before the next can be sent (case of TSCH). 

The assumptions behind are that an rfrag_ack takes the same path and the same time as the rfrag, which is mostly correct. So if we spread the fragments with IFG, keeping busy one hop out of 2 on both directions means aligning the window_size of the nb of hops. As you pointed out this is not a congestion control measure, it is just the window that is not "slower" than IFG, per your expression. The text that uses RTT/(XMIT+IFG) being equivalent I'm happy either way. Because knowing the RTT is the same problem as knowing the number of hops so we do not need to indicate both. 

3 is when you h	ave no idea of either RTT or nb of hops. it is conservative and will starve the TSCH sender if we have more than 3 hops. It also protects the intermediate node that can be very constrained, to at most 3 fragments per datagram that it relays. Note that I'm not aware of any full duplex radio available in LLNs (though there are prototypes for 5G). So this is really a corner case.

As written 32 indicates the last fragment of the datagram, which is usually way less than 32. When used, as you understood well, the only protection is IFG, and I'm must say I'm quite happy with the progress we made on that text together.

Please let me know, should I change something more?

Pascal