packet switching won over Virtual Circuits in the now distant past but in small, local and un-congested networks without reliability constraints, any solution can look good. If “Performance is Hard”, so are Manageability & Reliability. Packet switching hasn’t scaled well to Global size, at least IMHO. Ethernet only became a viable LAN technology with advent of Twisted pair: point to point + Switches. The One Big Idea for common channels, collision detection/avoidance, became moot, even irrelevant with switch buffering & collision-less connectivity. Watching networking types deal with ethernet multi-path routing & link failover - quite problematic for 802.1 layer-2 nets, I can’t but think “If you don’t design a feature in, why expect it to show up?”. All those voluminous CCITT / ITU-T standards were solving the problem “keep the network up & working”, they knew it wasn’t easy ‘at scale’. Harder if you have to billing :) Something I’ve never understood is how to design large-scale VM farms , where DB’s, Filestores & ’services’ (eg Web) have to be migrated between physical hosts, made more difficult when services have to be split out of existing instances: who gets to keep the MAC & IP address? I can’t see either a layer-2 or IP addressing scheme that’s simple and works well / reliably for large VM fleets. Whereas, ‘well known’ Virtual Circuit endpoints can be permanently allocated & tied to an instance/service. Packet encapsulation & separation techniques, like MPLS, VPN’s and VLAN’s, are now commonplace in IP networks. Even the ubiquitous (multi-level) use of NAT for traffic isolation & preventing unwanted ingress shows, IMO, a design failure. Why would I advertise my internal network with IPv6 and allow every bad actor to probe my entire network? Hellish security admin for little benefit. I’ve never understood this reasoning. It seems to me, IP networks are trying to provide the functionality of Virtual Circuits - dedicated paths, transparent failover & even committed data rates. There are two very valuable functions that ‘dedicated paths’, implying topology-aware switches, can do that packet-switch can’t: - Network-based “Call Transfer” There’s no packet-switch mechanism I know, that allows a connection to an advertised ‘gateway’ or authenticator, that then allows invisible network rerouting of the connection to a ’service provider’ or host, without giving away information to the caller. This would be really handy for “follow me” connections, moving between user devices, even different access networks. Apple have just announced something like this - moving running sessions between Mac, iPad, iPhone as needed. The inverse, “blocked caller id”, can’t be done in IP without a repeating host, ence VPN’s. [ In telephony, all A & B parties are identified for billing & forensics / interception. Addrs only hidden from other users. ] - “Multicast” / Conference calls Packet switched ‘conferencing’ is rarely done by the Network, despite multicast IP standards 25yrs of more old, they are rarely used. If major router vendors had good solutions, they’d be pushing them. The Pandemic brought forward the need for video calling everywhere, created a market for “Conferencing” products & “Streaming”. Isn’t Multicast of Free To Air TV & radio over Internet both obvious & desirable? It should be the modern equivalent of & replacement for ‘wireless’ broadcasting. Should be trivial if everyone has one or more mobile devices and a home Internet connection. The current Point-Point transmission model of Streaming Services - no scheduled broadcasts, On-demand only - seems to be the most resource intensive, hence costly, solution possible. Flash storage is under $0.20/GB, a small PVR with 1TB of “circular buffer” could cheaply convert “Scheduled” to “On Demand” at the customer premises. [ Samsung have announced a 1.5TB micro-SD card, targeted at surveillance recording. Purportedly, “100 days of video”. Cost? NFI ] One of the modern challenges for Enterprise Customers is “change network provider”. One major Aussie firm just took two years to move Service Provider and it was ’news’. 25yrs ago, and probably now as well, interconnecting / splitting corporate networks following merges / de-merges was a huge task. IP networks require re-numbering and basic IP services, like DNS, email, web, need re-provisioning / re-platforming. The Worst Case error - happens too often - is Network Admins cutting themselves off from the Remote Admin Network. ‘Recovery’ is slow & painful - all sites / all devices may have to be visited, even if you have a backup network link. Did Microsoft have a fault like this in the last 12 mths after it acquired a vendor? There was a big outage. Post merger, Enterprise phone switch & voice network are relatively simple & fast to change and rarely result in Admins losing Remote Admin access. It’s not that I don’t like cheap, easy Ethernet devices that mostly Just Work and at small scale are simple to setup and easy to manage. 30 years of hardware development has been a boon to us all, in almost all ways. Rob Pike wrote a great piece (in the 1980’s) about cheap hardware forcing systems software to take up the slack, an example I thought of Ashby’s Law of Requite Variety. Have we arrived in this Packet Switch nightmare because of "Microsoft is Best” thinking? I don’t have a proper name for this blinkered view of the world, backed by arrogance & the assumption “What I don’t know can’t matter”. regards steve j -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

On Sat, Jun 25, 2022 at 10:20 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: In that connection I have always admired Padlipsky's RFC 962, which exploits the existing TCP architecture to do just this. So simple, so easy, so Unixy.