Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Mike O'Dell]

excuse my naivete, but why on earth is homenet worried about
"interior routers"? there shouldn't *be* any interior routers
in a home network. ethernet switches, sure, but not routers.

	-mo

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Dave Taht]

The homenet argument, is that there is already typically dozens of
routing like devices in the home today, and
double/triple nat often resulting from misconfiguration.

Townsley makes the arguement coherently in the video I mentioned
earlier. If you can take 15 minutes out of your day to watch that,
perhaps the point will be made.

Notably bridging ethernet to zigbee and sensor networks (and wifi, to
a large extent) is an horrifically bad idea. (IMHO). There are people
strongly in favor of using Rbridges in that situation...

Short term, finding ways to avoid double-triple-nat would be an
improvement on how things work.

In my own case I worry more about small business than home networks.
Once you fall off the cliff of bridging,
the route towards routing is hard. And I'm totally in love with the
idea of getting multiple uplinks to different providers to "just
work".


On Sat, Jun 7, 2014 at 11:02 AM, Mike O'Dell <mo@ccr.org> wrote:
>
> excuse my naivete, but why on earth is homenet worried about
> "interior routers"? there shouldn't *be* any interior routers
> in a home network. ethernet switches, sure, but not routers.
>
>         -mo
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Mike O'Dell]

Having links from multiple providers "just work" is indeed a grand idea.

Unfortunately, IPv6 doesn't deal with multihoming any better than IPv4 doesn't;
in fact, it's pretty clearly worse.

you can get the bath water to run out a different hole by tipping
the bathtub, but you can't make in run *into* the bathtub the same way.

I agree that nested NATs are suboptimal and usually unnecessary.

As for falling off the cliff of bridging, it depends entirely
on how far you fall and what you land upon. 

The fundamental problem is that the L2 fabric needs dynamic routing
more sophisticated than a Spanning Tree. It's not hard to do and
is quite effective at solving the problems of transiting local
dynamic topology without annoying the L3 machinery. It even provides
for traffic engineering of different traffic types without having
to suffer through the myriad NO-OPs created by the IETF trying to solve
the problem in a network flat as road-kill on an Interstate.

	-mo

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Dave Taht]

On Sat, Jun 7, 2014 at 11:54 AM, Mike O'Dell <mo@ccr.org> wrote:
>
> Having links from multiple providers "just work" is indeed a grand idea.
>
> Unfortunately, IPv6 doesn't deal with multihoming any better than IPv4 doesn't;
> in fact, it's pretty clearly worse.
>
> you can get the bath water to run out a different hole by tipping
> the bathtub, but you can't make in run *into* the bathtub the same way.

Enter source-sensitive routing, with working implementations for both
babel and ospfv3.

http://www.ietf.org/proceedings/87/slides/slides-87-homenet-7.pdf

(and a couple drafts and papers related to it that I can dig up
 if you like - like this one:

 http://hal-univ-diderot.archives-ouvertes.fr/docs/00/94/72/34/PDF/source-sensitive-routing.pdf

We've needed this technology for ages, and it seems to work
magnificently. I hope
this summer to complete an example network with 5 upstreams...

makes mptcp "just work" too.

It does mean that you need hosts to have one ipv6 address per
possible egress point, but that basically already happens on
cellphones with wifi and 3g interfaces already.

Related work is the mdns-sd stuff to make mdns scale well
on home and campus networks.

> I agree that nested NATs are suboptimal and usually unnecessary.

Detecting when not to use nat via a standardized process would be
good. Also in the offing.

>
> As for falling off the cliff of bridging, it depends entirely
> on how far you fall and what you land upon.
>
> The fundamental problem is that the L2 fabric needs dynamic routing
> more sophisticated than a Spanning Tree. It's not hard to do and

There are ISIS fans in homenet. Also batman.

> is quite effective at solving the problems of transiting local
> dynamic topology without annoying the L3 machinery. It even provides
> for traffic engineering of different traffic types without having
> to suffer through the myriad NO-OPs created by the IETF trying to solve
> the problem in a network flat as road-kill on an Interstate.

Specifics please.

>
>         -mo



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Mike O'Dell]

look at what John Moy did in the Cascade 9000s back circa 1997
he used OSFP, of course, instead of ISIS and he did full constraint
resolution path identification along with with per-flow (aka VC) 
ingress rate monitoring which allowed completely distributed load shedding 
(policing) subject to a precedence lattice. once the path was identified
the only rate management was at the ingress points, and that's only per-port state. 

extending the model it to carry ethernet MAC addresses isn't very hard.

	-mo

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Dave Taht]

On Sat, Jun 7, 2014 at 12:20 PM, Mike O'Dell <mo@ccr.org> wrote:
>
> look at what John Moy did in the Cascade 9000s back circa 1997
> he used OSFP, of course, instead of ISIS and he did full constraint
> resolution path identification along with with per-flow (aka VC)
> ingress rate monitoring which allowed completely distributed load shedding
> (policing) subject to a precedence lattice. once the path was identified
> the only rate management was at the ingress points, and that's only per-port state.
>
> extending the model it to carry ethernet MAC addresses isn't very hard.

I googled for a couple pages and didn't find anything relevant. I'll gladly
read up on it...

A problem here, that many miss, is that sensor networks, wireless and
wifi behave
fundamentally differently that ethernet does. Wires, at least in the home, are
going the way of the dodo, so optimizing for the none-wired case is critical.

Multicast is particularly damaging
on wifi (running at the 1998 1mbit/sec rate where the overlying network can
now run at a gbit). Protocols like batman fold as many arp requests as possible
into a single packet, in order to deal with it, but overall,
minimizing multicast
is a goal until wifi improves it's multicast behavior.

Wireless/wifi/etc are also more like early ethernet in that they are
not full-duplex.

Most (all?) networking protocols have lousy metrics for determining
paths in a mixed
wireless/wired environments, and few have the ability to make
intelligent decisions
based on ingress/egress load at a gateway. Some things - like shortest path
routing - actually don't make a lot of sense in a mixed wireless,
wired environment.

Take a path like this

host A - Router B -> wireless ---long slow, unreliable hop
----->Router C-> internet
Host A - Router B -> wireless - short hop -> short hop -> ethernet ->
Router C-> internet

Despite the 2 shorter hops probably offering 10x the
bandwidth/reliability of the shorter path,
most routing protocols will select the "shorter" path. The "ETX"
metric is not horrible that
tries to mix in "quality" to the choice, but it is still not good.
Babel doesn't solve this
well either, presently.

Then there is the problem of channel selection. If you have this choice:

Host A - Router B -> wireless - short hop chan 36 -> short hop chan 36
-> ethernet -> Router C-> internet
Host A - Router B -> wireless - short hop chan 40 -> short hop chan 44
-> ethernet -> Router C-> internet

The second route above is superior to the first because the transit
will be non-interfering,
and scale as a full duplex link would rather than a half duplex one. A
string of half duplex links
on the same channel degrades rapidly.

There's two names for this feature, one is "diversity routing"

http://www.pps.univ-paris-diderot.fr/~jch/software/babel/wbmv4.pdf

And batman calls it something else, but specifically knowing the
channels on a path is
a really huge win that nothing else I know of currently thinks about.

I note that these are problems that can be solved at layer 2 as well,
but so far as I know,
nobody has solved them, and 802.11s was a disaster.

>
>         -mo



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 31, Issue 4

[Dave Taht]

What frustrates me most is that the IETF doesn't "get" wireless either,
and the IEEE is busy designing overly reliable, slow wireless networks
because EE types like never to drop packets, and they got retries
in their toolbox now to make it so. FEC belongs in their toolbox.
Retries, not so much. I keep thinking I have to start attending
IEEE meetings, particularly on the upcoming 802.11ak standard,
to knock some heds.

And: retries is partially my fault, based on the work we were doing in the
late 90s (see my mit talk for some
history) - but I never imagined we'd see 10s or 100s of retries built
into the layer 2 protocols as a result!

There is NO other good reason why
modern wifi should exhibit 100s of ms of latencies under load now that
we have fq_codel to shed it, but a whole ton of buffering, not just
retries, but aggregation buffers and re-order buffers, need to get
knocked out of the wireless
and wifi devices, in order to get back to sanity. First up is somehow
getting tools like veriwave to actually show latency in addition to
reliability...


On Sat, Jun 7, 2014 at 12:41 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Jun 7, 2014 at 12:20 PM, Mike O'Dell <mo@ccr.org> wrote:
>>
>> look at what John Moy did in the Cascade 9000s back circa 1997
>> he used OSFP, of course, instead of ISIS and he did full constraint
>> resolution path identification along with with per-flow (aka VC)
>> ingress rate monitoring which allowed completely distributed load shedding
>> (policing) subject to a precedence lattice. once the path was identified
>> the only rate management was at the ingress points, and that's only per-port state.
>>
>> extending the model it to carry ethernet MAC addresses isn't very hard.
>
> I googled for a couple pages and didn't find anything relevant. I'll gladly
> read up on it...
>
> A problem here, that many miss, is that sensor networks, wireless and
> wifi behave
> fundamentally differently that ethernet does. Wires, at least in the home, are
> going the way of the dodo, so optimizing for the none-wired case is critical.
>
> Multicast is particularly damaging
> on wifi (running at the 1998 1mbit/sec rate where the overlying network can
> now run at a gbit). Protocols like batman fold as many arp requests as possible
> into a single packet, in order to deal with it, but overall,
> minimizing multicast
> is a goal until wifi improves it's multicast behavior.
>
> Wireless/wifi/etc are also more like early ethernet in that they are
> not full-duplex.
>
> Most (all?) networking protocols have lousy metrics for determining
> paths in a mixed
> wireless/wired environments, and few have the ability to make
> intelligent decisions
> based on ingress/egress load at a gateway. Some things - like shortest path
> routing - actually don't make a lot of sense in a mixed wireless,
> wired environment.
>
> Take a path like this
>
> host A - Router B -> wireless ---long slow, unreliable hop
> ----->Router C-> internet
> Host A - Router B -> wireless - short hop -> short hop -> ethernet ->
> Router C-> internet
>
> Despite the 2 shorter hops probably offering 10x the
> bandwidth/reliability of the shorter path,
> most routing protocols will select the "shorter" path. The "ETX"
> metric is not horrible that
> tries to mix in "quality" to the choice, but it is still not good.
> Babel doesn't solve this
> well either, presently.
>
> Then there is the problem of channel selection. If you have this choice:
>
> Host A - Router B -> wireless - short hop chan 36 -> short hop chan 36
> -> ethernet -> Router C-> internet
> Host A - Router B -> wireless - short hop chan 40 -> short hop chan 44
> -> ethernet -> Router C-> internet
>
> The second route above is superior to the first because the transit
> will be non-interfering,
> and scale as a full duplex link would rather than a half duplex one. A
> string of half duplex links
> on the same channel degrades rapidly.
>
> There's two names for this feature, one is "diversity routing"
>
> http://www.pps.univ-paris-diderot.fr/~jch/software/babel/wbmv4.pdf
>
> And batman calls it something else, but specifically knowing the
> channels on a path is
> a really huge win that nothing else I know of currently thinks about.
>
> I note that these are problems that can be solved at layer 2 as well,
> but so far as I know,
> nobody has solved them, and 802.11s was a disaster.
>
>>
>>         -mo
>
>
>
> --
> Dave Täht
>
> NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article