Subject: Re: [Sipping] Comments on event-throttle 01

From: Adam Roach <[email-masked]>
Date: Wed, 15 Dec 2004 15:18:54 -0600

Cullen Jennings wrote:

>Not clear if the goal of this is to limit the number of  messages or limit
>the bandwidth of messages. The merging of partial states to a full state may
>make the problem worse not better.
>  
>

I'm not sure I understand this argument. It may be that we've read 
section 3.1.4 differently than each other -- but, as far as I can tell, 
the intention isn't to merge several partial states into a full state as 
much as it is to merge several partial states into a single partial state.

Concretely: consider the SIP overhead of sending a NOTIFY and getting a 
200 response to it to be X bytes.

Now, consider that Client A has subscribed to Client C, with a throttle. 
Client B has also subscribed, but without a throttle.

Now, client C publishes three notifications, of sizes N, M, and P, 
respectively.

Client B gets these in separate messages, for a total of 3X + N + M + P 
bytes.

Client A gets these in a single message, for a total of X + N + M + P bytes.

The total savings is 2X bytes.

That's the worst case scenario, in which all three notifications that C 
sends are for different parts of the state. In the case that any of 
these publications refer to the same part of the state, savings are even 
more substantial.

Or maybe I'm missing the scenario that you're talking about. Can you 
outline a concrete example (similar to what I've done above) that shows 
that the number of bytes can actually *increase* when using the throttle 
mechanism? (Of course, I'm ignoring the "Supported" header and other 
protocol additions used to actually effect the throttles as being 
insignificant; certainly, these aren't the increases you are worried 
about, right?)

/a

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Dec 2004 07:51:47 -0800

> much as it is to merge several partial states into a single partial state.

I hadn't realized that was the idea - that sounds pretty hard to implement
in a way that does not use insane amounts of state. I thought the idea was
that if you exceeded the throttle, then you waited till the next window you
could send and sent the complete state.

The only description in in the draft seems to be the non normative

" Partial-state:  The states of buffered notifications are merged, and
      the resulting notification is sent out.  This policy applies to
      those event packages that carry partial-state notifications."

I think the draft should explain clearly what the Notified is supposed to do
with all the data. 

My question still stands, is the goal to reduce bandwidth or number of
packets?

> The total savings is 2X bytes.

What would the saving have been if I was running these messages over a
compressed TLS connection?
 
> these publications refer to the same part of the state, savings are even

Is this part of figuring out, on a per client basis, the continuous partial
merge, checking that it is a valid document, and sending it on at the
appropriate time that sounds pretty challenging. If the draft is going to to
go say that the notifier MUST implement this - I'm find with the whole
thing.

This would be good in that the client would also know they got the all the
information, just some of it was delayed.

> insignificant; certainly, these aren't the increases you are worried

I was actually considering all the SIP headers close to irrelevant after
compression and that the real issue was in the bodies.

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Dec 2004 07:45:50 -0600

Cullen Jennings wrote:

>> ...[A]s far as I can tell,
>>
>in a way that does not use insane amounts of state.
>

I'm not sure I'd say "insane amounts of state," but it's certainly a 
memory/bandwidth tradeoff.

>My question still stands, is the goal to reduce bandwidth or number of

I suspect that the answer is bandwidth. At least, it would be for any 
application I'd be inclined to deploy this with.

>compressed TLS connection?

I'm assuming you're using deflate. Let's assume about 800 bytes of 
headers, and 4000 bytes of body. (I'm just trying to get my sizes right 
for the "offset" and "length" fields). Replicating the headers would 
take three length/distance codes, with the lengths being (2 * 8 bits + 
13 bits), and the distances being (3 * 16 bits)... or about 10 bytes per 
message, for 20 bytes total. There might also be some incidental savings 
effected because your distance code sizes won't increase as rapidly with 
the headers being absent. So, 10 to 12 bytes is not really a 
*significant* savings (probably only on the order of 2%), but it's still 
not the *expansion* you feared might happen.

And I'll reiterate that this is the worst case scenario. If more than 
one update for the same piece of state arrived during this period, you 
could completely elide all but the final one, which could well result 
savings of several hundred percent, regardless of whether compression is 
employed.

(As an aside, have you actually seen clients running TLS-negotiated 
compression in favor of SigComp? Could you point me to an example?)

>appropriate time that sounds pretty challenging.
>

Yes, and it is. So is almost everything else in a practical presence 
server. There are a whole slew of very difficult problems to solve... 
and, actually, once you have the data processing infrastructure in place 
to do things like state composition, you've done most of the work for 
implementing the throttling as it is currently described in the document 
(at least, by my reading of it).

>information, just some of it was delayed.

Agreed, and I think such is the intention. I understand that you think 
this point, as well as potentially some related points in the draft are 
unclear, and would encourage you to send text to Aki to clarify any 
points of ambiguity.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Dec 2004 13:59:48 -0700

> compression in favor of SigComp? Could you point me to an example?)

No - I have not seen anything using compress with TLS - or for that matter
even heard of anyone thinking of using it - and mixing compression with
security is pretty weird too :-)