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

[David Schinazi <[e-mail]>]

Hi Mirja,

Thank you for taking another look at the document.

I hope we can get this resolved quickly, as we have
already waited for 49 days for your last email.
I understand that you are busy but I did want to point
out that this is adding stress on the authors.

First, it appears that your review is still treating Babel like
a protocol running over UDP on the Internet. It is not.
Babel only operates point-to-point using IPv6 link-local
addresses, and the congestion properties of 802.11
are very different from the ones of an end-to-end
transport running over the wide area.

Second, the Babel working group prides itself with strict
adherence to the running code principle. Features or
recommendations do not make it into a Babel spec
unless they have been implemented and tested.

If we were discussing a transport protocol, I would
agree with your review. RFC 8085 is a great
document, but it wasn't written with link-local routing
protocols in mind.

As transport AD, it is your responsibility to ensure
new IETF protocols do not bring about another
congestion collapse, and I think that's critical.
I want to really thank you for the hours you spend
reviewing documents to ensure that goal. But I don't
think all of that guidance applies here.

Could I kindly ask you to take another look at your
review in this lens, and please let us know in what
way you think this draft has real-world issues?

We'd really like to make forward progress here, if
the only issue is default values, I'm not sure this is
worth causing delays on, as we haven't seen these
cause problems when implementing the protocol.

Thanks,
David


On Thu, Dec 5, 2019 at 3:53 AM Mirja Kuehlewind <[e-mail]> wrote:

> 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 <[e-mail]> 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 <[e-mail]> 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
> >>
> >>
> >>
> >
>
>