Minutes IETF100: panrg
minutes-100-panrg-00

Path Aware Networking (PAN) Proposed Research Group
Thursday, November 16, 2017 -- 13:30 -- Collyer -- IETF 100 Singapore

Chairs: Brian Trammell and Jen Linkova

Minutes: many thanks to Tommy Pauly!

Agenda

    Agenda / Note Well / Bluesheets/ Refresh Chairs, 10 min

There are lots of work in various areas around path selection! MPTCP, QUIC
mobility, BANANA, PLUS, IAB StackEvo, etc

Illustration: Today, you have endpoints that have no control other than to
route to the ultimate destination In a path-aware model, the endpoints get to
have much more control over what happens to their packets

We have one document so far, from Brian that covers open questions in
path-awareness. Please read! One suggestion in Prague was that signalling in
transports for path awareness has often not worked, and we should understand
why Spencer Dawkins: I think this cataloging effort will be really useful, and
I'm happy to help start cataloging. draft-dawkins-panrg-mpdiediedie

We'd like to have a workshop, asked for one in SIGCOMM, which would be Budapest
2018 (which may replace fall 2018 IETF meeting)

    Dissemination of Paths in Path-Aware Networks Christos Pappas, ETH Zürich,
    20 min

Motivation in research group:
    Endpoint discovery of paths
    Discover properties of the paths that are static or dynamic
    How do they select paths, and how to inform the network about which paths
    to use?

Three steps:
    Path construction (explore topology to endpoint)
    Path selection (choosing the construct path)
    Path representation (encoding the choice to the path)

In SCION, path construction happens through beacons and creation of up and down
segments. Beacons sent between ASes, etc. The beacons can disseminate more
extended path properties in the beacons [Details of SCION beacons and up down
segments between ASes, see slides] Multipath paths can be constructed from many
segments Paths are represented as interface level forwarding instructions, with
identifiers per segment.

In another related scheme, NIRA, there is a similar set of steps: topology
construction, path selection, and representation. Source/dest IPv6 addresses
represent the paths.

Pathlet Routing again follows similar steps. vnodes are used for construction.
Path selection is unspecified, and path representation is done like MPLS with
opaque identifiers.

Take aways:
    We have ways to handle multiple paths, and pass properties
    Questions: how to do dynamic properties, how to send to apps, how to lookup
    paths for endpoints?

Tommy Pauly: I like the representation of the three steps; I think they apply
beyond just these future internet models, but also for more present solutions.
How can we make applications able to transition? Christos: This looks more at
the network layer, but we can imagine applications first getting information
before they can truly select.

Thomas Schmidt: How to announce peering links?
Christos: This makes the relationships more explicit, not just hidden by BGP
Thomas: Isn't this in the carrier's interest to hide?
Christos: The providers don't want to do it, indeed.

Philip: How does this work inside the AS?
Christos: This left out that problem. The issue is scalability with more
disjoint information within a domain.

Aaron: In a project I worked on, it had the idea of letting users select long
distance providers. This was about providing hints. The intent wasn't about
fine-grained control, but to differentiate providers and services that users
could take advantage of.

    Interfaces for Path Selection Laurent Chuat, ETH Zürich, 20 min

We use multiple processors, CPUs, disks for speed and redundancy. What about
network paths? If one path goes down, we can have better reliability. We can
also have mobility and migration (not truly multipath).

Some would believe that using a single, very good path. But I argue that there
is no perfect path. Information can only travel 2/3 the speed of light in
fiber, so latency is a problem. Wireless is convenient but problematic.

What will tomorrow's network paths be made of? Infrastructure and FIAs.

MPTCP is part of the story, but since it hides paths from applications, it
cannot do everything.

Should we optimize for throughput or latency? We often want both. It's not easy
to optimize for both. Does the application need reliable or unreliable? If
contents need to be delivered, use MPTCP. If its a simpler model, just use
datagrams that can be path-independent.

Why do the current models fall short? There may be two paths: high bandwidth
with high loss, high delay, and one with low bandwidth, low delay, and low
loss. You can send on the high-loss path, and fill in gaps on the low-loss
path. This allows reaching optimal bandwidth. Path diversity helps. Paper
covers the function for linear optimization between two paths with different
characteristics, with math and simulation.

Objective: A more expressive sockets API would help here, have more knobs, on
which packets, etc? What should the application learn about how the
transmission went?

This relates to the Post Sockets API in TAPS. Message properties are important
here. Lifetime/partial reliability, priority, dependencies, idempotency, and
immediacy. Lifetime: reliable vs unreliable is false dichotomy; can have
partial reliability (see SCTP, D2TCP) Priority/Niceness: related to lifetime,
says how well it gets out of the way Dependency: Antecedent messages show
serialization between messages

These problems get hard:
    Assigning packets to paths is very difficult as the number of paths goes
    up. Good news is that the problem doesn't need to be solved for each
    packet. Not finding the best solution doesn't rule out good solutions New
    APIs can drive new research into multiple paths

Brian: (no hats) The graph is going up logarithmically for calculations, so may
want to remove path options?? As TAPS, we want to pick the stack based on
application needs to hide the complexity, while you want to expose the message
properties.

    Provisioning Domain PvD: network giving information to clients Eric Vyncke,
    15 min

Work in Internet Area that relates to path selection. If we look at networks,
there is often a lot of complexity of links beyond the local connection of a
device. Multiple service providers, etc, just through a single local interface.
VPNs too.

How does the application select the right thing? In IPv4 with NAT, you select
one path and just use that.

With IPv6, you may want to select one of multiple addresses that you received
from different providers behind your access point. The application needs to be
aware of multiple paths and their properties.

The MIF group defined RFC 7556, for Provisioning Domains. This is a coherent
set of information for a device. Up until recently, most devices saw a single
PvD. But when we have multiple, we want to identify them and understand them.
We also extend the definition of PvD to point to application layer extended
properties.

The protocol uses IPv6 Router Advertisement. The PvD ID is defined, along with
a generation count to manage instances of information, along with a bit
indicating how to access extended information via HTTPS. This extended info
will carry information about the network, such as its quality, walled garden,
captive portal, cost, etc.

Being implemented on many platforms in open source and by corporations. Also
related to work by the NEAT group.

Brian: Nasty question as someone who was only vaguely aware of PvD: this is a
less hacky way to extend DHCPv6. Gives you more space. Architectural question:
limited to first hop right now. Anything further could be segment routing, and
to go interdomain.

    Lightning Talks on Path Properties [5 mins each]

    The IETF ALTO Protocol and its Extensions Sabine Randriamasy, Nokia

List of open questions circulated last week. ALTO is working on exposing path
properties being defined and represented, etc. The ALTO protocol guides the
application in selecting paths via RESTful APIs. Built on mutual trust between
entities. The properties are exposed as a cost map. While PANRG may look at HOW
to connect, ALTO looked at WHERE to connect (path identification).

    Path Awareness for Congestion Control Xingwang Zhou, Huawei

Usually, congestion is discovered passively just by observing loss, etc. ECN
makes congestion an explicit signal from the network. In research, having still
more path properties is very useful (ingress/egress rates) to futher optimize
the bandwidth utilization. Explicit notification allows much faster adaptation,
or handling variable qualities.

ECN is one way to use two bits to signal congestion. For these experiments,
used further extended properties as a new path-layer property.

Dawn: How do you control the path properties from the application?
Xingwang: No way specified for this. Can interact with resources allocated for
them (?)

    Introduction of Open Questions (draft-trammell-panrg-questions), Brian
    Trammell, 5 min

Sent out draft with PANRG questions:
    - How are path properties defined and represented? (ALTO cost maps, PvD
    key/values)

        Are these properties always the best properties? We could have a common
        vocabularity, but they don't have them yet.

    - How do endpoints discover trustworthy properties? (SCION and ALTO have
    trust involved) - How can endpoints select paths? (Addressing and more may
    work) - How can interfaces to the transport and application layers support
    path awareness? (Post Sockets is one point here) - How can a path aware
    network be effective operated? ? ? - How can the incentives of operators
    and end users be aligned to realize the vision of path aware networking? ? ?

Lin (Huawei): These parts are huge. For address selection, are you referring to
source routing? Brian: Well, we use remote addresses all the time, but I was
referring to segment routing? Lin: What about v4? Brian: Why do I care about
the legacy internet?... My personal view on that is that many enabling
technologies work much better on v6 than v4 for this. If v6 does this much
better than v4, then it's easier to move to v6 while we rewrite applications
anyhow.

Lee: I could imagine writing in NAT Zones
Brian: "Addressing Zones"
Lee: Yeah, that could come out of this work.

Swetha: With the open question of how the path aware network will be operated,
wouldn't the networks use this signalling between one another, not just the
client? Some networks have path awareness, other don't. Brian: Very good to
think about. Swetha: Also doing IPPM work that seems relevant here, defining
what could be collected about the network for path properties. Would we modify
the transports to carry this information?

Tommy Pauly: This sounds a lot like CAPPORT problems when we talk about
incentives. Brian: I like the point Aaron made earlier about the fact that
multiple paths can be driven by an 'open market' for letting clients choose
which provider and services they want to use.

Brian: Looking forward to more in London! Smaller this time than first time,
but still good interest. Allison: We need way more conflicts listed to allow
everyone to come from other areas. Maybe have two different sessions to get a
wider audience.