Hi Michael, (This is intended as an individual contribution)
So I a bit thin on the TAPS context for your discussion her. However, the part of the UDP rendezvous I have more familarity. So lets discuss this from the context of ICE (RFC 8445) and especially with the Trickle (https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/) and PAC ( https://datatracker.ietf.org/doc/draft-ietf-ice-pac/) extensions. You maybe also have to consider if the interface needs to cater for rendezvous servers and such protocols, like TURN (RFC8656) or HIP. These protocols basically moves your UDP listener port to a relay server, i.e. you suddenly have a UDP port with a address and port beyond the local host. I note that these ports can have some filtering behaviour on them. For example TURN needs you to send outgoing traffic towards the address + ports from where you like to receive traffic. So an easy answer would be say that this is all application land, and then I think you are throwing away a lot of the functionality of TAPS interface. As you basically need one or more UDP sockets with a listener and tight sending capability. However, if one actually like to have an interface that tries to do the best here. Then one maybe like to have an API with baked in ICE functionality. Thus requesting an UDP port with rendezvous capabilities would require configuring STUN and TURN servers. The STUN and TURN server configuration would be to learn the hosts server reflexive candidates and relay candidates. Then generating ICE credentials, receive peer(s) credential, and a list of candidates (potentially empty initially). And with Trickle your list of remote peer candidates will be dynamically updated over time. It would also require asynchronous feedback towards the application as the layer learn more candidates for reaching the local application. I would also note that the timeout horizon for these operations are a minimal of approximately 40 seconds and depending on candidate additions etc it can grow to several minutes. There is also the mode when one would basically prepare a UDP port for rendezvous, which would mean gathering candidates, establish relay server candidates etc but simply hold waiting for remote candidates and during that time maintain these candidates which requires periodic keep-alive messages. So this may be way beyond what you asked for. However, normal listening UDP has limited utility in the face of stateful firewalls. Cheers Magnus Westerlund On Sat, 2020-04-25 at 14:44 +0200, Michael Welzl wrote: > Dear all, > > 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 -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: [email protected] ----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
