Subject: Re: Not Listening to the Ops Customer

From: [email-masked] (Noel Chiappa)
Date: Mon, 3 Jun 2013 11:56:42 -0400 (EDT)

> From: "cb.list6" <[email-masked]>

    > the emergent complex dynamical system we call the internet ... which is
    > almost completely zero compliant to the e2e principle. Not that e2e is
    > the wrong principle, but ipv4 could not support it as of 10+ years ago.
    > Hence, nearly every internet node is behind a stateful device
    > ...
    > Yet, corners of the ietf call this real world internet of middleboxes
    > as broken. As some of it is broken, so you have things ... to bust
    > through it. Mutation happens.
    > That said, the teaching moment here is look back and realize the
    > internet was not engineered, if was emerged.
    > Given that the internet is not engineered ... how do we make it go
    > fast, bigger, better given the few levers we have.

Exactly. The Internet is evolving, and can we push it in a better direction,
and if so, how?

In all of this, the bottom line, to me, is that we have to be aware of the
limits of our power. Mandating forklift replaces is just a non-starter. By
and large, new stuff has to interoperate to the maximum extent possible with
unmodified 'stuff'; an approach that don't require _any_ host modifications
is almost a sine qua non.

And it was long (and remains) a truism of system design that security can't
be added at the last stages - it has to be 'baked in' all the way through the
design process. The same is true, now, of deployment and interoperability.

I persist in thinking that those 32-bit names are continuing their evolution
into local-scope names, with translation at naming region boundaries. How can
we improve that - reduce the brittleness of the middleboxes you refer to, by
making their data more visible (and thus replicable, etc)?

And we still need global namespaces. DNS names are slowly becoming more key
(the Web now makes them a key namespace at the protocol level, not just the
content), but what else? At one point the IETF considered trying to craft a
new endpoint namespace (through the NSRG, if I have remembered the name
correctly), but I think in retrospect that's a non-starter - changing TCP
(which is what that would require) is not really an option (see point 1).

Within that 'deployable' envelope, I am now back to where I was almost 30
years ago, which is that _probably_ the thing to deploy is a new location
namespace, for use by the path-selection (since only _some_ routers have to
know about that). That's not a namespace the Internet has now, and so we'd be
less constrained in doing so, and it's one the Internet really needs.

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 04 Jun 2013 22:15:52 +0900

> making their data more visible (and thus replicable, etc)?

Just say, A+P, except that the original proposal of A+P has
wrongly assumed that a NAT box is required inside a site.

Still, surely, port numbers are local-scope names.

However, if the 16bit port numbers are combined with 32bit IP
addresses, they are the globally scoped names with 48 bit
length, which is a lot more than enough to make the Internet
fully end to end transparent even at the current global scale.

> but I think in retrospect that's a non-starter - changing TCP

Changing TCP is required not for address space extension but
for better handling of multiple addresses for better routing
table aggregation.

						Masataka Ohta