Subject: [homenet] Capabilities of small devices

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 8 Aug 2013 09:21:36 -0400

Once in a while we still hear statements like "we can not do X on CPE/small box as they are not powerful enough".

Many CPE's sold now are using SoC (System on Chip) with single core that runs somewhere in the 400-600Mz 
range either a ARM or MIPS based, this is slow compared to the 4 core 2.8 GHz chip in my laptop. 
At the same time It is important to remember that the CPU's powering these devices are faster
than the Server Class CPU's sold a little over a decade ago (compare it with R14000 that introduced in 2001) . 

R14000 class chips were powerful enough for the Internet of the time, thus they should be powerful enough for the small 
Internet in Jari's house as it is not as large as the Internet was in 2000 :-)  at least not yet.

A more important factor is the size of the memory on the devices, a box with 8MB memory will have problem with running
many services, but many boxes sold today have 32-128MB memory (both NVRAM and RAM)  
These 64MB+ boxes have space for services like: 
	a routing protocol, 
	real DNSSEC authoritative server,
	validating DNS resolver
	a full DHCP server, 
	a SIP server 
	NTP server 
all at the same time with memory left over.

See my blog post from about a year ago: 
https://www.dnssec-deployment.org/index.php/2012/03/is-a-70-router-fast-enough-for-dnssec/
We use this device as the main validating resolver for our small office. 
If history is any indicator we can expect to have 1GHz SoC in the CPE devices soon.

Moral: do not constrain homenet requirements by yesterdays devices. 

	Olafur

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Aug 2013 08:54:15 +1200

> Moral: do not constrain homenet requirements by yesterdays devices. 

Fair enough (after all, the IPv6 design is great for an end-of-era
minicomputer).

However, today's devices are overwhelmingly battery-powered, so even
if compute power and memory are not the issues, electricity matters.

   Brian

---

From: "Hartog, F.T.H. (Frank) den" <[email-masked]>
Date: Fri, 9 Aug 2013 01:49:19 +0000

At the same time, new and much smaller devices are introduced in the home. E.g. light bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we should define a baseline definition of what we mean with "small device" anno 2013 to frame the homenet arch discussions and documents. Regards, Frank.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olafur Gudmundsson
Sent: Thursday, August 08, 2013 3:22 PM
To: [email-masked]
Subject: [homenet] Capabilities of small devices

Many CPE's sold now are using SoC (System on Chip) with single core that runs somewhere in the 400-600Mz range either a ARM or MIPS based, this is slow compared to the 4 core 2.8 GHz chip in my laptop. 
At the same time It is important to remember that the CPU's powering these devices are faster than the Server Class CPU's sold a little over a decade ago (compare it with R14000 that introduced in 2001) . 

R14000 class chips were powerful enough for the Internet of the time, thus they should be powerful enough for the small Internet in Jari's house as it is not as large as the Internet was in 2000 :-)  at least not yet.

A more important factor is the size of the memory on the devices, a box with 8MB memory will have problem with running many services, but many boxes sold today have 32-128MB memory (both NVRAM and RAM) These 64MB+ boxes have space for services like: 
	a routing protocol, 
	real DNSSEC authoritative server,
	validating DNS resolver
	a full DHCP server, 
	a SIP server 
	NTP server
all at the same time with memory left over.

	Olafur

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2013 22:11:39 -0400

> At the same time, new and much smaller devices are introduced in the home. E.g. light bulbs (or rather LEDs nowadays) with IPv6 capability on a 256 kB - 32 MHz chip. Maybe we should define a baseli…

Do bear in mind that Olafur is talking about home routers here, not lightbulbs.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Aug 2013 07:54:17 +0200

> Do bear in mind that Olafur is talking about home routers here, not lightbulbs.

 From a RAM/CPU perspective no current home routers should have a 
problem with IPv6. Its just that some manufacturers don't integrate the 
necessary components into their basic firmware.

I think IPv6 support should be mandatory for Homenet routers. Maybe they 
won't have an uplink to the Internet with IPv6, maybe they have some 
attached devices without IPv6, but the software on the core Homenet 
routers should have access to IPv6.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Robert Cragie <[email-masked]>
Date: Fri, 09 Aug 2013 09:15:47 +0100

Yes, but who's to say a light bulb won't be a home router? 6LoWPAN ND 
and RPL introduce the the concept of 6LRs and RPL Routers respectively, 
which are generally small devices (i.e. around the figures Frank 
mentions below) with a single wireless network interface.

These devices rarely seem to be considered in the homenet WG but will 
surely be part of a home network.

Robert

---

From: Benedikt Stockebrand <[email-masked]>
Date: Fri, 09 Aug 2013 09:34:05 +0000

Hi Frank and list,

"Hartog, F.T.H. (Frank) den" <[email-masked]> writes:

> At the same time, new and much smaller devices are introduced in the
> home. E.g. light bulbs (or rather LEDs nowadays) with IPv6 capability
> on a 256 kB - 32 MHz chip.

let me get into a little more detail on this and put this into a
different perspective:

- The ATmega 328P microcontroller used on an Arduino Uno has 32 kB of
  flash memory and 2 kB of RAM.

- There is an implementation of a USB 1.1 interface plus the
  "application" logic to convert between USB and RS-232 called V-USB.
  To my knowledge (I haven't come around to testing it) this runs on an
  Atmel ATtiny 2313 with 2 kB of flash and 128 bytes of RAM/CPU
  registers.

- The ATtiny 2313 is one of the bigger types in the ATtiny family of
  microcontrollers.  The smallest I've ever checked out is the ATtiny 13
  with 512 bytes of flash and 64 bytes of RAM; considering the price at
  which it is sold, I'd guess this is an immensely popular chip,
  probably because it is the smallest one that can be programmed
  in-system.

- Below the ATtiny 13 there are some even more limited models that need
  to be programmed out-of-circuit.  These are too impractical for my
  needs, but if I was building some sort of mass product I'd take some
  pains to actually make things work on these if possible.

- Power consumption increases squarely with the clock frequency.  The
  Arduino Uno has a fixed 16 MHz quartz; the application notes for
  various Atmel microcontrollers point out it is possible to run them on
  32.768 kHz using a standard realtime clock quartz to minimize power
  consumption.

I don't think that a full-blown TCP/IP stack can compete with USB, or
possibly even ZigBee/802.15.4, or RS-232/422/485, when it comes to
resource usage.  Any vendor building embedded systems who has the choice
between using say an ATtiny 2313 or an ARM SoC running some sort of
embedded Linux for a product will go for the t2313.  If they didn't
they'd be fatally incompetitive

When it comes to general-purpose, freely programmable devices we go for
some excess resources to allow a wider variety of programs to run---no
matter if we talk smart phones or supercomputers.  But with
fixed-purpose devices, which may also include low-end CPE routers, it is
essential for the vendor to cut all the excess resources in the system
not needed for the fixed job it is designed for.

> Maybe we should define a baseline definition of what we mean with
> "small device" anno 2013 to frame the homenet arch discussions and
> documents.

That may be a good idea.  Another key difference between fixed purpose
devices and general purpose ones is that you see little if any growth in
resources.  A baseline microcontroller-equipped washing machine from
today shouldn't have a significantly more powerful microcontroller than
one from ten years ago.  We may have a good chance that such a baseline
might be useful for a fairly reasonable period.

What I think is absolutely essential however is something else: When it
comes to embedded/microcontroller/fixed-purpose/"Internet-of-Things"
devices, then we have to come to grips with the associated hardware and
its limitations.  If every lightbulb in a house needs its own Raspberry
Pi league controller, few people could possibly afford that.  This is a
rather fundamental matter of mindset, not only in homenet, but also in
(at least) the 6lowpan/6lo contexts.

Cheers,

    Benedikt

PS: Disclaimer: So far I haven't even come around to taking a proper
    look at PIC microcontrollers, Contiki, ZigBee, 802.15.4 or any of
    the existing microcontroller based TCP/IP implementations...

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.        http://www.stepladder-it.com/

---

From: Andrew Mcgregor <[email-masked]>
Date: Fri, 9 Aug 2013 11:40:30 +0200

Part of Homenet is to bring the typical home router's capabilities up to
the level of a 6lowpan/roll router.  I don't think we have a problem with
the tiny devices, they're all very new and quite capable of fending for
themselves in that kind of environment, given a sensibly implemented
gateway into the homenet.

On 9 August 2013 10:15, Robert Cragie <[email-masked]> wrote:

> Yes, but who's to say a light bulb won't be a home router? 6LoWPAN ND and
> RPL introduce the the concept of 6LRs and RPL Routers respectively, which
> are generally small devices (i.e. around the figures Frank mentions below)
> with a single wireless network interface.
>
>>> home. E.g. light bulbs (or rather LEDs nowadays) with IPv6 capability on a
>>> 256 kB - 32 MHz chip. Maybe we should define a baseline definition of what
>>> we mean with "small device" anno 2013 to frame the homenet arch discussions
>>> and documents. Regards, Frank.
>>>
>> ______________________________**_________________
>> homenet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>>
>>
>
>

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 8143 7128

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 Aug 2013 10:44:46 +0000

Early on in this WG, we said the ROLL domain would connect to the homenet but not replace it. 
Acee 
On Aug 9, 2013, at 4:15 AM, Robert Cragie wrote:

> Yes, but who's to say a light bulb won't be a home router? 6LoWPAN ND and RPL introduce the the concept of 6LRs and RPL Routers respectively, which are generally small devices (i.e. around the figures Frank mentions below) with a single wireless network interface.
> 
> These devices rarely seem to be considered in the homenet WG but will surely be part of a home network.
> 
> Robert
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 09 Aug 2013 13:41:10 +0100

OK, IIRC this was with respect to the routing protocol and I agree 
regarding that point. However, this is a discussion about capabilities 
of home routers.

Robert

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2013 11:52:52 -0400

On Aug 9, 2013, at 8:41 AM, Robert Cragie <[email-masked]> wrote:
> OK, IIRC this was with respect to the routing protocol and I agree regarding that point. However, this is a discussion about capabilities of home routers.

To be clear, if it's a discussion for homenet, it's probably a discussion about homenet routers, not all routers that could exist in the home.   And it's certainly true that you could make your 6lowpan router be a crappy little microcontroller device, but why would you?   It's got to connect to a wired network, so it's not entirely an LLN device itself.   It's likely that homenet routers in the future will have an LLN interface if we start to see widespread deployment of 6lowpan networks in the home.

That said, if you wanted to implement a 6lowpan router as a very low power device itself, you could do so, but it would have limitations, and would not be capable of running a full homenet stack.   That's okay, and within the design goals (as I understand them) of the homenet architecture.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 09 Aug 2013 09:11:03 -0700

> regarding that point. However, this is a discussion about capabilities
Having worked in a couple equipment vendors, the
contronl-plane/forwarding capacity of a router will be comensurate with
the requirements.  The question is not how slow or limited resource a
router can I make, it's what are the expectations for this device? If it
has 802.11ac out one side and gig-e on the other it's going to need a
lot more horse power then if it does zigbee.

A router for some set of 6lowpan segments may be resource constrained.
which is fine, a homenet router would tend to have a different set of
resource contraints given what it might be expected to do. What passes
for a router today is a fairly powerful device by historical standards
and I wouldn't expect the average homenet router to be less capable.
>>> Yes, but who's to say a light bulb won't be a home router? 6LoWPAN
>>> ND and RPL introduce the the concept of 6LRs and RPL Routers
>>> respectively, which are generally small devices (i.e. around the
>>> figures Frank mentions below) with a single wireless network interface.
>>>
>>>>> At the same time, new and much smaller devices are introduced in
>>>>> the home. E.g. light bulbs (or rather LEDs nowadays) with IPv6
>>>>> capability on a 256 kB - 32 MHz chip. Maybe we should define a
>>>>> baseline definition of what we mean with "small device" anno 2013
>>>>> to frame the homenet arch discussions and documents. Regards, Frank.

---

From: "Hartog, F.T.H. (Frank) den" <[email-masked]>
Date: Sat, 10 Aug 2013 01:52:38 +0000

I'm not sure. I guess the ratio behind IPv6 and routing in the home is that we expect the home to be stuffed with lots of small devices with limited networking (L1, L2) capabilities. IPv6 and routing should increase the scalability of such networks. There is a case then for having more than one homenet router in the home. They should therefore be considerably cheaper than some tens of $ which is what they cost today. Besides, there is limited physical space in the home to deploy a multitude of dedicated homenet router devices. Embedding the functionality in other IPv6 devices thus makes sense. Maybe the light bulb is stretching it somewhat, but I guess if we take the specs of current low-end home routers or semi-managed switches as a baseline, we should be pretty safe. I checked a few out: what about 200 MHz / 16 MB as a baseline? 

Frank
________________________________________
From: [email-masked] [[email-masked]] on behalf of joel jaeggli [[email-masked]]
Sent: Friday, August 09, 2013 6:11 PM
To: [email-masked]; [email-masked]
Subject: Re: [homenet] Capabilities of small devices

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2013 22:53:00 -0400

On Aug 9, 2013, at 9:52 PM, Hartog, F.T.H. (Frank) den <[email-masked]> wrote:
> There is a case then for having more than one homenet router in the home. They should therefore be considerably cheaper than some tens of $ which is what they cost today. 

The goal of homenet is to produce routers that deliver full IPv6 capabilities to homenets while preserving and improving upon the pluggability of IPv4 NAT home routers.   It is not to make home routers cost <$10. I'm not saying that's a bad goal, or that nobody should work on it.   But if that's what you want to work on, you are probably in the wrong working group.  I encourage you to read the homenet architecture document so as to familiarize yourself with the problem we are trying to solve here:

http://tools.ietf.org/html/draft-ietf-homenet-arch-10

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 01:54:56 +0200

> A more important factor is the size of the memory on the devices,
> a box with 8MB memory will have problem with running many services,
> but many boxes sold today have 32-128MB memory (both NVRAM and RAM)

An additional point is that all home routers sold in the last 10 years
or so have enough RAM to perform stateful NAT for hundreds of
connections.  Anything that can do stateful NAT can do IPv6 and
link-state routing without effort.

The community mesh networking community (ahem) has a lot of experience
with cheap boxes.  Henning will correct me if I'm wrong, but as far as
I am aware,

  - no box sold in the last few years has RAM issues (kernel+v4+v6+well
    implemented routing daemon fit in 32 Megs with plenty to spare);
  - some older boxes lack flash, this is not an issue on recent boxes;
  - some popular cheap boxes used to have power supply issues
    (overheating and crashing under load).

As flash and RAM keep getting cheaper, I expect the power supply to
increasingly become the main problematic component.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 09:02:16 +0200

> increasingly become the main problematic component.

Older (and cheap) home-routers had typically 4 MB flash and 16 MB RAM. 
You can run a dualstack router with routing protocol on this, but you 
have to be a bit careful not to overdo bloated additional software.

Many current home-routers have 32 MB RAM (some have more), some more 
"expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB.

Henning Rogge

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 Aug 2013 09:49:20 +0200 (CEST)

> "expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB.

How much of this cost increase is due to the flash and RAM, and how much 
is due to more expensive other components plus the software development 
effort to perhaps drive additional features these more expensive devices 
bring?

Personally I like the way CODEC WG approached this, by making a reference 
implementation available in source code in the standard. This is probably 
not practical for a complete homenet router, but at least my hope is that 
there will be freely available code that implementers can use so that just 
like they don't have to spend time to develop the linux kernel they're 
running on their devices, they don't have to develop (or buy) the routing 
control plane code (or forwarding for that matter), because it's already 
available.

So hopefully even homenet coming out with being quite complex compared to 
todays NAT44 routers typically seen, it won't mean all CPE manufacturers 
have to develop all functionality from scratch.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 10:09:38 +0200

> effort to perhaps drive additional features these more expensive devices

How much of it is just "hey, this is the improved version"? We don't know.

For 80$ you already get routers with 8 MB flash and 128 MB ram.

> Personally I like the way CODEC WG approached this, by making a
> reference implementation available in source code in the standard. This
> is probably not practical for a complete homenet router,

Why? A "homenet" package (most likely multiple packages) for OpenWRT as 
a reference implementation would be a great thing.

> but at least my
> hope is that there will be freely available code that implementers can
> use so that just like they don't have to spend time to develop the linux
> kernel they're running on their devices, they don't have to develop (or
> buy) the routing control plane code (or forwarding for that matter),
> because it's already available.

And it might give consumers the chance to get a router with a reasonable 
modern linux.

Henning Rogge

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 Aug 2013 10:44:13 +0200 (CEST)

On Mon, 12 Aug 2013, Henning Rogge wrote:

> Why? A "homenet" package (most likely multiple packages) for OpenWRT as a 
> reference implementation would be a great thing.

Well, I meant publishing the source code in the RFC text. I believe *WRT 
style implementation freely available is a great idea of course.

> And it might give consumers the chance to get a router with a reasonable 

Exactly. I'm running CeroWRT on a WNDR3800 that I bought refurbished for 
70USD. My hope is that in a few years when homenet is "done" this kind of 
device will be generally available at a lower price point new and 
available to everyone.

---

From: Teco Boot <[email-masked]>
Date: Mon, 12 Aug 2013 10:53:12 +0200

Joel Jaeggli mentioned the forwarding performance. Today's homenets are mainly single subnet with link-speed forwarding between (gig) ethernet ports, in hardware. L3 forwarding in software with single uplink or WiFi port at near to gig speed is doable. Forwarding in software on all ports require a new generation of low power and cheap CPU, I think. So probably use hardware forwarding as much as possible?

Teco

Op 12 aug. 2013, om 09:49 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:

>> Many current home-routers have 32 MB RAM (some have more), some more "expensive" ones (40$ and more) also upgrade the flash to 8 or 16 MB.
> 
> How much of this cost increase is due to the flash and RAM, and how much is due to more expensive other components plus the software development effort to perhaps drive additional features these more expensive devices bring?
> 
> Personally I like the way CODEC WG approached this, by making a reference implementation available in source code in the standard. This is probably not practical for a complete homenet router, but at least my hope is that there will be freely available code that implementers can use so that just like they don't have to spend time to develop the linux kernel they're running on their devices, they don't have to develop (or buy) the routing control plane code (or forwarding for that matter), because it's already available.
> 
> So hopefully even homenet coming out with being quite complex compared to todays NAT44 routers typically seen, it won't mean all CPE manufacturers have to develop all functionality from scratch.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 Aug 2013 11:40:17 +0200 (CEST)

On Mon, 12 Aug 2013, Teco Boot wrote:

> Joel Jaeggli mentioned the forwarding performance. Today's homenets are 
> mainly single subnet with link-speed forwarding between (gig) ethernet 
> ports, in hardware. L3 forwarding in software with single uplink or WiFi 
> port at near to gig speed is doable. Forwarding in software on all ports 
> require a new generation of low power and cheap CPU, I think. So 
> probably use hardware forwarding as much as possible?

Hardware assisted forwarding might be problematic due to us deciding on 
new functionality (source based routing for instance). I've read that in 
some routers the forwarding is done by microcode implemented by the 
hardware manufacturer, hindering the integrator (who buys the SoC in bulk) 
from doing what might be needed.

So yes, forwarding performance is a concern, at least when we're talking 
above 100 megabit/s.

I also think it would be beneficial if we could figure out as soon as 
possible what the requirements are on the forwarding plane, writing this 
down, so that hardware designers can avoid putting functionality into 
hardware that won't do what we need going forward.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 12 Aug 2013 13:03:42 +0200

On 08/12/2013 11:40 AM, Mikael Abrahamsson wrote:
>> Joel Jaeggli mentioned the forwarding performance. Today's homenets
>> are mainly single subnet with link-speed forwarding between (gig)
>> ethernet ports, in hardware. L3 forwarding in software with single
>> uplink or WiFi port at near to gig speed is doable. Forwarding in
>> software on all ports require a new generation of low power and cheap
>> CPU, I think. So probably use hardware forwarding as much as possible?
>
> hardware manufacturer, hindering the integrator (who buys the SoC in
> bulk) from doing what might be needed.
>

I agree, software forwarding should be the standard way. That makes it 
also more easy to adapt different routing protocols to HOMENET.

Henning Rogge

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Aug 2013 04:03:31 -0700

On 08/12/2013 01:44 AM, Mikael Abrahamsson wrote:
>
>> And it might give consumers the chance to get a router with a reasonable modern linux.
>
> Exactly. I'm running CeroWRT on a WNDR3800 that I bought refurbished for 70USD. My hope is that in a few years when homenet is "done" this kind of device will be generally available at a lower price point new and available to everyone.
>

I think that people would be more than happy to pay for beefed up home routers
if they actually did something that is near and dear to their heart instead of
things they don't understand. Like, oh say, was the controller to home automation,
and other things like that. Or you could put headless android apps on it with pretty
little ui's running on our phones. Routers have the desirable characteristic that
they are typically on 24/7, don't move around, and could easily serve up web
pages, etc, especially in a v6 world. Given how cheap ram/flash is these days,
I doubt that you'd even have to pay much more if anything at all.

Now when ISP's buy your router for you... a race to the bottom of course.

Mike

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 12 Aug 2013 10:44:05 -0400

>also more easy to adapt different routing protocols to HOMENET.

You guys are trying to hard to engineer products.  Figure out what it
should do and how, and let implementers implement it.  If you need
implementers to tell you how to do it, let's get more of them in here.

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 12 Aug 2013 11:07:46 -0400

On 8/12/13 7:03 AM, "Michael Thomas" <[email-masked]> wrote:

>> Exactly. I'm running CeroWRT on a WNDR3800 that I bought refurbished
>>for 70USD. My hope is that in a few years when homenet is "done" this
>>kind of device will be generally available at a lower price point new
>>and available to everyone.
>>
>

You would be mistaken.

Beyond my fundamental objection to the assumption that all routing devices
will run a profile we create just because we say so, you assume that
people have additional disposable income to spend on beefier home routers.

The presumption here--that we can dictate to consumers what features they
must buy--is breathtaking.  And possibly a violation of trust and consumer
protection laws in some places.  No matter how low-profile the device
specified by Homenet, it would be entirely possible to create a cheaper
device with less functionality that still served many households.  But
such a device would not interoperate with the Homenet devices.

>Now when ISP's buy your router for you... a race to the bottom of course.

Consumers are price-sensitive.  ISPs sell what a sufficient number of
consumers will buy.
Retail electronics stores sell what a sufficient number of consumers will
buy.  There are many sub-$50 routers on shelves, because they sell well.
Trying to add features so you can take lower-end routers off the market is
not going to work, because people will buy what they want.

Lee

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Aug 2013 08:41:13 -0700

> such a device would not interoperate with the Homenet devices.

Who's dictating anything? I said that if "routers" had features that
people liked and could relate to, they'd pay for it. It's manifestly
true: people now don't think twice about the $30/month for the
data plans for their iphones -- because they like them and have
features they can relate to. And routers are a fixed cost, rather than
a monthly treadmill.

> not going to work, because people will buy what they want.

They're price sensitive to things that for all intents and purposes
are the equivalent of an electrical outlet. And why shouldn't they?
Homenet isn't going to change that one whit. But routers are hosts
too... the same underlying "host" that drive all of their favorite
things. If you want a router to be well endowed, let it moonlight
as something people actually care about.

What's really funny is that I kept hearing the same argument about
cell  phones too -- that they're super constrained with tiny amounts of
ram/flash/display/etc. Now look at them. It's about features and
utility. Apple took that fallacy right to the bank.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 18:40:17 +0200

> If you need implementers to tell you how to do it, let's get more of
> them in here.

I wonder how friendly this group would be to outsiders who come with
working code?

(No need to answer.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Aug 2013 14:40:55 -0400

> I wonder how friendly this group would be to outsiders who come with

In general we're pretty friendly, but working code that doesn't do what we want can be reasonably thought of as a threat to forward progress, and therefore not constructive.  When it's not clear whether the code does what we want, of course there is controversy.   That's natural and desirable.

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 12 Aug 2013 16:48:41 -0400

>features they can relate to. And routers are a fixed cost, rather than

You're missing my point.  Yes, some people will happily pay an extra $30
for a home router with new features.  Others will not, or can not. We must
interoperate with those others.

Consider a variation: someone has a small, low-end network, and buys the
cheapest gateway they can find.  Some time later, they add another one,
for whatever functional reason.  Later, somehow another router finds its
way into the network.  Do we require them to rip and replace every device
they have?  Or do we expect that somehow all routers will support the
Homenet profile, in case it's used later?
It would depend on the size of the Homenet profile.  But building a
profile so large that we hope future hardware can handle it, or so large
that a manufacturer can compete by excluding it and knocking $5 off the
price, does not encourage interoperability.

>>> and other things like that. Or you could put headless android apps on
>>>it
>>> with pretty
>>> they are typically on 24/7, don't move around, and could easily serve
>>>up
>>> web
>>> pages, etc, especially in a v6 world. Given how cheap ram/flash is
>>>these
>>> days,

Some people will pay more for additional features.  But iPhones still have
to interoperate with non-Apple phones like Android, feature phones, and
rotary phones.
Only half of all new phone sales are for smart phones:
http://www.businessinsider.com/chart-of-the-day-smartphones-to-beat-feature
-phone-sales-2013-6
(Note that feature phones are a healthy second-hand market, so even if
they didn't drive sales, they would still be in wide use).

Lee

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Aug 2013 14:07:23 -0700

> price, does not encourage interoperability.

We're probably in violent agreement here. Today, cost is the only plausible
market differentiator since most people don't anything about networking.
So it's always a game of whether the step function on cogs supports X feature
set (where one value of X is homenet in this particular case). But it's constantly
bumping up against "can't afford it cuz need more ram/flash/processor).

If, on the other hand, the routers *also* included some features that consumers
could love and value beyond cost -- and sorry, nobody swoons for DHCP
or OSPF -- then the pressure might be off the router functionality since it
might be a relatively small footprints versus the added functionality (cf headless
android). Maybe we're not quite at that inflection point just yet, but Moore's law
keeps going and going and going...

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 12 Aug 2013 23:36:37 +0200

> Today, cost is the only plausible market differentiator since most
> people don't anything about networking.

[...]

> If, on the other hand, the routers *also* included some features
> that consumers could love and value beyond cost -- and sorry, nobody
> swoons for DHCP or OSPF -- then the pressure might be off the router
> functionality

FWIW, the reason the WNDR3800 are such nice machines for running
OpenWRT/CeroWRT is that the stock firmware includes functionality such
as NAS, printer and webcam sharing, and a fancy web interface.  (Not
sure about BitTorrent support.)

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Aug 2013 14:59:48 -0700

> sure about BitTorrent support.)

Right, aside from the actual network hardware, your lowest schmuck
android or iphone -- heck even an ipod -- could trivially support the ram/flash
and cpu needs of a homenet router. Just add some things to make people give
it a value beyond a strict cost equation and they'll judge it on that.

"It's my home lighting station and security cams and turns on the garden
watering... and I plug it right into the intert00bs!"

Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 10:59:24 +1000

> people have additional disposable income to spend on beefier home routers.

Today's routers have a NAT, packet inspecting firewall, DNS proxy,
http server, dhcp server, dhcp client, dynamic DNS client, routing
daemon and other stuff in a sub $50 box.  The same CPU is quite
capable of supporting a DNS server a DHCPv6 server, client, IPv6,
etc.  The only thing needed hardware wise is a little more flash
and a little more ram.  We are talking about a couple of additional
dollars of hardware.  There is absolutely no reason that the addition
functionally can't be supplied at essentially the same price point.

The problem is that most current IPv6 capable boxes shipping today
also include 802.11 n/a/c often with multiple radios which is more
expensive than 802.11b/g only boxes with a single radio.  The
additional flash and ram costs are insignificant compared with all
the other costs.  On top of that there are development costs which
have been recovered for the 802.11b/g boxes.  And how much markup
they can squease out of those that need IPv6 today.

If manufactures were willing to ship 802.11b/g only boxes with
HOMENET they could be delivered at the same price point as the IPv4
only boxes are today within $1 or $2.

> such a device would not interoperate with the Homenet devices.

And when you buy a cable / dsl modem it needs to meet a minimum set of
functionality.  This is no different.

> not going to work, because people will buy what they want.

It really depends on the features you are adding.  Software can generally
be added at $0 as it can increase volume.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Aug 2013 21:17:11 -0400

> only boxes are today within $1 or $2.

Just so I can be certain I've understood: "Manufacturers should either
reduce their profits by $1 or $2 per unit shipped, or reduce the
functionality that they offer, or both, in order to add a feature that
I think is important but that their customers apparently won't pay a
few dollars more for."  Do I have that right?  

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Aug 2013 18:19:15 -0700

> few dollars more for."  Do I have that right?

Let's keep in mind that flash/ram is a step function. Often the
incremental cost is entirely in NRE.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 12:15:29 +1000

> few dollars more for."  Do I have that right?  

I'm saying the price can be essentially the same.  It may be a
little bit more or it may be a little bit less to get more ram and
flash.  Most of the $50 boards were designed long ago which shows
in their external connectivity.  Small memory chips can actually
be more expensive to purchase than larger chips.

There is a assumption that HOMENET routers will be more expensive.
They don't have to be.  They are more complicated and have more
software on them.

Mark

---

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Aug 2013 10:50:36 -0400

> few dollars more for."  Do I have that right?  

Following up on "customers" and "features"...  Exactly what features will a homenet router vendor be able to sell to customers?  We all appreciate ZOSPF, automated prefix assignment and addressing, traffic engineering around wireless, etc.  What are vendors going to sell to customers?

Looking at one specific feature - could  vendors provide routing in a router available today that has wireless and wired interfaces?  I think they could but don't (I'd be happy to be told I'm wrong).  If I've got it right, why don't vendors provide routing that would be a 
marketable performance feature?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Aug 2013 11:11:50 -0400

> Following up on "customers" and "features"...  Exactly what features will a homenet router vendor be able to sell to customers?  We all appreciate ZOSPF, automated prefix assignment and addressing,…

It seems to me that the key feature of homenet routers, if we are successful, will be fewer support calls.

> marketable performance feature?

You mean as opposed to bridging?   I don't actually know how guest vlan isolation is currently done, but I assume that it involves separate subnets.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 13 Aug 2013 08:33:32 -0700

On 8/13/13 8:11 AM, Ted Lemon wrote:
>> Looking at one specific feature - could  vendors provide routing in a router available today that has wireless and wired interfaces? 
yes... they do. in in fact the whole notion of wan interfaces meaning
these boxes are presently routing.

something like:

http://www.netgear.com/home/products/wirelessrouters/high-performance/WNDR3700.aspx

Is a pretty good example of a circa 2012 dual radio plus gigabit
ethernet router with support for multiple subnets, guest ssids, limited
ipv6 routing (it's currently got a /64 from comcast via PD and is doing
RA +stateless dhcpv6) and nat. it was somewhat on the expensive side
(more than $100 US then less than $100 now)  but not dramaticailly so, I
bought it at frys.

This of course will be supplanted by one that provides 802.11ac thereby
providing an incentive to upgrade.

the openwrt wiki (I'm running the manufacturers firmware) tells me it's
a AR9344 (which is a mips SOC) running at 560mhz with 128MB of RAM

>>  I think they could but don't (I'd be happy to be told I'm wrong).  If I've got it right, why don't vendors provide routing that would be a

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Aug 2013 11:03:53 -0400

> if compute power and memory are not the issues, electricity matters.

Your home router is not battery powered (except for if you run it off a
battery back up system).

The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted,
this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2
years old: more recent routers are yet higher performance. Relative to what
you are used to on a desktop, the biggest performance differences are
caused by having a small cache (making many interpreted languages
relatively slow).  Even so, it's much faster than most desktops/servers
were not all that long ago, for integer codes.

I believe the power consumption is often dominated by the 1G ethernet
ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port
can consume significant power.  If you use a USB port, it can also consume
power (up to 2W).

The WiFi may account for a watt or so of the consumption (it turns out that
transmit and receive typically consume comparable amounts of power; the
transmit power isn't significant relative to the power consumed by the
signal processing that is done on receive).  The WiFi devices in handheld
devices may be somewhat more efficient (but also poorer performance: it
pays to have a good radio in the router, where power is easy to come by.).

- Jim

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Aug 2013 11:08:28 -0400

On Mon, Aug 12, 2013 at 4:44 AM, Mikael Abrahamsson <[email-masked]>wrote:

> device will be generally available at a lower price point new and available
> to everyone.
> 
>
>
The 3800 costs what it does in part due to having two radios (2.4 and
5ghz).  A single radio router would be cheaper (but not interesting for a
mesh network, due to 1/N performance with number of hops).

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Aug 2013 11:13:43 -0400

On Mon, Aug 12, 2013 at 5:40 AM, Mikael Abrahamsson <[email-masked]>wrote:

>> require a new generation of low power and cheap CPU, I think. So probably
>> use hardware forwarding as much as possible?
>>
>

Actually, I think (Dave Taht can tell us with data), that forwarding
performance is fine even on today's routers up to 300-400Mbps on the
WNDR3800 running CeroWrt (which routes, rather than bridging between
interfaces)..  The 600Mhz MIPS can't saturate a gigabit ethernet, however
(at least not without using lots of hardware offload on the ethernet
controller, which hurts latency and creates
other problems (packet bursts).

But as SOC's are increasing in speed while the price goes down...

> hardware that won't do what we need going fo
> r
> ward.

Hardware "assists", e.g. TSO, and GSO, are a problem, particularly in the
home.  You don't want line rate bursts going onto your WiFi (though
fq_codel helps that quite a bit, it's still evil).

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 14 Aug 2013 11:15:32 -0400

From: Jim Gettys <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 14, 2013 11:03 AM
To: Brian Carpenter <[email-masked]<mailto:[email-masked]>>
However, today's devices are overwhelmingly battery-powered, so even
if compute power and memory are not the issues, electricity matters.

Your home router is not battery powered (except for if you run it off a battery back up system).

This is true, but I believe this thread started as a discussion of the capabilities of devices that aren't what we currently think of as "The home router" but still have routing functions, or have other interactions with Homenet which might be constrained.  When specifying protocols for interoperability, the most-constrained device determines the capabilities.

Lee

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Aug 2013 11:19:35 -0400

> implementers to tell you how to do it, let's get more of them in here.

Yup.  People here should have a bit of faith in Moore's law.   These are
real computers, and nothing I've seen is very difficult.

 And most of this stuff is already running fine in OpenWrt/CeroWrt as
existence proof of viability.

I do urge everyone to get their hands dirty, of course.

Then you'd be discovering things like:
   1) to deploy DNSSEC, you need to securely get time at boot time from the
network.
   2) to deploy DNSSEC, you need enough randomness in the entropy pool to
generate the self-signed certs when you do the initial installation.

(both these examples are very real, and Homenet should ensure these get
fixed).

Rather than worrying so much about whether the routers can do what you
need, you'll be finding the real issues that need to be solved.
                                            - Jim

> Lee
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Aug 2013 08:20:06 -0700

On 08/14/2013 08:03 AM, Jim Gettys wrote:
>
> The one I've measured consumes of order 5W, IIRC (WNRD3700v2).  As noted, this is a 600Mhz SOC MIPS architecture (Atheros).  This is now about 2 years old: more recent routers are yet higher performance. Relative to what you are used to on a desktop, the biggest performance differences are caused by having a small cache (making many interpreted languages relatively slow).  Even so, it's much faster than most desktops/servers were not all that long ago, for integer codes.
>
> I believe the power consumption is often dominated by the 1G ethernet ports; a 1ghz SOC is only around 1W power consumption.  Each ethernet port can consume significant power.  If you use a USB port, it can also consume power (up to 2W).
>
> The WiFi may account for a watt or so of the consumption (it turns out that transmit and receive typically consume comparable amounts of power; the transmit power isn't significant relative to the power consumed by the signal processing that is done on receive).  The WiFi devices in handheld devices may be somewhat more efficient (but also poorer performance: it pays to have a good radio in the router, where power is easy to come by.).
>

Thanks for the stats, Jim. Having worked on both iphone and android apps, it is
*maddeningly* difficult to be a good battery citizen. There is no instrumentation
last I looked to determine things like "If you transmit n bytes, typical battery use
will be m mw at distance X" or "if you turn on this sensor at rate x, you can expect
it to consume y mw", etc. I wish the Google and Apple would do something more
than just being a scold ("don't use those features!") and forcing developers to put
inane disclaimers in their product descriptions. If they really wanted good
battery performance, they'd provide the OS level reporting that is necessary to
make good decisions. Like, oh say, "Golly it takes a lot of juice to get to that tower,
maybe I'll back off!"

And of course this isn't just phones, it's anything with a battery.

Mike

---

From: Dave Taht <[email-masked]>
Date: Wed, 14 Aug 2013 08:21:26 -0700

oh, no, forwarding rates are not very good. I have a bunch of numbers on
forwarding rates on the wndr3800 stuff, at best it's half that for routing
rather than bridging. I can give you current pps or bytes/sec, but not
right now. (felix just did a ton of tuning in this area). Bridging
outperforms routing by like 6x1.

Add in firewall rules or nat, or a software rate limiter, and you are well
below 100Mbit for forwarding rates over the ethernet on that particular box.

It's not the SOC per se' that's the issue, it's the tiny caches (vs, like,
um, ivy bridge), and the (generally 16 bit single channel) pretty slow
memory interfaces common in these platforms, as well as MIP's general
decrepitude.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

---

From: Jim Gettys <[email-masked]>
Date: Wed, 14 Aug 2013 12:36:11 -0400

On Wed, Aug 14, 2013 at 11:20 AM, Michael Thomas <[email-masked]> wrote:

>> The WiFi may account for a watt or so of the consumption (it turns out
>> that transmit and receive typically consume comparable amounts of power;
>> the transmit power isn't significant relative to the power consumed by the
My knowledge of power consumption is a bit dated on WiFi: I had to live and
breathe power consumption on battery devices when working on OLPC 5-6 years
ago.  It may be considerably lower at this date (probably is) on WiFi
devices used primarily for handhelds. Someone with current data would be
helpful to chime in here.

On the OLPC, we had a autonomous processor (a very low power ARM 9, IIRC),
four packet buffers, and the device could forward packets in the mesh
network without requiring the main processor to be involved at all. That
module consumed somewhere between .5 and 1W, IIRC.  Actual numbers are
someplace in the OLPC Wiki...  Transmit & receive power were roughly
comparable.

The big headache about WiFi is the current need to leave the receiver
powered up (taking the signal processing power hit).  And, of course,
most handhelds don't have another CPU to do the packet forwarding (so you'd
need to wake up the CPU to forward any packets).  It ought to be the case
that you'd not have to listen at all times (and I think there are
unimplemented 802.11 features to do so), but in practice, the last I knew,
you had to always be listening, so the power consumption was continuous.

The other major headache is trying to reduce unnecessary wakeups to the
main CPU (and when you do, take care of as much business as you can).
 IIRC, we got the wakeup rate down to order of 10's/second. I know Linux
has improved quite a bit in this area over this period; dunno what the
current state of the art is.
                             - Jim

---

From: joel jaeggli <[email-masked]>
Date: Wed, 14 Aug 2013 09:39:45 -0700

On 8/14/13 8:15 AM, Howard, Lee wrote:
>
>
> From: Jim Gettys <[email-masked] <mailto:[email-masked]>>
> This is true, but I believe this thread started as a discussion of the
> capabilities of devices that aren't what we currently think of as "The
> home router" but still have routing functions, or have other
> interactions with Homenet which might be constrained.  When specifying
> protocols for interoperability, the most-constrained device determines
> the capabilities.
>
In fact, at some levels of contsraint the issue is not that some devices
limit the capabilities of the network, it's that other devices have to
act as proxies on their behalf... If you don't have enough memory for
100 ND/ARP entries, then probably you're only going to allow for one,
e.g. a router. Wake-on-lan devices aren't ip speakers per-say but they
can be triggered by a router broadcasting or multicasting a packet.
Apple wake on demand/bonour sleep proxy is a literal proxy to work with
contrained devices (in this case nics that are awake even when machines
are not). zigbee lightlink bridges as featured in  philips hue (which
uses ipv6 btw) are another example of such a proxy, sure I can make a
lightbulb with wifi, but why frankly should it sit there and listen to
the inane multicast chatter of my bonjour devices all day when it
doesn't need a printer/remote display/storage device?

If constraints results in artifically small limitations to subnet size
or device count or constraint the functionality of the ethernet mac
layer then we've pretty much failed. there are practical  limitations
that apply in homenets just as the do in datacenters or elsewhere and
fitness for a particular purpose or application may vary.
> Lee
>
> ------------------------------------------------------------------------
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient of this E-mail, you
> are hereby notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments to this
> E-mail is strictly prohibited and may be unlawful. If you have
> received this E-mail in error, please notify the sender immediately
> and permanently delete the original and any copy of this E-mail and
> any printout.
>
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Aug 2013 09:44:03 -0700

On 08/14/2013 09:36 AM, Jim Gettys wrote:
>
>
>
> On Wed, Aug 14, 2013 at 11:20 AM, Michael Thomas <[email-masked] <mailto:[email-masked]>> wrote:
>
> My knowledge of power consumption is a bit dated on WiFi: I had to live and breathe power consumption on battery devices when working on OLPC 5-6 years ago.  It may be considerably lower at this date (probably is) on WiFi devices used primarily for handhelds. Someone with current data would be helpful to chime in here.
>
> On the OLPC, we had a autonomous processor (a very low power ARM 9, IIRC), four packet buffers, and the device could forward packets in the mesh network without requiring the main processor to be involved at all. That module consumed somewhere between .5 and 1W, IIRC.  Actual numbers are someplace in the OLPC Wiki...  Transmit & receive power were roughly comparable.
>
> The big headache about WiFi is the current need to leave the receiver powered up (taking the signal processing power hit).  And, of course, most handhelds don't have another CPU to do the packet forwarding (so you'd need to wake up the CPU to forward any packets).  It ought to be the case that you'd not have to listen at all times (and I think there are unimplemented 802.11 features to do so), but in practice, the last I knew, you had to always be listening, so the power consumption was continuous.
>
> The other major headache is trying to reduce unnecessary wakeups to the main CPU (and when you do, take care of as much business as you can).  IIRC, we got the wakeup rate down to order of 10's/second. I know Linux has improved quite a bit in this area over this period; dunno what the current state of the art is.
>

What's really needed is something like a bprof that developers can run both
in dev, as well as deployed (deferred to be sent up when convenient). And
this should be a first-rate feature of Android/Eclipse as well as Xcode. Even
if *just* those two were done, it would go a very long way to helping battery
use for a lot of non-phone apps because it would raise the awareness of what
to check for, and what is downright dumb. Right now it's way too easy to just
throw up your hands and say "Sorry! Get a bigger battery!".

Mike

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 14 Aug 2013 12:47:20 -0400

On 8/14/13 12:39 PM, "joel jaeggli" <[email-masked]> wrote:

>act as proxies on their behalf...

Yes, that's true, and a very good point.
Does that mean that we have to figure out the minimum footprint to play
Homenet, and figure out how to signal proxy capability to anything not
tall enough to ride this ride?

Lee

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Aug 2013 15:16:53 -0400

> It seems to me that the key feature of homenet routers, if we are successful, will be fewer support calls.

Seriously, that's it?  We're discussing several new technologies, based on a speculative model for home network architecture and deployment models, and the primary advantage is fewer support calls?

...which sounds like more of an advantage for the SPs - which is not a bad thing but I don't think "Now with fewer service calls!" is going to sell many routers.

> You mean as opposed to bridging?   I don't actually know how guest vlan isolation is currently done, but I assume that it involves separate subnets.

IMO, any traffic isolation will be based on a logical network topology that is independent of the physical network, so the routing envisioned in the current homenet technologies will need augmentation with some additional mechanisms.  So with my devil's-advocate-luddite hat firmly pulled down over my ears, I'll suggest that there is no advantage to the customer from routing as envisioned between randomly placed devices in a home network, and that re-using some existing bridging technology might be a better choice.

- Ralph, who realizes he's just painted a target on his chest

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Aug 2013 15:22:12 -0400

On Aug 13, 2013, at 11:33 AM 8/13/13, joel jaeggli <[email-masked]> wrote:

> ethernet router with support for multiple subnets,

I can't find the appropriate info from the website - different prefixes on wired and wireless with routing between them?

> guest ssids,

guest isolation only on wireless?

> limited

OK, thanks for this information about the current market.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Aug 2013 15:26:36 -0400

On Aug 14, 2013, at 11:21 AM 8/14/13, Dave Taht <[email-masked]> wrote:

> oh, no, forwarding rates are not very good. I have a bunch of numbers on forwarding rates on the wndr3800 stuff, at best it's half that for routing rather than bridging. I can give you current pps or bytes/sec, but not right now. (felix just did a ton of tuning in this area). Bridging outperforms routing by like 6x1.

Still with my devil's advocate hat on, and recognizing that I'm comparing a problem resulting from multicast with raw unicast performance, I thought routing between wireless and wired links was necessary to avoid a performance hit.  In practice, on a real and usual home network, does the performance hit from bridging multicast onto wireless outweigh the lower forwarding rates for routing unicast?

- Ralph

> 
> Add in firewall rules or nat, or a software rate limiter, and you are well below 100Mbit for forwarding rates over the ethernet on that particular box.
> 
> It's not the SOC per se' that's the issue, it's the tiny caches (vs, like, um, ivy bridge), and the (generally 16 bit single channel) pretty slow memory interfaces common in these platforms, as well as MIP's general decrepitude. 
> 
> 
> 
> 
> On Mon, Aug 12, 2013 at 5:40 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Hardware assisted forwarding might be problematic due to us deciding on new functionality (source based routing for instance). I've read that in some routers the forwarding is done by microcode implemented by the hardware manufacturer, hindering the integrator (who buys the SoC in bulk) from doing what might be needed.
> 
> So yes, forwarding performance is a concern, at least when we're talking above 100 megabit/s.
> 
> Actually, I think (Dave Taht can tell us with data), that forwarding performance is fine even on today's routers up to 300-400Mbps on the WNDR3800 running CeroWrt (which routes, rather than bridging between interfaces)..  The 600Mhz MIPS can't saturate a gigabit ethernet, however (at least not without using lots of hardware offload on the ethernet controller, which hurts latency and creates
> I also think it would be beneficial if we could figure out as soon as possible what the requirements are on the forwarding plane, writing this down, so that hardware designers can avoid putting functionality into hardware that won't do what we need going fo rward.
> 
> Hardware "assists", e.g. TSO, and GSO, are a problem, particularly in the home.  You don't want line rate bursts going onto your WiFi (though fq_codel helps that quite a bit, it's still evil).
> 
> 
> -- 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2013 16:09:06 -0400

> ...which sounds like more of an advantage for the SPs - which is not a bad thing but I don't think "Now with fewer service calls!" is going to sell many routers.

No, the point is that right now if you just take a bunch of IPv4 nat routers and plug them together, they work, because they're all translating.   Of course, service discovery fails utterly, but basic IP service works.   We want to deliver IPv6 functionality with routing and no translating, working service discovery across subnets, and support for multihoming.   And we want it to work more seamlessly than current single-homed IPv4 nat routers work.   That's a big deal, and worth working on, but the primary result of getting it right really is "fewer support calls."

We obviously have other features we want, and we may be able to figure out a way to convince end users that they want these features: for example, naming in the homenet, and phone home capabilities, and stuff like that.   But right now I have no idea how I sell "naming in the home" to 

> IMO, any traffic isolation will be based on a logical network topology that is independent of the physical network, so the routing envisioned in the current homenet technologies will need augmentat…

We really want traffic isolation.   I guess we could do that with TRILL, but we can also do it with subnetting.   There are significant advantages for subnetting, not the least of which is that we don't have all that dnssd multicast traffic being relayed across links with different performance characteristics.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2013 22:14:29 +0200

> In practice, on a real and usual home network, does the performance
> hit from bridging multicast onto wireless outweigh the lower
> forwarding rates for routing unicast?

These are not directly comparable.

Forwarding performance limitations is something you pay all the
time -- if your router cannot exceed 1 Mpps, then you're going to be
limited to 1 Mpps no matter what.

The cost of bridging 802.11 with Ethernet is something that you only
pay when there are significant amounts of broadcast/multicast traffic
on the Ethernet link.

Note furthermore that both issues are fixable.  The forwarding performance
can be drastically improved by disabling connection tracking (quite
reasonable for IPv6), while the multicast issue can be fixed by
implementing IGMP snooping (yuck) in your bridge.

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Aug 2013 13:18:49 -0700

> We obviously have other features we want, and we may be able to figure out a way to convince end users that they want these features: for example, naming in the homenet, and phone home capabilities…

I can. Right now in v4 world, calling home for just about anything is pretty
kludgy. Getting real server-like functionality with real names like nature
intended would go a very long way to making it easier for companies and
developers to design and deploy those things. Maybe they have a:

"Requires Homenet Capable Router!"

Stamped on them. Voila, the internet of things, as well as turnover for the
router vendors. Happiness ensues for all.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2013 16:25:09 -0400

> router vendors. Happiness ensues for all.

Absolutely.   But this isn't a straightforward sell, as you've just shown.   First the end user has to want to buy <foo>, and then <foo> requires <homenet router>, and now the user wants to buy <homenet router>.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Aug 2013 16:27:41 -0400

> pay when there are significant amounts of broadcast/multicast traffic

Yup ... so I'm curious about whether one cost or the other dominates in today's home networks or what we extrapolate as future home networks.  My intuition (perhaps supported by your observation about the penalty of forwarding performance) is that the penalty from routing performance has more impact than the penalty from bridging multicast traffic unnecessarily.

> implementing IGMP snooping (yuck) in your bridge.

Is the IGMP code available in Linux today?

- Ralph

---

From: joel jaeggli <[email-masked]>
Date: Wed, 14 Aug 2013 13:32:43 -0700

> Is the IGMP code available in Linux today?
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Snooping

---

From: Ralph Droms <[email-masked]>
Date: Wed, 14 Aug 2013 16:33:06 -0400

On Aug 14, 2013, at 4:09 PM 8/14/13, Ted Lemon <[email-masked]> wrote:

> No, the point is that right now if you just take a bunch of IPv4 nat routers and plug them together, they work, because they're all translating.

Depends on how you plug them together.  They will also work correctly as bridges if plugged together correctly, too.  By enabling spanning tree bridging or waiting for SPF bridging, those devices could be plugged together randomly and still work.

>   Of course, service discovery fails utterly, but basic IP service works.   We want to deliver IPv6 functionality with routing and no translating, working service discovery across subnets, and support for multihoming.   And we want it to work more seamlessly than current single-homed IPv4 nat routers work.   That's a big deal, and worth working on, but the primary result of getting it right really is "fewer support calls."

OK, but I think multi-homing support is orthogonal to internal routing in the homenet.  Routing might make the multi-homing problem worse...

> We really want traffic isolation.   I guess we could do that with TRILL, but we can also do it with subnetting.   There are significant advantages for subnetting, not the least of which is that we…

There are two kinds of traffic isolation - one is based on physical network topology (wireless/wired) and the other is based on logical device isolation (home/guest).  Routing to avoid multicast over wireless doesn't provide home/guest isolation.

- Ralph

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Aug 2013 22:35:53 +0200

> No, the point is that right now if you just take a bunch of IPv4 nat routers and plug them together, they work, because they're all translating.   Of course, service discovery fails utterly, but ba…

Hopefully using straight IPv6 instead of NAT with IPv4 might also
improve the performance of the homerouters.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Aug 2013 13:37:42 -0700

> Absolutely.   But this isn't a straightforward sell, as you've just shown.   First the end user has to want to buy <foo>, and then <foo> requires <homenet router>, and now the user wants to buy <ho…

I think that the basic problem is that the call-servers-in-homes is still waiting
just like everything else for v6 to be deployed wide enough that widget makers
can see a big enough market to justify the hardware dev cost. Regardless of
technology, what the cablelabs folks are doing is goodness if it helps that problem
along. I know this is very US-centric, but if just a couple of the big MSO's rolled
out v6 to the masses that an internet of things could take advantage of -- and we
could get our part done especially on the external naming -- a "Homenet Capable
Router" stamp might just work and actually give a reason that people care about
v6 (well, not really v6 but the ability to use their Internet of Things widgets).

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 15 Aug 2013 01:05:59 +0200

> Yup ... so I'm curious about whether one cost or the other dominates
> in today's home networks or what we extrapolate as future home
> networks.  My intuition [...] is that the penalty from routing
> performance has more impact

You're probably right -- right now, the multicast activity is reduced
to just ARP/ND and mDNS (triple-play providers use a separate ATM
circuit or Ethernet VLAN for carrying the television streams).  What
worries me, however, is that if we go the bridging route, we will make
it difficult or even impossible to deploy multicast services in the future.

> Is the IGMP code available in Linux today?

As mentioned by Joel -- it appears to be included in recent kernels,
although I don't know of anyone who has actually checked if it works.
(I'll take this opportunity to remind people that IGMP snooping is
a horrible hack.  Multicast routing is much better done at the layer
where it belongs.)

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Aug 2013 19:12:06 -0400

Ralph Droms <[email-masked]> wrote:
    >> No, the point is that right now if you just take a bunch of IPv4 nat
    >> routers and plug them together, they work, because they're all
    >> translating.

    > Depends on how you plug them together.  They will also work correctly
    > as bridges if plugged together correctly, too.  By enabling spanning
    > tree bridging or waiting for SPF bridging, those devices could be
    > plugged together randomly and still work.

They won't (in the sense that all computers won't be able to print to all
printers, while simultaneously unless you also turn off the multiple DHCPv4
servers.

But, we went through this two (or was it three) years ago.

--
Michael Richardson <[email-masked]>, Sandelman Software Works