[ih] ARPANET pioneer Jack Haverty says the internet was never finished

[Louis Mamakos]

How much simultaneous multicast traffic do you think there could be
over wide-area transit networks and across transit providers?

And that ship has sailed.  CDNs solve this problem now, for both
live and near-live content as well as delayed and on-demand content.
You don't need to augment your router with PIM-SM or some other
multicast routing protocol, or figure out how to make interdomain
routing work.  That's a lot of work for solving the general case
of multicast IP across the global internet, to displace the CDN-based
solution that already works and solves the higher-volume adjacent
problem space.  Application-layer multicast is mature and works
really well and can evolve without having to go in lock-step with
all of the intra- and inter-domain L3 routing/forwarding hardware
that's deployed.

I think one popular multicast solution was in last-mile CATV networks
to do delivery of video streams.  But from a user-experience
perspective, you've got join latencies that compete with another
HTTP unicast request and I can't pause my TV program to hit the
bathroom.  It's cheaper to have the extra bandwidth than adding
storage capacity in, e.g., set-top boxes for local caching and
asynchronous delivery.

I think that IP multicast is really neat tech, and I tried to make
a commercial success of service offering, but in the general case
I couldn't get (enough) customers at the time to want to pay for
the capability to support the infrastructure costs, not to mention
the operational complexity.

And then you open a can of worms on what settlement-free peering is
supposed to look like for multicast traffic.  With unicast traffic
crossing a peering interconnect, you didn't have to think real hard
about equal costs/equal burden sort of issues.  It wasn't obvious
at that time what that would mean for multicast traffic.

Louis Mamakos

On 3 Mar 2022, at 16:34, Miles Fidelman via Internet-history wrote:

> But why does there NEED to be a separate charging scheme?
>
> Seems to me that supporting multicast is a LOT cheaper than supporting 
> all that extra traffic generated by lots of redundant traffic.  
> Multicast would also likely reduce pressure on chokepoints, at ISP 
> boundaries.
>
> Miles Fidelman
>
>
> Brian E Carpenter via Internet-history wrote:
>> Actually inter-ISP diffserv is technically well defined now
>> as is mapping to MPLS and 5G classes of service. But indeed,
>> the issue for diffserv and multicast is the same: there is
>> no cost-effective business model across ISP boundaries.
>> Flat-rate best-effort capacity-based charging is still vastly
>> cheaper and simpler to implement. I can't see any reason that
>> will ever change.
>>
>> Regards
>>    Brian
>>
>> On 04-Mar-22 08:10, Dave Crocker via Internet-history wrote:
>>>
>>>> The small amount of multicast address space really isn't a problem 
>>>> in
>>>> practice.  For any successful, scalable multicast deployment, 
>>>> you'll end up
>>>> with source-rooted trees and the forwarding state in the routers 
>>>> are (S,G)
>>>> tuples.
>>>
>>>
>>> Broadly, for anything like TOS or multicast, there are two different
>>> sets of issues, either of which can easily create showstoppers.
>>>
>>> First is, of course, the mechanics.  What is the functional design?
>>> What is the basis for believing it will satisfy real-world needs?  
>>> How
>>> robust will it be?  How easy to operate?  Etc.
>>>
>>> Second is gaining adoption across a very large range of entirely
>>> independent operators.  What are their immediate, compelling 
>>> business
>>> incentives?
>>>
>>> As we keep seeing, getting adoption of anything across an Internet
>>> infrastructure service, is more than a little challenging.
>>>
>>> Cable TV's multicast is done within the span of a single 
>>> administrative
>>> control.  And it's a relatively stable, constrained set of traffic.
>>> Generic Internet multicast is multiple administrations, with highly
>>> variable sets of traffic, across many administrations.  Very, very
>>> different game.
>>>
>>> d/
>>>
>
>
> -- 
> In theory, there is no difference between theory and practice.
> In practice, there is.  .... Yogi Berra
>
> Theory is when you know everything but nothing works.
> Practice is when everything works but no one knows why.
> In our lab, theory and practice are combined:
> nothing works and no one knows why.  ... unknown
>
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history