Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Quake/QW and Pipeline 75 and NAT
David P. Reed wrote:
>
> Talk to Vint or Jon if you want to validate my role in the development of
> TCP, IP, and UDP. The key folks were Danny Cohen, Vint, Jon, me, and Steve
> Crocker, with help from John Schoch of Xerox PARC. RFC 6 was produced by
> Jon after significant debate in the original Transmission Control Protocol
> design group recognized the need to create the opportunity for
> non-virtual-circuit end-to-end protocols. This was a crucial point in the
> original design discussions, hotly contested, and I have a number of
> discussion documents authored by me and others regarding this. Jon got to
> write up the final spec of TCP, IP and UDP, which last we all viewed as
> pretty trivial - the key thing was the split of TCP into two layers, and
> the creation of a UDP alternative to TCP on top of IP which would support
> the range of connectionless protocols being discussed.
Ok. Just as long as we're agreed that STD 6 (RFC 768) is the UDP
standard.
> I fail to understand how you can read the phrase you quote from RFC 768,
> "may be assumed to be the port to which a reply should be addressed in
> the absence of any other information,"
> as _requiring_ that additional traffic be sent to that port, or as
> _requiring_ that addresses not be sent in the data portion of a UDP
> datagram or in other places not accessible to the NAT translator. Where
> else would 'other information' be provided?
I read it the following way:
You didn't quote the whole paragraph in the STD:
> Source Port is an optional field, when meaningful, it indicates the port
> of the sending process, and may be assumed to be the port to which a
> reply should be addressed in the absence of any other information. If
> not used, a value of zero is inserted.
To me, and many others, this means that to write a non-zero value in the
UDP header, and to copy that value in the UDP datagram is
1. A waste of 16 bits.
2. Completely pointless.
3. Against the last sentence of the quoted paragraph "If not used, a
value of zero is inserted." Quake packets have non-zero source ports,
but at the same time, clearly do not use that field.
4. A quick way to break any NAT scheme, which I realize you're in favor
of.
> My basic point is that the requirement you cite would be contrary to the
> goal of using UDP to support connectionless and multi-endpoint,
> non-session-oriented protocols. If one must stretch English meaning so far
> in order to argue that making the NAT kludge work is more important than
> preserving design options hard fought for, I see no point in continuing the
> discussion.
Exactly how has what I've said broken UDP's goal to support
connectionless and multi-endpoint non-session-oriented protocols? Those
theoretical protocols wouldn't work under NAT anyway. You would have to
get dedicated addresses.
My point is that UDP does support a mode of operation where it
essentially works like TCP, only there is no guaranteed packet delivery
or packet order. But yes, there is a "connection." You may say "but
UDP is a connectionless protocol, it says so in the STD." As soon as
you set the source port in the UDP datagram, you've made what, in this
argument, is effectively a "connection" (but not a stream as in TCP).
The client expects packets back to the port specified in the UDP header.
But what does that have to do with Quake? How is Quake
"connectionless"? Are there Quake clients talking to each other? No.
Are there Quake servers probing for clients? Nope. Is there ever Quake
traffic when a client does not request it? Nope.
Quake is using UDP. But, like DNS client queries, it can't be claimed
that Quake is connectionless. During normal, non-NAT operations, there
is a connection between the server at port 26000 to the client at some
random port. There are no other packets involved with the server and
that client.
Again, I have never claimed that this means UDP always involves
connections of some sort. Nor, can I conceive of a way to interpret
what I've said to mean that. In addition, NAT just won't work for
connectionless UDP protocols. (none of which have been named.)
You may ask why the topic always comes back to Quake, or why Quake does
or doesn't work. It is the topic of this thread, and the conclusion
many people have reached is there is a bug in the Quake protocol. UDP
clearly accommodates protocols wishing to use connections with it's
_optional_ "source port" field. I emphasize "optional" because that's
what it is. By setting this field to zero, the protocol is saying that
it does not use the field. Quake does not do this. As a side note, if
id Software set this field to zero, their protocol wouldn't violate
UDP. I'd personally consider it a bug, but would have no STD to cite
against it.
I am completely unconcerned about other connectionless UDP protocols you
have not mentioned. If someone wants to use those protocols, they
will. I don't have a problem with it, or care... but I am aware that
only a very small number of people care about those protocols. In
addition, I am also confident that if any of those protocols are
valuable to the mass market, they will be popular when IPv6 is
prevalent.
As a side note, an Ascend mailing list is not a good place to argue
about the merits of NAT. The InterNIC is, for all intents and purposes,
forcing ISPs to use NAT (i.e. many people on this list). If we don't
justify our address space utilization, the InterNIC will take the poorly
used address space away. We use NAT because it validates our ip address
space. We save dedicated IP addresses for those that need them.
Thanks,
--
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>