Re: Question related to ROHC-TCP Profile

Raffles <[email protected]>
Newsgroups gmane.ietf.rohc
Message-ID <[email protected]>
Hi Gurushant,

I feel I am beyond my knowledge of RFC 4997 at this point, but a
question to ask yourself: in case #2 if the compressor chooses a
suitable parameter itself, how does the decompressor know what number
the compressor chose?

Raffles

Gurushant wrote:

Hello Raffle,

Thank for providing good info, But I have
one question. In case of #2, if it is not possible to receive the
sequence number( for scaling factor) from other end link, since it
implementation specific. Is it OK if Compressor use any other suitable
parameter as scaling factor. In this case any suggestion to use any
other parameter as scaling factor?

Regards,

Gurushant

-----Original Message-----

From: [email protected] [ mailto:[email protected] ]On
Behalf Of Raffles

Sent: Thursday, April 02, 2009 11:29 PM

To: pradeep shambhu

Cc: [email protected]

Subject: Re: [rohc] Question related to ROHC-TCP Profile

Hi,

Thanks for the question. I must confess I was only involved in RFC 4996
peripherally, RFC 4997 was my main focus. However, my understanding is
that you are half right. The scaled sequence number cannot be used
until the scaling factor is known. This means that any formats which
use the scaled sequence number cannot be used until the transmitted
scaling factor has been received from the other end of the link.
Instead a format which encodes the sequence number directly must be
used. For example compressed format rnd_1 may be suitable if all the
other encodings succeed:

// Send LSBs of sequence number
COMPRESSED rnd_1 {
discriminator =:= '101110' [ 6 ];
seq_number =:= lsb(18, 65535) [ 18 ];
msn =:= lsb(4, 4) [ 4 ];
psh_flag =:= irregular(1) [ 1 ];
header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
}

However, at the very start, even the above encoding won't work. The
"lsb" encoding won't work because the sequence number is not given an
initial value (see the INITIAL section), so the context will be
undefined. "lsb" encoding needs valid context in order to work. So,
there are three phases

1. Prior to context, a random encoding of sequence number must be used,
such as co_common, which encodes the sequence number without needing
any context

2. After context has been established but prior to receiving the
transmitted scaling factor from the other end of the link, any encoding
can be used that encodes the sequence number directly

3. After the scaling factor has been received from the other end of the
link, any encoding method can be used (of course a good implementation
would aim to use the most efficient encoding)

This is my best understanding after a quick look at 4996, but it is not
a definitive answer. Others on the list who know 4997 and/or TCP better
than I do may be able to confirm or deny whether the above is correct.

I hope this helps.

Regards

Raffles

pradeep shambhu wrote:

Hi,

In ROHC-TCP [4996] page no-33, Scaling factor will not be
available for scaled acknowledgement number , because packets are
flowing in the opposite direction. but how to use the explicit scaling
factor ? Do we need to take the random scaling factor value initially ?

----------

_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc

--
Raffles (Robert Finking)
m: 0789 463 9887
e: [email protected]
w: gluft.com

O O
OOOOOO O O O OOOOOO OOOOO
O O O O O OOOOO O
OOOOOO O OOOOOO O O
OOOOOO
we care about software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.
Please consider the environment before printing this email.
-----------------------------------------------------------------

The information contained in this electronic message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended
recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy
all copies of this message and any attachments contained in it.

--
Raffles (Robert Finking)
m: 0789 463 9887
e: [email protected]
w: gluft.com

O O
OOOOOO O O O OOOOOO OOOOO
O O O O O OOOOO O
OOOOOO O OOOOOO O O
OOOOOO
we care about software

-----------------------------------------------------------------
Gluft Ltd. Registered No.: 6795336
The information contained in this e-mail and any attachments is
proprietary to Gluft Ltd and must not be passed to any third
party without permission. This communication is for information
only and shall not create or change any contractual relationship.
Please consider the environment before printing this email.
-----------------------------------------------------------------

_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.