Re: [PANRG] Is it useful for PANRG to produce a design goals draft?

[Theresa Enghardt <[e-mail]>]

Dear PANRG,

Some initial thoughts on this inline:

On 16.01.20 07:05, Spencer Dawkins at IETF wrote:
> On Sun, Jan 12, 2020 at 11:36 AM Spencer Dawkins at IETF
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>       * Theresa also asked (in her review comments) for a statement
>         about what Path Aware Networking was (or was not). I added a
>         new subsection in -06 that was expanding on the first sentence
>         in our charter, and that satisfied Theresa's comment, but
>         she's an RG document editor, so people who haven't spent
>         multiple years in PANRG would likely benefit from more
>         explanation about the kinds of things people are currently
>         trying to do with Path Aware Networking.
>
I noticed that it's not easy to find a clear problem statement for
PANRG, and that maybe makes it harder for people to understand our goals.

The parts that do exist are scattered across the charter and different
drafts.

For example, in the charter, the closest thing to a problem statement I
could find was "bringing path awareness to transport and application
layer protocols". The motivation is that because of "increased diversity
in access networks, paths can no longer be assumed to be "invisible,
homogenous, singular, with dynamics solely determined by the
connectivity of the endpoints and the Internet control plan".

Now while the motivation makes sense to me, I think the problem
statement is a bit vague: Why is it a problem if paths are different and
what do we want to achieve by knowing about and selecting a path? Better
security, whatever that means in a specific context? Better performance,
and for whom? Or something else? I think there's a diversity of possible
use cases here.


The Questions draft states as the definition (or goal?) of a path-aware
internetworking architecture that "endpoints have the ability to select
or influence the path through the network used by any given packet, and
the network and transport layers explicitly expose information about the
path or paths available between two endpoints to those endpoints and the
applications running on them, so that they can make this selection."

Also, the Questions draft implicitly contains at least some design
goals. For example, it mentions trustworthiness in multiple places, it
mentions scalability, it mentions deployment requirements. However, it
already indicates that there might not be a perfect solution, but
trade-offs, and the right answer may depend on context. (At least that's
what I'm reading into it.)

In addition, I guess some of the lessons in What-not-to-do can also be
rephrased as design goals.

While this is all quite general, the Path Properties draft contains more
specific use cases, such as Path Selection for security or performance
improvements, to motivate what properties it provides as examples. (Note
that us authors are currently in the process of reworking this section
though.)


>       * I think this would be extremely helpful in focusing the
>         research group on our goals (this is also related to, but not
>         the same as, our research problems, which also can focus us).
>
I agree that some focus would be useful. I'm just not sure if a generic
"PANRG Design Goals" document is the right thing to focus on.


>       * https://datatracker.ietf.org/doc/rfc6227/?include_text=1 is
>         only 8 pages long, and that covered all of Internet routing. I
>         don't think a document about our current goals for Path Aware
>         Networking would have to be any longer. Do others disagree?
>       * https://datatracker.ietf.org/doc/rfc6227/history/ says it took
>         about four years from -00 to approval as an RFC, but I don't
>         think PANRG needs four years to produce a design goals
>         document, for a variety of reasons. Do others disagree?
>
I think we could probably write something along these lines based on the
Questions draft and the What-not-to-do draft. I guess if we stick to the
generic problem statement, we pretty much agree what we want and this
will be quick and easy: Of course we want scalable, we want trustworthy,
we want deployable, etc.

However:

I think the actual trade-offs in these Design Goals, like some of the
answers to the questions in the Questions draft, depend on the specific
problem you are trying to solve. If our problem statement is too generic
or vague, I'm not sure we can produce much more useful content than we
already have in the existing drafts.

However, maybe it'd be interesting to write a draft on specific problem
statements within the scope of PANRG and then provide answers to some
design questions (like "how to achieve scalability" or "how scalable
does this need to be", "how to solve trust", ...) for this specific context.

Perhaps this could be the "What-to-do-instead" draft that somebody
mentioned some PANRG sessions ago?

But do we actually have any successfully deployed path-aware techniques
that we can point to and analyze? Or do we have to write science
fiction, which could also be interesting?

Just my 2 cents. Thanks for reading!


Best,
Theresa