Jump to content

Talk:Packet switching

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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

History of packet switching

[edit]

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.

Other networks (non-ARPANET/INTERNET)

[edit]

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)[reply]

No one is stopping you from adding in these other networks... Cburnett 20:23, 14 March 2006 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
As of 30 August 2013 Packet-switched network is now a redirect to this article. ~Kvng (talk) 23:16, 6 January 2025 (UTC)[reply]
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)[reply]
There's a paragraph about it today. Also Packet switching § X.25 era. ~Kvng (talk) 23:15, 6 January 2025 (UTC)[reply]

Octopus system

[edit]

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)[reply]

I agree it is not really clear what's going on but there is some discussion of packets in one of the sources ([1]). ~Kvng (talk) 23:40, 6 January 2025 (UTC)[reply]

The animation, which is misleading, needs to be improved

[edit]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

@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)[reply]

FWIW, [2] 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 ([3], [4]) 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)[reply]

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. — Preceding unsigned comment added by RD2017 (talkcontribs) 13:54, 29 October 2023 (UTC)[reply]