Thank for providing good info, But I have one qu= estion.=20 In case of #2, if it is not possible to receive the sequence number( for sc= aling=20 factor) from other end link, since it implementation specific. Is it O= K if=20 Compressor use any other suitable parameter as scaling factor. In this= case=20 any suggestion to use any other parameter as scaling factor?<= /DIV>

Regards,

Gurushant

-----Original Message-----
From: rohc-bounces@ietf.org=20 [mailto:rohc-bounces@ietf.org]On Behalf Of Raffles
Sent:=20 Thursday, April 02, 2009 11:29 PM
To: pradeep shambhu
Cc:= =20 rohc@ietf.org
Subject: Re: [rohc] Question related to ROHC-TCP=20 Profile

Hi,

Thanks for the question. I must co= nfess=20 I was only involved in RFC 4996 peripherally, RFC 4997 was my main focus.=20 However, my understanding is that you are half right. The scaled sequence=20 number cannot be used until the scaling factor is known. This means that = any=20 formats which use the scaled sequence number cannot be used until the=20 transmitted scaling factor has been received from the other end of the li= nk.=20 Instead a format which encodes the sequence number directly must be used.= For=20 example compressed format rnd_1 may be suitable if all the other encoding= s=20 succeed:
   // Send LSBs of sequence number
   COMPRESSED rnd_1 {
     discriminator =3D:=3D '101110'                        [ 6 ];
     seq_number    =3D:=3D lsb(18, 65535)                  [ 18 ];
     msn           =3D:=3D lsb(4, 4)                       [ 4 ];
     psh_flag      =3D:=3D irregular(1)                    [ 1 ];
     header_crc    =3D:=3D crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
     ENFORCE((ip_id_behavior.UVALUE =3D=3D IP_ID_BEHAVIOR_RANDOM) ||
             (ip_id_behavior.UVALUE =3D=3D IP_ID_BEHAVIOR_ZERO));
   }
However, at the very start, even the above encoding won't work. The=20 "lsb" encoding won't work because the sequence number is not given an ini= tial=20 value (see the INITIAL section), so the context will be undefined. "lsb"=20 encoding needs valid context in order to work. So, there are three=20 phases
1. Prior to context, a random encoding of sequence number must = be=20 used, such as co_common, which encodes the sequence number without needin= g any=20 context
2. After context has been established but prior to receiving t= he=20 transmitted scaling factor from the other end of the link, any encoding c= an be=20 used that encodes the sequence number directly
3. After the scaling fa= ctor=20 has been received from the other end of the link, any encoding method can= be=20 used (of course a good implementation would aim to use the most efficient=20 encoding)

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

I hope this=20 helps.

Regards

Raffles

pradeep shambhu wrote:=20 Hi,

In ROHC-TCP [4996] page=20 no-33, Scaling factor will not be available for scaled acknowledgement=20 number , because packets are flowing in the opposite direction. but how= to=20 use the explicit scaling factor ? Do we need to take the random scaling=20 factor value initially ?
_______________________________________________ Rohc mailing list Rohc@ietf= .org https://www.ietf.org/mailman/listinfo/rohc

--=20
Raffles (Robert Finking)
m: 0789 463 9887
e: ra=
ffles@gluft.com
w: gluft.com
        =20
        O                  O
OOOOOO  O  O    O OOOOOO OOOOO
O    O  O  O    O OOOOO    O
OOOOOO  O  OOOOOO O        O      =20
OOOOOO=20
     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=20
use of the addressee(s) and may contain proprietary, confidential or privil=
eged information. If you are not the intended
 recipient, you should not disseminate, distribute or copy this e-mail. Ple=
ase notify the sender immediately and destroy
 all copies of this message and any attachments contained in it.

------=_NextPart_000_0015_01C9B456.F94D0010-- From raffles@gluft.com Fri Apr 3 14:02:33 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B32528C133 for ; Fri, 3 Apr 2009 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QfpdbRCxdXD for ; Fri, 3 Apr 2009 14:02:32 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 887113A6940 for ; Fri, 3 Apr 2009 14:02:31 -0700 (PDT) Received: from [192.168.1.64] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1LpqY02jEw-0004YN; Fri, 03 Apr 2009 23:03:33 +0200 Message-ID: <49D679E8.5040205@gluft.com> Date: Fri, 03 Apr 2009 22:04:40 +0100 From: Raffles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gurushant@tataelxsi.co.in References: <253F2E97701B4E8387668A8B3C465560@telxsi.com> In-Reply-To: <253F2E97701B4E8387668A8B3C465560@telxsi.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+88zEfV4H8Ic8vdCZ+4Cb/DBaPvP2wgwBtr2T /yvJ/zdiihlPpfYUKLeNXhjfhyPquURxpa/08TyXvj+6ozIp2Z tNpDNCXkXEgMAVFxUZ+CtmDpS9vWXMQ Cc: rohc@ietf.org, 'pradeep shambhu' Subject: Re: [rohc] Question related to ROHC-TCP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:02:33 -0000 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: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Raffles
Sent: Thursday, April 02, 2009 11:29 PM
To: pradeep shambhu
Cc: rohc@ietf.org
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
Rohc@ietf.org
https://www.ietf.org/mailman/listinfo/rohc
  
-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: raffles@gluft.com
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: raffles@gluft.com
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 raffles@gluft.com Fri Apr 3 14:53:16 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825AD3A69AE for ; Fri, 3 Apr 2009 14:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibO0mNYHPWD9 for ; Fri, 3 Apr 2009 14:53:15 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 384AB3A68F0 for ; Fri, 3 Apr 2009 14:53:13 -0700 (PDT) Received: from [192.168.1.64] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1LprL42sN4-0007Jq; Fri, 03 Apr 2009 23:54:14 +0200 Message-ID: <49D685CC.9060203@gluft.com> Date: Fri, 03 Apr 2009 22:55:24 +0100 From: Raffles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pradeep shambhu References: <49D4FCCC.1010702@gluft.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19hjsdtn4fDL6zOxgTdKxJ1GGtsEVJbtzInncn rN4bwUOrf00BOii71PeCsINVzNhtlITXN5cNTFq//iErWPw+c4 SpZBQY2WZZk4ANwIsDRy5fc8fhfoVEA Cc: rohc@ietf.org Subject: Re: [rohc] Question related to ROHC-TCP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 21:53:16 -0000 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 <raffles@gluft.com> 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
Rohc@ietf.org
https://www.ietf.org/mailman/listinfo/rohc
  
-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: raffles@gluft.com
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: raffles@gluft.com
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 prvs=339c82286=gurushant@tataelxsi.co.in Sat Apr 4 20:23:35 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398F33A67CC for ; Sat, 4 Apr 2009 20:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt8xIwOonlDk for ; Sat, 4 Apr 2009 20:23:33 -0700 (PDT) Received: from smtpout1.vsnlxchange.com (smtpout1.vsnlxchange.com [59.163.96.2]) by core3.amsl.com (Postfix) with ESMTP id 1BC0F3A687C for ; Sat, 4 Apr 2009 20:23:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,388,1233513000"; d="scan'208,217";a="34232361" Received: from unknown (HELO VSNLCHNFE002.VSNLXCHANGE.COM) ([10.72.10.12]) by smtpout1.vsnlxchange.com with ESMTP; 05 Apr 2009 08:51:50 +0530 Received: from gurushanttemp ([122.24.128.48]) by VSNLCHNFE002.VSNLXCHANGE.COM with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Apr 2009 08:54:30 +0530 From: "Gurushant" To: "'Raffles'" Date: Sun, 5 Apr 2009 08:54:25 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C9B5CC.1FD6DAA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <49D685CC.9060203@gluft.com> Importance: Normal X-OriginalArrivalTime: 05 Apr 2009 03:24:30.0540 (UTC) FILETIME=[084B90C0:01C9B59E] Cc: rohc@ietf.org, 'pradeep shambhu' Subject: Re: [rohc] Question related to ROHC-TCP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gurushant@tataelxsi.co.in List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 03:34:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C9B5CC.1FD6DAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Raffles Sent: Saturday, April 04, 2009 3:25 AM To: pradeep shambhu Cc: rohc@ietf.org 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 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 Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc -- Raffles (Robert Finking) m: 0789 463 9887 e: raffles@gluft.com 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: raffles@gluft.com 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. ----------------------------------------------------------------- ------=_NextPart_000_0064_01C9B5CC.1FD6DAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Raffles,

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

As RFC 4996 says,

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

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

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

Thanks & Best Regards =
Gurushant.Kotagi

-----Original Message-----
From: = rohc-bounces@ietf.org=20 [mailto:rohc-bounces@ietf.org]On Behalf Of = Raffles
Sent:=20 Saturday, April 04, 2009 3:25 AM
To: pradeep = shambhu
Cc:=20 rohc@ietf.org
Subject: Re: [rohc] Question related to = ROHC-TCP=20 Profile

Hi,

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

The scaling = factor for=20 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=20 ack_stride is initialised to zero to prevent it being used (see the = INITIAL=20 section of the tcp encoding method). In order to be able to use = ack_stride it=20 MUST have been received from the other end of the link, with the other = end=20 sending a packet to indicate its value.

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

Regards

Raffles

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

pradeep shambhu wrote:=20 Hi,

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

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

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

Thanks and regards,

Pradeep Shambhu = =20

On Thu, Apr 2, 2009 at 11:28 PM, Raffles = <raffles@gluft.com> wrote:

Hi,

Thanks for = the question.=20 I must confess I was only involved in RFC 4996 peripherally, RFC = 4997 was=20 my main focus. However, my understanding is that you are half = right. The=20 scaled sequence number cannot be used until the scaling factor is = known.=20 This means that any formats which use the scaled sequence number = cannot be=20 used until the transmitted scaling factor has been received from = the other=20 end of the link. Instead a format which encodes the sequence = number=20 directly must be used. For example compressed format rnd_1 may be = suitable=20 if all the other encodings succeed:
// Send LSBs of = sequence number COMPRESSED rnd_1 { discriminator =3D:=3D '101110' [ 6 ]; seq_number =3D:=3D lsb(18, 65535) [ 18 ]; msn =3D:=3D lsb(4, 4) [ 4 ]; psh_flag =3D:=3D irregular(1) [ 1 ]; header_crc =3D:=3D crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ENFORCE((ip_id_behavior.UVALUE =3D=3D IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE =3D=3D IP_ID_BEHAVIOR_ZERO)); }
However, at the very start, even the above encoding won't = work.=20 The "lsb" encoding won't work because the sequence number is not = given an=20 initial value (see the INITIAL section), so the context will be = undefined.=20 "lsb" encoding needs valid context in order to work. So, = there are=20 three phases
1. Prior to context, a random encoding of sequence = number=20 must be used, such as co_common, which encodes the sequence number = without=20 needing any context
2. After context has been established but = prior to=20 receiving the transmitted scaling factor from the other end of the = link,=20 any encoding can be used that encodes the sequence number = directly
3.=20 After the scaling factor has been received from the other end of = the link,=20 any encoding method can be used (of course a good implementation = would aim=20 to use the most efficient encoding)

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

I hope this=20 helps.

Regards

Raffles

pradeep shambhu wrote: =

Hi,

In ROHC-TCP [4996] page = no-33,=20 Scaling factor will not be available for scaled acknowledgement = number ,=20 because packets are flowing in the opposite direction. but how = to use=20 the explicit scaling factor ? Do we need to take the random = scaling=20 factor value initially ?
_______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc

--=20 Raffles (Robert Finking) m: 0789 463 9887 e: raffles@gluft.com w: gluft.com =20 O O OOOOOO O O O OOOOOO OOOOO O O O O O OOOOO O OOOOOO O OOOOOO O O =20 OOOOOO=20 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. -----------------------------------------------------------------

--=20
Raffles (Robert Finking)
m: 0789 463 9887
e: raffles@gluft.com
w: gluft.com
        =20
        O                  O
OOOOOO  O  O    O OOOOOO OOOOO
O    O  O  O    O OOOOO    O
OOOOOO  O  OOOOOO O        O      =20
OOOOOO=20
     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.
-----------------------------------------------------------------

------=_NextPart_000_0064_01C9B5CC.1FD6DAA0-- From Priyanka.RAWAT@telecom-bretagne.eu Sun Apr 5 16:24:42 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70373A6B6B for ; Sun, 5 Apr 2009 16:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJAfGlprcBiG for ; Sun, 5 Apr 2009 16:24:42 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id F24913A67F6 for ; Sun, 5 Apr 2009 16:24:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n35NPnKw004340; Mon, 6 Apr 2009 01:25:50 +0200 Received: from courrier.enst-bretagne.fr (smtps.telecom-bretagne.eu [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n35NPiAQ004334; Mon, 6 Apr 2009 01:25:47 +0200 Received: from telecom-bretagne.eu (smtps.telecom-bretagne.eu [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n35NPZWE010752; Mon, 6 Apr 2009 01:25:36 +0200 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Mon, 06 Apr 2009 01:25:35 +0200 Message-ID: <20090406012535.28807fsji3cxiuww@webmail.telecom-bretagne.eu> Date: Mon, 06 Apr 2009 01:25:35 +0200 From: Priyanka.RAWAT@telecom-bretagne.eu To: Rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: priyanka.rawat@telecom-bretagne.eu Subject: [rohc] Rohc over IP tunnel X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 23:24:42 -0000 Hello All We have submitted a new draft to IETF. This document proposes a method to use ROHC over IP tunnel. The draft is available at http://tools.ietf.org/search/draft-rawat-hc-tunneling-00 Since we would like to continue this work further, it will be interesting for us to receive feedback on the draft and initiate discussion at IETF. Please let us know your opinion. Regards Priyanka Rawat IT/TELECOM Bretagne From larsman@home.se Mon Apr 6 00:24:12 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48883A6B62 for ; Mon, 6 Apr 2009 00:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.882 X-Spam-Level: * X-Spam-Status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBG5ZuWQkwdd for ; Mon, 6 Apr 2009 00:24:12 -0700 (PDT) Received: from spsmtp02oc.mail2world.com (spsmtp02oc.mail2world.com [74.202.142.148]) by core3.amsl.com (Postfix) with ESMTP id EBEA43A6A6E for ; Mon, 6 Apr 2009 00:24:08 -0700 (PDT) Received: from mail pickup service by spsmtp02oc.mail2world.com with Microsoft SMTPSVC; Mon, 6 Apr 2009 00:23:32 -0700 auth-sender: larsman@home.se Received: from 90.227.154.194 unverified ([90.227.154.194]) by spsmtp02oc.mail2world.com with Mail2World SMTP Server; Mon, 06 Apr 2009 00:23:31 -0700 Message-ID: <000701c9b688$d5841360$8700a8c0@jymden3> From: "Lars-Erik Jonsson" To: , References: <20090406012535.28807fsji3cxiuww@webmail.telecom-bretagne.eu> Date: Mon, 6 Apr 2009 09:25:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 06 Apr 2009 07:23:32.0337 (UTC) FILETIME=[9715DE10:01C9B688] Cc: priyanka.rawat@telecom-bretagne.eu Subject: Re: [rohc] Rohc over IP tunnel X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 07:24:12 -0000 This submission does not make much sense to me, as ROHC already provides mechanisms for compression of tunneling headers (outer headers). To support tunneling was a requirement stated already by RFC 3096, and thus addressed by RFC 3095. Since then, compression of IP tunneling headers has been provided by all ROHC profiles. Can you explain what you mean ROHC is missing, not doing correcty or efficiently, or by which other means you think ROHC is not sufficient in terms of IP tunnel compression? BR /L-E ----- Original Message ----- From: To: Cc: Sent: Monday, April 06, 2009 1:25 AM Subject: [rohc] Rohc over IP tunnel > Hello All > > We have submitted a new draft to IETF. This document proposes a method to > use ROHC over IP tunnel. > > The draft is available at > http://tools.ietf.org/search/draft-rawat-hc-tunneling-00 > > Since we would like to continue this work further, it will be interesting > for us to receive feedback on the draft and initiate discussion at IETF. > > Please let us know your opinion. > > Regards > Priyanka Rawat > > IT/TELECOM Bretagne > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc From raffles@gluft.com Mon Apr 6 04:18:58 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF313A6C3D for ; Mon, 6 Apr 2009 04:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=-1.621, BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, J_CHICKENPOX_93=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWQxLodfz0+l for ; Mon, 6 Apr 2009 04:18:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 656B83A6C3B for ; Mon, 6 Apr 2009 04:18:55 -0700 (PDT) Received: from [192.168.1.64] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Lqmrt3KiQ-0001x1; Mon, 06 Apr 2009 13:19:59 +0200 Message-ID: <49D9E59A.3070308@gluft.com> Date: Mon, 06 Apr 2009 12:20:58 +0100 From: Raffles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gurushant@tataelxsi.co.in References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18bunyBUbW4Vh3x/WPJxWAftF18b82yPL5Hqej MzHEJ9/vnkDQWI+H0GTupMfpfzlYFLCYWG80+deTfG6St9FuKH igm+oLyAnaxGQ4hJdxbrP9xFATt+VS4 Cc: Lars-Erik Jonsson , rohc@ietf.org, 'pradeep shambhu' Subject: Re: [rohc] Question related to ROHC-TCP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 11:18:58 -0000 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: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Raffles
Sent: Saturday, April 04, 2009 3:25 AM
To: pradeep shambhu
Cc: rohc@ietf.org
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 <raffles@gluft.com> 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
Rohc@ietf.org
https://www.ietf.org/mailman/listinfo/rohc
  

-- 
Raffles (Robert Finking)
m: 0789 463 9887
e: raffles@gluft.com
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 prvs=340b301c9=narendranv@tataelxsi.co.in Mon Apr 6 02:51:44 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AAE3A6C19; Mon, 6 Apr 2009 02:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.489 X-Spam-Level: * X-Spam-Status: No, score=1.489 tagged_above=-999 required=5 tests=[AWL=-2.788, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MY_CID_AND_ARIAL2=1.46, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNKic1iaQLYB; Mon, 6 Apr 2009 02:51:43 -0700 (PDT) Received: from smtpout2.vsnlxchange.com (smtpout2.vsnlxchange.com [59.163.96.4]) by core3.amsl.com (Postfix) with ESMTP id A12923A6BB4; Mon, 6 Apr 2009 02:51:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,388,1233513000"; d="gif'147?scan'147,208,217,147";a="34872711" Received: from unknown (HELO VSNLCHNFE001.VSNLXCHANGE.COM) ([10.72.10.11]) by smtpout2.vsnlxchange.com with ESMTP; 06 Apr 2009 15:05:31 +0530 Received: from narendranv ([59.160.207.5]) by VSNLCHNFE001.VSNLXCHANGE.COM with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:22:46 +0530 From: "narendranv" To: Date: Mon, 6 Apr 2009 15:22:45 +0530 Message-ID: <002401c9b69d$6fee51e0$2e1c320a@telxsi.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0025_01C9B6CB.89A68DE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-OriginalArrivalTime: 06 Apr 2009 09:52:46.0079 (UTC) FILETIME=[6FEE78F0:01C9B69D] X-Mailman-Approved-At: Mon, 06 Apr 2009 05:16:41 -0700 Cc: rohc@ietf.org Subject: [rohc] Clarrification needed regarding Multiple IP levels handling in IP Profile. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: narendranv@tataelxsi.co.in List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:52:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C9B6CB.89A68DE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0026_01C9B6CB.89A68DE0" ------=_NextPart_001_0026_01C9B6CB.89A68DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear RoHCers, I need clarrification regarding handling of Multiple IP Levels in Profile -0x0004. Let us assume 3 level IP as Input IP Packet: Outermost Ip Outer IP level Innermost IP level RFC3843 says : Sec3.2. Handling Multiple Levels of IP Headers: " The IP-only profile defined in this document goes one step further and supports compression of an arbitrary number of IP levels. This is achieved by adding a dynamic chain to the general format of compressed headers, to include the header part of each IP level in excess of the first two." " For compressed headers, the information related to the initial two IP headers is carried as for the IP/UDP profile, and a chain of dynamic header information is added to the end of the compressed header for each and every additional IP header. " Q.1) Which IP level should be considered as Additional IP Level in Profile- 0x004. Is "IP1" considered as Additional level or "IP3" should be considered as Additional level for Implementation? Q.2) Is this interpretation correct? IP2 and IP3 levels are compressed and respective fileds are filled in the compressed header and IP1 is added as additonal dynamic chain at the end of general format of compressed header. Pls share your valuable opinions on the same. Thanks & Regards, Narendran. The information contained in this electronic message and any attachments to= this message are intended for the exclusive=20 use of the addressee(s) and may contain proprietary, confidential or privil= eged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Ple= ase notify the sender immediately and destroy all copies of this message and any attachments contained in it. ------=_NextPart_001_0026_01C9B6CB.89A68DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear RoHCers,

I need clarrification=20 regarding handling of Multiple IP Levels in Profile=20 -0x0004.

Let = us=20 assume 3 level IP as Input IP=20 Packet:

=20 Ou= termost=20 Ip Oute= r IP=20 level = ; =20 Innermost IP level

RFC3843 says : Sec3.2. Handling Multiple Levels = of IP=20 Headers:

<= /P>
"&nbs= p; =20 The IP-only profile defined in this document goes one step=20 further

= ; =20 and supports compression of an arbitrary number of IP levels. This

= ; =20 is achieved by adding a dynamic chain to the general format=20 of

= ; =20 compressed headers, to include the header part of each IP level=20 in

= ; =20 excess of the first two."

<= /P>
"&nbs= p; =20 For compressed headers, the information related to the initial two=20 IP

= ; =20 headers is carried as for the IP/UDP profile, and a chain of=20 dynamic

= ; =20 header information is added to the end of the compressed header=20 for

= ; =20 each and every additional IP header. "

Q.1)=20 Which IP level should be considered as Additional IP Level in Profile-=20 0x004.

    Is "IP1" considered as=20 Additional level or "IP3" should be considered as Additional=20

     level for=20 Implementation?

Q.2)=20 Is this interpretation correct?

     IP2 and IP3 levels= are=20 compressed and respective fileds are filled in the compressed header=20

     and IP1 is added as add= itonal=20 dynamic chain at=20 the end of general format of compressed=20 header.

Pls=20 share your valuable opinions on the same.=

Thanks &=20 Regards,

Narendran.

= ;=20
The information contained in this electronic message and any attachments to= this message are intended for the exclusive=20 use of the addressee(s) and may contain proprietary, confidential or privil= eged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Ple= ase notify the sender immediately and destroy all copies of this message and any attachments contained in it.
------=_NextPart_001_0026_01C9B6CB.89A68DE0-- ------=_NextPart_000_0025_01C9B6CB.89A68DE0 Content-Type: image/gif; name="clip_image001.gif" Content-Transfer-Encoding: base64 Content-ID: <913122609@06042009-3718> R0lGODlhswE0AHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQCx ATIAhIGBgQAAAP///wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwL/hI+pF+sPo5w0toqz 3hzcDobiSJbm6aHqanzsC7fxTNc27d66k+9+1fsJh8RYsFg7IovKpfMJfTSjqCnVZr1qt7osF+T9 rsLisllEPlPSanT7DXfH5fMXu44/3/MyvmrvFxgFmEcouGB4qCiUONe4mAIpKfYIV6l4Oan5tynV yZH5KQo2mhAaeFqqKhXQ6vqq+SrbuoowK1ubW3VLG8ubqvYLrDv622lM7MGbzIx2+7nMHN1MrfEM PUt9Xc2NgVsMW/3dTT4xju3KfV7OztNbmt4d306P+A4+7Hhfz9+3ml8HYL+BBAsa/CMsocKFDBs6 fAgxosSJFCtavIgxo8aN/xwXCvgIMqTIkSRLmjyJMqXIACpbunwJsyTLmDRr2rw5cibOnTxN6uwJ 1GWroER7/iyKNObRpEybglzqNGpOqU2HUr26EqvWj1C3ehX69WrXsErHkg1q9qxRtWxPpm178y1c mXLnKrVbtC5esXvR9hWq9y/KwIJ9FlZL+PBUxT4TM376uKbjyDsnP7bc1irdXyQxJzWbcKVmuKCF iR5NWabbVwIUhpwVtjRrla7KEkbd+TXkp7gRp/ypM/hu0r91cx3eOrXb4saPI0/ufGtaq707O67e mHl06M/ZvgVuHDzxwc25l1eelXz5o+K3813NtS52+C/nb2/v3rt281A9E//9vt5i6OWmHnJLCded VNPNRF2DLA2lWW28ASchYPvhZ15mF56XH1kAGpjegAQuF2CIGFK1oIQQMvhgfC422BqLMcJkH3/d +ZfXhh3i6FeB3LFXI2UfgmhiggoO1hWMMs6ImpK3DRljbzz2SGJ8UuIF5WwjimjkeScGV6F0SOZU YYQymukkjVlWOR6bY01JpWFdzpkalDYWedaCos3oYp8rvnjmkzqqZteaW85lKJtcZngohieK2ViT WrLo4GuzyVJfoofq52N/HHo4KKGL0hkde176xhOcma7Gi3WqVsbqLaeFiepmsloapJAthXmrlbl+ BuuruwqL6KiKGhsnsp8/RvYresS2qWyy0TIq5LMaTrsstpJpS2phzSpnLafcwjpuuFF9W+e41KpL o7rmOtVRvPLOS2+99t6Lb7763lsAADs= ------=_NextPart_000_0025_01C9B6CB.89A68DE0-- From raffles@gluft.com Mon Apr 6 05:43:25 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494E13A6C54 for ; Mon, 6 Apr 2009 05:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.249 X-Spam-Level: * X-Spam-Status: No, score=1.249 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, J_CHICKENPOX_93=0.6, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q51XIDuY2ZzR for ; Mon, 6 Apr 2009 05:43:23 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 5BB273A6C5E for ; Mon, 6 Apr 2009 05:43:00 -0700 (PDT) Received: from [192.168.1.64] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1LqoBE3pFr-0004TG; Mon, 06 Apr 2009 14:44:01 +0200 Message-ID: <49D9F953.2080509@gluft.com> Date: Mon, 06 Apr 2009 13:45:07 +0100 From: Raffles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: gurushant@tataelxsi.co.in References: <49D9E59A.3070308@gluft.com> In-Reply-To: <49D9E59A.3070308@gluft.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+6O3/OaUu9z0dD1DJp5OOPWlTpy8MIGiJebp7 Ju9X7bAW9g7wNR57ERy5sZeQRrEEp9ldtstRB1F/wAw/NDjCgA bHuCm9XN9pOZL1a9NVDLfDWzJ/eYTQM Cc: Lars-Erik Jonsson , rohc@ietf.org, 'pradeep shambhu' Subject: Re: [rohc] Question related to ROHC-TCP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:43:25 -0000 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,

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: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org]On Behalf Of Raffles
Sent: Saturday, April 04, 2009 3:25 AM
To: pradeep shambhu
Cc: rohc@ietf.org
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 <raffles@gluft.com> 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 Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc

-- Raffles (Robert Finking) m: 0789 463 9887 e: raffles@gluft.com 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 Priyanka.RAWAT@telecom-bretagne.eu Mon Apr 6 16:14:13 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CA223A6BF4 for ; Mon, 6 Apr 2009 16:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.945, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RnP5DLrx11p for ; Mon, 6 Apr 2009 16:14:08 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by core3.amsl.com (Postfix) with ESMTP id 231853A67AE for ; Mon, 6 Apr 2009 16:14:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2006.08.14) with ESMTP id n36NFHLj002878; Tue, 7 Apr 2009 01:15:17 +0200 Received: from courrier.enst-bretagne.fr (smtps.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2008.01.11) with ESMTP id n36NFBuP002855; Tue, 7 Apr 2009 01:15:14 +0200 Received: from telecom-bretagne.eu (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2006.06.07) with ESMTP id n36NF2n4016577; Tue, 7 Apr 2009 01:15:03 +0200 Received: from srv-disi-b1-02.priv.enst-bretagne.fr (srv-disi-b1-02.priv.enst-bretagne.fr [10.29.96.3]) by webmail.telecom-bretagne.eu (Horde Framework) with HTTP; Tue, 07 Apr 2009 01:15:02 +0200 Message-ID: <20090407011502.134473karxildvcw@webmail.telecom-bretagne.eu> Date: Tue, 07 Apr 2009 01:15:02 +0200 From: Priyanka.RAWAT@telecom-bretagne.eu To: Lars-Erik Jonsson References: <20090406012535.28807fsji3cxiuww@webmail.telecom-bretagne.eu> <000701c9b688$d5841360$8700a8c0@jymden3> In-Reply-To: <000701c9b688$d5841360$8700a8c0@jymden3> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) /ENSTB X-Originating-IP: 192.44.77.81 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: Rohc@ietf.org Subject: Re: [rohc] Rohc over IP tunnel X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:14:13 -0000 Hello Lars-Erik The main differences are that the proposed solution, TuCP does not =20 compress outermost IP header (IPout) and it focuses on packet =20 reordering problem as there can be many routers between the compressor =20 and decompressor. The proposed draft defines header compression profiles for general =20 tunneling mechanisms. For example, in case of L2TP tunnel, ROHC does =20 not define a profile for compressing, IP/UDP/L2TP/PPP headers. =20 Moreover, in this example, IP is not to be compressed as it is =20 required for routing the packet to the final destination. If we consider both the inner and outer encapsulation which is IPout/UDP/L2TP/PPP/IPin/UDP/RTP, currently, there is no profile defined in ROHC to compress this entire =20 encapsulation. The ROHC RTP profile can be used to compress part of =20 the encapsulation which is IPin/UDP/RTP. However, there is a problem =20 of packet reordering in IP tunnels which needs to be addressed when =20 ROHC (RFC 3095) is used over IP tunnels. The proposed mechanism, TuCP, manages out of order packets, and thus =20 it enables the use of ROHC for inner IP packet headers efficiently. Hope that answers your queries. Regards Priyanka Rawat IT/TELECOM Bretagne Lars-Erik Jonsson a =E9crit=A0: > This submission does not make much sense to me, as ROHC already =20 > provides mechanisms for compression of tunneling headers (outer =20 > headers). To support tunneling was a requirement stated already by =20 > RFC 3096, and thus addressed by RFC 3095. Since then, compression of =20 > IP tunneling headers has been provided by all ROHC profiles. > > Can you explain what you mean ROHC is missing, not doing correcty or =20 > efficiently, or by which other means you think ROHC is not =20 > sufficient in terms of IP tunnel compression? > > BR > /L-E > > > ----- Original Message ----- From: > To: > Cc: > Sent: Monday, April 06, 2009 1:25 AM > Subject: [rohc] Rohc over IP tunnel > > >> Hello All >> >> We have submitted a new draft to IETF. This document proposes a =20 >> method to use ROHC over IP tunnel. >> >> The draft is available at >> http://tools.ietf.org/search/draft-rawat-hc-tunneling-00 >> >> Since we would like to continue this work further, it will be =20 >> interesting for us to receive feedback on the draft and initiate =20 >> discussion at IETF. >> >> Please let us know your opinion. >> >> Regards >> Priyanka Rawat >> >> IT/TELECOM Bretagne >> >> _______________________________________________ >> Rohc mailing list >> Rohc@ietf.org >> https://www.ietf.org/mailman/listinfo/rohc > From pradeep.shambhu@gmail.com Tue Apr 7 03:45:23 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C51128C1EA for ; Tue, 7 Apr 2009 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq86AJOqf2xd for ; Tue, 7 Apr 2009 03:45:22 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 5E6E428C1DD for ; Tue, 7 Apr 2009 03:45:21 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so2707822wfg.31 for ; Tue, 07 Apr 2009 03:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=BsbG3H/DH5mP2z/Xtor1jWz4/+e/aHHfli7j5chvcyU=; b=Gyi19Eb/2G367HuBm46BB5bjPizCl5hh0u/+JqQPL8A5GUTj0H4BpNHUUhP3ov3eDe Hbb+/er8oZN4lASZtX7IoBfgtgQMZ4gfELUbUZpF/r4LvB+9I6y8QaDQHjtEBW1ohiQg eab1xleXZJRZCUrflOWNh51KO/kx1otF8nWx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=rnvnYALeRhjINu625eTCcJQTFyWiczRyJMN5rvAAjBsem4lP+CaBu9XwCtjRIb84h9 aG2XZFSDjSmj/+bHGssIk5paQcI6RCAhdDMCGaWSKNRHhy+opMHs2N3EOm6+0zRf2YxJ D6Eeundrc8HZlm5kSfLutSeDA5qu6JAt4rdOM= MIME-Version: 1.0 Received: by 10.143.18.16 with SMTP id v16mr1596327wfi.142.1239101187936; Tue, 07 Apr 2009 03:46:27 -0700 (PDT) Date: Tue, 7 Apr 2009 16:16:27 +0530 Message-ID: From: pradeep shambhu To: Raffles Content-Type: multipart/alternative; boundary=001636e8ff6425d0990466f4ba1d Cc: rohc@ietf.org Subject: [rohc] Query regarding ROHC-TCP/IP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 10:45:23 -0000 --001636e8ff6425d0990466f4ba1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Raffels, Thanks for the information regarding Scaled Acknowledgement Number , you have clarified my doubt completely. I am having one more issue regarding the IP-ID random value. If IP-ID is sequential then we are going to select the compressed sequential packet format (1-8) , because IP-ID can be compressed using LSB encoding method and we can place it into any compressed sequential format. But if IP-ID is random then we select compressed random packet format (1-8). As IP-ID field is not mentioned in the compressed random packet formats (RFC 4996), how can we send the IP-ID in such packet formats ? With Regards, Pradeep Shambhu --001636e8ff6425d0990466f4ba1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Raffels,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Than= ks for the information regarding Scaled Acknowledgement Number , you have c= larified my doubt completely. I am having one more issue regarding the IP-I= D random value.

If IP-ID is sequential then we are going to select = the compressed sequential packet format (1-8) , because IP-ID can be compre= ssed using LSB encoding method and we can place it into any compressed sequ= ential format. But if IP-ID is random then we select compressed random pack= et format (1-8). As IP-ID field is not mentioned in the compressed random p= acket formats (RFC 4996), how can we send the IP-ID in such packet formats = ?=A0=A0 =A0

With Regards,
Pradeep Shambhu

--001636e8ff6425d0990466f4ba1d-- From pradeep.shambhu@gmail.com Wed Apr 8 21:32:14 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12CB3A68D0 for ; Wed, 8 Apr 2009 21:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZNEJKJ6Kd8T for ; Wed, 8 Apr 2009 21:32:14 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 626B63A6B07 for ; Wed, 8 Apr 2009 21:32:13 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so363702rvb.49 for ; Wed, 08 Apr 2009 21:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ooLbfziXyhXi8pXBvQfW9e2HeXbYAOBNlfibu8LFVB4=; b=uuoJnNxI40qYCkMMVcyfzA5LiZrh+b+xqvvRfRYKwR8izfXDxUwMj0rfQbxMpF9hh6 svSI05nD8Xd7EpD/FaDWTCnZb/eA4WXWf2nOKyaSuc84UTD4b3lGHQtzRQJUeIh32fK6 t3cfNd+0jxDGZNYtSa1S0XqbsbHpGhrS1ZIpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dnav9w8ShwVt00xOFkCN5FzC07Z2gFhLar8ExL8U6BV2MKsvaLUSNRfvVTF/47fABp FoarWd7o5pAPrLQTDuZmfqmd9syx2UXMELTIIRKIKwcfr+1tKL0/ITbHNTl9mmoey2DL gS1S19UOSdIrzAIJ2FfpD7qYliB+uOF4TctAQ= MIME-Version: 1.0 Received: by 10.142.58.5 with SMTP id g5mr718777wfa.170.1239251600966; Wed, 08 Apr 2009 21:33:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 Apr 2009 10:03:20 +0530 Message-ID: From: pradeep shambhu To: Raffles Content-Type: multipart/alternative; boundary=001636e0aa33768498046717bf6f Cc: gurushant@tataelxsi.co.in, rohc@ietf.org Subject: [rohc] Query regarding ROHC-TCP/IP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 04:32:15 -0000 --001636e0aa33768498046717bf6f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi , If IP-ID is sequential then we are going to select the compressed sequential packet format (1-8) , because IP-ID can be compressed using LSB encoding method and we can place it into any compressed sequential format. But if IP-ID is random then we select compressed random packet format (1-8). As IP-ID field is not mentioned in the compressed random packet formats (RFC 4996), how can we send the IP-ID in such packet formats ? With Regards, Pradeep --001636e0aa33768498046717bf6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi ,

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0
If IP-ID is sequential then we are going to select the com= pressed sequential packet format (1-8) , because IP-ID can be compressed us= ing LSB encoding method and we can place it into any compressed sequential = format. But if IP-ID is random then we select compressed random packet form= at (1-8). As IP-ID field is not mentioned in the compressed random packet f= ormats (RFC 4996), how can we send the IP-ID in such packet formats ?=A0=A0= =A0

With Regards,
Pradeep
=

--001636e0aa33768498046717bf6f-- From raffles@gluft.com Wed Apr 15 11:26:06 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CABA3A6C46 for ; Wed, 15 Apr 2009 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08opOfLVHZTk for ; Wed, 15 Apr 2009 11:26:05 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by core3.amsl.com (Postfix) with ESMTP id D70C528C14F for ; Wed, 15 Apr 2009 11:25:35 -0700 (PDT) Received: from [192.168.1.64] (93-97-78-217.zone5.bethere.co.uk [93.97.78.217]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1Lu9or1MNJ-0004TL; Wed, 15 Apr 2009 20:26:46 +0200 Message-ID: <49E62718.4010206@gluft.com> Date: Wed, 15 Apr 2009 19:27:36 +0100 From: Raffles User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pradeep shambhu References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18oD/dxzRawsv0MAEWxKamEUmQZ7QTubqzcxVr pGiC9AKGjHRKIuFQZ4pOj1JJTacJgabCtB+/G+sR6+mC2nO3+Q nK4LmxqG5fVgPZZ2355h0rX/tj9ze1E Cc: gurushant@tataelxsi.co.in, rohc@ietf.org Subject: Re: [rohc] Query regarding ROHC-TCP/IP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:26:06 -0000 Hi Pradeep,

I must reiterate I am not an expert on 4996. In particular although I'm obviously familiar with TCP, I don't know much about IP ID behaviour. However, I do notice that the DEFAULT section of the formal profile specifies static encoding as the default encoding for that field. This means that if a packet format doesn't specify an encoding to use, it defaults to static encoding. Please re-read RFC 4997 if you need further explanation on default encodings.

I am only able to answer this question because I just went and looked up the DEFAULT section in the RFC, which of course you are able to do yourself. I hope this answer helps you, but please do look up answers in the RFC first before posting questions to the list.

Thanks.

Regards

Raffles

pradeep shambhu wrote:

Hi ,


If IP-ID is sequential then we are going to select the compressed sequential packet format (1-8) , because IP-ID can be compressed using LSB encoding method and we can place it into any compressed sequential format. But if IP-ID is random then we select compressed random packet format (1-8). As IP-ID field is not mentioned in the compressed random packet formats (RFC 4996), how can we send the IP-ID in such packet formats ?

With Regards,
Pradeep

_______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc

-- Raffles (Robert Finking) m: 0789 463 9887 e: raffles@gluft.com 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 mihirjm@gmail.com Mon Apr 20 18:59:20 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801093A680B for ; Mon, 20 Apr 2009 18:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSG6WxJoZ+LF for ; Mon, 20 Apr 2009 18:59:19 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id B20383A6E35 for ; Mon, 20 Apr 2009 18:59:19 -0700 (PDT) Received: by gxk10 with SMTP id 10so1236533gxk.13 for ; Mon, 20 Apr 2009 19:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Rt56oKHC1oN3+7PkhFMH2oMRs94YqVhIbAzE/zOszvI=; b=BAlSsWZA4Rndlo1bgcEtEkD5Qvvo7gG2PfpK52BjgfT4xueySN98RC+xHyc7Y+HG+s ZkfkADB9RSlQBNkG5usZxIohhPvH+rLm+GpS6I0+m7ahi8EA9awYR4X6SEDuE2WpnvES DL3Zh6LmhUSzg2zLj6qNjdFyA3IlhU8onxX3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hvSLlcB14d7GaFLpPMJa+dpjGX1dpFgHjsyv9TJBwmWkQuaDrItN2kzyb7hZCS9uq2 K6xOYHFkZ196uVunLbug2CDWgS5KF2T1KKsqH0Hc5AsqAFGGbnm8EzHL+UqZTEsC/EIQ 5FKToG7lDj9xOPdt9jjkSWWxqW/OdwCRGFZLk= MIME-Version: 1.0 Received: by 10.231.19.72 with SMTP id z8mr3535338iba.42.1240279235409; Mon, 20 Apr 2009 19:00:35 -0700 (PDT) Date: Tue, 21 Apr 2009 10:00:35 +0800 Message-ID: <86c08c690904201900i460dba07uc9c404ee7efaf9d7@mail.gmail.com> From: Mihir Mehta To: Rohc@ietf.org Content-Type: multipart/alternative; boundary=00221532cf343fb87d0468070392 Subject: [rohc] Question regarding bit ordering in RTP headers packets RFC 3095 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 01:59:20 -0000 --00221532cf343fb87d0468070392 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all, I had a naive clarification on the bit ordering specified in the RFC 3095 for packets like RTP IR and IR-DYN. Does the 0-7 bit labeling specified above the packet header diagrams specify just the numbering of the bits or does it follow the same order too. In other words, does it follow 0-7 or 7-0 (the least significant bit first or most significant bit first) while formation and transmitting? It wasn't very clear to me from the RFC. Thanks in advance and best regards, Mihir. --00221532cf343fb87d0468070392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

I had a naive clarification on the bit orderin= g specified in the RFC 3095 for packets like RTP IR and IR-DYN.
<= br>
Does the 0-7 bit=A0labeling=A0specified above the packet head= er diagrams specify just the numbering of the bits or does it follow the sa= me order too.=A0

In other words, does it follow 0-7 or 7-0 (the least si= gnificant bit first or most significant bit first) while formation and tran= smitting? It wasn't very clear to me from the RFC.

Thanks in advance and best regards,
Mihir.

--00221532cf343fb87d0468070392-- From carl.knutsson@effnet.com Mon Apr 20 23:39:05 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B863A6FE5 for ; Mon, 20 Apr 2009 23:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq-VTslj1Tek for ; Mon, 20 Apr 2009 23:39:04 -0700 (PDT) Received: from lists.levonline.com (lists.levonline.com [217.70.33.37]) by core3.amsl.com (Postfix) with ESMTP id 5E1293A6A51 for ; Mon, 20 Apr 2009 23:39:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by lists.levonline.com (Postfix) with ESMTP id 310DD29C056; Tue, 21 Apr 2009 08:40:19 +0200 (CEST) X-Virus-Scanned: By http://levonline.com - free virus scanning for all customers Received: from lists.levonline.com ([127.0.0.1]) by localhost (lists.levonline.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AofoHStJ7frt; Tue, 21 Apr 2009 08:40:17 +0200 (CEST) Received: from truck2.fordonnet.levonline.com (gw-uu-virtual.levonline.com [217.70.32.2]) by lists.levonline.com (Postfix) with ESMTP id A6F3A29C3AF; Tue, 21 Apr 2009 08:40:17 +0200 (CEST) Received: from [192.168.101.28] (c-6a0471d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.4.106]) (authenticated bits=0) by truck2.fordonnet.levonline.com (8.12.11.20060308/8.12.11) with ESMTP id n3L6eGa8007555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 08:40:17 +0200 Message-ID: <49ED6A4A.5090108@effnet.com> Date: Tue, 21 Apr 2009 08:40:10 +0200 From: Carl Knutsson User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Mihir Mehta References: <86c08c690904201900i460dba07uc9c404ee7efaf9d7@mail.gmail.com> In-Reply-To: <86c08c690904201900i460dba07uc9c404ee7efaf9d7@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rohc@ietf.org Subject: Re: [rohc] Question regarding bit ordering in RTP headers packets RFC 3095 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 06:39:05 -0000 Hi Mihir, You can find the data transmission order in RFC 791 Appendix B. /Calle Mihir Mehta wrote: > Dear all, > > I had a naive clarification on the bit ordering specified in the RFC > 3095 for packets like RTP IR and IR-DYN. > > Does the 0-7 bit labeling specified above the packet header diagrams > specify just the numbering of the bits or does it follow the same > order too. > > In other words, does it follow 0-7 or 7-0 (the least significant bit > first or most significant bit first) while formation and transmitting? > It wasn't very clear to me from the RFC. > > Thanks in advance and best regards, > Mihir. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > From xavier.lebourdon@jcp-consult.com Mon Apr 27 00:06:19 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2ACF3A6F3A for ; Mon, 27 Apr 2009 00:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvmvubM6q7pt for ; Mon, 27 Apr 2009 00:06:18 -0700 (PDT) Received: from 6.mail-out.ovh.net (6.mail-out.ovh.net [91.121.25.210]) by core3.amsl.com (Postfix) with SMTP id E232E3A6873 for ; Mon, 27 Apr 2009 00:06:17 -0700 (PDT) Received: (qmail 2081 invoked by uid 503); 27 Apr 2009 07:43:13 -0000 Received: from b3.ovh.net (HELO mail407.ha.ovh.net) (213.186.33.53) by 6.mail-out.ovh.net with SMTP; 27 Apr 2009 07:43:13 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 27 Apr 2009 07:07:33 -0000 Received: from 242.74.64-86.rev.gaoland.net (HELO ?192.168.1.42?) (xavier.lebourdon@jcp-consult.com@86.64.74.242) by ns0.ovh.net with SMTP; 27 Apr 2009 07:07:32 -0000 Message-ID: <49F559B3.1030609@jcp-consult.com> Date: Mon, 27 Apr 2009 09:07:31 +0200 From: Xavier LE BOURDON User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 6463791365753128555 X-Ovh-Remote: 86.64.74.242 (242.74.64-86.rev.gaoland.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.500198/N Subject: [rohc] ROHCv2 - Profile 0x000 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:06:19 -0000 Hi, Should RoHCv2 implement the profile 0x0000 ? Thanks, Xavier LE BOURDON From cabo@tzi.org Mon Apr 27 00:19:55 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074F83A6D83 for ; Mon, 27 Apr 2009 00:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGrgnNqCSnha for ; Mon, 27 Apr 2009 00:19:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id ECA373A6A78 for ; Mon, 27 Apr 2009 00:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n3R7L499000444; Mon, 27 Apr 2009 09:21:04 +0200 (CEST) Received: from [192.168.217.107] (p5489F685.dip.t-dialin.net [84.137.246.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 7D0B71704DC; Mon, 27 Apr 2009 09:21:04 +0200 (CEST) From: Carsten Bormann To: Xavier LE BOURDON In-Reply-To: <49F559B3.1030609@jcp-consult.com> References: <49F559B3.1030609@jcp-consult.com> Message-Id: <60610F7B-833D-4B5B-86AE-780F2972D394@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 09:21:03 +0200 X-Mailer: Apple Mail (2.930.3) Cc: rohc@ietf.org Subject: Re: [rohc] ROHCv2 - Profile 0x000 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:19:55 -0000 > Should RoHCv2 implement the profile 0x0000 ? Generally, yes. It may not be strictly necessary if your link layer has another way to send packets around ROHC. Gruesse, Carsten From Karthik.Balaguru@lntinfotech.com Mon Apr 27 06:17:40 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F883A6960 for ; Mon, 27 Apr 2009 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imqa0P4oZeYq for ; Mon, 27 Apr 2009 06:17:37 -0700 (PDT) Received: from mail142.messagelabs.com (mail142.messagelabs.com [216.82.249.99]) by core3.amsl.com (Postfix) with SMTP id AD0483A6929 for ; Mon, 27 Apr 2009 06:17:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Karthik.Balaguru@lntinfotech.com X-Msg-Ref: server-9.tower-142.messagelabs.com!1240838337!36311544!1 X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 6860 invoked from network); 27 Apr 2009 13:18:57 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-9.tower-142.messagelabs.com with SMTP; 27 Apr 2009 13:18:57 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009042718505944-218920 ; Mon, 27 Apr 2009 18:50:59 +0530 To: rohc@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Karthik Balaguru Date: Mon, 27 Apr 2009 18:48:10 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/27/2009 06:49:03 PM, Serialize complete at 04/27/2009 06:49:03 PM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/27/2009 06:50:59 PM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/27/2009 06:51:02 PM, Serialize complete at 04/27/2009 06:51:02 PM Content-Type: multipart/alternative; boundary="=_alternative 00491114652575A5_=" X-Mailman-Approved-At: Mon, 27 Apr 2009 07:20:50 -0700 Subject: [rohc] GSW and performance X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:21:34 -0000 This is a multipart message in MIME format. --=_alternative 00491114652575A5_= Content-Type: text/plain; charset="US-ASCII" Hi, Increasing the GSW size could reduce the performance. So, What could be the optimal GSW size for good performance while considering the Feedback options w.r.t the LOSS Option ? Thx in advans, Karthik Balaguru ______________________________________________________________________ --=_alternative 00491114652575A5_= Content-Type: text/html; charset="US-ASCII"
Hi,

Increasing the GSW size could reduce the performance.
So, What could be the optimal GSW size for good performance while considering the Feedback options w.r.t the LOSS Option ?

Thx in advans,
Karthik Balaguru
______________________________________________________________________
--=_alternative 00491114652575A5_=-- From cabo@tzi.org Mon Apr 27 08:01:18 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F6E28C16B for ; Mon, 27 Apr 2009 08:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPbQRNKxCVRF for ; Mon, 27 Apr 2009 08:01:11 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2EB2A3A6F96 for ; Mon, 27 Apr 2009 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n3RF1sl0017671; Mon, 27 Apr 2009 17:01:54 +0200 (CEST) Received: from [192.168.217.107] (p5489F685.dip.t-dialin.net [84.137.246.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id C98A01704D6; Mon, 27 Apr 2009 17:01:53 +0200 (CEST) From: Carsten Bormann To: Karthik Balaguru In-Reply-To: References: Message-Id: <7EA28AFF-9E6E-453B-8724-044CBEB2EA59@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 17:01:52 +0200 X-Mailer: Apple Mail (2.930.3) Cc: rohc@ietf.org Subject: Re: [rohc] GSW and performance X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:01:18 -0000 > Increasing the GSW size could reduce the performance. > So, What could be the optimal GSW size for good performance while > considering the Feedback options w.r.t the LOSS Option ? Karthik, I don't think you will get good input from your two-liner questions. You need to explain more of the context you are coming from and what problem you are trying to solve. It may help to read: http://www.catb.org/~esr/faqs/smart-questions.html How much sliding window your compressor needs depends a lot on what your compressor does. Section 6 of RFC 3095 is about implementation issues, please read again: 6. Implementation issues This document specifies mechanisms for the protocol and leaves many details on the use of these mechanisms to the implementers. This chapter is aimed to give guidelines, ideas and suggestions for implementing the scheme. Section 5.7.6.9 tells you a lot about how the information in the LOSS option could be used by the compressor. Gruesse, Carsten From Karthik.Balaguru@lntinfotech.com Tue Apr 28 04:09:14 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D1028C1E2 for ; Tue, 28 Apr 2009 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2QUJS1QhXrq for ; Tue, 28 Apr 2009 04:09:13 -0700 (PDT) Received: from mail192.messagelabs.com (mail192.messagelabs.com [216.82.241.243]) by core3.amsl.com (Postfix) with SMTP id A1BAE28C1DC for ; Tue, 28 Apr 2009 04:09:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Karthik.Balaguru@lntinfotech.com X-Msg-Ref: server-12.tower-192.messagelabs.com!1240917032!30218009!1 X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 11458 invoked from network); 28 Apr 2009 11:10:33 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-12.tower-192.messagelabs.com with SMTP; 28 Apr 2009 11:10:33 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009042816423591-223524 ; Tue, 28 Apr 2009 16:42:35 +0530 In-Reply-To: <7EA28AFF-9E6E-453B-8724-044CBEB2EA59@tzi.org> To: Carsten Bormann MIME-Version: 1.0 Importance: High X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Karthik Balaguru Date: Tue, 28 Apr 2009 16:40:39 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/28/2009 04:40:40 PM, Serialize complete at 04/28/2009 04:40:40 PM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/28/2009 04:42:35 PM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 04/28/2009 04:42:37 PM, Serialize complete at 04/28/2009 04:42:37 PM Content-Type: multipart/alternative; boundary="=_alternative 003D6333652575A6_=" X-Mailman-Approved-At: Tue, 28 Apr 2009 04:29:28 -0700 Cc: rohc@ietf.org Subject: Re: [rohc] GSW and performance X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 11:09:14 -0000 This is a multipart message in MIME format. --=_alternative 003D6333652575A6_= Content-Type: text/plain; charset="US-ASCII" Hi, In the case of LOSS option in Feedback packet, if there is a large number of sequential packet drops, then the gsw size should be increased accordingly to minimize the losses at decompressor. But, If we increase the size to a large value (example - 50 or more), then it will take lot of time(processing cycles/cpu cycles) to operate(Encoding) on the gsw as it has to consider all the values inside the window . So, what could be the optimal gsw size such that it does not affect the performance(processing cycles/cpu cycles) and also the packet drops. Thx in advans, Karthik Balaguru Carsten Bormann 04/27/2009 08:31 PM To Karthik Balaguru cc rohc@ietf.org Subject Re: [rohc] GSW and performance > Increasing the GSW size could reduce the performance. > So, What could be the optimal GSW size for good performance while > considering the Feedback options w.r.t the LOSS Option ? Karthik, I don't think you will get good input from your two-liner questions. You need to explain more of the context you are coming from and what problem you are trying to solve. It may help to read: http://www.catb.org/~esr/faqs/smart-questions.html How much sliding window your compressor needs depends a lot on what your compressor does. Section 6 of RFC 3095 is about implementation issues, please read again: 6. Implementation issues This document specifies mechanisms for the protocol and leaves many details on the use of these mechanisms to the implementers. This chapter is aimed to give guidelines, ideas and suggestions for implementing the scheme. Section 5.7.6.9 tells you a lot about how the information in the LOSS option could be used by the compressor. Gruesse, Carsten ______________________________________________________________________ ______________________________________________________________________ --=_alternative 003D6333652575A6_= Content-Type: text/html; charset="US-ASCII"
Hi,

In the case of LOSS option in Feedback packet, if there is a large number of
sequential packet drops, then the gsw size should be increased accordingly to minimize
the losses at decompressor.

But,
If we increase the size to a large value (example - 50 or more), then it will take
lot of time(processing cycles/cpu cycles) to operate(Encoding) on the gsw as it
has to consider all the values inside the window .

So, what could be the optimal gsw size such that it does not affect the
performance(processing cycles/cpu cycles) and also the packet drops.

Thx in advans,
Karthik Balaguru

Carsten Bormann <cabo@tzi.org>
04/27/2009 08:31 PM

To
Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>

cc
rohc@ietf.org

Subject
Re: [rohc] GSW and performance

> Increasing the GSW size could reduce the performance. > So, What could be the optimal GSW size for good performance while > considering the Feedback options w.r.t the LOSS Option ? Karthik, I don't think you will get good input from your two-liner questions. You need to explain more of the context you are coming from and what problem you are trying to solve. It may help to read: http://www.catb.org/~esr/faqs/smart-questions.html How much sliding window your compressor needs depends a lot on what your compressor does. Section 6 of RFC 3095 is about implementation issues, please read again: 6. Implementation issues This document specifies mechanisms for the protocol and leaves many details on the use of these mechanisms to the implementers. This chapter is aimed to give guidelines, ideas and suggestions for implementing the scheme. Section 5.7.6.9 tells you a lot about how the information in the LOSS option could be used by the compressor. Gruesse, Carsten ______________________________________________________________________

______________________________________________________________________
--=_alternative 003D6333652575A6_=-- From karthikbalaguru79@gmail.com Tue Apr 28 06:26:30 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5CE28C247 for ; Tue, 28 Apr 2009 06:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tumPAD9AywZ9 for ; Tue, 28 Apr 2009 06:26:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 243D428C251 for ; Tue, 28 Apr 2009 06:26:24 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so330276rvb.49 for ; Tue, 28 Apr 2009 06:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EdZQjBbobpSr+PMP8kifM5UCi6fjNARfxzCqsuZ9uPw=; b=atJYazHgaoCgxIN07qXreJejjREtYzqKquXXIvkxmb7XpsnMWDpkbWZYkh+VP1zBMN 1+5RRS1MCi5haOmxqpYTTgrClWXsVNLB1lJRi0c2Q6UsVzzDpsVET87GzSuuF02+tsyh GxMeMmsZIQt5VndCXSQC+rt0tauRVkWOU0AJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MxooBYmDILx6vrCx2ceZCZEnyIz5R8WeKjsixoaHYoOYfAhWEJUaMD6ok8xdUOmjsz 3G45Aaaxd/O5le9unvwetFbUL9ozKS18ac79Waie1FPeZpqEfsOILAjIPOIx4CucyWYK ir6py8t3sf4mNkc1py4zwozoAQwtFXC19QJyE= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr1500693wfe.221.1240925265605; Tue, 28 Apr 2009 06:27:45 -0700 (PDT) In-Reply-To: <7EA28AFF-9E6E-453B-8724-044CBEB2EA59@tzi.org> References: <7EA28AFF-9E6E-453B-8724-044CBEB2EA59@tzi.org> Date: Tue, 28 Apr 2009 18:57:45 +0530 Message-ID: <53b627ea0904280627i39c5561chadef1a9a05918445@mail.gmail.com> From: Karthik Balaguru To: rohc@ietf.org Content-Type: multipart/alternative; boundary=000e0cd181c0a6343104689d6d61 Cc: Karthik Balaguru Subject: Re: [rohc] GSW and performance X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 13:26:30 -0000 --000e0cd181c0a6343104689d6d61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, In the case of LOSS option in Feedback packet, if there is a large number of sequential packet drops, then the gsw size should be increased accordingly to minimize the losses at decompressor. But, If we increase the size to a large value (example - 50 or more), then it will take lot of time(processing cycles/cpu cycles) to operate(Encoding) on the gsw as it has to consider all the values inside the window . So, what could be the optimal gsw size such that it does not affect the performance(processing cycles/cpu cycles) and also the packet drops. Thx in advans, Karthik Balaguru On Mon, Apr 27, 2009 at 8:31 PM, Carsten Bormann wrote: > Increasing the GSW size could reduce the performance. >> So, What could be the optimal GSW size for good performance while >> considering the Feedback options w.r.t the LOSS Option ? >> > > Karthik, > > I don't think you will get good input from your two-liner questions. > You need to explain more of the context you are coming from and what > problem you are trying to solve. > It may help to read: > http://www.catb.org/~esr/faqs/smart-questions.html > > How much sliding window your compressor needs depends a lot on what your > compressor does. > Section 6 of RFC 3095 is about implementation issues, please read again: > > 6. Implementation issues > > This document specifies mechanisms for the protocol and leaves many > details on the use of these mechanisms to the implementers. This > chapter is aimed to give guidelines, ideas and suggestions for > implementing the scheme. > > Section 5.7.6.9 tells you a lot about how the information in the LOSS > option could be used by the compressor. > > Gruesse, Carsten > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > --000e0cd181c0a6343104689d6d61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

In the case of LOSS option in Feedback packet,=A0 if there is a = large number of
sequential packet drops, then the gsw size should be inc= reased accordingly to minimize
the losses at decompressor.

But, =
If we increase the size to a large value (example - 50 or more), then it wi= ll take
lot of time(processing cycles/cpu cycles) to operate(Encoding) o= n the gsw as it
has to consider all the values inside the window .

So, what could be the optimal gsw size such that it does not affect the=
performance(processing cycles/cpu cycles) and also the packet drops.
Thx in advans,
Karthik Balaguru

On Mon, Apr 27, 2009 at 8:31 PM, Carsten Bormann <cabo@tzi.org> wrote:

Increasing the GSW size could reduce the performance.
So, What could be the optimal GSW size for good performance while consideri= ng the Feedback options w.r.t the LOSS Option ?

Karthik,

I don't think you will get good input from your two-liner questions. You need to explain more of the context you are coming from and what proble= m you are trying to solve.
It may help to read:
=A0http://www.catb.org/~esr/faqs/smart-questions.html

How much sliding window your compressor needs depends a lot on what your co= mpressor does.
Section 6 of RFC 3095 is about implementation issues, please read again:
6. =A0Implementation issues

=A0 This document specifies mechanisms for the protocol and leaves many =A0 details on the use of these mechanisms to the implementers. =A0This =A0 chapter is aimed to give guidelines, ideas and suggestions for
=A0 implementing the scheme.

Section 5.7.6.9 tells you a lot about how the information in the LOSS optio= n could be used by the compressor.

Gruesse, Carsten

_______________________________________________
Rohc mailing list
Rohc@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/rohc

--000e0cd181c0a6343104689d6d61-- From dima@ipcores.com Thu Apr 30 00:39:10 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D492F3A6A73 for ; Thu, 30 Apr 2009 00:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GppPaSR65j+t for ; Thu, 30 Apr 2009 00:39:10 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id E31073A69D8 for ; Thu, 30 Apr 2009 00:39:09 -0700 (PDT) Received: by gxk10 with SMTP id 10so3492206gxk.13 for ; Thu, 30 Apr 2009 00:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.190.18 with SMTP id n18mr3065292ybf.110.1241077232393; Thu, 30 Apr 2009 00:40:32 -0700 (PDT) Date: Thu, 30 Apr 2009 00:40:32 -0700 Message-ID: <3c9eb190904300040o428c07adw8c1389e4bb4d2102@mail.gmail.com> From: Dmitri Varsanofiev To: rohc@ietf.org Content-Type: multipart/alternative; boundary=000e0cd6b190936b690468c0cf4e Subject: [rohc] Current ROHC IPR situation X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 07:39:10 -0000 --000e0cd6b190936b690468c0cf4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear ROHC list subscribers, What is the current situation with the IPR for the ROHC implementations? I have searched the ROHC Web site and both "old" and "new" mailing archives, but did not find a clear answer. According to the ROHC web site and mailing lists, early in the development of the standard few players, including Ericsson, have identified that they might have patents and patent applications related to ROHC, and signed letters agreeing to license their IP on RAND terms. What I have not been able to find is the current IPR situation, in particular: 1) Did the IP owners move from RAND to RANDZ? 2) If fees are required, is there a centralized pool of IP? Is there an authoritative list of IP involved? 3) Do any of the existing ROHC vendors provide indemnification against the IP claims? or 4) Are the users of ROHC implementations expected to obtain their own [cross-]licensing? Any help will be greatly appreciated, including pojnters to Web sites, publications, companies, and people. Thank you in advance! -- Dmitri "Dima" Varsanofiev --000e0cd6b190936b690468c0cf4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear ROHC list subscribers,

What is the current situation with the I= PR for the ROHC implementations? I have searched the ROHC Web site and both= "old" and "new" mailing archives, but did not find a c= lear answer.

According to the ROHC web site and mailing lists, early in the developm= ent of the standard few players, including Ericsson, have identified that t= hey might have patents and patent applications related to ROHC, and signed = letters agreeing to license their IP on RAND terms.

What I have not been able to find is the current IPR situation, in part= icular:

1) Did the IP owners move from RAND to RANDZ?

2) If f= ees are required, is there a centralized pool of IP? Is there an authoritat= ive list of IP involved?

3) Do any of the existing ROHC vendors provide indemnification against = the IP claims? or

4) Are the users of ROHC implementations expected = to obtain their own [cross-]licensing?

Any help will be greatly appr= eciated, including pojnters to Web sites, publications, companies, and peop= le.

Thank you in advance!
--
Dmitri "Dima" V= arsanofiev

--000e0cd6b190936b690468c0cf4e-- From cabo@tzi.org Thu Apr 30 03:21:43 2009 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A8828C2BE for ; Thu, 30 Apr 2009 03:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fZhL0LlajDn for ; Thu, 30 Apr 2009 03:21:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id C779E28C2ED for ; Thu, 30 Apr 2009 03:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n3UAMtcX006673; Thu, 30 Apr 2009 12:22:55 +0200 (CEST) Received: from [192.168.217.107] (p5489E9D2.dip.t-dialin.net [84.137.233.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 176A21704D6; Thu, 30 Apr 2009 12:22:55 +0200 (CEST) From: Carsten Bormann To: Dmitri Varsanofiev In-Reply-To: <3c9eb190904300040o428c07adw8c1389e4bb4d2102@mail.gmail.com> References: <3c9eb190904300040o428c07adw8c1389e4bb4d2102@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 12:22:53 +0200 X-Mailer: Apple Mail (2.930.3) Cc: rohc@ietf.org Subject: Re: [rohc] Current ROHC IPR situation X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 10:21:43 -0000 Dear ROHC list subscribers, please do *not* discuss specific patents/patent claims on the mailing list, as such a discussion might require a number of contributors to unsubscribe and stop contributing. (It might also cause you or your employer to become liable for damages in interesting ways.) If you need information about patent ("IPR") claims, you know where to go: http://www.ietf.org/ipr/ This is also the place to go if you know about patent claims and need to declare them in order to fulfill your duties as cited in the "note well" you received when you subscribed to this list. The IETF cannot define "an authoritative list of IP" (patent claims) as that is fundamentally impossible. There is nothing that we can contribute on a technical level -- e.g., we all know a lot about prior art in this space, but this is barely relevant on a legal level. If you want to discuss this, meet in a hallway and make sure no microphones are nearby. Gruesse, Carsten On Apr 30, 2009, at 09:40, Dmitri Varsanofiev wrote: > Dear ROHC list subscribers, > > What is the current situation with the IPR for the ROHC > implementations? I have searched the ROHC Web site and both "old" > and "new" mailing archives, but did not find a clear answer.