Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hello Mirja > >> >> >> Please see below the discussion: >> > - > - > DISCUSS: > - > >> >> Note that all classical wireless interfaces perform ARQ. On one hop, you get >> the same effect of multiplying the traffic in the air vs. what the transport >> see. The factor can be high, e.g., 64. On a mesh, we get the additional >> effect of multiple flows converging on a same node. > > Yes but with only “one hop”/the network you are connected to directly, and > there is usually also some kind of back-off mechanism that reacts to > congestion/collision/contention on that layer. > > >> >>> >>> To be clear the request of this discuss is to give a normative >>> recommendation >>> for the default value of the window size and/or inter-frame gap. >> >> Yes, and since there is no great expectation that ECN will be implemented, >> that must be reasonable. >> Also we want to agree on the proposed mechanism to drop the window to 1 in >> case of congestion notification, or is that behind us already? > > Dropping to 1 on CE mark is fine. However, when do you increase the window > again? If you want to say something here, you have to specify that as well. If we keep things really simple it would not. Note that this applies to a single data gram and that’s usually just a few fragments. We could double at each round trip but by the time it takes effect the datagram will be done... > >> >> >>> >>> Further note, as you allow to adapt both the window and the inter-frame gap >>> dynamically, you actually implement two control mechanisms here. I actually >>> recommend to only use the inter-frame gap and don’t have window here. You >>> say a couple of times in your reply below, that the window determines the >>> ask- >>> rate, however, it is not clear to me because the ack rate should be a >>> parameter >>> at the receiver and not at the sender (maybe I don’t remember things >>> correctly >>> because it’s a while back since I read the draft and I couple find anything >>> about >>> this in the draft quickly). If the window size however does define the ack >>> rate, >>> then maybe you should rename that parameter respectively. >> >> The ack is not for flow control (as we do not have it) but in support of >> ARQ. The possibility to use it for congestion control is a desirable side >> effect. The fragmenting endpoint FSM may want to wait and see how things >> went for the fragments that it already sent. E.g., there's the case where >> the fragmenting endpoint would use an ack on the first fragment for a >> number of reasons such as check that a path is available, that the MTU is OK >> or assess an initial RTT. It may maximize the number of fragments in flight >> for congestion control. But whether to do any of that is left to >> implementation (so far). >> >> >>> >>> However, if there is really a need for a window, I still recommend to talk >>> less >>> about adapting this value dynamically and make clear that having a fixed >>> value >>> is the recommended default. Therefore I recommend to remove the parameter >>> MinWindowSize and MaxWindowSize because these should actually not be >>> parameters than can be configured but are actual bounds. If someone decides >>> to implement dynamic window adaption, they can decide to re-introduce these >>> parameter again and make them configurable but it doesn’t need to be part of >>> this spec. >> >> I can see that, yes. I still like the idea to drop to 1 in case of ECN. >> Do you suggest to remove that as well? >> If so, should we augment the inter-frame gap in case of ECN? >> That may be better though not simpler to specify or implement. > > That’s an option as well. Again when you reduce something you might as well > need to specify when to increase it again and that means you are specifying > basically a congestion control scheme. My goal for this doc was to keep it dead simple, build it so we have the necessary basis with ecn and windowing, and then play with it and learn from it. only then we can do a valuable spec. can we keep it at what the doc has now? > >> >> >> >>> >>> So it could be something like: >>> >>> "Window_Size: Window_Size MUST be at least 1 and less than 33. If the >>> inter- >>> frame gap is selected large enough to not overload the path and the one-way >> >> I see the IFG as more efficient for flow control than for congestion >> control: Increasing IFG slows down the packets but as long as the result is >> faster than the bottleneck, it does not help much does it? So I'm still >> unsatisfied on how to characterize an IFG that does not overload a path. But >> I'm not sure we can do better. I moved that piece to the IFG definition if >> that's OK? > > So how do you currently set the IFG? Both IFG and window_size can be used for > both flow as well as congestion control, it
Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hi Pascal, Inline. > On 19. Mar 2020, at 15:57, Pascal Thubert (pthubert) > wrote: > > Hello Mirja > >> Thanks for you updates. Sorry for my late reply. I unfortunately have some >> more comments. Please see below. > > More comments => more thanks, you'll have to live with it > > As usual I published for your convenience so you can observe the global > effect of your review. > Please see > https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-18.txt > (and as usual also I found a typo there that I fixed, this time the > duplication of "reduce the") > > Please see below the discussion: > - - DISCUSS: - > > >>> 4.3. Flow Control >>> >>> The inter-frame gap is the only protection that [FRAG-FWD] imposes by >>> default. This document enables to group fragments in windows and >>> request intermediate acknowledgements so the number of in-flight >>> fragments can be bounded. This document also adds an ECN mechanism >>> that can be used to adapt the size of the window, the size of the >>> fragments, and/or the inter-frame gap to protect the network. >>> >>> This specification enables the source endpoint to apply a flow >>> control mechanism to tune those parameters, but the mechanism itself >>> is out of scope. In most cases, the expectation is that most >>> datagrams will represent only a few fragments, and that only the last >>> fragment will be acknowledged. A basic implementation of the source >>> endpoint is NOT REQUIRED to variate the size of the window, the >>> duration of the inter-frame gap or the size of a fragment in the >>> middle of the transmission of a datagram, and it MAY ignore the ECN >>> signal or simply reset the window to 1 (see Appendix C for more) till >>> the end of this datagram upon detecting a congestion. >>> >>> The size of the fragments is typically computed from the Link MTU to >>> maximize the size of the resulting frames. The size of the window >>> and the duration of the inter-frame gap SHOULD be configurable, to >>> roughly adapt the size of the window to the number of hops in an >>> average path, and to follow the general recommendations in >>> [FRAG-FWD], respectively. >>> “ >>> >> Thanks for adding this. However, as I said a couple of times in my discuss >> there >> must be more guidance. This is not only about flow control but also about >> congestion control and it is not okay to declare congestion control out of >> scope. If you only do fragmentation but no retransmission, you don’t need to >> care about congestion control (but only flow control) as you don’t increase >> the >> actual network load by this. However, if you retransmit you are sending more >> data than the original sender (that hopefully is congestion controlled) and >> therefore you increase the load on the network and you MUST implement your >> own congestion control or some fixed rate limiting for that additional load. >> Saying this is out of scope and you want to do experimentation is not >> acceptable for a Proposed Standard. > > I agree. I should be a lot more careful with my wording. > > Understanding that the flow control is pacing from the receiver to protect > the receiver and congestion control is protecting the network (ECN etc...); > stricto sensu we are not doing any flow control since the receiver is > expected to have a buffer for the whole datagram and he does not need to be > protected. All we do is congestion control. > > => I should change "flow control" to "congestion control" throughout, and add > text about the above, is that correct? Yes, thanks! > > Note that all classical wireless interfaces perform ARQ. On one hop, you get > the same effect of multiplying the traffic in the air vs. what the transport > see. The factor can be high, e.g., 64. On a mesh, we get the additional > effect of multiple flows converging on a same node. Yes but with only “one hop”/the network you are connected to directly, and there is usually also some kind of back-off mechanism that reacts to congestion/collision/contention on that layer. > >> >> To be clear the request of this discuss is to give a normative recommendation >> for the default value of the window size and/or inter-frame gap. > > Yes, and since there is no great expectation that ECN will be implemented, > that must be reasonable. > Also we want to agree on the proposed mechanism to drop the window to 1 in > case of congestion notification, or is that behind us already? Dropping to 1 on CE mark is fine. However, when do you increase the window again? If you want to say something here, you have to specify that as well. > > >> >> Further note, as you allow to adapt both the window and the inter-frame gap >> dynamically, you actually implement two control mechanisms here. I actually >> recommend
Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hello Mirja > Thanks for you updates. Sorry for my late reply. I unfortunately have some > more comments. Please see below. More comments => more thanks, you'll have to live with it As usual I published for your convenience so you can observe the global effect of your review. Please see https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-18.txt (and as usual also I found a typo there that I fixed, this time the duplication of "reduce the") Please see below the discussion: > >> - > >> - > >> DISCUSS: > >> - > > 4.3. Flow Control > > > > The inter-frame gap is the only protection that [FRAG-FWD] imposes by > > default. This document enables to group fragments in windows and > > request intermediate acknowledgements so the number of in-flight > > fragments can be bounded. This document also adds an ECN mechanism > > that can be used to adapt the size of the window, the size of the > > fragments, and/or the inter-frame gap to protect the network. > > > > This specification enables the source endpoint to apply a flow > > control mechanism to tune those parameters, but the mechanism itself > > is out of scope. In most cases, the expectation is that most > > datagrams will represent only a few fragments, and that only the last > > fragment will be acknowledged. A basic implementation of the source > > endpoint is NOT REQUIRED to variate the size of the window, the > > duration of the inter-frame gap or the size of a fragment in the > > middle of the transmission of a datagram, and it MAY ignore the ECN > > signal or simply reset the window to 1 (see Appendix C for more) till > > the end of this datagram upon detecting a congestion. > > > > The size of the fragments is typically computed from the Link MTU to > > maximize the size of the resulting frames. The size of the window > > and the duration of the inter-frame gap SHOULD be configurable, to > > roughly adapt the size of the window to the number of hops in an > > average path, and to follow the general recommendations in > > [FRAG-FWD], respectively. > > “ > > > Thanks for adding this. However, as I said a couple of times in my discuss > there > must be more guidance. This is not only about flow control but also about > congestion control and it is not okay to declare congestion control out of > scope. If you only do fragmentation but no retransmission, you don’t need to > care about congestion control (but only flow control) as you don’t increase > the > actual network load by this. However, if you retransmit you are sending more > data than the original sender (that hopefully is congestion controlled) and > therefore you increase the load on the network and you MUST implement your > own congestion control or some fixed rate limiting for that additional load. > Saying this is out of scope and you want to do experimentation is not > acceptable for a Proposed Standard. I agree. I should be a lot more careful with my wording. Understanding that the flow control is pacing from the receiver to protect the receiver and congestion control is protecting the network (ECN etc...); stricto sensu we are not doing any flow control since the receiver is expected to have a buffer for the whole datagram and he does not need to be protected. All we do is congestion control. => I should change "flow control" to "congestion control" throughout, and add text about the above, is that correct? Note that all classical wireless interfaces perform ARQ. On one hop, you get the same effect of multiplying the traffic in the air vs. what the transport see. The factor can be high, e.g., 64. On a mesh, we get the additional effect of multiple flows converging on a same node. > > To be clear the request of this discuss is to give a normative recommendation > for the default value of the window size and/or inter-frame gap. Yes, and since there is no great expectation that ECN will be implemented, that must be reasonable. Also we want to agree on the proposed mechanism to drop the window to 1 in case of congestion notification, or is that behind us already? > > Further note, as you allow to adapt both the window and the inter-frame gap > dynamically, you actually implement two control mechanisms here. I actually > recommend to only use the inter-frame gap and don’t have window here. You > say a couple of times in your reply below, that the window determines the ask- > rate, however, it is not clear to me because the ack rate should be a > parameter > at the receiver and not at the sender (maybe I don’t remember things correctly > because it’s a while back since I read the draft and I couple find anything > about > this in the draft quickly). If the window size however does define the ack > rate, > then maybe you should rename that parameter
[6lo] I-D Action: draft-ietf-6lo-fragment-recovery-18.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF. Title : 6LoWPAN Selective Fragment Recovery Author : Pascal Thubert Filename: draft-ietf-6lo-fragment-recovery-18.txt Pages : 31 Date: 2020-03-19 Abstract: This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-18 https://datatracker.ietf.org/doc/html/draft-ietf-6lo-fragment-recovery-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Virtual 6Lo WG meeting - Call for agenda items - 27th April
Dear all, As you know, the exceptional situation due to COVID-19 led to cancelling the in-person IETF 107 meeting. As a replacement for the 6Lo WG session that was originally scheduled for IETF 107, we plan to hold a virtual interim 6Lo WG meeting. As recommended by the IESG, we plan to hold the virtual meeting on Monday, 27th of April (at a time yet to be determined, and with further details to be provided). Please send your requests for agenda items to the chairs by Thursday, 26th of March. Please provide us with the following information: - Draft name - Presenter name - Expected duration - Objective of the discussion As usual, we will need minute takers. Please do not hesitate to volunteer! Should you have any comments or questions, please let us know. Thanks, Shwetha and Carles ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hi Pascal, Thanks for you updates. Sorry for my late reply. I unfortunately have some more comments. Please see below. > On 6. Mar 2020, at 19:57, Pascal Thubert (pthubert) > wrote: > > Hello Mirja > > A great many thanks for your really deep review, this is both really > appreciated and incredibly useful. > > If that's OK with you let's make a round to clear the DISCUSSes separately > like I did for Benjamin's review. > > Also considering the breadth of the discuss alone, I'd rather publish the > proposed changes so you and Benjamin can review the changes I made for your > DISCUSSes. > > Please find the proposed changes discussed below in > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-14 > >> >> -- >> DISCUSS: >> -- >> >> Thanks for this well written document, however, I have a couple points >> below that need further clarification, all mostly related to congestion >> control. From an editorial point of view most of this is discussed either in >> the >> intro text of section 6, then some part in 7.1, and some in the appendix C. I >> would really recommend you to instead have a separate section that much >> clearer states what should be done by default (probably no dynamically >> window but a small fixed window with maybe size of 1) and what could be >> don as further optimisation, and also to discuss the parameter/variables >> there before the algorithms are discussed. >> > > A size of 1 is probably not acceptable for the general LLN case, considering > the cost of an ack. I'd rather leave that to config. > Otherwise, I agree. What about adding a subsection in section 4 as follows > (including changes that cover your comments below): > > " > 4.3. Flow Control > > The inter-frame gap is the only protection that [FRAG-FWD] imposes by > default. This document enables to group fragments in windows and > request intermediate acknowledgements so the number of in-flight > fragments can be bounded. This document also adds an ECN mechanism > that can be used to adapt the size of the window, the size of the > fragments, and/or the inter-frame gap to protect the network. > > This specification enables the source endpoint to apply a flow > control mechanism to tune those parameters, but the mechanism itself > is out of scope. In most cases, the expectation is that most > datagrams will represent only a few fragments, and that only the last > fragment will be acknowledged. A basic implementation of the source > endpoint is NOT REQUIRED to variate the size of the window, the > duration of the inter-frame gap or the size of a fragment in the > middle of the transmission of a datagram, and it MAY ignore the ECN > signal or simply reset the window to 1 (see Appendix C for more) till > the end of this datagram upon detecting a congestion. > > The size of the fragments is typically computed from the Link MTU to > maximize the size of the resulting frames. The size of the window > and the duration of the inter-frame gap SHOULD be configurable, to > roughly adapt the size of the window to the number of hops in an > average path, and to follow the general recommendations in > [FRAG-FWD], respectively. > “ > Thanks for adding this. However, as I said a couple of times in my discuss there must be more guidance. This is not only about flow control but also about congestion control and it is not okay to declare congestion control out of scope. If you only do fragmentation but no retransmission, you don’t need to care about congestion control (but only flow control) as you don’t increase the actual network load by this. However, if you retransmit you are sending more data than the original sender (that hopefully is congestion controlled) and therefore you increase the load on the network and you MUST implement your own congestion control or some fixed rate limiting for that additional load. Saying this is out of scope and you want to do experimentation is not acceptable for a Proposed Standard. To be clear the request of this discuss is to give a normative recommendation for the default value of the window size and/or inter-frame gap. Further note, as you allow to adapt both the window and the inter-frame gap dynamically, you actually implement two control mechanisms here. I actually recommend to only use the inter-frame gap and don’t have window here. You say a couple of times in your reply below, that the window determines the ask-rate, however, it is not clear to me because the ack rate should be a parameter at the receiver and not at the sender (maybe I don’t remember things correctly because it’s a while back since I read the draft and I couple find anything about this in the draft quickly). If the window size however does define the ack rate, then maybe you should rename
