Hello Colin Many thanks for your review! I published -12 to make it easier for you to review the changes I'm suggesting based on your review, The delta is visible here: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-12 Let's see below for the discussion: > The document updates RFC 4944 to provide a selective fragment recovery > scheme for 6LoWPAN networks. It builds on draft-ietf-6lo-minimal-fragment > and on the virtual reassembly buffers described in the expired draft draft-ietf- > lwig-6lowpan-virtual-reassembly. > > The mechanism is generally well described and clearly specified. My main > concern is that the performance of the mechanism will heavily depend on the > values selected for the parameters described in Section 7.1, but there is little > guidance provided on how to set these parameters for particular link layers. > The draft would be improved if it could point to some more detailed guidance > on parameter choice for particualar scenarios, or to further discussion on how > to estimate parameters. Providing values would be neat but not really possible. On the one hand we can add text to indicate why. On the other, we can certainly give more guidance than the close to zero that's in the doc today. - For the former, I suggest to add an introduction to section 7: " 7. Management Considerations This specification extends "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" [I-D.ietf-6lo-minimal-fragment] and requires the same parameters in the receiver and on intermediate nodes. There is no new parameter as echoing ECN is always on. This parameters typically include the reassembly time-out at the receiver and an inactivity clean-up timer on the intermediate nodes, and the number of messages that can be processed in parallel in all nodes. The configuration settings introduced by this specification only apply to the sender, which is in full control of the transmission. LLNs vary a lot in size (there can be thousands of nodes in a mesh), in speed (from 10Kbps to several Mbps at the PHY layer), in traffic density, and in optimizations that are desired (e.g., the selection of a RPL [RFC6550] Objective Function [RFC6552] impacts the shape of the routing graph). For that reason, only a very generic guidance can be given on the settings of the sender and on whether complex algorithms are needed to perform flow control or estimate the round-trip time. To cover the most complex use cases, this specification enables the sender to vary the fragment size, the window size and the inter-frame gap, based on the amount of losses, the observed variations of the round- trip time and the setting of the ECN bit. " For the latter, Section 7.1 would become: " 7.1. Protocol Parameters The management system SHOULD be capable of providing the parameters listed in this section. An implementation must control the rate at which it sends packets over a same path to allow the next hop to forward a packet before it gets the next. In a wireless network that uses a same frequency along a path, more time must be inserted to avoid hidden terminal issues between fragments. This is controlled by the following parameter: inter-frame gap: Indicates a minimum amount of time between transmissions. All packets to a same destination, and in particular fragments, may be subject to receive while transmitting and hidden terminal collisions with the next or the previous transmission as the fragments progress along a same path. The inter-frame gap protects the propagation of one transmission before the next one is triggered and creates a duty cycle that controls the ratio of air time and memory in intermediate nodes that a particular datagram will use. An implementation should consider the generic recommendations from the IETF in the matter of flow control and rate management in [RFC5033]. To control the flow, an implementation may use a dynamic value of the window size (Window_Size), adapt the fragment size (Fragment_Size) and insert an inter-frame gap that is longer than necessary. In a large network where node contend for the bandwidth, a larger Fragment_Size consumes less bandwidth but also reduces the fluidity and incurs higher chances of loss in transmission. This is controlled by the following parameters: MinFragmentSize: The MinFragmentSize is the minimum value for the Fragment_Size. OptFragmentSize: The OptFragmentSize is the value for the Fragment_Size that the sender should use to start with. It is more than or equal to MinFragmentSize. It is less than or equal to MaxFragmentSize. On the first fragment, it must enable the expansion of the IPv6 addresses and of the Hop Limit field within MTU. On all fragments, it is a balance between the expected fluidity and the overhead of MAC and 6LoWPAN headers. For a small MTU, the idea is to keep it close to the maximum, whereas for larger MTUs, it might makes sense to keep it short enough, so that the duty cycle of the transmitter is bounded, e.g., to transmit at least 10 frames per second. MaxFragmentSize: The MaxFragmentSize is the maximum value for the Fragment_Size. It MUST be lower than the minimum MTU along the path. A large value augments the chances of buffer bloat and transmission loss. The value MUST be less than 512 if the unit that is defined for the PHY layer is the octet. MinWindowSize: The minimum value of Window_Size that the sender can use. OptWindowSize: The OptWindowSize is the value for the Window_Size that the sender should use to start with. It is more than or equal to MinWindowSize. It is less than or equal to MaxWindowSize. The Window_Size should be maintained below the number of hops in the path of the fragment to avoid stacking fragments at the bottleneck on the path. If an inter-frame gap is used to avoid interference between fragments then the Window_Size should be at most in the order of the estimation of the trip time divided by the inter-frame gap. MaxWindowSize: The maximum value of Window_Size that the sender can use. The value MUST be less than 32. An implementation may perform its estimate of the RTO or use a configured one. The ARQ process is controlled by the following parameters: MinARQTimeOut: The maximum amount of time a node should wait for an RFRAG Acknowledgment before it takes a next action. OptARQTimeOut: The starting point of the value of the RTO, that is amount of time that a sender should wait for an RFRAG Acknowledgment before it takes a next action. It is more than or equal to MinARQTimeOut. It is less than or equal to MaxARQTimeOut. MaxARQTimeOut: The maximum amount of time a node should wait for an RFRAG Acknowledgment before it takes a next action. It must cover the longest expected round-trip time, and be several times less than the time-out that covers the recomposition buffer at the receiver, which is typically in the order of the minute. See Appendix C for recommendations on computing the round-trip time. MaxFragRetries: The maximum number of retries for a particular fragment. MaxDatagramRetries: The maximum number of retries from scratch for a particular datagram. An implementation may be capable to perform flow control based on ECN, more in Appendix C. This is controlled by the following parameter: UseECN: Indicates whether the sender should react to ECN. The sender may react to ECN by varying the Window_Size between MinWindowSize and MaxWindowSize, varying the Fragment_Size between MinFragmentSize and MaxFragmentSize and/or by increasing the inter-frame gap. " > > Nits: > Section 1, 3rd paragraph, typo: "[RFC4944] as no selective recovery and the > whole datagram fails when" -> "has no"? Fixed > > Section 7.1: Description of OptFragmentSize refers to MinFragmentSize > Fixed Again, many thanks Colin. Please let me know if the propose changes work for you. All the best, Pascal -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
