OSI: The Internet That Wasn’t (2013) | Hacker News Reader

OSI: The Internet That Wasn’t (2013)

spectrum.ieee.org

75 pointsghshephard47 comments

Eh. The fact that you had to spend around $1,000 to buy the set of manuals required, back when that was perhaps $2,000 in today's dollars, was probably a bigger factor than the article makes it out to be. Standards organizations like ISO and ANSI, at least back then, made their money selling manuals, which just doesn't work for something so ubiquitous in the number of people who have to know details.

Another problem that I read about at the time is that some of the ISO protocols didn't work. The "ISORMites" (http://www.amazon.com/Elements-Networking-Style-Animadversio...) were reported to be contemptuous of the Internet protocols, their origin from the "US Department of Death", etc. ... and didn't have a policy like the IETF's "running code wins" approach.

More generally, per http://www.ietf.org/tao.html "One of the 'founding beliefs' is embodied in an early quote about the IETF from David Clark: 'We reject kings, presidents and voting. We believe in rough consensus and running code'"

OSI's answer to TCP, TP4, was implemented in Windows 2000.

TP4 assumed a reasonably reliable data path, probably an X.25 virtual circuit, underneath. It didn't have all the timing, reordering, retransmit, and congestion control machinery that lets TCP work over bad links.

On the other hand, the OSI crowd had, at the time, more experience with scaling and routing. IP's class A, B and C networks, autonomous system numbers, and Border Gateway Protocol didn't scale well. Routing in the Internet is still something of a hack. Today's routers almost have to have an in-memory table mapping all 4 billion IPv4 addresses to Autonomous System Numbers. If memory wasn't so cheap, we'd be having real problems.

If memory wasn't so cheap, we would have transitioned to IPv6 long ago instead of coping with an ever increasing global routing table.

IANA and the RIRs are stepping away from their requirement that everyone route through their ISP's parent space. They quickly discovered there are a lot of reasons why Provider Independent Address Space (PIAS) is critical to any real business, and that nobody is going to re-number when they change ISPs (not to mention the hassle of having to deal with multi-site environments). The entire concept was a pipe dream.

If they hadn't yielded on PIAS then every enterprise network engineer out there was just going to deploy in RFC 4193 ULA space, say screw you to the IETF and implement RFC 6296 - NPTv6 on their perimeter.

Net-Net - Once IPv6 starts to get traction, we're going to have routing tables of roughly the same size, but they'll just consist of /48s instead of /20s.

Deploying RFC 4193 at least would not pollute the global routing table with lots of short prefixes. Those enterprise networks would pay for that flexibility themselves instead of forcing the cost onto the whole Internet.

Routers have gotten much, much faster, and memory has gotten much, much bigger. And a lot of the Longest Prefix Match stuff is highly optimized/fast switched anyways now.

Hence my inital premise: if memory hadn't gotten so cheap, we would have transitioned into IPv6 already. For all the good Moore's Law brought us, it is also the reason why we seem to be stuck in this NAT world with no end in sight.

The original belief with IPv6 is that End Users would route through their ISPs address space, and the IPv6 made renumbering so easy, that it would be simple for end-users to change providers and renumber.

This turns out not to be the case.

IPv6 will not reduce the size of the routing tables. Anybody with prefixes, and PIAS right now, will likewise get a /48 of IPv6 space and start advertising it into BGP.

If anything the more easily available space may result in bigger routing tables as a result. (Not everyone was able to get a /20 - particularly outside of ARIN space. For example - IPv4 addresses come very dear in places like Dubai.)

And NAT doesn't go away with IPv6. That was another belief that did not survive its first encounter with reality. It's simply called "Network Prefix Translation" now (NAT by another name)

> And NAT doesn't go away with IPv6. That was another belief that did not survive its first encounter with reality.

If it doesn't go away, it will be only because of ISP greed (i.e., charging customers for a larger number of publicly routable addresses). Otherwise, there simply is no reason not to give every customer a /56 or even a /48, given that routers won't be able to route prefixes longer than that anyway.

Fortunately, most ISPs offering native IPv6 so far have turned out not to be that greedy.

It has nothing to do with ISP greed. There is no shortage of IPv6 addresses, and, ISPs have every motivation to encourage their customers to use their IPv6 space.

The reason NAT doesn't go away is that customers don't want to use their ISPs IPv6 space, they want their own provider independent space.

The easiest way to do that, is to address all your devices from RFC 4193 ULA space, and then, on your perimeter, do RFC 6296 Network Prefix Translation to the ISPs IPv6 space.

Then, when you change ISPs, you simply make a single change on your perimeter rather than having to renumber hundreds of internal devices, DNS, configurations, etc...

I understand the argument for enterprise networks. Residential customers have everything to gain from using their IPv6 space, and provider-independence isn't an issue for them.

It's worth noting that NPTv6 is a lot better than NAT, though. For one thing, it operates strictly at the IP level and doesn't muck about with the transport layer. So, for instance, if you want to use a transport other than TCP or UDP, it should be possible - at least in principle - even if you are NPTing to and from ULA space. That's something you haven't been effectively able to do on the Internet for the past 20 years.

Totally agree with you across the board.

TP4, where the 4 stands for class 4, certainly had reordering, retransmission and congestion controll.

Other classes you could chose had varying degree of error detection and recovery. It also had a connectionless mode.

"You could choose". Therein lies the problem. TCP is automatic, which is a big win. You don't have to set parameters for TCP depending on the data path.

On the flip side, TCP forces you into a single ordered stream and head-of-line blocking. If you need a reliable yet unordered message stream, you have to reinvent the wheel on top of UDP.

Or use an internal work queue instead of buffering in the kernel and/or network; or use multiple TCP connections; or use a single SCTP (or SCTP/UDP) connection.

Any of these is less work and less bug-prone than "reinventing the wheel on top of UDP".

SCTP would be the ideal solution, but it's essentially broken on the wide Internet since virtually no NAT boxes understand it.

Using a large number of TCP connections breaks some of the assumptions behind TCP congestion control; this is one of the reasons why the SPDY/HTTP2 guys decided to layer a multi-stream protocol on top of a single TCP connection - and it still falls prey to head-of-line blocking.

Not sure what you mean by using an internal work queue - short of running a custom TCP/IP stack in kernel space or using some non-standard socket API, there's no way to work around TCP's ordered delivery.

Given these constraints, I can understand why designing a transport protocol on top of UDP might be reasonable. There probably is no need to roll your own, though - just use SCTP over UDP [1]. (Edit: I only noticed you did mention SCTP/UDP after I wrote my reply, sorry!)

[1] https://tools.ietf.org/html/rfc6951

SCTP would be the ideal solution, but it's essentially broken on the wide Internet since virtually no NAT boxes understand it.

Hence my suggestion of SCTP over UDP.

Using a large number of TCP connections breaks some of the assumptions behind TCP congestion control

Which assumptions? Using multiple connections is pretty standard in the enterprise storage world.

My bad, I missed that you were referring to lost packets blocking future packets (as opposed to slow-to-process work units blocking future work units). You're right that this is very much a problem with a single TCP stream. (Multiple TCP streams help with this.)

> Which assumptions? Using multiple connections is pretty standard in the enterprise storage world.

TCP congestion control is designed such that, under steady-state conditions, each TCP stream traversing a physical link gets an equal share of the available bandwidth. When an application that uses multiple TCP connections competes with another that uses a single one over the same link, the resulting bandwidth distribution is unfair to the latter. (Edit: there's also another problem, related to bufferbloat, but that one is a lot trickier to explain).

Of course, this may not be a problem when used on an internal network (which I assume is the scenario you are referring to). On the public Internet, however, HTTP is becoming increasingly disruptive to other kinds of traffic due to the increasing number of parallel connections used by web browsers.

Ah yes. I'd say that's more a problem with TCP in general than in using multiple connections. The assumption that "1 TCP connection == 1 share of bandwidth" is at best a useful first approximation. I don't know that N TCP streams eating N times their "fair share" is really any different a problem than some-important-interactive-application being given equal bandwidth with some-irrelevant-background-download. (Though it might be a worse problem.)

I'd love to live to see the day that something actually better than TCP (that addresses these and other issues) dethrones it, but given how long IPv6 took to gain traction, I wouldn't be surprised if it didn't happen in my lifetime.

I think it's a wonderful thing that the TCP/IP model (as originally envisioned) does not preclude endpoints from implementing their own transport protocols on top of IP, irrespective of what the rest of the network uses.

Unfortunately, reality has conspired against this possibility in two ways: NAT boxes, and the fact that transport protocols are implemented in the kernel on most operating systems (hence, an application cannot use its own transport protocol easily).

The deployment of IPv6 is a real chance to, at least, fix the first of these problems. Let's hope it does.

Why is that a problem ?

You specify a parameter when you start, telling which variant to use. It's really not that different sitting down before you start coding a program and deciding whether to use TCP, UDP, DCCP or similar.

Because you don't know whether the end user running the program has a gigabit server-quality pipe or a flaky mobile connection.

Sure, but how is that different from the TCP/IP world ? You select the protocol based on what your application needs.

Re: "Today's routers almost have to have an in-memory table mapping all 4 billion IPv4 addresses to Autonomous System Numbers."

Full BGP Table is around 500,000 entries, so you are off by several orders of magnitude there.

TCP is in fact pretty shitty over "bad links". Standard TCP congestion control algorithms are designed to assume that packet loss indicates congestion; not link degradation. This results in actual "bad links" tricking TCP into thinking there's congestion... so it backs off (which doesn't fix the problem); backs off some more (which still doesn't fix the problem); etc.; resulting in terrible throughput in the face of packet loss.

There are alternative congestion control algorithms that mitigate this somewhat; but the best solution (which AFAIK there is no widely-used standard for) is to use forward-error-correction. But since the Internet, for the most part, doesn't actually have "bad links", this is not generally necessary.

We're actually integrating an OSI-based network stack into our avionics datalink product at work right now.

The next generation of digital air traffic control between aircraft and the ground towers is an OSI stack. Proprietary application in layer 7 and avionics-specific layers 2 and 1, but everything in between is bog-standard OSI (TP4 & IDRP, IS-IS & CLNP, 8208).

Interesting protocol suite, and it will be keeping aircraft going the right direction for the next 25+ years.

Hilarious - a bit further down I mentioned how Hughes Canada Systems division had a team hard at work on that project in 1994/1995. I thought it had been scrapped - apparently not.

That is interesting I did in the summer go over to hanslope park (a technical out station for the Foreign office) for an interview and one of the technologies mentioned was OSI

To what end are non TCP/IP/Ethernet tools used?

Ah, reading about some of the early packet-switch debates reminds me of the time my dad called me up and said "I crossed off one of my bucket list items: Vint Cerf called me a 'circuit-switched bigot'"

I was working at Hughes Canada Systems Division in 1994/1995, and they had an entire division dedicated to developing a next generation Air Traffic Control system - it had been mandated about 4-5 years earlier, that this project had to be written using OSI protocol stack. They had been struggling for about 4 years, and still hadn't managed to get the protocol stack on their operating systems interoperating properly. There were dozens of people working on this project too. Total Fiasco. They ended up scrapping most of their work.

Interesting when I worked for BT I worked on OSI interconnects for the UK its not that hard once you grok asn.1 to workout what is going on.

My boss once watched a trace I was running stoped it and pointed to a particular dword and said that's a Sprint ADMD you can tell as they don't to that part of the had shake properly

"OSI has been forgotten by all but a handful of veterans of the Internet-OSI standards wars."

Hardly forgotten, I learned about OSI at the same time I studied TCP/IP back in college. And I'm hardly a veteran, since I graduated in '09.

OSI model, or OSI protocols? Everyone knows the OSI model - but outside of Avionics, you won't find that many people who know the protocol details beyond knowing they exist. And that TP4 is a thing.

You can tell people who relay know OSI by asking them which level MIDI is and critique CISCO'S asertation that its a layer 5

I remember working with that ISO, OSI, C-MIP/C-MIS, ASN.1, *registration hierarchy, etc. stuff. Worst interval in my career.

Finally I began to understand: The standards meetings were in Paris, Rome, London, Munich, ...!

The OSI was working to the one PTT per country model your government controlled/owned phone company.

Oddly enough some OSI protocols live on at the foundation of IP networks in the form of CLNS & IS-IS.

IS-IS is a internal routing protocol sometimes used instead of OSPF.

ASN.1 managed to infest some internet protocols like SNMP and SSL certificates. It's one of those solutions to a problem that shows its committee heritage and ends up being ludicrously complicated to implement because of all the edge cases. Lots of software has been compromised through flawed ASN.1 and X.509 decoders.

I'm old enough to remember back in the day when our customer (the biggest possible customer) allowed us to implement early versions using SMTP, but we had to design and plan to switch to X.400 since that was going to be the real standard. It was a strange era. We had things that worked, but everyone knew that the whole industry was going to switch to something completely different that solved all the same problems for a reason no one in the trenches really understood. Except the dates for switching kept moving and the software for the new way never really quite arrived in working order or with enough features to move.

LDAP as well. Tim Howes once told me if he had to do it all over again, he would have not used ASN.1, would have done a simple text protocol.

There is a quite interesting book where the author (John Day) shares an inside view about the OSI committees back in the 70's and 80's, and its endless discussions: "Patterns in Network Architecture: A Return to Fundamentals" [1]

[1] http://www.amazon.com/Patterns-Network-Architecture-Fundamen...

One advantage that circuit routing has over stateless routing is that of largely painless muxing / demuxing; and hence almost no buffer bloat. SONET can mux multiple channels without the need for a single buffer. Obviously the downside is the lack of flexibility, interdependency and hence increased fragility.

The 7 layer model lives on. It remains a good reference point for discussing networking.

Seven layers are a procrustean bed, at best. The model might be useful as a starting point, but really all it means is "good design uses layers." When you start discussing actual networking implementations, trying to fit a what you're doing into "where exactly this fits in the ISO model, and it's wrong if it doesn't fit" is a bad way to think.

Devices that mix layers can do pretty interesting work, too (e.g., inspection of packets for security purposes, smart buffering for controlling host load, etc.). So the "every layer only talks to the layers immediately above and below" is kind of suspect, at least as dogma. There are probably other examples in very high bandwidth systems where you want to skip layers for performance reasons.

Although I'm not really sympathetic to the OSI model, it did get some things right. For instance, witness how almost every TCP/IP protocol has to roll out its own session layer for authentication purposes...

Indeed, All People Seem To Need Data Processing.

Reply on news.ycombinator.com