Talk:Network packet

Definition

I decided to put the definition in this page, instead of Datagram, since a lot more pages link here, so we can avoid a redirect if a reader hits the "packet" link. Noel 09:12, 24 Aug 2003 (UTC)

I'm torn about the IP packet area. I just fixed some typos for 'length' and also realised that a) the description is very long-winded and might benefit from a graphic representation, and b) the idiom 'next XX bits is YY' is used. I personally would use 'next XX bits are YY' instead, but I can see the point of treating the group of bits as a single non-plural. What do people think? TheMoog 11:34, 16 February 2006 (UTC)

Yes. I've cleaned up the section and made it an ordered list, but I'm still not too happy with it. Maybe it's better to remove the section and link to the IPv4 packets/IPV6 packets sections instead? Ddfreyne 12:56, 29 April 2006 (UTC)

It seems like a bad idea to treat datagram only under packet. I have two reasons for saying that: 1) The idea of datagram is basic to the service provided by IP (in fact, it is often called "datagram service" and 2) A datagram is not really the same kind of thing as a packet, which is simply a unit of data; it is a different kind of thing, defined in all the textbooks on Internet networking that I have used by its basic property (containing enough information to get it to its destination) -- eg., Peterson & Davie, which devotes a section to datagrams; Kurose & Ross, which introduces it in its own section in the first chapter; and Comer, which also has a section on the "IPv4 Datagram". This definition is missing here -- all that can be understood from this article is that a datagram is an unreliable packet. --- There should be a separate article on datagrams. Ngriffeth (talk) 22:56, 9 March 2010 (UTC)

FYI Packets vs Datagrams

I feel inclined when removing a chunk of existing definition to explain what is going on. The definition tried to use the notion of "connections" to define datagrams. This is not correct - the generally accepted definition is that datagrams are unreliable while packets might-or might not-be, depending of if they are datagrams. While connections are related to reliable transmission on the Internet (TCP), there are clear examples of networks that did not support connections per se, but attempted to provide reliable transmission (Arpanet, SDLC, and probably everything else predating Aloha). The network does not need to have a notion of "connections" in order to have reliable transmission. Rick Smith 16:55, 14 June 2006 (UTC)

RFC 793 (Transmission Control Protocol) has a glossary that defines packet, segment and datagram. These definitions are:

Datagram - "A message sent in a packet switched computer communication networks."

Packet - "A package of data with a header which may or may not be logically complete. More often a physical packaging than a logical packaging of data."

Segment - "A logical unit of data, in particular a TCP segment is the unit of data transferred between a pair of TCP modules."

The RFCs are the documents that define how TCP/IP networks operate. If there are other documents that transcend them, somebody let me know.

RFC 793 says nothing about a datagram being reliable or unreliable. It only says that a message sent on a packet switched network is a datagram. It is incorrect to say that IP is unreliable. RFC 791 states that IP can rely on other protocols, particularly TCP, to provide reliability. Therefore, you don't know whether an IP datagram is reliable or unreliable. That depends on the protocol that formed the packet and passed it on to IP. It is also incorrect to say that datagrams come from a certain layer of the OSI model. According to RFC 768, UDP datagrams may come directly from the transport layer complete with a pseudo header, ready to send out on the network or IP may add an IP header to them. Rsduhamel (talk) 23:27, 15 April 2010 (UTC)

You are correct. People here are manufacturing truth by consensus. Jigen III (talk) 09:29, 24 July 2020 (UTC)

That was in fact not correct. At the time of RFC 793, datagram service (UDP) at the Transport Layer did not exist, IIRC. The monolithic "Transmission Control Program" had been split into a reliable TCP (Transmission Control Protocol) component and an IP (Internet Protocol) component which was the sole unreliable component. "Unreliable" is strongly associated with "datagram" in RFC 793. Kbrose (talk) 14:25, 24 July 2020 (UTC). PS: after review, UDP had actually just been invented, but 793 still is still based on the original TCP/IP model. Kbrose (talk) 14:31, 24 July 2020 (UTC)

"Therefore, you don't know whether an IP datagram is reliable or unreliable. That depends on the protocol that formed the packet and passed it on to IP." RFC 791 says:

The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.

So if you have a protocol that runs on top of IPv4, that protocol cannot rely on IPv4's service to reliably deliver the packet - a given IP datagram is not guaranteed to be delivered reliably. RFC 793 says:

A stream of data sent on a TCP connection is delivered reliably and in order at the destination.

In order to do this, a TCP segment might be retransmitted if not acknowledged, but that's done at the TCP layer; the IP datagram containing the TCP segment will not be retransmitted at the IP layer - it might be retransmitted at a layer below IP if that's part of the service provided by the protocol at that layer, but that's not part of the service offered by IP.

However, even if the IP layer makes no claim of guaranteed delivery for the datagrams it sends, a Web search for "reliable datagram" has enough hits to indicate that in at least some places, the term "datagram" is used to refer to something for which there is a delivery guarantee. For example, this document mentions Infiniband offering "reliable connection", "unreliable connection", "unreliable datagram", and "reliable datagram" transport-service types. Guy Harris (talk) 10:35, 24 July 2020 (UTC)

This Infiniband example is a reliable link technology, constructed so that any protocol running over it is reliable, for providing low latency channels. Calling the result "reliable datagram" service is a clever marketing tactic, but adds little to the common understanding of the individual terms. Kbrose (talk) 15:44, 25 July 2020 (UTC)

Datagrams have nothing to do with reliability, although there is an association. The underlying IP layer carries datagrams which can be fragmented and sent as several packets. What you call them depends on what layer you are inspecting. Johnuniq (talk) 10:54, 24 July 2020 (UTC)

"Datagrams have nothing to do with reliability" That's what I'm saying - the term "datagram" appears to be used for cases where packet delivery is guaranteed and where packet delivery isn't guaranteed. "Datagram" appears to be used for packets sent without a connection. Guy Harris (talk) 00:06, 25 July 2020 (UTC)

The network layer's only purpose is to forward and route; it is not about guarantees, so it's a moot point. The problem here is the phrasing. By saying that a datagram is always unreliable will only create confusion for the reader considering that its reliability depends whether it's encapsulating a TCP or UDP segment. A retransmitted TCP segment will still be encapsulated in an IP datagram; just because a service is provided by a different layer doesn't mean encapsulation stops. A better statement would be one of TCP vs UDP, not of TCP vs IP, considering that the transport and network layers serve different purposes. Jigen III (talk) 11:15, 24 July 2020 (UTC)

"A retransmitted TCP segment will still be encapsulated in an IP datagram" It will be sent in a new IP datagram; IP didn't make any effort to make the original IP datagram arrive. And there may be people saying a datagram is always unreliable, but I'm not one of them. IP datagrams are unreliable, in that any protocol that wants to offer reliable delivery over IP will have to take care of that itself. Guy Harris (talk) 00:09, 25 July 2020 (UTC)

You have to be careful which model of networking you want to cite. TCP/IP is not equivalent to OSI, so mixing language can only lead to confusion and misinterpretations. In the Internet Protocol Suite (TCP/IP) the Internet Layer is always unreliable, IP has no means to guarantee success, as Guy Harris demonstrated earlier quoting from the RFCs. The model delegates reliability (for the user's payload) to another layer: Transport Layer in case of TCP, or to the Application Layer in case of UDP. Even perfect error-correction in the hardware or in the Link Layer, while providing user data integrity, do not make the Internet Layer reliable, and the packets at that layer are still datagrams. Reliability has to be evaluated at each layer. Accordingly it makes no sense to state that the IP layer is reliable when using TCP at the Transport Layer. It is not. It is the Transport Layer that performs mitigation. The only correction that IPv4 performs is that it performs datagram reassembly after fragmentation from packets correctly, but IPv6 does not. The Network Layer of OSI is different in that it conceivably covers reliable protocols just as well. Text books and many other sources are often very lax on the distinctions between the models, and many authors seem to be confused themselves or tired about the difficulty, often molding their own models on the fly to fit the purpose of their book or audience. Kbrose (talk) 13:59, 24 July 2020 (UTC)

Note that ISO 8602 "Information technology - Protocol for providing the connectionless transport service" doesn't appear to use the word "segment", just as IETF RFC 768 "User Datagram Protocol" doesn't use "segment". That's probably because those packets aren't segments of anything - at the transport layer, each UDP or CLTP datagram is independent of all other datagrams. Guy Harris (talk) 00:03, 25 July 2020 (UTC)

"Datagram" comes from "data-telegram", which conveys the essence that a datagram is a complete message transmitted in one chunk. At least that was the original idea, and this still holds when ignoring fragmentation on a link of limited capacity. UDP sends complete messages. For this a "connection" is not necessary, get the message and be done for now. A "segment", otoh, is just that: a part of a message, and the complete message must be read in multiple reads by the receiver. This requires a "connection", and that requires reliability. That is the model for TCP. But this illustrates that the designers of the Internet Protocol Suite and of the OSI suite, needed to be careful in the naming of the entities sent across the network. They called them packets, because they didn't always represent complete messages as visualized by the application. However, from a strict layer-narrow view, these behave just like datagrams, unreliable and connection-less, in the case of the IP suite. Hence, IP and the third layer are usually said to provide a datagram service. On the larger scale, from the perspective of the application, that may or may not be the case. Kbrose (talk) 16:07, 25 July 2020 (UTC)

end-to-end principle

Is there a name for "networks that forward packets several hops from one node to the next, but occasionally drop packets and immmediately forget about them"? I suppose I could call them "dumb networks that follow the end-to-end principle", but is there a better name?

What other kinds of networks are there? --65.70.89.241 21:19, 21 August 2006 (UTC)

My understanding is that email is sent using some sort of ARQ system ...

It's called an unreliable network. Learjeff 19:57, 10 August 2007 (UTC)

preamble

I am considering adding this to the article:

In some radio communications, a fixed preamble is transmitted before the rest of the packet.

This helps the automatic gain control and clock recovery in the reciever settle to reasonable values.

Is the preamble considered "the first part of" the header, or "comes before" the header? --65.70.89.241 21:19, 21 August 2006 (UTC)

Is a one-byte preamble the same as a "sync byte"? A "sync byte" is mentioned in Transport_stream#Packet (0x47) and Binary_Synchronous_Communications#Framing (what value?) and Local_Interconnect_Network#Header (0x55).

--65.70.89.241 16:18, 25 August 2006 (UTC)

Ethernet also uses a preample. Preambles are common to protocols that use a broadcast medium, regardless of the particular broadcast medium. For Ethernet, the preample provides collision detection.

---

65.70.89.241 15:33, 20 May 2009 (UTC)

No

Merge of Transmission block to this, December 2007

Although the article 'transmission block' is very sparse and not very informative it should probably not be merged here, at least not without careful examination of the scope of that term. 'Packets' are a form of 'transmission blocks' by some definition perhaps, but transmission blocks are not usually packets, it would appear. A major characteristic of 'packets' or packet-mode communications is that they are sent over a shared communications medium, whereas telecom's 'transmission blocks' are sent over circuits, therefore the need for the common start/end of block markers. Kbrose (talk) 00:07, 24 February 2009 (UTC)

I agree. Merge declined. --Alvestrand (talk) 06:22, 28 June 2009 (UTC)

Payload

Under "Example: IP packets," it doesnt specify where in the list the payload itself goes and what size or size range it occupies. -67.161.. —Preceding unsigned comment added by 67.161.54.63 (talk) 10:43, 28 March 2011 (UTC)

I have clarified this. ~Kvng (talk) 15:16, 8 June 2019 (UTC)

Removed extraneous

There was some info that did not seem immediately relevant or supportive to the topic. This info was also unclear and unsupported. I am removing those lines and adding here.

• From Summary:
  • By using packet switched networking it is also harder to guarantee a lowest possible bitrate.

End of remarks Stephen Charles Thompson (talk) 15:41, 24 January 2012 (UTC)