Re: [Taps] UDP rendezvous

[Michael Welzl <[e-mail]>]

Hi,

Thanks again!  I knew that WebRTC plays all these tricks but must admit to never having dug into the ICE details.
Regarding “where the WG is in regards to…” - I think Colin’s previous email with the 5 steps is a good summary of what TAPS is intending to do wrt. rendezvous mechanisms.

Cheers,
Michael


> On Apr 27, 2020, at 2:59 PM, Magnus Westerlund <[e-mail]> wrote:
> 
> Hi,
> 
> Michael if you want an example of an API that contains the ICE related
> rendezvous aspects it is the WebRTC. https://www.w3.org/TR/webrtc/
> 
> You will find the ICEserver with configuration information. Note also how
> candidates are handled. I would also note the possibility to enable or disable
> trickling of candidates. Which is possibly something an application could want
> to indicate. I know the ICE parts is only a part of the complete WebRTC API so
> there is a lot to wade through here. 
> 
> 
> I would also note that there might be an other aspect of embedding ICE under the
> hood is the potential to use this as a method to update the path used between
> two peers during an ongoing communication session. There are two takes on this.
> Either the more standards compliant way of triggering an ICE restart, which
> involved application interaction through a new candidate exchange. 
> 
> Or the less so which is to not really terminate ICE. And instead keep your
> checklist alive and continously verify what candidate pairs that actually work
> and use re-occuring nomination to move the application datagram flow between
> working candidate pairs (
> https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/). I would
> recommend avoiding the later, but wanted to mention it for completeness. 
> 
> As I haven't been active in TAPS, I would appreciate any pointers to where the
> WG is in regards to the need for parameter exchange that need to be done by the
> application using the TAPS interface, rather than letting the lower layers
> handle that aspect. 
> 
> Cheers
> 
> Magnus
> 
> 
> On Mon, 2020-04-27 at 13:38 +0200, Michael Welzl 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.
>> 
>> 
>>> 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?
>> 
>> 
>>> 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!
>> 
>> 
>>> 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?)
>> 
>> 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
>> 
>> _______________________________________________
>> Taps mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/taps
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>