In #588 we clearly describe the relation between PacketNumberSpace and PathData. This also surfaces that we have been putting data in the wrong structs:
And also a lot of related things like PathStatus in paths.rs file are in the wrong place. The connection::paths module is awkward since it talks about network paths, not multipath paths.
In general I think using the following two terms might be desirable:
- path for a multipath path identified by a
PathId. If possible try and prefer space as that can be less ambiguous. Space is short for packet number space and includes the Initial and Handshake spaces which is fine in many contexts.
- 4-tuple for a network path.
It might even be desirable to aim for changing the entire module structure, e.g.: move PathData into
connections::space::four_tuple::FourTupleData. But more or better ideas here are welcome.
This issue should almost certainly be split up into sub-issues.
In #588 we clearly describe the relation between
PacketNumberSpaceandPathData. This also surfaces that we have been putting data in the wrong structs:PathData::off_path_challenges_unconfirmedPathData::statusPathData::open_statusPathData::drainingPacketNumberSpace::ecn_countersPacketNumberSpace::ecn_feedbackAnd also a lot of related things like
PathStatusinpaths.rsfile are in the wrong place. Theconnection::pathsmodule is awkward since it talks about network paths, not multipath paths.In general I think using the following two terms might be desirable:
PathId. If possible try and prefer space as that can be less ambiguous. Space is short for packet number space and includes the Initial and Handshake spaces which is fine in many contexts.It might even be desirable to aim for changing the entire module structure, e.g.: move
PathDataintoconnections::space::four_tuple::FourTupleData. But more or better ideas here are welcome.This issue should almost certainly be split up into sub-issues.