Re: [Spud] discovery

[Brian Trammell <[e-mail]>]

> On 20 Mar 2015, at 04:19, Michael Welzl <[e-mail]> wrote:
> 
> 
>> On 20 Mar 2015, at 03:00, Brian Trammell <[e-mail]> wrote:
>> 
>>> 
>>> On 19 Mar 2015, at 19:21, Michael Welzl <[e-mail]> wrote:
>>> 
>>> 
>>>> On 19. mar. 2015, at 17.18, Brian Trammell <[e-mail]> wrote:
>>>> 
>>>> hi Aaron,
>>>> 
>>>>> On 19 Mar 2015, at 11:48, Aaron Falk <[e-mail]> wrote:
>>>>> 
>>>>> The draft
>>>> 
>>>> ... where "the draft" is draft-hildebrand-spud-prototype ...
>>>> 
>>>>> doesn't say much about how one efficiently determines whether the other end is SPUD-capable so that an application can know whether it can use it.
>>>> 
>>>> No, it doesn't.
>>>> 
>>>>> Has anyone given thought to this?
>>>> 
>>>> Yes, I have...
>>>> 
>>>> I think for the most part that this question is (1) very important but (2) mostly orthogonal to that we're trying to answer in spud-prototype.
>>>> 
>>>> Initially, I would expect that discovery works the same way that it does for any other user of the transport layer: you either have a URL, or a name and a port, or some information from your application-layer protocol's discovery service, which includes "uses x-over-SPUD" in its semantics.
>>>> 
>>>> Dynamically discovering a SPUD endpoint might make sense if a server port / URL schema is assigned to a service over X or a service over x-over-SPUD. In this case, the magic number we've selected makes SPUD server probing by the client possible: a SPUD packet is neither valid UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or Bittorrent. This is not an exhaustive list, but we haven't found a protocol over UDP that is likely to consider d8 00 00 d8 as the first four bytes anything other than an error.
>>> 
>>> - but that won't tell you if SPUD actually does work across the path...
>> 
>> True. But discovery (is there an endpoint there?) is a separate question from path transparency (once you've found the endpoint, can you actually talk to it?)
> 
> Not entirely I think - see below:

The questions are absolutely separate. The way you answer them, not necessarily.

>> This would be an argument for specifying a dynamic discovery method, though -- not for determining whether you should use SPUD, but whether you can.
> 
> So I think, as much as some folks seem to hate it, there really isn't a way around happy-eyeballing...

In general, I don't disagree with this -- let me rephrase it to make sure we're saying the same thing:

"Dynamic discovery mechanisms are necessary at both endpoints to determine both far-endpoint and path-modulated availability of [a new protocol]."

> the reason I say it's not entirely separate ifrom discovery s that happy eyeballs can check availability both on the path and the other end in one go.

Since the point of happy/angry eyeballs is low connection setup latency, yes: the more stuff you can do with the fewer packets the better.

> However, having a separate method that really only deals with the other end can limit how much happy eyeballing one needs to do (i.e.: no point even trying SPUD if the other side doesn't use it).

There's an engineering tradeoff here between robustness and complexity, and I really hope that HOPS and related efforts get us some better insight as to what the exponents are on the types of impairments we hope to see. 

We're trying to run some measurements right now to get some numbers on how likely UDP-based encaps are to make it through the network, and how likely differential treatment of UDP and TCP packets will cause performance issues, as it's the UDP-ness of SPUD that is likely to cause us the most problems initially. (If anyone knows of studies to this question or available data to measure, please let us know. :) )

Cheers,

Brian