Subject: [Spud] discovery

From: Aaron Falk <[email-masked]>
Date: Thu, 19 Mar 2015 11:48:11 -0400

The draft 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.  Has anyone given thought to this?

--aaron

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 Mar 2015 11:53:32 -0400

Hi Aaron,

yes and thanks for asking this question on the list.

Don’t have the perfect answer though. But my current answer is: negotiation is done in the higher layer; two clients of the same app might know if the version the other end is using is Spud-enabled.

However, curious to hear more ideas!

Mirja

> Am 19.03.2015 um 11:48 schrieb Aaron Falk <[email-masked]>:
> 
> The draft 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.  Has anyone given thought to this?
> 
> --aaron
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Mar 2015 12:18:45 -0400

hi Aaron,

> On 19 Mar 2015, at 11:48, Aaron Falk <[email-masked]> 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.

Maybe we should mention this in the draft, but I think it's the *next* problem to solve.

Cheers,

Brian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 19 Mar 2015 17:02:05 +0000

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

Agree.

>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 applica…

RFC 3263 provides an existence proof, but probably not a design pattern to follow.

-- 
Joe Hildebrand

---

From: Michael Welzl <[email-masked]>
Date: Fri, 20 Mar 2015 00:21:07 +0100

> On 19. mar. 2015, at 17.18, Brian Trammell <[email-masked]> wrote:
> 
> hi Aaron,
> 

- but that won't tell you if SPUD actually does work across the path...

> Maybe we should mention this in the draft, but I think it's the *next* problem to solve.

to me, this has a "famous last words" feel to it...

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Mar 2015 22:00:41 -0400

> On 19 Mar 2015, at 19:21, Michael Welzl <[email-masked]> wrote:
> 
> 

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

This would be an argument for specifying a dynamic discovery method, though -- not for determining whether you should use SPUD, but whether you can.

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 20 Mar 2015 08:19:50 +0000

> On 20 Mar 2015, at 03:00, Brian Trammell <[email-masked]> wrote:
> 
>> 

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

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Mar 2015 07:47:02 -0400

> On 20 Mar 2015, at 04:19, Michael Welzl <[email-masked]> wrote:
> 
> 

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

> 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

---

From: Michael Welzl <[email-masked]>
Date: Fri, 20 Mar 2015 13:02:21 +0000

> On 20 Mar 2015, at 12:47, Brian Trammell <[email-masked]> wrote:
> 
> 

- 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 w…

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

Cheers,
Michael