Subject: Re: [PANRG] I-D Action: draft-irtf-panrg-questions-04.txt

From: Brian Trammell (IETF) <[email-masked]>
Date: Mon, 2 Mar 2020 15:43:06 +0100

hi Rayhaan,

Thanks for the note, and apologies for the delay in getting back to you. (Happy new year! :)

Notes on notes inline below (as author, not RG co-chair):

> On 24 Dec 2019, at 09:29, Rayhaan Jaufeerally (IETF) <[email-masked]> wrote:
> 
> Hi panrg,
> 
> I write down some notes / thoughts on the recently updated "Current open questions in path aware networking", and I thought I'd post it to the list in case someone is interested:
> 
> > 1.  Introduction to Path-Aware Networking
> 
> Could also add other examples such as path selection for specific applications like low jitter for voice or low bandwidth SSH connection over a stable link with low packet loss.

Maybe... This relates a bit, I think, to where we land in draft-enghardt-panrg-path-properties, because there's some thought there about timescales that we might want to pull up.

> > 2.1.  A Vocabulary of Path Properties
> 
> Everything which is exposed will be (ab?)used and may be difficult to change in the future (e.g. ossification of the network itself), so there's a fine line here.

Good point. To some extent, the work of PANRG is to be explicit about that ossification: define an an interface across these layers, then stick to it for the next half-century.

> We want to come up with some kind of network agnostic properties which is still useful to applications.

By network-agnostic, you mean "in terms of application-centric metrics as opposed to network-centric ones"? If so agreed. if not, please say more. :)

> > 2.2.  Discovery, Distribution, and Trustworthiness of Path Properties
> 
> This could be a good opportunity to mention other systems which are also built upon the trust model of interdomain routing, specifically the Resource PKI. RPKI is a central part of the effort to secure routing via ROAs and eventually BGPSEC but there are other proposals such as SEcure Neighbor Discovery (SEND) which could be bootstrapped from the same trust root. By the same token, a mechanism for distributing path information could share the same root of trust. Moreover, if the path information is contained in a ICMPv6 RA using SEND then such authentication comes for free. (Note: support for SEND is very lacking but that can be fixed).

Bridging path-aware interfaces to BGP is IMO certainly in scope for the RG (indeed IIRC you've got a draft on an experiment you did here) but I don't know how far down that rabbithole the *questions* draft should go.

> 
> > 2.5.  Implications of Path Awareness for the Data Plane
> 
> I think that it depends what is meant by a flow and how the path awareness is implemented in this section.
> 
> In a simple scenario where limited path control is given to end hosts it may be sufficient to implement path control by giving endpoints an address in various subnets which are routed differently. In this scenario the traditional 5 tuple would not change since path control is done by choosing a 5 tuple which corresponds to the desired route.
> 
> In this model there is still one route per 5 tuple. I agree however that if other out of band mechanisms are used such as having a flow server with which a client can pre-program in a route, or especially multiple routes then the single route property will no longer hold.
> 
> I wonder if there are any instances in the current internet where traffic is taking multiple paths at the same time for the same flow, and if this is being manifested in user visible things like ICMP, it would make an insightful RIPE Atlas experiment.

agreed with all of that, but these also seem to be work to do on the answers side of things, not questions. :)

> 
> > 2.6 What is an Endpoint?
> 
> I think in this context an endpoint would be perhaps the thing which receives path information and makes a selection of what path to use based on that? Endpoints can be at different layers too, for instance if a CPE router exposes multiple uplinks to the clients of a LAN then at that layer it is an endpoint, but for a TCP connection which goes over that CPE device the endpoint could be the ends of that connection i.e. the client and server.
> 
> > 2.7.  Operating a Path Aware Network
> 
> It's not clear to me how increasing path control could decrease connectivity.

short, short answer: game theory. 

> If a certain link does not have a route to the destination then the client cannot use it to reach that destination, but it seems to me that providing the path diversity should result in the number of paths being greater than or equal to the number with no path diversity.

There are assumptions now about how BGP announcements relate to how much traffic ends up flowing where, that get more complex when endpoints have more of a say. This is already kind of happening now with multipath transports balancing on Wifi and mobile, but to my knowledge not in any volume that causes those assumptions to be practically broken. It's not clear that that would remain the case with more endpoint control.

> > 2.8
> s/clear than/clear that/

Will apply this fix to the working copy.

Thanks, cheers,

Brian

> 
> Happy holidays,
> Rayhaan
> 
> On Tue, Dec 24, 2019 at 10:02 AM <[email-masked]> wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Path Aware Networking RG RG of the IRTF.
> 
>         Title           : Current Open Questions in Path Aware Networking
>         Author          : Brian Trammell
>         Filename        : draft-irtf-panrg-questions-04.txt
>         Pages           : 8
>         Date            : 2019-12-24
> 
> Abstract:
>    In contrast to the present Internet architecture, a path-aware
>    internetworking architecture has two important properties: it exposes
>    the properties of available Internet paths to endpoints, and provides
>    for endpoints and applications to use these properties to select
>    paths through the Internet for their traffic.  This document poses
>    questions in path-aware networking open as of 2019, that must be
>    answered in the design, development, and deployment of path-aware
>    intetnetworks.  It was originally written to frame discussions in the
>    Path Aware Networking proposed Research Group (PANRG), and has been
>    published to snapshot current thinking in this space.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-panrg-questions-04
> https://datatracker.ietf.org/doc/html/draft-irtf-panrg-questions-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg