NAT444 or ?

And these 'perceived' routing issues won't be noticed nor are they important to CDN's?

I know what my job is, but that may not matter to the CDN's. Reading this thread, I wanted to mention another problem that I feel has an effect on this issue.

Lyle

When you need to pile up this amount of trickery to make something
work, it's probably high time for letting the thing die :slight_smile:

Warm regards

Carlos

You could say the same thing about NAT44 from the very start!

IPv4 just needs to die sooner rather than later. For now though, there is a good many years of trickery left :wink:

When you need to pile up this amount of trickery to make something
work, it's probably high time for letting the thing die :slight_smile:

You could say the same thing about NAT44 from the very start!

many of us did

randy

And these 'perceived' routing issues won't be noticed nor are they
important to CDN's?
I know what my job is, but that may not matter to the CDN's. Reading
this thread, I wanted to mention another problem that I feel has an
effect on this issue.
Lyle

A very interesting point. In order to save precious CGN resources,
it would not be surprising to see some ISPs asking CDNs to provide
a private/non-routed behind-CGN leg for local CDN nodes.

For this to work, the CGN users would probably have a different
set of DNS servers (arguably also with a private/non-routed
leg) or some other way to differentiate these CGN clients. Lots
of fun in the future debugging that.

/JF

Especially once you have 10 or 15 CDNs doing this, all of which have different
rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar wants Y
and specifically NOT-X..." :wink:

And then Cogent will get into another peering spat and.... :slight_smile:

> A very interesting point. In order to save precious CGN resources,
> it would not be surprising to see some ISPs asking CDNs to provide
> a private/non-routed behind-CGN leg for local CDN nodes.
>

The actual problem here is that everyone assumes it'll be donkey's years
before every last web server in the world is on IPv6.

If you're a CDN, though, you can solve this problem for your own network
right now by deploying IPv6! Akamai says that you need 650 AS to cover
90% of Internet traffic. I propose that effort getting content networks
to go dual stack is better used than effort used to work around NAT444.

Further, if making your hosting network IPv6 is hard, the answer is
surely to give the job to a CDN operator with v6 clue. I actually rather
think CDNs are an important way of getting content onto the IPv6
Internet.

In my view CDNing (and its sister, application acceleration) is so
important to delivering the heavy video and complex web apps that
dominate the modern Internet that this should be a killer.

Still, breaking the BBC, Hulu, Level(3), Akamai, Limelight, and Google's
video services will probably reduce your transit and backhaul bills
significantly. Can't say it'll help with customer retention.

> For this to work, the CGN users would probably have a different
> set of DNS servers (arguably also with a private/non-routed
> leg) or some other way to differentiate these CGN clients. Lots
> of fun in the future debugging that.

Especially once you have 10 or 15 CDNs doing this, all of which have

different

rules of engagement. "Akamai requires us to do X, Hulu wants Y, Foobar

wants Y

I can predict the response from the teen dens of the world!
What does CGN mean .. Can't Get Nothing!

Christian

This is a good strategy for payload-type content from unitary sources which lends itself to caching/redistribution; however, Web applications, things which link to/incorporate lots of content, etc. under the control of other organization, and 'active content' are another story, unfortunately.

exactly. don't plan to deploy what breaks things for the user edge.

there are two issues here

1/ what ISPs do that might break things at the edge

2/ what edge stuff is doing that will break things at the other end edge of a connection

It seems a bit odd that ISPs would actively plot to do 1/ whilst they could be making hard cash helping people at the edge avoid 2/

Odd because it adds a 3/ element which is stuff at the edge which will break stuff in the network. Do (some) operators see more money in a 1/2/3/ world?

Christian

In spending millions of hard-earned $$ toward vendors, NTT
might not be alone in this realization.

However, in acknowledging that it's an endless blackhole
where you won't see money necessarily coming back relative
to the amount being put in, they may just part of a small
handful of folk, sadly.

GPRS/3G/EDGE has made many a mobile provider especially
notorious.

Mark.

You'll be hard-pressed to NOT find a vendor willing to sell
you the "right" solution for the "easy way out" :-).

Mark.

All this problematic state should be broken up into smaller instantiations and distributed as close to the access edge (RAN, wireline, etc.) as possible in order to a) reduce the amount of state concentrated in a single device and b) to minimize the impact footprint when aberrant traffic inevitably fills up the state tables and said devices choke.

I do expect some of these workarounds to be vendor and/or
platform specific, as more units are deployed and the
industry simply can't keep up with the various topologies
and customer elasticities ISP's have to maintain.

We're already seeing evidence of this as we discuss NAT64
options with vendors, particularly in the area of scale and
customer experience perceptions.

Mark.

Certainly a consideration when an ISP considers scaling
avenues for LSN's.

The issue is that there are simply too many variables, not
least of which is what business the ISP is in.

The mobile types are a lot more problematic because they
tend to centralize IP intelligence, and keep the RAN's
pretty simple (although the RAN's are now becoming more
intelligent thanks to your garden-variety IP vendors getting
into the game). What we've seen also, with some mobile
carriers, is that if you ask them to consider distributed IP
architectures, they/you quickly realize that IP routing
isn't really their core business or skill.

For your typical ISP, size notwithstanding, it will
invariably come down to how much money and effort they're
willing to spend or save with either centralized or
distributed architectures. Mind you, they're also battling
with other problems re: centralized or distributed
solutions, e.g., broadband aggregation, the ratio of
access:aggregation intelligence, access topology lay-outs,
e.t.c. And somehow, in all this mix, LSN's must work, be
they small units thrown around the network, or one or two
large monsters sitting somewhere in the core.

We've certainly considered both options very thoroughly.

Mark.

Concur. Many/most have essentially become 'accidental ISPs' through the rise in popularity of iDevices, and some at least are beginning to realize this and to staff and re-engineer accordingly. It takes time, though.

I certainly hope so - let's hope ISP's go out and deploy v6
beyond the core, as content providers deploy v6 for their
content, rather have a stand-off between both ends of fence
on who should move first.

Mark.

> GPRS/3G/EDGE has made many a mobile provider especially notorious.

All this problematic state should be broken up into smaller instantiations

and distributed as close to the access edge (RAN, wireline, etc.) as
possible in order to a) reduce the amount of state concentrated in a single
device and b) to minimize the impact footprint when aberrant traffic
inevitably fills up the state tables and said devices choke.

Ip mobility via gtp or mobile ip generally does not work when you nat at the
'edge'. If you don't want your ip address to change every time you change
cell sites, the nat has to be centralized.

Cb

Indeed, networks with some kind of anchor point (even xDSL networks with a LNS that terminates PPP sessions) really lend themselves to a big fat NAT box simply because there is a single point where all the connections appear anyway so why not have a single box doing NAT/DPI/etc as well?

I'd agree that, usually, distributed is better but these are not distributed networks, there is a single point (or a few large single points) of contact.

The point is that these aggregations of state are quite vulnerable, and therefore they should be as distributed as is practicable.