Subject: Re: [PANRG] RG Last Call for draft-irtf-panrg-what-not-to-do-05

From: Theresa Enghardt <[email-masked]>
Date: Mon, 6 Jan 2020 13:22:12 +0100

Dear PANRG,

I recently gave this document a thorough read from my perspective as a
researcher of Path Aware technologies.

As I have not been around yet for the development of most of the
technologies listed in this document, I find its "lessons learned" to be
quite a valuable resource.
So, again, thank you for writing it!

To make this document even more accessible to researchers wanting to
learn from it, I have a few comments, see below.

Once these are addressed, I think this document is ready for publication.

Section 1:

Maybe it's worth adding one paragraph with a short definition or
description of what we mean by Path Aware technologies here, e.g., at
the very beginning?

Section 2.1:

What exactly does "Overcoming Entropy" mean? To me, entropy sounds like
this is about the ecosystem of deployed hardware/software being too
diverse or chaotic, so the benefits of the proposed Path Aware solution
do not outweigh the costs. But the rest of the paragraph also sounds
like this is about trying to solve a non-problem, or a problem with
insufficient motivation to solve it? Or is this both?
Maybe I just fail to capture all the nuances of the colloquial American
English expression as a non-native English speaker. ;)
I think adding a clarifying sentence to make the lesson more explicit
would help here.

Section 2.3:

This is about multiple possible solutions to the same problem, right,
one being end-to-end and another being Path Aware? So is Path Aware
necessarily not end-to-end? This goes back to comment on considering to
add a definition of Path Aware technologies to Section 1.

Section 2.7:

What is the relationship between "Keeping Traffic on Router Fast-paths"
and "Router Alert Options (RAO)"? Does RAO mean that the traffic cannot
be fast-path anymore? This seems to be implicitly said here, but I think
adding a sentence to make this explicit would help.

Section 2.9:

The section heading says "Intermediate Devices Trusting Endpoints", but
the text is about endpoints not relying on signals from intermediate
devices. This seems odd to me.
Maybe the headings of 2.8 and 2.9 should be swapped, because 2.8 appears
to be about operators of intermediate devices not using signals from
endpoints and 2.9 seems to be about endpoints not using signals from
intermediate devices?

Nit: "long term, term trust relatioship" -> duplicate "term"

Section 2.11:

Does "Providing a new feature/signal [does not mean that that the
feature/signal will be used]" refer to the problem that a stack
implements the possibility to set, e.g., an additional variable, but
then an application using the stack fails to set this variable? Or is
this about the stack setting the variable, and then an application would
have to interpret this variable, but fails to do so? Or both?
I guess here, in the first sentence, I am confused about what exactly is
meant by "provide", "use", or "utilize" a signal - implementing support
for setting a variable, actually setting the variable, or interpreting
the variable which has been previously set by someone else?

I think another example of this problem is Section 5.8.

Section 3:

When categorizing the lessons as "invariant", "variable", or "dragons",
I guess "dragons" is kept vague on purpose. Still, I'm wondering if we
could make this a bit more clear - Does "dragons" mean that we don't
know if the lesson is invariant or variable, or that we don't want to
comment on it, or that the problem is open-ended?
Maybe adding one more sentence here makes sense, especially for
non-native English speakers who might not be familiar with the phrase
"here be dragons".

In the last paragraph, I fail to parse the following sentence: "[TAPS]
will justify consideration of the current state of play for Path Aware
Networking proposals for some time to come" - Does that mean that we
think TAPS might change this lesson, thus, the lesson should be
re-evaluated after some time?

Section 5.3:

"[…] In these cases, a sender cannot easily determine an appropriate
initial sending rate, given the lack of information about the path"
What does "these" refer to here? Isn't this a general problem?

"One challenge is synchronization of information between different
packets […]"
What does synchronization mean here? That a router signals for two flows
that there's capacity?

Section 5.5:

"[…] somehow TCP could be signaled when that link returned to service"
Should this be "somehow TCP could signal when the link returned to service"?

Section 5.6:

"work began on a protocol that would provide the same benefits for
multihomed IPv6 sites […]"
Same benefits as IPv4 multihomed sites? The previous sentence talks
about problems, not benefits.

Is the sentence starting with "In addition, the usual concerns about
firewalls […]" missing a verb?

Section 5.7.1:

"One reason for the non-deployment of NSIS is the usage of the IPv4 and IPv6
   Router Alert Option (RAO) to allow for an efficient interception of
   those path-coupled signaling messages"
As someone not familiar with RAO, this sentence reads a bit confusing to
me - it was not deployed because it is efficient?

"End-to-end signaling approaches were considered problematic […]"
So is NSIS an end-to-end signaling approach? I thought Path Aware
technologies were not end-to-end (Section 2.3)? To me, end-to-end by
default means "end host to end host", without considering any
intermediate device, but I think this paragraph means something else by it.
I think adding a sentence explaining who the "end to end" is here would
help.

Best,
Theresa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Jan 2020 18:08:15 -0600

Hi, Theresa,

Thank you for your help with this document! Please see comments inline
below.

Best,

Spencer

> description of what we mean by Path Aware technologies here, e.g., at

Done.

> I think adding a clarifying sentence to make the lesson more explicit

The intention was to say "insufficient motivation". I changed this term to
be "Justifying Deployment", which I hope is clearer.

> add a definition of Path Aware technologies to Section 1.

In addition to the new section 1.2, I tried to make this section clearer.

> adding a sentence to make this explicit would help.

Good point. "Everybody" knows this, but enough people didn't know it to
justify the "Spherical Routers" session at IETF 104. (
https://datatracker.ietf.org/group/wgtlgo/meetings/). I added some details
here.

> endpoints and 2.9 seems to be about endpoints not using signals from

Well, THAT was embarrassing ... swapped now!

> Nit: "long term, term trust relatioship" -> duplicate "term"

Thanks for spotting this.

> the variable which has been previously set by someone else?

I wrote the text with a specific problem in mind, but you are pointing to
it being more general. I tried to make this clearer.

> non-native English speakers who might not be familiar with the phrase

Rephrased without dragons. :-)

> re-evaluated after some time?

Yeah, I failed to parse it, too. A long time ago, it made sense to me.
Rephrased.

> What does "these" refer to here? Isn't this a general problem?

I took Michael's suggestion to the limit - I deleted the reference to DCCP
QuickStart, because it wasn't adding any information to the lesson. But too
your larger point ...

I agree this is a general problem, but the contribution I was analyzing was
a single mechanism exhibiting the problem. I rephrased without "in these
cases" - I don't think it added anything, but seemed to be TRYING to add
something.

> What does synchronization mean here? That a router signals for two flows

I took Michael's suggestion here as well.

> Should this be "somehow TCP could signal when the link returned to

This is about waking up the TCP that's been sitting quietly, because
retransmitting over a known-out-of-service-interface doesn't help.

The problem was that I was using the passive voice. Now it's "somehow
something along the path could signal TCP", which is about as much clarity
as we had in initial discussions about TRIGTRAN :D ...

> about problems, not benefits.

This was phrased badly. Changed to "provide multihoming for IPv6 sites".

> me - it was not deployed because it is efficient?

This is the same issue you tagged in 2.7, which isn't surprising because
2.7 is a lesson that references this contribution. Added details here, too.

> I think adding a sentence explaining who the "end to end" is here would

This contribution expanded beyond NSIS a bit here - contributions in
Section 5 should be focused on a specific technology. I was able to replace
most occurrences of "end-to-end" referring to NSIS in this section, which
avoided the problem.

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 10 Jan 2020 16:54:54 +0100

Hi,

Thanks for the replies, Spencer and Michael, and thanks for the revision.
This addresses all my comments.

Best,
Theresa

On 10.01.20 01:08, Spencer Dawkins at IETF wrote:
> On Mon, Jan 6, 2020 at 6:22 AM Theresa Enghardt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear PANRG,
>
> The intention was to say "insufficient motivation". I changed this
> term to be "Justifying Deployment", which I hope is clearer. 
>  
>
>     Section 2.3:
>
> Good point. "Everybody" knows this, but enough people didn't know it
> to justify the "Spherical Routers" session at IETF 104.
> (https://datatracker.ietf.org/group/wgtlgo/meetings/). I added some
> details here. 
>  
>
>     Section 2.9:
>
> I wrote the text with a specific problem in mind, but you are pointing
> to it being more general. I tried to make this clearer. 
>  
>
>
> I took Michael's suggestion to the limit - I deleted the reference to
> DCCP QuickStart, because it wasn't adding any information to the
> lesson. But too your larger point ...
>
> I agree this is a general problem, but the contribution I was
> analyzing was a single mechanism exhibiting the problem. I rephrased
> without "in these cases" - I don't think it added anything, but seemed
> to be TRYING to add something. 
>  
>
>
> something along the path could signal TCP", which is about as much
> clarity as we had in initial discussions about TRIGTRAN :D ...
>  
>
>     Section 5.6:
>
> This is the same issue you tagged in 2.7, which isn't surprising
> because 2.7 is a lesson that references this contribution. Added
> details here, too. 
>  
>
>
> Section 5 should be focused on a specific technology. I was able to
> replace most occurrences of "end-to-end" referring to NSIS in this
> section, which avoided the problem. 
>  
>
>     Best,
>     Theresa
>
>