Subject: [Sip] multicast restricted to ttl=1

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Feb 2002 14:08:59 -0500

Folks,

As a result of IESG review, there were concerns about the multicast
usage of SIP. In particular, for the things we were using it for, it was
felt that a limitation of scope to ttl=1 was needed. As such, I have
modified the transport chapter to reflect a SHOULD level usage of ttl=1. 

Comments or questions welcome.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 21 Feb 2002 23:05:44 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Sunday, February 17, 2002 2:09 PM
> To: [email-masked]
> Subject: [Sip] multicast restricted to ttl=1
> 
> 
> Folks,
> 
> As a result of IESG review, there were concerns about the 
> multicast usage of SIP. In particular, for the things we were 
> using it for, it was felt that a limitation of scope to ttl=1 
> was needed. As such, I have modified the transport chapter to 
> reflect a SHOULD level usage of ttl=1. 
>
Well, according to bis-08, multicast can be used to find a registrar if
you don't have a DNS-discoverable proxy to route your register to. If
that's the purpose, what leads one to believe that the registrar is
likely to be on your local subnet?

Seems if multicast for regisration is useful at all, it makes more sense
for the discovery to either be via expanding ring broadcast and/or an
admin-scoped group.

BTW: bis-08 does not prohibit multicasting INVITES, which is equally
useful (which could be to say not very...) as multicasting
registrations, for completely infrastructure-less small configurations.
The same question about single-hop applies.

What am I missing? If I'm not missing anything and the SHOULD is an
attempt balance utility against danger, I'm not sure the balance is
right, since violating a SHOULD makes you only conditionally compliant,
whereas I can think of quite a few configurations which are small enough
to want to use this (e.g. for minimal functioality when your
proxy/registrar is pooched) yet span more than one subnet.

Does an admin scope on the multicast strike a better balance?

I don't feel strongly about this, BTW.

Dave.

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2002 03:40:09 -0500

> likely to be on your local subnet?

Well, more like, if its not on your subnet, multicast register is going
to have some problems.

> for the discovery to either be via expanding ring broadcast and/or an

Without proper response suppression, reliability, and other multicast
specific capabilities, we cannot do this properly. If there is
sufficient interest, an extension can be defined to do this.

> The same question about single-hop applies.

Same answer.

> proxy/registrar is pooched) yet span more than one subnet.

It is an attempt to balance utility against danger. Unfortunately, SIPs
processing at the higher layers is strongly based on a single non-2xx
response per request, an assumed invariant that is false as a result of
multicast. As such, we are not going to properly process the other
responses, leaving transactions hanging, and so on. We also have no
response suppression mechanisms. As such, use of multicast except in the
most limited confines and use cases is both dangerous and moderately
broken. However, enough people whined when I proposed to remove it
entirely, that it remains in this more limited form.

-Jonathan R.

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 27 Feb 2002 07:08:17 -0500

> Sent: Wednesday, February 27, 2002 3:40 AM
> To: David R. Oran
> Cc: [email-masked]
> Subject: Re: [Sip] multicast restricted to ttl=1
> 
> 
> 
> 
> "David R. Oran" wrote:
> > 
> > > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > > Jonathan Rosenberg
> multicast 
> > > usage of SIP. In particular, for the things we were using 
> it for, it 
> > > was felt that a limitation of scope to ttl=1 was needed. 
> As such, I 
> > > have modified the transport chapter to reflect a SHOULD 
> level usage 
> > > of ttl=1.
> > >
> > Well, according to bis-08, multicast can be used to find a 
> registrar 
> > if you don't have a DNS-discoverable proxy to route your 
> register to. 
> > If that's the purpose, what leads one to believe that the 
> registrar is 
> Well, more like, if its not on your subnet, multicast 
> register is going to have some problems.
>
The only thing that matters is the total receiver population. 4000
phones (or proxies or registrars) on one subnet is worse than 200 phones
on five subnets. What am I missing?

> > 
> > Seems if multicast for regisration is useful at all, it makes more 
> > sense for the discovery to either be via expanding ring broadcast 
> > and/or an admin-scoped group.
> 
> Without proper response suppression, reliability, and other 
> multicast specific capabilities, we cannot do this properly. 
> If there is sufficient interest, an extension can be defined 
> to do this.
>
It isn't clear you can do this "properly" even with these mechanisms.
The fact is, in a properly configured system there will be only one or a
few respondents, and in a misconfigured system even implosion control
will likely be ineffective.

> > registrations, for completely infrastructure-less small 
> > configurations. The same question about single-hop applies.
> 
> Same answer.
> 
> > 
> > right, since violating a SHOULD makes you only conditionally 
> > compliant, whereas I can think of quite a few 
> configurations which are 
> > small enough to want to use this (e.g. for minimal 
> functioality when 
> > your proxy/registrar is pooched) yet span more than one subnet.
> 
> It is an attempt to balance utility against danger. 
> Unfortunately, SIPs processing at the higher layers is 
> strongly based on a single non-2xx response per request, an 
> assumed invariant that is false as a result of multicast. As 
> such, we are not going to properly process the other 
> responses, leaving transactions hanging, and so on. We also 
> have no response suppression mechanisms. As such, use of 
> multicast except in the most limited confines and use cases 
> is both dangerous and moderately broken. However, enough 
> people whined when I proposed to remove it entirely, that it 
> remains in this more limited form.
> 
OK, then leaving it in is silly. Take it out. The ttl=1 piece is a red
herring.

Dave.