Re: [Spud] discovery

[Michael Welzl <[e-mail]>]

> On 20 Mar 2015, at 12:47, Brian Trammell <[e-mail]> wrote:
> 
> 
>> 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. 

- I think we agree on everything here.


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

I don't but I think this is a very cool thing to test! Curious to see the results!

Cheers,
Michael