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?
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 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
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
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)
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
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