A New Way to look at Networking

[ixf05u]

Really great talk - he is an inspiration and a genius

[ixf05u]

@ixf05u NB I'm not one of those douches who makes an off the cuff witty joke disregarding the people who disliked the video. However I'm confused about who would dislike this? Why would you even be watching it in the first place?

[CirkusBolgen]

@ixf05u I suspect some people use disliking to eliminate videos they don't want suggested to them by YouTube.

[flowewritharoma]

I have had a great impression on this vid.

[evanplaice]

And Last. Re-write the OSI model. Nobody uses it because it doesn't accurately reflect the networking stack.

[TheYouSphere]

@evanplaice That's not why OSI model is not used. In the 90s TCP/IP took over because the standardization process for TCP/IP was much faster than for OSI protocols. ISO simply took too long in defining OSI and most of the people did not appreciate the length of time it took so TCP/IP took over.

[evanplaice]

(cont) Fourth apply checksums only to the layer that they're contained. The TCP checksum breaks this rule. Every layer should be completely isolated of knowledge from each other layer. Fifth, quit putting checksums on everything; they're a waste of cycles and computationally expensive on smaller devices (like embedded platforms). If they were intended to be used for security, well, one's sum isn't exactly rocket science to apply on an injection.

[evanplaice]

(cont) Second, add version numbers to protocols. A half byte should me more than enough and it'll go a very long way to making life easier for people who write packet parsers. Third, make networking components big endian. It's staggering to consider how many man hours are wasted just addressing this dumb issue (not to mention the performance degradation to convert the data to the right format).

[videowatcherforsale]

@evanplaice - For fuck sake no one cares what you have to say! No need to type over 20 comments...

[evanplaice]

While I disagree with a lot of the points the speaker made it was definitely interesting talk. While I strongly wish the people writing the network specs would focus on improvements that will clear up a lot of issues with the present infrastructure. First and foremost, don't create specifications using RFCs. There are documentation repositories and community driven discussion tools available now. Use them.

[evanplaice]

(cont) To create a repository like Google's (which contain mostly text) into one that contains images/videos of the web it would require a physical structure many magnitudes larger than what Google has. YouTube has a massively expensive infrastructure mostly because it takes a lot of resources to store and serve large amounts of video content.

[evanplaice]

(cont) To create a repository like Google's (which contain mostly text) into one that contains images/videos of the web it would require a physical structure many magnitudes larger than what Google has.

[evanplaice]

Hole 12: The resources needed to create gigantic up-do-date web repositories of date are unrealistic.

He glosses over how Google has solved the issue and URLs aren't really needed anymore. Google accomplishes >1/2 second searches with a network of 200,000 - 1,000,000 servers worldwide (the actual figure isn't shared with the public). And that's just to store some text info about the content, some metadata, and URLs.

[evanplaice]

Hole 11: Local broadcasting isn't only possible now, it always has been.

Not only can you broadcast information across a local network without the overhead of an IP layer, it's very easy to do. Just assign the MAC address to FF:FF:FF:FF:FF:FF. In fact, that's exactly how that little Wake-On-Lan feature works. The issue is, developers aren't given the ability (on windows) because security experts said that developers shouldn't have access below the TCP layer (due to the ability to IP spoof).

[evanplaice]

(cont) That may not be a lot but consider the wasted computation time wasted to break apart and reassemble that 100mb file into 69905 chunks. When the internet was created, KBs of data was considered a lot. That's not the case anymore. If IP is being updated to address the address space issue, TCP should also be updated to address the packet size issue.

[evanplaice]

(cont) If you really want to improve the quality for transferring different types of data, give us better metric to adjust packet sizes. For instance, if I'm transferring a movie, why does it make sense to fragment it down into 1.5kb chunks. With every packet containing (ethernet frame:24 bytes, IP:20 bytes, TCP:20 bytes) 64 bytes of metadata (if no options are specified in the IP or TCP layers). So, for a 100 mb movie approx 68.2KB needs to be added for metadata alone.

[evanplaice]

(cont) Not to mention the vast number of different formats (and differences across different versions of those formats). The Networking layer (TCP) is already bloated enough as is. I know, I've implemented a full-featured TCP parser before. Lets just say, the term 'TCP Options' makes me cringe involuntarily.

[evanplaice]

Hole 10: Bits are not just bits, they're a way of expressing complex information

The networking people couldn't even get the order of bits part right. They choose little endian where the majority of operating systems today arrange data in memory in bit endian format. If they made that one little fundamental change they could same millions of hours of processing time wasted everyday worldwide.

[evanplaice]

(cont) This issue behind this is, if such a bill passes, they will be given the full power to directly manipulate their market to maintain their monopoly over transmitting high quality video content. If that isn't a conflict of interest, I don't know what is.

[evanplaice]

Hole 9: QOS based on the type of data being sent across is a really bad idea

If the service providers are given the means to distinguish the type of data being sent across, they will abuse that privilege to discriminate against their competitors. Back before Netflix/Hulu gained market saturation Cable companies implemented some questionable application firewalls (that they dubbed traffic shaping) that would spy on the data being sent across and interfere with packets that looked like a torrent.

[evanplaice]

Hole 8: Data already has a name not a location

The combination of a DNS (Domain Name System) name and CDN (Content Delivery Network) comprising of hosts placed around the globe. Don't believe me, look up how Google serves up data to its users for Google Maps. Hint, there's at least a dozen DNS names for the image tiles alone (which can each point to multiple servers). In fact, almost all (professional) websites serve content from multiple sources.

[evanplaice]

Hole 7: Hashes don't make a file safe

Recalculating manipulating the content isn't a whole lot more difficult to do than it is to dynamically change the data using an application firewall. The fact is, the internet is inherently sent because you're passing your data through many intermediate hosts before it reaches its destination. Unless you encrypt the data itself, it will be subject to being changed/viewed along the way.

[evanplaice]

Hole 6: The concept of naming data is already used in caching

On a website, if you want to ensure freshness of data but still allow caching, you use a webserver that adds a hash to the filename of a file containing static content. When the file is changed the webserver recalculates the hash and renames it before transmitting.

Take a look at mod_pagespeed to see what I mean. This is a application layer issue. Not a networking layer issue.

[evanplaice]

Hole 5: Contrary to his statements, most applications contain very little networking plumbing

That was the whole point of the DNS model. You have one named source (which can actually be one name pointing to many sources in the case of Content Delivery Networks) that points to a machine containing the content. The file transfer version is called a DHT (distributed hash table) and is used for bittorrents to share sources of the data without the need of a central host.

[evanplaice]

Hole 4: Broadcasting networks create Monopolies

The internet is a pull model. You grab the data you want, when you want it, on demand. We already have a push model that relies on broadcasting, It's called Television. The issue with broadcasting is, the number of pipes that allow data to be sent across is limited. therefore, the company with the most resources and political power will control those pipes. If anything changing the internet to a broadcast model is a step back in progress.

[evanplaice]

Hole 3:

>99% of data being sent across is messaging related to email/websites? I strongly disagree. The majority of content being sent across is content (either audio/video/images). To optimize those transfers the MTU size of TCP transfers really needs to be increased to cut down on the number of packets being sent (Ie, send more payload data and less packet header metadata in a connection)

[evanplaice]

Hole 2: This implementation doesn't consider changing content

The current implementations of caching (when implemented properly) do a very good job of cutting the number transmissions needed to deliver content. If NBC doesn't understand the deeper aspects of caching and, more specifically, content delivery networks, they should fire all their network engineers and start over.

[evanplaice]

Hole 1: Hashing doesn't solve the problem, it makes it worse

What host is charged with generating the hash how will it be stored on routers and where will the canonical data store be placed that contains the actual copy of the data. You still need a home for the content whether that comprises of one or many endpoints. Many routers crash when ARP tables grow to sufficient size to saturate the memory, a table containing host/content would be many magnitudes larger.

[neuraxon77]

I created a Content-centric Networking Google Group if anyone is interested in discussing this.

[rrrchk]

truly wonderful indeed

[routenearzero]

this is borring! how wants to know that

[Captnuendo]

You are indeed a stupid individual.

[thefutureanotherway]

If you add bit torrent tracker functionality to web servers and bit torrent client functionality to web browsers the problem would be solved?

[b001ean]

"Data has got a name, not location", "The data doesn't live anywhere, its just out there". I find this very hard to understand... If data doesn't live somewhere how do you control/manage it? Besides, it has to exist somewhere!

Anybody able to clarify this point?

[Alex756e]

As far as I could understand in data dissemination we neither need to control nor manage it. Think of a newspaper, after it's printed out and sold all over the country we can't tell where it's located because it's everywhere. You can ask a friend to lend you a copy of todays news and you end up trusting the copy because it looks like todays news, i.e. the data has a name. Well in this case the appearance has the function of a (cryptographic) name.

[zenban]

yes, except in this case the newspaper is the size of a dust, it sits in your pocket, you don't need to do a thing to transfer it and the more you give away, the more you get back!

[amitgurkha]

Good one...Great overview.

[5jgibbs8]

Great video, but audio is not synced right with movie.

[shepting]

This was wonderful.

[gmvsea]

This is awesome!!! I learned more meaningful information about networking from this lecture than reading dozens of networking books.

Please get Van Jacobson to do a more presentations on networking. His presentations are lucid, entertaining and highly understandable.