Re: [Taps] UDP rendezvous

[Colin Perkins <[e-mail]>]

> On 27 Apr 2020, at 12:38, Michael Welzl <[e-mail]> wrote:
> 
> Hi,
> 
> I’m answering this email, but Magnus, consider yourself answered too with a big THANK YOU for your thorough explanation!
> 
> I agree that we want some (much!) of this functionality “under the hood” if possible. And, of course, I agree that we don’t want the application to be aware of e.g. UDP specifically if we can avoid it. I think we’re all on the same page on that; but I think that, indeed, the text in the API draft needs some fixing.
> 
> Colin, thank you very much for outlining the 5 steps below: they give a very good context for this conversation. So, I answer in line below:
> 
>> On Apr 27, 2020, at 12:23 PM, Colin Perkins <[e-mail]> wrote:
>> 
>> 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
> 
> These two steps are reflected in the API as it stands, and so this is already reasonably clear, I think. IMO, nothing to do here.
> 
> 
>> 3) application shares these candidates with its peer, via out-of-band means, and receives remote endpoint candidates from the peer
> 
> Based on Magnus’ email, I suppose that this *could* be done in standard ways with trickle, and hence theoretically put “under the hood” too.
> But, I think that keeping this in the application space for the sake of TAPS is quite reasonable. This step is perhaps implicit in the text, but I think it’s pretty obvious that it would need to happen. People doing rendezvous will have to be aware of this step anyway, so I see no real problem here.

This has to be done by the applications, since it will involve the signalling protocol (SIP, WebRTC, etc).

>> 4) application adds remote endpoints for the peer’s candidates
> 
> My first hiccup: I don’t see that this is supported in our current API - how would one add remote endpoints? I think, the way we have it, there’s only one for each Connection.
> Have I overlooked something?

They go on the Preconnection. The allow multiple remotes there.

>> 5) application calls Rendezvous(), which performs the ICE-style probing to find a working path, based on the candidates, then returns s Connection
> 
> THIS would be really good, but it’s not at all how I read the current text. It says:
> 
> "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.”
> 
> My interpretation of this sentence is that Rendezvous doesn’t do much more than listen + send something, using the same local ports. For TCP, I would have implemented this functionality by just doing an active connect, using a pre-configured local port (TCP will retry sending SYNs, and if both sides issue this call with the correct ports, I guess it all works out eventually). However, from below, it seems to me that such an implementation would be doing way too little!

It sends the STUN packets to probe connectivity. I read this as “establish a Connection”, but we maybe need to clarify the wording (or just give an additional example).

>> This relies on the Endpoint abstraction supporting STUN, which is maybe implicit in the drafts. 
> 
> Yes - there is text there about STUN configuration, but nothing about it in the Rendezvous text (unless I missed it, apologies if I have!). And it’s not just STUN, it’s the ICE-style probing, with various candidates supplied, that’s missing.
> 
> 
>> 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.
> 
> Okay, I understand this… but what happens if UDP *is* the protocol that is available (not e.g. RTP), and the application calls Rendezvous?
> (I guess failing, with a useful error code, is the best choice, then?)

Applications don’t use raw UDP or TCP – they always run some protocol, however trivial inside it, so there’s a framer.

> Again, just to be clear, I agree with everything you say here, and I thank you (and Magnus) again for explaining it to me!   - I just want to get the text right. Actually, I was just trying to understand how to implement this call’s functionality, and was left puzzled.
> 
> Cheers,
> Michael

Cheers,
Colin



-- 
Colin Perkins
https://csperkins.org/