Subject: Re: [homegate] [fun] HOMENET working group proposal

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 10:01:59 +0200

On Jul 1, 2011, at 1:10 AM, Robert Raszuk wrote:

> 
> I think this is a great WG proposal and I fully support it's creation.
> 
> However my ISP is telling me that it has sufficient pool of IPv4 addresses for the min next 5-10 years so rolling v6 for residential users is completely not that much appealing to him.

My ISP has v6 to a half-million homes and doesn't know how to deal with multiple v6 subnets (among other things) aside of manual configuration. But let's stay out of "my ISP says" discussions. Clearly, we can come up with anecdotes at every extreme. What's important is that, globally, IPv6 deployment is finally on the rise and implementations are appearing in commercial products targeted at the home. 

You are probably running IPv6 in your home anyway if you have a Mac, linux, or windows machine circa Vista or later. It may be disconnected from the Internet (or is possibly connected via some automatic tunnel that you may or may not be aware of), but even link-local IPv6 in the home is something that should work correctly. 

> 
> IETF can build many specs recommending v6 deployments, protocol extensions and network architectures. Unfortunately before the day  when there is first attractive real content available online _only_ via v6 or when there is new killer app which works only over v6 I think the world will become more and more fragmented into islands of v4, v4v6 and v6 only.
> 
> The issue is not technical here and IETF will not I am afraid be able to fix it.

There are technical issues with deploying IPv6 in the home, and that is what homenet is slated to work on. 

> The issue is purely business driven and till all providers get clear message from their users that they must have v6 as they can not google anymore, pay their bills, use new fancy holographic movie downloader app (just as examples) the migration towards v6 may take not 10 but 50 to 100 years.

Ah yes, the Killer App - it would all too easy if IPv6 had a visicalc or wordstar equivalent to drive sales, wouldn't it? 

http://en.wikipedia.org/wiki/Killer_application

That discussion is not really within the scope of this WG though.

- Mark

> 
> Cheers,
> R.
> _______________________________________________
> fun mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fun

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Fri, 1 Jul 2011 00:30:14 -0500

I'd like to second the relaxation of "wherever possible", which may lead to a suboptimal solution for several components.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 11:33 AM
To: Keith Moore <[email-masked]>
Cc: IETF Discussion <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [fun] [homegate] HOMENET working group proposal

On Jun 30, 2011, at 5:46 PM, Keith Moore wrote:

> 
> On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:
> 
>> 
>> I think the consensus we had in the past BoFs and discussion in and around this topic can be summed up as stating that homenet deliverables will:
>> 
>> - coexist with (existing) IPv4 protocols, devices, applications, etc.
>> - operate in a (future) IPv6-only home network in the absence of IPv4
>> - be IP-agnostic whenever possible
> 
> I'd like for this group to relax the "wherever possible" bit, so as to not preclude solutions where IPv6 can do a better job than IPv4.

Yes, and I think that IPv6 should naturally do a better job than IPv4 in the cases where it can. 

My original mail had this restatement of the above, which I think gets closer to what you want:

>> However, when we can define something that is needed for IPv6 in a way that is also useful for IPv4 without making significant concessions, we should go ahead and do so.

- Mark

> 
> IPv4 is a dinosaur gasping for its last breaths.
> 
> Keith
> 
> 
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: Mark Townsley <[email-masked]>
Date: Fri, 1 Jul 2011 10:53:37 +0200

On Jun 30, 2011, at 6:36 PM, Keith Moore wrote:

> On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote:
>>>> 
> when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4.

The idea is not to go out of our way for IPv4, but if the topic is IP agnostic anyway, so be it. To be clear, there is no *requirement* to support IPv4 here. However, there is no requirement to avoid IPv4 *if* it doesn't cause significant concession in the IPv6 design either.

This cuts both ways, if there is something that is working well in IPv4 that we need to carry over to IPv6 with simple extensions, we'll do that and capitalizing on that running-code should be considered a good thing. We don't want to invent new v6 protocols from scratch that don't work with IPv4 when there is no need. For example (and I think this is hinted at in the charter), we might use naming and service discovery that already exists for IPv4, adapted the the v6 homenet. This doesn't mean we need to re-invent a v6-only naming system from scratch - i'd much rather use one that is there, which very well may support v4 and v6. 

> 
> please don't constrain home networks to work only within the confines of IPv4 brain damage.

What I think I am saying here is that we will do our best to perform as if our brains are not damaged, and equally try to avoid damaging our brains in the process.

- Mark

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 Jul 2011 09:35:53 -0400

> What I think I am saying here is that we will do our best to perform as if our brains are not damaged, and equally try to avoid damaging our brains in the process.

+1

Keith

---

From: james woodyatt <[email-masked]>
Date: Fri, 01 Jul 2011 09:37:46 -0700

On Jun 30, 2011, at 6:34 PM, Martin Focazio wrote:
> On Jun 30, 2011, at 19:51, james woodyatt <[email-masked]> wrote:
>> 
>> The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa.  The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge.  The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard.
> 
> You assume at Alice CAN select a service provider. In a large part of
> the USA your choices are nil. You have a single wireline provider or
> you don't have a connection.

Telecommunications services are still ostensibly a regulated utility in the USA.

If the people living in those areas neither want to move, nor demand their utility commissions to hold service providers accountable for the proper operation of the monopoly franchise they receive from the government, then those people are making their choice.  Choosing an alternative is possible.  It entails either individual action to relocate or collective action to reform the telecommunications services.  Inaction, of course, is also an alternative.  People choose one or the other.

As I said, Alice can break Bob's applications by choosing her service provider.  And vice versa.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 8 Jul 2011 09:46:00 +0200

On Thu, Jun 30, 2011 at 4:57 AM, Fernando Gont <[email-masked]> wrote:
> On 06/29/2011 11:38 PM, Cameron Byrne wrote:
>
>> The opportunity for restoring e2e is one of the great opportunities of
>> ipv6
>
> This assumes that e2e reachability is a desired property for all networks.

A very good point, there are a few network that break e2e on purpose.
But I guess this mostly affect enterprises and not the general
Internet part, and still I would guess that the network on the
"inside" for those enterprises still use e2e quite heavily so it's
still relevant.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: ken carlberg <[email-masked]>
Date: Tue, 12 Jul 2011 09:11:10 -0400

Jari,

My apologies for the tardy response, but given the following text in the proposed charter...

> Home networks need to provide the tools to handle these situations in
> a manner accessible to all users of home networks. Manual
> configuration is rarely, if at all, possible. The purpose of this
> working group is to focus on this evolution, in particular as it
> addresses the introduction of IPv6, by developing an architecture
> addressing this full scope of requirements:
> 
> o prefix configuration for routers
> o managing routing
> o name resolution
> o service discovery
> o network security

...I was wondering where something like buffer-bloat, and in particular supporting/managing AQM, would fit in given the above.  Jim Getty's talk at the last IETF meeting was well received and appeared to open some eyes to an issue that seemed to have been easily overseen.  My impression is that work in Home Networks could help address some of the items that Jim brought up in his presentation.

thoughts?

-ken

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Jul 2011 10:04:09 -0400

> ...I was wondering where something like buffer-bloat, and in particular supporting/managing AQM, would fit in given the above.  Jim Getty's talk at the last IETF meeting was well received and appea…

I think that the need is felt in home, SOHO, and hotel (eg, broadband last mile) networks, and suggestions I have made along such lines have focused on them. However, the topic is closer to the charter of tsvwg IMHO, except in the ways that it manifests in broadband interfaces (the fact of the router, modem, CMTS/DSLAM, and upstream router being separate entities with separate buffers). The problem is in essence that ECN/AQM is generally not implemented in such networks, in part because there is a sense on the carrier side that loss is a bad thing, and in part because tuning the algorithms can be a pain. What the Georgia Tech folks have worked out, as much as anything, is an acceptable configuration driven by user perceptions rather than research optimizations (eg, for them it's not about finding the absolute knee of the curve and making the combined queue be as thin as possible, but finding a pragmatic solution that is predictable and acceptable to the typical user).

---

From: ken carlberg <[email-masked]>
Date: Tue, 12 Jul 2011 10:33:04 -0400

Fred,

> I think that the need is felt in home, SOHO, and hotel (eg, broadband last mile) networks, and suggestions I have made along such lines have focused on them. However, the topic is closer to the cha…

given that a lot of these boxes are linux-based, is it a case of not being implemented, or simply not being turned on in the shipped image?  And if the latter, then perhaps Homegate/Homenet offers us a means of configuring ECN/AQM.

And I agree, the algorithms would be something that is advanced in TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is just one part of where bufferbloat can manifest itself.

-ken

---

From: Mark Townsley <[email-masked]>
Date: Wed, 13 Jul 2011 14:07:35 +0200

> given that a lot of these boxes are linux-based, is it a case of not being implemented, or simply not being turned on in the shipped image?  And if the latter, then perhaps Homegate/Homenet offers…

Certainly, a primary homenet requirement would be that the parameters configure themselves so that a user does not have to. 

- Mark

---

From: Randy Turner <[email-masked]>
Date: Wed, 13 Jul 2011 05:58:02 -0700

+1 on the self-configuring of parameters

Randy