From mailman-bounces@core3.amsl.com Fri Feb 1 05:58:58 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF27628E718 for ; Fri, 1 Feb 2008 05:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGCBdxy6J8yO for ; Fri, 1 Feb 2008 05:58:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891B5295798 for ; Fri, 1 Feb 2008 05:32:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rohc-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:58 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/rohc/rohc-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:02:45 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE73294ABA for ; Fri, 1 Feb 2008 05:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-7YfWB3Knqa for ; Fri, 1 Feb 2008 05:56:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9DE28C521 for ; Fri, 1 Feb 2008 05:32:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rohc-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:04:57 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/rohc/rohc-archive%40megatron.ietf.org From rohc-bounces@ietf.org Mon Feb 4 07:07:31 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF343A6EF2; Mon, 4 Feb 2008 07:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCTAiBzsptT2; Mon, 4 Feb 2008 07:07:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446283A6F08; Mon, 4 Feb 2008 07:07:30 -0800 (PST) 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 AFCF83A6F08 for ; Mon, 4 Feb 2008 07:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD0NzcFN+evo for ; Mon, 4 Feb 2008 07:07:28 -0800 (PST) Received: from effnet.com (unknown [194.237.235.30]) by core3.amsl.com (Postfix) with ESMTP id 0DCA83A6EB2 for ; Mon, 4 Feb 2008 07:07:27 -0800 (PST) Received: from [192.168.102.22] ([192.168.102.22]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id m14F8wSN021332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 4 Feb 2008 16:09:00 +0100 Message-ID: <47A72EC1.2030908@effnet.com> Date: Mon, 04 Feb 2008 16:26:57 +0100 From: Carl Knutsson User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: rohc Subject: [rohc] ROHCv2 submit and Write-Up. X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Hi all, I have asked the IESG to publish draft-ietf-rohc-rfc3095bis-rohcv2- profiles-05.txt as RFC. I am sending the entire Write-Up to the ROHC-WG mailing list (as recommended in RFC4858). I want to thank everyone in the WG that contributed to this document. I apologize for delay of the actual submit. The administrative tasks takes a bit longer than one might expect. This is the first document I am sheparding. Hopefully I got the whole submit process right:) The write-up follows below... Best regards, /Carl Knutsson (ROHC WG Chair) --- Write-up for draft-ietf-rohc-rfc3095bis-rohcv2-profiles: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Carl Knutsson (ROHC WG chair) is the Document Shepherd, has personally verified this version of the document, and believes that it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This draft (and previous versions of the draft) have been well-discussed on the ROHC mailing list by key WG members as well as persons connected to 3GPP and 3GPP2 standard bodies. Four active WG participants have provided comprehensive reviews as Committed Document Reviewers. Newer WG members have also provided useful review to the document. The Document Shepherd is confident with the depth and breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. The draft uses RFC4997 formal notation (FN). The ROHC FN is somewhat complex, however a large portion of the FN code could be reused from RFC4996 (ROHC-TCP) with improvements. The document shepherd expects that the General Area Review Team would review this document, but no additional review is required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed. If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document shepherd does not have specific concerns or issues with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The shepherd believes there is a clear WG consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? None that the shepherd is aware of. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The Document Shepherd has verified that the document satisfies all ID nits. There are no additional formal review criteria that are applicable to this document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative/informative. There is a normative reference to the ROHC framework RFC4995. An error has been found in RFC 4995 that makes piggybacking of feedback impossible. This is not a key feature and a new draft has already been created to replace or update RFC4995. Otherwise none pending. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has an IANA section, requesting registration of ROHC profile identifiers for the new ROHCv2 profiles. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The Document Shepherd has checked and verified the formal notation (RFC 4997) part of the document. The authors have used an inofficial non-public automated checker as support to the work. There is however no complete and publicly available automatic checker for the ROHC formal notation, however all reviewers including the Document Shepherd are confident that the formal notation part of the draft is correct. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Technical Summary This document defines RObust Header Compression (ROHC) profiles for compression of IP, UDP/IP, ESP/IP, UDP-Lite/IP, RTP/UDP-Lite/IP and RTP/UDP/IP packets. They represent a second generation of profiles (ROHCv2) to the ROHC framework (RFC 4995). ROHCv2 profiles include a number of simplifications to the algorithms used to govern the behaviour of the compression endpoints. They are designed to efficiently and robustly handle long round-trip-times, packet loss and packet reordering over the ROHC channel. The ROHCv2 profiles supersede but do not obsolete the earlier generation of profiles specified in RFC3095, RFC3843 and RFC 4019. Working Group Summary This document has been in the working group for roughly 18 months. The document originated from implementation experience gained with RFC 3095, from which implementers have outlined its complexity and the relevance of defining simpler profiles, as well as from the requirement and the need to introduce support against reordering between compression endpoints. These new profiles were first drafted as an individual submission, and the first draft was submitted to the WG in September 2006. Initially, there was a relatively large interest for the new profiles, but few technical reviews. Since May 2007, the active participation in the working group to this draft has accelerated and ultimately the document received several comprehensive reviews. The general design approach is similar as for ROHC-TCP (RFC 4997), and has not changed significantly since it was first introduced in the group. The WG have a consensus for the new profiles. Document Quality The document has been reviewed by several individuals, with different perspectives and approaches to the reviews. The formal notation part was verified manually but also partly validated by automated tools. During WG Last-Call, the document was reviewed by the committed WG reviewers Robert Finking, Haipeng Jin, Rohit Kapoor and Mark West. In WG reviews and otherwise, feedback has been received from persons active in the ROHC WG as well as in 3GPP and 3GPP2 standard bodies. Personnel Authors are Kristofer Sandlund and Ghyslain Pelletier. The Document Shepherd for this draft is Carl Knutsson, and Magnus Westerlund is the responsible Area Director. _______________________________________________ Rohc mailing list Rohc@ietf.org http://www.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Feb 6 07:03:50 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8730C3A6E3F; Wed, 6 Feb 2008 07:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=1, MIME_HTML_MOSTLY=0.001, RELAY_IS_203=0.994] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1FhBpWuCHuI; Wed, 6 Feb 2008 07:03:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 155843A6E16; Wed, 6 Feb 2008 07:03:46 -0800 (PST) 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 3D7683A6850 for ; Wed, 6 Feb 2008 07:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvvvGgBRX7qX for ; Wed, 6 Feb 2008 07:03:39 -0800 (PST) Received: from gws03.hcl.in (gws03.hcl.in [203.105.186.19]) by core3.amsl.com (Postfix) with ESMTP id 1C5E53A6E07 for ; Wed, 6 Feb 2008 07:03:38 -0800 (PST) Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 432C537C114 for ; Wed, 6 Feb 2008 20:35:07 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id 097B237C181for ; Wed, 6 Feb 2008 20:35:07 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Feb 2008 20:35:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Feb 2008 20:35:06 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60391D534@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Doubts in ROHC Feedbak in RTP Profile Thread-Index: Acho0ag4AiqoapdkS4y8poz023+e0A== From: "Gangadharan G, TLS-Chennai" To: "rohc" X-OriginalArrivalTime: 06 Feb 2008 15:05:06.0774 (UTC) FILETIME=[A8B1D760:01C868D1] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-23.1062 TC:1F TRN:72 TV:5.0.1023(15714.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [rohc] Doubts in ROHC Feedbak in RTP Profile X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632316481==" Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1632316481== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C868D1.A8BA1603" This is a multi-part message in MIME format. ------_=_NextPart_001_01C868D1.A8BA1603 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have listed down my doubts in the ROHC Feedback mechanism in RTP Profile=2E Please help me to clarify it=2E =20 1) The Sliding Window structure for the List Compression is different for R-Mode and U/O-Mode=2E The RTP CSRC and IP-extension header uses List compression=2E =20 So, those fields have to be reinitialized when there is a Mode Transition (transit from U to R Mode)=2E I=2Ee=2E, when the C_TRANS is PENDING, the compressor has to send IR/IR-Dyn/UOR-2 packets=20 with all dynamic fields (at least the field that needs to be reinitialized) __but__ RFC 3095 doesn't mandate the compressor to update the dynamic fields while mode transition=2E=20 =20 Whether we need to send IR/IR-Dyn/UOR-2 packets with all dynamic fields or not? Also whether the compressor does downward state transition while Mode transition? =20 2) In R-Mode Feedback,=20 Section 5=2E5=2E2=2E1=2E Decompression logic (R-mode) specify that The decompressor SHOULD act according to section 5=2E3=2E2=2E2=2E3 when= CRCs fail, except that no local repair is performed=2E I=2Ee=2E=2E, send Nack (k_1 out of n_1) when CRC fails =20 Section 5=2E5=2E2=2E2=2E Feedback logic (R-mode) specify that=20 When context damage is detected, send a NACK(R) if in Full Context state, or a STATIC-NACK(R) if in Static Context state =20 Does the above statement specify to send NACK for each failure?=20 If so, then it contradicts with the statement in the section 5=2E5=2E2=2E1(mentioned earlier)=2E =20 3) In R-Mode Feedback logic,=20 Does the Decompressor have to send the NACK for the rejected packet in SC State? But RFC 3095 mentioned about sending NACK for rejected packet in O-Mode (Section 5=2E4=2E2=2E2) and for R-Mode=2E =20 4) When the D_Trans is Initiated or Pending, the Decompressor send Ack/Nack for each received packet=2E Whether the Decompressor does upward/downward state transition after sending the Ack/Nack? Or, the Decompressor has to follow the corresponding Mode Feedback logic for State transition,=20 even though it send Ack/Nack for each packet=2E =20 5) When the D_Trans is Initiated or Pending, Whether the Decompressor has to send Static-Nack or Nack in SC state? =20 6) RFC 3095 mentioned about what the Compressor and Decompressor has to do when there is a Mode transition=2E But it does not specify when the Decompressor has to initiate the Mode Transition=2E Is it implementation specific or Link-Layer dependent? The upward mode transition is required for better compression=2E Is there any real time need for the downward mode transition? =20 Please forgive me if I am ignorant on anything=2E =20 Thanks, Gangadharan =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C868D1.A8BA1603 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have listed down my doubts in the ROHC Feedback= mechanism in RTP Profile=2E

Please help me to clarify it= =2E

 

1) The Sliding Window structure for the List Compression= is different for R-Mode and U/O-Mode=2E

    The RTP CSRC and IP-extension header= uses List compression=2E     =

    So, those fields have to be= reinitialized when there is a Mode Transition (transit from U to R Mode)= =2E

    I=2Ee=2E, when the C_TRANS is= PENDING, the compressor has to send IR/IR-Dyn/UOR-2 packets=

   =        with all dynamic fields (at least the field that needs to be= reinitialized)

    __but__ RFC 3095 doesn’t= mandate the compressor to update the dynamic fields while mode transition=2E=

   

    Whether we need to send= IR/IR-Dyn/UOR-2 packets with all dynamic fields or not?

    Also whether the compressor does= downward state transition while Mode transition?

 

2) In R-Mode Feedback,

    Section 5=2E5=2E2=2E1=2E = Decompression logic (R-mode) specify that

The decompressor= SHOULD act according to section 5=2E3=2E2=2E2=2E3 when= CRCs

  =          fail, except that no local repair is performed=2E

    I=2Ee=2E=2E, send Nack (k_1 out of= n_1) when CRC fails

 

    Section 5=2E5=2E2=2E2=2E = Feedback logic (R-mode) specify that

      &n= bsp;     When context damage is detected, send a NACK(R) if in Full= Context

    =        state, or a STATIC-NACK(R) if in Static Context state

 

   = Does the above statement specify to send NACK for each failure?=

    If so, then it contradicts with the= statement in the section 5=2E5=2E2=2E1(mentioned earlier)=2E

 

3) In R-Mode Feedback logic,=

    Does the Decompressor have to send= the NACK for the rejected packet in SC State?

    But RFC 3095 mentioned about sending= NACK for rejected packet in O-Mode (Section 5=2E4=2E2=2E2) and for R-Mode= =2E

 

4) When the D_Trans is Initiated or Pending, the= Decompressor send Ack/Nack for each received packet=2E

    Whether the Decompressor does upward/downward state transition after sending the= Ack/Nack?

    Or, the Decompressor has to follow= the corresponding Mode Feedback logic for State transition,=

    even though it send Ack/Nack for each packet=2E

 

5) When the D_Trans is Initiated or Pending, Whether the= Decompressor has to send Static-Nack or Nack in SC state?

 

6) RFC 3095 mentioned about what the Compressor and Decompressor has to do when there is a Mode transition= =2E

   But it does not specify when the= Decompressor has to initiate the Mode Transition=2E Is it implementation specific or= Link-Layer dependent?

   The upward mode transition is required for better compression=2E

   Is there any real time need for the= downward mode transition?

 

Please forgive me if I am ignorant on anything= =2E

 

Thanks,

Gangadharan<= /p>

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C868D1.A8BA1603-- --===============1632316481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org http://www.ietf.org/mailman/listinfo/rohc --===============1632316481==-- From rohc-bounces@ietf.org Tue Feb 19 22:17:47 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E6128C6DE; Tue, 19 Feb 2008 22:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.026 X-Spam-Level: X-Spam-Status: No, score=0.026 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 Z+snQNnTj7Ge; Tue, 19 Feb 2008 22:17:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C5B3A6860; Tue, 19 Feb 2008 22:17:46 -0800 (PST) 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 0C7233A683B for ; Tue, 19 Feb 2008 22:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 qf+nK3WwrQC5 for ; Tue, 19 Feb 2008 22:17:44 -0800 (PST) Received: from nav6.org (unknown [219.93.2.104]) by core3.amsl.com (Postfix) with ESMTP id 332313A6E18 for ; Tue, 19 Feb 2008 22:17:37 -0800 (PST) Received: from [10.207.160.229] (unknown [10.207.160.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by nav6.org (Postfix) with ESMTP id 06ABE1D60141 for ; Wed, 20 Feb 2008 14:29:20 +0800 (MYT) Message-ID: <47BBC5FD.3030507@nav6.org> Date: Wed, 20 Feb 2008 14:17:33 +0800 From: Ang Way Chuang User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: rohc@ietf.org Subject: [rohc] Value of next header (IPv6) and protocol (IPv4) field X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org Hi all, In the presence of IPv6 extension headers, what should be the value of next header? For instance, if the following datagram goes to compressor, IPv6 base header --- Hop by Hop header --- UDP header I guess the next header field in the static header contains the value of 17 (UDP header) since the section 5.8.4.1 of RFC 3095 states that "All communicated uncompressed extension header items indicate their own type in their Next Header field". So it is only logical to put the value of next upper layer protocol in the next header field. Is my assumption correct? I think the similar concept applies to IPv4 datagram as well? Thank you in advance. Regards, Ang Way Chuang _______________________________________________ Rohc mailing list Rohc@ietf.org http://www.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Feb 27 08:53:26 2008 Return-Path: X-Original-To: ietfarch-rohc-archive@core3.amsl.com Delivered-To: ietfarch-rohc-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D07928C988; Wed, 27 Feb 2008 08:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 RghzJNsBCGYs; Wed, 27 Feb 2008 08:53:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9045728C9D2; Wed, 27 Feb 2008 08:51:38 -0800 (PST) X-Original-To: rohc@ietf.org Delivered-To: rohc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 16D8A28C9B4; Wed, 27 Feb 2008 08:51:36 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20080227165137.16D8A28C9B4@core3.amsl.com> Date: Wed, 27 Feb 2008 08:51:37 -0800 (PST) Cc: rohc@ietf.org Subject: [rohc] Last Call: draft-ietf-rohc-rfc3095bis-rohcv2-profiles (RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite) to Proposed Standard X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rohc-bounces@ietf.org Errors-To: rohc-bounces@ietf.org The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-03-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-rohcv2-profiles-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15136&rfc_flag=0 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc