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

Fri Mar 4 07:43:10 PST 2022

Miles,
   The issue is not multicast vs not-multicast.
   The issue is doing multicast at the IP / Layer-3 level vs doing 
multicast at the Application level.

   The pioneering conferencing systems, built on vic and vat and MBone, 
were working in the early 1990s.  But they required heroic engineering 
to make it work and, in the early 2000s it *still* required (a little 
less) heroic engineering.
   That created an opening for CDNs etc.  And the "etc." is important, 
because how the application-level multicast is done depends on, ahem, 
the application.
   Thus, Akamai does a kind of app-level multicast for non-real-time web 
content and Zoom does its thing for real-time conferencing.  And, even 
in the old days, Usenet has its wonderful NNTP.

   Sometimes economics does trump technology, but that is not necessary 
to explain the limited success of IP-level Multicast.
	-- Guy

On 3/4/22 10:09 AM, Miles Fidelman via Internet-history wrote:
> Brian E Carpenter via Internet-history wrote:
>> On 04-Mar-22 15:15, Louis Mamakos via Internet-history wrote:
>>> 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.
> 
> And make a lot of bucks doing so.  Seems to me that's a lot of the
> reason that
> multicast didn't go all that far.
> 
> Economics tends to trump technology.  Particularly, it seems, when it
> comes to
> interoperability.  (Consider all the walled garden email systems that
> have popped
> up in the medical community - despite secure mail being built into most
> clients these days.)
> 
> Miles
> 
> 
>>> 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.
>>
>> Actually, I think it's fairly obvious: you'd need traffic metering
>> and settlements. Nobody wanted that. Apart from anything else
>> it raised anti-trust concerns because people would have to talk
>> about pricing.
>>
>> That's exactly why the following draft never got a -01 version:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-carpenter-metrics-00__;!!KwNVnqRv!QY_7WIqxdeyM6Z5L6ofsGrIrdu0degUDBMlkZA4-5XCvDOEXR7LCgP3KUQJRBg$ 
>> The ISPs wouldn't touch it. (And I didn't even mention multicast.)
>> My memory tells me that John Curran and Mike O'Dell took me out
>> for lunch (most likely at IETF 96 in Montreal) to explain the facts
>> of life to me in simple words.
>>
>>    Brian
>>
>>>
>>> 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://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!QY_7WIqxdeyM6Z5L6ofsGrIrdu0degUDBMlkZA4-5XCvDOEXR7LCgP15_iffNw$ 
>>
> 
> 
> -- 
> 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://urldefense.com/v3/__https://elists.isoc.org/mailman/listinfo/internet-history__;!!KwNVnqRv!QY_7WIqxdeyM6Z5L6ofsGrIrdu0degUDBMlkZA4-5XCvDOEXR7LCgP15_iffNw$
> 