Re: Question related to ROHC-TCP Profile

Hi,

Thanks for this. Although involved peripherally with RFC 4996 (due to
its connection with RFC 4997) I must repeat that I am not an expert on
RFC 4996. The below quote from 4996 is something which I had missed =(
Before reading your message I had thought that the only way to use ack
number scaling was if the compressor and decompressor at the same end
of the link talked to each other.

In the absence of a connection between the compressor and decompressor
at the same end of the link (and I must repeat I am not an expert), it
seems to me that there are two obvious approaches. One approach would
be to fix the scaling factor to a constant value based on the expected
usage of the link. For example if large file transfers are the norm it
could be fixed based on the MTU, or if VOIP was the norm it could be
based on the typical size of a VOIP packet. This is pretty limited in
effectiveness, depending on how uniform traffic tends to be, but it
should allow some benefit to be gained from ack-number scaling.

A more effective approach would be to observe the delta between the ack
numbers being used for subsequent packets, and set the scaling factor
based on this, retransmitting the ack_stride when it changes. However,
re-transmitting the ack_stride to the other end of the link is
expensive. The packet formats which communicate it are large (e.g.
tcp_dynamic, tcp_replicate, co_common). There is no point in using the
scaled ack number unless the flow has bursts of uniform sized packets
which result in an overall saving. If there are no such bursts then it
is cheaper to stick to formats such as rnd_3, which encode the
ack_number using lsb. Comparing rnd_4 to rnd_3 we see that rnd_4 saves
1 byte per packet by using ack number scaling (rnd_4 is 2 bytes long,
rnd_3 is 3 bytes long, 50% longer). Looking at co_common, we see it is
40 bits minimum plus 16 bits for the ack_stride is 56 bits, 7 bytes
(this ignores the other fields which may also be transmitted). This 7
bytes is 4 bytes longer than rnd_3, so we need a burst of at least 5
packets of the same size for the rnd_4 scaled ack number format to give
us a saving. Bearing this in mind I would suggest that the ack_stride
is only retransmitted after several packets have been seen where the
ack_stride has not changed. This is just a suggestion as to how I might
tackle this if I had to do it myself - I am sure you will come up with
ideas of your own.

I don't think I am likely to be able to help any further with this. I
will contact Mark, Ghyslain and Kris directly to see if I can get them
to respond on the list to this as I suspect that they are probably busy
with other things and not reading the list particularly closely at
present. In the meantime, L-E as a co-author of 4996, could you check
whether what I've said makes any sense?

Regards

Raffles

Gurushant wrote:

Hi Raffles,

Thanks for your detailed explanation. I
understand that, the Compressor needs to send the scaling factor to
Decompressor.But my doubt is what value the compressor will send as
scaling factor is the point of discussion.

As RFC 4996 says,

"The compressor MAY use the scaled acknowledgment number
encoding;what
value it will use as the scaling factor is up to the compressor implementation. In the case
where there is a co-located decompressor processing packets of the same TCP flow in the
opposite direction,the
scaling factor for the sequence number used for that flow can be used by the compressor to
determine a suitable scaling factor for the TCP Acknowledgment number for this flow"

In this case if Compressor tried to
determine scaling factor, then there is has to be interface between the
co located compressor and Decompressor. This kind of implementation
make mandatory to have interface between the Compressor and
De-compressor( colocated). There is design possibility, that interface
between the collocated compressor and Decompressor may not exist. Hence
for the compressor it is difficult determine the scaling factor from
the colocated Decompressor TCP sequence number for that flow in
opposite direction.

So I am thinking is there any other value
to determine the scaling factor in the compressor, so that we avoid the
interface between the colocated compressor and decompressor.

Thanks & Best Regards

Gurushant.Kotagi

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

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

Sent: Saturday, April 04, 2009 3:25 AM

To: pradeep shambhu

Cc: [email protected]

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

Hi,

Apologies, I did not take enough time answering previously and gave you
an answer which didn't quite make sense, being a combination of scaled
sequence number and scaled ack number! The answer was close but not
quite right. Thank you for bearing with me - I hope that at some point
one of the 4997 authors will chip in (ahem Mr. West, Ghyslain, Kris,
L-E). In the meantime here is another attempt at an answer from me. I
have just left Roke today having initially walked through the door 20
years ago and am currently celebrating, so there is a danger the below
may not be entirely accurate, but I'll do my best.

The scaling factor for the ack number is set by the other end of the
link sending it directly (ack_stride). Prior to receiving the
ack_stride from the other end, the ack_stride is initialised to zero to
prevent it being used (see the INITIAL section of the tcp encoding
method). In order to be able to use ack_stride it MUST have been
received from the other end of the link, with the other end sending a
packet to indicate its value.

I hope this helps, please do ask more questions if this does not help.

Regards

Raffles

PS Why am I checking the RoHC list in the middle of leaving drinks?!

pradeep shambhu wrote:

Hi,

Thanks for the response, I agree with your understanding that
scaled sequence number cannot be calculated without scaling factor. But
for scaled acknowledgement number, the compressor / decompresser pair
might not be available the information of scaling factor , because
packets are flowing in the opposite direction.

And initially for IR packets its difficult to get the scaling factor
for acknowledgement number. because scaling factor will not available.
Since TCP-SYN Packets will not have payload and until connection
established its unable to compress the packet.

So how to set scaling factor ? Do we need to calculate it by
subtracting from Packet size of packet received by the decompresser
side with value 1.Clarify the details.

Thanks and regards,

Pradeep Shambhu

On Thu, Apr 2, 2009 at 11:28 PM, Raffles
<[email protected] >
wrote:

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