Re: [rrg] Paul Jakma's blog article

[Paul Jakma <[e-mail]>]

On Sun, 14 Feb 2010, Robin Whittle wrote:

> I believe that once you understood the proposals in detail, the question
> of what is being split or separated would matter to you.

Ok, I'm not sure I'm completely happy to have my understanding 
denigrated like that, when it could perhaps just be that I understand 
but don't consider certain things important at this point. :) But 
hey...

> You can do this and so ignore what I wrote - but you haven't argued 
> why anyone else should do the same or why I or anyone else should 
> respect your choices.

I didn't ignore what you said - CEE doesnt do tunneling. I'm trying 
to connect my terminology with yours and check whether they match.

> No - you can use "Core-Edge Separation" and "Core-Edge Elimination".  I
> am trying to be concise.

I don't really understand those terms tbh. I have had a glance 
through the RRG wiki (the "terminology" page particularly), and your 
http://www.firstpr.com.au/ip/ page, but I don't find an explanation.

The general architecture I'm familiar with that doesn't do tunneling 
instead uses address rewriting of some form. So I tend to call it 
"rewriting".

I'll try get accustomed to your terminology, but perhaps till then 
you can try tolerate mine. :)

> because there's no way the world will alter all its host stacks or 
> (for most CEE architectures) rewrite its applications *completely*

That is a significant concern alright. The only reason such a 
suggestion isn't complete crack is cause:

- The world basically already did this for IPv6, so we know what it
   involves.
- The apps that have updated should, by and large, now be using
   address family abstracting interafaces, making future changes
   slightly less painful.

>>> CEE architectures can only provide substantial benefits to adoptors
>>> and only provide real scaling benefits, when all, or almost all,
>>> networks adopt the new architecture.  This means moving everyone to
>>> IPv6 and altering all host stacks to implement the particular CEE
>>> architecture's alteration of IPv6.

>> I'd disagree with this. If you read the blog entry I'm outlining a
>> scenario where the immediate problem to be solved is pressure on NAT
>> (not multi-homing), leading to hacks being deployed which benefit both
>> customer and ISP together. These hacks then can be later, slowly,
>> extended to things like multi-homing.
>
> I don't see how the above paragraph relates to you disagreeing with the
> paragraph of mine before it.

> What you are proposing is neither a CEE nor a CES architecture.  You are
> proposing to extend the port range of IPv4 TCP and perhaps UDP
> protocols, as a means of enabling NAT boxes to serve more hosts from a
> single IPv4 address.

Correct, and so provide a basis for a CEE architecture to be built on 
it.

The NAT shortage is the initial pressing problem that gets the basic 
option in the field and deployed widely. Further protocols, offering 
further facilities, such as core-separated multi-homing, can then be 
layered on top.

> This doesn't solve the routing scaling problem in any way.  It is 
> an attempt to cope with a situation where there is such a shortage 
> of IPv4 space that there's not enough to run NAT boxes with 
> whatever limitations they have from the current 16 bit TCP/UDP port 
> numbering system.

I think you must have stopped reading that blog post about half way 
through, or you skimmed it :).

> I don't understand your reasoning - and I can't see where you have
> explained your reasoning.

I was proposing something more than just NAT. Specifically, I was 
describing a path of least-resistance toward a "core/edge separated 
internet, using rewriting" (CEE, right?), where the first step on 
that iteration of hacks is "make NAT work for higher number of 
hosts". Further, this proposal remains backward compatible with the 
existing IPv4 network, to a greater degree than other CEE proposals 
at least.

I think perhaps you may not have read the latter parts of that blog 
post. (My writing style is dry, dull and sucks generally, so I can 
understand you'd have fallen asleep a paragraph or two in! ;) ).

> establishing communications - with more management packets flowing back
> and forth etc.  Arguments against doing this are in:
>
>   Today's "IP addr. = ID = Loc" naming model should be retained
>   http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

The signalling overhead of an end-host<->end-host multihoming 
proposal is a concern. However, you have the same problem with the 
map-encap proposals - the signalling has to be done somewhere. You 
can do it on x hosts, or x/y middle-boxes.

It seems there's a compromise we have to pick between:

- carrying information about peripheral^Wedge networks in the core
   routing protocol

- carrying information about peripheral networks in packets *over*
   the core routing protocol.

To my feeble mind, I don't see any way for protocols alone to 
*reduce* the amount of signalling required, for a given amount of 
information about edge networks.

The only way to reduce that information is to organise the edge 
networks some way, e.g. through an administratively imposed hierarchy 
(aggretation by geography, IX, whatever), or by some clever dynamic 
organisation. I see that as an orthogonal matter to the protocol 
question, and one best left at the door to this WG.

> Please take a look at the graphs here:
>
>   CES & CEE are completely different (graphs)
>   http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

Those graphs are your opinion, rather than based on data :). If 
you're right, then CES will see deployment. We don't need to have a 
speculative argument about it here.

> If you disagree with this, then please write why.

If would move access customers to NAT, and use the reclaimed 
addresses for services that need it. If I were part of a community of 
ISPs I would start looking at cross-organisation reclaiming of 
ineffectively used addresses. A free market in IPv4 addresses may 
well develop to allow organisations to put a price on the cost of 
renumbering Vs the cost of not having public IP space, and so 
facilitate reclaiming. If I were an ISP, I would do all these things 
well before deploying CES.

As I wrote earlier, it is quite plausible that such address space 
recyling will serve the needs of the IPv4 internet for quite a while 
- at least long enough for the NAT problem to become a pressing one 
to solve.

And as I wrote in blog post, solving the NAT problem can provide the 
immediate benefit to get an extension widely deployed that can then 
be used as the basis for a CEE architecture.

Small incremental steps.

> CES involves adding some things to the network.  This is easier than
> changing all the apps.

Experience with IPv6 suggests otherwise.

It's 15 odd years now, and the inter-network still does not generally 
support IPv6. Despite the lack of IPv6 network service, the end-host 
software *did*, to a significant degree, get upgraded.

Granted, CES doesn't require the fork-lift upgrade that IPv6 does. 
But still, it assumes that ISPs will choose to add relatively complex 
CES control plane - which implies administrative overheads, which 
implies increased staffing costs - over the tried, tested and simple 
NAT box + reclaiming address space.

Anyway, we can't resolve this argument without data. The market will 
provide that in time.

> But increasing the number of hosts a NAT box can handle from a 
> single IPv4 address has nothing to do with the routing scaling 
> problem, or multihoming, portability, inbound TE or mobility.

I respectfully submit you have considered only the initial part of my 
argument :)

I will of course reread yours to see what of it I have missed.

> Unfortunately it couldn't become even a little popular since it is 
> impractical to use it through the DFZ, or probably with most 
> routers.

I don't buy that. The same thing applied to IPv6 at one stage, indeed 
it was worse with IPv6 for the DFZ couldn't forward IPv6 /at all/.

IP options being slow would be resolved within about 1 life-cycle of 
routers (at least, their line cards) on the DFZ. I don't have 
anything but anecdotal evidence as to what that is, my best guess is 
circa 5 years.

> Its not just slow - it involves such packet loss rates that 
> communication would be impractical.  Even being slow would be 
> enough to ensure no-one wants it.

They found significant problems with about 15% to 21% of the paths 
they tried. So 80% odd of the 210 paths they tried were fine. Plus we 
need further studies to see how peculiar these loss rates were to the 
set of paths they measured.

It's a problem, sure, but it doesn't quite seem as bad as you've 
stated it. We face similarish connectivity problems trying to recycle 
addresses when address ranges have been listed in bogon space, or 
with low address ranges that historically have not been used and 
which have ended up being used privately in places. E.g. what 
proportion of paths have PMTU problems (which would affect CES - I 
have to read your link still).

There isn't any perfect solution, it seems. This is about choosing 
between problems.

> But until such upgrades are done, there's no way anyone can 
> reliably communicate across the IPv4 DFZ with a new kind of 
> protocol, or with IPv4 packets with option headers.

It would take a similar time-scale to start to get IP extensions 
deployed in end-hosts.

> Once we can contemplate such upgrades to DFZ and other routers, then we
> could do a CES architecture (Ivip) without encapsulation:

>  http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00
>
> As you note in the "pjakma said" addition to your page:
>
> http://pjakma.wordpress.com/2010/02/12/making-the-internet-scale-through-nat/
>
> your proposal would also depend on upgrading applications.  I agree 
> with your assessment of this aspect of your proposal "This is the 
> most obviously crack-full part of it all."!

Indeed.

But again, it can be deployed in stages, and each stage can bring 
some immediate benefits, while enabling the next stage. No single 
stage solves all the problems, but after a number of iterations more 
and more problems can be solved.

I'm not saying this is /better/ than map-encap solutions, just saying 
that if for some reason map-encap doesn't gain traction either that 
there is still a possible engineering path to a rewrite-based n-layer 
routing architecture.

Just saying..

regards,
-- 
Paul Jakma	[e-mail]	Key ID: 64A2FF6A
Fortune:
Having the fewest wants, I am nearest to the gods.
 		-- Socrates