Subject: [Sip] RE: Encapsulating EPIC in UDPComp

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 03:01:08 -0400

> -----Original Message-----
> From: Price, Richard [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 8:00 AM
> To: 'Jonathan Rosenberg'; [email-masked]'; [email-masked]'
> Subject: RE: Encapsulating EPIC in UDPComp
> 
> > Code       output
> > -------------------
> > 0          WRITE the string which follows by splitting the 
> > indicated vertex
> > in the curren table
> > 1          WRITE the string which follows into the root table 
> > (i.e, change
> > contexts) by splitting the indicated vertex
> > 
> > This code would need to be followed by the identity of the 
> > vertex, and then
> > the text itself.
> > 
> > This way, you start off with very efficient codes that write 
> > into the table.
> > As the table gets larger, you use the efficient codes for the common
> > strings, and the code for writing into the table gets longer.
> 
> This is a very nice idea but I'm not sure how to make it 
> robust against
> misordering or packet loss between the compressor and decompressor.
> The compressor will need to continue sending the explicit form of the
> token until it receives confirmation that it has arrived at the
> decompressor, after which it can switch to the more efficient Huffman
> code for the token. Using the above technique, can we make sure that
> writing the same Huffman code into the table more than once will not
> cause problems?

Ah, good point. For this to work well under packet loss, changes to the
codebooks need to be incremental, so that existing stuff is unchanged by the
addition or removal of an element. My proposal violates that rule, so we
should not go that route.

I suppose we should then stick with the model where the code for the new
element is transmitted directly. We can pick a reasonably short code for the
READ and WRITE commands, and see whether the overhead for them is
acceptable.

> > 
> > This turns the tree of tables into a more general purpose 
> > digraph, which is
> > probably a really good idea. It can save a lot of overhead in 
> > the management
> > of the table. Protocols, like SIP, have many "paths" through 
> > the message
> > which can arrive at a common piece of data (for example, the 
> > SIP URL). This
> > way, the encoding for the SIP URL appears only once in 
> > memory, rather than
> > based on each path to get to it.
> 
> Once the decompressor arrives at the common piece of data (say the
> SIP URL), how should it decide where to go next? 

To be done generally, that information would have to be transmitted.
However, it will have a lot of overhead. Basically, the pointer to the next
table is defined as the series of huffman codes that would take you from the
root to that table. For deep tables, this information will be quite large, I
suspect. Its not clear it would be worth it.

-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://www1.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