On 26 Jun 2022, at 12:19, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
From: Paul Ruizendaal
it would seem to me that Sandy had figured out a
core problem some 30
years before the TCP/IP world would come up with a similar solution. I
would not even be surprised if I learned that modern telco routers
transparantly set up virtual circuits for tcp traffic.
To fully explore this topic would take a book, which I don't have the energy
to write, and nobody would bother to read, but...
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