Subject: [Panrg] Proposed Path Aware Networking RG

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 12 Jul 2017 08:21:47 +0200

Greetings, all,

We'll be having a first meeting of the proposed Path Aware Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3. Since bringing path awareness to the endpoint has been the focus, at least in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG seems to be of general interest to the transport area.  Olivier Bonaventure will give a review and overview of research to date in this space, and Adrian Perrig will present a fully path-aware Internet architecture, as an illustration of what is possible when path-awareness is promoted to a first-order goal.

From our proposed charter (https://datatracker.ietf.org/group/panrg/about):

The Internet architecture assumes a division between the end-to-end
functionality of the transport layer and the properties of the path between the
endpoints. The path is assumed to be invisible, homogeneous, singular, with
dynamics solely determined by the connectivity of the endpoints and the Internet
control plane. Endpoints have very little information about the paths over which
their traffic is carried, and no control at all beyond the destination address.

Increased diversity in access networks, and ubiquitous mobile connectivity, have
made this architecture's assumptions about paths less tenable. Multipath
protocols taking advantage of this mobile connectivity begin to show us a way
forward, though: if endpoints cannot control the path, at least they can
determine the properties of the path by choosing among paths available to them.

This research group aims to support research in bringing path awareness to
transport and application layer protocols, and to bring research in this space
to the attention of the Internet engineering and protocol design community.

The scope of work within the RG includes, but is not strictly limited to:

- communication and discovery of information about the properties of a path on
 local networks and in internetworks, exploration of trust and risk models
 associated with this information, and algorithms for path selection at
 endpoints based on this information.

- algorithms for making transport-layer scheduling decisions based on
 information about path properties.

- algorithms for reconciling path selection at endpoints with widely deployed
 routing protocols and network operations best practices.

The research group's scope overlaps with existing IETF and IRTF efforts, and
will collaborate with groups chartered to work on multipath transport protocols
(MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments
(ICCRG), and alternate routing architectures (e.g. LISP), and is related to
the questions raised in the multiple recent BoF sessions that have addressed
path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA).

he PAN(P)RG intends to meet at each IETF meeting until a
determination is made whether or not to charter it. Afterward, the RG intends to
meet at 1-3 IETF meetings per year, and hold one workshop per year, colocated
with a related academic conference.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 12 Jul 2017 08:41:52 +0000

Hi,

> to the attention of the Internet engineering and protocol design community.

there was a bunch of work related to a "TERNLI" (Transport-Enhancing Refinements to the Network Layer Interface) BOF attempt about ten years ago that may be relevant (and older work referred to by it). Specifically:

* https://www.ietf.org/proceedings/66/slides/intarea-3.pdf
* https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01
* https://www.ietf.org/proceedings/66/slides/MobOpts-4/sld1.htm
* https://tools.ietf.org/html/rfc4907 by the IAB

Other folks may have other pointers from that time?

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 12 Jul 2017 13:52:44 +0100

Brian,

1/ The IRTF sounds like a good landing point for all the previous 
attempts to get the IETF to add path-awareness protocols.

BTW, this goes back a lot further than SPUD. A good summary of pre-2007 
efforts in this space is in a section of Pasi's draft on this from 2007: 
https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 
, which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and 
TERNLI (2006).

[I wrote this before seeing Lars's email pointing to TERNLI]

2/ The advantages of opacity (invisibility) of path characteristics 
should also be in scope.

In general the tone of the text seems to be "awareness = good; 
unawareness = bad". If I have detected this tone correctly, it would 
represent an implicit value judgement; which would not be a good 
starting point for research.

* You've alluded to potential security advantages in the phrase 
"exploration of trust and risk models".

* There are also evolvability advantages. I recall David Clark (I think) 
saying that the rudimentary interface between transport and network was 
a feature not a bug. Admittedly it's a pain for the transport to have to 
discover available path capacity, path delay, etc. However, the 
alternative would have been to require all L2 technologies to be able to 
give information that would require them to make assumptions about the 
transport. That in turn would ossify transports and L2 technologies.

We might be saying that the Internet is moving into a new phase where 
performance is now more important than evolvability. That's a point to 
debate, but I know you, at least, still believe that stack evolution 
will remain important.

Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Jul 2017 10:30:22 -0500

Brian, Bob, and Lars,

On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe <[email-masked]> wrote:

> Brian,
>
> 1/ The IRTF sounds like a good landing point for all the previous attempts
> to get the IETF to add path-awareness protocols.
>
> 2/ The advantages of opacity (invisibility) of path characteristics should
> also be in scope.
>
> In general the tone of the text seems to be "awareness = good; unawareness
> = bad". If I have detected this tone correctly, it would represent an
> implicit value judgement; which would not be a good starting point for
> research.
>
> saying that the rudimentary interface between transport and network was a
> feature not a bug. Admittedly it's a pain for the transport to have to
> discover available path capacity, path delay, etc. However, the alternative
> would have been to require all L2 technologies to be able to give
> information that would require them to make assumptions about the
> debate, but I know you, at least, still believe that stack evolution will
> remain important.
>
>
> Bob
>
>
>> We'll be having a first meeting of the proposed Path Aware Networking
>> (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall
>> 3. Since bringing path awareness to the endpoint has been the focus, at
>> least in part, of a couple of running TSV working groups (MPTCP, TAPS),
>> this RG seems to be of general interest to the transport area.  Olivier
>> Bonaventure will give a review and overview of research to date in this
>> space, and Adrian Perrig will present a fully path-aware Internet
>> architecture, as an illustration of what is possible when path-awareness is
>> promoted to a first-order goal.
>>
Brian, thank you for taking this on, in the first place. We've been dancing
around the topic in the IETF for a while, and if I've learned anything from
attending that dance, this isn't engineering (yet) and isn't IETF timescale
(yet). So, the IRTF seems appropriate.

Lars and Bob, thank you for the pointers to prior art. I was aware of some
of that (for better or worse, I co-chaired the TRIGTRAN BoF, but
co-chairing PILC might have made up for some of that), but certainly not
all of it, and much of what you two named happened while I was off doing
RAI stuff after PILC concluded.

I look forward to the first PANRG session in Prague, and I'll encourage TSV
area chairs to consider whether PANRG should be on their conflict lists for
future IETF meetings.

Travel safely, and I'll see many of you next week.

Spencer, as TSV AD and at-large IRSG member

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 13 Jul 2017 00:06:49 +0200

hi Bob, (hi Lars),

> On 12 Jul 2017, at 14:52, Bob Briscoe <[email-masked]> wrote:
> 
> Brian,
> 
> 1/ The IRTF sounds like a good landing point for all the previous attempts to get the IETF to add path-awareness protocols.
> 
> BTW, this goes back a lot further than SPUD. A good summary of pre-2007 efforts in this space is in a section of Pasi's draft on this from 2007: https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and TERNLI (2006).
> 

Of course, and thanks to the pointers (also to the list).

Previous efforts here (indeed, including my own) seem to be focused on cross-layer approaches and involve signaling across the layer boundary. MPTCP shows that path-aware protocols can be implemented, albeit in a limited fashion, without such signaling. So I think the scope is a little bigger here.

> 2/ The advantages of opacity (invisibility) of path characteristics should also be in scope.
> 
> In general the tone of the text seems to be "awareness = good; unawareness = bad". If I have detected this tone correctly, it would represent an implicit value judgement; which would not be a good starting point for research.

Possibly. I'm taking the fact that this theme winds through an array of current work in the IETF as an indication that awareness is something that is being driven toward, so if it's not "good", then it's at least something we need to be ready for. Perhaps the language is a bit boosterish, though.

> * You've alluded to potential security advantages in the phrase "exploration of trust and risk models".

Here, what I think needs exploration is "how can you ensure that the information flow, implicit or explicit, in path-aware architectures or (even partially) path-aware technologies is trustworthy, and that the level of exposure is appropriate?" You could, of course, implement path awareness at the transport layer without any signaling across layers at all. This is how MPTCP works. Anytime you do add signaling for path awareness, the trust establishment problem comes up. PLUS included an attempt to sidestep this through severe restrictions on the vocabulary, and I still think that's a field worth exploring in more concrete detail. Another way to do this is to derive path property information from a (secure, trusted) control plane; SCION does this, albeit with a somewhat different architecture than the Internet presently follows.

> * There are also evolvability advantages. I recall David Clark (I think) saying that the rudimentary interface between transport and network was a feature not a bug. Admittedly it's a pain for the transport to have to discover available path capacity, path delay, etc. However, the alternative would have been to require all L2 technologies to be able to give information that would require them to make assumptions about the transport. That in turn would ossify transports and L2 technologies.

... which are, of course, not ossified now. ;) I think we paid a price here and didn't get the full benefit, but that's with the benefit of a bit more hindsight.

> 
> We might be saying that the Internet is moving into a new phase where performance is now more important than evolvability. That's a point to debate, but I know you, at least, still believe that stack evolution will remain important.

I would personally say that a core requirement of anything that comes out of PANRG and into the IETF is that it be evolvability-preserving, but that's me, and as you say, that belief is I think obvious from my body of work on the subject. But yes, this is another axis to bring under discussion.

Thanks, cheers,

Brian

> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 13 Jul 2017 15:41:49 +0200

Hi all,

I would like to add one point because I was involved in the scope discussion for this proposed research group early on. Other than with the efforts listed below, this activity does not focus on protocol (or interface) design. It's rather about mechanisms, especially for path selection, that can use this kind of path information if available, or/and to figure what the information is that we need to exchange in existing or new protocols to realize the proposed mechanism. These mechanisms may be very similar in different scenarios that are already consider in various existing working groups but usually out of scope for those working groups as in the IETF the focus is on protocol design. So hopefully this research group can be a good supplement for existing and future IETF working in this space.

Mirja

> Am 13.07.2017 um 00:06 schrieb Brian Trammell (IETF) <[email-masked]>:
> 
> hi Bob, (hi Lars),
>

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 12 Jul 2017 07:19:47 +0000

Wouldn't it make sense to "liaison" also with the ALTO and (perhaps) the TEAS working group?

In these working groups, quite a number of technologies may already exist to solve this sort of problem.

Michael

> -----Original Message-----
> From: tsv-area [mailto:[email-masked]] On Behalf Of Brian
> Trammell (IETF)
> Sent: Mittwoch, 12. Juli 2017 08:22
> To: [email-masked]
> Cc: [email-masked]
> Subject: Proposed Path Aware Networking RG
> 
> Greetings, all,
> 
> 3. Since bringing path awareness to the endpoint has been the focus, at least
> in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG
> seems to be of general interest to the transport area.  Olivier Bonaventure
> will give a review and overview of research to date in this space, and Adrian
> Perrig will present a fully path-aware Internet architecture, as an illustration
> of what is possible when path-awareness is promoted to a first-order goal.
> 
> From our proposed charter
> (https://datatracker.ietf.org/group/panrg/about):
> 
> functionality of the transport layer and the properties of the path between
> the endpoints. The path is assumed to be invisible, homogeneous, singular,
> with dynamics solely determined by the connectivity of the endpoints and
> the Internet control plane. Endpoints have very little information about the
> paths over which their traffic is carried, and no control at all beyond the
> destination address.
> 
> Increased diversity in access networks, and ubiquitous mobile connectivity,
> have made this architecture's assumptions about paths less tenable.
> Multipath protocols taking advantage of this mobile connectivity begin to
> show us a way forward, though: if endpoints cannot control the path, at least
> they can determine the properties of the path by choosing among paths
> available to them.
> 
> - communication and discovery of information about the properties of a path
> on  local networks and in internetworks, exploration of trust and risk models
> will collaborate with groups chartered to work on multipath transport
> protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected
> environments (ICCRG), and alternate routing architectures (e.g. LISP), and is
> related to the questions raised in the multiple recent BoF sessions that have
> addressed path awareness and multiply-connected networks (e.g. SPUD,
> PLUS, BANANA).
> 
> he PAN(P)RG intends to meet at each IETF meeting until a determination is
> made whether or not to charter it. Afterward, the RG intends to meet at 1-3
> IETF meetings per year, and hold one workshop per year, colocated with a
> related academic conference.
>

---

From: Aaron Falk <[email-masked]>
Date: Wed, 12 Jul 2017 16:20:25 -0400

This sounds interesting and I’m glad to see a place for this work to 
be addressed in this community.

It does make me sad that PANARG (a proposed RG and kind of a BoF) is up 
against IDEAS (an actual BoF).  Indeed, the Venn diagram of path-aware 
networking and identity-locator split have some overlap in my mind.  
YMMV, of course.

—aaron

On 12 Jul 2017, at 2:21, Brian Trammell (IETF) wrote:

> (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress 
> Hall 3. Since bringing path awareness to the endpoint has been the 
> focus, at least in part, of a couple of running TSV working groups 
> (MPTCP, TAPS), this RG seems to be of general interest to the 
> transport area.  Olivier Bonaventure will give a review and overview 
> of research to date in this space, and Adrian Perrig will present a 
> fully path-aware Internet architecture, as an illustration of what is 
> possible when path-awareness is promoted to a first-order goal.
>
> protocols

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jul 2017 21:07:02 +0000

Isn’t In-Band OAM supposed to expose the actual Path Information?

More and more services need to know network delay & path information. That is why there are so many network monitoring companies popping up in offering delay and other characteristics of network to end points.

However, it has been difficult for network operators to expose its exact paths due to the confidentiality of its network topology.

It makes more sense for end points to inquire pseudo path information instead of real path information, and more realistic from networks’ controller or management system.

My two cents
Linda Dunbar

From: tsv-area [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, July 12, 2017 10:30 AM
To: Bob Briscoe <[email-masked]>
Cc: [email-masked] >> [email-masked] <[email-masked]>; [email-masked]
Subject: Re: [Panrg] Proposed Path Aware Networking RG

Brian, Bob, and Lars,

On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

Bob

Brian, thank you for taking this on, in the first place. We've been dancing around the topic in the IETF for a while, and if I've learned anything from attending that dance, this isn't engineering (yet) and isn't IETF timescale (yet). So, the IRTF seems appropriate.

Lars and Bob, thank you for the pointers to prior art. I was aware of some of that (for better or worse, I co-chaired the TRIGTRAN BoF, but co-chairing PILC might have made up for some of that), but certainly not all of it, and much of what you two named happened while I was off doing RAI stuff after PILC concluded.

I look forward to the first PANRG session in Prague, and I'll encourage TSV area chairs to consider whether PANRG should be on their conflict lists for future IETF meetings.

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2017 14:10:02 -0700

On 7/12/2017 5:52 AM, Bob Briscoe wrote:
> BTW, this goes back a lot further than SPUD. A good summary of
> pre-2007 efforts in this space is in a section of Pasi's draft on this
> from 2007:
> , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003)
> and TERNLI (2006). 
IMO, those are less "path" than "link" aware.

I.e., I see "path aware" as knowing the difference in the *path*
properties of two different paths, e.g., BW, latency, jitter.

I see "link aware" as dealing more with per-hop loss rates, MAC
collisiions, etc.

So yes, there are a lot of "dead" bodies from past work here, but IMO
that's a lesson - I don't think link-transport interactions are a great
idea. I sincerely hope that this new effort is doign in a different
direction, rather than rehashing these old efforts...

Joe