Minutes IETF105: panrg
Path Aware Networking RG
||Minutes IETF105: panrg
PANRG Agenda IETF 105
When: 13:30 - 15:30 UTC-4, Thu 25 July 2019
Where: Laurier, Fairmont The Queen Elizabeth, Montreal
Chairs: Jen Linkova and Brian Trammell
Minutes Taker: Tommy Pauly
Jabber Scribe: Tal Mizrahi
Open Questions in Path Aware Networking
-02 document, new in May. No structural changes to the document recently. Got
some good comments. Question about being a living/open document, or publish as
a snapshot in time
This document hasn't been updating much and is essentially expiring. Rather
than being a zombie document, why don't we just publish it?
Aaron Falk: Maybe add the timeframe to the title, like "Open Questions in 2019"
Spencer: I'm expecting to refer to this in my later presentations; please let
me know if I should point to it as a draft or an RFC
Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)
Not getting a lot of new material, mainly refining existing lessons learned.
Want to review the lessons learned and validate what is still true and what
- Overcoming entropy: I think will always be true for path aware networking -
thumbs up - Providing benefits for early adopters: Same, also always true -
- End-to-end mechanisms may respond quickly enough that they can overshadown
path aware mechanisms. More thoughts requested. LOOPS talked about is the
complexity worth adding the extra knowledge. Can't you burn more round trips
and just be simpler?
Brian: Modifying middleboxes to tell you measurements won't get you there
faster than just measuring. BUT for aspects that change slowly and are hard to
detect, there is a benefit. Flip the question around a bit, rephrase in terms
of properties. Path RTT is a terrible property to measure here. The link type
(satellite link) is a much more stable property.
Spencer: First thing, may have a -04 with new subsections, and this could go
there. Second thing, be clear when we talk about long lived data is good.
Tommy: Agree that rephrasing would be good—tell us what about a protocol
mechanisms makes it more or less useful on this scale.
Theresa: Discuss things that explain what the endpoint can tell on its own
versus with the path's help.
- Follow the money; I think will always be true (thumbs up)
- Operational practices can be show-stoppers;
worth discussing; why are some protocols operationally train wrecks, and others
are not? See invariants in QUIC. This is a changing area.
Brian: This one also has a flip-side. Path awareness that improves operation
may also be an incentive.
- Per-connection state can be an impediment; may be worth discussing, not
Eric Kinnear: The problems isn't that the per-connection state exists, but what
is done with it. If you do have state, what is fine; but what is hard or
harmful. How expensive is it?
Philipp Tiesel: Stepping back, adding new functions to a network can be adding
work to devices next to the routers, not on the routers themselves. This change
makes it more feasible.
- In-band mechanisms might not be a fast path; similarly, this one may have
more recent changes and exceptions.
- Can the nework path trust endpoints? We need to talk about this!
Brian: Right now, SAG is talking about discussion for opening the internet
threat model to include new things. This is the path-aware internet threat
Igor: If the endpoints have no incentive to be truthful, some mechanisms
benefit truth-tellers more than liars.
- Can the network provide actionable information? Again, likely always true for
path aware networking.
Brian: If the information is available from measurement, why get it from the
- Do the endpoints know what the path needs to know? True in general.
- Can the endpoint tell the path what it knows? Want to let TAPS API play out
around this one.
Performance Implications of Path Characteristics
Please read this document!
Had side meeting at IETF 104 and IETF 105. Not a lot of warning on the list.
Yesterday morning meeting. Had good people show up for current research on this
area. (about 10) Bad news is that almost everything is still research, not
concrete protocol advice.
Why not do PIPC in PANRG?
- This isn't for research, it's more like a BCP in the IETF (want IETF review)
Paths exist, but they may change. Explaining paths on their own is good.
Are all parts of a path equal in usefulness, trust, etc?
Cases like wi-fi plus satellite is interesting
Hints like ECN exist; hints seem safer than directives.
Tell hosts "here's the path, do the right thing!"
Brian: There are some properties that will tell you "you'll have a bad day if
you ignore this" Are directives even possible? No.
Igor: Looks like these hints are the things that try to ossify protocol,
RFC8558 (explicit signals). This is dangerous to consider as a hint or
Spencer: Yes, that's a tension that existed in the room.
Erik Kline: Certainly watching IP TTL changes on a certain network (188.8.131.52 had
vastly different TTLs on different ports). Signs of interference not just path,
Spencer: Another point was "trust no one!". Some applications don't want to
trust anyone! Don't trust any signals into or out of the network? Want to
remove all signals. A key about PANRG is that we want to guide those protocol
Erik Kline: I've been contemplating a "hybrid" network architecture. What do
you trust? The less you ask people to trust, the more useful it can be. Let me
give local multicast a hint that there's some change. Limit the scope of what
Tommy: Regarding trusting parts of the path, I think it's about provisioning;
we can know only when elements of the path are aware and coordinating with one
another. We can get a hint that different entities in the network and path are
provisioned similarly or together.
Spencer: There was a talk in IRTF open about hardening NTP, and preventing
"time travel". How should you allow changes to your time, based on the sampling
you have from multiple entities? If you had a sample of a quarter of NTP
servers, at a regular interval, it would take an attacker 100 years to skew the
clocks by less than a second. Can models like that be helpful for us? Recommend
Nicolas Kuhn : You may want to consider Gorry's draft on guidelines for
congestion control - presented in parallel at TCPM
Communication is a good thing!
Brian: This room is a good place to have this conversation. Can a research
group give advice to IETF? Yes, as long as it isn't binding. Do you want the
advice to be binding or not?
John Border: Does PANRG want to take on the analysis task?
Brian: This seems a good a room as any. Looking around, there's an unfortunate
conflict with TCPM; we conflicted with routing before too. Would not want to
look around the room, and just see the transport people who care here, and no
Spencer: It would be good to update the conflicts.
Tommy: We've often had too little external involvement here. Can we solicit
more direct presentations from IETF protocol groups (like QUIC, say) on their
path awareness work to present here in PANRG, to get communication. That way
our documents can reflect that communication?
Brian: We'd have to check the charter and ask the ADs.
Also note that there are different path definitions in different situations.
Will talk with ADs and Chairs and Spencer.
A Vocabulary of Path Properties
T. Enghardt, C. Krähenbühl
Draft aiming to answer the first question on the PANRG draft: how do we talk
about path properties. Mainly looking at terminology, making it more rigorous.
Nodes process packets (hosts or routers); joined by links.
Nodes and links are path elements. They join to be subpaths. Paths end with
Eric: Is the sequence of path elements adjacent, for the purpose of measuring
Theresa: Maybe the properties are just routers, so its a sequence not a subpath.
Philip: And there is always a link between nodes?
Theresa: Yes. There may be a virtual link.
Erik Kline: I assume this unidirectional? The path may be asymmetric? What is
the flow made of, packets or subpaths?
Brian: A flow is an entity made of packets to which the traits of a path or set
of subpaths may be applied.
Alia: You're assuming the endpoint is always a host? You're deliberately
leaving out overlays in this case, which are really everywhere. I encourage
thinking about overlays here.
Theresa: In our definition, the overlay between routers is a subpath.
Alia: The overlays may have sub/micro-flows that are different than the
original end-to-end flow. So this does have implications. We keep talking about
paths here as if they're static—they're not. Think about hashing, etc. Have a
way of discussing the time-relevance of a path definition, and the liveness of
Stu: What do we call a flow when it doesn't satisfy the definition of the flow
that requires it to follow a single path?
Brian: You're not making any constraint on the layer on which a link exists,
right? Spencer was asked to create a document to define a path, and if you
apply the comments you've received, it becomes that document. We can't have an
IETF-wide definition of flow or path; micro-flows, etc.
Y. Richard: Great to talk about the path definition in this research group.
Paths often come from graph theory. Do we design by path or flow? You have a
problem enumerating exponential possible paths.
Nicholas Kuhn: We may have unidirectional links with links different in each
Brian: Should we call for adoption?
Spencer: Yes, that would help Theresa work on this with the rest of the
Research Group and get more eyes on this.
Brian: Also, does this first half of the document fulfil the need you (spencer)
have for a definition of path?
Spencer: Yes, and I think having something concrete will help us communicate
about our work here.
Eric Kinnear: Our abillity to communicate with others will be much improved by
having this as an RG document.
Al Morton: This actually matches well to what we do in IPPM.
Brian: Will follow up on the list for adoption call.
Experiments with Property-based Path Selection
First IETF! Working on the SCION project, so coming from that perspective.
Looking at questions 2.7 and 2.8:
2.7: How to reconcile conflicts of intent between endpoints and operators?
2.8: How can the operators be incentivized to let go of path control?
This all depends on the specific path selection behaviors of the endpoint.
"Path selection should aim to not be worse than the default case". Corollary is
that path selection should not be to the detriment of the network. In a Kantian
sense, let things be universally applicable.
Path selection needs to work when all endpoints follow the same behavior. If
this is ubiquitous, does it work?
If there is a sudden burst of traffic, does the system scale?
Did experiments with naive approaches to show that you get oscillations that
are hard to dampen.
Should we provide guidelines for path selection?
Would it be okay for networks to misrepresent paths depending on who asks?
Theresa: Very interested here, want to see more details. Related to question
2.3 as well. How can we trust, etc.
Sabine: Thanks! In car traffic, a variation of 5% can cause a traffic jam. Very
Brian: I like the Kant reference, will use in a draft =) Very valid
contribution. What's the ask? Do you want a draft? Lots of the questions are
similar to transport area for bad feedback. The graphs aren't new, they just
have new axes.
Tommy: Yes, I can totally see this group being an ICCRG for these other
dimensions of coexistence (across path selection).
Philipp: I think the network should not be able to lie to the endpoints about
the path properties.
QUIC vs PEP Over Satellite
We're looking at how we can make QUIC work well over satellite, since we can't
do the same performance enhancing proxy we have with TCP.
See slides for numbers on relative performance with different variables.
You need a large window to get to high speed, but also enhanced loss recovery.
We would like to collaborate with a high-speed connection to a QUIC server to
do experiments. Want some control over BBR, etc.
Theresa: Isn't this what LOOPS is for? Why can't we use LOOPS?
John: LOOPS doesn't go the the end host, and most of the loss is on the first
hop (Wi-Fi). QUIC makes me end-to-end. I have proprietary solutions for LOOPS
type stuff in the middle of the network.
Colin: I think LOOPS was open to considering this use case.
Erik: Re the difference between HTTP/1.1 and HTTP/2, since HTTP/2 as built-in
flow control, how did that change?
C. Su: HTTP/2 has data stream flow control (6 or 12 MB)
Brian: Please also take to QUIC and TSV lists.
QUIC Over In-sequence Paths with Different Characteristics
Satellite links don't generally have visible losses, to the concerns are
different. Highly asymmetric links with high jitter.
Waiting for QUIC v1 for building full solution.
Currently testing with QUIC-GO
See slides for traffic patterns and results.
Looking at FEC, also interactions with MASQUE proposal.