Subject: RE: [rohc] Questions on draft-ietf-rohc-sigcomp-06.txt

From: [email-masked]
Date: Mon, 13 May 2002 12:15:25 -0500

Hi Chan,
 See inline comments. (My answers are based on my intrpretation of the draft)

-Narendra

Am i right to say that both the State Handler at the receiver 
and the Compressor at the sender have to create the hash ? 
This is done so that when the compressor wants to access a 
state, it has to supply the state identifier to the UDVM. when 
the UDVM receives this state identifier, it 
passes the state identifier to the State Handler to access 
a particular state. Since the State Handler also has the state 
identifier, it can then verify if the state identifier is a 
valid one. 

ANS: Yes. 

2) In section 9.4.1, it is stated that UDVM uses CRC to 
detect errors in the decompressed message and then a 
Decompression Failure will trigger a manual decompression 
failure. Can anyone tell me what is meant by 'manual 
decompression failure' ? 

ANS:  Manual decompression failure implies compressor shutsdown (manually through an instruction) the decompression  at the UDVM.  Usually, Decompression failures occur in an UDVM if something unexpected happens like accessing out of memory range, cpu cycles exhaust etc  and these things occur beyond the knowledge of compressor.

Is it required
by the UDVM to ask the compressor to retransmit the corrupted
compressed message ? 

ANS: Dispatcher invokes UDVM when it receives the sigcomp message. The life of the UDVM then starts and ends with successful decompression/unsuccessful decompression. UDVm has no knowledge of the underlying transport and so, it cannot ask for retransmission.

Or is it possible to implement some kind
of FEC ( forward error correction ) at the UDVM to recover
errors ?
ANS: I really don't know about this. But my guess is that it could be possible.

Thank you.

Regards,
Kwang Mien

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

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

---

From: Kamal Deep Dham <[email-masked]>
Date: Tue, 14 May 2002 10:39:36 +0530

Hi,

It is not clear in RFC 3095 regarding the detection of first item type in ip extension
header list on decompressor side.  How will decompressor identify the first item
type in the ip extension header list as dynamic/static chain sent does not contain the next
header to be pointed to any extension headers.

please explain ..

-Kamal

---

From: Wang Hai Guang <[email-masked]>
Date: Wed, 15 May 2002 09:10:16 +0800 (SGT)

Hi.

In my understanding.

The first occet of the item, the next header field, carries the

protocol number of the item instead of the subsequent header. 

For example, for a GRE item, the next header field is 47.

After decompress, this field is changed to the protocol number of

the subsequent protocol number. 

Please refer to page 118, paragraph 5 for the information.

Best regards.

Haiguang

---

From: "kamaldeep dham" <[email-masked]>
Date: Wed, 15 May 2002 08:26:01 +0530

Hi,

Yes the information on page 118 para 5 says

"
   The value of the Next Header field corresponds to GRE (this value is 47
   according to the Assigned Internet Protocol Number section of
   [ASSIGNED]) when the uncompressed item is to be inserted in a list,
   and to the type of the subsequent header when the uncompressed item
   is in a Generic list.
"

Which in my view explains that the next header field will contain its
own value when a new item is inserted in a list (encoding 1). But it
also says that in generic list (encoding 0) the next header field contains
the value of subsequent header.

Also at page 112 last para says

"
   All communicated uncompressed extension header items indicate their
   own type in their Next Header field.
"
What do you infer with the above statement ??

My confusion is if the next header field contains its own value in the
scenario only when a new header is inserted in a list and to subsequent
header
in generic list then while sending a generic list how will decompressor come
to know about the first item type in ip extension list ???

br
-Kamal

-----Original Message-----
From: Wang Hai Guang [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 6:40 AM
To: Kamal Deep Dham
Cc: [email-masked]
Subject: Re: [rohc] List Compression Q?

Hi.

In my understanding.

Best regards.

Haiguang

---

From: Wang Hai Guang <[email-masked]>
Date: Wed, 15 May 2002 13:18:36 +0800 (SGT)

Hi.

In my implementation, I assume the next header filed in the

item only indicate its own type. After decompression, I change

the next header field to the type of subsequent header in the

list. 

Else how can we know the type of the first header.

Haiguang