headers
Price, Richard | 2 Jun 2003 17:04
Picon

RE: linux constant IP ID field can't be compressed in prof ile 0x0001?

Hi,

I'm confused - is this a part of the final standard?

My interpretation of RFC 3095 is that the compressor subtracts the
sequence number from the IP-ID, and then sends the resulting offset
using W-LSB encoding. The decompressor reconstructs the original
IP-ID by decoding the offset and then adding the sequence number. In
particular, if the decompressor receives 0 LSBs of offset, it will
always assume that the offset is the same as the value stored in the
context - i.e. that the IP-ID is going up by 1 in every successive
packet.

Regards,

Richard

> -----Original Message-----
> From: zhigang.c.liu <at> nokia.com [mailto:zhigang.c.liu <at> nokia.com]
> Sent: Friday, May 30, 2003 8:14 PM
> To: micke <at> cs.arizona.edu; Lars-Erik.Jonsson <at> epl.ericsson.se;
> rohc <at> ietf.org
> Subject: RE: [rohc] linux constant IP ID field can't be compressed in
> profile 0x0001?
> 
> 
> > Since the IP ID field being constant is clearly a pattern, it seems
> > reasonable to demand that this pattern should be detected in the normal 
> > way patterns are detected. Thus, even if the existing WLSB encoding doesn't 
> > compress the constantly zero field very well, the compressor would still
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars-Erik Jonsson (EAB | 3 Jun 2003 09:59
Picon
Picon

RE: linux constant IP ID field can't be compressed in prof ile 0x0001?

Richard, Zhigang, and others,

I agree with Richard that this is indeed confusing. What has been
outlined as a potential solution by Micke and Zhigang might be a
good way to handle this, and something we can define for new
profiles. However, the profiles in 3095 do not specify this
behavior, and a compressor can thus not assume that the decompressor
will detect the pattern. The compressor must rather assume the
opposite, and send IP-ID.

We are working with standards here, solutions are important, but we
must also introduce them in our standards in a proper way.

Rgds,
/L-E

> -----Original Message-----
> From: Price, Richard [mailto:richard.price <at> roke.co.uk]
> Sent: den 2 juni 2003 17:04
> To: 'zhigang.c.liu <at> nokia.com'; micke <at> cs.arizona.edu; Lars-Erik Jonsson
> (EAB); rohc <at> ietf.org
> Subject: RE: [rohc] linux constant IP ID field can't be compressed in
> prof ile 0x0001?
> 
> 
> Hi,
> 
> I'm confused - is this a part of the final standard?
> 
> My interpretation of RFC 3095 is that the compressor subtracts the
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ghyslain Pelletier | 4 Jun 2003 10:19
Picon
Picon

ROHC-TCP: Update and some topics to be discussed

ROHCers,

The discussions regarding the ROHC-TCP profile need to be restarted on
this mailing list. Let me try to kickstart this...

An updated version of the draft describing the ROHC profile of TCP,
<draft-ietf-rohc-tcp-04.txt>, has been submitted. The following has been
updated:

- The normative section on context replication has been removed.
  Instead, the definition of the context replication mechanism
  has been submitted in a separate draft, mainly for clarity.

- A basic structure for the IR/IR-DYN packets has been proposed.
  This structure uses static and dynamic chains. See Section 5.5.1.
  See also issue #3 later in this mail.

- A basic structure for the IR-REPLICATE packet has been proposed.
  It follows the structure suggested in the context replication draft.
  See Section 5.5.3. See also issue #2 later in this mail.

- Feedback format and options for ROHC-TCP has been defined.
  See Section 5.5.4.

- Section 6 - Implementation parameter - has been removed.

Please comment on these changes and the updated version in general.

For the TCP profile to move forward, I have tried to summarize some of
the topics that require further discussions on the mailing list:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Price, Richard | 4 Jun 2003 16:41
Picon

RE: ROHC-TCP: Update and some topics to be discussed

Hi,

Please find attached some comments on Topic 2 (the context
replication mechanism).

Regards,

Richard

------------------------------------------------------------

Page 1: "context replication, an alternative to the context
initialization procedure found in ROHC"

I'd say "complement" rather than "alternative", as the context
replication mechanism works in conjunction with the existing
context establishment mechanisms.

Page 3: "as each new packet stream requires the entire headers
to be sent initially"

Pedantic comment - we can avoid sending the entire header even
in the IR packet, as a small number of fields can be inferred
at the decompressor (e.g. IP Payload Length etc.).

Page 4: "The fundamentals of general header compression may be
found in [RFC-3095]. These are assumed to be understood
throughout this document."

I'd like to clarify the above a little further. Is it only
(Continue reading)

Permalink | Reply | 1 comment |
headers
Price, Richard | 4 Jun 2003 18:19
Picon

Problem with RFC 3095 Extension Header encoding

Hi,

I'm currently attempting to add support for IP Extension Headers to
our ROHC-TCP implementation - the plan is to reuse the existing packet
formats from RFC 3095. However, I'm having some difficulty decoding the
compressed versions of the AH, ESP and GRE Sequence Numbers.

What isn't clear from the standard is the following:

1. What interpretation interval should I use to decode the sequence
   number LSBs?

2. Should the decoded sequence number be treated as an absolute value,
   or as an offset from the RTP Sequence Number?

If I've missed the relevant text in RFC 3095, please let me know!

Thanks,

Richard
Permalink | Reply | 0 comments |
headers
Yousuf.Saifullah | 4 Jun 2003 23:56
Picon

RE: ROHC-TCP: Update and some topics to be discussed

Hi Gyslain,

The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt):

- Section 3.2.2: What is "OPTIONAL improved forward transition"? I was not able to find any description for
this term.

- Section 3.2.2.1 - last two paras: NACK is not sent in response to IR-REPLICATE. Instead, it looks like that
it is a general failure information procedure for informing decompression of a subsequent packet not
IR-REPLICATE. I think these two paras are irrelevant to context replication. I'd suggest to either take
out these paras or explicitly mention that this is a general failure procedure.

- Section 3.3.2 - Third para: Could you please clarify when the compressor will be sending IR-REPLICATE
packets as subsequent packets after receiving ACK for successful decompression of the initial
IR-REPLICATE. The decompressor after successfully validating IR-REPLICATE will send ACK, which moves
the compressor from IR to CO state (taking ROHC-TCP state machine). I think in this state the compressor
will be sending compressed packets not IR-REPLICATE. 

- I think we can improve on failure mechanism mentioned in the above two sections. The draft mentions that if
the decompression of IR-REPLICATE fails, the decompressor will send STATIC NACK and the compressor MUST
refrain from IR-REPLICATE, in other words use IR packets. Moving to IR means sending more bytes compared
to IR-REPLICATE, hence degrading compression efficiency. If the decompression has failed due to
transmission error of IR-REPLICATE (case-1), then the decompressor is unnecessarily asking for IR. It
is better to ask for the retransmission of IR-REPLICATE and gain more compression efficiency. Not to
mention, retransmitting an already encoded packet would be faster for the compressor. It is also
possible that the decompression has failed because of the corruption in the base context (case-2). In
case-2 we definitely want to move to the IR packet, since there is no way to fix it without sending full
header. 
I'd propose that the decompressor should differentiate between the two cases. It can be done if we increase
the coverage of 8-bit CRC (section 3.4.1.2)to cover static and dynamic chain also. The CRC of an IR or
(Continue reading)

Permalink | Reply | 2 comments |
headers
Yousuf.Saifullah | 5 Jun 2003 01:22
Picon

RE: ROHC-TCP: Update and some topics to be discussed

Hi, 
I have some thoughts on some of the Richard's comments. Please search for [Yousuf] below.

Cheers,
Yousuf

-----Original Message-----
From: ext Price, Richard [mailto:richard.price <at> roke.co.uk]
Sent: Wednesday, June 04, 2003 9:41 AM
To: 'Ghyslain Pelletier'; rohc <at> ietf.org
Subject: RE: [rohc] ROHC-TCP: Update and some topics to be discussed

Hi,

Please find attached some comments on Topic 2 (the context
replication mechanism).

Regards,

Richard

------------------------------------------------------------

Page 1: "context replication, an alternative to the context
initialization procedure found in ROHC"

I'd say "complement" rather than "alternative", as the context
replication mechanism works in conjunction with the existing
context establishment mechanisms.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paulius.Meskauskas | 5 Jun 2003 08:23
Picon

Dynamic update of resources in SigComp

Hi,

I would like to get the clarification about the the dynamic
update of resources in the SigComp endpoints (I could not
find the clear answer in the RFC3320).

Is it possible that two SigComp endpoints using dynamic
compression updates i.e. decrease or increase sms,
dms or cpb values dynamically? And if it possible, how
the compartments can be synchronized?

best regards,
	paulius
Permalink | Reply | 0 comments |
headers
Lajos Zaccomer (ETH | 5 Jun 2003 08:34
Picon
Picon

RE: Dynamic update of resources in SigComp

Hi,

The updates of the parameters may happen at any time with the help of the returned parameters, but an
endpoint is not allowed to decrease its parameters, only to keep the originals or to increase them.

As you cannot force another endpoint to send its parameters, true synchronization is impossible (lack of
signalling - NACK was partly introduced to eliminate this shortcoming). If a compartment is out of
synchron, the only thing it can do is to fall back to the initial state, just as if nothing has happened before.

BR/Zacco

-----Original Message-----
From: Paulius.Meskauskas <at> nokia.com [mailto:Paulius.Meskauskas <at> nokia.com]
Sent: 2003. június 5. 8:23
To: rohc <at> ietf.org
Subject: [rohc] Dynamic update of resources in SigComp

Hi,

I would like to get the clarification about the the dynamic
update of resources in the SigComp endpoints (I could not
find the clear answer in the RFC3320).

Is it possible that two SigComp endpoints using dynamic
compression updates i.e. decrease or increase sms,
dms or cpb values dynamically? And if it possible, how
the compartments can be synchronized?

best regards,
	paulius
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ghyslain Pelletier | 5 Jun 2003 15:11
Picon
Picon

Re: ROHC-TCP: Update and some topics to be discussed

Hi Richard,

Thanks for your comments! I've also commented in-line. I will get back
to the ones I haven't answered in this mail in a later mail.

/Ghyslain

"Price, Richard" wrote:
> 
[snip]
> ------------------------------------------------------------
> 
> Page 1: "context replication, an alternative to the context
> initialization procedure found in ROHC"
> 
> I'd say "complement" rather than "alternative", as the context
> replication mechanism works in conjunction with the existing
> context establishment mechanisms.

Absolutely. Text will be fixed.

> Page 3: "as each new packet stream requires the entire headers
> to be sent initially"
> 
> Pedantic comment - we can avoid sending the entire header even
> in the IR packet, as a small number of fields can be inferred
> at the decompressor (e.g. IP Payload Length etc.).

Absolutely. I can change the wording.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane