Subject: Sdr advertisement problem . . .(follow-up)

From: Deb Agarwal <[email-masked]>
Date: Fri, 18 Sep 1998 16:22:53 -0700

Hi all,

Just to update you on the problem.  My sdr advertisement now
seems to be getting out to everyone again.  This time the
problem appears to have been a misconfigured router in the
vBNS.  Thanks to all who sent mtraces so that we could pinpoint
the router that was pruning.

We have in the past had the same sap.mcast.net blackhole effect
caused by routers that were not misconfigured and been able to
simply HUP the router and get rid of the problem. As the
multicast routing is moved into the production routers this solution
will be less viable and we need to determine why the routers decide to
blackhole the traffic in the first place.

Thanks again for everyone's help.  I am encouraged to hear from
several people that they are building or have built tools to help
in tracing these problems.

Deb
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Deb Agarwal                                  e-mail:[email-masked]
MS50B-2239                                   phone :(510)486-7078
Lawrence Berkeley National Lab  
Berkeley, CA 94720
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Mark Handley <[email-masked]>
Date: Sat, 19 Sep 1998 18:23:47 -0400

>blackhole the traffic in the first place.

Cisco routers are capable of listening to SAP to provide information
about multicast sessions.  We've seen cases for at least a couple of
years where SAP packets can loop but no other groups loop - the
culprit appears to be a cisco bug related to listening to SAP on the
router itself.  I saw packets looping on session annoucements from
within cisco when I looked a couple of minutes ago, so the bug still
appears to exist in whatever release of IOS that Cisco use themselves.

Anyway, it wouldn't surprise me if there's a similar condition where
SAP packets get blackholed.  

Also as far as I can tell, MSDP is designed to blackhole SAP packets
(and other bursty sources) unless you enable data encapsulation (which
is optional) so don't expect this to get any better in the near
future.

Cheers,
	Mark

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 09:18:21 -0700 (PDT)

>> is optional) so don't expect this to get any better in the near

    This is not true Mark.

Dino

---

From: Dennis Ferguson <[email-masked]>
Date: Mon, 21 Sep 1998 13:12:05 -0700

Dino,

> >> is optional) so don't expect this to get any better in the near

I'm curious.  Which part of the sentence isn't true?

Dennis

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 13:09:51 -0700 (PDT)

>> I'm curious.  Which part of the sentence isn't true?

    Multiple parts:

    1) the optional reference (the spec says an SA message may contain
       multicast data).
    2) "so don't expect this to get any better in the near future" (our
       implementation does do encapsulation).

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 21 Sep 1998 17:46:49 -0400

>       implementation does do encapsulation).

What method does one use to determine if a source is bursty or not?

A simple one that works is:

1. Assume all sources are bursty
2. See #1.

Another method (slightly more complicated) is:

1. Assume all sources are bursty until the MSDP peer tells you otherwise

The problem with this method is MSDP includes no method for the latter.
So it reduces to the first case.

Yet another method:

1. Assume all sources are bursty until a rate controlled threshold is
   reached on the encapsulating MSDP peer.

At first glance, this appears to work, although the rate is controlled
by the encapsulator and not the decapsulator.

I can also think of methods that don't work. One example is:

1. Preconfigure a list of known to be bursty groups (224.2.127.254, etc.)
2. Encapsulate known bursty groups and suppress all others.

Obviously, this is a bad idea since the list will always be changing.

If encapsulation is not optional, will the issue of determining when a
source is bursty be discussed in the spec?

Also, I will plead one last time for "PIM register encapsulation" instead
of TCP. By the quotes, I mean same semantics as MSDP, just different bits
on the wire. (i.e. not always including the data, possibly even defining
a new bit in the register header to signify the difference).
I know we've discussed this before but I don't think you understand
the problem.
Forwarding data through the routing protocol just tears me up... ;-)

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 15:02:45 -0700 (PDT)

>> What method does one use to determine if a source is bursty or not?

    There isn't one, unfortunately unless you want to use RSVP Path messages.

>> Yet another method:

    How about an even simpler method. Encapsulate the first packet only, that
    is only when (S,G) is created in the RP of the source domain.

>> source is bursty be discussed in the spec?

    Probably not.

>> 2. Encapsulate known bursty groups and suppress all others.

    Agree. Even though many operators wanted this.

>> of TCP. By the quotes, I mean same semantics as MSDP, just different bits

    This isn't flexible enough. Here are the problems with PIM registers
    across domains:

    o You have to know *all* RPs. This isn't the case with MSDP. In fact,
      MSDP allows you to aggregate other MSDP connections.
    o Receiving Registers (from the PIM spec) imply you may create source
      state, this is undesirable if a domain doesn't have members for that
      group.
    o Receiving Registers may imply sending Register-Stops. You don't want
      an implosions of Register-Stops to come back to the Register source.

>> I know we've discussed this before but I don't think you understand

    I don't understand the proposed solution because it wasn't explained
    in enough detail to make sense.

>> Forwarding data through the routing protocol just tears me up... ;-)

    PIM is forwarding through the routing protocol. So what. The only other
    way to skin this cat is to have the source advertise it is going to
    send data. Architecturally, it is more elegant so the multicast routers
    don't have to guess about sources and their rate when data is upon them.

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 21 Sep 1998 18:18:29 -0400

>    is only when (S,G) is created in the RP of the source domain.

And subsequent packets get dropped on the floor until the state times out?

>      an implosions of Register-Stops to come back to the Register source.

I believe you can use the packet format of registers without carrying along
the way they are currently used. Instead, just send NULL registers to the
same MSDP peers you would send SA messages to. If you have a bursty source
that you would encapsulate over TCP, encapsulate it instead in a PIM register.
Define a new bit (external) in the PIM register header to say, treat these
registers different than normal registers. Then the packets go to the exact
same "peers" as with MSDP but the only difference is the packet format.
This gets around using TCP for data encapsulation.

>    don't have to guess about sources and their rate when data is upon them.

In theory, yes. In practice, no. The header is straight forward and
it is possible to encapsulate/decapsulate outside of the protocol.
With TCP, this is no longer possible.

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 15:31:18 -0700 (PDT)

>> And subsequent packets get dropped on the floor until the state times out?

    No, subsequent packets are forwarded natively as joins come in. This is
    a first stab solution for the existing bursty sources we know of today
    (SAP and RTCP, both 1-packet sources with minutes between transmissions).

>> the way they are currently used. Instead, just send NULL registers to the

    Then you muddy up PIM.

>> This gets around using TCP for data encapsulation.

    I don't see how this makes "things" better. You have to process the SA
    message anyways, so why not append data to it. You have to propagate
    the SA message to other MSDP peers, so why not append data with it. You get
    all the MSDP filtering capabilities without having to put in special 
    filters into PIM for this. 

    Tom, we want to keep this protocol 1) separate, 2) lightweight, 3) and
    simple to implement. By having it separate, you can remove it with
    configuration and use PIM proper without having all this inter-domain
    baggage inside of it.
     
>> With TCP, this is no longer possible.

    You missed my point, we encapsulate data inside of PIM, so asserting that
    it's wrong for MSDP isn't a strong argument. The encapsulation is done
    inside of MSDP because that is the time the source's are advertised (when
    the data arrives).

    You'd have to advertise the source anyways, why not put both the identity
    information and data together. It sounds obvious to me.

Dino

---

From: David Meyer <[email-masked]>
Date: Mon, 21 Sep 1998 16:25:24 -0700 (PDT)

Tom,

> I know we've discussed this before but I don't think you understand

	Tom, to do this you have to reinvent MSDP (i.e., you 
	don't win anything). For example, you have to know where
	the peers are, you have to know if the register is
	internal or external (don't want to create (S,G)
	state on "external register"), have to stop "inter-domain"
	registers from looping, and you have to find a way
	to handle bursty sources (PIM Register semantics don't
	help here; don't know how to stop, you're in the control 
	(not data) plane, like PIM register stops are, etc).

	Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Sep 1998 19:50:56 -0400 (EDT)

>     is only when (S,G) is created in the RP of the source domain.

I think that would be broken on two accounts:
1) It assumes that a burst consists of only one packet,
   and loses all the other packets sent in the burst.
2) It isn't robust, since a domain coming up after the first
   packet never sees any data.

If you do the simple thing Tom suggested, and encapsulate all data packets
from all sources, then you have a "broadcast-and-don't-prune" protocol
between RPs, which I'm not sure why anyone would want to deploy.  You do, 
however, at least have connectivity, which appears to be more useful than 
encapsulating only the first packet.

-Dave

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 17:05:58 -0700 (PDT)

>>    and loses all the other packets sent in the burst.

    For now, it is sufficient. For bursty multi-packet sources, one could
    monitor the behavior (the RP in the source domain) of the source and
    tell other domains in a *new* MSDP message what the rate is and inter
    packet delay is of the bursty source. In this case, PIM Join messages 
    traveling inter-domain can increase their holdtime. This would suffice 
    for longer-lived, multi-packet bursty sources.

    This mechanism could also be used for short-lived, single packet sources
    where you can tell downstream domains to not create any state. SAP is
    a good example here.

    In fact, SAP in MSDP (in TCP) provides better reliability of those single
    packet sources.

>>    packet never sees any data.

    It will see the packet the next time the source transmits (via 
    encapsulation). That is for single-packet bursty sources.

>> encapsulating only the first packet.

    This will never fly. And I'm not sure Tom was suggesting exactly this. I
    think he wanted to use the Register-Stop mechanism in PIM too. He can
    correct me if I mis-represented him.

Dino

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Sep 1998 20:20:03 -0400 (EDT)

>     For now, it is sufficient. 

I'm not convinced.  Aren't apps like wb, vat during an online meeting,
nte, etc multi-packet bursty sources?

> For bursty multi-packet sources, one could

Maybe.  But the current MSDP doesn't have this.

>     encapsulation). That is for single-packet bursty sources.

What about for non-bursty soures?  Wouldn't video have a "non-bursty
source problem"?

>     This will never fly. 

Completely agree.

>     And I'm not sure Tom was suggesting exactly this. I

Dave

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Sep 1998 17:30:36 -0700 (PDT)

>> nte, etc multi-packet bursty sources?

    State for those sources stay around for the life of the conference. If 
    a late joiner in another domain comes into a vat group, it knows that
    a source that now has gone silent is active (from a routing perspective
    due to RTCP) so it will join all sources that are active.

>> Maybe.  But the current MSDP doesn't have this.

    Right, in time it may as the *real* requirement demands it. That is to
    say, that we have thought about it and are not calling it a non-problem.

>> What about for non-bursty soures?  Wouldn't video have a "non-bursty

    For a non-bursty source (i.e. a constant source), the (S,G) entry stays
    active on the existing distribution tree (which includes the RP in the
    source domain), therefore the RP continues to advertise the source in
    MSDP.

Dino

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 21 Sep 1998 21:21:17 -0400

Yes, I was being sarcastic. This is a bad thing.

Thanks anyway.

Tom

---

From: Stephen Casner <[email-masked]>
Date: Wed, 23 Sep 1998 00:23:09 -0700 (Pacific Daylight Time)

>     (SAP and RTCP, both 1-packet sources with minutes between transmissions).

Just a minor clarification:  The interval for SAP is in minutes, but the
interval for RTCP is seconds (typically 5, increasing as the number of
participants increases).
							-- Steve

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 23 Sep 1998 10:17:53 -0700 (PDT)

>> interval for RTCP is seconds (typically 5, increasing as the number of

    But what's more important is that they are *single* packet bursts.

Dino