Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hi Pascal, Thanks for this additional text. I just cleared my discuss. A couple of nits you/Suresh maybe want to add as RFC editor note: OLD Note that the action upon detecting a congestion only applies till the end of the datagram NEW Note that the action upon detecting congestion only applies till the end of the datagram. MAYBE EVEN Note that any action that has been performed upon detection of congestion only applies for the transmission of one datagram OLD an inter-frame gap can be as a flow control or a congestion control measure NEW The inter-frame gap can be used as a flow control or a congestion control measure OLD a conservative Window_Size of, say, 3, will be the gating factor that starves the sender MAYBE a conservative Window_Size of, say, 3, will be the gating factor that limits the transmission rate of the sender Mirja > On 20. Mar 2020, at 19:25, Pascal Thubert (pthubert) > wrote: > > 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 >> Sent: vendredi 20 mars 2020 18:12 >> To: Pascal Thubert (pthubert) >> Cc: 6lo-cha...@ietf.org; The IESG ; 6lo@ietf.org; >> draft-ietf-6lo- >> fragment-recov...@ietf.org; Carles Gomez ; Martin >> Duke ; Benjamin Kaduk >> 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) >> 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 recomme
Re: [6lo] 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) > 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
Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
Hi Pascal, 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? 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.”… 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? Mirja > On 19. Mar 2020, at 20:12, Pascal Thubert (pthubert) > wrote: > > 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 we
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 to
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
Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)
Hi Pascal, Again, yes, you can have normative text in information documents. In the minutes below the group concluded correctly, as also mentioned by Suresh, that the respective text should be normative. However, that does not automatically mean that this document has to be PS. In any case this is a decision for Suresh to make and I just provided my input. Mirja > On 4. Mar 2020, at 13:56, Pascal Thubert (pthubert) > wrote: > > Hello again Mirja > > The decision was made in Singapore at the 6lo working group with Suresh. > > The minutes are at https://datatracker.ietf.org/doc/minutes-106-6lo/ > I extracted the below for you: > > " > [13:42] > INTDIR review of 6LoWPAN fragment forwarding Pascal > Thubert 10 min >https://tools.ietf.org/html/draft-ietf-6lo-minimal-fragment-04 > https://datatracker.ietf.org/meeting/106/materials/slides-106-6lo-6lo-fragmentation-00 > minimal-fragment and fragment-recovery drafts. Passed WG LC. > Pascal goes over Dave Thaler's review. Discussion about is the draft > normative. > Text introduces behaviour with uppercase that is generic to any FF solution, > be it VRB or recovereable fragments. Also discusses pitfalls such as found > with Rahul's experiments. No more a simple description of the Virtual > Reassembly Buffer technique. > Suresh: I think its normative. > Pascal: will add BCP14 text. > Another comment is hitting Hop Limit while fragmented, how is it reported to > the source, which source? If send ICMP packet to origin source with > reconstructed packet, loose all info on cause for the problem (if pb occurred > with fragments). Should 6lo, independent from this work, document ICMP > handling behaviour in hc scenarios? Discussion on what proper response should > be to the situation described. > > " > All in all the main point was that it is not an article on VRB but a > specification on a "mpls like" forwarding technique. > > Also please find below the message that triggered the change: > > " > > All the best > > Pascal > > -Original Message- > From: Carles Gomez Montenegro > Sent: mardi 26 novembre 2019 18:41 > To: Pascal Thubert (pthubert) > Cc: 6lo-cha...@ietf.org > Subject: Re: minimal fragments > > Dear Pascal, > > Yes, based on Suresh's comments during the 6lo session in Singapore, it is > our understanding that the Intended Status for the "minimal" draft needs to > be "Standards Track". > > Thanks for your hard work! > > Shwetha and Carles > > >> Dear chairs >> >> I think we concluded that with the changes I made for Dave Thaler's >> review the doc should now be std track. >> I published the changes in question in 05, together with a new >> security section based on Ines' IOT-DIR review; please let me know if >> I should move the track to std as well. >> >> All the best >> >> Pascal > > " > > That's all the history that I could find. Having been through that change and > again, I'm not inclined to reopen. > But I'm willing to learn. Where exactly do you place the bar? > > All the best > > Pascal > >> -Original Message- >> From: Mirja Kuehlewind >> Sent: mercredi 4 mars 2020 13:41 >> To: Pascal Thubert (pthubert) >> Cc: The IESG ; Benjamin Kaduk ; draft-ietf- >> 6lo-minimal-fragm...@ietf.org; Carles Gomez ; 6lo- >> cha...@ietf.org; 6lo@ietf.org >> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-6lo-minimal- >> fragment-12: (with COMMENT) >> >> Hi Pascal, >> >> Informational documents can also have normative text. If that was the >> criteria >> the decision was made on, the decisions should be re-evaluated. >> >> Mirja >> >> >> >>> On 4. Mar 2020, at 13:25, Pascal Thubert (pthubert) >> wrote: >>> >>> Dear Mirja (and Ben), >>> >>> Many thanks for reviewing this document! >>> >>>> - >>>> - >>>> COMMENT: >>>> - >>>> - >>>> >>>> I agree with one of Ben's comments in that I'm not certain about the >>>> intended document status as PS. I think Informational might be more >>>> appropriate, as it rather describes an approach based on existing >>>> protocols than a normative protocol specification. >>>
Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-minimal-fragment-12: (with COMMENT)
Hi Pascal, Informational documents can also have normative text. If that was the criteria the decision was made on, the decisions should be re-evaluated. Mirja > On 4. Mar 2020, at 13:25, Pascal Thubert (pthubert) > wrote: > > Dear Mirja (and Ben), > > Many thanks for reviewing this document! > >> -- >> COMMENT: >> -- >> >> I agree with one of Ben's comments in that I'm not certain about the intended >> document status as PS. I think Informational might be more appropriate, as it >> rather describes an approach based on existing protocols than a normative >> protocol specification. > > This was long debated and went back and forth. We finally settled for STD > track after the review by Dave Thaler. > There's actually generic normative text in this document, in the forwarding > fragments section. > Any spec that provides a fragment forwarding technique should normatively > refer this and abide by that text. > > As an example, but there's more: > " > Since the datagram_tag is uniquely associated to the source Link- > Layer address of the fragment, the forwarding node MUST assign a new > datagram_tag from its own namespace for the next hop and rewrite the > fragment header of each fragment with that datagram_tag. > > When a forwarding node receives a fragment other than a first > fragment, it MUST look up state based on the source Link-Layer > address and the datagram_tag in the received fragment. If no such > state is found, the fragment MUST be dropped; otherwise the fragment > MUST be forwarded using the information in the state found. > " > > This is why we ended up with STD track. You found reviewing > https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery that there's > already a std track with a normative reference to this. > > Many thanks again! > > Pascal ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)
Hi Younghwan, Thanks! Please see below for point 3. > On 7. Jun 2019, at 03:35, 최영환 wrote: > > Hello Mirja and all, > > Thanks for your valuable reviews. > Please find my answers inline. > > BRs, > Younghwan Choi > >> -Original Message- >> From: Mirja Kühlewind via Datatracker >> Sent: Wednesday, March 13, 2019 10:49 PM >> To: The IESG >> Cc: draft-ietf-6lo-...@ietf.org; Carles Gomez ; >> Samita Chakrabarti ; 6lo-cha...@ietf.org; >> carle...@entel.upc.edu; 6lo@ietf.org >> Subject: Mirja Kühlewind's No Objection on draft-ietf-6lo-nfc-13: (with >> COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-6lo-nfc-13: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/ >> >> >> >> -- >> COMMENT: >> -- >> >> 1) I agree with Benjamin's discuss point on sec 3.4: there seems to be a >> mismatch between the text and the figure that needs to be resolved or >> clarified before publication. > > I agreed with Benjamin's point, so I will change the paragraph for > clarification. Please refer to my answers for Benjamin's DISCUSS and COMMENTS. > >> >> 2)Use of normative language doesn't always seem quite appropriate, >> especially SHALL. Benjamin already identified some cases in section 3.3. >> >> Here is an additional one in sec 4.1: >> "The adaptation layer for IPv6 over NFC SHALL support neighbor >> discovery, stateless address auto-configuration, header compression, >> and fragmentation & reassembly." > > I will get rid of the "SHALL". > >> >> Also this MAY in sec 5.2: >> "In an isolated NFC-enabled device network, >> when two or more LRs MAY be connected with each other, and then they >> are acting like routers, the 6LR MUST ensure address collisions do >> not occur." >> >> Please also check other occurrences. > > I will change "MAY" with "are". And I will check the others as well. > >> >> 3) I would have expected to see some discussion about the ability to >> potentially connect devices over an IP-gateway device to the Internet that >> were previously not designed to be connected to the Internet. However, >> maybe that's asked too much as that is certainly something that needs to >> be addressed by either a higher layer or the device system architecture as >> a whole. >> > > I don’t get your point about 3), but IPv6 over NFC is a just protocol and can > be used for every NFC-enabled device (including IP-Gateway devices), which > are connected to the Internet. If the assumption is that any IPv6 over NFC is only send in secured networks, maybe the higher layers are not further protected, and therefore a gateway should probably not just take the IPv6 packet and send it out in the Internet as is. I wonder if that is something that should be further discussed or at least mentioned in the security consideration section. Mirja ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)
Sounds good to me. > Am 28.02.2017 um 23:55 schrieb Kerry Lynn : > > Hi Mirja, > > Thanks for your review. Comments inline... > > On Wed, Nov 30, 2016 at 11:07 AM, Mirja Kuehlewind > wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-6lo-6lobac-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > -- > COMMENT: > -- > > 1) Agree with Ben that normative wording should not be used if it just > summarizes things that are specified in a different doc. > > See if my response to Ben is satisfactory for you. > > 2) Section 5: "A node implementing [RFC7400] MUST probe its peers for GHC > support before applying GHC." How? > > I deleted this sentence. RFC 7400 discusses it. > > 3) Just to make sure I get the security section right: MS/TP networks are > not connected to the Internet or use something like a gateway. Maybe make > this point more clear: basically say that the reason to use IPv6 is NOT > that you want to send these packets eventually directly to the Internet! > > Not sure I wanted to create the impression that MS/TP nodes will never > connect to the Internet. I reworked Sections 6 & 12 to make clear that > different methods of forming addresses are recommended depending on > the scope of the address. > > Thanks again, Kerry > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-dect-ule-08: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6lo-dect-ule-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/ -- COMMENT: -- One tiny comment: This sounds like a summary of what's specified in TS102.939-1 and therefore should probably not use normative language in this doc: "In DECT protocol domain the PP SHALL specify the <> in a service-change (other) message before sending a service-change (resume) message as defined in [TS102.939-1]. The <> SHALL define the ULE Application Protocol Identifier to 0x06 and the MTU size to 1280 octets or larger. The FP sends a service-change-accept (resume) that MUST contain a valid paging descriptor. The PP MUST be pageable. Following this, transmission of IPv6 packets can start." ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Mirja Kühlewind's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6lo-6lobac-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ -- COMMENT: -- 1) Agree with Ben that normative wording should not be used if it just summarizes things that are specified in a different doc. 2) Section 5: "A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC." How? 3) Just to make sure I get the security section right: MS/TP networks are not connected to the Internet or use something like a gateway. Maybe make this point more clear: basically say that the reason to use IPv6 is NOT that you want to send these packets eventually directly to the Internet! ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
