Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP

From: "Liu Zhigang.C (NRC/Dallas)" <[email-masked]>
Date: Thu, 27 Sep 2001 15:20:43 -0500

Hans,

> I agree that the negotiation whether to apply compression 
> between two parties or not should be taken care of before (in 
> the case of SIP) the first SIP INVITE messages. Thus, this 
> can not be done by SigComp itself.
                     ^^^^^^^
I guess you mean SIP?
 
> However, there might be a need to negotiate other parameters, 
> e.g. The usage of a Codebook/Byte-buffer, buffer memory etc., 
> But, we have to think of the complexity issue with too many 
> parameters to set/negotiate, and also if SigComp itself 
> should do this kind of negotiation or if some other protocol 
> should do this, e.g. according to 
> http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiat
> e-00.txt . My belief is that SigComp should not have its own 
> negotiation procedure.

Sorry, I haven't had time to read through the sip-negotiate draft. 
I agree with you that we should keep the number of parameters to 
minimal. However, I feel that the parameters you just mentioned
are closer to SigComp than to SIP. They are really tied to the
algorithms/procedures of SigComp. In my view, the negotiation 
should be either defined with SigComp in one document or in 
a separate document (brother/sister of SigComp). But in either 
case, we should draw a line between SIP (the "user" of SigComp) 
and SigComp (the service provider). The interface between
the two is the negotiation protocol. 

For example, SIP can trigger the negotiation by sending a request
like (SIP, UDP, port #) to the SigComp negotiation. The negotiation
then setup the rest. This what I meant in my previous email. 
Similarly, an RTSP module can trigger the negotiation by 
(RTSP, UDP, port #). 

> Also how to decide to use a Codebook or a Byte-buffer is 
> suggested by Jan Christoffersson in:
> http://www.cdt.luth.se/rohc/msg02686.html . 

That's one important issue, i.e. token formats and context 
structure. I've suggested an alternative to merge codebook
with byte-buffer in http://www.cdt.luth.se/robhc/msg02649.html.
As to the token formats, one simple (perhaps dumb) solution
is to define two sets of token formats: one for LZSS (byte-buffer)
and one for LZW (codebook). Then we only need one bit in the 
header part to signal which set should be used to process a
compressed message. For example, if the flag set to 0,
READ = (pointer, length), referring to byte buffer. Otherwise,
READ = (index), referring to codebook.

> > Note that although the negotiation procedure is out of SIP (again,
> > to be generic), it may be triggered by SIP as a service request. 
> 
> The scheme is still generic even though it uses e.g. SIP to 
> negotiate its usage. The same compression scheme can still be 
> applied to e.g. RTSP. If we define what has to be negotiated 
> (if any) it should be up to the application to make this happen.    

Pleae see my comment above.

> > However, the two endpoints 
> > should periodically verify they are still in sync (e.g. between 
> > sessions when traffic is relatively idle).
> 
> What should be verified? The settings of the compression 
> scheme or its dictionaries/Code-books.

Both (they together constitute the compression context).
 
> > Re Markus' question about the requirement, the location of the peer
> > compression entities is not addressed (to make SigComp generic).
> > However, the need of negotiation is mentioned/implied in current
> > requirement draft (e.g. 3a - compatibility, 6 - Scalability).
> 
> Yes, negotiation is needed, but the question is how we do it.

We can take the ideas from SCRIBE. The exact parameters to
be negotiate may not be the same. But the basic mechanism
is already there (packet type, CRC, handshake procedures, etc.).

BR,
Zhigang

---

From: "Hans Hannu" <[email-masked]>
Date: Fri, 28 Sep 2001 11:40:30 +0200

Hi,

See comments inline.

> > can not be done by SigComp itself.

No, I do not. Whether to apply compression or not should be decided by the
application e.g. SIP. SigComp is just the tool that the application will use
for compression.

Basically, there are two issues:
1) Whether compression is to be applied or not,
2) How to negotiate the SigComp parameters (If any needs to be negotiated).
What we should do is to first define what parameters that we see a need to
negotiate. Then we could start thinking of how to do the negotiation. And
also if the parameters need to be negotiated or if they can be signaled "in
band".

1 - Whether to apply SigComp compression or not should be negotiated by the
application, e.g. SIP. Because it is the application which knows where the
other party is located. If this is done with a new SIP method or according
to: http://www.cdt.luth.se/robhc/msg02358.html
Rosenberg: "My proposal for modeling this as a SIP transport handles this
case. I suspect that the usage of SRV records, a key piece of the SIP
approach, will also work fine for other application protocols, such as
RTSP."

> In my view, the negotiation

I agree to that we should draw a line between the SIP, which uses
Compression, and SigComp that performs the compression.

> READ = (index), referring to codebook.

Yes, this is a simple solution and personally I like it. We could state that
the decompressor implementation must support both a byte-buffer and a
codebook. I believe that the extra complexity of supporting both is very
small. This will then also exclude one parameter to negotiate.

BR
/Hans H