Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

[Brian Trammell <[e-mail]>]

> On 22 May 2016, at 21:34, Michael Welzl <[e-mail]> wrote:
> 
> Hi,
> 
> I’m sorry for derailing this a little - it isn’t so relevant to the BoF, but I’d really like to answer this part of the discussion:
> 
>> On 20. mai 2016, at 12.32, Brian Trammell <[e-mail]> wrote:
>> 
>> 
>>> On 19 May 2016, at 21:17, Tom Herbert <[e-mail]> wrote:
>>> 
>>> On Thu, May 19, 2016 at 11:27 AM, Toerless Eckert <[e-mail]> wrote:
> 
> (snip)
> 
> 
>>> With something like SPUD (basically anything not simple TCP/IPv4) we
>>> are always faced with the same problem that some networks on the
>>> Internet may arbitrarily drop or otherwise restrict packets (we know
>>> for instance that some network operators choose to severely rate limit
>>> all UDP because of DOS concerns).  So even if we do manage to start
>>> deploying transport protocols over UDP we are going have TCP as a
>>> fallback for indefinite future, i.e. more happy eyeballs.
>> 
>> Yes, and if we do manage to start deploying transport protocols over IPv6, we are going to have IPv4 fallback for an indefinite future. I share your concern about happy eyeballs state explosion (a phenomenon we refer to around the office as "angry eyeballs" -> eight orthogonal network/transport layer choices to test at startup means that every flow begins with a 256 packet burst)... but the benefit of doing this to transport flexibility is potentially worth the cost, which is the fundamental question we want to address in PLUS.
> 
> I have a problem with this “angry eyeballs” thing: it’s assuming a very simplistic happy eyeballing algorithm and, by calling it names, gives the impression as if the described problem was universal to all possible happy eyeballing algorithms - which isn’t the case.
> 
> For example: we often surf to the same websites, which are often on CDNs, on a path that doesn’t change very much. So if my computer would happy eyeball slowly and store information in its cache, that information is potentially valid and useful for a LONG time. Then, why not use the favored transport *only* as long as the cache hasn’t expired, and then try fall-backs if things fail?  Also the multiplicative effect that you’re pointing at can be circumvented. E.g., if TCP doesn’t work over IPv6, it doesn’t make much sense to try a different transport over v6… so the number of tests can be gradually reduced.
> 
> I’m just giving examples to say that much more reasonable mechanisms than the one that you sketch here could be devised. Happy Eyeballing doesn’t *need* to be “angry”.

I agree with you here. There are lots and lots of ways to keep the state manageable. For example, quite a few impairments you might want to happy-eyeball around seem to be linked to access networks, as opposed to impairments along the path. For these, caching information on a per-interface / per-connection-profile basis amortizes the measurement overhead quite well.

I think it *is* our responsibility, though, in standardizing things that might not work everywhere, to carefully specify how the measurement of multiple features should work, because the naive implementation of these measurements done in an ad-hoc way, or designs which do not carefully consider the tradeoff between cache management overhead and network overhead, lead to the worst case, which does deserve the name.

Cheers,

Brian

> 
> Cheers,
> Michael
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud