Subject: Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

From: Aki Niemi <[email-masked]>
Date: Sun, 02 Mar 2008 15:42:04 +0200

On pe, 2008-02-29 at 22:08 -0500, ext [email-masked] wrote:
>    Then that's bad. How does the notifier then know which PIDF to pick in
>    presence subscriptions?
> 
> Especially if it's not a presence subscription.  But seriously, is
> this proposal confined to presence events?  I see no such text.

Of course it is not. But clearly presence won't work correctly, if the
notifier doesn't know which URIs route to it, i.e., which resources it
is responsible for. I assume this to be the case for most applications
of SIP events. Can you give an example of a currently specified event
package that doesn't require this?

> In general, a SUBSCRIBE will fork, and the subscriber presumably knows
> how it wants to integrate the events it will receive from the various
> subscriptions, based on the semantics of its situation.

Then presumably the semantics of the situation will also describe how
entity-tags are handled? Especially if they are not all of the same
value in the different dialogs.

>    I agree this kind of setup presents a problem. But I also think that
>    what we're dealing with here is not that different from the web world.
>    There are a lot of load balancing schemes that can be used with HTTP,
>    which result in a GET ending up in different data centers in different
>    parts of the world at different times.
> 
>    What's important to note there is that if the service that is accessed
>    via this GET needs sessions and gives out cookies, then the backend
>    system needs to be synchronized. Otherwise, the servers will be unaware
>    of each others cookies, and the service won't work correctly.
> 
>    Similarly, the backend to the SIP notifiers needs a synchronized
>    backend, otherwise, subnot-etags won't work.  Naturally, the etags just
>    like cookies can be constructed in such a way that they contain the
>    necessary state.
> 
> There's a hidden philosophical problem:  People think of SIP routing
> as being like PSTN routing, where the caller sends the call to a
> number which designates one destination, or at least, a single device
> which has total knowledge of a small number of possible destinations.
> The caller knows the globally-recongized *name* of the
> destination-group, and every destination knows of and is coordinated
> with *every other possible destination*.
> 
> Your HTTP model is similar; you assume the request will reach one of a
> set of servers that are co-adminstered.
> 
> But the reality is that SIP routing can be like sending e-mail to a
> mailing list -- the sender doesn't know what the possible destinations
> are, and each destination doesn't know what all the destinations are
> either, because some of the routing can be done by agents that are not
> co-administered with either the sender or the destination.

What you are saying is similar to having [email-masked] route to multiple
mailman instances, each of which has a different set of subscribed email
addresses. But that's not how mailing lists work either.

> Now I think the first case is more common, but if we are going to
> design a general mechanism, it should not fail badly in practice in
> the second case.

Can you give an example event package that would fail badly with
clashing entity-tags and (uncontrolled) forking?

> Getting back to possible solutions:
> 
> Looking at section 6.1, I see '[An entity-tag] can have any value,
> except for "*".'  (Let's correct that to 'An entity-tag can be any
> token, except for "*".')  We can dodge the problem of uncoordinated
> notifiers by demanding that entity-tags have some minimum amount of
> randomness.  E.g., if any group of coordinated notifiers picks a
> 64-bit random value, and the entity-tag is generated by making a
> 64-bit hash of that value with the event information, the chances of
> an etag-value collision in any single instance is 2^-64.

Your application of SIP events certainly can implement as much
randomness it wants. But it's hardly appropriate to require that of all
implementations of conditional notification.

For MWI, a timestamp seems sufficient; for conference events, a
monotonically increasing counter would probably work just fine. 

> One can easily encode a 64-bit value in 11 token characters using
> (modified) base64.  Compare that to the 5-character values used as
> examples in the I-D.  Though if we used 6 base64 characters, we would
> still have a 36-bit hash, which is probably good enough.

Were we to design some mandatory-to-implement entity-tag generation
algorithm, I'd much rather suggest salting the hash with appropriately
unique information, like the server IP address and a timestamp, rather
than just "randomness". But since we aren't, this (among many, many
others) is a valid way to generate entity-tags.

Cheers,
Aki

> Dale
> _______________________________________________
> Sip mailing list  https://www.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

_______________________________________________
Sip mailing list  https://www.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: Dean Willis <[email-masked]>
Date: Mon, 3 Mar 2008 09:42:39 -0600

> package that doesn't require this?

I have yet to figure out how a multiuser UA  (including an event  
server) is supposed to function if:

1) The To: field does not indicate the user being targeted, which  
happens if a UAC-side proxy retargets, as in the case of a speed-dial  
service, and

2) The request-URI does not indicate the user being targeted, which  
happens in many cases including when the UAS-side proxy does contact- 
routing AND the user-part of the contact isn't differentiated per- 
user. It also occurs with some load-balancers. That's part of why we  
don't specify bulk registration in RFC 3261, but instead recommend  
using routing table entries.

--
Dean

---

From: [email-masked]
Date: Mon, 3 Mar 2008 16:37:41 -0500

From: Aki Niemi <[email-masked]>

In all the cases I'm aware of, the notifier determines the resource in
question by examining the request-URI.  This certainly seems to be the
case when phones are generating dialog events.  A solution to the
"proxy loose-routing problem" would improve the results by giving the
notifier more information on the intentions of the subscriber.

The problem isn't combining entity-tags from different subscriptions
created by a single SUBSCRIBE, since the NOTIFYs can be differentiated
by which subscription they are part of.  The problem is when
establishing a later subscription, how to correlate (or not) the
entity-tags from the later subscription with those from the earlier
subscription.

Unfortunately, the safe assumption is to consider the entity-tags to
be non-matching between the different subscriptions, but that violates
the requirement for which the mechanism was defined -- the ability to
avoid re-sending values in later subscriptions that were already sent
in earlier subscriptions.

What is interesting is the case where there is no central server that
knows all of the destinations, which implies that the destinations do
not all know each other.

In the case of mailing lists, one such structure would be for everyone
at my company to subscribe to a local redistribution, and the local
redistributor would have a single subscription to [email-masked].  But a
friend of mine also wants the mail, so I program my workstation to
forward to him a copy of all the messages I'm sent.

A more realistic case would be along these lines:

I subscribe to a virtual phone service that provides me with an AOR,
[email-masked].  This service routes all requests based on time-of-day
to either my desk phone at my job, [email-masked], or my cell phone,
[email-masked].

As expected, a presence subscription (or any other subscription) sent
to [email-masked] does the right thing, it routes to the phone that I am
present at at that time.  (There's a bit of a problem with
subscriptions that span the cutover between the two desitnations.)

If some UAC wants to do periodic polling-type SUBSCRIBEs of
[email-masked], some times it will go to the UAS at [email-masked], and
sometimes to the UAS at [email-masked].  (Or to servers implementing the
events on their behalf.)

The entity-tags chosen by [email-masked] and by [email-masked] are (by
hypothesis) uncoordinated with each other, and there is some risk that
the previous value from one server will be different from the current
value from the other server, but the two will happen to assign the
same entity-tags to those particular values.

Dale

---

From: [email-masked]
Date: Mon, 3 Mar 2008 16:45:35 -0500

From: Dean Willis <[email-masked]>

This has been a known problem for ages -- a UA should register
different contacts for different AORs, so when a request comes in it
knows which AOR (which "line appearance") the request concerns.  I
wrote this in Oct. 2005 (draft-worley-sip-gruu-implement-00), and it
was old information then:

   As detailed below, when responding to requests, the UA should use the
   GRUU associated with the AOR through which the request was routed to
   the UA.  In order to ensure that the UA can determine this, it should
   register distinct URIs for each AOR it services.  (The From header
   may contain a different AOR which was routed to one of the UA's AORs,
   and so can not be depended on to provide the AOR through which the
   request was routed to the UA.)

      Guideline: The UA should register distinct URIs for each AOR it
      services.  (Note that it is not sufficient to generate from each
      AOR a contact 'sip:{user-part}@{IP-address}', since it is common
      for a UA to service two AORs with the same user part in different
      domains.)

Dale