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

[Brian E Carpenter]

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.
> 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://datatracker.ietf.org/doc/html/draft-carpenter-metrics-00
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://elists.isoc.org/mailman/listinfo/internet-history