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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Theresa,

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

Best,

Spencer

On Mon, Jan 6, 2020 at 6:22 AM Theresa Enghardt <[e-mail]> wrote:

> 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?
>

Done.


> 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.
>

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


> 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.
>

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


> 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.
>

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:
>
> 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?
>

Well, THAT was embarrassing ... swapped now!


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

Thanks for spotting this.


>
> 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 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 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".
>

Rephrased without 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?
>

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


>
> 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?
>

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.


>
> "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?
>

I took Michael's suggestion here as well.


>
> 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"?
>

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 ...


> 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.
>

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


> 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?
>

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.


>
> "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.
>

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.


> Best,
> Theresa
>
>