Don't know why I came across this, but I found a document on Sprintlink's
site that says their entire backbone is multicast enabled, and they also
peer with the MBONE for multicast traffic. They charge no fee for dedicated
customers to be multicast-enabled.
Are any other major networks doing this? Or have I been living under a rock
and _everyone_ is doing this now?
Thanks,
Deepak Jain
AiNET
verio and l3 are both multicast enabled... I don't know the extent to
which it's available as a customer...
joelja
(almost) any verio customer can receive multicast. It is
available upon request. Let me know if you are a verio customer and
require assistance getting multicast.
- Jared
I think I should have been more clear.
When multicast enabling a network, am I wrong in assuming that the routers
will only multicast to their direct, end-user connections and peers (like an
access router will only offer streams to its direct connections)? I am
trying to figure out what advantages multicast-enabling a backbone has when
the majority of customers are not multicast-peers of their upstream routers.
Thanks,
Deepak Jain
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
AT&T has most/all of their backbone natively multicast enabled and will
multicast enable customer access routers upon request. They do have a
setup fee, but no monthly recurring fees.
UUnet has two levels of multicast capabilities. Their "Basic" package is
receive only and is free. Their "Gold" package is full send/receive, but
they charge a ton for it. The basic package seems pretty useless to me.
To join a multicast group, you have to be able to send to it, right?
I have found that most sales reps don't know what multicast is, or why it
is important to have. It also takes a few phone calls to get the right
people to explain how their backbone is setup. If most customers would
ask about and request multicast capabilites, we would probably see more
carriers toutintg their multicast capabilities which would, in turn,
generate more customer demand.
You can't find any information about multicast on AT&T's website, yet they
are fully multicast enabled. sheesh!
=== Tim
UUnet has two levels of multicast capabilities. Their "Basic" package is
receive only and is free. Their "Gold" package is full send/receive, but
they charge a ton for it. The basic package seems pretty useless to me.
To join a multicast group, you have to be able to send to it, right?
not right. with many/most multicast protocols, you can (sometimes must)
build a source-rooted tree, not a shared tree. joining as a receiver
is then a matter of becoming another branch off the tree, hopefully
along the reverse shortest path to the sender. in this case, you can
send but not receive.
possibly the difference is in your permissions to establish a (s,g) pair
or to announce a core (RP).
which multicast routing protocols are on offer? PIM-SM? MSDP? MBGP?
if you can't get your multicast across the border, it may not be useful
to you.
there are better protocols in the literature than are deployed
but the arcana is often politically anathema for inertial, commercial
or plain lack-of-working-code reasons.
I have found that most sales reps don't know what multicast is, or why it
is important to have.
many network engineers glaze over at the mention of multicast. it
takes some serious grey matter work to fathom the entire subject.
AT&T has most/all of their backbone natively multicast enabled and will
multicast enable customer access routers upon request. They do have a
setup fee, but no monthly recurring fees.
Fundamentally is that not the way that it should be? I think that if I
were an AT&T customer I am paying for the ability to flow bits at whatever
speed my link or service contract was permitted. It should not depend if those
bits are multicast bits or unicast bits. Then in my selection of a provider the
provider that offered me more features for the same dollar would have a larger
value and ultimately win my decision process.
UUnet has two levels of multicast capabilities. Their "Basic" package is
receive only and is free. Their "Gold" package is full send/receive, but
they charge a ton for it. The basic package seems pretty useless to me.
To join a multicast group, you have to be able to send to it, right?
If you are wanting to receive multicast traffic of a live event for
example, no you would not have to send to the multicast group. Your client
would send an IGMP join request to the (*,Group) and then ultimately receive
(host, Group) of data. Your clients and routes only need to know that there is
a host registered to receive the data, then they will not PRUNE the flow.
I have found that most sales reps don't know what multicast is, or why it
is important to have. It also takes a few phone calls to get the right
people to explain how their backbone is setup. If most customers would
ask about and request multicast capabilites, we would probably see more
carriers toutintg their multicast capabilities which would, in turn,
generate more customer demand.
Sales represenatives are only taught to sale what is the sales managers
hot topic and makes the commision levels that they want. It is unfortunate that
VERY few companies actually have a sales force that understands the community
and all the features that they have to offer.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> UUnet has two levels of multicast capabilities. Their "Basic" package is
> receive only and is free. Their "Gold" package is full send/receive, but
> they charge a ton for it. The basic package seems pretty useless to me.
> To join a multicast group, you have to be able to send to it, right?not right. with many/most multicast protocols, you can (sometimes must)
build a source-rooted tree, not a shared tree. joining as a receiver
is then a matter of becoming another branch off the tree, hopefully
along the reverse shortest path to the sender. in this case, you can
send but not receive.
Now my eye's are glazing over. 
Did you mean "receive but not send"
or actually, "send but not receive" as you wrote above?
UUnet's arguement for charging to sendis that you can potentially chew up
large portions of their network bandwith with only a small connection
yourself.
possibly the difference is in your permissions to establish a (s,g) pair
or to announce a core (RP).
With their basic package, you don't get to announce an RP at all.
which multicast routing protocols are on offer? PIM-SM? MSDP? MBGP?
if you can't get your multicast across the border, it may not be useful
to you.
Their "Gold" package is PIM-SDM/MSDP/MBGP. Their "Basic" package is
PIM-SDM/SDR with DVMRP unicast-routing. I was told UUnet runs PIM
Dense-Mode on their multicast backbone.
there are better protocols in the literature than are deployed
but the arcana is often politically anathema for inertial, commercial
or plain lack-of-working-code reasons.> I have found that most sales reps don't know what multicast is, or why it
> is important to have.many network engineers glaze over at the mention of multicast. it
takes some serious grey matter work to fathom the entire subject.
Very true. I am having a hard time grasping the technical specifics. It
has taken quite a bit of study and discussion to figure out what I have so
far, and I am sure I have misunderstood many things. Unfortunately, what
I am finding out, is that multicast is a subject that rarely comes up as
an option with customers. There isn't a demand, so the providers don't
put the resources into it...
=== Tim
I do not know that I would agree on that aspect, but if they did then
it would be the result that multicast works in reverse of unicast. If the same
person were to learn multicast then they just might learn better the
fundamentals of unicast as well.
Now my eye's are glazing over.
i did indeed. there wash shushi in my keyboardsh.
UUnet's arguement for charging to sendis that you can potentially chew up
large portions of their network bandwith with only a small connection
yourself.
what else is multicast for? hopefully it works out cheaper than your
expected outbound unicast streams would have cost (including the clue
overhead for supporting mcast)
Very true. I am having a hard time grasping the technical specifics. It
has taken quite a bit of study and discussion to figure out what I have so
far, and I am sure I have misunderstood many things. Unfortunately, what
I am finding out, is that multicast is a subject that rarely comes up as
an option with customers. There isn't a demand, so the providers don't
put the resources into it...
things don't gain momentum if they keep changing direction.
<sotto-voce>the same might be said to the v6 folks</sotto-voce>
- J
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> UUnet's arguement for charging to sendis that you can potentially chew up
> large portions of their network bandwith with only a small connection
> yourself.what else is multicast for? hopefully it works out cheaper than your
expected outbound unicast streams would have cost (including the clue
overhead for supporting mcast)
That is my argument. I am working on them now. However, what they hit me
back with, is if you are multicasting, you can have a 10MB connection to
UUnet, send a 1MB multicast stream which could be multiplied 100 times
over their backbone. Thus, you can use much more than their backbone than
you are paying for.
However, with unicast, if you have a 10MB connection, you can't send more
than 10MB with unicast. If you need more bandwidth, you buy more.
My argument back, was that it is highly unlikely that I will have 100
different receivers which will have 100 different paths across their
network. If their network is designed properly, there should be less
impact on their network with multicast than with unicast. I hope they buy
that.
> Very true. I am having a hard time grasping the technical specifics. It
> has taken quite a bit of study and discussion to figure out what I have so
> far, and I am sure I have misunderstood many things. Unfortunately, what
> I am finding out, is that multicast is a subject that rarely comes up as
> an option with customers. There isn't a demand, so the providers don't
> put the resources into it...things don't gain momentum if they keep changing direction.
<sotto-voce>the same might be said to the v6 folks</sotto-voce>
Changing direction or improving? Many of the original problems with
multicast are being addressed and improved upon with newer RFC's and
protocols. At least, that is my understanding... I am new to multicast,
so that may just be the marketing drivel that I have stumbled onto.
=== Tim
However, with unicast, if you have a 10MB connection, you can't send more
than 10MB with unicast. If you need more bandwidth, you buy more.My argument back, was that it is highly unlikely that I will have 100
different receivers which will have 100 different paths across their
network. If their network is designed properly, there should be less
impact on their network with multicast than with unicast. I hope they buy
that.
Now you get to a Randy Bush argument of what are you actually paying me
for (Sorry Randy, but I like your comment so I decided to apply it here) from
the provider. If the provider is assumming all the risk for your flow should
they not be compensated for the flow? If you are going to have N times
receivers of your stream, should they then not have the ability to charge you
some factor greater than 1 to support the flow? One method is to limit the
amount of bandwidth of multicast per edge interface, but if a 128K stream is
sent to hundreds or thousands of places then it could impact certain links as
well. Maybe not the backbone running at OC-x speeds...
The impact to their backbone is calculated on a fixed connection speed.
There have been enough studies that proper traffic engineering can be
accomplished with Y number of connections at X data rate. The larger number Y
is the actually closer that they can better construct their models. Then with
actual trending they can forcast and the situation continues.... Then comes
multicasting... If I started streaming a popular live event (since so much
attemtion with multicast is for multimedia anyway) at say 384K and tens of
thousands of people subscribe there will be N number of nodes that will be
getting the stream once, but the overall impact to the network on any given
link is 384K, but the overall impact would be N times of 384K. That could
amount to a total aggregate of say 10times that you are paying or higher. I
would think that a charge based on number of receivers at a reduced rate over
unicast would be in order.
> > an option with customers. There isn't a demand, so the providers don't
> > put the resources into it...
That is the way our economy works...
The advantage is that you can turn up a customer the same day
compared to having to schedule some maintence to make the network multicast
enabled.
Making all your bgp sessions do unicast+multicast is a trivial
configuration change and does not cause any extra instability.
Then you can turn on/off pim to the edge where the customer
is attached as needed.
- Jared
they not be compensated for the flow? If you are going to have N times
receivers of your stream, should they then not have the ability to charge you
some factor greater than 1 to support the flow? One method is to limit the
amount of bandwidth of multicast per edge interface, but if a 128K stream is
sent to hundreds or thousands of places then it could impact certain links as
well. Maybe not the backbone running at OC-x speeds...
I'm relatively new to multicasting, but my impression is that if you have a
128K stream that you are sending out then, even if you are sending it towards
hundreds or thousands of places, no individual link would have more than
128K on it (thus the point of multicasting). There may be hundreds of
different links each with an additional 128K, but the N-factor amplification
you are referencing would be more from the "we now have to send this same
128K out 20 different peering links and possibly (depending on your peering
policy) pay 20 times the bandwidth cost" but it shouldn't cause any
individual link to become overloaded.
Eric
In the original message keep reading. I stated the same thing. The
concept is not just to a peering location, but say you have hundreds to
thousands of receivers, each link is getting (in my example 384K) then you have
N number of links each getting 384K. If you have a backbone with say 500 major
links and there is a receiver off each wanting this traffic, then the backbone
provider is duplicating your traffic 500 times, delivering it to 500 locations,
but being paid for one 384K flow.
Another manner to look at this is that in tradiational uni-cast there
is a hop on and a hop off that is a 1 to 1 relationship. In multicast there is
a 1 to N relationship and the provider is still being compensated on a 1 to 1
basis. The coutner to this is that each party is paying a hop on and hop off so
why should the provider be compensated more as each end party is paying for
their connection. The myth to the latter argument is that you are not truely
paying for the cost of delivering the packets from A to Z, the providers count
on the ability to aggregate traffic and knowing that at any given moment that
their tail links are not consumed. It is risk management, traffic engineering,
whatever you want to call it, but it ammounts to knowing that there is not a
full 1 to 1 relationship. Multicast if it ever becomes widely deployed will
shoot the theory and pricing model and one of two things will happen in my
opinion: Cost for multicast traffic will skyrocket as providers of content
reduce their demands for bandwidth (take 1000 streams of 384 and I can get it
on a T1 vs multiple OC-3), or cost for all connections will increase.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> AT&T has most/all of their backbone natively multicast enabled and will
> multicast enable customer access routers upon request. They do have a
> setup fee, but no monthly recurring fees.Fundamentally is that not the way that it should be?
Yes, I agree.
I think that if I were an AT&T customer I am paying for the ability to
flow bits at whatever speed my link or service contract was permitted.
It should not depend if those bits are multicast bits or unicast bits.
Then in my selection of a provider the provider that offered me more
features for the same dollar would have a larger value and ultimately
win my decision process.
Again, I agree. I am struggling with this issue right now.
> UUnet has two levels of multicast capabilities. Their "Basic" package is
> receive only and is free. Their "Gold" package is full send/receive, but
> they charge a ton for it. The basic package seems pretty useless to me.
> To join a multicast group, you have to be able to send to it, right?If you are wanting to receive multicast traffic of a live event for
example, no you would not have to send to the multicast group. Your client
would send an IGMP join request to the (*,Group) and then ultimately receive
(host, Group) of data. Your clients and routes only need to know that there is
a host registered to receive the data, then they will not PRUNE the flow.
Thanks, Michael. I had one other person inform me that JOIN requests are
done with IGMP. I appreciate the correction.
=== Tim
Now you get to a Randy Bush argument of what are you actually paying me
for
credit where due department:
i was merely channeling a position sean doran has taken for many years
and, while we have a non-op message
o after five years, i graduated from verio a couple of months ago, and
am now at at&t doing research and architecture
o i suspect the nanog thread regarding which backbones have native
multicast enabled may be inaccurate. but it's good to see new folk
exploring the technology
o the folk most interested in revising the meaning of "tier-1" are
usually those who are not
o the kiddies are out for the summer nothing constructive to do, so
are impersonating net operators on aim, phone, etc. so verify cold
calls, aim, etc.
o ipv6, mpls, and diffserve-enabled backbones will solve all your
problems
randy
credit where due department:
i was merely channeling a position sean doran has taken for many years
Sorry, I have hear that argument from you in past nanogs, and on this list for
some time. I will correct my source....
and, while we have a non-op message
o after five years, i graduated from verio a couple of months ago, and
am now at at&t doing research and architecture
Congratulations then may be in order. I noticed the change in some
postings and the URL that you sent, but am taken aback that you changed from
the hectic world to a more calm and slower pace setting of research. (That is
the natural opinion... hehehe)
o i suspect the nanog thread regarding which backbones have native
multicast enabled may be inaccurate. but it's good to see new folk
exploring the technology
Could not agree more, there are several native multicast backbones and
we interact with several as well. Most of our multicast traffic is not
multimedia, but actually science data to researchers.
o the folk most interested in revising the meaning of "tier-1" are
usually those who are not
Not sure as to if that applies to this thread or my former comments,
but I tend to agree
o the kiddies are out for the summer nothing constructive to do, so
are impersonating net operators on aim, phone, etc. so verify cold
calls, aim, etc.
Again not sure as to implication, but my messages to this list with
this address are personal in nature. I have the experience of running several
regional ISPs (not teir-1, but large non the less. Kinda like Verio some
time back...) and currently running NASA's IP networks (WAN not the hosts).
o ipv6, mpls, and diffserve-enabled backbones will solve all your
problems
Sounds like you researchers have all the answers, so when will it be
enabled and resove all our problems? Will we not have a new set of problems,
or has something changed that resolves those as well?
Again, congratulations, if you are happy, on you move from the
commerical sector to the research side.
o ipv6, mpls, and diffserve-enabled backbones will solve all your
problems
Think you missed making sure you cook this lot up on
top of ATM SVCs and season with tier-1 peering to taste
before diffserving.
Alex Bligh
Personal Capacity.
o ipv6, mpls, and diffserve-enabled backbones will solve all your
problemsThink you missed making sure you cook this lot up on top of ATM SVCs
i was using atm-2, not atm-1. in the modern age, they're called lsps not
svs. i think all my competitors should deploy these technologies.
randy