Re: Question related to ROHC-TCP Profile
Raffles <[email protected]>
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <[email protected]> |
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.
-----------------------------------------------------------------
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc