Re: [PANRG] [LB] Questions about draft-irtf-panrg-what-not-to-do-19.txt

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

Hi, Lynne,

On Thu, May 6, 2021 at 5:33 PM Lynne Bartholomew <[e-mail]>
wrote:

> Hi, Spencer.
>
> Many thanks for your prompt reply and helpful text!  We have updated this
> document per your notes below.
>
> Regarding our question 14) and your reply:
>
> >> 14) Section 6.5:  This sentence does not parse, and we
> >> cannot follow its meaning.  Are some words missing after
> >> "single signal"?  Please clarify "the end-to-end flow control
> >> mechanism has only a single signal, the loss of a segment, and TCP
> >> implementations since the late 1980s have ..."
> >>
> >> Original:
> >>  TCP [RFC0793] has a well-known weakness - the end-to-end flow control
> >>  mechanism has only a single signal, the loss of a segment, and TCP
> >>  implementations since the late 1980s have interpreted the loss of a
> >>  segment as evidence that the path between two endpoints may have
> >>  become congested enough to exhaust buffers on intermediate hops, so
> >>  that the TCP sender should "back off" - reduce its sending rate until
> >>  it knows that its segments are now being delivered without loss
> >>  [RFC5681].
> >>
> > Breaking into more sentences ... I'd suggest
> >
> >  TCP [RFC0793] has a well-known weakness - the end-to-end flow control
> >  mechanism has only a single signal, the loss of a segment, TCP
> >  implementations since the late 1980s have interpreted the loss of a
> >  segment as evidence that the path between two endpoints may have
> >  become congested enough to exhaust buffers on intermediate hops, so
> >  that the TCP sender should "back off" - reduce its sending rate until
> >  it knows that its segments are now being delivered without loss
> >  [RFC5681].
>
>
> We found one sentence in the suggested, which made it a run-on.  Would the
> following work (realizing that we might be incorrectly guessing that the
> single signal could result in loss of a segment)?
>
>  TCP [RFC0793] has a well-known weakness -- the end-to-end flow control
>  mechanism has only a single signal, which could result in loss of a
>  segment.  TCP implementations since the late 1980s have interpreted
>  the loss of a segment as evidence that the path between two endpoints
>  may have become congested enough to exhaust buffers on intermediate
>  hops, so that the TCP sender should "back off" - reduce its sending
>  rate until it knows that its segments are now being delivered without
>  loss [RFC5681].
>

It's actually that the signal is the result of the loss of a segment (or
its acknowledgement). Perhaps this is better?

TCP [RFC0793] has a well-known weakness -- the end-to-end flow
control mechanism has only a single signal, the loss of a segment, detected
when no acknowledgement for the lost segment is received at the sender.
There are multiple reasons why the sender might not have received an
acknowledgement for the segment. To name several, the segment could have
been trapped in a routing loop, or could have been
 damaged in transmission and failed checksum verification at the receiver,
or could have been lost because some intermediate device discarded  the
packet, or any of these things could have happened to the
 acknowledgement on the way back from the receiver to the sender.
 TCP implementations since the late 1980s have made the "safe" decision,
and have interpreted
 the loss of a segment as evidence that the path between two endpoints
 may have become congested enough to exhaust buffers on intermediate
 hops, so that the TCP sender should "back off" - reduce its sending
 rate until it knows that its segments are now being delivered without
 loss [RFC5681].



>
> = = = = =
>
> Regarding our question 23) and your reply:
>
> >> 23) Section 6.9.1:  Is the "at least" necessary in this
> >> sentence?  It looks odd in the context of "All three" in the next
> >> sentence.
> >>
> >> Original:
> >>  There are at least three sub-stories - ECN deployment in clients, ECN
> >>  deployment in routers, and AQM deployment in operational networks.
> >>  All three sub-stories mattered.
> >>
> > This text was discussed in a fairly intense (for PANRG) email thread. I
> was trying to avoid saying that I knew what all of the substories were (and
> trying to get agreement on that). Let me try again.
> >
> > ECN deployment relied on three factors - support in client
> implementations, support in router implementations, and in deployment
> decisions in operational networks.
>
> We were not sure whether "support" applied to two or three of the
> factors.  We updated as follows (two of the three).  Please let us know if
> "and in deployment" should be "and support in deployment":
>
>  ECN deployment relied on three factors -- support in client
>  implementations, support in router implementations, and deployment
>  decisions in operational networks.
>

Much better. Thanks.


>
> = = = = =
>
> Regarding our question 25) and your reply:  Thank you for that info.!
> I'll check with Sandy Ginoza on this one and will let you know what I find
> out.  (Would like to think that most people will just click the slide links
> on the page and won't download the PPT file, but as you point out, it would
> be good if what is now the "PPT Version" link pointed to something that is
> easier to use.)
>
> = = = = =
>
> Regarding our question 29) and your reply:
>
> >> Thank you for chasing this down. Cool URLs don't change, right?
>
> Thanks for this note!  Actually, credit goes to Chris Smiley in the RPC
> for finding this during her formatting pass.
>
> = = = = =
>
> Regarding our question 33)b) and experimental / Experimental, and your
> reply:
>
> >> If that suggestion isn't helpful, perhaps
> >>
> >>    Quick-Start [RFC4782] is defined in an Experimental RFC, and is a
> TCP extension that leverages
> >>    support from the routers on the path to determine an allowed initial
> >>    sending rate for a path through the Internet, either at the start of
> >>    data transfers or after idle periods.
> >>
> >> Do either of those work for the RFC Editor?
>
> This is very helpful; thank you!  We used your "perhaps" suggestion.
>
>
> And regarding the rest of the 33)b) items:
>
> >>  global IPv6 routing table / IPv6 global routing table
> >>    (We see "global IPv4 routing table" as well.)
> >>
> >> The latter form is fine with me.
>
> Just to confirm -- we went with "IPv6 global routing table" and "IPv4
> global routing table".  Please let us know if we misunderstood.
>
> >>
> >>  invariant / Invariant (Do the lowercased instances refer to the
> >>    category type (in which case they should be initial-capitalized),
> >>    or is the word "invariant" used generally?)
> >>


Did I skip over this one? My bad.

In each case, "invariant" is referring to one of the three categories used
in Table 1. I'd make them all uppercase, which I think is what you did.


> >>  path / Path (e.g., 'definition of a path', 'current
> >>    definition of "Path"')
> >>
> >> The latter form is fine with me.
> >>
> >>  path aware / Path Aware / path-aware (where used generally, e.g.,
> >>    "many Path Aware techniques*", "some path aware techniques*",
> >>    "earliest Path-Aware Networking technique", "path-aware protocol",
> >>    "your path aware technology", "your Path Aware technology")
> >>
> >>    * (We also see the variations "Path-Aware techniques" and
> >>       "Path-Aware Techniques" (title of Section 2.2), "Path-Aware
> >>       techniques" and "Path Aware Technique"; we suggest choosing one
> >>       form for consistency of style.)
> >>
> >> Spencer question: I'm not sure what your suggestion is here - is this
> saying that there are this many variations in the document and you don't
> have a suggestion?
> >>
> >>  path-aware networking / path aware networking /
> >>    Path Aware Networking / Path Aware networking /
> >>    Path-Aware Networking (in text, where used generally)
> >>
> >> Spencer question: I'm not sure what your suggestion is here - is this
> saying that there are this many variations in the document and you don't
> have a suggestion?
>
> Yes, and apologies for not being more clear on these.  We normally defer
> to author preference, but if you would like us to make suggestions and the
> terms above are considered to be proper terms / terms of art, we're happy
> to.  We propose
>
> * Invariant
> * Path Aware (initial capitals, no hyphen) (Also, per your note further
> below, we have updated to use "Path Awareness")
> * Path Aware networking (other than when referring to the Research Group,
> e.g., "Path Aware networking techniques")
> * path (where used generally, e.g., "path-coupled", "fast path",
> "alternate paths")
> * technique (in running text, i.e., we would wind up with "Path Aware
> techniques" and "Path Aware networking techniques")
>

This all works for me.

It looks like the vast majority of "techniques" omit "networking". You
could reasonably remove "networking" unless it's a reference to the
research group. All of the techniques are networking techniques, so being
inconsistent isn't helpful.


>
> >>
> >>  path awareness / Path Awareness (e.g., 'the definition of path
> >>    awareness', 'The current definition of "Path Awareness"',
> >>    'think about path awareness', 'benefit of Path Awareness')
> >>
> >>   The latter form is fine with me.
> >>
> >>  the research group / the Research Group
> >>
> >> Perfect.
>
>
> Thank you again for your help and patience!
>

Oh, thank YOU.

Best,

Spencer


>
> RFC Editor/
>