Subject: Re: draft-ietf-pim-dm-new-v2-04.txt

From: Beau Williamson <[email-masked]>
Date: Wed, 01 Aug 2001 16:37:59 -0500

John,

Once again I think you and I are on the same wavelength.  I'd like to see MSNIP evolve into something more like the RTS/CTS mechanism that you describe with sufficient specifications as to how the first hop device (maybe a router or maybe a layer-3 aware switch) should handle this.

In addition, I'd like to see "receiver" admission control added if at all possible.  I'm not convinced that this would require a extension to IGMP or a new protocol and may actual fall into vendor specific features.  

In any case, the worries over DoS Attacks due to random sourcing and random joining (especially if SSM takes off) are real and are quickly becoming a barrier to multicast deployment.

Maybe this can be discussed at the MAGMA WG in London.  Unfortunately, I won't be there so I'm hoping you or someone else will carry the flag.  (At least initially.)

Beau
At 01:26 PM 7/31/2001, John Zwiebel wrote:
>Bryan Mclaughlin wrote:
>> 
>> This issue is addressed by Multicast Source Notification of Interest
>> Protocol (MSNIP)  for SM protocols,  isn't it ? What would need to be added
>> to make it work for DM?
>> 
>
>MSNIP does not do admission control.  It "kind of" does it, but
>there's nothing that prevents a source from dumping mpackets on to the
>LAN.
>And MSNIP does not specifically address what a router should do if
>it sees packets from a source that hasn't registered via MSNIP.
>(one could make the leap that in such a case the router could just
>bit bucket the data stream)
>
>The host (source) is still "in charge" and the network has to muddle
>through the best it can.  If a host is sending and there is no MSNIP
>available, there's nothing to stop it.
>
>The RTS/CTS process I'd like to see would make the network more 
>"superior" to the host and is quite a bit more complicated than what
>MSNIP is trying to provide.
>
>I guess this sentence from the MSNIP draft makes my point:
>
>     Hosts that wish to be managed by MSNIP periodically transmit an
>     Interest Solicitation message. This message is multicast with a
>group
>     destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) and is
>     transmitted every [Interest Solicitation Interval] seconds.  
>
>  -- MSNIP is IGMPv3 only
>  -- Hosts can arbitrarily decide to not be managed by MSNIP
>  -- MSNIP does not describe how to signal the "network" that the
>        source is about to send.
>
>This shouldn't be taken as a condemnation of MSNIP.  Its quite 
>possible my imagination just isn't strong enough to grasp the
>capabilities.  And what I think is needed may be way too complicated
>and contrary to the "spirit of the internet".

---

From: Brian Haberman <[email-masked]>
Date: Thu, 02 Aug 2001 07:31:27 -0400

John & Beau,
     Dave Thaler has requested some time in London to discuss MSNIP.
Specifically, what it does and does not do (especially in a zeroconf
environment).  We can evolve that to a meta discussion on MSNIP and
hopefully get some more interest in it than what we have had in the
past.

Regards,
Brian

John Zwiebel wrote:
> Beau Williamson wrote:
> FWIW: if we view the future to be SSM then MSNIP will be more than
> good enough.  The setup of a SSM multicast session will migrate out
> of the network so that the requirement to not drop packets will become
> an application problem.  (And, 2cents, MSNIP at that point could be
> viewed as superfluous from a network perspective.  Who cares if the
> source LAN alone is swamped.  This shouldn't be taken to mean that
> I believe MSNIP is not a good idea, its just an idea that I wouldn't
> care about.)
> 
> Folks who want to continue pushing SM/DM are the ones who'll need the
> greater admission control capability.  If we had just "KISSed" it in
> the beginning...
> 
> z
> _______________________________________________
> Magma mailing list
> [email-masked]
> http://www.innovationslab.net/mailman/listinfo/magma

---

From: Beau Williamson <[email-masked]>
Date: Thu, 02 Aug 2001 09:34:53 -0500

Brian,

Unfortunately, I wont be in London so I'll have to let someone else carry the torch at that meeting.

I don't agree that MSNIP is "good enough" and would like to see us extend IGMP to include the RTS/CTS mechanism that John Z. mentioned.  That would permit the first hope devices (switches?) to snoop only a single protocol for both senders and receivers.  We could make it such that sender admission control was something that could be enabled (or not) on a switch/router/first-hop device and that would permit one to still use the old "send in the blind" model defined in RFC 1112 (the "Multicast Dead Sea Scrolls").

Hopefully, the MAGMA session will be multicast and I can at least listen in on what is going on. 

Beau

---

From: Bryan Mclaughlin <[email-masked]>
Date: Thu, 02 Aug 2001 18:16:46 +0100

Beau,

My question is what does RTS/CTS stand for?

Ready to send/ clear to send  or  reason to send/ content to send?

I do not feel comfortable with a router having the power to 'enforce' 
quiescence on a host or am I just being a coward ;) Perhaps the ability to 
enable or not enable this feature would mitigate my concerns.

I agree that augmenting an existing deployed protocol, such as IGMP, with 
source communication abilities is a good idea.

Bryan

At 09:34 02/08/2001 -0500, Beau Williamson wrote:
>I don't agree that MSNIP is "good enough" and would like to see us extend 
>IGMP to include the RTS/CTS mechanism that John Z. mentioned.  That would 
>permit the first hope devices (switches?) to snoop only a single protocol 
>for both senders and receivers.  We could make it such that sender 
>admission control was something that could be enabled (or not) on a 
>switch/router/first-hop device and that would permit one to still use the 
>old "send in the blind" model defined in RFC 1112 (the "Multicast Dead Sea 
>Scrolls").
>
> >> > Once again I think you and I are on the same wavelength.  I'd like 
> to see MSNIP evolve into something more like the RTS/CTS mechanism that 
> you describe with sufficient specifications as to how the first hop 
> device (maybe a router or maybe a layer-3 aware switch) should handle this.
> >> >
> >>

---

From: Bryan Mclaughlin <[email-masked]>
Date: Fri, 03 Aug 2001 12:19:42 +0100

John

The RTS CTS questions was facetious. RTS CTS is part of v24/rs232 control 
where the DTE rts's and the  DCE CTS's i.e the DCE has control over when a 
DTE can start TXing.

My point being that in IP environment we do not(IMHO) want the DCE/router 
to have that amount of control. It(the router) can/should however inform 
the DTE/Host that there is a "reason" to send and dependent upon the 
network admin/application support we can use a MSNIP type protocol 
to  enable the DCE/router convey this "reason to send" to the host.  This 
'rts' would be sent  after the host/DTE also has used its the ability to 
indicate it has "Content to send" to DCE/router who has subsequently been 
able to determine if there are interested receivers in the Multicast network.

As you point out this could introduce a delay in the initialization of the 
session, which is why I belive the ability to use this on a per application 
as well as per network scenario is important.

Bryan

At 12:15 02/08/2001 -0700, John Zwiebel wrote:

>         Request to Send
>         Clear to Send
>Modem cable stuff -- right?
>
> >
>Don't configure it in your network.  :-)
>
>
>Multicast doesn't have a nice handshake like TCP to start a session.
>Customers (some customers anyway) insist that multicast not lose any
>data.  Expecting the network to be able to immediately set up a (S,G)
>route as soon as a source starts dumping data on to the LAN is never
>going to work.
>
>There are many, many, many alternatives.  And, IMHO, some of the
>best would be to let the application handle the problem.  But that
>may result in chaos if we ever get a multicast implementation that
>depends on many different vendors.  (implementation isn't the right
>word, but then neither is session, or protocol or capability.  Perhaps
>I mean service.)
>
>Video/audio doesn't care about the few lost packets at the beginning
>of a session.  Downloading data files (MFTP like) does.
>
>I'm not necessarily in favor of the IETF doing anything about this --
>including MSNIP.  Its a question that the Apps guys have to ask because
>the solution depends on what they want to do.
>
>What I do want to do is make sure that no one goes around thinking that
>if we follow Fenner's (et. al.) new spec to the letter that data won't
>be lost at session start up any longer.  I want to bring expectations
>down to a realistic level.  I want to start "KISSing" multicast so
>certain ISPs will stop complaining about how badly it destabilizes
>their network.  (Perhaps I should say, "can stop", after all they
>are just pointing out an unpleasent truth).
>
>Now, again, this shouldn't be taken to mean that I think the new PIM
>spec is useless or flawed or anything at all like that.  I'm constantly
>amazed by how complete it is.  It's just too bad its so hard to
>grasp.
>
>2cents.  I'll try to refrain from expressing any more political
>view points in this area now.  :-)

---

From: Beau Williamson <[email-masked]>
Date: Fri, 03 Aug 2001 11:28:26 -0500

>My question is what does RTS/CTS stand for?

Request-to-Send / Clear-to-Send

>I do not feel comfortable with a router having the power to 'enforce' quiescence on a host or am I just being a coward ;) Perhaps the ability to enable or not enable this feature would mitigate my concerns.

Yes, I think at least initially we have to have a way to enable/disable this function.  At least until the new sender model is implemented in the host stacks.

>I agree that augmenting an existing deployed protocol, such as IGMP, with source communication abilities is a good idea.
>
>Bryan
>
>
>

---

From: Bill Fenner <[email-masked]>
Date: Fri, 3 Aug 2001 14:53:34 -0700

>Multicast doesn't have a nice handshake like TCP to start a session.

Neither does IP.

>route as soon as a source starts dumping data on to the LAN is never

As you say, the right answer here is to
a) Set their expectations properly.
b) Design a protocol that meets their expectations.

The answer to "b" probably should not require any IP-level changes.

  Bill