Talk:Packet switching

Redirects: Packet Switching, packet switching, packet mode, packet oriented, packet based.

History of packet switching

Please refer to the Talk:Packet switching/OriginsArchive for the lengthy discussion that led to the baselining of the respective roles of Paul Baran, Donald Davies, and Leonard Kleinrock in the history of packet switching.

3 Sept 2006 edit of initial sentence

I have made two changes to the initial sentence: a] "are individually routed" changed to "are routed" recognizes that some virtual-call networks such as TYMNET, RCP and IPSANET used fixed routing. b] changed "which might be shared by many other nodes" to "shared with other traffic". Nodes originate and receive little information. Most traffic is generated outside of nodes (perhaps by hosts or terminals which are attached to a node).Rdmoore6 16:14, 3 September 2006 (UTC)

Other networks (non-ARPANET/INTERNET)

The article has little mention of packet switching networks other than ARPANET/Internet. Possible examples include GTE TELENET, Tymnet, X.25/X.75, Systems Network Architecture, IPSANET. The external links are devoid of references to these non-mainstream networks.Rdmoore6 20:52, 21 February 2006 (UTC)

No one is stopping you from adding in these other networks... Cburnett 20:23, 14 March 2006 (UTC)

I'm taking over Packet switched network for just this purpose. It was a redirect here, but had no links to it. I'll add a see also at the top, just in case. Ewlyahoocom 08:02, 18 March 2006 (UTC)

Let me know if you need details on some of these. I was a network management architect for GTE TELENET and worked, at a detailed level, with Tymnet and SNA. Howard C. Berkowitz 19:44, 3 July 2007 (UTC)

Is there a good reason for having separate Packet switching and Packet-switched network articles? There is some indication that readers are having difficulty finding what they're looking for. --Kvng (talk) 15:43, 11 November 2011 (UTC)

It would be wonderful to see x.25 and the like added to the history section, given how seminal it in particular was. And arthritis and lack of knowledge are stoppipng me from adding it lol, but i believe it is important as the article reads as though pactet switching was entirely developed by arpanet. Alsobe cool to mention that packet switching mirrors traditional postal or courier service where CSD is more like train freight (even insofar as parcels can travel on a train part of the way).Mycosys (talk) 06:01, 17 February 2014 (UTC)

Cleanup - Current Article Misses the Mark

The article is marked for cleanup. This strikes me as justified as the current article misses the mark in many respects. The first couple of sentences, for example, make it sound as if routing and delay are the distinguishing properties of a packet-switched network. In fact, the essential property is that there is no static division of the underlying transmission facility into fixed-bandwidth channels or "circuits". The division of the underlying bandwidth is dynamic, based on the division of payload into "packets" and the addition to the packets of some sort of control information. This control information, rather than the appearance of the data on a pre-determined circuit, is what allows the data to be directed to its proper destination. Characteristics such as statistical multiplexing, buffering delay, circuit emulation, etc. stem from this, but are not fundamental. Should the article be rewritten from this point of view? GrahamDavies 21:48, 5 July 2007 (UTC)

Historically (and I speak as an X.25 person before I was an IP person, with a brief period of OSI insanity), statistical multiplexing was indeed the first motivation, but close behind it came resiliency through some level of routing. Admittedly dating myself as a Neolithic networker, I do remember point-to-point statistical multiplexers (Timeplex, Codex, etc.) long before they had any alternate routing capability.

Telenet, ARPANET, and Tymnet, all with quite different underlying models, still distinguished themselves from oversubscription-based point-to-point products by their ability to do quasi-static alternate routing.

I agree that controlled delay, virtual circuit emulation, etc., did not seriously get considered until the semi-blind-alley of ATM. Statistical multiplexing and routing, however, are, to me, the distinguishing features of early packet switching. The routing, at first, was not always dynamic (yes, it was in ARPANET, but Telenet was quasi-static and Tymnet centralized with redundant centers). Howard C. Berkowitz 23:10, 5 July 2007 (UTC)

OK, that's a good explanation of the present point of view. The approach is "why should we do it this way" (because we can oversubscribe bandwidth and use statistical multiplexing and for that we'll accept some buffering delay) rather than "how does this aproach differ fundamentally from the alternatives" (which is where I was going). I suppose the issue is whether to lead with the technology itself or the motivation for the technology.

I'm still not sure that routing should appear so early in the article and I don't understand why the motivation for routing should be resiliency. I think circuit-switching incorporated pretty good resiliency mechanisms. I rather thought the point of routing was inter-networking and cost reduction, perhaps in conjunction with connection-less service, which isn't really possible with circuit switching.

Having argued this far, I now see clearly why I prefer to lead with a description of the technology rather than its motivation. It's easier to agree on what the technology is than how it got that way. I'm not about to push that point of view, however, so let's see what happens. 64.119.141.34 14:44, 6 July 2007 (UTC)

Packet mode verses packet switching

User:Hcberkowitz changed the following:

Packet switching is based on packet mode or packet oriented data link layer communication between the network nodes. This is a statistical multiplexing technique, where a physical communication channel is divided into an arbitrary number of logical variable bit-rate channels or data streams.

to

Packet switching is based on packet mode or packet oriented communication between the network nodes, which, depending on the implementation, can involve mechanism at the network layer, the data link layer, or both. Some legacy packet techniques, such as X.25, may have functions normally associated with other layers. This is a statistical multiplexing technique, where a physical communication channel is divided into an arbitrary number of logical variable bit-rate channels or data streams.

Thankyou for your contribution. However, it is not clear to me what you mean. The aim with this paragraph is to distinguish the definition of packet switching from packet-mode communication over point-to-point links and non-switched LAN, for example bus networks or ring networks. X.25 is packet switched, and not only packet oriented. Perhaps you mean LAPB. But that is a link layer protocol. Anyway, this is the article header, which should not deal with basic definitions rather than detail discussions. Please simplify this paragraph and move the detail discussions into the discussion page or the end of the article. Mange01 18:34, 17 July 2007 (UTC)

My concern, where I tried to make a minimal edit, was the previous comment that the data link layer was responsible for the statistical multiplexing. In X.25, that is flatly wrong; the LCN/LCGN field in the packet header, after call setup, is responsible for multiplexing multiple virtual circuits onto LAP-B. LAP-B is unaware of any multiplexing.

While one could argue that a polled SDLC channel shares bandwidth, I wouldn't call it statistical multiplexing given that it's strictly deterministic. In other words, I didn't accept that any form of packet switching exists at the data link layer.

I don't follow your point about distinguishing packet-mode communication relevant to point-to-point, nonswitched LANs, or any other medium. I've run X.25 over LANs (ISO 8880) and connectionless packets (ISO 8881 and IP) over point-to-point and switched media. Indeed, I would need to be convinced that there is any significant and contemporary distinction between packet mode and packet switching. Both terms are largely obsolete; it's arguable that this article should primarily be a redirect.

There are always exotic applications when one has to do strange things. I once had to run TCP/IP over slow and error-prone links in a third-world country. Turning on LAP-B retransmission alone wasn't sufficient, because IP's minimum packet length of 576 made retransmission extremely inefficient. By sliding in the X.25 packet level (i.e., between LAP-B and IP), I was able to negotiate a packet length of 128, which was optimal for retransmission. Howard C. Berkowitz 19:08, 17 July 2007 (UTC)

Well, packet mode/switching is not obsolete. See for example the discussion about GPRS, HSDPA, 4G versus 3G, etc. But X.25 is rather obsolete and should perhaps not be the first thing we mention here.

Your third world story was interesting.

I'm sorry, I know too little about X.25, LAP-B and SDLC to understand your point.

I have made an attempt to clarify the paragraph, but I think it can be further improved. I removed the layer issues. I must leave for now. Good night! Mange01 03:25, 18 July 2007 (UTC)

Edited opening paragraph to more accessible language

In consideration of the banner notice, but still taking into consideration the above dialogue, I went ahead and edited the opening paragraphs into common language. The bulk of this new text is based on the more accessible description of packet switching already incorporated on the [circuit switching] wikipedia page.

This edit seems to make the first bit of the article approachable for the common person. The remaining tech jargon in the article, while interesting and probably still useful, may benefit from more simplification, clarification and better organization, prior to recommending the article for quality upgrade. ThreePD (talk) 20:51, 27 September 2008 (UTC)

Octopus system

I'm not sure this Octopus system (interesting as it is) is a real packet-switching system. The reference provided doesn't given enough details of the internal mechanisms involved to make a determination. What concerns me is that if we're going to include systems where a number of computers at one location are connected via links, if memory serves there were a number of systems like that from the late 50's on. I don't have time to research this point at the moment, but I think the earliest such system might have been the NBS PILOT system from '58 or so. And then there's SAGE - I seem to recall the centers talked to each other (and they were geographically disparate, to boot). The IBM ASP thing was another example of multiple independent machines coupled into a similar processing complex. And I seem to recall that Larry Roberts was hired by ARPA because he had prior experience (at Lincoln Labs) in getting computers to communicate over phone links. Etc, etc...

To me the determining factor would be things like 'were there real packets involved, i.e. blocks with headers that could direct the data to any element of the network' and 'could the packets take arbitrary paths from source to destination, including through a sequence of nodes, so link bandwidth was shared between all nodes'. More limited inter-computer communication setups would not, IMO, count as packet networks. Noel (talk) 03:10, 27 May 2009 (UTC)

British work on packet switching

Did it really happen at the same time, or did it precede US work?

• http://news.bbc.co.uk/1/hi/technology/8498826.stm

"Roger Scantlebury, who worked with Dr Davies, presented the ideas about "packet switching" to a conference in the US, where they were picked up by the creators of the nascent Arpanet, the fledgling internet.

Does that mean Britain invented the internet?

"Yes and no," said Mr Scantlebury. "Certainly the underlying technology of the internet, which is packet switching, we did invent.""

86.7.211.128 (talk) 14:26, 7 February 2010 (UTC)

I'm not sure what Scantlebury is talking about here. If you read Baran's tome, it clearly is talking about packet switching as we know it today, and it equally clearly predates the UK work. The term 'packet switching' was clearly coined by Davies - perhaps the Beeb lost the distinction between 'term' and 'concept'? Noel (talk) 22:04, 2 May 2010 (UTC)

Good information, but unreliable due to lack to references

The article has good information and describes exactly what packet switching does. They are not any references or sources listed which makes the article unreliable even though the information may be correct. I plan on find references that will back this article and give it stability. References I plan to include are IT companies specializing in networking, other articles, textbooks, and websites. — Preceding unsigned comment added by Dmcaldwell3 (talk • contribs) 17:20, 1 November 2011 (UTC)

Merge from Packet-switched network

I don't think we need to have separate articles for the noun and verb forms of this topic. -—Kvng 13:06, 19 April 2013 (UTC)

Merge: Seems to be the same thing to me... -Keith (Hypergeek14)^Talk 19:52, 30 August 2013 (UTC)

Merge: I agree. In fact I went ahead and did the merge. A good bit of cleanup remains to be done. I'll work on that, but others are welcome to contribute too. --Jeff Ogden (W163) (talk) 22:53, 30 August 2013 (UTC)

Thanks! ~KvnG 13:52, 3 September 2013 (UTC)

Well, IMO the lengthy list of packet switched networks merged in (see "Other networks (non-ARPANET/INTERNET)", above) really detracts from a vitally-needed article which clearly explains what packet switching it, and why it was such a good engineering approach.

That list is interesting, and worth having somewhere in the encyclopaedia, but not here; here, it just cruds up the article. It should have been left in packet switching network (perhaps renamed to packet switching networks, or list of packet switching networks). Noel (talk) 15:38, 8 January 2015 (UTC)

The article's not really long enough to clearly merit a split. I've hidden stuff in the TOC. Does that help? ~KvnG 16:23, 11 January 2015 (UTC)

It helped, but... Length is not the only reason to merit a split. The long list of packet switching networks really detracts from having a clear, concise article on the topic. Noel (talk) 14:30, 1 March 2015 (UTC)

That's usually resolved by splitting to something like List of packet-switched networks. I guess we're going the long way there. I don't oppose this but also don't think it is absolutely necessary. You probably should try to get consensus for it before proceeding. ~KvnG 15:53, 5 March 2015 (UTC)

Incorrect definition of term "Packet switching" in intro

"Packet switching is a digital networking communications method that groups all transmitted data - regardless of content, type, or structure - into suitably sized blocks, called packets."

That's not correct.

Packet switching does that, but *also* relays packets through multiple hops by switching them via a dynamically updated routing table (connectionless packet switching), trying to send different packets in parallel through different routes to improve throuput, and changing decisions as routine table changes to send each packet through the shortst-time path to ultimate destination, or by relaying intact packets consecutively over a fixed path (connection-oriented packet switching).

(Of course if you want to establish a TCP connection between two adjacent nodes, so that the packets travel only a single hop, for which there is only a single physical link (no redundant links), and where that single physical link incurs less transit time than any multi-hop route, then no actual switching occurs, all packets hopefully travel exactly the same route, along that single hop using that unique physical link. But the full TCP/IP protocol is used, routing tables are consulted AGAIN for each packet to make sure they go the shortest route, so in that sense they are still switched, albeit in a trivial way.)

By comparison, packet linking (more properly a "packet-link protocol") never forwards packets. Packets are built, sent on a single hop, and immediately decomposed and spliced into the TCP-like stream at the next-higher level of protocol.

For multi-hop TCP-like circuits, packets are disassembled, re-queued per byte, and new packets are assembled from the queue, at each relay point. The size of packets at each hop depends on data available in the queue feeding into this hop of this stream, and priority of this stream along this next hop compared to competing streams that need to share the same hop.

The PCNET protocol (circa 1977, designed by Dave Calkins, Mike Wilber, Peter Deutsch, and myself Robert Maas) was an example of a packet-link protocol, which specifically had transparency for binary-octet data.

(Not to be confused with IBM's "PCNET" protocol, invented a year or so later, which was unrelated except for usurpting our copyrighted name without consent of our copyright holder, namely PCC = People's Computer Corporation of Menlo Park, California.)

DIALNET, Kermit, XMODEM, etc. were also packet-link protocols, none of which however provided binary-data transparency IIRC.

Unfortunately, PCNET never had a large enough set of nodes, with some nodes having multiple phone lines with multiple modems, to warrent implementing any stream-relay nodes, so that part of the protocol was never formally specified and implemented.

For multi-hop e-mail, we used store-and-forward of entire messages (much as UUCP-mail, and later USENET newsgroup messages, including InterNet/UUCP gateway conventions using addresses such as "infmx!cathl@uunet.uu.net"), rather than carrying message live over end-to-end multi-hop stream as SMTP typically does over TCP/IP nowadays.

Both packet switching, and packet linking, are sub-types of packet mode communication, as opposed to circuit switching.

I don't know whether PPP allows forwarding of packets (multi-hop), in which case it's properly a packet switching protocol, or it allows only single-hop streaming, with stream-data re-queued at the boundary between PPP and TCP/IP, in which case PPP is a packet link protocol, or whether each PPP packet is mapped exactly to one TCP/IP packet at the dialup-server end, in which case it's still packet mode communication but in neither sub-type packet switching nor packet linking, thus a third sub-type of packet mode communication.

"Packet switching contrasts with another principal networking paradigm, circuit switching" is also wrong. It's packet mode communication, a super-type of both packet switching and packet linking, which directly contrasts with circuit switching, as peers/sisters in the hierarchy/cladogram.

"Packet mode communication may be utilized with or without intermediate forwarding nodes (packet switches or routers)." -- Correct.

Google search for "packet link protocol" finds mention but no definition:

www.all-acronyms.com/Packet+Link+Protocol

"All definitions for PACKET LINK PROTOCOL acronym or abbreviation have been removed or haven't been published yet."

www.all-acronyms.com/reverse/Packet%20Link%20Protocol

"PACKET LINK PROTOCOL has not been found in any definition"

Is there some more standard jargon for what I've been calling "packet link" protocol since circa 1980 (when it became necessary to distinguish PCNET from the newly-proposed TCP/IP when trying to explain it to people), and I'm the only person still using the "packet link" jargon because I don't yet know the new standard jargon for the same concept?

198.144.192.45 (talk) 09:44, 2 May 2013 (UTC) Twitter.Com/CalRobert (Robert Maas)

Animation is inappropriate file size

The animation is 8.9 MB - that's hardly appropriate. It's nowhere informative enough to justify that kind of bandwidth. 76.178.147.142 (talk) 16:18, 3 May 2015 (UTC)

Animation contains glaring error

I came here to learn about packet switching, so I'm no expert. But the starting message and the received message are different! Surely that's not right!? 212.62.5.158 (talk) 16:03, 16 September 2015 (UTC)

The animation shows that the order of messages can be changed through a packet switched network. The receiving device must reorder the data to reconstruct the message. ~Kvng (talk) 17:30, 20 September 2015 (UTC)

X.25 vs. Frame Relay

I have removed this tangential and difficult-to-traverse section from the article. I have looked at X.25 and Frame Relay as potential homes and I am not convinced it would be helpful in either location. ~Kvng (talk) 14:11, 20 August 2019 (UTC)

Both X.25 and Frame Relay provide connection-oriented operations. X.25 provides it via the network layer of the OSI Model, whereas Frame Relay provides it via level two, the data link layer. Another major difference between X.25 and Frame Relay is that X.25 requires a handshake between the communicating parties before any user packets are transmitted. Frame Relay does not define any such handshakes. X.25 does not define any operations inside the packet network. It only operates at the user-network-interface (UNI). Thus, the network provider is free to use any procedure it wishes inside the network. X.25 does specify some limited re-transmission procedures at the UNI, and its link layer protocol (LAPB) provides conventional HDLC-type link management procedures. Frame Relay is a modified version of ISDN's layer two protocol, LAPD and LAPB. As such, its integrity operations pertain only between nodes on a link, not end-to-end. Any retransmissions must be carried out by higher layer protocols. The X.25 UNI protocol is part of the X.25 protocol suite, which consists of the lower three layers of the OSI Model. It was widely used at the UNI for packet switching networks during the 1980s and early 1990s, to provide a standardized interface into and out of packet networks. Some implementations used X.25 within the network as well, but its connection-oriented features made this setup cumbersome and inefficient. Frame Relay operates principally at layer two of the OSI Model. However, its address field (the Data Link Connection ID, or DLCI) can be used at the OSI network layer, with a minimum set of procedures. Thus, it rids itself of many X.25 layer three encumbrances, but still has the DLCI as an ID beyond a node-to-node layer two link protocol. The simplicity of Frame Relay makes it faster and more efficient than X.25. Because Frame Relay is a data link layer protocol, like X.25 it does not define internal network routing operations. For X.25, its packet IDs—the virtual circuit and virtual channel numbers—have to be correlated to network addresses. The same is true for Frame Relay's DLCI. How this is done is up to the network provider. Frame Relay, by virtue of having no network layer procedures, is connection-oriented at layer two, by using the HDLC/LAPD/LAPB Set Asynchronous Balanced Mode (SABM). X.25 connections are typically established for each communication session, but X.25 does have a feature allowing a limited amount of traffic to be passed across the UNI without the connection-oriented handshake. For a while, Frame Relay was used to interconnect LANs across wide area networks. However, X.25 and Frame Relay have been supplanted by the Internet Protocol (IP) at the network layer, and the Asynchronous Transfer Mode (ATM) and/or versions of Multi-Protocol Label Switching (MPLS) at layer two. A typical configuration is to run IP over ATM or a version of MPLS. <Uyless Black, X.25 and Related Protocols, IEEE Computer Society, 1991> <Uyless Black, Frame Relay Networks, McGraw-Hill, 1998> <Uyless Black, MPLS and Label Switching Networks, Prentice Hall, 2001> < Uyless Black, ATM, Volume I, Prentice Hall, 1995>

The animation, which is misleading, needs to be improved

The animation is misleading on how the Internet works: in absence of a route change, an event to be kept rare for the E2E efficiency of TCP, routers must maintain the same route for all datagrams that belong to the same user session. Supposing that many users would like to nevertheless keep the animation in view of its being nicely made, I propose to just mitigate its misleading effect by simply making it very clear, in the animation explanation itself, that the Internet works differently. The last text proposed by Zac67 goes in the right direction but is still IMHO insufficient. The new text I propose is: “This animation illustrates a theoretical model in which consecutive packets of a single user message would typically take differing routes. This is however not the real Internet model in which each node must forward all packets of a given user session to the same next node until an update of its routing table imposes a change.”--RD2017 (talk) 11:50, 18 October 2023 (UTC)

routers must maintain the same route for all datagrams that belong to the same user session [...] This is however not the real Internet model in which each node must forward all packets of a given user session to the same next node is a misconception on your side. There is no such obligation and a router doesn't even have a concept of a "session" – it deals with packets on an individual basis and in a stateless manner.

Of course, out-of-order delivery usually causes performance problems and is generally avoided as best practice, even at high cost. Yet there is no formal obligation to ensure in-order or same-path delivery. In fact, the Internet was designed for providing variable paths.

The only problem that I have with the animation (as an admittedly fringe case) is that the packet seem to be reordered at the destination, yet they're presented out of transmitted order which might confuse an observant reader. --Zac67 (talk) 17:51, 18 October 2023 (UTC)

In your quote of what I wrote about "the same route for all datagrams", the key words "in absence of a route change" are missing. Indeed, all packets of a user session, e.g. a TCP connection, don't necessarily all take the same route from its beginning to its end, and destinations must therefore be ready to receive out-of-order deliveries. But each out of order delivery is usually due to a routing table update, itself due to change of traffic amount in some parts of the network, a typically unfrequent event.

Yes, a router deals with packets "on an individual basis" but, if several net hops are possible, it chooses the one to be used as a function of the current state of its routing table, a state which is usually stable for some time.

I hope that, with our two last modifications, the subject will be closed.--RD2017 (talk) 09:01, 19 October 2023 (UTC)

Hi Zac67. I don't understand why you persist to avoid clarifying that the Internet does avoid simultaneous parallel routes. To replace "the Internet" by "Most networks", you should know at least one network that doesn't. If you can indicate which one, that's useful information. But otherwise, you should IMHO stop my effort to avoid misleading readers about how the Internet works.

Besides, your previous comment that avoiding misordering (even if only most of the time) could be "at high cost" is a misundertsanding of how it works (it isn't AFAIK techincally justifiable). --RD2017 (talk) 10:08, 23 October 2023 (UTC)

@RD2017: On the contrary – I changed "the Internet [...] attempts" to "most networks attempt" which is more general. There is simply no reason why the Internet would and other networks wouldn't. "To replace 'the Internet' by 'Most networks', you should know at least one network that doesn't." – There may be networks that simply don't care, which we don't know, so I used most for general, best practice. All would require a good RS, imho. "why [I] persist to avoid clarifying that the Internet does avoid simultaneous parallel routes" – I didn't. Where did you read that from? --Zac67 (talk) 11:38, 23 October 2023 (UTC)

FWIW, [1] is a study from 2004 that found reordering of about 3% in longer paths across the internet. Up to 20% on certain of the longest paths. I found a couple other studies ([2], [3]) from around the same time that corroborate this. However, 2004 was a very long time ago in terms of internet technology. ~Kvng (talk) 19:01, 28 October 2023 (UTC)

Thank you for the references, all interesting. To know why out-of-order deliveries should preferably be avoided, RFC 2991 is the best reference I know. It explains why routers should avoid producing systematic out-of-order deliveries (they introduce problems on PMTUD, on TCP performance, and on Ping and Traceroute debugging tools). The RFC also provides guidelines on how to avoid creating such problems.