Thanks for all the feedback! It seems like calling the field a Sequence Number field was not the best choice here. It's better to call it Request ID, with no expectation how IDs will be generated. It's just an identifier that the requester sets, and which allows distinguishing multiple concurrent requests (potentially on different paths). A requester may use incrementing IDs, but that's an implementation decision.
> If an endpoint needs to know its public IP address and port, I suppose it needs to know when it changes. Would not it be better to have endpoints automatically send NEW_OBSERVED_ADDRESS frames at the beginning of the connection and when they detect an IP address or port change instead of relying on the request/response semantics in the proposal? Igor, that's an interesting proposal. We could change the logic such that negotiating this extension means that: 1. Endpoints are expected to inform their peer of the observed address after completion of the handshake (or maybe even in Handshake packets during the handshake?). 2. Include a NEW_OBSERVED_ADDRESS frame in probing packets on a new path. 3. Send a NEW_OBSERVED_ADDRESS whenever the remote address changes on a path (e.g. due to a NAT rebinding). We might use the value of the transport parameter to distinguish between "I'm willing to report your address" and "I'm requesting that you send me NEW_OBSERVED_ADDRESS frames". I opened https://github.com/marten-seemann/draft-seemann-quic-address-discovery/issues/7 to track this proposal. > That leads me to wonder if it is the best way to implement this sort of request-response protocol directly on top of QUIC frames. What is the rationale for defining this protocol not on top of QUIC streams, as part of the application protocol? Kazuho, there are multiple reasons: 1. Using QUIC probing frames allows you to use this extension when probing paths, without initiating a path migration. 2. QUIC stacks don't necessarily expose an API to let the application control the path used by a new stream, nor would they necessarily expose an API on the receiver side to let the application observe the path on which a STREAM frame was received. 3. As you noted yourself, we don't have a way to demultiplex multiple application protocols. On Fri, 20 Oct 2023 at 12:51, Christian Huitema <[email protected]> wrote: > Nice draft, Marten. > > I left a minor comment on the GitHub issue -- the draft could say > something about operating in a multipath environment. Not hard, and does > not require changing the proposed formats. > > Not sure that I can implement the draft in time for the hackathon, but I > will give it a try. > > -- Christian Huitema > > On 10/19/2023 3:19 AM, Marten Seemann wrote: > > I just published an I-D that defines a mechanism for QUIC endpoints to > > discover their (public) IP address and helps them determine their > > position in the network (e.g. if they're behind a NAT): > > https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/ > > <https://datatracker.ietf.org/doc/draft-seemann-quic-address-discovery/> > > This is especially helpful for QUIC nodes running in a p2p setting. > > > > A similar result could be achieved by using STUN on the same UDP socket, > > but there are several advantages of doing it inside of QUIC. See the > > draft for details. > > >
