Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

Mirja Kuehlewind <ietf@kuehlewind.net> Thu, 05 December 2019 11:53 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4112120108; Thu, 5 Dec 2019 03:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 BGzGcnhS4L36; Thu, 5 Dec 2019 03:53:23 -0800 (PST)
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 1FF541200F8; Thu, 5 Dec 2019 03:53:23 -0800 (PST)
Received: from 200116b82cc7ef0034996fbfb45dc371.dip.versatel-1u1.de ([2001:16b8:2cc7:ef00:3499:6fbf:b45d:c371]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1icph9-0007KD-UR; Thu, 05 Dec 2019 12:53:19 +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: <B3A7583A-B4DE-4CE5-A74D-0D4C22FABD83@kuehlewind.net>
Date: Thu, 5 Dec 2019 12:53:19 +0100
Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs <babel-chairs@ietf.org>, Babel at IETF <babel@ietf.org>, The IESG <iesg@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Martin Vigoureux <martin.vigoureux@nokia.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <160C625D-866B-40D3-8549-7E714F8F8E9B@kuehlewind.net>
References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> <87imomknn0.wl-jch@irif.fr> <B3A7583A-B4DE-4CE5-A74D-0D4C22FABD83@kuehlewind.net>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1575546803;9af5b230;
X-HE-SMSGID: 1icph9-0007KD-UR
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/J4_w96OjdP4adjZ_LDXCsWfl1L8>
Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2019 11:53:25 -0000

Hi again,

And one more comment regarding pacing: Again I will not block on this issue anymore, however, as you have a babel implementation I would assume it would be easy to add more details on how pacing is done in your implementation in the draft (at least in the appendix).

Mirja



> On 5. Dec 2019, at 12:50, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
> Hi Juliusz, hi all,
> 
> I took another look at the updated RFC and I have to say I’m still concerned about the default values (which is also an issue that was also raised by Alvaro) and the appendix B.
> 
> You know added another case:
> 
> "The following values are recommended in a network where reconvergence
>   within 2 seconds after a mobility event is desired:
> 
>      Multicast Hello Interval: 0.5 seconds.
> 
>      Unicast Hello Interval: infinite (no Unicast Hellos are sent).
> 
>      Link cost, IHU Interval, Update Interval, IHU Hold Time, and Route
>      Expiry Time: computed as in the first case above.
> 
>      Request Timeout: initially 0.5 seconds, doubled every time a
>      request is resent, up to a maximum of three times.
> 
>      Urgent timeout: 0.2 seconds.
> 
>      Source GC time: 3 minutes.”
> 
> These value are much lower than in the first case and can easily leads to signification congestion, however, you don’t say anything appropriate about when those value might be used or should be avoided. What appendix B does is simply given some sample calculation about what the expected reconvergence time is based on the selected values but it does not give any guidance about which network conditions would bear which setup, nor does it talk about negative implication of selecting lower values.
> 
> I still think that it is important to provide default values as part of the normative specification. For me finding such default value (maybe with more discussions about in which network scenarios these vales makes sense and when it might be useful to consider different values) was part of the experiment with babel and if you are not able to address these questions, babel is not ready for PS. 
> 
> Alternatively you can check the values in RFC8085 again and see if these are acceptable values for most scenarios. Values in that RFC are lightly lower than the first example (e.g. 3 secs interval and 1 sec timeout) but quite a bit larger than the new example you introduced (without further guidance on usage of the values).
> 
> Especially in section 3.8.2.1. regarding the Request Timeout it is not sufficient to only point to the appendix. Please also note that there are actually two values here that need suitable default values, the time-out itself and the number of retries.
> 
> Thanks!
> Mirja
> 
> 
>> On 18. Oct 2019, at 18:46, Juliusz Chroboczek <jch@irif.fr> wrote:
>> 
>> Dear Mirja,
>> 
>>> 1) Let's move appendix B into the body of the document. I think these
>>> are important information for an implementer and therefore it needs more
>>> attention.
>> 
>> I am sorry, but I disagree.  The original document that I submitted for
>> IETF review back in 2009 had the structure that you suggest, but the
>> reviewer (Joel Halpern) convinced me to a adopt the following structure:
>> 
>> - the body of the document describes the main algorithm, the parts that
>>   are required to enforce the strong guarantees that the protocol makes
>>   about lack of loops and forward progress;
>> - the appendices describe algorithms that have been shown to be useful
>>   over some link layers but that might need to be tweaked when Babel is
>>   run over new, exciting link layers.
>> 
>> Since Joel did a good job convincing me, it will take some work to
>> convince me otherwise.
>> 
>>> 2) Maybe you can add something like: [...]  I’m sure you have a better
>>> wording. My intention is simply to add another warning, to think
>>> carefully instead of just pick some default.
>> 
>> I don't necessarily agree, but I've done as you request.
>> 
>>>>> Thanks. I was also hoping that you could make any recommendation on how
>>>>> to implement that e.g. a fixed delay of a certain (default) value or
>>>>> based on some other knowledge. [...]
>> 
>>>> You do realise it's a very high bar you're setting?
>> 
>> [...]
>> 
>>> I wasn’t looking for a tutorial for pacing but rather a reference to
>>> add. E.g. just naming different approaches for how to implement pacing
>>> and provide a reference would be a good thing I think. However, I will
>>> not block on this one thing. Your choice.
>> 
>> I am not aware of any good reference on packet pacing that covers IEEE
>> 802.11 multicast (an important usecase for Babel).  After checking some
>> papers and scratching my head for a long time, I've just added another
>> sentence to Section 3.1; I'm afraid I'm not competent to do anything more.
>> 
>>> I just wondering why you don’t call them default value rather then
>>> examples. I think specifying default value normatively would be more
>>> clear and is what we usually do in specs. However, I think in this case
>>> it will not make a huge practical difference.
>> 
>> Great, let's agree that we're not in full agreement, then.
>> 
>> -- Juliusz
>> 
>> 
>> 
>