Hi, This is one of the areas where the drafts likely need expanding, but I think the model is:
1) application configures STUN (and maybe also TURN) local endpoints 2) application calls Resolve() on these, to find server reflexive candidates 3) application shares these candidates with its peer, via out-of-band means, and receives remote endpoint candidates from the peer 4) application adds remote endpoints for the peer’s candidates 5) application calls Rendezvous(), which performs the ICE-style probing to find a working path, based on the candidates, then returns s Connection This relies on the Endpoint abstraction supporting STUN, which is maybe implicit in the drafts. Also, as usual with TAPS, the application doesn’t say that it wants UDP. It says it wants, e.g., RTP preferably over an unreliable connection, and this higher-level protocool gives the de-framer the ability to distinguish the STUN packets from the data packets. Colin > On 25 Apr 2020, at 13:44, Michael Welzl <[email protected]> wrote: > > I know way too little about rendezvous mechanisms, so I may get this > completely wrong - please bear with me! > It may be that I describe an issue that’s a non-issue. But, if I do > understand this right, maybe that’s something which needs fixing? > > Ok, here it goes… > > Our current Rendezvous text in the API draft says the following: > "The Rendezvous() Action causes the Preconnection to listen on the Local > Endpoint for an incoming Connection from the Remote Endpoint, while > simultaneously trying to establish a Connection from the Local Endpoint to > the Remote Endpoint. This corresponds to a TCP simultaneous open, for > example.” > > Now, if an application chooses unreliable data transmission, it may get SCTP > with partial reliability, or it may (in the future) get QUIC with datagrams, > or whatever… and then, the protocol may be able to do what’s needed > (something similar to a simultaneous open). > > However, in case of UDP: > - Listening is quite okay, > - “simultaneously trying to establish a Connection” really means nothing - no > packet will be sent. > > I believe that applications doing this over UDP will implement their own > “SYN”-type signal for this - but then it’s up to the application, which, over > TAPS, would need to: > - create a passive connection, > - send a Message from that same connection, i.e. using the same local address > and port (I believe?) - which is a matter of configuring the local endpoint, > and doable if the underlying transport system can pull it off. I think > there’s nothing in our API preventing an application from doing this. > > If all of the above is correct, the problem that I see is that an application > may ask for unreliable transmission, and then have one case in which calling > “Rendezvous” is the right thing to do, and another case in which it is not - > so it would need to be able to distinguish between these two cases: is it a > protocol with Rendezvous-capability, or do I have to do it myself. Maybe, in > case of UDP, the call to Rendezvous should just fail, and our text should say > that Rendezvous failing would inform the application that it would have to > implement it by itself, by issuing Listen and then sending a Message to the > peer. > > Thoughts? Am I completely off track, or is this something that needs a text > fix? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps -- Colin Perkins https://csperkins.org/ _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
