Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

Mirja Kuehlewind <ietf@kuehlewind.net> Sun, 22 March 2020 18:09 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016B53A0973; Sun, 22 Mar 2020 11:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89huVrvBE2_E; Sun, 22 Mar 2020 11:09:50 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D43A0970; Sun, 22 Mar 2020 11:09:50 -0700 (PDT)
Received: from p200300dee7239a007961e4d1ac1a08c3.dip0.t-ipconnect.de ([2003:de:e723:9a00:7961:e4d1:ac1a:8c3]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jG52f-0006BL-DG; Sun, 22 Mar 2020 19:09:45 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: =?utf-8?q?=3CMN2PR11MB35651B894A5B29455B4033A8D8F50=40MN2PR11MB?= =?utf-8?q?3565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Sun, 22 Mar 2020 19:09:44 +0100
Cc: "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, The IESG <iesg@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-fragment-recovery@ietf.org" <draft-ietf-6lo-fragment-recovery@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Martin Duke <martin.h.duke@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <69FA92C7-0F93-4A20-B2C8-D3799375C2A0@kuehlewind.net>
References: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB356540107CC4FC7F9CB9F412D8E30=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C7D77F80D-9D2C-4AF7-AB7E-4EDF58A9258A=40kuehlewind=2Enet=3E_=3C?= =?utf-8?q?MN2PR11MB3565C75A4707268047E1F90ED8F40=40MN2PR11MB3565=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= <9823A19B-CA7D-47D1-92FE-8AA436240BD4@kuehlewind.net> <C3771F28-264D-4D0D-9864-D40711EBA0FD@cisco.com> =?utf-8?q?=3CD3F4ECB5-3E1D-48EF-83D9-71F3F14629C4=40kuehlewind=2Enet=3E_=3C?= =?utf-8?q?MN2PR11MB3565B3E9A05CF5D10D125407D8F50=40MN2PR11MB3565=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C14C773BF-09B3-43A9-893C-8CC8A03E7159=40kuehlewind=2Enet=3E_=3C?= =?utf-8?q?MN2PR11MB35651B894A5B29455B4033A8D8F50=40MN2PR11MB3565=2Enamprd11?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?=
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1584900590;f8107004;
X-HE-SMSGID: 1jG52f-0006BL-DG
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/pYdmcONxqNNRQXP9MoQnLSfbf58>
Subject: Re: [6lo] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-6?= =?utf-8?q?lo-fragment-recovery-13=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Mar 2020 18:09:53 -0000

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) <pthubert=40cisco.com@dmarc.ietf.org> 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 <ietf@kuehlewind.net>
>> Sent: vendredi 20 mars 2020 18:12
>> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>> Cc: 6lo-chairs@ietf.org; The IESG <iesg@ietf.org>rg>; 6lo@ietf.org; draft-ietf-6lo-
>> fragment-recovery@ietf.org; Carles Gomez <carlesgo@entel.upc.edu>du>; Martin
>> Duke <martin.h.duke@gmail.com>om>; Benjamin Kaduk <kaduk@mit.edu>
>> 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=40cisco.com@dmarc.ietf.org> 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
>>> 
>