Minutes IETF104: panrg
minutes-104-panrg-00

PANRG Agenda IETF 104
When: 09:00 - 10:30 UTC+1, Thu 28 March 2019
Where: Congress Hall 3, Hilton Prague, Prague
Chairs: Jen Linkova and Brian Trammell
Minutes Taker: Tommy Pauly, Dave Plonka
Jabber Scribe:Aaron Falk

===================
Brian is not remote - despite the agenda slides' claim
===================

Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-02

Spencer Dawkins

Update on -01 version of the doc, want to determine next steps for the document
Gorry provided text about ST, ICMP source quench, and flow labels
Significant rewrite of summary of lessons learned (which is the core point of
the doc)

Points that are being made. Question is: are these right, or are they crazy?
- Benefit must be great enough to overcome entropy for existing devices
- Must provide benefits for early adopters

Jake Holland: I think this point needs a bit of wordsmithing; that should go on
the list?

Brian Trammell: Yes, word changes on the list.

Jake: It may be useful to also talk about the costs, not just the benefits?

Spencer: Good point. Please drop a note to the list on this.

Erik Kline: Is this same or different from single-mover benefits? Do we
distinguish between benefit to one party vs all parties on the path?

Spencer: Thinking about if this gets benefits depending on which boxes on the
path actually update. We meant, "does everyone along a path have to do
something?" Are there still benefits even if everyone doesn't change?

Erik: Okay, so sounds like this applies even if only one party sees a benefit.

- End-to-end mechanisms (not path aware) may be good enough that adding path
awareness don't actually provide benefit

Gorry Fairhurst: May be good to note how critical each point is to deployment;
what are actually blockers.

- If you can't charge for path awareness, then the benefits to the operator
must be significant to incentivize their participation

Lars Eggert: Also, as a corollary, if the operator charges for the path
awareness, the benefit must also be significant for the user!

Aaron Falk: This and the benefits for early adopters are related. The parties
that bring up the new work must bear the cost, and must benefit. The IAB did
some documents (8170 for example) that seem to overlap here. May want to cite
that.

Spencer: Yes, some of these are also general guidance, not just for path aware.
May be good to point that distinction out.

Brian: To rephrase Aaron, what about this draft is special about path
awareness, and what is general. I think the process here was to look at
failures and pull out commonalities. Many of the failures line up for the
success and failures for many other protocols (both transport and not). That's
a good signal to capture.

Tim Chown: You may want to tease out the cases when the operator needs to
enable something end to end from when it can be added incrementally

- Impact of a Path Aware technology requiring changes to operational
      practices can prevent deployment of promising technology.

Colin Perkins: Can prevent, but doesn't mean that it will prevent

Spencer: This comes back to the distinction between fatal points and optimizing
points

- Per-connection state in intermediate devices can be an impediment
      to adoption and deployment.

Spencer: Wondering if we can do this now where we couldn't in the past

Stewart Bryant: It depends! At the edge of the network, you have more power to
affect the packets, etc. At the core of the network, it's really hard. Per
connection state trips us up more there. In deterministic networking we found
it almost impossible to get the information between interfaces. Packets from
different flows and flow groups may go different ways through the network.

Brian: Agreed; the answer is yes, but no.
As you add QUIC, you may have fewer network-perceived flows through the core of
the network. The boundary between where you track individual flows will keep
moving around. But it won't change significantly.

Tim Chown: With quantum internet research group meetings, they think they need
per-connection state in their future design. We may want to advise and figure
out how to share advice to them.

Stewart: The other point to bring up is the difference between per-connection
state that's imposed by control as opposed to being used by the data plane
only. May want to take this to the routing area wg meeting.

Colin: We're making assumptions about end-to-end architecture. It would be
interesting in some document to comment on how changes to the architecture
change these considerations.

Jake: There's a general comment for many of these points: there are also some
exceptions, and we may want to call out for how people overcame these
differences.

Gorry: Discussing per-flow accounting in tsvwg list. Agreeing with Stewart that
the boxes and paths you choose are going to be different for different parts of
your traffic. May want to comment on tension between bad ideas and things that
must be done.

Rudiger: Looking at MPLS overlays; don't want this group to make things harder,
would be great to suggest solutions.

Stewart: Difference between base and overlay; don't assume you're operating on
the base.

- Many modern routers, especially high-end routers, have not been
      designed to make heavy use of in-band mechanisms

[no discussion]

- Can The Network Trust Endpoints?

- Can Endpoints Trust the Network Path?

Spencer: Tried to combine these two trust points, but they're distinct.
They both matter and don't have the same solutions.

- Can the network provide actionable information?

- Can the endpoint tell the path what it knows?

Do the APIs actually let the applications guide what is communicated to the
paths

What other experience should we capture to add to the lessons learned?
- We already added three new ones, that still added to lessons learned.
- We're not finished yet! More depths to plumb.
- Started transport heavy, and moved into INT space. Need to get more from
the routing area.

Brian (as chair): We keep talking about reaching out to routing. The chairs
needed be forceful to deconflict. Stewart suggested going to routing working
group, should send a pointer to the rtgwg list and propose a presentation in
rtgwg in Montreal.

Stewart: Yes, should present in routing.

Stewart: There's also network slicing. It does require state in the network
to support applications.
There's also a big difference between arbitrary applications using this,
and large corporations deploying specific applications. They have different
economic balances. The work that Geoff Huston is doing to show how the internet
is not how we traditionally think of is relevent here.

Tim Chown: Regarding point 5, how much of this is general advice that can
be captured elsewhere?

Spencer: Gorry and I need to add context in the text.

Spencer: Note that while the IETF stream needs to control BCP, IESG can
determine that work is useful to be a BCP.

Colin: Just noting we're not here to descend on working groups to tell them
what to do.

Spencer: Good to note that different research groups have different roles
relating to working groups. We should determine our model.

Rudiger: Let's figure out what is the real requirement. Is it the shortest
delay? And if my path is broken, and I want to use a different path, can I cope
with that?

Spencer: Right, that's a great point that we want to capture in follow-on work.

Spencer: How long do we want to work on and iterate on this in the group?

Jen: How many people read latest version?
(~6 hands?)
Please read it! Very useful doc.

=====
Open Questions in Path Aware Networking
https://tools.ietf.org/html/draft-irtf-panrg-questions-01
Brian Trammell

Brian: Wanted to ask as author of open question in path-aware networking, it's
about to expire. We've had good discussion in our previous meetings. We've
incorporated the comments. Think we're done. As editor, asking the group about
what we want to do with this. Personally like to have an RFC to point to in
other documents. May want to note that it is a snapshot.

Spencer: I think it's good. The one suggestion I have is to look at what we've
learned and see if there are additional research questions to add.

Brian: We should sit down and look at that before it expires.

Med Boucadair: Good for looking at critical points. I don't think it's timely
to freeze this as an RFC. We can always point people to the I-D. It's too early.

Jake: I like the idea of publishing. My problem with the draft is that at the
end I feel like "so what". Would be good to have an actionable suggestion, just
to say "panrg is looking for suggestions".

Brian: So looking for section 3, "so what?"

Mirja Kühlewind: Why do you need to publish it as an RFC? Keep it as a living
document. Does it have value for others, or is it for us?

Brian: Want something archival.

Kristy: Its not clear from reading the draft that there are more open questions
and this will evolve?

Jake: I expect this area will be open for some time to come. If this will be
open for 20 years, let's just publish this and make updates later.

Brian: Who has read this?
[12+]

=====

Vocabulary of Path Properties
https://tools.ietf.org/html/draft-enghardt-panrg-path-properties-01
Cyrill Krähenbühl

Cyrill: Incorporated feeback from last time in -01.
Added terminology section:
    - Path element (device or link)
    - Path segment (ordered set of path elements)
    - Path (path segement where the segment is the first and last)

Med: If a path element is a device, we lose visibility into the service
functions. I'd like to have more granularity. Don't be specific to hardware.

Cyrill: The idea is to define a path, and still describe lower and higher
levels. Define it first at the network layer.

Med: Need to generalize to be service functions, not just nodes. I think the
definition needs to change.

Stewart: Make sure that path segment doesn't conflict with segment routing.

Cyrill: Will need to look up more about spring terms.

Lars: I want more formalism in the definitions. What is the ordered set ordered
by?  Devices or links is too ambiguous. Some links connect more than two
devices. This isn't useful if they're so vauge/ambiguous. Terminology needs to
be rigorous.

Joachim: We have RFC 2330 that defines hops, links, etc. Look at formal
definitions from IPPM. Including draft-ietf-ippm-route.

Cyrill: We did look at the IPPM work, and did get some inspiration there.

Jake: Want to disagree with some previous comments. Looking at the draft, I do
find it to be nuanced. Can be improved, but the current text is improving.

Stewart: You need to read RFC 8402 for segment routing arch. There is a huge
overlap has concept of strict and loose routing This has been going on in the
IETF for 5 years.

Brian (chair): Can we use this generically; how much can we extract that's not
too tied into spring?

Gorry: It may be useful to look at the pointers Stewart is giving before we do
more work on this, because getting terms right first is important.

Cyrill: other terms are:
    - Flow (several packets traversing path elements)
    - Properties (includes path + flow)
    - Aggregate Properties (set of properties)
    - Measured properties (measured and estimated property values)

Also added three use cases:
    - Traffic policies
    - Network monitoring
    - Path selection for routing, endpoint selection, and multipath

Too early to ask for adoption; Cyrill and Theresa have some good feedback from
the group, please take discussion to the list and we hope to see this document
come back in Montreal.

====

Multipath Use Case and Security Requirements
https://datatracker.ietf.org/meeting/104/materials/slides-104-panrg-multipath-use-case-and-requirement-for-security-00
Stefan Rass

Security is not easy (see how hard it is to do SMIME for email)
Using only point-to-point symmetric crypto, we can actually get good security by
using multipath transmission, where I can control where I send anywhere,
I can become a moving target.

If I send over multiple paths, my adversary might not be able to see all of
the packets, and thus make it hard to break/reconstruct.

Requirements:
    - Need to have multiple paths
    - Need to ensure that the packets stay on the correct paths
    - Needs to work cross-domain
    - Needs to have some device pairing and unpairing

Rudiger: Did you check possibilities of address entropy? If you use different
addresses flows will be routed differently in the single domain. Could be much
simpler.

Jen: Comments to the list are appreciated.

====

Efficiency of Source-based path selection
https://datatracker.ietf.org/meeting/104/materials/slides-104-panrg-pan-architectures-within-a-game-theoretic-framework-01
Simon Scherrer

Applying game theory to analyze approaches to path selection.
Distinct from network-based path selection by BGP.
Network operators like network-based selection since it is orchestrated.
Souce-based can be seen are more chaotic and uncoordinated.
Question is: is this actually inefficient?

Need a way to quantify the inefficiencies in path selection.
Game theory around price of anarchy. (see slides for equation)

Results are that the end-host optimum is quite different from end host.
The price of anarchy can be bounded by latency funcitons.
Additional information can be both beneficial and harmful.

Brian: Really interesting to give formalism to measurement of stability.
Would you be interested in further pursuing in the research group.
Asks the room if interested (quite a lot of interest).
Please put this into an I-D so we can discuss on list.