Subject: RE: [Ieprep] multicast

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2002 11:12:05 -0800

At 10:18 AM 3/29/2002, Gunn, Janet NE wrote:
>What, if any, priority mechanism would be appropriate with multicast?

Isn't that sort of an application question? Multicast is a way to 
distribute it - you can send one stream to each recipient unicast, or one 
stream to many recipients multicast. In the latter case, you save the 
network N-1 streams worth of overall bandwidth.

RFC 3246 describes one approach to deploying QoS for multicast; RFC 2597 
describes another. There exist proponents of each. But bottom line, to get 
video to work in a network, you have to get the video frames into the 
jitter buffer before the jitter buffer is dumped into the codec. You can do 
that unicast, and you can do the same thing multicast.

Marshall, there is a niggly operational problem here, though. The 
applicability of multicast varies by use of the application. If you are 
trying to distribute CNN-style broadcasting via the Internet, it makes a 
lot of sense to send one video stream and tell viewers to "join the video 
in progress". If you have people asking to "show me that picture of the 
building collapsing", it might make sense to display it once every few 
seconds, and multicast it to a new multicast group every few seconds - if 
there is end to end service to accomplish that. The way the media have it 
set up, though, is that when you click on the image, you download (using 
TCP) a file which you now display using RealAudio or some such. According 
to the folks I have spoken with, bandwidth has not been the issue, it has 
been server resources, and a TCP download of yet another file is a pretty 
simple thing to offload to a web cache or a download server.

So I understand the *solution*: use multicast to send the stream once 
rather than bandwidth to send it many times. But what *problem* is it 
solving for emergency workers, and does it solve it in a manner useful to them?

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 29 Mar 2002 19:13:55 -0500

On Fri, 29 Mar 2002 11:12:05 -0800
> simple thing to offload to a web cache or a download

Dear Fred;

The trouble with that on 9/11 (in the specific cases that I
am aware of, such as the Washington Post site, which was
both Akamai'zed and totally useless, from my direct
experience), was that the source became overloaded and the
data did not flow to the cache.

In fact, on the morning and early afternoon of 9/11, the
only news sites that I could get _that had any news_, were
in Europe. My friends in NYC had the same experience, and I
received emails from there requesting news from people whose
cable TV was down and who could not get news from the
Internet.

Regards
Marshall

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2002 17:20:43 -0800

At 04:13 PM 3/29/2002, Marshall Eubanks wrote:
>The trouble with that on 9/11 (in the specific cases that I am aware of, 
>such as the Washington Post site, which was both Akamai'zed and totally 
>useless, from my direct
>experience), was that the source became overloaded and the data did not 
>flow to the cache.

Well documented and well understood. That's not the point, or at least not 
my point.

If it did get to the cache - and the various services tell me that they 
have every reason to believe that they would now be able to handle what 
happened to them on that day - would the type of service being offered be 
consistent with the use of multicast? Multicast is a great solution which 
may or may not answer the need of the application that you are proposing it 
for. Remember, bandwidth was *not*the*issue*, and multicast as a solution 
solves the problems it solves by reducing the bandwidth consumed.

Plus, it's not obvious that the emergency workers were depending on CNN 
etc. They had other things on their minds. The discussion topic of ieprep 
is the needs of emergency workers and how the Internet might meet them. 
Multicast, to be relevant in this working group, needs to address a problem 
the emergency workers had, or will have in a future emergency.