On May 3, 2011, at 11:02 AM, Rémi Després wrote:
>> I refer you to the definition of the term. A datagram is self-addressed and
>> contains all of the information necessary to deliver it from its source to
>> its destination.
>
> In hosts, which perform datagram reassembly, that's correct.
You really don't understand. The distinction is between datagram networks and
virtual circuit (in context, SNA and X.25) networks. A transport PDU could be
carried by a virtual circuit from here to there, or it could be carried in a
datagram over a connectionless network. TCP data is carried in datagrams, and
UDP data is carried in datagrams. NFS routinely used fragmented UDP packets to
carry its data, but when UDP was designed, that was not the intended model;
anyone who has done very much UDP-with-fragmentation will tell you that it
operationally doesn't work very well either if there is any kind of bottleneck
in the path.
I found a formal definition of the term in RFC 1594:
Datagram
A self-contained, independent entity of data carrying
sufficient information to be routed from the source
to the destination computer without reliance on earlier
exchanges between this source and destination computer and
the transporting network.
Is this really worth arguing about? I use the term "datagram" because the
meaning is important in the context; I'm playing with the prefixes in the
addresses in the datagram header. I don't use the term "packet" because it's an
empty word; it can be applied at any layer (an ATM "cell" is a packet with a
certain format, an IP datagram is a packet with a certain format, a LAPB or
Frame Relay "frame" is a packet with a certain format, and a TCP segment is a
packet with a certain format). A packet is a quantum of data moving as a single
unit in the network at the layer of interest. I'm sorry it bothers you. What
NPTv6 deals with is IP datagrams. You very correctly called me on using both
terms in the document, and in response to your comment I corrected the usage.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
