All things considered, I'd rather be in Pittsburgh
or - what I saw at the 48th IETF in Pittsburgh, July 30 to August 4, 2000
First, some personal matters:
As of August 1 (coincidentally, the second day of this IETF meeting),
I am now a consultant with Cisco Systems, and my work email is now alvestrand@cisco.com.
However, this note does not represent a company position in any way,
shape or form - given how new I am with the company, it will take me quite
a bit of time to figure out what the company position is!
And I intend to make sure the harald@alvestrand.no address remains
viable for a long time yet.
The quote from Ezra Pound's gravestone in the title seems strangely
appropriate, but maybe in a different way from the author's intention.
The centre of Pittsburgh today is a strange mixture - lovingly restored
churches and brownstones, gigantic office towers intermixed with older
buildings that seem to remain standing mostly out of habit - the architecture
seems to reflect the checkered history of the economy of this city.
But Pittsburgh of today is certainly a city worth visiting - and the
direction of the economy seems "up".
Not that we spent much time studying the architecture - most IETFers
seemed, as usual, to concentrate on the meetings, rushing out to meals
and rushing back to the next meeting. Sometimes I wonder whether we should
hand out warning flyers to the restaurants before we hit them....
Drama ongoing: Instant Messaging doesn't get the message
In the ongoing media war between the AOL "monopoly" and the Microsoft+allies
"underdog", the IETF is one battlefield among many. AOL simplified the
battle by choosing not to offer a proposal for the IETF; that meant
that we were only left with 3 or 4 proposals that were technically sound,
backed by reasonably committed groups of engineers, and completely impossible
to merge.
The lead proposals seemed to be IMXP, growing out of a traditional
"Internet engineer" grouping led by such well known and not uncontroversial
figures as Marshall Rose and Dave Crocker, and proposing an entirely new
protocol with some nice engineering; the other team, with strong ties to
the voice-over-IP industry, suggested building on the framework of the
runaway-successful SIP (Session Initiation Protocol) to create the basis
for this new application.
At the end of the meeting, a few facts stood out:
-
Both proposals would be able to fulfil the requirements set
-
Neither team was willing to give up on their idea.
The area directors and working group chairs at last punted, suggesting
that a 3-man team from each "camp" prepare detailed proposals on a very
short timescale (2 weeks). The next round is forthcoming!
Of course, IETF delay serves the nonstandard monopolist in this matter.
Something will give.
The Hammer-of-the-month prize goes to....MPLS!
The Multi-Protocol Label Switching protocol/architecture/suite is a mechanism
to move packets more efficiently through a network, by making sure the
switches (not quite routers) in the middle of the network can do simple
lookups on short identifiers, rather than doing longest-prefix match on
long ones.
The resulting architecture bears a resembleance to ATM, in the same
way that Frame Relay resembles X.25: Most of the extra bells and whistles
are gone, just the model remains.
It's been popular with many service providers for a while, and as with
all tools that fit a need, people are looking at other things it might
be useful for.
One suggestion is provisioning of virtual private networks (VPNs);
if this network has customers on different providers' networks (a common
case), this of course requires the interconnection of multiple MPLS clouds.
Question: What is the difference between a subnet layer and the Internet?
Answer: The Internet can reach any customer, anywhere.
Question: When you can do MPLS to any customer, then....?
Answer: Oops....
Scaling a system based on hop-by-hop identifiers to Internet scale does
not seem trivial. It's an useful tool, but may be stretched beyond its
natural usefulness.
The news that someone had suggested carrying MPLS over IP in order to
get between service providers was greeted with a storm of suggestions for
other "interesting" stacks one could builld - the one I remember best is
MPLS over IP over IPSec over IP over ATM over IP over HTTP.....all of these
are suggested, built or already in production somewhere in the Internet..and
it was not the longest one.
Spaghetti junctions on the Infobahn (with tollbooths)
There seems to be a growing tendency to depend on tunnels in the modern
Internet.
We've got encryption tunnels using IPSec or SSH, VPN tunnels using
IPSEC, L2TP or GRE, service tunnels for multicast and IPv6, special-purpose
tunnels for routing info and other things.
This is one instance of "boxes in the middle" - things that are interested
in doing other things to packets than merely get rid of them ASAP. Other
examples are TCP ACK finaglers, NAT boxes, "transparent" webcaches, DNS-based
source optimizers and the "anycast" approach to service provisioning.
The IAB is worried enough about this that it's spending some time at
a workshop worrying aloud about them.
¥æÛ and other interesting names
What's in a name?
For the longest time, the Internet has been getting along on a strange
theory: That the characters a-z, 0-9 and the dash were enough to
name anything that needed global names (that is, DNS names).
This worked great for most names that were in English, and for a lot
of others - especially if you were willing to use names that just vaguely
resembled the "real" name of the referred-to object..
But once the bizarre idea that an Internet nametag "should" belong
to someone who was using the name for something in Real Life, it was a
very short step to the conclusion that names that didn't fit into the model
of A-Z also "deserved" to be represented in domain names.
Once the first instance of this idea turned up, it was not long before
others jumped on the bandwagon, and now there are more than a dozen companies
registering domain names tthat have non-ASCII characters in them.
However, there are some problems.
-
Lots of code (and I mean LOTS) expect A-Z names, and will behave strangely
otherwise.
-
Having multiple representatoins of names doesn't work terribly well either
- after all, the purpose of the DNS is to match names with data about them,
and if you can't agree on how to represent them, it's hard to match them.
-
How does case sensitivity really work? I mean, matching A to a is easy,
but how about matching Å to å while realizing that ß matches SS if it
matches at all?
-
Who's responsible for making sure a name registered in traditional Chinese
characters is not registered by someone else using Simplified Chinese?
-
How do you match Hebrew names with optional vowels?
And so on and so forth. Like with some other thorny issues, "if you aren't
scared, you don't understand the problem".
The IDN working group has been looking at this for a while now. A lot
of people have looked at the problem too (like the ICANN DNSO ccTLD forum),
and decided it¨s our problem. They won't move until we do.
But we'd better get something that works soon. And get it right.
It looks as if we know what the best solution we can make based on the
DNS looks like.
But if that doesn't work well enough - we have to try something else.
Throwing multicast around
It would not be fair to call multicast a roaring success.
Still, having a single box send a video stream to 10.000 other boxes
does not work very well.
There are multiple alternatives:
-
Change the multicast model to be more deployment-friendly, such as single-source
multicast and small groups multicast
-
Move the multicast function to the application layer, and use unicast between
"content distribution points", with other protocols to find the "right"
application server
-
Declare multicast boring, since when everyone can make their own near-real-time
video menu, nobody will be watching the same program anyway
The last alternative doesn't sound right. There are many other things to
use multicast for than 10.000 TV channels.
But the most effective way to deploy multicast is probably that seen
in the Netherlands: Put the TV stations on the multicast backbone, and
post instructions on how to get connected to it.
Content is king.
IPv6: The absence of alternatives....
....clears the mind marvellously.
Everyone realizes that the IPv4 model doesn't work for mobile phones.
And the walled garden approach taken by the current WAP specification
has already proved itself too painful for words. (the DoCoMo IMode service
in Japan is a success - perhaps mainly because it focuses on content, not
technology. Content is king.)
And Perry Metzger claims that he can now use an IPv6-only box for something
useful, something that was impossible 6 months ago. Progress!
DNS security: Not a done deal
OK, we know how to put digital signatures into DNS records.
From there to a secure DNS service involves a number of steps, some
of which were noted in previous notes in this series.
The calculation of the week was this:
If it is required to put an NS record, an A record, an A6 record, a
NXT record, SIG records and a KEY record for all of these into a DNS packet,
how many nameservers can you list within a 1280-byte packet?
The answer seems to be on the order of four.
Oops. Perhaps increasing the default max buffer size from 512 bytes
to 1280 bytes won't solve all the world's problems after all.
OTOH, if the current experiment with "anycast DNS servers" (draft-ietf-dnsop-ohta-shared-root-server-test)
works well enough, perhaps we won't need 13 root server names in the packets
anyway?
Rumours, factoids, nibbles, teasers...
did you know that....
-
if you count the amount of fiber being laid in the US every day, and translate
it into a speed, it is around Mach 4?
-
if you plotted the current transatlantic/transpacific capacity and what's
planned to be online in 2 years' time on a linear plot, you'd have to use
a magnifying glass to see today's capacity?
-
to get an IETF participant really upset, mention "patents", "royalties"
and "IPR" in close succession.
A new set of clarifications on intellectual property rights issues was
circulated at the IETF; basically, if you say something at a meeting, you
allow other people to quote you, and if you have or know of rights that
would make it impossible to use your given information freely, you have
to disclose that fact
-
if you thought you had a document being considered by the IESG, you might
want to look at http://www.ietf.org/IESG/status.html
to see if the IESG thinks so too. (This is news!)
It's time to get this document distributed. So I won't say anything
more.
Enjoy!