Subject: [babel] Cutoff date for rfc6126bis is 3 July

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Jun 2017 19:26:39 +0200

Dear all,

The I-D cutoff date is 3 July, and I'd really like to get any major new
features into rfc6126bis by that date.  I feel that the document is mostly
complete with the significant exception of Unicast Hellos.

Is there an implementation yet?  Are we ready to write it down?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Jun 2017 10:28:55 -0700

I was planning on working on that this week.
First an implementation, and once it works a proposal for RFC text.
I'll do my best to have that ready by Friday.

David

> On Jun 13, 2017, at 10:26, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Jun 2017 22:40:45 +0200

> I'll do my best to have that ready by Friday.

Excellent.  Let me know if you want to have a chat on the phone or on IRC.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 13 Jun 2017 23:43:12 +0200

> Is there an implementation yet?  Are we ready to write it down?

Not a complete implementation, but I managed to get something
rudimentary to work. Pushed here:

https://github.com/tohojo/bird/tree/babel-unicast

Basically, what this does is:

- Change the first byte of the reserved part of the hello TLV to be a
  flags field and define a unicast flag (0x20) to indicate unicast
  hellos.

- If configured to do so (there's a per-interface 'prefer unicast'
  config option), whenever a new neighbour is acquired, send a unicast
  hello (flag set, unicast packet dest, per-neighbour sequence number)
  to that neighbour.

- Upon receiving a unicast hello, if 'prefer unicast' is enabled on the
  interface, switch that neighbour to unicast mode, reset the hello
  history and immediately reply with a unicast hello in return. If
  unicast mode is disabled, just ignore the TLV.

- When a neighbour is in unicast mode, completely ignore all multicast
  hellos from that neighbour and don't multicast IHUs to it. There is no
  way to switch back to multicast mode short of losing and re-acquiring
  the neighbour completely.

Because a peer is only switched into unicast mode upon receiving a
unicast hello, the initial unsolicited unicast hello acts as a probe. If
no unicast hello is ever received in the other direction, everything
continues as before; but if it is, the nodes will effectively have
negotiated unicast mode and continue that way.

As I said, the implementation is quite rudimentary. But it works so that
two nodes can successfully negotiate unicast mode and switch over; or
stay in multicast mode if one or both have the config option switched
off. However, I have not tested how robust this is on a real network.

Right now I'm just sending a unicast hello to every unicast mode
neighbour whenever I'm sending multicast hellos, and send an IHU after
every unicast hello. Planning to make that smarter (at the minimum,
allow separate intervals for unicast and multicast hellos), and also to
add an option to send all other TLVs as unicast to unicast neighbours;
and probably a config option to add unicast peers without having to
discover them via multicast (for links that don't support that at all).
But that is not really that important for the protocol spec, I figure...

As far as the protocol spec is concerned, I suppose the flag and the
"mode switch" need to go into the RFC. Don't really see much of a use
case for "mixing" unicast and multicast cost estimation for the same
neighbour, which is why I went with the simple option of just switching
mode.

I can propose some text once someone else has confirmed that this way of
doing things is not completely daft...

-Toke

---

From: David Schinazi <[email-masked]>
Date: Wed, 14 Jun 2017 22:45:05 -0700

Hi everyone,

I finally got some free time to spend on Babel and brought my implementation up to speed,
it now supports mandatory sub-TLVs, which were easy to add.

I've also added support for unicast Hellos, which I've renamed Personal Hellos.
I thought unicast/multicast were IP-level concepts and since these Hellos have more
interesting properties than their destination IP address, I named them
- Public Hellos -- which are multicast and equivalent to RFC6126 Hellos
- Personal Hellos -- which are unicast

I went with an approach different from Toke's, of having both of them co-exist.

On the outgoing side, nodes now have a per-interface Public Hello seqno
(which renames the previous per-interface Hello seqno) and
a (new) per-neighbor Personal Hello seqno.

On the incoming side, nodes now keep two sets of Hello timer/history/interval/expected seqno
per neighbor, one for Public and one for Personal. This allows computing two independent
costs, and they are combined to create the actual link cost.

Regarding packet encoding, I renamed the Reserved field in Hello TLVs to Flags,
and added a PERSONAL flag (hex 8000).

Adding this to my implementation was pretty straightforward, and it seems to work well.
I haven't had time to play with many different values for the timers,
or to come up with fancy cost computation techniques, but as these are
implementation-specific, it doesn't block discussion of the specification.

I think this approach has the advantage of
- not needing negotiation (feature negotiation isn't in the spirit of Babel today)
- not needing modes of operation (from experience, these always cause bugs where
    two nodes disagree on what mode they think the other is in)

Regarding backwards compatibility, I think we could deploy a quick fix in today's
implementations: simply ignore Hello TLVs with the Personal flag. This can be
done alongside mandatory sub-TLV support. Implementations can then take
their time to support Personal Hellos.

I took a jab at writing this up, and pushed it to the repository:
https://github.com/jech/babel-drafts/pull/3/files <https://github.com/jech/babel-drafts/pull/3/files>

It's a very early draft, but I think it conveys a possible solution.

Let me know what you think!

Thanks,
David Schinazi

> On Jun 13, 2017, at 14:43, Toke Høiland-Jørgensen <[email-masked]> wrote:
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 15 Jun 2017 11:14:50 +0200

> - Personal Hellos -- which are unicast

For some reason I *really* don't like those names. Not sure why; too
anthropomorphic, perhaps? Anyway, that aside...

> I went with an approach different from Toke's, of having both of them

Yeah, I guess you are right that just having them co-exist is better.

> Regarding packet encoding, I renamed the Reserved field in Hello TLVs
> to Flags, and added a PERSONAL flag (hex 8000).

I guess there's an implicit network-to-host byte order here; is that
always obvious when the field is not an integer field? That was the
reason why I opted for a 1-byte flags field. In either case we should
probably at least pick the same flag value... ;)

> It's a very early draft, but I think it conveys a possible solution.

A few things that I'm not sure are well-defined currently; consider
these questions that should be resolved:

- Is it allowed to not send multicast hellos at all (I think it should
  be)?

- Is it legal for an implementation to completely ignore one type of
  hello (probably should be, but could be problematic if we don't
  guarantee that they are both always available, see below)?

- Is an implementation allowed to stop sending unicast hellos to a
  neighbour after it started doing it? This could be problematic if the
  other neighbour relies only on unicast to define neighbour
  availability.

- When should a neighbour entry be expired? When we stop receiving
  multicast hellos, or when we stop receiving any one type?

- Should we recommend that IHUs be send the same way as the hello was
  received?

-Toke

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Jun 2017 11:15:52 -0700

Thanks Toke, responses inline.

> On Jun 15, 2017, at 02:14, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 

[DS] I'm totally open to changing these, can you propose something other
than unicast / multicast?

> probably at least pick the same flag value... ;)

[DS] I had the same thought, here's a clearer writeup based on the IKEv2 RFC

   The Flags field is interpreted as follows:
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |P|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   In the description below, a bit being 'set' means its value is '1',
   while 'cleared' means its value is '0'.  'X' bits MUST be cleared
   when sending and MUST be ignored on receipt.

   o  P (PERSONAL) flag (8000 hexadecimal): if set, then this Hello
      represents a Personal Hello, otherwise it represents a Public
      Hello.
I used 8000 because that's the leftmost one and in the Update TLV we started from the left.

>  multicast hellos, or when we stop receiving any one type?

[DS] I think the answer to these are intertwined. I see 3 aspects that we can optimize for:
- flexibility on the sender
- flexibility on the receiver
- interoperability between implementation strategies
but we can't have all of these. I was initially thinking mainly about interop,
so on possible answer to these could be:
(1) always send Public hellos (you can set the interval to 11 minutes)
    this allows interoperability with Public-only implementations
(2) implementations can choose to ignore all Personal Hellos
    this makes it easy to make existing implementations compliant
(3) implementations cannot ignore Public Hellos
    this allows interoperability with Public-only implementations
    implementations can give very high costs to neighbors with only Public Hellos
(4) if an implementation decides to use a given type of Hello, they MUST honor
    the interval value they set (and keep sending) if they want to participate
    (this is already somewhat implied by the definition of the Interval field)
(5) if we have received no hellos (neither Public nor Personal) from a neighbor
    we MUST set their cost to infinite, and that's a good time to consider expiring them

The downside of this is that it forces Personal Hello implementations to still support
Public Hellos.

Another strategy could be to change
(1) nodes may decide to only send Personal Hellos
(3) implementations may ignore all Public Hellos
and add a note saying that doing so prevents interop and requires an external
discovery mechanism.

What do people think?

> - Should we recommend that IHUs be send the same way as the hello was

[DS]  What's the rationale? Getting the multicast state of the link
in both directions isn't particularly helpful the routing decisions
mainly apply to unicast traffic.

Thanks,
David Schinazi

---

From: "Russ White" <[email-masked]>
Date: Thu, 15 Jun 2017 14:43:25 -0400

> than unicast / multicast?

What is wrong with unicast/multicast? I must have missed why these are bad labels?

😊 /r

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Jun 2017 21:08:20 +0200

I need some more time to grok the fullness of the two proposals, but here
are a few thoughts:

Multicast/Unicast Hellos seem fine to me, I don't see any opportunity for
confusion.

There seems to be consensus to using a bit in the (newly defined) Flags
field.  I'm fine with that, if anyone has strong feelings, please yell
now.

I'm of opinion that we must support the Multicast Hellos-only case
(meaning that an implementation MUST grok Unicast Hellos, but it MAY send
Multicast Hellos only).  I'm also of opinion that we must support the
Unicast Hellos-only case (e.g. for NBMA links, where discovery is done by
means external to the protocol -- Margaret, that's your hint).

We must be extremely clear about the meaning of the intervals in Hellos.
Does the Interval field of a Multicast Hello carry a promise to send
another Multicast Hello, or does it carry a promise to send a Hello of any
kind?  (I believe that we need to implement it before you can have an
opinion.)

I've glanced across David's pull request, and it looks fine to me except
for the issue in the last paragraph above.  Toke, I'd be grateful if you
could read it and let me know if there's anything in it you feel is wrong,
or anything you wish to add.  We want to get this or something similar
merged and published in an I-D before the Prague cutoff (3 July).

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Jun 2017 13:47:43 -0700

Thanks Juliusz, responses inline.

David Schinazi

> On Jun 15, 2017, at 12:08, Juliusz Chroboczek <[email-masked]> wrote:
> 

[DS] I can live with that. I'll give people a few days to comment on this and
I'll update the branch.

> means external to the protocol -- Margaret, that's your hint).

[DS] If we're supporting Multicast-only and Unicast-only, then these will not
interoperate. That's fine by me, we'll just need to add text to make that clear.

> kind?  (I believe that we need to implement it before you can have an

[DS] The way I implemented it (and what I tried to convey in the spec) is
that the Interval and Seqno is specific to a Unicast vs Multicast. This is
what I had on that topic for the Hello TLV:
Interval  An upper bound, expressed in centiseconds, on the time
          after which the sending node will send a new Hello TLV with
          the same setting of the PERSONAL flag.  This MUST NOT be 0.
I think this is absolutely necessary for Unicast and Multicast to share links.
If it's not clear enough, should we mention this in other parts of the spec as well?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 16 Jun 2017 00:45:17 +0200

> What is wrong with unicast/multicast? I must have missed why these are

I think David is concerned about the confusion between the network-layer
destination address (unicast/multicast) and the types of application-layer
packets (Unicast/Multicast Hellos).  As a matter of fact, it is perfectly
legal to send a Multicast Hello to all neighbours over multiple unicasts.

While I understand David's unease, I don't think the confusion is likely
to cause trouble, and unless somebody comes up with some absolutely
perfect terminology that we all agree on, I suggest we stick to
Unicast/Multicast Hellos.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 16 Jun 2017 00:49:35 +0200

> interoperate. That's fine by me, we'll just need to add text to make that

What I meant is that all implementations MUST be able to parse both kinds
of Hellos, but an implementation may choose to only ever send Multicast
Hellos.  It may also choose to only send Unicast Hellos, but in that case
you need some other discovery mechanism.

> I think this is absolutely necessary for Unicast and Multicast to share links.

Fully agreed.

Now what about an implementation that sends mostly Multicast Hellos, but
occasionally sends a Unicast one?  Such an implementation needs to express
the notion that it makes no promise to ever send another Unicast hello.

> If it's not clear enough, should we mention this in other parts of the

Yes, I think we need an explanatory paragraph somewhere.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Jun 2017 16:42:04 -0700

> On Jun 15, 2017, at 15:49, Juliusz Chroboczek <[email-masked]> wrote:
> 

Is there benefit in requiring all implementations to parse Multicast?
If I only send Unicast and you only parse Multicast we're not going to
interoperate anyway, so might as well remove the requirement that
everyone needs to parse Multicast.

> the notion that it makes no promise to ever send another Unicast hello.

I think the only way to allow occasional Unicast Hellos would be to
allow the Interval to be 0 if the Hello is Unicast. I'm not sure that's
reasonable, because if you only ever send Unicast and send it with
an Interval of 0, I don't know when to expire you from my neighbor table.

> Yes, I think we need an explanatory paragraph somewhere.

I had added a paragraph to section 3.4.1 (Reverse Reachability Detection):

   The dichotomy between Public and Personal Hellos (and the fact that
   they have separate sequence numbers and intervals) allows
   implementations to use different intervals based on link properties.
   Public Hellos are sent over multicast, which allows discovery of new
   neighbors but may cause issues on link layers where multicast is
   degraded.  Personal Hellos are sent over unicast, improving
   reliability on these networks.

Perhaps that needs to be even more explicit on the topic of Intervals.

Thanks,
David Schinazi

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 16 Jun 2017 10:43:55 +0200

> everyone needs to parse Multicast.

If we require all implementations to understand both sorts of hello we
ensure that there's always a way to get "in touch" with another
implementation. I think the language on sending multicast hellos should
be something like "SHOULD send multicast hellos unless there is another
out-of-band discovery mechanism".

> allow the Interval to be 0 if the Hello is Unicast. I'm not sure
> that's reasonable, because if you only ever send Unicast and send it
> with an Interval of 0, I don't know when to expire you from my
> neighbor table.

What's the use case for "occasionally" sending a unicast hello, and can
it not be covered by a high interval?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 17 Jun 2017 02:05:17 +0200

> everyone needs to parse Multicast.

Require that all implementations parse *both*, but an implementation is
not required to send either.  So whether you send multicast or unicast
doesn't matter, I still associate with you.

The implementation cost is fairly moderate (one extra set of history per
neighbour, 16 bits in my implementation), simple to specify, and ensures
interoperability.

Any counter-proposals?

> an Interval of 0, I don't know when to expire you from my neighbor table.

Well, I was thinking that an implementation MUST send either periodic
Multicast Hellos or periodic Unicast Hellos, but it MAY send occasional
Hellos of the other kind.  Occasional Hellos do not participate in
link-quality estimation.

The main application is the RTT extension, which requires a Hello to be
sent in the same packet as an IHU.  If an implementation sends Multicast
Hellos and Unicast IHU, it will want to send an "occasional" Unicast Hello
together with each IHU.

"Occasional" Hellos MAY be silently ignored, but any sub-TLVs must still
be parsed.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 17 Jun 2017 02:15:26 +0200

> it not be covered by a high interval?

All of the TLVs defined in Babel are idempotent: sending multiple
identical Updates, or multiple identical Requests, is equivalent to
sending a single Update or Request.

The only exception are Hellos, which are not idempotent, since they change
the state used for link-quality estimation.  This is the root cause of
all of our troubles: we cannot send ordinary ("Multicast") Hellos over
unicast, or else we desynchronise the link-quality estimation state.

The other trouble this causes is with sub-TLVs: if some data is defined to
be carried in a sub-TLV of a Hello, then it cannot be sent at arbitrary
times, since that would change the link-quality estimation.

We define an Unscheduled Hello as one that carries an Interval of 0.  Such
a Hello MAY be ignored for link-quality estimation purposed, and MAY be
outright ignored upon reception; however, any sub-TLVs it carries are
still parsed, and aced upon.

The current application is the RTT metric, which requires a Hello to be
sent together with each IHU (in order to carry a timestamp).  In most
implementations, IHUs are naturally sent together with Hellos, so nothing
is required; however, if an implementation schedules IHUs independently of
Hellos, then something needs to be done, either change the scheduling of
Hellos (which might or might not be complicated), or send an Unscheduled
Hello in order to carry the timestamp.

Note that the above says MAY be silently ignored.  If we end up finding
a really smart link-quality estimation algorithm that needs to use
unscheduled Hellos, this can be implemented in the future without
requiring a specification change.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Mon, 19 Jun 2017 22:39:54 -0700

That's an elegant solution. It reduces constraints on implementations
but still allows the current model to work.

I do have one question however: what does the seqno represent on
unscheduled Hellos (UH)? If an implementation MAY ignore UH for
the purpose of link-quality estimation, then incrementing the seqno
on UH will confuse it.

For that reason I propose that, for UH, seqno MUST be set to 0
when sending and MUST be ignored on reception. Also, the
interface outgoing periodic Hello seqno MUST NOT be
incremented when sending UH.
>From my understanding, this is compatible with the RTT
extension since that doesn't use the seqno or interval.

Thoughts / counter-proposals?

Also minor: we've used the terms "occasional" and "unscheduled"
to denote Hellos with an Interval of zero. We should pick one for
standardization, I personally prefer "unscheduled". We should
also pick a term for Hellos with non-zero Intervals, I personally
prefer "periodic".

I tried to incorporate it into my pull request:
https://github.com/jech/babel-drafts/pull/3/files <https://github.com/jech/babel-drafts/pull/3/files>
Let me know what you think.

Thanks,
David Schinazi

> On Jun 16, 2017, at 17:15, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Mon, 19 Jun 2017 22:40:02 -0700

> On Jun 16, 2017, at 17:05, Juliusz Chroboczek <[email-masked]> wrote:
> 

[DS] This approach has several downsides, all of which minor enough that
I still think you're right.
1) it makes implementations over unicast-only links non-compliant.
    I think we can solve this by adding text saying that the requirement
    to support Uni/Multicast only applies to link-layers that support
    Uni/Multicast, respectively.
2) It makes existing implementations non-compliant -- I'm fine with that
3) An implementation that only plans to use one type of Hello
    needs to do additional work to receive the other kind -- I'm fine with that

But the upsides make it better than other proposals including mine:
1) Any two (modern) implementations sharing a link-layer interoperate
2) Implementors are absolutely free to pick what they send
3) The RTT extension still works in all cases

So I support this change.

> "Occasional" Hellos MAY be silently ignored, but any sub-TLVs must still

See other thread:
"Re: [babel] Unscheduled Hellos [was: Cutoff date for rfc6126bis is 3 July]"

Thanks,
David Schinazi

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 20 Jun 2017 10:00:10 +0200

> Thoughts / counter-proposals?

While it makes sense that we should have a "seqno-less" hello if we are
going to be ignoring them, at this point it really feels like we are
overloading hellos to the point that we are really defining two
different TLVs in one. A hello is there to carry a seqno and an
interval, and now we're defining one that carries neither... so it's
basically a new TLV, no?

If we want an idempotent discovery TLV, why not just define one,
separate from Hello?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 14:10:49 +0200

> Uni/Multicast, respectively.

I think it's okay to require that all implementations be able to parse
both kinds of Hello; if an implementation never receives a Multicast
Hello, then the requirement is vacuously satisfied.

(What's more, it is legal to send a "Multicast" Hello over multiple
Unicast to all neighbours, as Margaret's implementation does.  So just
because an implementation speaks NBMA only doesn't mean it'll never
receive a Multicast Hello.)

> 2) It makes existing implementations non-compliant -- I'm fine with that

Agreed.

> 3) An implementation that only plans to use one type of Hello needs to
> do additional work to receive the other kind -- I'm fine with that

Agreed, it's one extra 16-bit field per neighbour.

> https://github.com/jech/babel-drafts/pull/3/files

Thanks a lot, that's very helpful.

> Let me know what you think.

 - the NBMA exception noted above is not needed in my opinion;
 - that's not the way ETX should work with two kinds of Hellos with
   different loss probabilities;
 - you're giving some implementation advice that is unproven ("Properties
   of Multicast and Unicast Hellos")
 - I don't agree that unscheduled Hellos should be seqno-less -- see other
   mail.

I assume I have your permission to cherry-pick just some of your hunks and
commit under your name.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 14:25:25 +0200

>> the purpose of link-quality estimation, then incrementing the seqno

It's ignored for the purposes of link-quality estimation, but it must
still participate in seqno computation.  So upon receiving an unscheduled
Seqno, you do the following:

  if received seqno = expected seqno
      expected seqno := received seqno + 1
      hello history remains unchanged
  else
      compute the amount of loss as usual.

The only issue is that if unscheduled Hellos were lost, you might mistake
them for scheduled Hellos.  Not a big deal, but I must do an
implementation before I'm sure.

>> when sending and MUST be ignored on reception.

> If we want an idempotent discovery TLV, why not just define one,

Agreed -- but we should do one or the other, not both.  Either a new TLV
for seqno-less Hello, or the Unicast flag in Hellos.  I'm strongly opposed
to doing both.

That was more or less my proposal in Chicago: define a new "Unicast Hello"
TLV that is seqno-less and interval-less.  This was rejected by David, who
wants Unicast Hellos to have all the nice properties of ordinary
(multicast) Hellos.

Now, I'm rather sympathetic to David's concerns, but I want Unicast Hellos
to fix the RTT extension when Hellos are sent over multicast and IHUs are
sent over unicast (right now, RTT requires that Hellos and IHUs be sent
together).  I see three solutions:

  1. redefine the RTT extension to allow timestamps in IHU;
  2. allow unscheduled Hellos;
  3. force all implementations of RTT to either send IHU over multicast or
     to participate in Unicast Hello link-quality estimation.

(3) significantly complicates implementation of the RTT extension, which
is successfully deployed in production and not something I'm willing to
give up.  What is more, I'm worried that using Unicast Hellos in
link-quality estimation will break WiFi link-quality estimation -- I'll
expand on that in another mail.

So my choice would be to allow unscheduled Hellos.  Right now, I see no
good reason to make them seqno-less, but I might change my mind when
I write the code.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Jun 2017 10:05:04 -0700

> On Jun 20, 2017, at 05:10, Juliusz Chroboczek <[email-masked]> wrote:
> 

Fair enough, I removed that text.

> receive a Multicast Hello.)

I agree, I changed the text to reflect that.

> - the NBMA exception noted above is not needed in my opinion;

Agreed

>   different loss probabilities;

Continuing discussion on thread:
"Unscheduled Unicast Hellos: some background on 802.11 link quality estimation"

>   of Multicast and Unicast Hellos")

Fair enough, I still think we should provide rationale and advice on how
to pick which type of Hello to use, can you suggest better text?

> - I don't agree that unscheduled Hellos should be seqno-less -- see other

Continuing discussion on thread:
"Unscheduled Hellos"

> I assume I have your permission to cherry-pick just some of your hunks and

Absolutely.

David Schinazi

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Jun 2017 10:41:28 -0700

I agree with Juliusz in that I'd rather not have a new TLV for
Unscheduled Hellos. I'd like Periodic Unicast Hellos to have
a seqno so a Unicast-only implementation can still perform
similar link-cost estimation. Also, the main goal of
Unscheduled Hellos in my mind is to support the RTT
extension and similar sub-TLVs, which need to be sent on
the Hello TLV.

I also agree that Unscheduled Hello are simpler than changing
the RTT extension.

Regarding the seqno on Unscheduled Hellos, we have two options:

1) Keep the seqno (send it and increment it)
    Upsides:
         Hello carries some more information (?)
    Downsides:
        Hello parsing code becomes slightly more complex
        Missing an Unscheduled Hello is indistinguishable from missing a Periodic Hello

2) Remove the seqno (send 0, ignore it, do not increment)
    Upsides:
         Implementations can simply ignore them
         An implementation can avoid having seqnos at all for
             outgoing Unicast Hellos if using Periodic Multicast Hellos.
    Downsides:
        Hello carries less information (?)
        Overloads fields in the Hello TLV

I have a preference for (2) because it fits all our requirements and
was simpler than (1) to implement.

Does someone see other upsides to (1) or downsides to (2) that I'm missing?

Thanks,
David Schinazi

> On Jun 20, 2017, at 05:25, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 20:59:56 +0200

> Regarding the seqno on Unscheduled Hellos, we have two options:

Either makes sense, either solves the problem.  Implement both, look at
code complexity?  (I'd expect it to be roughly equal, but one sometimes
has surprises.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 21:20:34 +0200

> Does someone see other upsides to (1) or downsides to (2) that I'm missing?

The spec is somewhat simpler if unscheduled Hellos increment seqno -- it
removes a lot of special-casing in your text.  (Not a conclusive argument,
IMHO, but a strong argument nonetheless.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 21:30:32 +0200

> Let me know what you think.

Rather than "Periodic Hello", I'm going to use "Scheduled Hello".  This is
consistent with Updates, and doesn't imply that jitter is illegal.

I'm sorely tempted to keep the seqno in unscheduled Hellos, since it makes
the text simpler.  We can remove them later when we have implementation
experience.

It is always legal to send a scheduled Hello ahead of schedule -- the
protocol explicitly allows varying the Hello interval.  Unscheduled Hellos
are only really useful for implementations that never send scheduled
Hellos of a given kind.

The way to deal with Unscheduled Hellos for link-quality estimation should
not be normative -- the only normative condition is that a link that has
not received a Hello recently (of any kind) has infinite cost.  The term
"link-quality" should not appear in the normative part of the document.

I'm going to redo Appendix A, since I disagree with much of your advice.

Ok?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 20 Jun 2017 22:13:04 +0200

> IMHO, but a strong argument nonetheless.)

I agree. And I don't think the downside to being unable to distinguish
between the two types of loss is that big; I mean, a packet loss is a
packet loss.

Do we really need the interval=0 spec? I mean if you send a hello at T=0
promising to send another at T=4, and then decide to send an unscheduled
one at T=2, couldn't you just use the remaining time (2 in this case) as
the interval? Or is that too complicated to implement (depends on the
timer implementation, I guess)?

-Toke

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Jun 2017 13:37:25 -0700

> On Jun 20, 2017, at 13:13, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 

That may cause inefficiencies because if I receive your Hello at T=2 with I=2
and then don't hear anything until T=21 then I'll think I missed 9 Hellos
whereas in reality I only missed 5 Hellos.

David Schinazi

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 20 Jun 2017 23:14:48 +0200

> timer implementation, I guess)?

It's much simpler than that.  If you're sending every 4 seconds and then
decide to send a Hello at t=2, you just send it with interval=4.  Then you
reschedule the next Hello to be sent at t=6 instead of t=4, and you've
resynchronised.  And if the Hello at t=2 is lost, you'll still detect the
loss, just two seconds late.  And even if you f*ck up (e.g. by failing to
reschedule), it doesn't matter, since the Hello history will resynchronise
the next time you get a seqno (check the "undoing history" bit in Appendix A),
and your hysteresis algorithm will swallow the short-lived variation in
link quality.

The case I'm concerned about is that of an implementation that only sends
scheduled Hellos of a given kind but occasionally needs to send a Hello of
the other kind.  For example, an implementation only sends Multicast
Hellos, but then at some point decides to send a Timestamp sub-TLV over
unicast, which needs to be attached to a Hello.  If it sends a normal
Unicast Hello, then the peer might start doing accounting of Unicast Hellos,
and spuriously detect loss when the Interval expires.  Attaching the
sub-TLV to an unscheduled Hello avoids the spurious variation in link quality.

Conversely, consider an implementation that usually sends Unicast Hellos,
but sends a bunch of unscheduled Multicast Hellos when the link layer
indicates that a new station has joined the BSS (or when it receives an
ICMPv6 packet from a new IP, or when MARS indicates that a new node has
joined the Emulated LAN, or whatever).  Since the link-layer event is
unpredictable, there is no way to choose a good interval for Multicast
Hellos, and sending a non-zero Interval might cause peers to start doing
link-quality estimation using Multicast Hellos.

Folks, I'd really like to avoid the need for Interval=0.  If you can find
a good way to implement the two use cases above with the existing mecha-
nisms, I'll be thrilled.  On the other hand, Interval=0 is just a small
amount of spec (don't reset the timer when Interval=0, and don't tweak the
Hello history), and a very small amount of code, so we might as well go
for it.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Tue, 20 Jun 2017 19:01:18 -0400

> scheduled Hellos of a given kind but occasionally needs to send a Hello of the
> other kind.  For example, an implementation only sends Multicast Hellos, but
> then at some point decides to send a Timestamp sub-TLV over unicast, which
> needs to be attached to a Hello.  If it sends a normal Unicast Hello, then the
> peer might start doing accounting of Unicast Hellos, and spuriously detect
> loss when the Interval expires.  Attaching the sub-TLV to an unscheduled
> Hello avoids the spurious variation in link quality.
> 
> unpredictable, there is no way to choose a good interval for Multicast Hellos,
> and sending a non-zero Interval might cause peers to start doing link-quality
> estimation using Multicast Hellos.
> 
> Folks, I'd really like to avoid the need for Interval=0.  If you can find a good
> way to implement the two use cases above with the existing mecha- nisms,
> I'll be thrilled.  On the other hand, Interval=0 is just a small amount of spec
> (don't reset the timer when Interval=0, and don't tweak the Hello history),
> and a very small amount of code, so we might as well go for it.

You could solve with an extra bit -- but I think interval == 0 is the simplest way to solve it.

😊 /r

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Jun 2017 22:49:45 -0700

> On Jun 20, 2017, at 12:30, Juliusz Chroboczek <[email-masked]> wrote:
> 

Sure, I updated the branch.

> the text simpler.  We can remove them later when we have implementation

I thought about this, implemented it, thought about it some more, and
I feel less strongly about it now. Keeping the seqno does not make the
code that much more complex and does simplify the spec.
So I changed the branch to reflect that.

> and a very small amount of code, so we might as well go for it.

I agree, but couldn't come up with a better way without unscheduled hellos.
Unscheduled hellos (with seqno) seem like a good solution to me.

> "link-quality" should not appear in the normative part of the document.

Agreed, I fixed that

> I'm going to redo Appendix A, since I disagree with much of your advice.

Send some text!

Updated branch is here:

David Schinazi

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Jun 2017 11:38:57 +0200

> Sure, I updated the branch.

Sorry I wasn't clearer -- I was in the midst of editing.  Please don't
touch the branch until I've merged your text (hopefully before midnight).

-- Juliusz