Subject: RE: [Sip] Open Issue #72: CANCEL for multicast

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 01:28:42 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 9:42 PM
> To: Howard Hart
> Cc: [email-masked]'
> Subject: Re: [Sip] Open Issue #72: CANCEL for multicast
> 
> 
> Howard Hart wrote:
> > 
> > Make that two opposed, though not vehemently in our case. Multicast
> > registration has worked fine for us for a while--I'd hate 
> to lose it.
> > Anyone for deprecate Multicast with the exception of 
> REGISTERs, or should I
> > say, is anyone using Multicast with any SIP method other 
> than REGISTER?
> > 
> 
> Plus, multicast is nice to have for updating several 
> registrars at once,
> scalably.

I just don't see how this works under any amount of packet loss.

Lets say there are three registrars. A UAC sends a multicast REGISTER, which
is received by two of the three. The UAC will get two 200 OK. According to
the spec, it now stops retransmitting the request, since it got a 200 OK.
But, since the third registrar never got the request, the registration is
not updated there.

To fix that, we'd have to basically retransmit continously for a while,
independent of any responses, in the hopes that we hit every registrar. The
client has no way to know if this succeeds. It results in lots of network
traffic, probably much less traffic than just sending three separate unicast
transactions. It also introduces another transaction model.

To be honest, if you want to establish registration state at multiple
servers, you are much better off using time tested and well understood
database replication protocols in the back end between the servers.

> 
> Another reason for keeping this is that multicast REGISTER can be
> programmed to avoid the "reboot building" problem of 20,000 phones all
> registering more or less at the same time when the power 
> comes back on.
> We haven't pursued this, but it would be easy (as an implementation
> choice) to implement a form of RTCP reconsideration that causes phones
> to back off when they see lots of other registrations, rather than
> causing the poor registrar to drop almost all registrations. 
> I wouldn't
> be surprised if, just like RTCP, somebody eventually calls us on this
> problem. (Not that other protocols, such as DHCP, don't have the same
> problem...)

I'll note that this still remains a problem in theory only for RTCP.

> 
> For non-REGISTER: I wonder if there is a need/use for 'non-confirmed'
> requests, e.g., notifications that are meant for a large 
> group, but with
> no need for reliability. This would address some of the concerns in
> terms of response implosion. Beyond unreliable notifications, once we
> have a reliable multicast infrastructure in place, there may well be
> other applications where the current concerns don't apply. It 
> should be
> noted that many other event systems have this mode, as it is much more
> scalable than individual event notification. I would hate to have this
> ruled impermissible. Since SIP, being transport-neutral, 
> should be able
> to make use of reliable multicast transport, it would seem 
> short-sighted
> to rule this out of scope completely.

The primary issue is that as specified, multicast operation just doesn't
work under anything but perfect conditions. So, it either needs to be fixed,
or if it can't be fixed and there are other ways to achieve the same ends,
it has to go. I don't want to be adding things, I want to be removing them.

-Jonathan R.

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

_______________________________________________
Sip mailing list  http://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: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Sep 2001 22:54:04 -0400

> I just don't see how this works under any amount of packet loss.

My model is somewhat different: A proxy fronts three registrars, which
back up each other, but are on a local network in close proximity to the
proxy server. In that case, packet loss is very unlikely, but
replication is very efficient and easy to implement.

> database replication protocols in the back end between the servers.

That's one approach, which assumes that there is a shared traditional
database. With in-memory databases, that's not nearly as easy.

> I'll note that this still remains a problem in theory only for RTCP.

Unlike the RTCP problem, which assumes wildly popular and
start-time-synchronized multicast sessions we haven't exactly been
blessed with, power outages and synchronized restarts are at least
plausible, without changing the network.

> it has to go. I don't want to be adding things, I want to be removing them.

Agreed. However, as discussed, multicast addresses a number of problems
where other solutions may not exist (DHCP) or not be equivalent. The
complexity of this feature is extremely modest, so I don't see a large
gain in removing the feature, but I am afraid of removing a useful tool.
It's a separate issue as to whether it makes sense to split this off
into a separate draft, similar to the SCTP-as-transport draft. As is,
not every registrar supports it, so this would not seem to imperil
interoperability beyond the current state.