Subject: [Taps] Follow-up on TTL+multicast send question

From: "Holland, Jake" <[email-masked]>
Date: Sat, 30 Mar 2019 08:16:40 +0000

Hi taps,

At the mike, I believe Gorry asked whether I need sender TTL,
and I replied "Yes."

I want to add a little nuance to that:

I think a default value for TTL that reaches remote receivers
is probably the right choice, so that it's an optional setting
(as opposed to today's default of 1 for multicast packets, which
you have to always set if you want non-LAN traffic).

I think asking application developers to choose an integer
value is almost certainly harmful, to the extent it has any
effect.  At least, I'm certain that when I've set the value
out of necessity, I have done so in an entirely unprincipled
way, with a goal best phrased as "works for me".  (Though I
think some people might have real reasons they'd pick specific
values, so maybe it has to be allowed.)

Some sending use cases are for LAN only (e.g. many discovery
and hello protocols), and I think that's why the default for
multicast when sending from sockets is TTL=1, and you have to
change it--if you forget to set it, you won't blow anything out,
you'll just say "huh, I guess multicast doesn't work".

I think that probably made sense back when people still thought
dense-mode and global source-active announcements might be a
good idea, but now maybe it doesn't have to be that way.  (Or
if anybody thinks that's unsafe, maybe only for ASM?)

Anyway, I think in my perfect world, sender TTL for multicast
UDP would default to a system-overrideable high value named "global"
something, with a corresponding system-overrideable low value named
"local" something defaulted to 1, and maybe (if anyone cares) a
middle thing named "site" something, and maybe even all the rest of
the scopes if you can find me someone who uses them that I can talk
to.  (And for IP6 these could be inferred and defaulted from the group
address's scope[1], with optional override.)

Something like that would be way better IMO (as an app dev and/or
network admin) than our default TTL=1 world in BSD sockets.

But all we really need is a local/not-local selection, and somebody
probably does really need to be able to pick a specific value sometimes,
because people are just that crazy.  (And I would be totally comfortable
with making that a privileged operation, btw, if we've got such a
concept...)

I'll fold this into my #150 resolution proposal[2] when I get there,
but I wanted to kick off discussion on this point if anybody has
opinions.  So please comment if this email makes any sense to you, or
ask questions if it doesn't.

Best,
Jake

[1] https://tools.ietf.org/html/rfc7346#section-2 
[2] https://github.com/ietf-tapswg/api-drafts/issues/150