Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

[Lorenzo Colitti <[e-mail]>]

On Wed, Apr 22, 2015 at 2:02 AM, Erik Nordmark <[e-mail]> wrote:

> With unsolicited RAs the host would be waiting up to 15 minutes (or 6
> hours with a larger maxra) for a the next unsolicited RA. With RS refresh
> it would send a new RS after a second.


Oh, I see what you mean now. But I think you are assuming that unmodified
hosts will simply ignore periodic multicast RAs, and then not send an RS
when they wake up. That sort of behaviour is a violation of the standard
(because the host is not processing the multicast RAs) and is guaranteed to
cause breakage.

Also: I'd argue that nothing stops a node from sending RSes using the
resilient RS retransmit algorithm when it wakes up (see below). You don't
need any of this document for a host to be able to do that.


> If what you're saying is that the sleeping node is going to ignore RAs
>> anyway, then you don't need an RS refresh option for the node to send an RS
>> and receive an RA when it wakes up. That's already possible.
>>
> There is no RFC which suggests or recommends sending a RS after wakeup.
> RFC 4861 is very prescriptive on when RS can and can not be sent.


RFC 4861 says a host can send an RA when it "re-attaches to a link after
being detached for some time". I'd argue that's the case here. The host is
in effect disconnected, because it's asleep and not processing multicast RA
(and maybe not even unicast packets). If you think hosts might not do that
because it's not clearly allowed by the standard, then fine, let's clarify
the standard. But we don't need to change the semantics.


> The document says that if you want to reduce multicast, you can increase
>> the RA interval. Personally, I don't think that makes sense, because one RA
>> every half hour is a tiny amount of traffic, which is trivial on any
>> general-purpose network.
>>
>
> IPv6 needs to apply to a large range of network technologies, just like
> IPv4 does.
> I think that is the fundamental disconnect here.


IPv4 applies to a large range of network technologies not because of the
standards, but because implementations are, let's say, "creative". For
example: ARP is a broadcast packet, right? In how many networks is ARP
*actually* a broadcast that goes to everybody? I'd argue that there is no
large wireless network where ARP is actually broadcast - because if there
were, that network would fall over. :-)


>     Are you arguing that all your points in the draft need to be
>>     addressed to your satisfaction before it can even become a WG draft?
>>     That isn't how an IETF working group is supposed to operate.
>>
>> No. I am worried that this document cannot meet its goals, and even if it
>> does not, after adoption we will be unable to abandon it and instead ship
>> something that does not meet its goals.
>>
>> Perhaps the issue here is that we don't agree on a problem statement, or
>> more accurately, what we're trying to accomplish with this drafts.
>>
>
> You've said that for > 2 years now, but never provided any useful
> suggestions.
>

But it's impossible for me, or anyone else, to provide a useful suggestion
without a problem statement.

This document proposes a solution. I don't like this solution because I
think it is not useful except if limited cases, and in some cases it is
harmful, and I think that on balance, the harm outweighs the good. So I
ask: "Why do we need this? What justifies a change to the IPv6
configuration model, such that we're changing it from a pure push model to
a hybrid push/pull model and possibly to a pull-only model? Why are we not
carefully considering the reasons for making the change, and instead only
documenting the change without asking ourselves why?"

Suppose for the sake of argument that your draft isn't actually solving any
real problem. There would be no suggestion anyone could possibly make other
than "please describe the problems that need to be solved, and let's design
a solution together". And I don't think "I waited two years and there were
no useful suggestions, so we should adopt this solution" is an argument
that makes sense.

Assuming it has actually been two years, then in those two years I can
recall the following use cases:

1. Mobile network paging channel excessive usage. I think the numbers in
that argument were dubious, because in any mobile network today the vast
majority of devices is sending packets *way* more often than one every half
an hour. But even supposing they weren't, that problem can be fixed by
increasing the maximum RA interval and/or piggybacking RAs onto unicast
traffic, and/or sending an RA to the node opportunistically right after the
node sends a packet and thus has the channel grant.

2. Excessive multicast use on wifi. Most of this problem problem can be
solved by sending solicited RAs unicast. RA isn't really a high-order
contributor to this problem anyway - bonjour is much worse, and so is ARP.

3. Low-battery nodes. Here you can construct an argument that justifies
anything: all you need to do is posit the existence of a node whose
constraints make it a poor fit for the periodic RA model, and then decide
to optimize for that node. For example, you can posit a node that is
super-constrained, whose battery has to last years of sending one packet
per day, but cannot disconnect because it needs to receive unicast packets
on someone else's schedule instead of the natural option for a constrained
device of *disconnecting* and only polling periodically. Even here, though
- why are these devices not using special link layers? For example, 802.11
in particular is terrible at power consumption for this sort of device.
It's a high-speed technology intended to provide XXX megabit speeds, not
optimizing low power. Why are we trying to use it?

I have repeatedly suggested: let's look at the *real* harm in these cases,
and let's see how far we can go without changing the protocol. But I think
you've just kept coming back with suggestions on how to fix the protocol
without first discussing how and how much it's broken.