[Top] [All Lists]

Multicast and charging (Was: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?)

2008-03-08 16:25:40
Patrik Fältström wrote:
I am afraid that this is the sort of reasoning that has lead to P2P having such widespread use.

I fully agree, (unicast) P2P is a godsend for Transit operators.

The fun with "p2p" is though, that HTTP is also peer to peer and actually anything unicast is p2p from a design point of view ;)

Is not one of the problems of exchanging multicast packets that someone that receive a multicast packet do not know how much bandwidth in the internal network that packet in reality will take? If the incoming packet is a unicast packet, there is a 1:1 relationship between incoming and outgoing packets. With multicast, one might have to send >1 packet out over the egress after receiving a packet?

Generally a network is a tree, unicast will mean you get a packet per branch, multicast you get 1 packet for all branches. As such your traffic is less. Though indeed, if you get 1 packet from your transit (thus at the root of your network), it takes up 1 packet everywhere else in your network. But you only pay your transit for 1 packet, not the zillion of branches that you might have and thus not for a zillion of packets.

AFAIK the biggest problem with multicast is management though. Not evening going onto the subject of it being available in hardware for most platforms...

If so, could not new models of charging be that if A send multicast packet to B, "the number of packets sent" are the number of packets going _out_ from B, not in to B? If it was possible to do such accounting...

Multicast account is simple: you do it at the place where you measure, same as unicast.

Thus if you have:
                       /----> H
                      /-----> I
               /---> E------> J
A ---> B ---> C ---> F....
       \       \---> G....
          \---> D....

For multicast, if you have clients everywhere, at A you see 1 packet and at H you see 1 packet, but that same packet is also at I J etc.

For unicast you see <clients> times packets at A and 1 packet at each client.

As such, an ISP (B) who has clients C,D,E,F,G..., will pay Transit A, in case of Multicast 1 packet, while for unicast he would pay Transit A for <clients> packets. In both cases though ISP B will charge his clients for that single packet. As such, multicast makes money for B, but not for A.

Transits thus don't like it, ISP's don't get it.


(This all reminds me to put working multicast on the list again for SixXS...)

Attachment: signature.asc
Description: OpenPGP digital signature

IETF mailing list
<Prev in Thread] Current Thread [Next in Thread>