Subject: RE: [rohc] Partial_State_ID calculation at compressor End

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Wed, 12 May 2004 10:37:10 +0200

Hi,

1. The compressor must be aware of what the state ID is, so no need to send it back.
2. This question is not discussed in implementation details in the RFC 3320 that says in 4.3 (remember the note in my previous message):

Upon receiving a decompressed message the application may supply the
   dispatcher with a compartment identifier.  Supplying this identifier
   grants permission for the following:

   1. Items of state accompanying the decompressed message can be saved
      using the state memory reserved for the specified compartment.

   2. The feedback data accompanying the decompressed message can be
      trusted sufficiently that it can be used when sending SigComp
      messages that relate to the compressor's equivalent for the
      compartment.

BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 10:14 AM
To: Lajos Zaccomer (IJ/ETH)
Cc: [email-masked]; [email-masked]; 'suman'
Subject: RE: [rohc] Partial_State_ID calculation at compressor End

Hi,

A couple of points

1. If you don't send the feedback in the case of TCP , how do you know the
partial state id of the saved state so that u can send it in the next
message you send ? the partial state id is calculated when the UDVM
executes at the remote end.

2. I believe,  if the state save fails due to some reason, the requested
feedback should not be sent back at all by the receiving endpoint.

regds,
suprabhat

             "Lajos Zaccomer                                               
             (IJ/ETH)"                                                     
             <lajos.zaccomer@e                                          To 
             ricsson.com>              "'suman'" <[email-masked]>,      
             Sent by:                  [email-masked], [email-masked]    
             [email-masked]                                          cc 
             rg                                                            
                                                                   Subject 
                                       RE: [rohc] Partial_State_ID         
             05/12/04 01:20 PM         calculation at compressor End       

                                                                           

Hi,

As far as I know, using a reliable transport makes feedbacks unnecessary.
In such a case, it is not the feedback you need to decide if the requested
save state operation has been performed but the advertisement of SMS > 0
(as Suman mentioned it might be 0).
In the example, the first message might advertise SMS > 0, which I believe
is enough to think that the BYTECODE was successfully saved, so there is no
need to repeat it in the 180 Ringing.
Note that the feedback in itself is not enough to know if the save state
was indeed all right, because there might be some kind of state database
error or lack of memory in state handler, while the requested feedback is
still sent back (indicating only that the application accepted the
decompressed message).

BR/Zacco
      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]On Behalf Of
      suman
      Sent: Wednesday, May 12, 2004 8:52 AM
      To: [email-masked]; [email-masked]
      Subject: Re: [rohc] Partial_State_ID calculation at compressor End

      In your example, the 180 ringing will always carry the bytecode in
      case of both UDP and TCP.
      This is because the other endpoint could be stateless with sms = 0.
      Without receiving feedback from the peer endpoint, it cannot be
      assumed that the states are saved.

      thanks
      suman
       ----- Original Message -----
       From: [email-masked]
       To: [email-masked]
       Sent: Wednesday, May 12, 2004 10:19 AM
       Subject: [rohc] Partial_State_ID calculation at compressor End

       RFC 3321 says

       "The compressor must only use states   that are established at the
       remote decompressor, otherwise a decompression failure will occur.
       For this reason,  acknowledgements are necessary, at least for
       unreliable transport."

       My case is as follows :

       1. EP1 sends compressed INVITE message with decompression BYTECODE
       to EP2.
       2. EP2 saves state EP2_S1.
       2. EP2 sends compressed 100 Trying  message with decompression
       BYTECODE to EP1.
       3. EP1 saves state EP1_S1.
       4. Now when EP2 wants to send 180 ringing and it has not go the ack
       for state EP1_S1.

       My question is in case of TCP, can the EP2 send the partial_state_Id
       instead of uploading BYTECODE again when it sends 180 Ringing.

       If so how the partial_state_id will be calculated at EP2 compressor
       End.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Wed, 12 May 2004 15:05:44 +0530

Hi Lajos,

This mail is regarding the pt-1 as stated by you in previous mail.

As per my understanding of RFC 3320, the sigcomp does not mandate
any "compression algorithm & decompression bytecode" because
the decompression intelligence is built in the UDVM.

The sender sends the compressed message along with the decompression
bytecode in the sigcomp message. That clearly means that decompression
algorithm/bytecode writing is outside the scope of the sigcomp and
it is entirely in scope of application written over top of the sigcomp.

Pls note that State-Id calculation requires following parameters :
1> State Length
2> State address
3> State Instruction
4> Min access length
5> State Retention Priority

Also, note that state create request can be made through two
instructions :
a. STATE_CREATE
b. END_MESSAGE

The sigcomp can not know the above parameters at the time of
sending message (which will contain the bytecode as chosen
by the application) so how can State-Id be calculated at sender
side. That is, how can compressor at local end know the state-id
as the parameters [required for state id calcuation]
are embedded inside the bytecode [which can be interpreted at the
remote end only] ?

Waiting for your input on this point.

thanks and regards
Jyoti

             "Lajos Zaccomer                                               
             (IJ/ETH)"                                                     
             <lajos.zaccomer@e                                          To 
             ricsson.com>              "[email-masked]'"         
             Sent by:                  <[email-masked]>           
             [email-masked]                                          cc 
             rg                        [email-masked], [email-masked],   
                                       "'suman'" <[email-masked]>       
                                                                   Subject 
             05/12/04 02:07 PM         RE: [rohc] Partial_State_ID         
                                       calculation at compressor End       

                                                                           

Hi,

1. The compressor must be aware of what the state ID is, so no need to send
it back.
2. This question is not discussed in implementation details in the RFC 3320
that says in 4.3 (remember the note in my previous message):

BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 10:14 AM
To: Lajos Zaccomer (IJ/ETH)
Cc: [email-masked]; [email-masked]; 'suman'
Subject: RE: [rohc] Partial_State_ID calculation at compressor End

Hi,

A couple of points

regds,
suprabhat

             "Lajos Zaccomer
             (IJ/ETH)"
             <lajos.zaccomer@e                                          To

Hi,

BR/Zacco
      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]On Behalf Of
      suman
      Sent: Wednesday, May 12, 2004 8:52 AM
      To: [email-masked]; [email-masked]
      Subject: Re: [rohc] Partial_State_ID calculation at compressor End

      thanks
      suman
       ----- Original Message -----
       From: [email-masked]
       To: [email-masked]
       Sent: Wednesday, May 12, 2004 10:19 AM
       Subject: [rohc] Partial_State_ID calculation at compressor End

       RFC 3321 says

       My case is as follows :

---

From: [email-masked]
Date: Wed, 12 May 2004 15:07:16 +0530

Hi Lajos,

thanks and regards
Jyoti

             "Lajos Zaccomer                                               
             (IJ/ETH)"                                                     
             <lajos.zaccomer@e                                          To 

                                                                           

Hi,

BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 10:14 AM
To: Lajos Zaccomer (IJ/ETH)
Cc: [email-masked]; [email-masked]; 'suman'
Subject: RE: [rohc] Partial_State_ID calculation at compressor End

Hi,

A couple of points

regds,
suprabhat

             "Lajos Zaccomer
             (IJ/ETH)"
             <lajos.zaccomer@e                                          To

Hi,

BR/Zacco
      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]On Behalf Of
      suman
      Sent: Wednesday, May 12, 2004 8:52 AM
      To: [email-masked]; [email-masked]
      Subject: Re: [rohc] Partial_State_ID calculation at compressor End

      thanks
      suman
       ----- Original Message -----
       From: [email-masked]
       To: [email-masked]
       Sent: Wednesday, May 12, 2004 10:19 AM
       Subject: [rohc] Partial_State_ID calculation at compressor End

       RFC 3321 says

       My case is as follows :

---

From: suman <[email-masked]>
Date: Wed, 12 May 2004 17:19:55 +0530

Hi Jyoti,

 Please note that the State-Id calculation requires State Value and not
State retention priority.

Sigcomp will be aware of all the states that will be created at remote
endpoint
even before the sigcomp message is sent to the remote endpoint.

This is because the bytecode being transferred to the remote endpoint will
have
a direct one to one relationship with the way the compression algorithm
behaves.
Before sending the compressed message with the bytecode, the compressor has
to save the state it has generated during process of compression. And this
state id
will be the same as that computed at remote end using STATE-CREATE
or END-MESSAGE instructions.

thanks
suman

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 12, 2004 3:07 PM
Subject: RE: [rohc] Partial_State_ID calculation at compressor End

---

From: [email-masked]
Date: Wed, 12 May 2004 17:41:52 +0530

Hi suman,

Going by your statement you are assuming that the bytecode generation is in
the scope of Sigcomp(the compressor). But then you r restricting the
application on top of Sigcomp to use any compression algorithm it wishes.

regds,
suprabhat

             suman                                                         
             <[email-masked]                                             
             m>                                                         To 
             Sent by:                  [email-masked], [email-masked]  
             [email-masked]                                          cc 
             rg                        "Lajos Zaccomer (IJ/ETH)"           
                                       <[email-masked]>,      
                                       [email-masked], [email-masked]  
             05/12/04 05:19 PM                                     Subject 
                                       Re: [rohc] Partial_State_ID         
                                       calculation at compressor End       

                                                                           

Hi Jyoti,

thanks
suman

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>;

>              <lajos.zaccomer@e
To
>              [email-masked]
cc
Subject
>              <lajos.zaccomer@e
To
>              [email-masked]
cc
Subject

---

From: suman <[email-masked]>
Date: Thu, 13 May 2004 09:43:47 +0530

hi suprabat,

    The application is flexible to choose any of the compression algorithms,
but there will be a unique bytecode
for each of the compression algorithm(each of which is available within the
SigComp framework).

SigComp layer should send the corresponding bytecode depending on the
compression algorithm chosen by application.

The state management policy could be different for each of the compression
algorithms.
It should be handled in the same way by the compression algorithm and the
corresponding bytecode.

If the application on the top of SigComp wishes to use a new compression
algorithm,
it has to bind the corresponding bytecode to the SigComp layer.

But as you say, this architecture has some limitations.

Introducing a new compression algorithm on the fly by application means, the
compressor
should be made aware of the states that will be created by this algorithm,
and the corresponding bytecode.

thanks
suman
----- Original Message -----
From: <[email-masked]>
To: "suman" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Lajos
Zaccomer (IJ/ETH)" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 12, 2004 5:41 PM
Subject: Re: [rohc] Partial_State_ID calculation at compressor End

---

From: suman <[email-masked]>
Date: Thu, 13 May 2004 14:42:51 +0530

hi suprabat,

thanks
suman