Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 17:38:29 -0400

> -----Original Message-----
> From: Romeo Zwart [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 3:27 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt
> 
> 
> Jonathan,
> 
> In the diagram of section 4.6, the WRITE HIGH REFERENCE token 
> is shown as 
> identical to the WRITE HIGH token. I assume this is a typo. 
> What is the 
> intended token for the WRITE HIGH REFERENCE case?

No, they're not the same. The WRITE HIGH REFERECE appears on the top of page
9. So, WRITE REFERENCE is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   index     |1|1|0|   TC    | tokens..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and WRITE HIGH REFERENCE is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1|   index     |0|1|1| index   |x|x|x|   TC    |  tokens
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 
> In the same diagram, is there a defined value for the three 
> 'padding' bits 
> that fill up the third octet?

No. It doesn't really matter.

> 
> In section 5 you describe your proposed new LZW variant. Your 
> 'friendly 
> test' shows very nice results, except for the initial message in the 
> series, which has an (expected) larger compressed size than the 
> uncompressed size. Have you considered jumpstarting the 
> codebook with a set 
> of default entries (e.g. INVITE, From:, To:, etc.)? Would you expect 
> earlier convergence?

Yes, I had thought about usage of static codebooks, which is used in one of
the other proposals. I think its probably a good idea. 

The draft I wrote up is not really meant to be a complete solution, and I
expect the final compression work will be a synthesis of many of the fine
ideas in SCRIBE, ROGER, EPIC, and this proposal. My main goals with this
were to emphasize some key points:

1. this is the BEST way to solve the problem for wireless usage of SIP
2. the protocol is best viewed as a mechanism for maintenance and management
of codebooks, and that allowing different compression algorithms within that
framework is a good thing
3. There are reasonable ways to handle compression of out of order messages
that must be taken into account.
4. The mechanism, from a SIP perspective, is best done at the "transport
layer", in the sense that its something for which SRV record-entries are
defined, and a SIP transport param is defined, so that the existing
transport negotiation mechanisms in SIP can be applied. 

Looking forward to discussing it all in London....

-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

_______________________________________________
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: [email-masked]
Date: Mon, 30 Jul 2001 17:14:10 -0500

The following is a very good way to proceed. I share the same
view as yours (need to do some homework on point 4 to understand
the details). It is also important that we can proceed fast to meet
3GPP schedule. Otherwise, we will all spend 20 or more seconds 
listening to the ring each time we make a SIP call.

Br,
Zhigang

> Yes, I had thought about usage of static codebooks, which is 
> used in one of the other proposals. I think its probably a good idea. 
> 
> The draft I wrote up is not really meant to be a complete 
> solution, and I expect the final compression work will be 
> a synthesis of many of the fine ideas in SCRIBE, ROGER, 
> EPIC, and this proposal. My main goals with this
> 2. the protocol is best viewed as a mechanism for maintenance 
> and management of codebooks, and that allowing different compression 
> algorithms within that framework is a good thing
> 3. There are reasonable ways to handle compression of out of 
> order messages that must be taken into account.
> 4. The mechanism, from a SIP perspective, is best done at the 
> "transport layer", in the sense that its something for which SRV 
> record-entries are defined, and a SIP transport param is defined, 
> so that the existing transport negotiation mechanisms in SIP 
> can be applied. 
>

---

From: "Hans Hannu" <[email-masked]>
Date: Tue, 31 Jul 2001 08:57:37 +0200

Hi,

I agree, it is important that we can proceed fast, and also that the final
compression work will probably be a synthesis of the ideas in the current
contributions.
I also share the idea with Jonathan, to separate message compression into
two problems; a Protocol and the actual compression Algorithm, see 1) and 2)
below.

1) The Scheme/Protocol
- Message handling. E.g. verification of correct decompression, usage of
previous messages in the compression process, context handling
(dictionary/codebook handling)
2) The actual compression algorithm
- What to save in the dictionaries/codebooks etc..
- Compressed message representation. E.g. different Lempel-Ziw based
representations.

In our contribution, ROGER
http://www.ietf.org/internet-drafts/draft-hannu-rohc-roger-01.txt
we are following this grouping. E.g. the actual compression algorithm can be
substituted and ROGER's focus has been more set on number 1 above.
I believe that the other contributions more or less have this separation.

BR
/Hans H

>Mailing list for Robust Header Compression WG
>Archive: http://www.cdt.luth.se/rohc/
************************************************************************
Hans Hannu  | Phone: +46 920 20 21 84, +46 70 55 99 015
Ericsson Erisoft AB | Fax: +46 920 20 20 99
Laboratoriegränd 11, Box 920, S-971 28 Luleå, Sweden
************************************************************************