[fleitz]

I wonder if it's just my naiveté however it sounds like this is more likely to produce an X400 than an SMTP.

The vision seems pretty grand and all encompassing wholesale replacement of the entire networking stack, rather than small and easy to implement iterative approach. It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed.

Yes you could certainly improve TCP/IP but is it going to be 10X better?

[tgflynn]

Yes you could certainly improve TCP/IP but is it going to be 10X better?

Doubtful, and I think you'd really need to see that level of improvement to have any hope of replacing TCP/IP.

[vidarh]

If the "CDN" part of it proves to be sufficiently useful, this could be deploy layered on top of IP, or wrapped in UDP or even a TCP connection. Capable clients would then "just" need a means of discovering the nearest capable router that'll let it tunnel. And while IPv6 also can easily be tunnelled, the benefits of doing so are much smaller: IPv6 doesn't give you that much if your host still has an IPv4 address too.

But if this system lets your ISP drop in a new router or two that suddenly can know just by looking at packet headers that it is allowed to returned data from a local cache instead of passing the data on to the server and waiting for a response, then it could have sufficient benefits as soon as a couple of large bandwidth hogs starts supporting it. E.g. if Netflix or Youtube made use of it

That potentially a pretty different proposition.

Then again, the question is whether they need to re-architect the lower level protocols to do this, instead of defining a protocol on top of TCP or UDP that services that are actually likely to benefit can implement.

[signa11]

> It seems that the biggest thing the TCP/IP folks got 'wrong' was the 32 bit address space, and even that small change is taking forever to be deployed.

i guess you are alluding to ipv6 here. and imho, ipv6 provides quite a large number of changes from vanilla ipv4. it is not just a much larger address space...

[jacquesm]

That is absolutely true but the main driver behind the replacement is the increased address space. None of the other changes seems to have been a driver at all.

So as far as the consumers go IPv4 is 'good enough' and if and when IPv6 will finally take over it will remain the de-facto world wide networking protocol used to power the internet for a very very long time.

Cisco attempting to drive a wedge between IPv4 and IPv6 in the midst of this (very very slow) transition seems like a very strange move to me, almost certainly bound to fail or in the end not replacing IPv4/IPv6 but maybe ending up as a transport layer underneath it (killing most of the advantages it would offer in the process).

And that's besides trying to replace TCP which would require re-writing/adapting of virtually every computer program active on the net today.

[tgflynn]

I don't know that they're trying to drive a wedge between IPv4 and IPv6. I would think that even NDN's supporters see it as a very long-term, post-IPv6 development.

I am surprised however to see Cisco supporting this. It's one thing to have some academic networking specialists writing papers about NDN, but for a major corporation to devote resources to a 10+ year development project with an unproven architectural basis strikes me as odd.

[takeda]

Cisco was involved with it since at least of 2012. They actually wrote software in the protocol as well. It was for video conference if I recall correctly.

[drvdevd]

The "forever to be deployed" part is a crucial observation. Perhaps research into how to get the Internet community to adopt new protocols is more relevant than the protocols themselves. In other words: how can we speed up the adoption of IPv6?

[mmaunder]

But it's a great way to sell more stuff.

[walshemj]

Scraping Ipv6 and starting again would be a better solution and this was trivially obvious back in the mid 90's that ip/v6 was a POS