Hi Pascal, The proposed text below and in your previous email look good! Thanks!
I would appreciate and recommend to add also a shorter version of your good explanation below to make the reader better understand which factor is the limiting one when using a certain parameter setting and respectively which factor could be tuned if any dynamic adaptation is implemented. Thanks! Mirja P.S.: Off for today but will check for an update tomorrow in order to clear my discuss! > On 20. Mar 2020, at 17:15, Pascal Thubert (pthubert) > <[email protected]> wrote: > > 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 > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
