Re: Question related to ROHC-TCP Profile

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




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