Subject: Re: Bringing back Internet transparency

From: [email-masked] (Noel Chiappa)
Date: Tue, 30 Jul 2013 09:23:05 -0400 (EDT)

> From: Roland Bless <[email-masked]>

    > we probably need to do something on reducing the number of _broken_
    > middleboxes (or their implementations respectively) - I'm not focusing
    > on NAT boxes here.
    > ...
    > I think it's clear that we will not get rid of them, but if I hear
    > about boxes that try to do "clever optimization" or "security" by
    > re-writing TCP sequence numbers ... bundling segments and so on, I'm
    > wondering who actually engineered those boxes; aren't the
    > vendors/engineers participating in the IETF? Who buys and deploys such
    > boxes
    > ...
    > What could be IETF efforts to get a better situation for the deployment
    > of future innovations or do we simply accept that (a few) broken
    > middleboxes dictate the future level of innovation in the Internet?

I hear you, but... this is not a simple problem.

I think we need to start by understanding what drives the creation and
deployment of these devices. I think the answer to that has to be that some
people have needs that aren't being met by the IETF, and so there's an
opportunity for private entities to create and sell 'solutions'.

The IETF doesn't have a police force, or any enforcement mechanism. If we're
going to head off these boxes, the only tool we have to do that is to build
better mousetraps - i.e. design stuff that does what people want, is more
cost-effective, and is better than these local 'point deployment' boxes.

Sadly, the IETF has a long history of being hard-headed about 'my way or the
highway', and not carefully listening to what the 'customers' are telling us
about these various aspects of a successful design.

(The most noteable example of this being NAT - which was going to be ugly
anyway, but as a result of the IETF refusing to create an architected NAT
solution - apparently on the theory that if we stuck our fingers in our ears
and went la-la-la-la loud enough, it would Just Go Away - we now have NAT that
is both ugly _and_ brittle [because it's not part of an architected _system_],
difficult to work with because it [mostly] lacks any external control
interface, etc.)

So, sorry, I don't have a simple solution to what I concede is a real problem.
But it's a complicated problem -> no simple solution.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2013 17:25:48 +0200

On Jul 30, 2013, at 3:23 PM, Noel Chiappa wrote:

> The IETF doesn't have a police force, or any enforcement mechanism.

That's true, but people do sometimes cite IETF specifications as requirements for equipment procurement.   And in many cases it is possible to test equipment for conformance to specifications.

> If we're

That's not the "only tool" (see above), but to the extent we're failing to address legitimate needs, we need to identify those needs and see what we can do to address them. And we need to do this as early as possible, ideally before we've gone down a particular path so far that there's too much deployment of a protocol that can't be retro-fitted to address those needs.   We have no structure at all for doing this now.

> about these various aspects of a successful design.

I suspect it's worse than that.   We don't even know who our customers are.

> difficult to work with because it [mostly] lacks any external control

It's ridiculous to say that we have NAT because we didn't architect NAT.  NAT has never been a good idea from any long-term point of view.   The only justifications that have ever existed for NAT were short-term hacks.     Our mistake, in hindsight, was in not specifying NAT in such a way that they provided a transition path away from NATs.   (perhaps something like PCP in conjunction with v4/v6 NAT, though there's a huge privacy/security problem with that kind of approach that I've never figured out how to address, so I'm inclined to think that PCP makes things still worse.)   

Though of course an underlying problem is that no vendor wants to sell hardware that will obsolete itself, unless of course it obsoletes itself by requiring the customer to purchase even more expensive hardware than it replaces.    It's hard to see how IETF could fight against vendors who were making good money by making the network more complex, less reliable, and less flexible.

Keith

---

From: Josh Howlett <[email-masked]>
Date: Tue, 30 Jul 2013 15:55:06 +0000

>
>Though of course an underlying problem is that no vendor wants to sell
>hardware that will obsolete itself, unless of course it obsoletes itself
>by requiring the customer to purchase even more expensive hardware than
>it replaces.    It's hard to see how IETF could fight against vendors who
>were making good money by making the network more complex, less reliable,
>and less flexible.

Personally I would characterise this as a demand-side problem, not
supply-side: most users plainly aren't willing to pay for Internet
transparency. You can't blame vendors or providers for not making stuff or
operating services that people won't pay for. The issue IMO is the lack or
poor alignment of economic incentives for choosing implementation and
deployment options that promote transparency.

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2013 17:59:11 +0200

On Jul 30, 2013, at 5:55 PM, Josh Howlett wrote:

> transparency.

I don't think that's the problem; I think the problem is that most users don't realize how much lack of transparency is harming them.   So "transparent Internet access" isn't a commodity.    Transparency would be cheaper if there were more demand for it, and there would be more demand for it if people realized how much more utility they'd get out of the Internet if they had it.

Keith

---

From: Josh Howlett <[email-masked]>
Date: Tue, 30 Jul 2013 16:15:48 +0000

>I don't think that's the problem; I think the problem is that most users
>don't realize how much lack of transparency is harming them.

Sure, but that's really just the 'opportunity cost' side of the same coin.
Converting that opportunity cost into a tangible value proposition for the
user is probably the most important part of a solution.

Josh.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 30 Jul 2013 17:33:16 +0100

On Tue, Jul 30, 2013 at 4:25 PM, Keith Moore <[email-masked]>wrote:

> That's true, but people do sometimes cite IETF specifications as
> requirements for equipment procurement.   And in many cases it is possible
> to test equipment for conformance to specifications.
>
>

{{citation-needed}} - I've only ever seen specification conformance in
procurement documents for military systems, never for anything else.

And moreover, I suspect that this doesn't matter; the kinds of people
who're procuring, as such - rather than either buying or just living with
what someone else bought - are a tiny minority. Real people, who drive most
of the internet's use, wouldn't know or care if their new router supported
RFC 6592.

Maybe this could be addressed by having a Marketing Label™ to attach to
internet access, in the same way that WiFi™ has helped 802.11a/b/g/n do so
well. I'm pretty sure than if (for example) Skype stamped on its box that
you were recommended to have Halfway Decent™ bandwidth, that an ISP could
start to market their Halfway Decent™ offering, and would be procuring
Halfway Decent™ equipment. And for what it's worth, I'd happily pay -
indeed, do happily pay - a premium to have Halfway Decent™ internet access.
But I'm not sure this is an IETF activity - perhaps an ISOC one though.

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jul 2013 16:59:14 +0000

On Jul 30, 2013, at 6:33 PM, Dave Cridland <[email-masked]> wrote:
> {{citation-needed}} - I've only ever seen specification conformance in procurement documents for military systems, never for anything else.

It's quite common to see a list of supported RFCs in the spec sheet for a piece of network hardware.   University of New Hampshire testing lab does a lot of testing, including home gateway testing, TRILL testing, and so on.

> And moreover, I suspect that this doesn't matter; the kinds of people who're procuring, as such - rather than either buying or just living with what someone else bought - are a tiny minority. Real people, who drive most of the internet's use, wouldn't know or care if their new router supported RFC 6592.

No, they don't, but they care that Comcast says it works, because they know what happens if they use a router that Comcast doesn't say works.

> Maybe this could be addressed by having a Marketing Label™ to attach to internet access, in the same way that WiFi™ has helped 802.11a/b/g/n do so well. I'm pretty sure than if (for example) Skype stamped on its box that you were recommended to have Halfway Decent™ bandwidth, that an ISP could start to market their Halfway Decent™ offering, and would be procuring Halfway Decent™ equipment. And for what it's worth, I'd happily pay - indeed, do happily pay - a premium to have Halfway Decent™ internet access. But I'm not sure this is an IETF activity - perhaps an ISOC one though.

Yes, labeling is another very good solution—see the V6Ready label that was used for the World IPv6 launch.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Jul 2013 09:21:01 -0800

On 7/30/13 7:59 AM, Keith Moore wrote:
> I don't think that's the problem; I think the problem is that most
> users don't realize how much lack of transparency is harming them.
> So "transparent Internet access" isn't a commodity.    Transparency
> would be cheaper if there were more demand for it, and there would be
> more demand for it if people realized how much more utility they'd
> get out of the Internet if they had it.

<n> decades in, I suspect that if there were going to be demand
for "transparency" we'd be seeing it by now.  If VoIP wasn't the
kick in the pants that's been needed to change things, it's
difficult to imagine what else might be.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Jul 2013 08:29:58 +1200

> difficult to imagine what else might be.

Users want applications to just work, but they (and many business
managers in our "industry") don't understand that when applications
fail unpredictably, it's often because of glitches in what we call
transparency.

However, we are in an arms race here. Every step to improve transparency
will be met by a further step in middleboxes that nibbles away at
transparency. We've been debating this for 15 years; have you seen
any real change in the balance of power?

    Brian

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Jul 2013 13:02:37 -0800

> fail unpredictably, it's often because of glitches in what we call

I suspect applications are not failing unpredictably often enough,
seriously enough, or impossible-to-fix-edly enough (thank you, I'm
here all week) to provide incentive for radical change in the
network, which elimination of problematic middleboxes would
certainly represent.  There are several things going on now
that I think hold some promise for overall approaches to improving
the situation but it's just hard to work on middlebox problems
in the IETF because you can't avoid getting bogged down in rehashing
the same ideological debates over and over and over again.  Yes,
problematic middlebox behavior causes real-world problems but
cursing the darkness hasn't yet been productive and I'm reasonably
sure that it never will be, particularly in a world where vendors
are churning out those cursed boxes and network operators and data
centers are buying them.

> any real change in the balance of power?

I'm not sure there is a balance of power between the people selling
middleboxes and the IETF.  In fact, I'm rather certain there isn't.

Melinda

---

From: Roland Bless <[email-masked]>
Date: Wed, 31 Jul 2013 00:35:10 +0200

Hi Noel,

> I hear you, but... this is not a simple problem.

Yes, and I wasn't expecting it to be simple...

> opportunity for private entities to create and sell 'solutions'.

Agree, that would be one possible action...

> The IETF doesn't have a police force, or any enforcement mechanism. If we're

Yep, that's true and I'm fully aware of it.

> cost-effective, and is better than these local 'point deployment' boxes.

... NAT ...

> difficult to work with because it [mostly] lacks any external control

That is a little bit more along my direction. Maybe we can at least give
advice what to strictly avoid and how to leave a path open for
innovation, e.g., do expect that other transport protocols may exist in
the future, so do not assume that only TCP and UDP are in use, or:
be prepared to process/bypass extension headers etc.

> But it's a complicated problem -> no simple solution.

I wasn't expecting that. :-)

Regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jul 2013 15:41:57 -0700

> cost-effective, and is better than these local 'point deployment' boxes.

Although I appreciate the sentiment, "what people want" (ISP operators, 
or at least some of them), was an artificial way to differentiate home 
customers from commercial providers.

I.e., they wanted to create a differentiation that wasn't part of the 
Internet architecture, so they put one in.

NATs did other things (reuse addresses, block services, etc.), but IMO 
mostly as a by-product of this primary motivation.

It's very hard to do "what people want" when what they want is to defeat 
the core concept of the architecture - that all endpoints are 'equal'.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 30 Jul 2013 23:04:39 -0400

> any real change in the balance of power?

Well this is the real issue. I really could not care whether my IP
addresses are constant end to end or change on each hop if the packets get
there.

What I do care a lot about is being able to work out what my network is
doing and which piece of equipment is responsible for any given fault.

One of the architectural shortcomings of the current situation is that the
Internet was originally designed to fill the gaps between the networks, the
inter-network. We now use the same architecture inside the local network.
Only it isn't optimized for network use in quite the same way or at least
the home user does not have a toolset that is as powerful for their
purposes as the Internet backbone providers have for theirs.

Instead what happened was that network devices that were poorly architected
to run under novel or windows or appletalk sprouted IP as a transport
choice. And in many cases this was done in a really shoddy way.
Filesharing, printers, the rest all hang off the network in ad hoc fashion.

Keith's obsession with NAT boxes is totally irrelevant to the core problem
which is that home networks don't use DNS as their
naming/directory/discovery infrastructure which is what they would do if
they were really Internet based. There is no model of what is 'normal' in
the network so no way to detect abnormal situations or the cause.

NAT is here to stay until the last IPv4 address is withdrawn which is 30
years off at minimum. And it will remain even then because there are so
many fun games to play with NAT.