Minutes IETF102: panrg
minutes-102-panrg-00

PANRG Agenda IETF 102
When: 11:50 - 13:20 GMT-4, Friday 20 July 2018
Where: Laurier, Fairmont The Queen Elizabeth, Montreal
Chairs: Jen Linkova and Brian Trammell
Minutes Taker: Tommy Pauly
Jabber Scribe: Theresa Enghardt

11:50
5m
Welcome, Note Well, Agenda
Chairs

Research group is now official (no longer just proposed!)
We have two documents now, and we will discuss charter going forward

11:55
10m
RG Charter Discussion
Chairs

After last meeting in London, had a few comments around the charter. No
fundamental changes. Need to update the charter now that no longer proposed.

Chris: (comment on preamble) Are privacy considerations considered in scope
Brian: Yes, but we haven't written it down, and it should go in the scope list.
Please propose a bullet point. Mirja: (as individual) Also add assurance about
what path was traversed. Brian: Kind of hidden in "trust and risk models", but
should be teased apart.

Interactions with MP transports (MPTCP, QUIC, TSVWG); congestion control
(ICCRG); and routing (LISP, SPRING) Borje: Also relate to ALTO? Brian: List is
inclusive but not limited to. Please send a bullet point to the list!

Brian: We need to not schedule against routing area people, and get them here
and involved.

Expect to be 2-3 meetings per year, colocated with IETF

12:00
15m
draft-irtf-panrg-questions
B. Trammell

Open questions:
    1. How are path properties defined and represented?
    2. How do endpoints get access to trustworthy path properties?
    3. How can endpoints select paths to use for traffic in a way that can be
    trusted by both the network and the endpoints? 4. How can interfaces to the
    tranport and application layers support the use of path awareness? 5. How
    should transport layer protocols be redesigned to work over path aware
    layers? 6. How is path awareness different when applied to tunnels and
    overlays? 7. How can a path aware network be operated in an internetwork 8.
    How can incentives of operators be aligned to realize this vision?

    4-5 questions belongs in TAPS.
    7-8 questions are deployment and political questions

We will begin to answers from the top, in increasing difficulty levels

We have some information already about the information that is bound to paths

Looking for authors!

Theresa: I've been doing research on characteristics of access networks and
paths, and I would like to collaborate. Joeli: If you have a device with
multiple uplinks that it's aware of, you want it to choose the paths, right?
Brian: That's the first step, which we have already in many ways (wi-fi vs
cellular). Where I want to get is to be able to do the same kind of multipath
stuff when I'm only singlely connected. You could build this with many VPN
tunnels off of your local link, you could emulate this. Joeli: Is there a
vision that every end host would have this information about every path and
host it wants to contact? Isn't that a lot of overhead? Brian: Yes, but agreed
that the naive way to do this is not scalable. You could argue that Tor is like
an anonymity focused path aware network. Brian: We need to add a note on the
previous work in this space that had tapered off due to improved scalability
(name??)

Spencer: Would the new documents contain answers?
Brian: Yes, that's the hope

Spencer: How much of the TAPS related work is still research?
Brian: So TAPS is building a standards track interface for protocol stack
agility (generalization of happy eyeballs). We know how to do that pretty well.
For (4) for interfaces for selection are not too hard. Stuart Card: We should
not decide too quickly which properties are appropriate to expose. There may be
internet complacency issues. Brian: Yes. Question 2 and 3 should focus on the
internet case, but also explore other cases. Tommy Pauly: Regarding Question 4
and 5. 4 matches TAPS, there may be parts we don't cover there yet, where we
could explore research here. Question 5, I wonder if that's less TAPS and more
MPTCP and MP-QUIC. In these groups we haven't explored the ramification of
having more links. Brian: Yes, we will need to have some thinking about how to
make more than two links be scalable (see laurant's previous talk) Joeli: Any
thoughts on dynamic or asymmetrical paths? Brian: Oftentimes asymmetric is
written off as too hard; we should add this to the document. Mirja: I'm
wondering if we need to start at the top of the list is actually correct, based
on hearing this discussion. The first question (what is path property) is a
pre-req, but the other don't have to be in order. We could focus on those
questions that are NOT related to another working group if we want; or we could
focus on the items more closely related to practical work in the IETF. Brian: I
would start by documenting what has been done before, and what we've learned,
and then see how we can not fall into those traps. I see this as a new way to
frame very old questions. Mirja: For question (2) it's very related to alto.
That's only one solution, but it is standardized. Lin Han: Do you encourage new
architectures? Because current multipath is not deployable. Brian: This isn't
about picking up an existing path architecture and trying to make it happen; we
can look at those after first principles, but the concepts are more important.
Gabriel: Do you want to also make this document a collection of references to
previous work? See MIF and v6ops/PvDs Brian: I think this document is just the
questions, the references should be for other docs.

12:15
30m
draft-dawkins-panrg-what-not-to-do
S. Dawkins

"Bestiary of Roads Not Taken"! This document is an outcome of the first meeting
at IETF99, to track the lessons from failed attempts. Was research even if we
tried to do it in IETF. Major update -01 just submitted before IETF 102. Added
pointers to IAB documents, and a summary of lessons learned from IntServ Quick
Start TCP, TRIGTRAN, etc.

Lessons:
    - Benefits of adoption must be big enough
    - Middleboxes are only helpful when trusted
    - Benefits must justify deployment
    - Per connection state is hard
    - Increasing distance is hard
    - Applications don't know what to tell transports

Meant to be useful to PANRG and IETF. IETF will likely make same mistakes
again; how can this provide guidance? This can also help guide PANRG work.

Brian: I thought this was more useful than I thought it would be—it's
blindingly obvious stuff, but we have data, which is great.

Questions: are there more PAN lessons to document? Are there more places to
look for lessons?

Is additional work on this doc valuable? Should it be adopted by the RG?

Theresa: I read document, found it very interesting. Want more content, so yes
to both questions. Brian: how many people read? (several) Jen: I support
adopting this document

Spencer: I should point out that -01 is a lot better than -00, and most of the
reason for that is that people sent material I didn't write. My inbox is always
open ...

Hum for adoption:
    Loud
Hum for not adopting:
    Silent

Brian: Let's submit the next version as a -irtf draft.

12:45
10m
Requirement of User-network interface for Path-aware networking
L. Han

What are the challenges of path aware networking? Lack of architecture that can
be accepted or deployed soon. Hard to deploy widely. Only deployment for MPTCP
is WiFi+LTE or DSL+LTE Can we support PAN in current internet? Can we have
multipath support with only one interface? Think yes for some scenarios. Can
have one operator network, or operator working with on content provider, etc.
Proposing creating new protcol between user and operator; but don't want too
complicated of headers. Proposing new dataplane to replace existing stack.

Dirk: Regarding UNI; the point of the internet was to not have the limited
interface for the endpoint, and I'm not sure we really want to be segmenting
where the network ends as mentioned here. Lin: Also have network-to-network
Dirk: That raises more questions, and really deviates from the Internet model
and has many traps

Brian: I agree with what Dirk said about the internet end-to-end model, and
adding back UNI and NNI, we blow that model up. What you're not showing here,
however, is are all the tunnels to implement this. It's all encapsulation. I'd
like to take this idea and get the good parts out. I do like the multiple data
plane idea. Asking the network for what you want is probably not a bad idea. ?:
You only trust the service provider due to previous agreement Alia: For
thinking about this MPLS or segment routing, because a segment is used as an
arbitrary identifier, you may think of that as a kind of abstraction of how you
communicate what you want to tu policies; with well-known segment IDs that can
be looked up to translate into more path data. As brian says, it is tunnels all
the way down. Lin: We are only planning to use existing protocols for this.
Alia: We can't intend this for just one service provider. Alia: You're thinking
of tunnels as things that take time to set up Lin: Yes Alia: You don't have to
have set up time, it doesn't have to look like an interface. You just say how
you want to go, and off you go.

12:55
25m
Open Mic Discussion
Chairs

Tommy: I was thinking of PvDs. Would it be useful to have a distinction between
truly different provisioning domains (different services offered by network)
and paths that differ in terms of quality/latency but are equivalent in terms
of service they provide? Brian: We have topological properties and then this
other fuzzy box. Is this a new question for the questions document? Tommy: I
can try to formulate this as a question.

Gabrial: What is the relation between PANRG and Network Slicing, especially
regarding Question 7 and 8? Brian: This seems more about a single operator
scenario. It gets much harder and more interesting in a multi operator scenario.