Re: [Taps] UDP rendezvous

Michael Welzl <michawe@ifi.uio.no> Mon, 27 April 2020 13:43 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373763A0ACA for <taps@ietfa.amsl.com>; Mon, 27 Apr 2020 06:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N24YDBMHIfPW for <taps@ietfa.amsl.com>; Mon, 27 Apr 2020 06:43:22 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BAA3A0AC9 for <taps@ietf.org>; Mon, 27 Apr 2020 06:43:21 -0700 (PDT)
Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1jT42Y-000Aqa-UP; Mon, 27 Apr 2020 15:43:18 +0200
Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from <michawe@ifi.uio.no>) id 1jT42U-0009Fi-81; Mon, 27 Apr 2020 15:43:18 +0200
From: Michael Welzl <michawe@ifi.uio.no>
Message-Id: <061B4D0A-EB81-4BC8-ABF0-8ACA3E2FFA36@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B9A37066-282A-4B2A-971C-C53899622E75"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 27 Apr 2020 15:43:13 +0200
In-Reply-To: <91F3869D-D908-489F-82E2-2BEADA357C2A@csperkins.org>
Cc: "taps@ietf.org" <taps@ietf.org>
To: Colin Perkins <csp@csperkins.org>
References: <B04764EF-FD10-45A0-9080-0A84C21107C1@ifi.uio.no> <A8590FF8-9905-4942-845B-0F38510D101B@csperkins.org> <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> <91F3869D-D908-489F-82E2-2BEADA357C2A@csperkins.org>
X-Mailer: Apple Mail (2.3445.104.14)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4];
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 17D28DAE1232D8F5251914BBD9739E9CE5B553C0
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/yNlOXI6LfDCUXcORg0gn8cSzJiw>
Subject: Re: [Taps] UDP rendezvous
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 13:43:26 -0000


> On Apr 27, 2020, at 1:55 PM, Colin Perkins <csp@csperkins.org> wrote:
> 
> 
> 
>> On 27 Apr 2020, at 12:38, Michael Welzl <michawe@ifi.uio.no> 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 <csp@csperkins.org> 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).

Ok; got it.


>>> 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.

Aha!
(yes that’s allowed, I saw that text now)


>>> 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).

I think so. To me, as someone who only has a faint idea of how these things work, “establish a Connection” would have been way less than that. Or, something else: AFAIK STUN is only use to the STUN server, but one wouldn’t use STUN packets to then try to connect to the peer, right? Rather SIP, or something.  VERY sorry if this is all a silly misunderstanding on my behalf, which is quite possible!


>>> 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.

… okay, so you’re saying the sender-side framer could supply that first type of message that is sent to the peer when rendezvous() is called (and the first one to expect from the peer)?  That would sound reasonable to me - but, I thought framers are associated with a Message (or, rather, its messageContext) - but we’re not sending a Message yet. Shouldn't the rendezvous() Action have optional Message and messageContext parameters, 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
> 
> Cheers,
> Colin
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>