Subject: RE: [Sip] Some comments on GRUUs

From: "Dale Worley" <[email-masked]>
Date: Fri, 1 Jul 2005 15:47:39 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
>
> The draft I was thinking of is draft-jennings-sipping-outbound-01.txt.
> It allows multiple registrations with the same instance id, but
> distinguished by a unique flow id. Only one registration per
> instanceid/flowid pair is permitted.
>
> This doesn't explicitly address GRUU, but the gruu mechanism should work
> with it - the same gruu would be assigned as long as the instanceid
> remains the same. In this draft you wouldn't be registering multiple
> contacts in the same REGISTER call, since the point is to
> send them over different paths.

Well, I was thinking of how we could allow multiple contacts for a GRUU in a
manner that was as close as possible to draft-ietf-sip-gruu-03.  The draft
is keen on two points:  1) a GRUU corresponds to an instance-ID and an AOR,
and 2) a GRUU has exactly one contact.  The more I think about it, the more
I like (1) and the less I like (2).  It seems to me that contacts could be
connected to GRUUs as dynamically as they are connected to AORs.  As I said
before, that does not present the proxy with any routing problem that it
does not already know how to solve.

And now draft-jennings-sipping-outbound shows another situation where having
only one contact for a GRUU is not what we really want.

Dale

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Jul 2005 17:49:05 -0400

> only one contact for a GRUU is not what we really want.

I think we are really on the same page here.

Maybe -outbound- isn't so clear, but I believe that if both it and gruu 
are in use then it requires that gruu allow multiple contacts for the 
same instance id, which an extension to the gruu spec. Instead of 
allowing only one contact per instance id, it only allows one per each 
instanceid/flowid pair.

Were that all agreed to, you could achieve what you want by simply doing 
one registration with two contacts, which have a common instanceid but 
different flowids.

In outbound, one purpose of flowid is to distinguish intentional 
registration of another contact to the same instance id from a 
registration of a replacement contact to that instance id. This is what 
would be exploited for your case. In principle this isn't needed in the 
case of a single registration. If one register request contains two 
contacts with the same instanceid, one can presume that one is not 
intended to supercede the other without any further hints. So 
conceivably the rules could be relaxed to not requie flowid in this case.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 5 Jul 2005 12:18:42 -0400

> conceivably the rules could be relaxed to not requie flowid

As I see it, the concept that there should only be one contact for a given
GRUU is of little value.  At worst, it means that a request to the GRUU
forks, but then both sides of the fork (if they both get through) go to the
same device, which can select which of them it wishes to answer.  And in
general, if one contact is to supercede another, the UA should be cancelling
the registration for the old contact, which will automatically remove it as
a contact for the GRUU.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jul 2005 13:00:01 -0400

Dale Worley wrote:
> GRUU is of little value. 

I think it has been recognized that there indeed can be multiple 
contacts for a GRUU. But this is semantically different from different 
contacts for an AoR. With an AoR the assumption is that the different 
contacts represent distinct alternative UAs. With a GRUU the assumption 
is that the GRUU represents a single UA and that multiple contacts 
represent different ways of reaching it.

The rest of the stuff around this is a matter of how to manage all this 
in some kind of coherent way, and preserve the above semantics. And so 
far the attempt has been to manage this using just the REGISTER request. 
(An unexplored alternative would be to use different requests to manage 
these two concepts.)

> At worst, it means that a request to the GRUU
> same device, which can select which of them it wishes to answer. 

I believe the assumption has been that because these are alternative 
paths to the same destination, that they should be tried serially, and a 
subsequent one only tried if the first one failed in a way that is 
consistent with loss of connectivity.

I suppose one could argue with that philosopy.

> And in

In general that would be the goal. But failure scenarios may result in 
that not happening. E.g. a device reboots and gets a different ip 
address assigned to it. It doesn't remember the one it had before reboot.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jul 2005 02:14:07 -0400

inline.

> As I see it, the concept that there should only be one contact for a given

There is a lot of value when the client is not trying to have redundant 
paths to reach the same instance, which is the only case when you really 
want multiple contacts for the same gruu. For this reason, the 
multiple-contacts thing is being handled in the sipping-outbound draft.

Now, the problem is, as you point out, that draft-ietf-sip-gruu is 
fairly dogmatic about a single contact per gruu, when we know we are 
about to modify that behavior in the sipping-outbound draft. One of the 
changes I am making in the next revision of gruu is to add some weasel 
words that open the door for a future spec to define a case where 
multiple contacts would be permitted.

> the registration for the old contact, which will automatically remove it as

That was the initial design. The problem it had was a terrible 
amplification of avalanche restart load. If a bunch of clients restart 
due to a restoration of power after an outage, you have at least a 
doubleing of the number of registration transactions that need to be 
processed. In the initial design, where the registrar prohibited 
multiple registered contacts with the same instance ID, it took four 
transactions:

1. initial registration that fails
2. query registration to learn existing contacts
3. registration to remove the exsiting contact
4. registration to add the new one

if you allow multiple contacts with the same instance ID to register, 
you can reduce that to two:

1. initial registration, response indicates multiple contacts with the 
same instance ID
2. second registration to remove the old one

The avalanche restart was considered sufficiently nasty that it was 
worthwhile to have this enforcement about a single contact for a 
particular instance ID, which we'll relax somewhat with 
sipping-outbound, but all that does is add an additional parameter to 
the uniqueness key - the flow ID. Same basic idea though - you can only 
have one contact for a specific flowID/instanceID, and if you register a 
second one it actually clobbers the first. That behavior gets you the 
benefits of multiple contacts without the avalanche restart consequences.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com