Subject: Re: [PANRG] David Oran's Yes on draft-irtf-panrg-what-not-to-do-14: (with COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 Dec 2020 20:00:42 -0600

Hi, David,

(Adding PANRG, since I'd like for the RG to be aware of your helpful
comments and my responses)

Thanks for the careful read. I have thoughts, inline below.

Best,

Spencer

On Tue, Dec 22, 2020 at 9:58 AM David Oran via Datatracker <[email-masked]>
wrote:

> David Oran has entered the following ballot position for
> draft-irtf-panrg-what-not-to-do-14: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm in favor of publishing this, and the comments below don't need to be
> considered before advancing the document. I gave it a detailed reading and
> if
> we decide to work on a -bis version in the future here are a few things I
> think
> could be improved upon:
>
> - Things that measure paths and things that constrain paths are kind of
> mixed
> together. While you need to measure paths in order to have reasonable
> mechanisms to select/constrain them, the reverse is not necessarily the
> case.
>

Interesting. Let me chew on this a bit.

- There's a minor mis-characterization of INTServ as requiring state in
> every
> intermediary. Intserv can work through a node that doesn't keep state, as
> long
> as that node is extremely unlikely to be a bottleneck.

ACK. I'll make this clearer.

> Also, it would be
> helpful here and in some other places to tease apart things that require
> data
> plane state only, control plane state only, or both.
>

I need to re-read the draft - it went into RG Last Call just over a year
ago - but I think this is useful for me to think about.

> - Associated with path awareness is the question of whether a mechanism
> supports admission control of endpoints/applications. One of the
> motivations of
> INTServ and a number of other architectures (e.g. DETnet) is the ability to
> "say no" to an application based on resource availability on a path
> *before*
> the application tries to inject traffic onto that path and discovers the
> path
> does not have the capacity to sustain enough utility to meet the
> application's
> minimum needs. The question of whether admission control is needed comes up
> over and over again, but we have learned a few useful lessons that, while
> covered implicitly in some of the lessons learned of the document, might be
> explained explicitly:
>     * We have gained a lot of experience with application-based adaptation
>     since the days where applications just injected traffic in-elastically
> unto
>     the network. Such adaptations seem to work well enough that admission
>     control is of less value to these applications * There are end-to-end
>     measurement techniques that can steer traffic at layer 7 rather than
> layer
>     3 (CDNs, multi-CDNs like Conviva, etc.) * Often, applications don't
>     actually know enough about their admission control threshold to be
> able to
>     ask accurately for the resources they need and attempts to help them
>     haven't gotten anywhere (e.g. the multi-TSPEC additions to RSVP to
> attempt
>     to mirror codec selection by applications).
>

Thanks for suggesting text. I'll start with this, for sure.

> - There's no discussion of multicast in the document. Not a serious
> omission,
> but perhaps useful to add in the future.

We were relying on people to contribute examples, and no one did, but it's
worth considering whether we could have included anything about multicast.

I don't have a super-detailed understanding of multicast, but I've seen a
lot more written about maintaining multicast trees than about optimizing
trees by taking path characteristics into consideration.

If we can identify one or two examples, I'd be happy to figure out what to
do with them, but at a minimum, I think the current draft should explicitly
point out that none of the examples involve multicast.

> - Some of the history explained here could shed light on more fundamental
> aspects of the IP protocol architecture. If path awareness continues to be
> of
> interest to the community, understanding what is "baked into IP" and what
> is
> not could be helpful. One deep example is path asymmetry. Many things about
> path awareness (and QoS as well) are made vastly more difficult when paths
> are
> asymmetric. One could define ways to add symmetry constraints to IP rather
> than
> try over and over to work in its absence. There may be some useful insight
> here
> as well from the choice by the CCNx and NDN protocol architectures to
> enforce
> path symmetry: path awareness and path selection become substantially
> easier to
> attain.
>

I like the idea of looking at this in more detail - not only for your
example of asymmetry, but for your previous mention that we've tended to
try to avoid admission control, rather than rely on it.

I'd suggest that this should be a separate document, but I think it's worth
working on, for sure.

Again, thanks for your insights, and I'll work through a revision over the
next couple of weeks.

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 29 Dec 2020 15:37:45 -0600

Hi, David,

Just following up on your ballot comments here.

I've submitted a -15, that

I apologize for the number of diffs in
https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-what-not-to-do-15, but
what you should see is

   - I added a new section, 5, on Future Work, that relies heavily on
   observations you made in your ballot.
   - (This renumbered all the sections from what was section 5 on, so
   that's what most of the diffs are),
   - I updated what is now section 6.2 on IntServ, based on your
   observation that IntServ doesn't break completely if non-bottleneck routers
   don't support IntServ,
   - I added references for what's now in Section 5, and
   - I added you to the acknowledgements section - thanks again for your
   help and wisdom.

If you see anything I got wrong, please let me know.

If the research group members see anything to object to, please let me know.

I think that addresses all the comments outstanding.

I'll let the shepherds confirm that, of course.

Best yearend holidays to all!

Spencer

On Sat, Dec 26, 2020 at 8:00 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> On Tue, Dec 22, 2020 at 9:58 AM David Oran via Datatracker <
> [email-masked]> wrote:
>
>> considered before advancing the document. I gave it a detailed reading
>> and if
>>     since the days where applications just injected traffic
>> in-elastically unto
>> aspects of the IP protocol architecture. If path awareness continues to
>> be of
>> path awareness (and QoS as well) are made vastly more difficult when
>> paths are
>> asymmetric. One could define ways to add symmetry constraints to IP
>> rather than
>> try over and over to work in its absence. There may be some useful
>> insight here
> I'd suggest that this should be a separate document, but I think it's
> worth working on, for sure.
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 30 Dec 2020 10:10:02 -0500

> Just following up on your ballot comments here.
While I did say that I thought the existing text was fine for 
publication without my adding material to reflect my comments, I do 
appreciate the care with which you dealt with them, and the 
acknowledgement of them contributing to the future work section you 
added.

So, consider my comments nicely dealt with!

…and happy new year! Perhaps I can thank you in person at some point 
in 2021.

> I've submitted a -15, that

DaveO