new paragraph on use cases in intro

[mirjak]

fixes #512

[gorryfair]

Looks better to me, thanks.

[LPardue]

Perhaps avoid using address here since it means something different to the earlier address discovery mention

[martinduke]

Thank you for this text.

[larseggert]

Suggested change

	Simultaneous path usage generally, however, needs more consideration
	than specified in this document to avoid negative performance
	impacts, e.g. when stream data is distributed over multiple paths with
	different delays.
	Simultaneous transmission on multiple paths is not supported by the extensions defined
	in this document. It requires substantially more machinery than defined here
	to avoid negative performance impacts, e.g., when data is to be transmitted
	over multiple paths with different characteristics.

[mirjak]

@larseggert this sentence is simple not true. Of course you can send simultaneous which the protocol specified in this doc and we say that multiple times also in the abstract. Also we want people to experiment with that.

[larseggert]

I thought we agreed that this doc should call out that it is not a complete multipath solution at PS level. "Can experiment" to me sounds again like this should be Experimental?

[mirjak]

This is covered already in the previous paragraph where it does say that this extension does not "define
how multiple, simultaneously open paths are used to send packets" (and always did). However, there is nothing in this spec that stops people from using multiple paths, so your sentence is simply incorrect. Also we want to enable that; I thought we just agreed to add a warning.

[mirjak]

@gorryfair @martinduke any further comments from you side (as you approved the PR already as is)?

[LPardue]

I agree that's good suggestion and I've proposed text to that effect in #520

[huitema]

I wrote a small note on the subject of multipath and congestion control. I do not think that RFC 9473 applies to scheduling algorithms. Scheduling algorithms define which packets goes on what path, and there are very many algorithms that could be tried, such as:

• associate QUIC streams to specific paths, so as to minimize the amount of reordering between packets received on the same path (some folks do that with picoquic)
• or, spread packets of a long stream on multiple paths, based on whichever path has congestion control credits available at time of scheduling (picoquic does that by default)
• or, send a stream twice, with one copy on each path, to get the best delivery delay,
• or, use some kind of FEC, send a stream on one path and redundant FEC packets on the other, to get the best delays without being too piggish.

All of those have been experimented. All depends on following whatever limits are imposed by per path congestion control.

[gorryfair]

This raises an interesting question about the maturity of the method. To me the list above suggests experimental use. I see aligns with the suggestion to revisit the document status: If the desire is to publish as EXP, then I still think that RFC 9473, is relevant to specifying future standards-track methods.

[mirjak]

As spelled out clearly in the intro now, this spec does not cover packet scheduling. The parts that are covered by the spec, which are the frames and machinery for path management, are mature and well tested. And that was the discussion we already had before we adopted the document, that we only cover the parts that can be well tested and enable opening and closing of paths but do not cover paths usage (as well as address management) and explicitly leave this open for future work.

[LPardue]

PRs are not the appropriate place for these discussions so I've locked it down.

Please open separate issue(s) if there are other points to follow up with.

[qdeconinck]

Minor nits but for the rest, good to ship.

[mirjak]

I'm merging this PR as several people have approved it. As indicated by the chair, for further comments please open new issues and we can work on another PR if needed.