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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 00:39:56 -0400

Old thread, but we need resolution of it, and I have a proposal. Comments
inline.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2001 10:54 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [Sip] Open Issue #72: CANCEL for multicast
> 
> 
> > 
> > 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.

Well, you can't guarantee correctness in this case, which seems problematic.
If you have only three registrars, it seems an awful lot easier and more
robust to simply do a unicast fork to each of them.

> > 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.
> 
> That's one approach, which assumes that there is a shared traditional
> database. With in-memory databases, that's not nearly as easy.

There are certainly solutions for that as well, which support in memory
replication of data amongst a set of servers (i.e., TimesTen for example).
Anyway, we are getting off track. My point was only that multicast is not a
useful substitute for database replication protocols, which is what they are
being used for here.

> > 
> > 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.
> 
> 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.
> 

I would not mind keeping it, if it weren't for the fact that so many things
just break, or have to be declared as exceptions. For example:

1. response suppression, and even worse, the suppression is code specific
2. rules for matching responses to transactions don't work, since the via
header is the same for each multicast recipient. Thus, there will often NOT
be a way to disambiguate final responses from different recipients
3. request retransmission rules are different
4. proxy state machinery is different; since you don't know when you've
gotten all responses, you have no way to know if its safe to forward a
non-2xx upstream

The result is that multicast is hard to implement, because exceptions for
handling it are pervasive and significant. It is particularly problematic in
bis-05, where we have taken a more layered approach to the protocol.
Multicast introduces changes in all layers. Ideally, proxy processing should
not depend on transport level issues, and that is completely true EXCEPT for
multicast. 

So, my proposal is a compromise:

Multicast remains, but its behavior is NO different than unicast at all
layers of the protocol except transport (i.e., you expect the response via
multicast). That is, when a client sends a multicast request, it expects,
for non-invite, a single response. Any others would be discarded as
retransmits, even if the code is different, or the tag is different. You
stop retransmitting after the first response. There is no response
suppression. In other words, protocol behavior treats multicast more like
anycast, so that it assumes a single recipient, and treats responses as if
that were the case.

This means that a client sending a multicast register to a single registrar
will work just fine. However, using multicast registers to replicate data
across a set of registrars will not work under any packet loss greater than
zero, but will work properly with zero packet loss.

The limitations will need to be documented, of course.

How is that?

-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