Subject: mboned: draft-lehtonen-mboned-dynssm-req

From: Hoerdt Mickael <[email-masked]>
Date: Fri, 10 Jun 2005 11:41:34 +0200

Hello,

With Stig and Rami, a draft has been presented to the mboned at the
last 62th IETF in Minneapolis. This draft discuss about the requirements
needed
for a general source specific multicast service and the application
range scope where
it could be used.

During the session, it seems that good comments where raised about this
work, but there where no reaction on the mailing list, so I start a
thread on it. The draft can
be read on line at :

http://ietfreport.isoc.org/idref/draft-lehtonen-mboned-dynssm-req/

What do you think of this work ? Do you think that a general SSM source
discovery
layer have to be studied or it is better for developpers to write their
own ?

Another question :

Last experiments on the IPv6 multicast enabled showed that the time to
construct a multicast branch is very high (about 900ms-1s for the
PIM-JOIN message to reach hop
by hop some source, traversing 8 hops). Experiments on the mbone IPv4
network showed similar results, do someone have an idea why it takes to
much time (thats
about 100ms per hop, which is a geologic time in current networks), is
there something
in the PIM specification or is it implementation related ?

Cheers,

Hoerdt Mickaël

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 10 Jun 2005 10:09:29 -0700

>in the PIM specification or is it implementation related ?

This seems high to me as well. But core router implementations have
to balance fast joins with DOS attacks and large numbers of joins
(100k) so its possible that default throttling is affecting you.

An mtrace would be interesting...

As far as the SSM stuff, I'm not ignoring that part of the message
but I'll have to read the draft again first.

Thanks,
Tom

---

From: Hoerdt Mickael <[email-masked]>
Date: Fri, 10 Jun 2005 19:40:21 +0200

I don't understand how it can be related to DOS (or DDOS) attacks. If
someone manage
to join 100k channels, how the fact that the join are delayed will
protect the network
from being DOSed ? These channels will be automatically created, sooner
(1ms) or
later (100ms), and it can be very difficult to know if it's a DDOS or not.

But yes maybe the default time scheduler of PIM implementation is high
to allow PIM Join aggregation and preserve ressources, but aggregation
could be done later, after having sent the first Join.... So the
explanation is still unclear for me.

Also, knowing that the hop by hop join propagation time can be very
high, I am wondering how it can affect the PIM-SM architecture state
scalability. If it takes one
seconds for PIM to join a source specific tree, what will do the RP
during that time, especially if the agregate of sources are sending at
high rate ? aren't the source specific join there to preserve ressources
on the RP ?

Related to this, there is something not clear for me : a PIM-RP is there
for source
discovery inside an ASM/IP session. What happen if a new receiver join
the session and that all other DR's switched to the SPT. when the RP
receive the (*,G) join coming from the new receiver, will it join all
the sources in the session again to permit the DR of  the
new receiver to discover the sources or ? Would it mean that a RP have
to discover
all the source for all the groups that it supports and that periodically
it would have to
support all the sources from all the groups that it support too to
discover them ?

If someone could point me out on the spec about this, thanks.

Hoerdt Mickaël

Hoerdt Mickaël

---

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Jun 2005 13:01:59 +0200

On Fri, Jun 10, 2005 at 07:40:21PM +0200, Hoerdt Mickael wrote:
[...]
> the sources in the session again to permit the DR of  the

If you implement just what the spec says, then I believe what happens is
that no register stop is sent next time the DR sends a register, and
hence the RP will start receiving. But this might take up to 65s with
the default values I think.

What I have seen in practise though, is that the RP does join towards
the sources. I think that is reasonable, but I can't see anything in
the PIM spec that states or leads to this behaviour.

I would also like to know if there is something I have missed, or if
there are differences in behaviour between implementations.

If the last-hop routers immediately switch to SPT, then a consequence
of this I suppose is that you get lots of state changes in many routers
over a short time.

The different trees constructed and removed are:

1. RPT from last-hop to RP
2. SPT from RP to first-hop
3. SPT from last-hop to first-hop
4. prune S from RPT
5. prune SPT from RP to first-hop

A theoretical way of improving this would be to do something like

1. RPT from last-hop to RP
2. RP signals down the RPT who the sources are, but not actual data
	It knows the sources but doesn't receive data from them
	This would be slightly similar to the null-registers...
3. SPT from last-hop to first-hop
4. prune S from RPT

You would avoid building and removing the SPT from RP to first-hop
then.

> support all the sources from all the groups that it support too to

Not sure what you're saying here. But the RP is aware of the sources
all the time. DRs periodically send registers for the active sources
and this maintains the info at the RP.

Stig