Re: Comments on draft-niemi-sipping-event-throttle-06

I agree: we could instantiate two independent subscriptions, with two
independent filters, two throttles, etc, and get what we want.

We could also have a min throttle option.

Which is simpler?

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> Sent: Thursday, July 31, 2008 12:36 PM
> To: Brian Rosen
> Cc: 'sipping'
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> 
> 
> Brian Rosen wrote:
> > This really is pretty easy.  You are tracking an object.  You want to
> filter
> > the notifications.  If the target is moving rapidly (large changes), you
> can
> > tolerate 10 updates a minute.  If the target is moving slowly, you don't
> > want to be bothered (because it isn't changing much), but, at least once
> in
> > a while, you want to update the location.
> >
> > If you set the update rate to be the same, but a very small motion
> change

Re: Comments on draft-niemi-sipping-event-throttle-06

Brian Rosen wrote:
> I agree: we could instantiate two independent subscriptions, with two
> independent filters, two throttles, etc, and get what we want.
> 
> We could also have a min throttle option.

That isn't what I meant.
Start the subscription with one filter and one throttle.
When that isn't what you want any longer, change it to a different 
filter and a different throttle.

AFAICT you don't need both settings at the same time.

	Paul

> Brian
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>> Sent: Thursday, July 31, 2008 12:36 PM
>> To: Brian Rosen
>> Cc: 'sipping'
>> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
>>
>>
>>
>> Brian Rosen wrote:
>>> This really is pretty easy.  You are tracking an object.  You want to
>> filter

I-D Action:draft-ietf-sipping-consent-format-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : A Document Format for Requesting Consent
	Author(s)       : G. Camarillo
	Filename        : draft-ietf-sipping-consent-format-08.txt
	Pages           : 15
	Date            : 2008-08-01

This document defines an Extensible Markup Language (XML) format for
a permission document used to request consent.  A permission document
written in this format is used by a relay to request a specific
recipient permission to perform a particular routing translation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-consent-format-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip

I-D Action:draft-ietf-sipping-capacity-attribute-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in
Resource Lists
	Author(s)       : M. Garcia, G. Camarillo
	Filename        : draft-ietf-sipping-capacity-attribute-07.txt
	Pages           : 18
	Date            : 2008-08-01

In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs).  The sender sends a single SIP request to a server which
further distributes the request to the group.  This SIP request
contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request.  This URI-list is
expressed as a resource list XML document.  This specification
defines an XML extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a copy control
level similar to the copy control level of existing e-mail systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-capacity-attribute-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: Comments on draft-niemi-sipping-event-throttle-06

It works, it's just too much signaling.  It's also hard for the watcher to
know when to switch.

I really think min is s simpler mechanism.

I've been talking to the throttle authors.  I'll have a proposal on the list
shortly.

Brian

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> Sent: Thursday, July 31, 2008 10:22 PM
> To: Brian Rosen
> Cc: 'sipping'
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> 
> 
> Brian Rosen wrote:
> > I agree: we could instantiate two independent subscriptions, with two
> > independent filters, two throttles, etc, and get what we want.
> >
> > We could also have a min throttle option.
> 
> That isn't what I meant.
> Start the subscription with one filter and one throttle.
> When that isn't what you want any longer, change it to a different
> filter and a different throttle.
> 

Re: Comments on draft-niemi-sipping-event-throttle-06

Brian Rosen wrote:
> It works, it's just too much signaling.  It's also hard for the watcher to
> know when to switch.
> 
> I really think min is s simpler mechanism.
> 
> I've been talking to the throttle authors.  I'll have a proposal on the list
> shortly.

I hear you. I understand it is simpler. But I just have trouble making 
any *sense* semantically out of a minimum frequency for a throttle.

I certainly hope it won't have you sending *identical* data when nothing 
has changed since the last send.

	Paul

> Brian
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>> Sent: Thursday, July 31, 2008 10:22 PM
>> To: Brian Rosen
>> Cc: 'sipping'
>> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
>>
>>
>>
>> Brian Rosen wrote:

Re: comments on draft-shen-sipping-load-control-event-package

Thanks for your comments.

On Jul 27, 2008, at 8:55 PM, Jonathan Rosenberg wrote:

> A few comments on this draft:
>
> * a think a bit more discussion is needed on how this is different  
> from the work being done by Volker and the overload team. Clearly  
> there is amount of overlap, in that both mechanisms attempt to work  
> to reduce overall network congestion during periods of load. The  
> mechanism here is much more policy-centric, and targeting the  
> specific case where load is directed to a particular number.  
> However, with a sufficiently general policy, could this not be used  
> as an alternative feedback mechanism between a proxy and its  
> upstream neighbor, to reduce the load on all traffic?

Yes, this had occurred to me. I didn't want to muddle the discussion,  
also because the load-event-package work has notions of pre- 
announcement ("throttle tomorrow at 8 pm"), which don't really apply  
to the in-band feedback in Volker's draft. That said, I have no  
objection to a common format if there's an advantage to that.

>
>
> On the other hand, a more complementary way of thinking about them,  
> is that when the overload mechanism ala draft-hilt-* indicates to an  
> upstream proxy, 'hey, I'm overloaded, please reduce by 20%', now  
> that proxy needs to make a POLICY decision about which traffic to  
> discard to achieve said goal. Though it could randomly throw away  
> traffic to achieve it, another approach would be to selectively  

Re: Current status of response to 3gpp Liaison Statementon offer/answer procedures

Robert wrote:

> It is a hard requirement that any pair of transaction state 
> machines (the client and server machines for any given hop) 
> have the same timer values. Without that, behavior becomes 
> very incorrect. And for INVITE/ 200/ACK the TU timers (which  
> are all based on T1) have to be the same or you get into 
> broken territory. The result is that if you change a timer 
> somewhere in the network, you either change it across the 
> whole network or you put in a node that's essentially playing 
> the role of a SIP-SIP gateway that deals with complexity of 
> having timers different on each side. 

Is this actually written anywhere. I expected to find it in RFC 3261 if it was written but a scan did not reveal this.

I know IMS uses, for the mobile accesses, timer values that are T1 * 4 for UA to 1st proxy, and then the normal
values in the network.

Robert, can you be more specific on the implications of such a mismatch.

Regards

Keith

> -----Original Message-----
> From: sipping-bounces <at> ietf.org 
> [mailto:sipping-bounces <at> ietf.org] On Behalf Of Robert Sparks
> Sent: Monday, July 28, 2008 3:51 PM
> To: Paul Kyzivat
> Cc: sipping; Mary Barnes; Gonzalo Camarillo

Re: Current status of response to 3gpp Liaison Statementon offer/answer procedures

I will defer to Robert for a definitive statement on this. But AFAIK 
this is *not* *written* anywhere. I think it is a consequence of the 
specs - that as the state machines are defined they *will not work 
correctly* if the two ends don't have he same values.

	Paul

DRAGE, Keith (Keith) wrote:
> Robert wrote:
> 
>> It is a hard requirement that any pair of transaction state 
>> machines (the client and server machines for any given hop) 
>> have the same timer values. Without that, behavior becomes 
>> very incorrect. And for INVITE/ 200/ACK the TU timers (which  
>> are all based on T1) have to be the same or you get into 
>> broken territory. The result is that if you change a timer 
>> somewhere in the network, you either change it across the 
>> whole network or you put in a node that's essentially playing 
>> the role of a SIP-SIP gateway that deals with complexity of 
>> having timers different on each side. 
> 
> Is this actually written anywhere. I expected to find it in RFC 3261 if it was written but a scan did not
reveal this.
> 
> I know IMS uses, for the mobile accesses, timer values that are T1 * 4 for UA to 1st proxy, and then the normal
values in the network.
> 
> Robert, can you be more specific on the implications of such a mismatch.
> 
> Regards

I-D Action:draft-ietf-sipping-service-identification-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : Identification of Communications Services in the Session Initiation Protocol (SIP)
	Author(s)       : J. Rosenberg
	Filename        : draft-ietf-sipping-service-identification-03.txt
	Pages           : 24
	Date            : 2008-08-04

This document considers the problem of service identification in the
Session Initiation Protocol (SIP).  Service identification is the
process of determining the user-level use case that is driving the
signaling being utilized by the user agent.  This document discusses
the uses of service identification, and outlines several
architectural principles behind the process.  It identifies perils
when service identification is not done properly - including fraud,
interoperability failures and stifling of innovation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.