Subject: Re: [homenet] L2 link status [was: More about marginal links]

From: Henning Rogge <[email-masked]>
Date: Sun, 1 Mar 2015 14:08:17 +0100

On Sun, Mar 1, 2015 at 12:52 AM, Curtis Villamizar
<[email-masked]> wrote:
> If any of the control packets drop, drop a partial result, repeat
> later, and compare to the last complete result.
>
> Is one cycle per neighbor too much?  How about one cycle per neighbor
> each 5 seconds?  If "B" is the AP it sends only one packet per cycle
> but both sides get accurate drop rate for both directions.

I went even further and restricted the probing to a fixed amount per
interface... to prevent the wifi network from overloading in crowded
adhoc networks (where everyone can see everyone).

Henning Rogge

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 01 Mar 2015 11:08:56 -0500

In message <CAGnRvurm5wDMVxdvHy6rdvkPkwQ2q_YHcZiU0+NLmq=[email-masked]>
 
> adhoc networks (where everyone can see everyone).

Henning,

That sounds like a good strategy.  Negotiating a rate among two
parties is not a hard protocol problem, nor is changing it.

Note that PPP LQM (link quality monitoring) or MPLS-TP LM (loss
monitoring) is not probe data.  For example, one cycle of LQM packet
every 10 seconds yields the exact number of packets sent and recieved
and the exact number dropped in both directions over a 10 second
period.  One cycle is three packets, with two in one direction.

IMHO an LQM for WiFi would be a good idea.  It would have to be
specified and coded (though coded and then specified seems to be the
model that some people prefer).

Curtis

---

From: Henning Rogge <[email-masked]>
Date: Sun, 1 Mar 2015 17:54:09 +0100

> period.  One cycle is three packets, with two in one direction.

The Neighborhood Discovery Protocol (RFC 6130) has a similar
mechanism... each node collects local link quality information and
then shares them from time to time with all neighbors, which means
everyone knows about both directions of a link.

Henning Rogge

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 1 Mar 2015 09:30:32 -0800

The question really is how elaborate homenet wants to be. 

Given how i suffered for a good while due to broken transceivers
in LAN equipment resulting in persistent 0.5% loss on links,
i would like homenet to be a lot better than your average
enterprise network is on this. 

Sure, in my case there was ECMP, so one COULD have done intelligent
routing changes. But more often than not, alerting the user is
the primary action to take.

"Check the cable on portX/routerY. You may need to try a different cable"
"Put the poor AP further away from the microwave"

I really can't see how to build successfull home  wireless without
good diagnostics and suggestion system. Some of the higher end
home AP vendors seem to start doing this with smartphone apps
as the user interface. PowerLine equally has a lot of gotchas.

I have also seen crazy things like failing linux-PC starting
to blast multicast packets, killing a whole LAN segments until
the PC rebooted. Sure, a lot of enterprise switching gear can
throttle this, but alerting the user should be even more
important.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 01 Mar 2015 17:14:19 -0500

In message <CAGnRvuqTphM9c=[email-masked]>
 
> everyone knows about both directions of a link.

RFC 6130 uses probes (hello message success rate).

For example: If an AP sends 100 packets a second to a neightbor and 5
drop it would be better to send one LQM packet and know that loss is
5% rather than have to send 100 hello packets in addition to the 100
data packets to reliably know that loss is 5%.  (In MPLS it could be a
billion packets between LM packets).

LQM does not rely on a count of probe packet success.  Please reread
what I sent earlier or read about PPP LQM or MPLS-TP LM OAM.

Please compare RFC 6130 section 14.2 (Basic Principles of Link
Quality) with RFC 1989 and RFC 6375.  In RFC 6375 look at Section 2.2
(Packet Loss Measurement) and Section 3.1 (Loss Measurement Message
Format).  RFC 6130 has no comparable mechanism.

Curtis

---

From: Henning Rogge <[email-masked]>
Date: Mon, 2 Mar 2015 08:20:30 +0100

> RFC 6130 uses probes (hello message success rate).

No, it does not... at least not for calculating the link metric.

> Quality)

"Link quality" and "Link metric" are two different kind of things for
NHDP/OLSRv2.

Link quality is used for a hysteresis mechanism that can make a link
symmetric/asymmetric.

Link metric (as defined in RFC 7181) is used for path selection.

> with RFC 1989 and RFC 6375.  In RFC 6375 look at Section 2.2

RFC6130 (NHDP) and RFC 7181 (OLSRv2) define the incoming link METRIC
calculation as an external process. It can be anything, as long as it
gives you a dimensional link cost in the right range.

I admit the splitup between RFC6130 and RFC7181 is a bit confusing...

Henning Rogge

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Mar 2015 18:28:01 -0500

Henning,

You cut the following off the top of your reply.

> RFC 6130 uses probes (hello message success rate).

Cutting this off makes a big difference.  See below.

In message <CAGnRvup-F4_A1-sHkh3EWRgrX=[email-masked]>
> No, it does not... at least not for calculating the link metric.

The discussion was the quality measurement.  The quality measurement
uses hello message success rate.  See section 14 in RFC 6130.

The discussion was not link metrics.  You chopped the prior discussion
when quoting the one sentence above.  Below I describe the why RFC
6130 Link Quality is nothing like LQM.

> I admit the splitup between RFC6130 and RFC7181 is a bit confusing...

I know the difference between link quality and link metric.

You just jumped from ND to OLSRv2 for MANET.  RFC 7181 does not
preclude using a LQM-like mechanism, but neither RFC 6130 or RFC 7181
define such a mechanism.

The discussion was regarding doing something like LQM and three
messages ago you stated that RFC 6130 already had something like LQM.
Neither RFC 6130 or RFC 7181 define a mechanism anything like LQM.

Curtis

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Mar 2015 08:48:42 +0100

Sorry,

too much working on the implementation side of NHDP/OLSRv2 in the last
years... should have thought a bit more about the reply before sending
it.

Yes, you are correct that RFC6130 does not contain the description of
the link metric...  it only contains a rough EWMA based "link quality"
hysteresis that switches on and of links. I don't even think the
algorithm defined in the RFC is really useful (but its easy to plug in
a different one because the Link Quality calculation and decision is
just local).

I was thinking about the Link Metric NHDP extension defined in RFC7181
(which can easily be used without using the OLSRv2 routing), which is
based on "Incoming/Outgoing Link Metric" values.

(in my implementation I put the whole Link Metric and MPR code into
NHDP to make them usable without OLSRv2)

Henning Rogge

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Mar 2015 14:12:31 -0500

In message <CAGnRvuqcwFjE6NZ_tOnQEBN8RG8wUFeSsQSqsETh=[email-masked]>
 
> NHDP to make them usable without OLSRv2)

The basis for the metric in RFC 7181 is out of scope.  So what did you
use?

Also I'm not sure what you meant by the "MPR code".  Did you leave in
the LINK_METRIC TLV and leave out the rest of RFC 7181?

So my point still stands that there is nothing like LQM is anything
over WiFi (more correctly 802.11).

Curtis

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Mar 2015 20:21:06 +0100

> The basis for the metric in RFC 7181 is out of scope.  So what did you

This:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04

I am still using the multicast loss (plus the raw link speed) to judge
the links, but I have done some early experiments with integrating the
L2 frame statistics too. Not sure it works that well for wifi without
a lot of probing, much more than you need for getting an useful link
speed).

> the LINK_METRIC TLV and leave out the rest of RFC 7181?

Multipoint Relays. Its a method to reduce the flooding overhead in a
wireless mesh network. Its defined in RFC 7181, but its a modification
of NHDP so I put it into my NHDP implementation.

> over WiFi (more correctly 802.11).

With an Atheros card I get both transmitted frames, retransmitted
frames and (completely) lost frames on the sender side of a link...
its just that these values are not that useful when most of your
wireless links are not transporting traffic.

Henning Rogge

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Mar 2015 15:50:13 -0500

In message <CAGnRvuq+kq+djqPvKHDXBdDkbfjt=[email-masked]>
 
> https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04

It seems like with this draft, packet with RFC 5444 (Generalized
Mobile Ad Hoc Network (MANET) Packet/Message Format) sequence numbers
are counted and absent any of those, only HELLO packets are counted.

If all packets had RFC 5444 sequence numbers this would have the same
effect as LQM.  Unfortunately this requires the host to use RFC 5444
encapsulation over WiFi.

Unfortunately LQM requires both side to play.  On the bright side, a
host would only need to copy counters into a packet to allow the AP to
gather information.

> a lot of probing, much more than you need for getting an useful link

It would be nice to write down somewhere (preferably and
internet-draft for WG purposes) exactly what you end up with once
you've made good progress on this.

> wireless links are not transporting traffic.

Its great that you are working on wireless mesh networks.

IMHO the typical homenet environment is Ethernet plus WiFi in AP mode,
not mesh.  Its good to have things that work well for mesh.  Right now
it would be really good to have solutions for the problem of lots of
AP in a confined area.

In some cases, such as appartment buildings with lots of consumer run
AP, the issue is keeping the density of AP from congesting airwaves.

In other cases (such as IETF, or an enterprise with lots of APs) hosts
will be roaming among APs and that should be smoother than it is now.
Unfortunately I don't think that is fixable with zero host changes.

Curtis

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Mar 2015 08:27:45 +0100

> Op 3 mrt. 2015, om 21:50 heeft Curtis Villamizar <[email-masked]> het volgende geschreven:
> 

With 5GHz, signal fades away rather quickly due to walls.
This has as a disadvantage that even in moderate sized homes, there are multiple 5GHz APs needed for good performance (>20Mbps).
So the number of WiFi AP's in homes will grow and there's a need for support of IEEE 802.11k and 802.11r.
With 802.11ad, walls block RF.

> Unfortunately I don't think that is fixable with zero host changes.

In today's WiFi stack and good WLAN controller, this works quite well. Next step is home wireless routers. This homenet WG should catch up.

Teco

> 
> Curtis
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Dave Taht <[email-masked]>
Date: Wed, 4 Mar 2015 08:45:26 -0800

>> In some cases, such as appartment buildings with lots of consumer run

My best (well, worst) dataset here was in paris where in my 18th floor
apartment I could "hear" over 200 APs, and was generally lucky to get
a few dozen k in throughput from across the room. 5ghz was illegal at
the time, it was all 2.4ghz traffic.

As I recall, Mark Townsley also had trouble getting 2.4 ghz signal or
bandwidth from across the room in his apt there, also.

>> AP, the issue is keeping the density of AP from congesting airwaves.

Yes.

See the minstrel-blues work - which looks to make a dent in that
problem by reducing signal strength whenever it makes sense.

http://www.linuxplumbersconf.net/2014/ocw//system/presentations/2439/original/Minstrel-Blues%20@LinuxPlumbers%202014.pdf

> With 5GHz, signal fades away rather quickly due to walls.

False. It is mostly the low signal strength that is legal on the lower
5ghz bands that is the problem here. Higher bands usually let you have
much more output power. But, that too creates problems. See above for
one piece of a solution.

I figure (since I am unsubscribed) this message will bounce. But whatever.

> So the number of WiFi AP's in homes will grow and there's a need for support of IEEE 802.11k and 802.11r.

h, also.

> With 802.11ad, walls block RF.

Thankfully, although I am waiting for products to appear and it
appears this standard is mostly targetted at TV, not interactive
applications.

> In today's WiFi stack and good WLAN controller, this works quite well.

Um, no. Today's wifi stacks and most chipsets and drivers are
horribly, horribly borken.

>Next step is home wireless routers. This homenet WG should catch up.

+10.

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Mar 2015 18:40:35 +0100 (CET)

> much more output power. But, that too creates problems. See above for

Could you please elaborate? I have read papers claiming 5GHz and 2.4GHz 
attenuates identically through concrete. My personal experience is exactly 
the opposite, that with 20cm re-inforced concrete floors or walls, 5GHz 
basically doesn't work at all, whereas 2.4GHz works ok. I don't believe 
this is only due to lower power output, but I'd gladly be convinced why I 
am wrong.

I thought it was quite obvious that the higher the frequency, the lower 
the solid object penetration is.

> Thankfully, although I am waiting for products to appear and it appears 
> this standard is mostly targetted at TV, not interactive applications.

I have been told 60Ghz is line-of-sight only, which I have no trouble 
believing. My experience with 38GHz radio links has shown me how little it 
takes to make things stop working compared to 2.4GHz or 5 GHz.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Mar 2015 19:09:39 +0100

> Op 4 mrt. 2015, om 17:45 heeft Dave Taht <[email-masked]> het volgende geschreven:
>>> 

My telco offered me a free iPhone 6 so I can offload :-)) 
It works very well, I enjoy it at work.
https://support.apple.com/en-la/HT202628

Some say iOS is 2 years behind Android / Nexus 4:
http://uk.businessinsider.com/graphic-iphone-6-v-nexus-4-2014-9?r=US
So Android WiFi roaming should work also (and sometimes, it does).

I am looking for a good solution for homes. Cheapest enterprise level of WiFi equipment costs at least 3x more than an a set of high-end wireless routers. On roaming, it works 1000x as good, so one can say it is value for money.

Back to homenet topics: zero-conf layer-3 topologies with SADR is great. But ignoring IEEE802.11 / WiFi standards sounds crazy to me. Please, let's not make it worse.

And yes, I highly respect your efforts making WiFi and AQM better. But this is less related to homenet work.

Teco