From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D78B23B2A4 for ; Mon, 26 Jun 2023 09:54:55 -0400 (EDT) Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-668711086f4so2140837b3a.1 for ; Mon, 26 Jun 2023 06:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687787694; x=1690379694; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=SrONgGSqv88WB1QI1bPY/oWTRyfX3U3v9h10bGP3Md0=; b=d99EmHUkFwK4iMy8ugGsjRo7DU9TBzGDeID6bqr9t/sEokK5T10c+9IlVVP0gU/H3k MHPiFsT3uHKv/PzqDKJooDRnUyVU30CXAVXs276ijhOwtzvbUXgFdCn1uRh3+YEOKe+V bctDLTC+QZ5atN/PfHa4Qm5hV04JZ+1Q+ON425X7+SdGN/IsPi6UX+zDmQCThd64awxF 9MeQUbOFExzAkfqgqNttvHIKXvhxMxD9UaKr3MMg1OdxYVtJSsrRF0XigKkfPolgJn9f eQo5LAf64VYBM1UCKzUujb9a4uTcY3zzokG5RY6VMpk3QcN5ohvc98oQYsotJIzZf76S 8OFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687787694; x=1690379694; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SrONgGSqv88WB1QI1bPY/oWTRyfX3U3v9h10bGP3Md0=; b=AKBzAdD+052z4gctwfvJ50WpHr7w2iqlUNf4a1z2cP79bOE3+yE/R1cvRpvwssCUNK eHY1XOgTs7NKBOKss2nagaAtXWqmHZ7VskiJHCktVglMVkBh2cd8RWL2RDpNsNoFTp8u 68G9C8hcdqn1Ff1o05knudZX92uKtYpvgSc9FEJ0G48KFUQfM4ZLiEloCeSV4hJz1MzF MW9kzuwHEd5KHceYDVDX4YT/1JSuSDeLy/2f5XL0f161gWhtHaWlHVSURLqaZGxc/h/m yxiwcNMi5UJjB5SkmWtRpKXZcRWDoHpFyQ+qRWqZvJsED3HdN4FOL/Yx2JTmw8zTtniJ A2Vg== X-Gm-Message-State: AC+VfDwCTWIb0UK6xt6LgeUignuNkvlauqZYBgyyIC5qNrwWAF0viTDC NZ7MOnjprz6g2lnimtpNCqVL2Y5//ffX1J8hCvEbnxINy3p/fw== X-Google-Smtp-Source: ACHHUZ6o8E6XClJ7Ia++M5HyENBnJWH4cXFWjBAhA8JL2rVTeV15/pjesAoFqjx9LFj7cOeg5fuqHIdIKxO3KGUnn40= X-Received: by 2002:a17:90b:484:b0:261:326d:99e8 with SMTP id bh4-20020a17090b048400b00261326d99e8mr13791648pjb.2.1687787694184; Mon, 26 Jun 2023 06:54:54 -0700 (PDT) MIME-Version: 1.0 References: <168739863699.25774.12064454751487007083@ietfa.amsl.com> <87jzvwxny8.wl-jch@irif.fr> <8C314BC3-BBDF-44E8-A4BC-DB1E5C839348@steffenvogel.de> In-Reply-To: <8C314BC3-BBDF-44E8-A4BC-DB1E5C839348@steffenvogel.de> From: Dave Taht Date: Mon, 26 Jun 2023 07:54:42 -0600 Message-ID: To: cerowrt-devel Content-Type: multipart/alternative; boundary="000000000000f7dc9605ff08b1e0" Subject: [Cerowrt-devel] Fwd: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2023 13:54:56 -0000 --000000000000f7dc9605ff08b1e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: Steffen Vogel Date: Thu, Jun 22, 2023, 1:46 AM Subject: Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt To: Juliusz Chroboczek Cc: Hi Juliusz, Its great to see that the RTT draft has been reactivated! I already started to support its first version it in my Go implementation which I am Planning to use for routing in VPN overlay networks. I=E2=80=99ve given the updated draft a first read. Here are my comments so = far. Sorry if that=E2=80=99s not the correct approach for submitting a review. I am a newcomer to the whole RFC process. # Section 1 + 3: Negative feedback loop The introductory section says: > Since this causes a negative feedback loop, special care is needed to ensure > that the resulting network is reasonably stable. This statement is repeated in Section 3: > Second, using the RTT signal for route selection gives rise to a negative feedback loop: [...] However, in my understanding a control loop is usually qualified as negativ= e if it dampens systems responses and hence promotes stability. This is also in line with the definition on Wikipedia: > Negative feedback (or balancing feedback) occurs when some function of th= e > output of a system, process, or mechanism is fed back in a manner that tends > to reduce the fluctuations in the output, whether caused by changes in th= e > input or by other disturbances. Source: https://en.wikipedia.org/wiki/Negative_feedback Should this working be replaced with "positive feedback"? # Section 2.1: Clock properties The draft permits clocks to be stepped to support reboots of nodes. However, I think it would wise to recommend the use monotonic system clocks where available. E.g. CLOCK_MONOTONIC vs CLOCK_REALTIME on Linux systems. Otherwise, time adjustments by NTP clients or leap-seconds might impede the protocol operation if the clocks are stepped by a seconds or fractions thereof. # Section 2.1: Clock origin Maybe replace the term clock "origin" with "epoch"? Here are a few definitions which I think match the intended meaning in this context: - "In computing, an epoch is a date and time from which a computer measures system time." (https://en.wikipedia.org/wiki/Epoch_(computing)) - "In a computing context, an epoch is the date and time relative to which a computer's clock and timestamp values are determined" (https://www.techtarget.com/searchdatacenter/definition/epoch) - "an instant of time or a date selected as a point of reference" (Merriam Webster) - "a precise date to which information, such as coordinates, relating to a celestial body is referred (astrology)" (Collins Dictionary) # Section 5: Unit of timestamp fields Section 5 defines the 32-bit timestamp as follows: > Timestamps are encoded as 32-bit unsigned integers, expressed in units of one microsecond, counting from an arbitrary origin. Timestamps wrap around every 4295 seconds, or slightly more than one hour. While, section 2.3 defines the timestamp as follows: > Timestamp values are a count of milliseconds stored as a 32-bit unsigned integer; thus, they wrap around every 50 days or so. I think having a millisecond resolution of the timestamps is a bit too coarse for some use cases. I would recommend to go with microseconds as defined in Section 5. # Section 9: Hyperlink in reference I am a newcomer to writing RFCs, but I was wondering why the URL of the rerence [DELAY-BASED] is not put into <>. In the html-ized view of the IETF datatracker, the link is not converted to a hyperlink. # Typos - Section 2.1: - Old: "This extesion extends every etry in the Neighbour Table with the following data" - New: "This **extension** extends every **entry** in the Neighbour Table with the following data - Section 2.2: - Old: Additionally, it ocasionally sends a set of IHU messages, at most one per neighbour [...]. - New: Additionally, it **occasionally** sends a set of IHU messages, at most one per neighbour [...]. - Section 2.2: - Old: This is illustrated in the followsing sequence diagram - New: This is illustrated in the **following** sequence diagram - Section 2.3: - Old: Similary, the node compares the Hello's timestamp with the Receive Timestamp recorded in the Neighbour Table - New: **Similarly**, the node compares the Hello's timestamp with the Receive Timestamp recorded in the Neighbour Table Please let me know if I can support the process of getting this draft into a standard in any other way =F0=9F=98=8A Best regards, Steffen *From: *babel on behalf of Donald Eastlake < d3e3e3@gmail.com> *Date: *Thursday, 22. June 2023 at 04:10 *To: *Juliusz Chroboczek *Cc: * *Subject: *Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt Hi Juliusz, Thanks for reactivating this draft ! Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Wed, Jun 21, 2023 at 9:53=E2=80=AFPM Juliusz Chroboczek wr= ote: > Title : Delay-based Metric Extension for the Babel Routing Protocol > Authors : Baptiste Jonglez > Juliusz Chroboczek > Filename : draft-ietf-babel-rtt-extension-01.txt > Pages : 12 > Date : 2023-06-21 I've done some serious rewriting: the document is split into two parts, one which is written in normative language, and the second which is more clearly experimental. It's in a somewhat rough state, I'll try to find the time to do some proof-reading and submit a -02. However, I feel it's ready for reviewing by the WG, so please do so. Thanks, -- Juliusz _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel _______________________________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel --000000000000f7dc9605ff08b1e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ---------
From: Steffen Vogel <post=3D40stef= fenvogel.de@dmarc.ietf.org>
Date: Thu, Jun 22, 2023, 1:46 = AM
Subject: Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.tx= t
To: Juliusz Chroboczek <jch@irif.fr<= /a>>
Cc: <babel@ietf.org>= ;


=

Hi Juliusz,

=C2=A0

Its great to see that the = RTT draft has been reactivated!

I already started to support its first version it = in my Go implementation which I am

Planning to use for routing in VPN overlay netw= orks.

<= u>=C2=A0

I= =E2=80=99ve given the updated draft a first read. Here are my comments so f= ar.

Sor= ry if that=E2=80=99s not the correct approach for submitting a review.

I am a newc= omer to the whole RFC process.

=C2=A0

=C2=A0

=C2=A0

# Section 1 + 3: Negative feedback loop

=C2=A0

The introductory s= ection says:

=C2=A0

> Since this causes a negative feedback loop, special care is need= ed to ensure

> that the resulting network is reasonably stable.

=C2=A0

This statement is repe= ated in Section 3:

=C2=A0

> Second, using the RTT signal for route selection gives ris= e to a negative feedback loop: [...]

=C2=A0

However, in my understanding a control loop i= s usually qualified as negative

if it dampens systems responses and hence promotes= stability.

=C2=A0

This is also in line with the definition on Wikipedia:

=C2=A0

> Negative feedback= (or balancing feedback) occurs when some function of the

> output of a system,= process, or mechanism is fed back in a manner that tends

> to reduce the fluct= uations in the output, whether caused by changes in the

> input or by other dis= turbances.

=C2=A0

Source: https://en.wikipedia.org/wiki/Negative_fe= edback

=C2=A0

Should this working be replaced with "positive feedback"?<= /u>

=C2= =A0

# Section = 2.1: Clock properties

=C2=A0

The draft permits clocks to be stepped to support reboots of= nodes.

However, I think it would wise to recommend the use monotonic system clock= s

where= available. E.g. CLOCK_MONOTONIC vs CLOCK_REALTIME on Linux systems.=

=C2=A0=

Otherwise, ti= me adjustments by NTP clients or leap-seconds might

impede the protocol operation = if the clocks are stepped by a seconds or fractions thereof.<= /span>

=C2=A0<= /span>

# Section 2.1: Clock = origin

= =C2=A0

= Maybe replace the term clock "origin" with "epoch"?<= /u>

=C2= =A0

Here are a= few definitions which I think match the intended meaning in this context:<= u>

= =C2=A0

- "= ;In computing, an epoch is a date and time from which a computer measures s= ystem time."

=C2=A0=C2=A0 (https://en.wikipedia.org/wik= i/Epoch_(computing))

=C2=A0

- "In a computing context, an epoch is the date and = time relative to which a computer's clock and timestamp values are dete= rmined"

=C2=A0=C2=A0 (https://www.techtarg= et.com/searchdatacenter/definition/epoch)

=C2=A0

- "an instant of time or a date= selected as a point of reference"

=C2=A0=C2=A0 (Merriam Webster)

=C2=A0

- "a precise = date to which information, such as coordinates, relating to a celestial bod= y is referred (astrology)"

=C2=A0=C2=A0 (Collins Dictionary)

=C2=A0

# Section 5: Unit of ti= mestamp fields

=C2=A0

Section 5 defines the 32-bit timestamp as follows:

=C2=A0

> Timestamps are enc= oded as 32-bit unsigned integers, expressed in units of one microsecond, co= unting from an arbitrary origin. Timestamps wrap around every 4295 seconds,= or slightly more than one hour.

=C2=A0

While, section 2.3 defines the timestamp as follo= ws:

= =C2=A0

>= ; Timestamp values are a count of milliseconds stored as a 32-bit unsigned = integer; thus, they wrap around every 50 days or so.

=C2=A0

I think having a millisecond = resolution of the timestamps is a bit too coarse for some use cases.=

I would recom= mend to go with microseconds as defined in Section 5.<= /p>

=C2=A0<= /p>

# Section 9: Hyperlink in re= ference

=C2=A0

I am a newcomer to writing RFCs, but I was wondering why the URL of=

the rerence [= DELAY-BASED] is not put into <>.

In the html-ized view of the IETF datatrack= er, the link is not converted to

a hyperlink.

=C2=A0

# Typos

=C2=A0

- Section 2.1:

=C2=A0 - Old: "This extesion = extends every etry in the Neighbour Table with the following data"<= /u>

=C2=A0 - N= ew: "This **extension** extends every **entry** in the Neighbour Table= with the following data

=C2=A0

- Section 2.2:

=C2=A0- Old: Additionally, it ocasionally sends = a set of IHU messages, at most one per neighbour [...].

=C2=A0 - New: Additionally= , it **occasionally** sends a set of IHU messages, at most one per neighbou= r [...].

=C2=A0

- Section 2.2:

=C2=A0 - Old: This is illustrated in the followsing sequence dia= gram

= =C2=A0 - New: This is illustrated in the **following** sequence diagram<= /u>

=C2= =A0

- Section = 2.3:

= =C2=A0 - Old: Similary, the node compares the Hello's timestamp with th= e Receive Timestamp recorded in the Neighbour Table

=C2=A0 - New: **Similarly**, t= he node compares the Hello's timestamp with the Receive Timestamp recor= ded in the Neighbour Table

<= span lang=3D"EN-US">=C2=A0

<= span lang=3D"EN-US">Please let me know if I can support the process of gett= ing this draft into a standard in any other way =F0=9F=98=8A

=C2=A0

Best regards,

Steffen

<= span>=C2=A0

From: babel <babel-bounces@ietf.org> on= behalf of Donald Eastlake <d3e3e3@gmail.com>
Date: Thu= rsday, 22. June 2023 at 04:10
To: Juliusz Chroboczek <jch@irif.fr>
Cc: <babel@ietf.org>
Subject: Re: [babel] I= -D Action: draft-ietf-babel-rtt-extension-01.txt

=C2=A0

Hi Juliusz,

= =C2=A0

Thanks for reactivat= ing this draft !


Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cel= l)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail= .com

=C2=A0<= u>

=C2=A0

<= div>

On Wed, Jun 21, 2023 at 9:53=E2=80=AFPM Juliusz = Chroboczek <jch@irif.fr> wrote:

>=C2=A0 =C2=A0= Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Delay-based Metric Extensi= on for the Babel Routing Protocol
>=C2=A0 =C2=A0 Authors=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: Baptiste Jonglez
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Juliusz Chroboczek
>= =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-babel-rtt-ex= tension-01.txt
>=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: 12
>=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2023-06-21

I've done some serious rewriting: the document = is split into two parts,
one which is written in normative language, and= the second which is more
clearly experimental.

It's in a som= ewhat rough state, I'll try to find the time to do some
proof-readin= g and submit a -02.=C2=A0 However, I feel it's ready for reviewing
b= y the WG, so please do so.

Thanks,

-- Juliusz

________= _______________________________________
babel mailing list
babel@ietf.org=
https://www.ietf.org/mailman/listinfo/babel

_________________= ______________________________ babel mailing list babel@ietf.org https://www.ietf.org/mailman/listinfo/babel

<= /div>
_______________________________________________
babel mailing list
babe= l@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000f7dc9605ff08b1e0--