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

From: Raffles <[email-masked]>
Date: Thu, 02 Apr 2009 18:58:36 +0100

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-masked]
https://www.ietf.org/mailman/listinfo/rohc

--
Raffles (Robert Finking)
m: 0789 463 9887
e: [email-masked]
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.
-----------------------------------------------------------------

---

From: "Gurushant" <[email-masked]>
Date: Fri, 3 Apr 2009 12:23:18 +0530

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-masked] [mailto:[email-masked]]On Behalf Of
Raffles
  Sent: Thursday, April 02, 2009 11:29 PM
  To: pradeep shambhu
  Cc: [email-masked]
  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-masked]
https://www.ietf.org/mailman/listinfo/rohc

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

        O                  O

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.

---

From: Raffles <[email-masked]>
Date: Fri, 03 Apr 2009 22:04:40 +0100

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-masked] [mailto:[email-masked]]On
Behalf Of Raffles

To: pradeep shambhu

Cc: [email-masked]

Hi,

I hope this helps.

Regards

Raffles

pradeep shambhu wrote:

Hi,

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

O O

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

O O

---

From: Raffles <[email-masked]>
Date: Fri, 03 Apr 2009 22:55:24 +0100

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-masked]> wrote:

Hi,

I hope this helps.

Regards

Raffles

pradeep shambhu wrote:

Hi,

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

O O

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

O O

---

From: "Gurushant" <[email-masked]>
Date: Sun, 5 Apr 2009 08:54:25 +0530

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-masked] [mailto:[email-masked]]On Behalf Of
Raffles
  Sent: Saturday, April 04, 2009 3:25 AM
  To: pradeep shambhu
  Cc: [email-masked]
  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.

  Regards

  Raffles

  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

      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-masked]
https://www.ietf.org/mailman/listinfo/rohc

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

        O                  O

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

        O                  O

---

From: Raffles <[email-masked]>
Date: Mon, 06 Apr 2009 12:20:58 +0100

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-----

To: pradeep shambhu

Cc: [email-masked]

Hi,

Regards

Raffles

pradeep shambhu wrote:

Hi,

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.

Thanks and regards,

Pradeep Shambhu

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

Hi,

I hope this helps.

Regards

Raffles

pradeep shambhu wrote:

Hi,

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

O O

---

From: Raffles <[email-masked]>
Date: Mon, 06 Apr 2009 13:45:07 +0100

Hi again,

Just to clarify, I think the strictest answer to your question is "it
is up to the implementor". Any implementation which conforms to RFC
4996 is fine. If so then any other implementation which also conforms
to RFC 4996 should be able to interoperate with it. Perhaps the most
important point to note here is that the ack_stride is initialised to 0
at the start of the flow:

INITIAL {
ack_stride =:= uncompressed_value(16, 0);
}

This sets the value of ack_stride in the context to be 16 bits wide and
set to zero, and allows the ack_stride to be sent using static encoding
from the outset with a value of 0, until you have set it. Apart from
this, it is entirely up to you what you do to set the ack_stride value.
As long as it conforms to RFC 4996 it will interoperate. It is up to
you to design a scheme for producing a value which will optimise the
compression, and which will correctly detect circumstances in which it
is more efficient not to send an ack_stride, but rather stick to using
lsb encoding.

I suspect that you wanted an answer that started like "You do it like
this...", but as always the RFC aims to specify "what" rather than
"how", to avoid placing any unnecessary restrictions on the
implementor. Nonetheless, I hope that the suggestions in this and my
previous message will help.

All the best

Regards

Raffles

Raffles wrote:

Hi,

Regards

Raffles

Gurushant wrote:

Hi Raffles,

As RFC 4996 says,

Thanks & Best Regards

Gurushant.Kotagi

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

From: [email-masked]
[mailto:[email-masked]]On
Behalf Of Raffles

To: pradeep shambhu

Cc: [email-masked]

Hi,

Regards

Raffles

pradeep shambhu wrote:

Hi,

Thanks and regards,

Pradeep Shambhu

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

Hi,

I hope this helps.

Regards

Raffles

pradeep shambhu wrote:

Hi,

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

O O