Subject: Re: packet loss between mbone2.UU.Net & SanFrancisco.mci.net

From: [email-masked] (Tim Dorcey)
Date: Tue, 11 Feb 1997 19:56:50 -0800

At 7:04 PM 2/11/97, Bill Fenner wrote:
>In message <v02130505af26b79c206e@[204.80.124.85]> you write:
>>If the Internet were fully multicast capable, then each person on a 28.8
>>dial-up link would have the ability to send a 28.8 stream simultaneously to
>>every other host on the Internet.
>
>No, that's broadcast.  With multicast, each person on a 28.8 dial-up link
>would have the ability to send a 28.8 stream simultaneously to each host
>on the Internet which desires to receive said stream.  Why is this a problem?

The problem, I think, is that users will frequently request a higher data
rate than they are actually capable of receiving at any given moment (e.g.,
because of congestion or ignorance).  The question, then, is who pays for
the capacity to carry traffic that is dropped before it reaches its
destination?  Unregulated unicast (e.g., UDP) presents exactly the same
problem, except that the amount of data any source can put into the network
is limited by the size of pipe they have paid for.

We have seen the Internet scale amazingly well under a load dominated by
point-to-point streams with end-to-end flow control.  Each stream is
simultaneously limited by both the size of the incoming and the outgoing
pipe.  We are now seeing increasing volumes of point-to-point streams
without end-to-end flow control.  Perhaps this can be managed, since the
input pipe is still fixed capacity.  I think multicast might be
self-managing if there were back-pressure from the outgoing end.  I don't
believe the combination of multicast packet replication and no flow control
can be deployed Internet-wide without some significant
policy/management/administration beyond what we have become accustomed to
for unicast traffic.

Tim

---

From: Bill Fenner <[email-masked]>
Date: Tue, 11 Feb 1997 20:12:26 PST

In message <v02130508af26e6ce37fe@[204.80.124.85]> you write:
>because of congestion or ignorance).

And they will get extremely poor service, and they will stop doing whatever
they did to make that happen.  (Doctor, it hurts when I try to fit 40kbps
down my 28.8kbps line!)

It is true that flow control is an important thing that's missing from
the current multicast transport protocols.  That is still a research
topic (other than the "this hurts, stop doing that" approach).

  Bill

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 12 Feb 1997 09:54:33 +0000

Bill

right.....but

some problem with end to end congestion avoidance for multicast are
1/ everyoine uses UDP,. which typically operates _outside_ the unix
kernel, outside the winsock.dll, outside the mac os......

this means that Any Idiot (tm) can write a multicast app, but Most
Idiots (tm) don't understand control loops...

2/ you can use closed loop feedback

other than that used by _some_ adaptive apps like Ivs....for slowing
down the video/aido rates based on rtp receiver stats.....but as van
and ian argued out, there are better ways....

3/ we do have some ideas in steve mccanes rdlm/vic research, but we
need fast leave deployed well for them to work...plus the coordination
of multiple join experiments between different unlreated sessions
was not entirely convincing.....

there is, however, another approach: change the queueing in the
routers (options exist for this...though the usual "doesn't run aboive
2Mbps in a cisco yet" limitation may stop this for a while....but not
long)......

the acronym RED springs to mind....(which maybe does run at speeds in
high end routers...anyone at cisco comment?)

 jon

---

From: Per Gregers Bilse <[email-masked]>
Date: Wed, 12 Feb 1997 16:54:20 +0100

[Hi Tim, I trust you're the Tim Dorcey I had vigorous discussions
with a couple of years go.-]

> they did to make that happen.  (Doctor, it hurts when I try to fit 40kbps

No, they don't stop.  Typical hobby users find choppy, poor quality
Internet video absolutely fascinating, and certainly more interesting
than no video.  I've seen it dozens of times -- 500+ kbps being
hurled at a 14.4 kbps modem, and the user going "great, fantastic,
marvellous, wonderful".

And even if they did stop after a few attempts, there's 10-25k new
users on the Net every day.

-- 
------ ___                        --- Per G. Bilse, Mgr Network Operations
----- /     /  /   __   ___  _/_ ---- EUnet Communications Services B.V.
---- /---  /  /  /  /  /__/  /  ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___  /__/  /  /  /__   /  ------ tel: +31 20 5305333, fax: +31 20 6224657
---                           ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net  e-mail: [email-masked]

---

From: Mark Boolootian <[email-masked]>
Date: Wed, 12 Feb 1997 11:26:35 -0800 (PST)

>kernel, outside the winsock.dll, outside the mac os......

That problem exists for unicast as well as multicast and (this) one wonders
about what contribution to congestion all the great unicast streaming 
applications out there now are making.

---

From: Petri Helenius <[email-masked]>
Date: Wed, 12 Feb 1997 23:09:07 +0200 (EET)

> applications out there now are making.
Somebody should put an analyzer (if somebody hasn't already done that)
to the MAE-E and see what familiar port numbers used by these
'streamers' come up.

Pete