Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: multicast seen as equivalent of caching packets

  • From: Jamie Scheinblum
  • Date: Wed Jun 16 10:10:57 1999

The problem I think is getting cooperation.  If you do replication on top of
the existing non-multicast internet you would have to build a network on top
of existing routing.  Which it seems to me would mean either a new hierarchy
of data transport needs to be built (new peering, etc), or the source sender
ends up sending content to n first level nodes on a small height tree, which
offers no great advantage. 
I always thought the advantage of multicast was that it minimized the number
of receivers the source sent content to.  Packet caching in multicast seems
to be at the advantage that if any multicast router had caching enabled,
everyone in the tree would benefit, if I followed Sean's summary correctly.

-jamie

> -----Original Message-----
> From:	Alex P. Rudnev [SMTP:alex@Relcom.EU.net]
> Sent:	Wednesday, June 16, 1999 6:29 AM
> To:	smd@clock.org
> Cc:	avg@kotovnik.com; jamie@fast.net; nanog@merit.edu
> Subject:	Re: multicast seen as equivalent of caching packets
> 
> 
> Sorry; it was my assertion in this tread -:). Through it change nothing...
> 
> Why don't start fron the replication/reflection, then go to the 
> short-time-caching, may be to the long-time-caching, and then only to the 
> multicasting. Those who is playing around multicasting now looks amazing 
> - they build a complex, twisted routing schema with the PIM, etc etc to 
> deliver usially ONE data stream to the ONE customer -:). May be, to the 
> two customers. And then ask _why don't another want to play with them_.
> 
> This was the issue - on the first stage, simple packet replication is 
> just the same as multicasting, but is much simpler to inplement globally. 
> And this is in fact caching with the zero time-to-expire.
> 
> Alex.
> 
> > If you think about it briefly, Vadim's assertion that "packet caching"
> > and "multicast distribution" are indistinguishable if the packets are
> > retained in the cache for essentially 0 time.
> 
> > 
> > I think Vadim's point is that accepting the validity of the 
> > multicasting = caching assertion allows one to consider doing 
> > a better job of reducing the consumption of network resources 
> > by replayable content than the use of native multicast does.
> Just right.
> 
> > (This is perhaps why Peter Lothberg and company have been working
> > fairly hard at enabling the inflation of the use of Internet multicast,
> > since the deployment costs of native IP multicast are so small that
> > the ultimate non-scalability of IP multicasting (or multicasting
> > in general if you accept Vadim's argument) does not prevent people
> > from turning on PIM/SM+mBGP+MSDP.   First you roll (excuse the pun) out
> Compare the multicsting listeners and RealVideo or RealAudio or MP3 
> listeners; first are 1% of the last. What multicast deploying are you 
> talking about, it's a myth yet.
> 
> 
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095)
> 230-41-41, N 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> 





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.