# PANRG at IETF 111 * Chairing: Jen Linova * Vacationing, Sending Regrets, and SorryNotSorry: Brian Trammell * Notes: Spencer Dawkins and Tom Jones # Welcome, Note Well, Agenda Chairs * We started on time (yay, Jen!) * We had a short celebration of [RFC 9049](https://https://datatracker.ietf.org/doc/rfc9049/) being published. * [The Research Questions draft](https://https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/) is in IRSG balloting now (and Spencer noted mentally that it's got the ballots it needs to be published after any final revisions) # A Vocabulary of Path Properties (draft-irtf-panrg-path-properties) T. Enghardt, C. Krähenbühl * Most of the work since IETF 110 was on the definition of transparency. * Added a formal Entity definition * Comments? * Sabine: regarding entity, I think that would be on path, and characterized by some actions. There may be several parameters that characterize an entity, for example, a role. * Cyrill: Entity is the basic term - other things refine that term. * Sabine: can I specify parameters? Can I tell that something is an Entity? * Cyrill: we do, using inheritance. * Richard Yang: I like that you mention entity in context of inheritance. Are there functions that would exist across all Entities? * Theresa: Not currently formalized, but a starting point would be to look at the Use Cases section, which has examples of non-node entities. * Richard: what exactly is "transparent"? For instance, a NAT? * Cyrill: let's discuss it on the mailing list. * Ready for last call? * (Did not get to this last question - Theresa will express an opinion on the mailing list and ask what the research group thinks) # Path Selection for Multiple Paths In QUIC (draft-dawkins-quic-multipath-selection) S. Dawkins * "How many path selection strategies are enough?" * Spencer identified 10 in QUIC WG discussions about multipath, and thinks there is no obvious upper bound * Arbitary combinations of path selections are happening in the real world * Can we identify building blocks and use those to build new strategies? * Is this research? Is it interesting? Is it doable? Do **YOU** want to help? * Comments * Theresa Enghardt: I like your draft. It fits well here and I am willing to help * Spencer: thank you, and your gracious offer is very welcome! * Richard Yang: I found the problem interesting, but it is really hard and it depends on the outcome. I have a link to [a paper](https://dl.acm.org/doi/pdf/10.1145/3230543.3230562) called "Trident: Toward a Unified SDN Programming Framework with Automatic Updates" (see Table 1). We tried hard to come up with an algebra with 8/9 operators. Reviewers asked if this was complete, or this was optimal and we couldn't answer at that time. * Spencer: Thank you for the link, and I look forward to conversations about that topic on PANRG! * Lucas Pardue on Jabber: another algorithm for you: the path of least resistance. I've also heard it referred to as "paving the cow path" * John Border on Jabber: A thought about latency that Spencer's statement triggered that I think is worth getting captured. Most commonly, we think of latency as being the time to send one message across the path. But, another view is the time it takes to get the entire job done. So, picking between a path with 100 milliseconds latency but only 2 Mbps of throughput can be traded against 500 milliseconds latency with 200 Mbps of throughput. A terabyte file transfer will finish faster on the latter. * Antoine Fressancourt on Jabber: @John, I think Detnet guys have such concepts in the expression of their routing constraints * Spencer's take on the results of this discussion, worth verifying on the mailing list * Definitely research * In scope for PANRG * It's a hard problem, but worth solving if we can solving * Enough people are interested to make it worthwhile for PANRG # Enhancing Transport Protocols over Satellite Networks (draft-jones-tsvwg-transport-for-satellite) T. Jones * The TCPSAT working group produced two excellent RFCs in the 1990s that are outdated now, because * Satellites are several generations further on now, and * Most of the TCP performance improvements come with Performance Enhancing Proxies (PEPs), that won't work with QUIC because of encryption * This draft started out as advice for QUIC * Want to provide advice to transport protocol designers * (Spencer notes this is the way the PILC working group went, producing [RFC 3819 - Advice for Internet Subnetwork Designers](https://https://datatracker.ietf.org/doc/rfc3819/)) * We think this is great, but is it of interest to PANRG? * Hesham: have you done work with redundant links? * Tom: we have a section on that, but we need help adding information from satellite operators for various types of satellites and constellations - we have information about GEO satellites, but need information on MEO and LEO satellites. [EtoSat MailingList](https://www.ietf.org/mailman/listinfo/Etosat) * Theresa: Yes, this is interesting. I see it as a specific case of path awareness, with path properties, an entity that is aware of it, and optimizing. Maybe this is not just guidance for protocol designers, but also part of "protocol selection" or "protocol configuration", like tuning QUIC parameters because you're on a satellite path. * Tom: we have a lot of information about tuning TCP buffers - looking at how QUIC is similar and how it's different would be great * Gorry (on Jabber): this sounds about right * How should we move on with this draft? * Jen asked us to share the document on the list and we can start discussion there # Dynamically Recreatable Keys (draft-garciapardo-panrg-drkey) J. A. Garcia-Pardo * Lightning Filter suitable for high speed connections running on a normal PC * Jen asked that people send comments about this talk to the PANRG mailing list # Path aware routing over MASQUE proxies T. Pauly * Tommy presented some work Apple is doing on routing over MASQUE proxies * Not just providing privacy, but actually getting better performance * Using QUIC, which supports migration, and we're still figuring out how to exploit that * Proxied connections can always be "fast opened" * Think of this as authenticated and validated NATs or routers * New avenues * How do you discover proxies and paths? * Future vision * Ingress proxies * Egress proxies * Overlay networks * Comments: * In Gather, and then on the mailing list