Re: [rohc] ROHC-TCP: Update and some topics to be discussed
Ghyslain Pelletier <Ghyslain.Pelletier@epl.ericsson.se> Thu, 05 June 2003 14:53 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29118 for <rohc-archive@odin.ietf.org>; Thu, 5 Jun 2003 10:53:18 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55EqrM10652 for rohc-archive@odin.ietf.org; Thu, 5 Jun 2003 10:52:53 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EqrB10649 for <rohc-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 10:52:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29098 for <rohc-web-archive@ietf.org>; Thu, 5 Jun 2003 10:52:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nw4t-0007Zn-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:50:55 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nw4t-0007Zk-00 for rohc-web-archive@ietf.org; Thu, 05 Jun 2003 10:50:55 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EqAB10625; Thu, 5 Jun 2003 10:52:10 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EjoB10285 for <rohc@optimus.ietf.org>; Thu, 5 Jun 2003 10:45:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28870 for <rohc@ietf.org>; Thu, 5 Jun 2003 10:45:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvy5-0007WL-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:43:53 -0400
Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Nvy4-0007WI-00 for rohc@ietf.org; Thu, 05 Jun 2003 10:43:52 -0400
Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55EkNbj014957; Thu, 5 Jun 2003 16:46:23 +0200
Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LVYTBSJS; Thu, 5 Jun 2003 16:45:29 +0200
Received: by lms001.lu.erisoft.se id QAA18284; Thu, 5 Jun 2003 16:45:38 +0200 (MET DST)
Message-ID: <3EDF577F.32F2CEDE@epl.ericsson.se>
Date: Thu, 05 Jun 2003 16:45:20 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Ghyslain Pelletier <Ghyslain.Pelletier@epl.ericsson.se>
Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yousuf.Saifullah@nokia.com
CC: rohc@ietf.org
Subject: Re: [rohc] ROHC-TCP: Update and some topics to be discussed
References: <025E7DD4182874489CC2F61EE0FA19CE0139885A@daebe004.americas.nokia.com>
Content-Type: text/plain; charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id QAA18284
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55EjoB10286
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h55EqAB10625
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55EqrB10649
Content-Transfer-Encoding: 8bit
Hi Yousuf, Thanks for your comments. Some answers in-line. I will get back to some of the issues I won't address in this mail in a later mail. Regards, /Ghyslain Yousuf.Saifullah@nokia.com wrote: > > Hi Gyslain, > > The following are my comments on the context replication draft (draft-pelletier-rohc-context-replication-00.txt): > > - Section 3.2.2: What is "OPTIONAL improved forward transition"? > I was not able to find any description for this term. This is written in the same way as in RFC-3095, section 5.4.1.1. Basically, what this means is that it is not necessary - the compressor may still transit to a higher state, but it can help such a transition to happen faster. > - Section 3.2.2.1 - last two paras: NACK is not sent in response to > IR-REPLICATE. Instead, it looks like that it is a general failure > information procedure for informing decompression of a subsequent > packet not IR-REPLICATE. I think these two paras are irrelevant to > context replication. I'd suggest to either take out these paras or > explicitly mention that this is a general failure procedure. I am not sure that I understand the first statement in the comment. What do you mean by "NACK is not sent in response to IR-REPLICATE"? I'd like you to bring some precisions so I can bring you a better answer. Section 3.3.2. of the draft states that the decompressor can send a NACK in response to an IR-REPLICATE in some cases. > - Section 3.3.2 - Third para: Could you please clarify when the > compressor will be sending IR-REPLICATE packets as subsequent packets > after receiving ACK for successful decompression of the initial > IR-REPLICATE. The decompressor after successfully validating > IR-REPLICATE will send ACK, which moves the compressor from IR to CO > state (taking ROHC-TCP state machine). I think in this state the > compressor will be sending compressed packets not IR-REPLICATE. I think that we do not prevent the IR-REPLICATE to be sent and decompressed in other states than IR state, that is we do not prevent it (and I don't think we can anyway) to be used as an ordinary packet. [snip] [I'll get back on the feedback and failure mechanism.] [I think this should be taken separately.] > > Section 3.4.1 - third para: The way I understood this para is that > the 8-bit CRC could cover entire IR header but a profile may not do > that and the reason is in section 5.2.6 of RFC 3095. I was unable to > find the explanation in the reference, could you please explain this > limitation. Recall point 10) in section 5.2.6. of RFC-3095 states: 10) If the packet type is IR, the profile indicated in the IR packet determines how it is to be processed. If the CRC fails to verify the packet, it MUST be discarded. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, no further action is taken. This is framework logic, and the IR-REPLICATE is also an IR packet. The text in the context replication draft states the consequence of that point for the IR-REPLICATE regarding the type of CRC, its presence in an IR packet (thus this applies to the IR-REPLICATE as well) and nature of what it protects (e.g. it cannot be redefined to cover say the original uncompressed header instead). Therefore only the extent of the CRC coverage can be redefined by a profile and it must meet the minimal coverage required (CID, Profile, etc. - that is at least the initial part of the packet ending with the Profile field). > Section 3.4.2 - IR-REPLICATE format figure: I think it would be more > clear to show 7-bit CRC and Base CID in the figure. These fields are > described but are not shown in the figure. The 7-bit CRC (always present) and the Base CID (if present) are both part of the profile specific information. This means that how they are to be represented in the format depends on the packet format defined by a specific profile, and this may vary from one profile to another. Therefore it would not be appropriate in my opinion to show these fields in the figure. Consider for example a profile that would define two "sets" of packet formats, one of which includes the Base CID for when the compressor wants to create a different context and keep the base context, and one that doesn't for when we want to overwrite the base context. Another profile might be defined so that the Base CID field is always present in the format. Still, it is appropriate for the text to mandate the presence of a 7-bit CRC in the packet and mention that an identifier to the Base CID may be present because these belong to the replication mechanism - their functionality and nature is defined by context replication. > Appendix A: Is this the intention that the formats mentioned in this > Appendix will become standardized format? If that is the case, then I > would suggest to put these formats in the main body of the draft not > in appendix. The appendix is informative. This is simply a suggestion to exemplify a possible structure to the IR-REPLICATE packet. Other approaches than chains (for example) might be taken. As said previously, this part is profile specific, so I am not sure how/if we can make this part normative in this document. See also my reply to Richard's comments on this. > A.1: Why didn't we define a flag for marking Traffic Class as > replicable? Is this because adding a bit would mean adding a byte and > that would exactly be the saving in the Traffic class case? This can be added without requiring another octet. We could use codes insteads of flags. As Richard pointed out, we could also add hop limit as well. I can update that. > A.2: The two spare bits left in the first byte can be used for the > replication flags for Type of Service and Identification fields. This > will not cause any addition in the packet size. Could you please > define the spare bits as the flags. Yes, I can do that. As Richard pointed out, we could also add TTL as well. Thanks for your comment. I will get back on the question I haven't answered in a later mail. /Ghyslain Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 920 20 24 32 Mobile: +46 (0) 70 609 27 73 Ghyslain.Pelletier@epl.ericsson.se http://www.ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc
- [rohc] ROHC-TCP: Update and some topics to be dis… Ghyslain Pelletier
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- Re: [rohc] ROHC-TCP: Update and some topics to be… Ghyslain Pelletier
- Re: [rohc] ROHC-TCP: Update and some topics to be… Ghyslain Pelletier
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Lars-Erik Jonsson (EAB)
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Hongbin Liao (Intl Staffing)
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- RE: [rohc] ROHC-TCP: Update and some topics to be… Lars-Erik Jonsson (EAB)
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- RE: [rohc] ROHC-TCP: Update and some topics to be… Lars-Erik Jonsson (EAB)
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Yousuf.Saifullah
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- RE: [rohc] ROHC-TCP: Update and some topics to be… Lars-Erik Jonsson (EAB)
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard
- Re: [rohc] ROHC-TCP: Update and some topics to be… Ghyslain Pelletier
- Re: [rohc] Feedback with ROHC-CR (was: ROHC-TCP: … Ghyslain Pelletier
- RE: [rohc] ROHC-TCP: Update and some topics to be… Price, Richard