Hello Mirja: I published 20 with this addition.
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-20 I guess we're close to be done by now. In that case, I must thanks you again and deeply. Be safe, Pascal > -----Original Message----- > From: Mirja Kuehlewind <[email protected]> > Sent: vendredi 20 mars 2020 18:12 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: [email protected]; The IESG <[email protected]>; [email protected]; > draft-ietf-6lo- > [email protected]; Carles Gomez <[email protected]>; Martin > Duke <[email protected]>; Benjamin Kaduk <[email protected]> > Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: > (with DISCUSS and COMMENT) > > 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
