RE: [rohc] RE: Comments on ROHCv2 profiles draft
"Kristofer Sandlund (LU/EAB)" <kristofer.sandlund@ericsson.com> Tue, 19 June 2007 06:48 UTC
Return-path: <rohc-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0XW1-0001j4-Fe; Tue, 19 Jun 2007 02:48:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0XVz-0001iv-J6 for rohc@ietf.org; Tue, 19 Jun 2007 02:48:35 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0XVy-0001xJ-Dt for rohc@ietf.org; Tue, 19 Jun 2007 02:48:35 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A57F420090; Tue, 19 Jun 2007 08:48:33 +0200 (CEST)
X-AuditID: c1b4fb3e-b0835bb0000007e1-52-46777c41984c
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86F48201A3; Tue, 19 Jun 2007 08:48:33 +0200 (CEST)
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 08:48:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [rohc] RE: Comments on ROHCv2 profiles draft
Date: Tue, 19 Jun 2007 08:48:31 +0200
Message-ID: <A91F30A632473A47B40C18D2B107CA6F04212435@esealmw105.eemea.ericsson.se>
In-Reply-To: <C2E0B39A89E6BE4FAFA874758D621CF4012380FF@NAEX15.na.qualcomm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rohc] RE: Comments on ROHCv2 profiles draft
Thread-Index: AceemKzW4kh3p+4+SgCvFk/ihGdinQQKjVVgABhcy+AAiTYXUAA7vAHQ
References: <A91F30A632473A47B40C18D2B107CA6F04041FEF@esealmw105.eemea.ericsson.se><C2E0B39A89E6BE4FAFA874758D621CF4011CDD70@NAEX15.na.qualcomm.com> <A91F30A632473A47B40C18D2B107CA6F041B8CBA@esealmw105.eemea.ericsson.se> <C2E0B39A89E6BE4FAFA874758D621CF4012380FF@NAEX15.na.qualcomm.com>
From: "Kristofer Sandlund (LU/EAB)" <kristofer.sandlund@ericsson.com>
To: "Jin, Haipeng" <haipengj@qualcomm.com>, rohc@ietf.org
X-OriginalArrivalTime: 19 Jun 2007 06:48:33.0376 (UTC) FILETIME=[DA9C1600:01C7B23D]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4
Cc: "Ghyslain Pelletier (LU/EAB)" <ghyslain.pelletier@ericsson.com>
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
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>
Errors-To: rohc-bounces@ietf.org
Hi Haipeng, thanks for the feedback, more comments inline. Jin, Haipeng <mailto:haipengj@qualcomm.com> wrote on den 19 juni 2007 03:10 : > Hi, Kristofer, > > Thanks for your reply, please see more comments following yours. > > -----Original Message----- > From: Kristofer Sandlund (LU/EAB) > [mailto:kristofer.sandlund@ericsson.com] > Sent: Friday, June 15, 2007 1:26 AM > To: Jin, Haipeng; rohc@ietf.org > Cc: Ghyslain Pelletier (LU/EAB) > Subject: [rohc] RE: Comments on ROHCv2 profiles draft > > Hi Haipeng, > > comments inline as usual. > > Jin, Haipeng <mailto:haipengj@qualcomm.com> wrote on den 15 juni 2007 > 07:05 : > >> Hi, Kristofer and Ghyslain, >> >> Great effort in updating the profile draft! >> >> I have the following comments: >> 1. Decompressor state: >> I remember we had some discussion on the state diagram in >> section 5.3.1. >> It is not possible to transit from NC to FC directly. The >> main reason is >> that IR-DYN carries CRC-8 but does not verify the entire context so a >> CRC-7 packet such as co-common or p0-crc7 is needed as an >> intermediate step. Now that IR-DYN is removed, I would propose to >> change the stage diagram to allow direct transition from NC to FC >> with CRC-8 verification. > > The IR packet has the same potential issue as the IR-DYN packet, i.e. > that it may omit control fields from the packet and these do not get > verified by the CRC-8. Therefore, I think the 2-step > transition is still > a valid choice. > The alternative is still to try to beef up the IR > by either adding an extra CRC or mandating the presence of control > fields etc, but I think that's going to be a lot more "patch-work" > (and more overhead) than having a 2-step transition which is simple. > And the cost > is quite minimal since you're not going to be in NC state very often. > > I would have liked to change the coverage of the existing CRC-8 for > the IR, but since that is defined by the framework, that's not an > option, unfortunately. > > [Haipeng] The framework only says the coverage of CRC-8 for IR is > profile-dependent and recommends what is the minimal that need to be > covered. If you think there are fields that need to be covered in > RTP/UDP/... profiles, wouldn't it be great to list them out and have a > discussion here and maybe make the coverage mandatory in > these profiles? When I read up on the old discussions we had on this, I found my old email from last year http://www1.ietf.org/mail-archive/web/rohc/current/msg04569.html which proposed alternatives for how to handle IR and state transitions, and the only reply I got on that was from Lars-Erik who supported the two-step approach which is why this draft version still uses the two-step logic. Could you check that one and give your opinions? Btw, you're absolutely right that the IR CRC-8 coverage is profile-dependent. I don't know where I got the other idea from, so that possibility is also listed in the referenced mail above :) > > Anyway, note that section 5 is informative, so if an implementation > wants to do something else such as a one-step approach, that would not > be illegal, although it is not the main recommendation of this spec > > [Haipeng] The problem is that the text gives the impression that only > two-step transition is allowed. For example, if no CRC7 is received > in-between crc8 and crc3 packets, the decompressor will not attempt > decompression on those crc3 packets. > If both options are allowed, then > it would be great if the text can be clarified to convey the idea. I > understand that it might be hard to express all possibilities in the > diagram before making it appear messy, maybe an alternative is to make > the diagram simpler. Instead of showing all transition possibilities > which are not currently done as you pointed out, the diagram can show > only the three available states and general transition > connections. The > text can be enhanced to capture all the conditions. Yes, as Rohit pointed out, there is something missing here w.r.t. the two-step transition. I'm not exactly sure on what's the best way to fix this, but probably add some normative rules in section 6. > >> I still don't see how the two-step upward >> transition helps >> to make the decompression process more robust. Actually, it may make >> things worse in some cases, for example, if the compressor sends a >> couple of IRs, followed by a couple of p0-crc7 and then a >> number of crc3 >> packets. If the p0-crc7 packets are erases and the >> decompressor stays in >> IC, all the subsequent crc3 packets will be dropped even without >> decompression attempt when those packets can actually be decompressed >> successfully. This is even worse if the compressor is working in >> non-feedback mode. > > As stated above, there's a larger chance of things going wrong with > the one-step approach. And since we're using the optimistic approach, > the chance of losing all pt-0-crc7 (as in your example above) that you > send should be very small, otherwise the compressor has chosen a bad > optimistic approach value. > > [Haipeng] The reason I gave this example is because in the past email > threads, similar examples (IR re-ordering followed by crc3 > packets) were > used to show why two-step transition is needed. I agree that if the > compressor can choose a good OAA value, then neither that > example nor my > example will be a concern. One-step approach won't have > problem either. > >> >> Another question I have regards decompressor state is: in section >> 5.3.1.3, the text says "The decompressor moves back to the IC state >> if it assumes context damage, and back to the NC state if it >> assumes static >> context damage." about downward transition, this is not >> consistent with >> the diagram. So what is the real intend here? Are you >> thinking to allow >> direct transition back from FC to NC? > > Agreed, the text and the picture are inconsistent. I would probably > prefer adding an extra arrow to the picture, but I think the other > option is also viable. What's you opinion? > > [Haipeng] RFC3095 only discussed two-step downward transition, " Only > when decompression of several packets sent in the FO state > fails in the > "Static Context" state will the decompressor go all the way > back to the > "No Context" state.". I don't see much problem allowing > transition back > from FC to NC, but it would be great if there are some general > guidelines on what might be the criteria for the decompressor to > determine whether to go from FC to IC or from FC to NC. Do > you have some > scenarios in mind? I prefer to leave it up to the decompressor to drop back to NC state whenever it wants to, as long it has reason to suspect that it might have lost synch of the static context. For example, if the decompressor receives an IR packet with a bad CRC-8 followed by a CRC-3 packet, it might guess that it doesn't have sufficient static context and drop directly to NC. I'm not saying it should do that always, but since all the downwards transitions have to be based on some form of guessing by the decompressor, I think it is fine for the spec to say that it may be extra conservative if it wants to. But like I said, I can agree to either of the solutions. Regarding more guidelines, do you think that section 5.3.2 is insufficient (we refer to that from the picture w.r.t. transitions)? I think that has quite good guidelines for how to detect context damage, but if you think it is insufficient, please give a text proposals that we can discuss further. > >> >> 2. IP-ID behavior >> >> The new profile only allows sequential behavior to inner >> IP-ID. For all >> outer headers, IP-IDs are assumed to be either constant or >> random. This >> means that in two-level IP headers (e.g. MIP) case which may >> be a common >> use case in wireless networks, the compressor may not be able to >> compress the packet as efficiently as in RFC3095. It would be great >> if you can add an sequential indicator for the outer header to >> handle at least this case. > > Here, I refer to the motivations in the now-expired requirements draft > that this WG agreed on for ROHCv2, see section 2.6 of this one: > http://tools.ietf.org/html/draft-ietf-rohc-rfc3095bis-improvements-03 > > So I would be very much against changing this since that adds a lot > of complexity and it gives a very minimal gain and only for a very > small subset of tunneled packets. > > [Haipeng] I would be careful in saying that tunneled packets > belong to a > very small subset. MIP is a mobility management mechanism that is used > widely. Tunnel packets with two levels of headers are common if CCoA > mode of operation is used and it is important for ROHC to handle them > efficiently. > > [Haipeng] In addition, the text in the expired requirements draft says > that it is unrealistic that the outer IP-ID can be compressed > sequentially. This is not true either. There are actually > implementations where the tunneling endpoints set outer IP-ID to the > same as inner IP-ID sequentially to allow efficient compression using > 3095. If the same stacks are used for updated profile, the IP-ID will > not be compressed efficiently. Sure, there are tunnels that use such a mechanism, but however you cut it, tunneled packets are a subset of all packets, and tunnels with the behavior you describe are a subset of tunnels which means this is a minority of packets that are affected. And the cost of 0-2 bytes in those cases seems small enough to avoid trying to optimize. The outer-IPID mechanism of 3095 has really been despised by implementers due to its strange and over-complex logic and it would require quite a large change in the current v2 packet formats to get that back. So I think you will need very strong motivations to get that change into the spec, especially with previous WG consensus of not doing this (also, ROHC-TCP already follows the IPID logic used in v2). /Kristofer > > > Best Regards, > Haipeng > >> >> 3. Packet formats >> >> I have similar concerns as Rohit on the packet formats and bit number >> allocations and will try to follow your response on the >> existing thread. > > Ok, since that's a bit more complex issue, I will get back to > that when > I have had more time to prepare a comprehensive answer and re-read all > the old discussions we had last year. > > BR, > Kristofer > >> >> That is for now. >> >> Best Regards, >> Haipeng > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc
- [rohc] Update of ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- Re: [rohc] Update of ROHCv2 profiles draft Carl Knutsson
- RE: [rohc] Update of ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- Re: [rohc] Update of ROHCv2 profiles draft Carl Knutsson
- RE: [rohc] Update of ROHCv2 profiles draft Sarkar, Biplab
- RE: [rohc] Update of ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] Update of ROHCv2 profiles draft Biplab Sarkar
- RE: [rohc] Update of ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] Update of ROHCv2 profiles draft Biplab Sarkar
- Re: [rohc] Update of ROHCv2 profiles draft Carl Knutsson
- Re: [rohc] Update of ROHCv2 profiles draft Vicknesan Ayadurai
- Re: [rohc] Update of ROHCv2 profiles draft Carl Knutsson
- Re: [rohc] Update of ROHCv2 profiles draft Carl Knutsson
- RE: [rohc] Update of ROHCv2 profiles draft Kapoor, Rohit
- RE: [rohc] Update of ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] Update of ROHCv2 profiles draft Kapoor, Rohit
- [rohc] Comments on ROHCv2 profiles draft Jin, Haipeng
- [rohc] RE: Comments on ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Kapoor, Rohit
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Jin, Haipeng
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- [rohc] More comments on ROHCv2 profiles draft Carl Knutsson
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Jin, Haipeng
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- RE: [rohc] RE: Comments on ROHCv2 profiles draft Jin, Haipeng
- [rohc] RE: More comments on ROHCv2 profiles draft Kristofer Sandlund (LU/EAB)
- [rohc] Re: More comments on ROHCv2 profiles draft Carl Knutsson
- [rohc] typo in FN of ROHCv2 profiles draft? Carl Knutsson
- [rohc] RE: typo in FN of ROHCv2 profiles draft? Kristofer Sandlund
- [rohc] ROHCv2 IP-ID encoding. Carl Knutsson
- [rohc] ROHCv2 Implementation msn, sn and ipid in … Carl Knutsson
- [rohc] RE: ROHCv2 Implementation msn, sn and ipid… Kristofer Sandlund