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

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

Theresa,

On Mon, Jan 20, 2020 at 10:01 AM Theresa Enghardt <[e-mail]>
wrote:

> Dear PANRG,
>
> Some initial thoughts on this inline:
>

Thanks for thinking!

I'm top-posting, because I'm not sure what I'm typing maps onto specific
text you typed (so inline isn't a great plan), but I definitely am reacting
to your comments below.

I could have done a better job of saying this in my note, but I'd guess a
PAN Design Goals draft wouldn't be as cohesive as
https://datatracker.ietf.org/doc/rfc6227/?include_text=1, precisely because
(as you said) we aren't all working on the same problems with the same
constraints. I think it would be OK to say "these are design goals that
people try to achieve", but not "these are design goals that you must try
to achieve to work in PANRG". So, agreed where you said things like that.

I'd guess doing a table of contents/skeleton would tell us a lot about
whether this could be a good idea. I'd be happy to work on that, and would
love to work on that with someone else. Anyone interested?

I think we can steal (some) stuff out of what-not-to-do and
research-questions, but it's good to remember that what-not-to-do isn't
THAT broad a survey (all the protocols listed passed through some version
of the IETF), and some of the contributions go back into the 1970s and
1980s, so we might be able to mine those drafts for a starting point, but
we could also ask "what are the design goals we should be working toward,
in research now?"

You asked "has anybody gotten this right yet?". What-not-to-do excluded
that question by definition, but perhaps we should be asking it now, and
looking outside the IETF experience (and if we had design goals, we'd know
whether someone's $MyCoolIdea actually was the kind of path aware
networking we are researching, which would help separate sheep from goats).

I absolutely agree that problem statements would be technique-specific - so
there wouldn't be a "PAN Problem Statement" draft. I think you're combining
two things - a clear definition of Path Aware Networking - which interacts
with our design goals - and a clear problem statement (or set of problem
statements), which interacts with our research questions. I agree that we
could use both.

I really like your invocation of "what-to-do-instead". People have been
asking for that, and we're headed the right direction towards being able to
say something intelligent.

Thanks again for your thoughts.

Best,

Spencer


> 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]> 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
> _______________________________________________
> Panrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/panrg
>