Subject: Re: mbone dvmrp/pim

From: Bill Fenner <[email-masked]>
Date: Thu, 18 Sep 1997 13:51:51 PDT

>I am not sure what you mean here, Steve. If traffic reaches stub LANs,
>prunes are sent right away and propagated upstream.

But prune propogation takes time, right?  Quoting from the PIM-DM spec:

     When a prune message is sent on an upstream LAN, ... the
     expected upstream router will schedule a deletion request
     of the LAN from its outgoing interfaces for the (S,G) entry
     from the prune list.  The suggested delay time before
     deletion should be more than 3 seconds.

So each hop takes "more than 3 seconds" to propogate the prune, while
DVMRP propogates prunes immediately.  I believe that is what Steve was
referring to.

  Bill

---

From: Manoj Leelanivas <[email-masked]>
Date: Thu, 18 Sep 1997 14:17:59 -0700 (PDT)

=>    
=>    >I am not sure what you mean here, Steve. If traffic reaches stub LANs,
=>    >prunes are sent right away and propagated upstream.
=>    
=>    But prune propogation takes time, right?  Quoting from the PIM-DM spec:
=>    
=>         When a prune message is sent on an upstream LAN, ... the
=>         expected upstream router will schedule a deletion request
=>         of the LAN from its outgoing interfaces for the (S,G) entry
=>         from the prune list.  The suggested delay time before
=>         deletion should be more than 3 seconds.
=>    
=>    So each hop takes "more than 3 seconds" to propogate the prune, while
=>    DVMRP propogates prunes immediately.  I believe that is what Steve was
=>    referring to.
=>  

This is true only during the first flood, if prune refreshes are used. I am
not sure if it is in the spec yet. Also, this is not an issue on p2p
links.

-Manoj

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Sep 1997 15:14:52 -0700 (PDT)

>> not sure if it is in the spec yet. Also, this is not an issue on p2p

    Prune refreshes are in a separate spec authored by:

Network Working Group                                        David Meyer
Internet Draft                                      University of Oregon
                                                      Sangeeta Mukherjee
                                                        Sun Microsystems
                                                           Kurt Windisch
                                                    University of Oregon

draft-meyer-pim-dm-prune-refresh-00.txt                   September 1997

                  Prune Refresh Extensions for PIM-DM

Dino

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 21 Sep 1997 23:19:24 +0100

>>> not sure if it is in the spec yet. Also, this is not an issue on p2p

in the absence of adaptive senders, or layered multi-channel
receviers, it seems to me that the video/audio e2e tools ought to have a
default behaviour that they leave a group/exit if the loss is aboove
some (settable) threshold......this is the nearest one could get to
saving naive, bandwidth impoverished users from themselves.....
in fact, a tool could even _force_ a prune, if so configured (e.g. for
home uses at end of isdn) and resend a few......i.e. a step fuction in
bandwidth is a better approximaion to tcp's slow start behaviour, than
just waiting for the user to make up their mind the quality isn't good
enuff.....

maybe....

j.

---

From: Petri Helenius <[email-masked]>
Date: Mon, 22 Sep 1997 08:50:58 +0300 (EEST)

> just waiting for the user to make up their mind the quality isn't good
This would effectively make troubleshooting bad network state very
hard, that is the case when there is not supposed to be high loss but
there is, since the clients would be hopping off the group all the
time.

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 22 Sep 1997 08:46:40 +0100

Pete

um,. well one could put some hysterisis (damping and hold down in routing terms)
so it didn't thrash.......

anyhow, if the bad state is _caused_ by people pulling down overload
on an impoversihed link, you'd want the problem to go away surely?

 jon

---

From: Petri Helenius <[email-masked]>
Date: Mon, 22 Sep 1997 11:14:54 +0300 (EEST)

> on an impoversihed link, you'd want the problem to go away surely?
If they screw only themselves, I don't really care, if they try to eat
excessive bandwidth on shared links, I'll do fancy queueing.

Pete

---

From: [email-masked] (Ran Atkinson)
Date: Mon, 22 Sep 1997 08:03:00 -0700

> on an impoversihed link, you'd want the problem to go away surely?

On Sep 22 11:14, Petri Helenius wrote:
% If they screw only themselves, I don't really care, if they try to eat
% excessive bandwidth on shared links, I'll do fancy queueing.

While fancy queuing (particularly WFQ in this case) is A Fine
Thing, I'd still prefer to additionally have a built-in mechanism
(as Jon suggests) that would tend to cause the problem to go away
on its own.

Such a mechanism would tend to help MBONE/IP-Multicast deployment,
not least because not everyone has fancy queuing available.  Also,
in situations where one's router is already fairly loaded, the
additional load caused by queuing/tossing the excessive multicast
traffic is undesirable.  Lack of congestion avoidance in multicast
sessions is one reason that some ISPs are reluctant to travel the
road of inter-domain multicast routing.  Intra-domain multicasting
is a rather different beast operationally.

Ran
[email-masked]

---

From: Petri Helenius <[email-masked]>
Date: Mon, 22 Sep 1997 18:50:24 +0300 (EEST)

> is a rather different beast operationally.
I've always thought that the above is an artifact of the fact that
there is no reasonably scalable and working inter-domain architechture
to be used in the first place, not that a group of users pulling down
megabits of data would be of great concern. (since they can do it
anyway, just with multicast it does less damage)

Pete

---

From: [email-masked] (Ran Atkinson)
Date: Mon, 22 Sep 1997 10:20:53 -0700

On Sep 22 18:50, Petri Helenius wrote:
} Subject: Re: mbone dvmrp/pim & congestion

% I've always thought that the above is an artifact of the fact that
% there is no reasonably scalable and working inter-domain architechture
% to be used in the first place, not that a group of users pulling down
% megabits of data would be of great concern. (since they can do it
% anyway, just with multicast it does less damage)

TCP sessions do MUCH less damage to the network infrastructure than
UDP sessions, because TCP includes congestion avoidance.  Multicast
necessarily uses UDP.  Until multicast sessions include some form
of reasonable congestion avoidance, there is good reason to fear
multicast traffic more than TCP-based unicast traffic.

Ran

---

From: Petri Helenius <[email-masked]>
Date: Mon, 22 Sep 1997 21:27:28 +0300 (EEST)

> multicast traffic more than TCP-based unicast traffic.
I wonder since when these Internet media applications which are
usually categorized "streaming media" have started using TCP?

Pete

---

From: [email-masked] (Ran Atkinson)
Date: Mon, 22 Sep 1997 13:14:06 -0700

On Sep 22 21:27, Petri Helenius wrote:

% I wonder since when these Internet media applications which are
% usually categorized "streaming media" have started using TCP?

There are a number of examples based on web technology or other
TCP-based technology.

Ran
[email-masked]

---

From: Petri Helenius <[email-masked]>
Date: Mon, 22 Sep 1997 23:33:53 +0300 (EEST)

> There are a number of examples based on web technology or other
I don't want to waste any more bandwidth on this but the truth is that
99% of 'streaming media' runs on UDP, regardless of the destination
address being unicast or multicast.

Pete

---

From: Steve Deering <[email-masked]>
Date: Mon, 22 Sep 1997 14:11:35 -0700

> address being unicast or multicast.

Most of the serious Internet Telephony apps are also UDP unicast, without
any congestion control.

Steve

---

From: k claffy <[email-masked]>
Date: Mon, 22 Sep 1997 17:25:52 -0700 (PDT)

Ran

hopefully it goes without saying that
you're talking about camelot TCP traffic
(well implemented slow start/back off,
conversations long enough to actually
make it into congestion control mode)

so even though 95ish% of WAN bytes
(85ish % of packets) are TCP,
the distribution of connection sizes
(in packets, bytes) 
and predominance of 40-byte critters
doesn't really give me a warm fuzzy
camelot congestion control kinda feelin

but maybe it's just me

k

---

From: "Heiko W. Rupp" <[email-masked]>
Date: Tue, 23 Sep 1997 10:18:08 +0200

> usually categorized "streaming media" have started using TCP?

Also TCP congestion avoidance is often levered out that multiple connections
are established in paralell (e.g. several Newsfeeds).

-- 
NTG Netzwerk und Telematic GmbH   /          Heiko W.Rupp
Geschaeftsbereich Xlink         \/           phone: +49 721 9652 0
Vincenz-Priessnitz-Str. 3       /\ link      fax:   +49 721 9652 210
D-76131 Karlsruhe, Germany     /_______      email: [email-masked]
[ NTG Netzwerk und Telematic GmbH, Sitz Chemnitz                          ]
[ Kreisgericht Chemnitz/Stadt HRB 4217, Geschaeftsfuehrer: Michael Rotert ]