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 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 <[e-mail]>
> Sent: vendredi 20 mars 2020 18:12
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; The IESG <[e-mail]>; [e-mail]; draft-ietf-6lo-
> [e-mail]; Carles Gomez <[e-mail]>; Martin
> Duke <[e-mail]>; Benjamin Kaduk <[e-mail]>
> 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)
> <pthubert=[e-mail]> 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
> >