Subject: RE: [rohc] regarding UDVM

From: "Gangadharan G - NPD, Chennai" <[email-masked]>
Date: Wed, 9 Aug 2006 18:32:32 +0530

Hi Raghu,
 
A1. Not only for the Deflate, The decompression logic of all the compression
algorithm should be written in terms of UDVM instruction.
      Once you written the decompression algorithm in UDVM instruction set ,
convert it into bytecodes using UDVM assembler.
      This bytecode has to sent in the message.
 
A2. On receiving the message, Decompress dispatcher initializes one UDVM
instance. It loads the bytecode 
,present in the message, in the UDVM memory and the destination is specified
in the message. Bytecode should take care of the UDVM memory usage.
 
A3. It is not compulsory to use static dictionary in the compressor side. 
But you should support the static dictionary as state, if your Application
protocol mandates.
Its up to you to decide whether compressor has to use static dictionary
while compressing.
 
A4. State Address specifies the UDVM's next instruction to be executed after
loading the state value.
This would be useful when you save the UDVM memory as one state.
The state address for this case is the start of the UDVM bytecode(same as
the destination mentioned in the first message).
 
Thanks,
Gangadharan.

-----Original Message-----
From: Raghavendra D P [mailto:[email-masked]]
Sent: Wednesday, August 09, 2006 4:22 PM
To: [email-masked]
Subject: [rohc] regarding UDVM

hi all
 
Q1)first thing is how to create UDVM bytecode for deflate algorithm , 
*is it by using UDVM instuctions
* all UDVM instuction including state instuction (state acess, state create
and state free ) are sent in UDVM bytecode

Q2)  when to initialize UDVM memory (64 k) 
 is it while sending UDVM bytecode along with sig comp message,  
 
Q3) why this static dictionary is required. It is compulsory or not
is it  used by compressor  and application layer 

Q4) The State value can be either of the following also Decompressed
message, Message to be sent or Dictionary. 
 
can static dictionary values can be overwritten by  Decompressed message,
Message to be sent 
if not separate state should be created.

other items like 
state instuction - it contains program start address , 
state address  -  pointer to UDVM memory
  
what actually state addreess  contains , if possible by example.

thanks in advance
regards
Raghavendra 

Disclaimer:

This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Raghavendra D P" <[email-masked]>
Date: Thu, 10 Aug 2006 17:48:38 +0530

HI 

Thanks a lot for ur cooperation in sloving my question.  i am having some queries again

1)  The State value can be either of the following  Decompressed message, Message to be sent or Dictionary

my question is,      In what scenarios state value contains decompressed message and Message to be sent . please do clarify

2) The state address for this case is the start of the UDVM bytecode    (same as the destination mentioned in the first message).

state adresss      = destination address which indicates address of UDVM bytecode to be uploaded in UDVM memory
state insrtuction  =  program start address ie destination address 
then both are same, but   u also have mentioned that it conatins next instruction code execution address
 scenario if possible

please do clarify it.

3) once the compressor dispathcer gets application and invokes particular compressor, 
Now we have sigcomp message which is encoded or commpressed data

Next is to create sig comp format message  and there i will uplaod the UDVM bytecode  and feedback return data and also sig comp message 
in correct order specified in the RFC 3320 . 

On recieving  endpoint, decompressor dispatcher recieves Sigcomp message along with  UDVM bytecode and feedback data(Decompressed_memory sz, 
sig_version and cycles per bit) then dispatcher creates one instance of UDVM memory and it initializes memory using feedback data, udvm bytecode is copied to correct dest address. and after decompression of sigcomp message using UDVM bytecode, state is created .
And also compartment  identifier is provided by the application layer  to the dispatcher to save the information in state .

On sending endpoint ,  next sigcomp message is created and it is formatted using other sigcomp message format form , which includes the state identifier , feedback data, sig comp message, 
Again this message is received by the decompressor dispatcher , using state identifier  it access the state using state access instuction 

PLEASE TELL ME THAT WHO HAS INVOKE THIS STATE ACCESS INSTRUCTION , IS IT  ON SENDING  ENDPOINT OR DISPATHCER OR IN FIRST MESSAGE 
WHATEVER WE ARE UPLOADED UDVM BTECODE,  and  ONLY WE HAVE to CHANGE THE  

STATE INSTRUCTION - STATE ACCESS INSTRUCTION ADDRESS
STATE ADDRESS - ?

PLEASE TELL ME , I HAVE TO USE FEEDBACK DATA TO FILL UDVM_MEMORY _SIZE, CYCLES_PER BIT (STARTING VALUES UPTO  4 BYTES OF UDVM 
MEMORY) , SO I HAVE TO SEND FEEDBACK DATA ALONG WITH SIGCOMP MESSAGE   EVERY TIME . 

OR  ELSE I HAVE TO STORE IN STATE HANDLER.

PLEASE CLARIFY IT.

Then state values are  copied to UDVM memory (this is done by normal programming :RIGHT) then decompression takes place by executing UDVM bytecode  and decompression message is given to application layer.

4) IS THERE  GUIDE OR LINK WHICH HELPS IN GENERATING   UDVM BTECODE ?

thanks in advance 

PLEASE HELP ME IN THIS REGARD , WAITING FOR UR  REPLY 

regards 

raghavendra 
  ----- Original Message ----- 

  From: Gangadharan G - NPD, Chennai 
  To: Raghavendra D P ; [email-masked] 
  Sent: Wednesday, August 09, 2006 6:32 PM
  Subject: RE: [rohc] regarding UDVM

  Hi Raghu,
   
  A1. Not only for the Deflate, The decompression logic of all the compression algorithm should be written in terms of UDVM instruction.
        Once you written the decompression algorithm in UDVM instruction set , convert it into bytecodes using UDVM assembler.
        This bytecode has to sent in the message.
   
  A2. On receiving the message, Decompress dispatcher initializes one UDVM instance. It loads the bytecode 
  ,present in the message, in the UDVM memory and the destination is specified in the message. Bytecode should take care of the UDVM memory usage.
   
  A3. It is not compulsory to use static dictionary in the compressor side. 
  But you should support the static dictionary as state, if your Application protocol mandates.
  Its up to you to decide whether compressor has to use static dictionary while compressing.
   
  A4. State Address specifies the UDVM's next instruction to be executed after loading the state value.
  This would be useful when you save the UDVM memory as one state.
  The state address for this case is the start of the UDVM bytecode(same as the destination mentioned in the first message).
   
  Thanks,
  Gangadharan.

    -----Original Message-----
    From: Raghavendra D P [mailto:[email-masked]]
    Sent: Wednesday, August 09, 2006 4:22 PM
    To: [email-masked]
    Subject: [rohc] regarding UDVM

    hi all

    Q1)first thing is how to create UDVM bytecode for deflate algorithm , 
    *is it by using UDVM instuctions
    * all UDVM instuction including state instuction (state acess, state create and state free ) are sent in UDVM bytecode

    Q4) The State value can be either of the following also Decompressed message, Message to be sent or Dictionary. 
     
    can static dictionary values can be overwritten by  Decompressed message, Message to be sent 
    if not separate state should be created.
     
    other items like 

     
    thanks in advance
    regards
    Raghavendra 

  Disclaimer: This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers, privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. 

This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc