Nice document and good arguments against using STUN. I agree it should be a (random-ish) request ID rather than sequence number. Text currently says a re-transmitted request has to increment the (sequence) number but changing the value on retransmit seems unnecessary for the address discovery to work? If it is necessary, it will need motivation.
-d > On Oct 20, 2023, at 12:42 AM, Marten Seemann <[email protected]> wrote: > > 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: > 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?). > Include a NEW_OBSERVED_ADDRESS frame in probing packets on a new path. > 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: > Using QUIC probing frames allows you to use this extension when probing > paths, without initiating a path migration. > 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. > 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] > <mailto:[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. >> >
