Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Quake/QW and Pipeline 75 and NAT
I realize I'm going to lose this argument, as I'm arguing with the
inventor of UDP, but I'm going to give it a shot. :)
David P. Reed wrote:
>
> This is probably the wrong place for this point, but I'll make it anyway.
>
> I was the person who proposed UDP in the original TCP/IP design (in 1976),
> and fought for it as a vehicle for connectionless protocols.
> Connectionless protocols are very powerful, especially when there are more
> than two end-points in a protocol, and when communication among the end
> points is used to propagate state changes in an application-specific way.
Well, unfortunately this is the end of 1997. IP address space is low...
soon the InterNIC will charge for them. 99% of protocols (including UDP
based) the "average" user would use over the Internet are
connection-based. (off-hand, I can't think of one that isn't, but I'm
sure there are). I realize that UDP means "connectionless," but most
protocols simply take this to mean "best effort delivery," or simply use
it as a base for their own TCP-like wrapper (as Quake almost does).
This also facilitates the use of switching protocols, which I believe
the Internet is heading. (Why pay the routing overhead for every
packet? I think the idea behind switching is the same as the idea
behind a CPU cache.)
> UDP does NOT have 'connections'. It is NOT required, and was NEVER
> intended that a UDP datagram must be part of a 'session' set up by some
> kind of initial datagram from the person 'opening' the 'session'. That may
> be a common use, but it is not the only use, and such a restriction was not
Well, it does turn out that this use is the most desirable for the
average dialup user or dialup LAN.
> intended in the original design. It's a peculiar rewrite of history to say
> (as one correspondent did) that Quake violates a rule of UDP by
> transmitting addresses in data portions of datagrams. That rule is not a
I do apologize. I was under that impression, but I was wrong.
> UDP rule, but a NAT-compatibility limitation - a case where NAT does not
> work. But NAT-compatibility is not a requirement for Internet protocols -
> to the contrary, IP is an end-to-end protocol, and the IP spec says that
> certain parts of the IP datagram are to be delivered unchanged (and that
> includes the address fields). That NAT happens to work at all is a lucky
> accident.
The keyword here is lucky. NAT is a good idea. With a single class C,
one can attach 254 networks of arbitrary size. Not only that, it acts
as a cheap firewall... and customers can switch POPs/ISPs without
renumbering.
> NAT requires that UDP be used in this restricted manner (requiring
> connections) in order to detect new translations that it must do. In other
> words, NAT precludes a wide variety of perfectly legitimate protocols.
But this issue has been about Quake. There aren't any special needs of
the protocol beyond what NAT can handle. Quake is client-server based,
as most other protocols. id Software just decided to ignore the source
port on the packet and trust the client. This is unlike other UDP
protocols, and offers no benefit to Quake. This has been my point.
There's no inter-client communication.
> IMHO, this makes NAT bad for the Internet. If you cannot conceive of the
> Internet evolving and adding new multi-endpoint protocols, you may not
> agree. But I hope some of you will join me in resisting the spread of NAT
> by not using the feature, and by informing any ISPs or corporate sysops who
> use NAT that NAT is a bad idea for the health of the net.
Obviously, I disagree here :) I do conceive of the Internet evolving.
I believe it will evolve to IPv6, where NAT doesn't make a lot of
sense. Every computer will have it's own 128-bit IP address. (1 for
each ISP it connects to, that is.) NAT has no place in that future.
But we're here, now.
> The spread of NAT (which Ascend and other vendors are encouraging, much to
> my chagrin, and anger,) with its assumption that 'connections' are
> maintained, is being used as a vehicle for stamping out protocols that are
> PERFECTLY valid, and in many cases very good ideas. It may be possible to
What mainstream protocols? There's nothing special about the Quake
protocol requirements as to break NAT... just an incompatible
implimentation. I'm sure that users who need the special UDP protocols
(none of which have been named) can ask their ISP for dedicated IP
addresses. Most ISPs would be happy to give out DHCP or dedicated
addresses if the customer can justify the need. (then, the ISP can
justify the IP addresses to the InterNIC. The InterNIC doesn't believe
that 253 computers web browsing are justification for a class C.)
> make Quake's protocol NAT-compatible - and I suspect the market will do
> that, because enough ISPs have decided to offer NAT-crippled service to
> save a few bucks on subnet address space. But there are other protocols
> (some yet to be invented) that make a lot of sense for their application,
> but for which forcing NAT compatibility may be difficult, impossible, or
> just plain suboptimal.
Again, in those cases, a good ISP will give their customers dedicated
addresses. But why waste them on users without the need for them? (i.e.
most people) It's not just dollars, it's sense. IPv4 addresses are a
limited resource. Why waste them?
--
Jason Eggleston
SysAdmin, Jet.Net Inc.
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: