Live data from Hacker News

UCLA, Cisco and more join forces to replace TCP/IP

networkworld.com

51–60 of 86 posts

Re: UCLA, Cisco and more join forces to replace TCP/IP

#51
post #14

One of the earliest attempts to replace the the TCP/IP model (or rather the lower layers of the ISO-OSI model) was the Asynchronous Transfer Mode (ATM). Despite being a well-intentioned idea, it failed to see real world usage because of the complexity. Along the way many developments happened. People learned to live and work with IPv4. Even IPv6 hasn't picked up despite solving some important problems. So when it com…

yep if having a better networking stack was going to work we would be using OSI, X.400 and X.500 now and not TCP/IP

Still id have probably still be working for a Telco and have a really cool mail address though cn=uk cn="maurice"

Re: UCLA, Cisco and more join forces to replace TCP/IP

#52
post #5

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 depl…

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

Re: UCLA, Cisco and more join forces to replace TCP/IP

#53
post #49

Nothing except efficiency is preventing us from using names as parts of network/subnet hierarchy instead of numbers, e.g. : steve.home.town.country instead of 192.168.5.6 (or the same thing on IPv6), and even efficiency could be improved by the smart use of hashing... BUT! The major problem I see here is that there simply are more numbers than words . In practice, especially at large companies, it will certainly with…

That's not what NDN is about.

NDN assigns names (or addresses) to data contents, not physical machines/interfaces like IP does. So it's conceptually quite different from the way IP routing works.

The issue you mention is already solved by DNS.

This looks like a solution in search of a problem.

NDN attempts to make content distribution more efficient through caching. Whether solving that problem justifies rewriting the entire network stack is highly questionable.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#54
post #44

Earlier quoted context omitted.

Since most servers were found to be vulverable to crazy simple attacks like that: http://en.wikipedia.org/wiki/Heartbleed or the Apple one: http://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto... (and tons of others besides, plus crappy code in the most prevalent implementations used).

And when someone implements new code dealing with security, such bugs are not possible ?

He's going to write it, so it'll be better than everything in the past and unicorns will fly by when you use it.

Hypothetical code is always better than the unpleasant kind we actually write…

Re: UCLA, Cisco and more join forces to replace TCP/IP

#55
post #21

People are trying for almost 15 years to replace IPv4. That's almost impossible, 96% of the traffic worldwide is still IPv4. This project is dead on arrival.

read other poster(s) above... IPv6 is on the uptick, especially since IPv4 is more or less out of space.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#56
post #25
post #14

One of the earliest attempts to replace the the TCP/IP model (or rather the lower layers of the ISO-OSI model) was the Asynchronous Transfer Mode (ATM). Despite being a well-intentioned idea, it failed to see real world usage because of the complexity. Along the way many developments happened. People learned to live and work with IPv4. Even IPv6 hasn't picked up despite solving some important problems. So when it com…

"Even IPv6 hasn't picked up" - this needs correction. http://6lab.cisco.com/stats/ https://www.google.com/intl/en/ipv6/statistics.html#tab=per-... http://www.worldipv6launch.org/measurements/ You can notice that 9% of the internet users in the US are IPv6-enabled. Germany is over 11%. Belgium is almost 30% (of course due to smaller population it's less in absolute host count). How many IPv6 users this is in millions,…

Wait. Germany's over 11% - I'm probably counted as one of them.

My anecdote: I'm getting a DS-Lite connection here, that's forced on new customers for this (big) ISP. For month the (mandatory) hardware froze whenever the prefix changed or was reannounced. Basically a (silent) dead connection every 2-3 days, for a looong time. Known problem, nothing that can be done about. But .. that's the past and solved.

Currently? I cannot reach ipv6 addresses. Read that again: DS-Lite, cannot reach any ipv6 addresses while my ipv4 traffic (which .. is tunneled) works fine. I tested with quite some sites, mostly with ipv6.google.com.

Customer support says "They're out of capacity" and want to give me a normal/default ipv4 connection again, they claim that they won't even look into this problem at this point. "Won't Fix", basically.

So I do wonder what these 11% mean and if I'm really just an outlier - or if more people like me exist and maybe don't even KNOW that they are supposed to be able to use ipv6 and cannot?

Re: UCLA, Cisco and more join forces to replace TCP/IP

#57
post #5

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 depl…

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.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#59
post #29

I hope keeping it all patent free / disarmament patent style is a requirement for participation.

I note that patents/"Intellectual Property" wasn't mentioned in the article at all. I suspect, based on the participants mostly being corporations, that the whole thing will be covered by patents.

I think TCP/IP as non-patented, slipped by the major corporations. A protocol anyone can implement, and where the "client" and "server" are pretty hard to tell apart, is disadvantageous to market encumbents, and to surveillance agencies. For instance, nobody can charge fees for implementing TCP/IP. Nobody can license content servers. Nobody can accurately attribute a packet to a legally-responsible entity ("one neck to wring").

The protocol to replace TCP/IP will be patent encumbered, it will make a complete distinction between "client" and "server", it will be centrally routed, it will be subject to surveillance, and servers will be licensed, and costly. If NDN doesn't do some or all of these things, it's already dead.

Re: UCLA, Cisco and more join forces to replace TCP/IP

#60
Whatever Cisco plans to do, I won't trust it not to have a back door. After all Cisco is the author of the IETF protocol for "lawful intercept" in routers, and if I'm not mistaken they also have a pretty high placed co-chair at IETF.

http://www.cisco.com/c/en/us/tech/security-vpn/lawful-interc...

https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/Bl...

Post reply on HN