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 protected]>: > > hi Bob, (hi Lars), > >> On 12 Jul 2017, at 14:52, Bob Briscoe <[email protected]> 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). >> >> [I wrote this before seeing Lars's email pointing to TERNLI] > > 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 > >> >> Bob >> >> On 12/07/17 07:21, Brian Trammell (IETF) wrote: >>> 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. >>> >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> _______________________________________________ >> Panrg mailing list >> [email protected] >> https://www.irtf.org/mailman/listinfo/panrg > > _______________________________________________ > Panrg mailing list > [email protected] > https://www.irtf.org/mailman/listinfo/panrg
