Subject: [Sip] RE: [rohc] New I-D on compression of SIP

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 17 Jul 2001 00:09:33 +0200

Hi Jonathan,

First of all I have to say that I think it is good that we now have several contributors to this discussion about signaling compression, e.g. SIP compression. I have read your draft and have a number of comments but before I take them all I would like to ask you for some clarifications about how you mean this new "protocol shim" is introduced in reality. You say that it becomes a new alternate transport but it is not clear how this is indicated. Is your intention to create a new "UDP-compress" transport protocol (new protocol ID)? 

Cheers,
/L-E

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: den 13 juli 2001 22:09
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: [rohc] New I-D on compression of SIP
> 
> 
> Folks,
> 
> I've just submitted a new I-D on compression of SIP messages, 
> particularly
> for wireless links. Until the draft appears in the archives, 
> you can pick up
> a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt
> 
> Thanks,
> 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
>  
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 

_______________________________________________
Sip mailing list  http://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: James Undery <[email-masked]>
Date: Tue, 17 Jul 2001 14:19:31 +0100

> First of all I have to say that I think it is good that we now have several contributors to this discussion about signaling compression, e.g. SIP compression. I have read your draft and have a numb…

I think by this Jonathan means to have a new transport parameter for SIP URLs and position the encoding/decoding just above the UDP "stack" code and below the SIP "stack" code. My major concern is the lack of a message acknowledgement mechanism, I know why this was done, however, in the pathelogical case in SIP where all the Request transmissions are lost, the decoder will never update it's codebook from then on adding to the overheads not helping.

James

---

From: Romeo Zwart <[email-masked]>
Date: Thu, 19 Jul 2001 21:03:14 +0200

At 03:19 PM 7/17/2001, James Undery wrote:
> > First of all I have to say that I think it is good that we now have 
> several contributors to this discussion about signaling compression, e.g. 
> SIP compression. I have read your draft and have a number of comments but 
> before I take them all I would like to ask you for some clarifications 
> about how you mean this new "protocol shim" is introduced in reality. You 
> say that it becomes a new alternate transport but it is not clear how 
> this is indicated. Is your intention to create a new "UDP-compress" 
> transport protocol (new protocol ID)?
>
>I think by this Jonathan means to have a new transport parameter for SIP 
>URLs and position the encoding/decoding just above the UDP "stack" code 
>and below the SIP "stack" code. My major concern is the lack of a message 
>acknowledgement mechanism, I know why this was done, however, in the 
>pathelogical case in SIP where all the Request transmissions are lost, the 
>decoder will never update it's codebook from then on adding to the 
>overheads not helping.

I agree with your concern about the absense of message acknowledgement. I 
am pleased that you do understand why this is the case, as I don't :-). Is 
it the intention to save on coding complexity or do we want to save a few 
bits over the wire? In the latter case, I think the intent is good, but 
aren't the achieved savings quite modest? In the former case, I don't think 
there are any savings at all, possibly complexity is worsened depending on 
what mechanism is chosen for the encoder to track message reception.

The draft talks about the encoder that learns "in some way" that the 
message was received at the other end. Magic I can think of here would 
either look very much like an (implicit) acknowledgement mechanism, where 
the decoder and encoder on one side of the link communicate to confirm 
message reception. Alternatively, message confirmation might depend on 
direct signalling from the application layer to the compression layer. 
However, since the SIP layer is not aware of the encoder, I don't think 
that's a valid approach. I'd be interested to how this is perceived to work.

By the way, I am not so much concerned with the pathological case you've 
given above. If lower layers are dropping *all* requests, a non-updated 
codebook is probably not my main worry. But I'd agree that in the case of 
deteriorating network behavior, e.g. ramping up towards an overload 
situation, non-updated codebooks are going to worsen the problem.

Romeo