or - what I saw at IETF'43, December 1998
Harald Tveit Alvestrand
Harald.Alvestrand@MaXware.no
who went there as local host and IAB member
You may also want to look at notes from other people; I don't have URLs for any yet.
If you want a long, calm and uneventful life, one thing you don't want to do is to host an IETF.
On the other hand, if you can manage to find a team of people eager, willing and competent to do the arrangements, wiring, troubleshooting and general gofering needed to make an IETF a success, so that you can spend the week smiling and fielding the occasional query, it isn't so bad after all.
The requirements for hosting an IETF meeting are roughly:
If you can get all of the above, you're doing fine.
Until, that is, the temperature hits 25 degrees centigrade and the airconditioning turns off, you discover that you don't have a night guard to watch the PCs, or you discover something else breaking. That's life.
But that isn't why you are reading this report. If you've already hosted an IETF, you know what it's like. And if you haven't - you don't know what it's like.
It's been quite a few years. Some people think that IPv6 will never happen.
But the problem it was designed to solve is still there: The Internet is running out of
address space.
Slowly, for sure, and the spread of NAT boxes (see other section) has been a tremendous
help in slowing the trend, but still - there are now more boxes connected to the Internet
than the IPv4 addressing infrastructure can easily support if they all were to have unique
addresses.
IPv6 offers a way around that - 128 bits of address space, rather than IPv4's 32. And easier renumbering, and autoconfiguration of addresses. And it's simpler.
One by one, the milestones get passed. At this IETF, we heard that the first "production" address prefixes were due to be allocated; no more "experimental" labelling. People have claimed that this was an important milestone before people could start selling IPv6 service commercially.
But still things are happening to rather basic parts of the infrastructure; the DNS people have just gotten around to discussing (again) how the address of an IPv6 node should be represented in the DNS (what used to be called an "AAAA" record). It looks like the new proposal is workable, but it'll need new code in systems to support it.
And the interworking between systems using IPv4 and IPv6 is still an open game; there
are more proposals for ways to attack the problem than there are people involved.
The nice thing is that most of (all?) the solutions don't need Grand Deployment Plans; any
site can use the tool it finds best for its situation. That's a Good Thing.
There's always been a theory in the Internet that it's possible to make sensible ways to send something once, and have several places get it, cheaper than sending it once per recipient.
The economies aren't big if you are only 3 people, but think of a situation like the World Cup finals, and you might get a few more people involved.
There are two problems here:
With video and audio, the last point is "rather simple": just send - if some recipients miss a few packets, no big deal. The other problem has given network engineers nightmares for years (especially the part about "who pays for the work of keeping track - CEOs tend to ask that sort of things), but is close to being solved - at least for the commercially interesting case of one sender and a couple of million listeners.
The other problem is harder - at least if you insist that the cost to the sender & the network should be less than that of maintaining 1 TCP connection to each. We know how to solve this for 10 or 100 recipients, at reasonable cost; we don't know how to solve it for a million.
There's been an Internet research task force Reliable Multicast Group working on this for a while, after RFC 2357 laid down the criteria for how one should evaluate such things; the results are starting to become available, and are encouraging enough that the Transport area has started a Reliable Multicast Transport (rmt) working group, in order to decide how to start work on defining such protocols.
As the focus of the Internet has shifted from "how do we get this to work" to "how do we get paid for this", the interest in Quality of Service, or "I pay more, therefore I should get more", has grown enormously.
The main components in this effort are currently:
The POLICY wg is trying out the problem of representing a policy. They've chosen a hard way: Taking an existing model (CIM) from an outside forum (DMTF) and attempting to shoehorn it into an existing protocol (LDAP) while hyping the name of this effort (Directory Enabled Networking).
All the while saying that they can't really fill out the details about what the policy they're representing actually should be capable of expressing, because that woud poach on areas that should belong to companies. Go figure..... I'm not happy, and I don't expect to be when the final (?) result rolls either.
I think this effort will take a lot of time to get right.
But RSVP's been out for a while, DiffServ is mostly done, RAP has got its first iteration on the table .... as long as we don't actually want to manage the things in a standard way, it seems that we have got things to work on.
And of course the vendors aren't waiting for the standard; they're deploying their own stuff, "whatever works", and will conform to the standards when they come along.
This worries me a bit.
LDAP is king.
But the world looks different than it used to; LDAP is being used for:
Long ago in a galaxy far away (about 1988), we thought there might be a place in the world for a global distributed information service called "The Directory". This vision, unlike the vision of the global namespace named "DNS" and the global address space called "IP (version 4)" (now significantly frayed), has not materialized.
One BOF at the IETF (LSD2, led by yours truly) talked about this. 175 people attended,
which was twice the number of the technical sessions - go figure...
The rough conclusions were:
The work with LDAP extensions is proceeding apace; paged results just got the final heave-ho, we now have agreement about what the requirements for access control lists are (but still don't know what they look like), and asking hard questions on how new proposed extensions interwork with other (proposed and approved) extensions is now becoming so much routine that the flood of new extensions has slowed down to just a minor river. That's good.
The LDUP people (replication of LDAP servers) look happy too. They think they have something that's close to being finished.
So do I.
When Fred Baker presented the makeup of people at this meeting spread over companies, one thing was blindingly obvious.
The telephone guys are coming.
The biggest company at the IETF wasn't Cisco, it was Nortel - one of the REALLY large telco operators and telephone technology innovationists. And quite a few telco and telco-related organizations were in the top-ten list too.
It's clear that the telco operators have figured out 2 things:
It's obvious enough now that they've done the obvious thing - "if you can't beat them, join them".
A number of working groups (SIGRAN, MEGACO, IPTEL, PINT) are dealing with specific telephone-like or telephone-related issues. And much of the traffic engineering stuff is driven by the need to carry voice over the Internet.
My personal opinion may be that we're investing too much in this single, "legacy" application; the way people interact will be changed by the advent of the Internet, and it's not certain that the voice-only, mostly-two-person, strangely addressed network service we've been used to calling "telephone" will be the most obvious way to communicate in the future.
But I've been wrong before - the telephone has proved extremely powerful in adapting to the requirements of the mobile telephone era. Although the standards and procedures of the current generation of mobile phones (GSM and friends) look baroque, monopolistic, inefficient and inflexible by Internet metrics, they work - and have a growth rate that makes even the Internet look slow.
The next generation of the mobile phone system (the UMTS) has a component in it called WAP (wireless access protocol?) which is "networking-to-the-phone". This is, in the imagination of the telcos, going to be coupled with "content massagers" and "media gateways" that will make these relatively low bandwidth, low resolution devices surf the Internet effectively.
It's probably possible. And even if it's impossible, it will be done.
I'm a bit afraid of the result. Because as it stands now, I don't think the Internet will function terribly well if we add another 200 million hosts to it at one go. There's something about how efficiently you can use number spaces which doesn't quite fit here... we can make the packets go for sure. But the design will either look grotesque or cause trouble.
Or both.
Oh yes - the Bill Simpson Appeal. Great show. No fireworks.
(If you're not into IETF procedures, or just don't like hearing about it, skip this
section)
Capsule version: Bill Simpson writes a document. IPSec working group works on document. Bill Simpson cooperates. IPSec working group disagrees with Bill. Bill claims copyright, takes his docs and leaves. IPSec WG writes new docs. Some words look similar.
Bill claims a) copyright infringement and b) that he should be credited. Lots of noise.
Very little useful end result. Nobody but Bill seems to agree much with Bill's view of
things. The IAB is still considering.
(I was a member of the IESG at the time the appealed matters hapen, so I have to wait
outside the virtual door for the IAB decision on this one....)
Social event: At the Seafaring Museum in the Oslo fjord - lots of food & drink, lots of great company, music was where you could take it or leave it, weather stayed good - WONDERFUL event.
Biggest gripe: Only 3 lifts go from the meeting rooms at floor 1/2/3 of the hotel to
the terminal room at 33.
We couldn't rebuild the hotel in time; sorry about that.
Welcome back - if someone dares to host it again!