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

Mirja Kuehlewind <ietf@kuehlewind.net> Fri, 20 March 2020 17:12 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 DFE0C3A0C7C; Fri, 20 Mar 2020 10:12:17 -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=unavailable 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 gC5stSKf9z5g; Fri, 20 Mar 2020 10:12:16 -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 E4A8C3A0C71; Fri, 20 Mar 2020 10:11: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 1jFLBR-0000Q5-3e; Fri, 20 Mar 2020 18:11: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: <MN2PR11MB3565B3E9A05CF5D10D125407D8F50@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Fri, 20 Mar 2020 18:11:39 +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: <14C773BF-09B3-43A9-893C-8CC8A03E7159@kuehlewind.net>
References: <158212059997.17584.9409485384556514167.idtracker@ietfa.amsl.com> <MN2PR11MB356540107CC4FC7F9CB9F412D8E30@MN2PR11MB3565.namprd11.prod.outlook.com><7D77F80D-9D2C-4AF7-AB7E-4EDF58A9258A@kuehlewind.net> <MN2PR11MB3565C75A4707268047E1F90ED8F40@MN2PR11MB3565.namprd11.prod.outlook.com> <9823A19B-CA7D-47D1-92FE-8AA436240BD4@kuehlewind.net> <C3771F28-264D-4D0D-9864-D40711EBA0FD@cisco.com> <D3F4ECB5-3E1D-48EF-83D9-71F3F14629C4@kuehlewind.net> <MN2PR11MB3565B3E9A05CF5D10D125407D8F50@MN2PR11MB3565.namprd11.prod.outlook.com>
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;1584724336;c59c4e06;
X-HE-SMSGID: 1jFLBR-0000Q5-3e
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Sdq8V8mmfkLzdH2eeFQcHPPOoqo>
Subject: Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)
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: Fri, 20 Mar 2020 17:12:18 -0000

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
>