Reese Enghardt introduced path properties.
What terms need to be defined in this document?
Brian: We could just continue until we have a stable version and then last call for comments.
Sabine R.: Did you consider adding a point that there are different scopes, relative to which we can provide a defintion?
Reese: Yes we have tried to do that, it’s focussed on the needs of PANRG and drafts that refer to this.
Sabine R.: Is it helpful to qualify the context for key definitions.
Reese: I think we might add endpoint as a definition, if people think it is useful.
Spencer: We scoped the research questions draft to a timeframe, and we could do the same for this draft - “these are the terms now”. Terms that we ought to need in PANRG could be included if we can predict these, but if we can’t, we can publish a current version and start a -bis draft if we need to add things we couldn’t predict.
Gorry: I think “Endpoint” could be defined if we talk about transports. I think we can also talk about “end-to-end” if we refer to transport layer. Maybe we should try this? Shall we raise issues in github?
Reese: Contribution via email and issues are both welcome, I’ll likely turn topics into github issues.
Brian: We should probably find a research group method to determine as many issues as we can - in terms of things that are missing - before the next meeting.
Spencer: discussion in repos can be summarized and reflected to our mailing list using https://github.com/ietf-github-services/activity-summary, so that the people who only follow the mailing list will know, weekly, if there are things happening in tracked github repos that they should look at. I’ve found that to be very helpful in the Cellar working group that I co-chair.
Brian: I’ll send a PR for that during this meeting.
Updated to use the PANRG terminology.
Reese: I read the update and I think it is useful as a check for seeing how this uses the path properties terminology. Can any of the “questions” also be solved in this context? This maybe is a context where we can get some way to answering the research questions.
Brian: As Chair, the question I have is where we are with respect to the topic of path awareness for satellite, and whether that deeper exploration is a different document? Is it a TSVWG document?
Nicholas: There is lots of work needed to make any useful document.
Gorry (as TSVWG Chair): Yes this document was submitted for discussion at TSVWG - but the pushback was that this was at least 2 documents, one was advice to transport … which might be something to work on in future; one something that is about what a satellite path looks like and what characteristics it has/needs to have. This document isn’t being progressed in the current shape.
Gorry (individual): I’d love to refocus on the PANRG topics and bring the path part here, I think it is a much better fit for the IRTF:-)
Brian: Please submit a new revision to discuss next PANRG.
Noted that we’ve had multipath support (at least failover support) for SCTP for more than a decade, MP-TCP support as an experimental RFC since 2013, but TSVWG adopted MP-DCCP at IETF 111, and QUIC hummed to adopt an Multipath QUIC Extension draft at IETF 112. As Martin Duke noted in TSVAREA, multipath is everywhere.
Reviewed RFC9049 “lessons learned” against MultiPath options for QUIC. Spencer’s summary is that this -00 draft avoided almost all of the impediments to deployment that we listed in RFC 9049
Brian: I wonder if we should be worrying about support at both endpoints. In QUIC there was some first adopter benefit; but massive second adopter benefit.
Spencer: I wonder if we should make a document about what to do?
Cyril: (via jabber): I would say that partial deployment heavily depends on the existence of different high-quality paths. If there are no good alternative paths then there is essentially no benefit for MPQUIC.
Spencer: I had a conversation this week with someone who said you can’t get better performance than what the network can give you. We should look at where we are now,
Gorry: What seems like a high-quality path, depends on what scheduler model you desire.
Spencer: There was an IAB Measuring Network Quality for End-Users Workshop (https://www.iab.org/activities/workshops/network-quality/) that might be useful here: see meeting report at https://datatracker.ietf.org/doc/draft-iab-mnqeu-report/.
Gorry: Do applications know what they are trying to achieve? That was a huge stumbling block for some technologies in the past.
Spencer: Yes this is a very interesting thing to look at, can the app tell you what it really wants. This was an RFC 9049 impediment to deployment, and we now understand better that not only is communication between the application and the transport layer about these needs difficult, but that what the application needs can change quickly (when a VR headset user turns her head).
Tianji: There can be proxies for aggregation, whereas QUIC is an endpoint proposal. Have these two approaches been compared?
Spencer: We haven’t talked about why we have not deployed path aware networking involving devices performing aggregation, but the question is useful because the ATSSS in 5G with intermediaries, might in 5 years time, be something that you might want to do with MASQUE intermediaries. This is a really interesting topic for PANRG.
Spencer: one thing I noticed while doing the RFC 9049 analysis of Multipath QUIC is that with a heavily-encrypted transport, many of the past impediments to deployment we’ve identified are changing meaning. We’ve been asked many times for a document that is a companion to RFC 9049, that tells people what TO do. Is this a good opportunity to start working to provide that guidance?
More Multipath
Brian: Supporting endpoint stacks using advanced scheduling is a case of path-awareness. MP-QUIC is a testing ground for that question. Different situations call for different schedulers.
Chris: Consider some phones that try to use cellular or wifi, and the wifi itself could be multipath (could be ATSSS, or some other way), if we assume the IP path and the transport are both multicast the interactions might be complex and we might have different steering policies (even if they both try to achieve the same goal, e.g. throughput, they still might be competing for capacity).
Spencer: For IETF participants talking with 5G folks, “ATSSS” comes up a lot. We discussed ATSSS in the QUIC interim in October 2020, so there might be some context there that’s useful for IETF participants (see https://datatracker.ietf.org/doc/ht…-bonaventure-quic-atsss-overview-00). A lot of the complexity exists here will also be problems that 3GPP will be trying to solve.
Brian: Please send to the list, it would be useful to discuss there.
Other issues for PANRG?
Tianji: Does the device have to know something before it makes a decision?
Brian: It can also infer things from measurements. Can we add more than sensing? I think it’s more than just two interfaces.
Spencer: We talked a lot about signalling in the past, and the definition could be broader than what we first envisaged. The IAB review deck had insight into what might usefully happen next.
Zahed (as TSV AD): We have been discussing mutipath concepts; and multipath protocol-specific work, and where at the IETF/IRTF this might be placed.
Colin (as IRTF Chair): This is a conversation to be had. There are clearly some research issues, the topics could scatter across multiple groups. I’ve a preference for not creating very-specific focused groups.
Brian: There are 2 places in the IRTF: path problems, CC problems, …
Colin: We need to discuss the best place(s) to work on this.
Spencer: We might also need to know how we detect failures, etc.
Spencer: the IAB RG review said that they viewed PANRG as a general venue for IETF-adjacent work on the intersection between TSV and RTG. Given that there are also boundaries between applications and the transport, could PANRG be a general venue for IETF-adjacent work on the intersection between TSV and ART?
Sabine: There is a WG draft in Alto that speaks about a protocol extension to sit between two endpoints and indicate useful information about the path. I will send a link.
Brian: Please do discuss this topic on the list.
-end-