From rohc-bounces@ietf.org Thu Jan 04 15:50:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXP-0002EM-8N; Thu, 04 Jan 2007 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXH-000297-UU; Thu, 04 Jan 2007 15:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ZXG-0003m7-O4; Thu, 04 Jan 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8694C26ECC; Thu, 4 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2ZXG-0000ec-A5; Thu, 04 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-sigcomp-impl-guide-10.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : Implementer's Guide for SigComp Author(s) : A. Surtees, et al. Filename : draft-ietf-rohc-sigcomp-impl-guide-10.txt Pages : 28 Date : 2007-1-4 This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document (if approved) clarifies and corrects text in the following updated RFCs: RFC 3320, RFC 3321, RFC 3485. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rohc-sigcomp-impl-guide-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-4143438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sigcomp-impl-guide-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-4143438.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Wed Jan 17 07:49:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AEh-0001LK-GN; Wed, 17 Jan 2007 07:49:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78CV-0001xZ-SM for rohc@ietf.org; Wed, 17 Jan 2007 05:39:27 -0500 Received: from hu-out-0506.google.com ([72.14.214.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H78CR-0006dL-AS for rohc@ietf.org; Wed, 17 Jan 2007 05:39:27 -0500 Received: by hu-out-0506.google.com with SMTP id 38so1268782huc for ; Wed, 17 Jan 2007 02:39:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=F1ANNIJ7KvLUYd7KAY9yWi8MqnyXsWyR3V4N7ufzdVgrjhouZarMNYmtdW+c8x3gWXDcCyGGYJn77NGDJlHpx0VLkJRzwtPoVr6BCbogh3/JQ363/gW553OkUuQp6ESrVatVlVjV82jDirVTKZbT6WTYYkQiEMhAUOj9h+QZPBs= Received: by 10.82.138.6 with SMTP id l6mr1480090bud.1169030361097; Wed, 17 Jan 2007 02:39:21 -0800 (PST) Received: by 10.82.112.7 with HTTP; Wed, 17 Jan 2007 02:39:21 -0800 (PST) Message-ID: Date: Wed, 17 Jan 2007 16:09:21 +0530 From: "Haritas Sharma" To: cabo@tzi.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Wed, 17 Jan 2007 07:49:49 -0500 Cc: rohc@ietf.org, Erik Nordmark , haritas71@gmail.com Subject: [rohc] Regarding ROHC ipv6 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0160153713==" Errors-To: rohc-bounces@ietf.org --===============0160153713== Content-Type: multipart/alternative; boundary="----=_Part_92420_495554.1169030361060" ------=_Part_92420_495554.1169030361060 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I was trying to find an overview of impact of rohc over ipv6 framework. We are using rohc for the PDSN for CDMA2000 network. Any pointers which is already documented, towards this is helpful. Thanks and regards, Haritas ------=_Part_92420_495554.1169030361060 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
 
I was trying to find an overview of impact of rohc over ipv6 framework.
We are using rohc for the PDSN for CDMA2000 network.
 
Any pointers which is already documented, towards this is helpful.
 
Thanks and regards,
Haritas
------=_Part_92420_495554.1169030361060-- --===============0160153713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0160153713==-- From rohc-bounces@ietf.org Wed Jan 17 16:58:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Inq-0004zK-BT; Wed, 17 Jan 2007 16:58:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Inn-0004yu-S6; Wed, 17 Jan 2007 16:58:39 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Inn-0003xu-Dh; Wed, 17 Jan 2007 16:58:39 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D978A26EE0; Wed, 17 Jan 2007 21:58:38 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7Inm-0007Qf-PM; Wed, 17 Jan 2007 16:58:38 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 17 Jan 2007 16:58:38 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: rohc mailing list , rohc chair , Internet Architecture Board , RFC Editor Subject: [rohc] Protocol Action: 'Formal Notation for Robust Header Compression (ROHC-FN)' to Proposed Standard X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org The IESG has approved the following document: - 'Formal Notation for Robust Header Compression (ROHC-FN) ' as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-formal-notation-13.txt Technical Summary This document defines ROHC-FN (RObust Header Compression - Formal Notation); a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. Previous header compression profiles have been so far specified using a combination of English text together with ASCII Box notation. Unfortunately, this was sometimes unclear and ambiguous, revealing the limitations of defining complex structures and encodings for compressed formats this way. The primary objective of the Formal Notation is to provide a more rigorous means to define header formats -- compressed and uncompressed -- as well as the relationships between them. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help simplifying future profile development work. Working Group Summary This document has been in the workings for several years, it first appeared as part of of a header compression research proposal known as "EPIC", and became an official WG item 2002, to serve the ROHC TCP profile development. Its form has changed through the years, but it has now been rather stable for a long time and is used as a basis for both the ROHC TCP profile and the upcoming ROHCv2 profiles. The document has been carefully reviewed by both the WG and externals, and there is WG consensus that the document should now be published as an RFC. Document Quality The formal notation specified by this document has now been put in use for two ROHC profile specifications, the TCP and the ROHCv2 profiles. The document has been both manually reviewed by several parties with different perspectives, and checked by automated tools. During WGLC, the document was reviewed by the committed WG reviewers Mark West, Carsten Bormann and Joe Touch, as well as by Sally Floyd, who provided a review at the request of the Transport Area Directorate. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. Note to RFC Editor Section 3.3, OLD: UNCOMPRESSED { version [ 4 ]; header_length [ 4 ]; tos [ 6 ]; NEW: UNCOMPRESSED { version [ 4 ]; header_length [ 4 ]; dscp [ 6 ]; ^^^^ Section 3.3, page 13: OLD: tos =:= irregular(6); NEW: dscp =:= irregular(6); ^^^^ Section 4.12.1.3: OLD: ipv4 { UNCOMPRESSED { version; // 4 bits hdr_length; // 4 bits protocol; // 8 bits tos_tc; // 6 bits NEW: ipv4 { UNCOMPRESSED { version; // 4 bits hdr_length; // 4 bits protocol; // 8 bits dscp; // 6 bits ^^^^ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 17 23:12:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OdH-0000K5-ED; Wed, 17 Jan 2007 23:12:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OdF-0000In-Gk for rohc@ietf.org; Wed, 17 Jan 2007 23:12:09 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7OdD-0004Tw-TT for rohc@ietf.org; Wed, 17 Jan 2007 23:12:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4D1FC90028 for ; Wed, 17 Jan 2007 23:12:04 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20755-02 for ; Wed, 17 Jan 2007 23:11:59 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 17 Jan 2007 23:11:59 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 23:11:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rohc] Regarding ROHC ipv6 Date: Thu, 18 Jan 2007 09:41:55 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C2F8C03@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Regarding ROHC ipv6 Thread-Index: Acc6NiKDQGU4J1cqQzCFKOKkU1SuOAAf/00w From: "Sarkar, Biplab" To: "Haritas Sharma" , X-OriginalArrivalTime: 18 Jan 2007 04:11:59.0732 (UTC) FILETIME=[CCC5C340:01C73AB6] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: Erik Nordmark , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1536137432==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1536137432== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73AB6.CA5541BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73AB6.CA5541BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Haritas, =20 I am not sure what type of impact document you are looking for. For ROHC-over-IPV6 there are RFCs capturing the protocol and also the IPv6CP negotiations for PPP link level negotiations.=20 =20 Thanks Biplab =20 -----Original Message----- From: Haritas Sharma [mailto:haritas71@gmail.com]=20 Sent: Wednesday, January 17, 2007 4:09 PM To: cabo@tzi.org Cc: rohc@ietf.org; Erik Nordmark; haritas71@gmail.com Subject: [rohc] Regarding ROHC ipv6 =20 Hello, =20 I was trying to find an overview of impact of rohc over ipv6 framework. We are using rohc for the PDSN for CDMA2000 network. =20 Any pointers which is already documented, towards this is helpful. =20 Thanks and regards, Haritas ------_=_NextPart_001_01C73AB6.CA5541BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Haritas,

 

I am = not sure what type of impact document you are looking for. For ROHC-over-IPV6 = there are RFCs capturing the protocol and also the IPv6CP negotiations for PPP = link level negotiations.

 

Thanks

Biplab

 

-----Original = Message-----
From: Haritas Sharma [mailto:haritas71@gmail.com]
Sent: Wednesday, January = 17, 2007 4:09 PM
To: cabo@tzi.org
Cc: rohc@ietf.org; Erik = Nordmark; haritas71@gmail.com
Subject: [rohc] Regarding = ROHC ipv6

 

Hello,

 

I was trying to find an overview of impact of = rohc over ipv6 framework.

We are using rohc for the PDSN for CDMA2000 = network.

 

Any pointers which is already documented, = towards this is helpful.

 

Thanks and regards,

Haritas

------_=_NextPart_001_01C73AB6.CA5541BC-- --===============1536137432== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1536137432==-- From rohc-bounces@ietf.org Thu Jan 18 02:15:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7RUU-0006Lz-As; Thu, 18 Jan 2007 02:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Iyi-00025b-A9 for rohc@ietf.org; Wed, 17 Jan 2007 17:09:56 -0500 Received: from smtp.telefonica.net ([213.4.149.66] helo=ctsmtpout4.frontal.correo) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Iyg-00056X-Se for rohc@ietf.org; Wed, 17 Jan 2007 17:09:56 -0500 Received: from hppav (88.18.237.185) by ctsmtpout4.frontal.correo (7.2.056.6) (authenticated as michelle-luis$telefonica.net) id 45AE62BE0000F47F for rohc@ietf.org; Wed, 17 Jan 2007 23:09:53 +0100 Message-ID: <004701c73a84$6e705c60$2301a8c0@local.lan> From: "Michelle Y Luis" To: Date: Wed, 17 Jan 2007 23:11:25 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-Mailman-Approved-At: Thu, 18 Jan 2007 02:15:17 -0500 Subject: [rohc] Question about SigComp Decompression in TCP X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556237330==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1556237330== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C73A8C.CFB00400" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C73A8C.CFB00400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I have been looking for examples of Sigcomp decompression in TCP, = finding RFC4465-SigComp TortureTests as a very useful piece of = information, but I did not find yet a clear answer to the following = scenario so I guess someone in this list can tell me.=20 Say we receive the following compressed string=20 0xFFFF 1234 5678 FF02 90FF ABCD FFFF my question is, should the bytes 0xABCD be sent for decompression even = though they are not qouted by the 0xFF02 delimiter before?, I mean = should the string to be decompressed 0x1234 5678 90FF ABCD or 0x1234 5678 90FF Thanks ------=_NextPart_000_0044_01C73A8C.CFB00400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi All,

I have been looking for examples of Sigcomp = decompression in=20 TCP, finding RFC4465-SigComp TortureTests  as a very useful piece = of=20 information, but I did not find yet a clear answer to the following = scenario so I guess someone in this list can tell me.=20
 
Say we = receive the=20 following compressed string
 
    0xFFFF 1234 5678 FF02 90FF ABCD FFFF
 
my = question is,=20 should the bytes 0xABCD be sent for decompression even though they are = not=20 qouted by the 0xFF02 delimiter before?, I mean should the string to be=20 decompressed
 
    0x1234 5678 90FF ABCD
 
   =20 or
 
    0x1234 5678 90FF
 

Thanks
------=_NextPart_000_0044_01C73A8C.CFB00400-- --===============1556237330== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1556237330==-- From rohc-bounces@ietf.org Thu Jan 18 04:09:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7TGm-0005mU-AT; Thu, 18 Jan 2007 04:09:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7TGl-0005mJ-3p for rohc@ietf.org; Thu, 18 Jan 2007 04:09:15 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7TGj-0007NY-L9 for rohc@ietf.org; Thu, 18 Jan 2007 04:09:15 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id l0I948in007765; Thu, 18 Jan 2007 10:04:09 +0100 (CET) In-Reply-To: <004701c73a84$6e705c60$2301a8c0@local.lan> References: <004701c73a84$6e705c60$2301a8c0@local.lan> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D13358E-5A71-44CC-8BC0-B167FF9D6916@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] Question about SigComp Decompression in TCP Date: Thu, 18 Jan 2007 10:04:05 +0100 To: "Michelle Y Luis" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Carsten Bormann , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Jan 17 2007, at 23:11, Michelle Y Luis wrote: > > Hi All, > > I have been looking for examples of Sigcomp decompression in TCP, > finding RFC4465-SigComp TortureTests as a very useful piece of > information, but I did not find yet a clear answer to the following > scenario so I guess someone in this list can tell me. > > Say we receive the following compressed string > > 0xFFFF 1234 5678 FF02 90FF ABCD FFFF > > my question is, should the bytes 0xABCD be sent for decompression > even though they are not qouted by the 0xFF02 delimiter before?, I > mean should the string to be decompressed > > 0x1234 5678 90FF ABCD > > or > > 0x1234 5678 90FF There is no reason to quote the ABCD, so it is handed through unchanged. The result is: > 1234 5678 FF90 FFAB CD Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 18 04:12:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7TK5-00078H-1i; Thu, 18 Jan 2007 04:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7TK3-000782-KO for rohc@ietf.org; Thu, 18 Jan 2007 04:12:39 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7TJz-0007Av-WC for rohc@ietf.org; Thu, 18 Jan 2007 04:12:39 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE69B20FBE for ; Thu, 18 Jan 2007 10:11:24 +0100 (CET) X-AuditID: c1b4fb3e-a78e9bb000002522-f3-45af39bc8660 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D214420FA7 for ; Thu, 18 Jan 2007 10:11:24 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 10:11:24 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 10:11:24 +0100 Message-ID: <45AF39BC.3000700@ericsson.com> Date: Thu, 18 Jan 2007 10:11:24 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rohc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2007 09:11:24.0371 (UTC) FILETIME=[A0882230:01C73AE0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [rohc] draft-ietf-rohc-sigcomp-impl-guide-10 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, For your information we are doing some tweaking of the SigComp implementors guide using RFC-editor notes in the process of resolving the discusses placed. Currently the below changes are proposed. If you have strong opinion about any of these please respond ASAP. Cheers Magnus First page header: NEW: Updates: RFC 3320, RFC 3321, RFC 3485 (once approved) Title: OLD: Implementer's Guide for SigComp NEW: Signaling Compression (SigComp) Corrections and Clarifications Abstract: OLD: This document (if approved) clarifies and corrects text in the following updated RFCs: RFC 3320, RFC 3321, RFC 3485. NEW: This document updates the following RFCs: RFC 3320, RFC 3321, RFC 3485. Section 1: OLD: "in section 3.4" refers to section 3.4 of this document "in section RFC-3320:3.4 refers to section 3.4 of RFC 3320 [1] NEW: "in section 3.4" refers to section 3.4 of this document "in section RFC3320-3.4" refers to section 3.4 of RFC 3320 [1] Section 2.1, First paragraph: OLD: SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in section RFC3320:7 to be (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2) for those transported over TCP. NEW: SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in section RFC3320-7 to be (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2) for those transported over TCP. Section 12, final paragraph OLD: These are seen to be relatively low cost bugs as only these 5 strings are affected and they are only affected under certain conditions. NEW: This document does not correct the dictionary, as any changes to the dictionary itself would be non-backwards-compatible, and require all implementations to maintain two different copies of the dictionary. Such a cost is far too high for a bug that is trivial to work around and has negligible effect on compression ratios. Instead, we point out the flaw so as to allow implementers to avoid any consequent problems. Specifically: if the bytecodes sent to a remote endpoint contain instructions that load only a sub-portion of the SIP/SDP dictionary, then the input stream provided to those bytecodes cannot reference any of these five offsets in the offset table unless the corresponding string portion of the dictionary has also been loaded. For example, if bytecodes loaded only the first three priorities of the dictionary (both string and offset table), use of the offset for "send" (at 0x089d) would be valid; however, use of the offset for "phone" (at 0x00f2) would not. Please replace all occurances of "Sigcomp" with "SigComp". -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Jan 18 14:41:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d8U-0002c4-CA; Thu, 18 Jan 2007 14:41:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d8R-0002bf-Bb; Thu, 18 Jan 2007 14:41:19 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7d8R-0001GG-2V; Thu, 18 Jan 2007 14:41:19 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E19A026E65; Thu, 18 Jan 2007 19:41:18 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7d8Q-00051R-Px; Thu, 18 Jan 2007 14:41:18 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 18 Jan 2007 14:41:18 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: rohc mailing list , rohc chair , Internet Architecture Board , RFC Editor Subject: [rohc] Protocol Action: 'Implementer's Guide for SigComp' to Proposed Standard X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org The IESG has approved the following document: - 'Implementer's Guide for SigComp ' as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-10.txt Technical Summary This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. Working Group Summary This document has grown through concerns from implementers. The final document has been reviewed by the WG, and there is WG consensus that the document should now be published as an RFC. Document Quality There are several independent implementations of SigComp, which are in general already implemented according to this document. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. Note to RFC Editor First page header: NEW: Updates: RFC 3320, RFC 3321, RFC 3485 (once approved) Title: OLD: Implementer's Guide for SigComp NEW: Signaling Compression (SigComp) Corrections and Clarifications Abstract: OLD: This document (if approved) clarifies and corrects text in the following updated RFCs: RFC 3320, RFC 3321, RFC 3485. NEW: This document updates the following RFCs: RFC 3320, RFC 3321, RFC 3485. Section 1: OLD: "in section 3.4" refers to section 3.4 of this document "in section RFC-3320:3.4 refers to section 3.4 of RFC 3320 [1] NEW: "in section 3.4" refers to section 3.4 of this document "in section RFC3320-3.4" refers to section 3.4 of RFC 3320 [1] Section 2.1, First paragraph: OLD: SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in section RFC3320:7 to be (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2) for those transported over TCP. NEW: SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in section RFC3320-7 to be (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2) for those transported over TCP. Section 12, final paragraph OLD: These are seen to be relatively low cost bugs as only these 5 strings are affected and they are only affected under certain conditions. NEW: This document does not correct the dictionary, as any changes to the dictionary itself would be non-backwards-compatible, and require all implementations to maintain two different copies of the dictionary. Such a cost is far too high for a bug that is trivial to work around and has negligible effect on compression ratios. Instead, we point out the flaw so as to allow implementers to avoid any consequent problems. Specifically: if the bytecodes sent to a remote endpoint contain instructions that load only a sub-portion of the SIP/SDP dictionary, then the input stream provided to those bytecodes cannot reference any of these five offsets in the offset table unless the corresponding string portion of the dictionary has also been loaded. For example, if bytecodes loaded only the first three priorities of the dictionary (both string and offset table), use of the offset for "send" (at 0x089d) would be valid; however, use of the offset for "phone" (at 0x00f2) would not. Please replace all occurances of "Sigcomp" with "SigComp". _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Jan 19 06:04:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rY6-0002kD-8O; Fri, 19 Jan 2007 06:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rY4-0002g5-CM for rohc@ietf.org; Fri, 19 Jan 2007 06:04:44 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7rXx-0000F2-AQ for rohc@ietf.org; Fri, 19 Jan 2007 06:04:44 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 22DBB21827; Fri, 19 Jan 2007 11:59:58 +0100 (CET) X-AuditID: c1b4fb3e-a98edbb000002522-3f-45b0a4ae5adc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 064EE2181B; Fri, 19 Jan 2007 11:59:58 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 11:59:57 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 11:59:57 +0100 Received: from [131.160.126.127] (rvi2-126-127.lmf.ericsson.se [131.160.126.127]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 462E7269D; Fri, 19 Jan 2007 12:59:57 +0200 (EET) Message-ID: <45B0A4AC.5040803@ericsson.com> Date: Fri, 19 Jan 2007 12:59:56 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Surtees, Abigail" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2007 10:59:57.0239 (UTC) FILETIME=[F4EAAC70:01C73BB8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: lars-erik@lejonsson.com, rohc@ietf.org Subject: [rohc] Re: Second WG last-call for SIP/SigComp - dedicated review X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, thanks for your review. Answers inline: > Abstract and introduction: > "Any implementation of SigComp for use with SIP must confirm to this > document." > This sentence appears in the introduction too. What does this mean > without the must being a MUST (I realise it shouldn't be a MUST in the > abstract)? What does this mean for legacy implementations / > implementations conforming to other specifications e.g. 3GPP TS24.229? yes, abstracts should not have normative language. However, you are right pointing out that the second 'must' should be normative. I have moved that text from the Introduction to a new section right after the Terminology section and I have made that 'must' a normative MUST. Of course, specifications should be followed once they are published. Therefore, legacy implementations will, obviously, not be compliant with this document. That is why the document contains a Backwards Compatibility section explaining the situation. Regarding implementations confirming to other specs, the section on Provate Agreements covers that. > Introduction: > "Additionally, it must support ...[3485] and ...[3486]." > Again no standards language. Support for 3485 is specified further on > in the document (so I think isn't needed here) but support for 3486 > isn't so what does this mean for support of that RFC? we do not use normative language because support for RFC 3485 is already normatively mandated in RFC 3485, and support for RFC 3586 is already normatively mandated in RFC 3486. We point to those RFCs, but do not repeat the normative statements here (this is common practice when writing RFCs). > Section 3.1: > I know the 'reason' part here but I think it should be written more > clearly (I think if you were new to it you'd have to read it several > times). Add another sentence to explain the example. Also, the SigComp > user guide refers to 'circular buffer' not 'ring buffer' so it may be > worth using 'circular buffer' here (ring buffer isn't used anywhere > else). I have replaced 'ring buffer' with 'circular buffer'. I will be happy to add the clarifying sentence you request if you provide me with it. > Section 3.2: > The arguments now is: > * 'non-zero SMS removes uncertainty' - that's not strictly true because > the application can still refuse state creation. > * Stateless SIP implementations are unlikely to do SigComp - fair > enough > * 2K per compartment isn't a huge overhead for a stateful > implementation - ok > [12/12/06] Some text has been removed from this section which is fine, > but the first point still seems slightly disingenuous and could cause > confusion. I have performed the following change: OLD: Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether or not it can be created in the remote endpoint. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NEW: Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether the remote endpoint will have enough memory to store such a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ state. ^^^^^^ > Section 3.5: > Add a statement that because the static dictionary is mandatory it does > not need to be advertised (last point in this email discussion > http://www1.ietf.org/mail-archive/web/rohc/current/msg04463.html). I have added: "Note that, since support for the static SIP/SDP dictionary is mandatory, it does not need to be advertised." > Section 8.2 > Re: Use of IP address and port/connection for the remote application > identifier for legacy systems. If a client fails (losing all SIP state > including SigComp compartment) and re-REGISTERS with the same IP > address, how can the SIP stack tell that the old compartment is invalid. > I realise that the answer is probably that this circumstance is > relatively unlikely and that NACK would recover the situation, but I > think this should be made clearer. Implementors are made aware of this type of problem related to legacy systems in the section about Backwards Compatibility. > Section 8.3 > I think this section should be combined with section 8.4. The > definition of when compartments should be opened and closed needs to be > stronger. In this section, section 8.4 and section 12, there are strong > echoes of the fact that it used to be possible to have different > compartment lifetimes. > I think there should be standards language (probably SHOULDs) stating > when compartments should be opened and closed. i.e. compartments SHOULD > last the lifetime of the registration, but leaving the possibility for > early closure and NACK recovery in extreme cases (e.g. overload > conditions). I have combined Sections 8.3 and 8.4, as you suggest. The document already contains normative language regarding when one should open and close compartments. Regarding the MAY strength on compartment closure, we need to leave the door open for implementations to keep states after the registration expires. With respect to your overload example, the document already says that implementations SHOULD NOT close the compartments before the registration expires. Note that we do not use MUST NOT. > Section 8.3 (Paragraph about keeping state beyond the end of a > compartment): > This paragraph still refers to compartments lasting the length of a > dialog or transaction! > How useful is the technique described in this paragraph, now that a > compartment lifetime is a registration? I have removed the text talking about dialogs and transactions. Per my comment above, we do not need to force implementations to close their compartments when the registration expires. If they want to do it, they can do it, but if they don't, they do not harm anyone by not closing the compartment. > Section 8.4 > See comment on section 8.3 about strengthening compartment definition. > I also think the security implications of opening a compartment on > receipt of a REGISTER should be mentioned. Compartments and state can > only be created if the application says so, but, particularly if the > decompressing node is a proxy, the non-2xx response may take a while to > be generated. Non-2xx responses for REGISTER requests are generated immediately. > Section 8.4 > "However, applications MAY also choose to keep these > compartments open for a longer period of time, as discussed > previously." > Does the 'as discussed previously refer to the 'paragraph about keeping > state beyond the end of a compartment'? If so, then i) I'm not sure > it's that useful and ii) the wording implies something different. If > not, then what does it refer to? it refers to the text you point to and, per my comments above, I believe it is indeed a useful feature. > Section 8.5 > I was surprised to see this section (but maybe I missed it's discussion > on the list). I can understand softening the 'SHOULD' in RFC3486, but I > don't think it should be a 'SHOULD NOT' - it depends on the stateless > algorithm in use and the size of the message being compressed. With a > stateless algorithm that has short bytecode and a large message (e.g. > INVITE) it is possible to still achieve non-trivial compression gain. Theoretically, you are right. Practically, no one intends to do that. Note that revision 03 of this draft covered every single scenario you could eventually implement. The conclusion was that the spec needs to focus on realistic scenarios only; this way, it becomes a simpler spec. That is why revision 04 is much simpler than 03. > Section 12: > I think section 12 should either be part of section 8 or become section > 9 (preferably the former) because it is an example of compartment > creation and deletion. This is of course a matter of taste, but, as it is the case in many other RFCs, we have chosen to place the examples at the end of the document. > As mentioned above several sentences have echoes of the possibility of > having variable compartment lifetime: > > "This compartment will be valid, at least, for the > duration of the registration." > Remove the 'at least' > > "The compartment opened by the outbound proxy will be valid, > at least, for the duration of the registration." > Remove the 'at least' The 'at least' is there because implementations may choose to extend the lifetime of the compartment, per my comments above. > "Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of > the compartment created before, this compartment is used to compress > the INVITE request." > What other compartment could be used? The node may have SigComp relationships with other nodes at the same time (e.g., an outbound proxy from other operator for reliability). > Nits: > > Section 3: page 3 > "Note: a SigComp endpoint MAY offer additional resources if available;" > - make clear that it's additional over and above the minimum values > specified in this document rather than the basic SigComp minimum values. Fixed. > Section 4: second paragraph: > > "For a message-based transport such as UDP or SCTP, this can be done per > message." > -> > "For a message-based transport such as UDP or SCTP, distinguishing > between SigComp and non-SigComp messages can be done per message." Fixed. > Section 4: third paragraph: > > "For a stream-based transport such as TCP, this can be done per > connection." > -> > "For a message-based transport such as UDP or SCTP, distinguishing > between SigComp and non-SigComp has to be done per connection." Fixed (taking into account the copy/paste error in your email). > Section 4: final note: > > Refers to 'a SigComp structured TCP connection' - I think the word > structured is unnecessary and mildly confusing in this note. > Alternatively make it 'SigComp-structured' Fixed. > > Section 7: > Phraseology 'failure occurred to' and 'loss occurred to' feel slightly > clumsy. > Rephrase to: > 'failure occurred on' and 'If the response was lost, ...' Fixed. > Section 8.1: > "Incoming responses: the remote application identifier is the same as > the one of the previously-sent request that initiated the transaction > the response belongs to." > -> > "Incoming responses: the remote application identifier is the same as > that of the previously-sent request that initiated the transaction to > which the response belongs." Fixed. > > "Outgoing responses: the remote application identifier is the same as > the previously-received request that initiated the transaction the > response belongs to." > -> > "Outgoing responses: the remote application identifier is the same as > that of the previously-received request that initiated the transaction > to which the response belongs." Fixed. > comparment -> compartment (1 instance in section 8.3 and 1 in section > 11) Fixed. > > Section 8.4: last paragraph > "If following the previous rules" -> "If, following the rules above, " Fixed. I uploaded a working version of revision 05, which includes all the changes above, to: http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-sip-05.txt Let me know if you are OK with this version so that I can submit it. Cheers, Gonzalo _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Jan 26 12:18:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUi5-0005UA-S8; Fri, 26 Jan 2007 12:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUi2-0005Sn-RT for rohc@ietf.org; Fri, 26 Jan 2007 12:17:55 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUht-0006LH-48 for rohc@ietf.org; Fri, 26 Jan 2007 12:17:54 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 76FD5205B4; Fri, 26 Jan 2007 18:17:40 +0100 (CET) X-AuditID: c1b4fb3c-aefc6bb0000007de-0b-45ba37b4cd2c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5725720407; Fri, 26 Jan 2007 18:17:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 18:17:40 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 18:17:39 +0100 Message-ID: <45BA37B2.9000405@ericsson.com> Date: Fri, 26 Jan 2007 18:17:38 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rohc@ietf.org, EPLGHPE , Lars-Erik Jonsson , "Kristofer Sandlund (LU/EAB)" , "West, Mark" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2007 17:17:39.0961 (UTC) FILETIME=[E1D7DE90:01C7416D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [rohc] AD comments on draft-ietf-rohc-tcp-15 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, First sorry for the long delay in getting this review done. First, thanks for a great document. However there are some very minor things that needs to be fixed before going forward. Section 5.2.2, The reference to 5.2.3.1, should be to 5.2.4.1 as I understand it. Question, shouldn't the "should"s in feedback logic in Section 5.3.1.3 and 5.3.1.4 be in capitalized? Section 6.4.1: Last paragraph: "The compressor MAY use the header checksum to validate the correctness of the header before compressing it, to avoid compressing a corrupted header." I wonder how this can be a MAY. To me it should be a requirement to do if you are performing HC and infeering the checksum in the compressor. Changing the packet from one with non-matching checksum to one with a matching one seems pretty serious. Section 8.1: You provide the TCP sequence number with bits assuming that the MTU will be 1500 bytes. Can you please explain what happens in cases when the path MTU is larger than 1500 bytes, like 4k or 9k. I do understand that this is so far not that likely for systems that needs header compression. However I do like to understand what affect this will have. Section 8.2: Please change all the occurances of "tos_tc" to "dscp". Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Jan 26 17:00:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ7F-0004QQ-Sn; Fri, 26 Jan 2007 17:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ7E-0004QL-PW for rohc@ietf.org; Fri, 26 Jan 2007 17:00:12 -0500 Received: from deliverator8.gatech.edu ([130.207.165.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZ7D-0006r3-EX for rohc@ietf.org; Fri, 26 Jan 2007 17:00:12 -0500 Received: from deliverator8.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 33CCFD4 for ; Fri, 26 Jan 2007 17:00:11 -0500 (EST) (envelope-from christian@gatech.edu) Received: from mailprx5.gatech.edu (mailprx5.prism.gatech.edu [130.207.171.19]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "smtp.mail.gatech.edu", Issuer "RSA Data Security, Inc." (verified OK)) by deliverator8.gatech.edu (Postfix) with ESMTP id 9240B122 for ; Fri, 26 Jan 2007 17:00:10 -0500 (EST) (envelope-from christian@gatech.edu) Received: from Christian2 (r82h200.res.gatech.edu [128.61.82.200]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (sasl: method=LOGIN, username=cmenkens3@mailprx5.gatech.edu, sender=n/a) by mailprx5.gatech.edu (Postfix) with ESMTP id 638432383 for ; Fri, 26 Jan 2007 17:00:10 -0500 (EST) (envelope-from christian@gatech.edu) From: "Christian M Menkens" To: Date: Fri, 26 Jan 2007 17:00:08 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdA88eJx9B/bq1hRiKIhAsZend5yQAoVC5w Message-Id: <20070126220010.638432383@mailprx5.gatech.edu> X-GT-Spam-Rating: (7%) X-GT-Spam-Details: The following antispam rules were triggered by this message: Rule Score Description HTML_70_90 0.100 Message is 70-90% HTML X-GT-AVAS-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2007.1.26.134932 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Subject: [rohc] SigComp compression client (or SigComp proxy - client testbed) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1267468478==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1267468478== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0176_01C7416B.6F959A90" This is a multi-part message in MIME format. ------=_NextPart_000_0176_01C7416B.6F959A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I am working on a project in which we have to analyse SigComp compressed SIP messages. This includes call setup, but also notification for presence, location and more, over several types of links. I was looking for clients that can create SigComp compatible compressed SIP messages on the internet, but I couldn't find any that we could use out of the box. The best thing would even be a client and proxy combination that lets us create compressed SIP message flows. Does anybody know any free, evaluation or commercial products that we could use? I already got some really good tips about opensigcomp and other SIP proxy related source or implementation resources on the SIP implementors mailinglist. But our project schedule is quite tight and we don't have much time that we can spend on developing our own test suite. We planned to spend most of the time on analysing the compression, message flows and different link types etc. Thx, Christian M. ---------------------------------------------------- Christian M. Menkens Georgia Institute of Technology christian@gatech.edu ------=_NextPart_000_0176_01C7416B.6F959A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am working on a project in which we have to = analyse SigComp compressed SIP messages. This includes call setup, but also notification for presence, location and more, over several types of = links.

 

I was looking for clients that can create = SigComp compatible compressed SIP messages on the internet, but I couldn’t = find any that we could use out of the box.

The best thing would even be a client and = proxy combination that lets us create compressed SIP message = flows.

 

Does anybody know any free, evaluation or = commercial products that we could use?

 

I already got some really good tips about = opensigcomp and other SIP proxy related source or implementation resources on the = SIP implementors mailinglist. But our project schedule is quite tight and we don’t have much time that we can spend on developing our own test = suite. We planned to spend most of the time on analysing the compression, = message flows and different link types etc.

 

Thx,

 

Christian M.

--------------------------= --------------------------

Christian M. Menkens
Georgia Institute of Technology
christian@gatech.edu<= /font>

 

------=_NextPart_000_0176_01C7416B.6F959A90-- --===============1267468478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1267468478==-- From rohc-bounces@ietf.org Mon Jan 29 10:40:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYca-00006Z-4T; Mon, 29 Jan 2007 10:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYcY-00006U-TU for rohc@ietf.org; Mon, 29 Jan 2007 10:40:38 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYcS-0003jS-9E for rohc@ietf.org; Mon, 29 Jan 2007 10:40:38 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 66788201CA; Mon, 29 Jan 2007 16:38:46 +0100 (CET) X-AuditID: c1b4fb3e-afed3bb0000007e1-ee-45be15068eab Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C9F621480; Mon, 29 Jan 2007 16:38:46 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 16:38:45 +0100 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 Date: Mon, 29 Jan 2007 16:38:45 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> In-Reply-To: <45BA37B2.9000405@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdBbeIJ/k1u//IvSjez0hefsExC4QCJK6mQ From: "Ghyslain Pelletier \(LU/EAB\)" To: "Magnus Westerlund \(KI/EAB\)" , , "Lars-Erik Jonsson" , "Kristofer Sandlund \(LU/EAB\)" , "West, Mark" X-OriginalArrivalTime: 29 Jan 2007 15:38:45.0952 (UTC) FILETIME=[90233400:01C743BB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Magnus, Thanks for your review. > First sorry for the long delay in getting this review done. All things being relative with respect to when this wg started working on a profile for TCP, I would not worry too much over this ; ) See my comments inline. Let me know if these are satisfactory, also let me know if you need an updated draft to be submitted in order to move the draft forward once we've agreed on this. ///Ghyslain Magnus Westerlund wrote: > Hi, >=20 > First sorry for the long delay in getting this review done. >=20 > First, thanks for a great document. However there are some very minor > things that needs to be fixed before going forward. >=20 > Section 5.2.2, The reference to 5.2.3.1, should be to 5.2.4.1 as I > understand it. Agreed. =20 > Question, shouldn't the "should"s in feedback logic in Section 5.3.1.3 > and 5.3.1.4 be in capitalized? No, I think that small "should" is ok in these sections. This is because this is related to something that is very much up to the implementation, but mainly because these shoulds are based on "if context damage is assumed" -- which is itself only loosely defined on purpose. > Section 6.4.1: Last paragraph: > "The compressor MAY use the header checksum to validate the > correctness of the header before compressing it, to avoid > compressing a corrupted header." >=20 > I wonder how this can be a MAY. To me it should be a requirement to do > if you are performing HC and infeering the checksum in the compressor. > Changing the packet from one with non-matching checksum to one with a > matching one seems pretty serious. IMHO I think a MAY here is in fact the only alternative that is proper. My understanding is that making this statement anything else than a MAY would go beyond the scope of a header compression protocol -- there is no requirement to sanity check the protocols that it compresses.=20 While I agree that header compression has the requirement to not produce a decompressed header that differs from the original header (transparency), I do not think it is a requirement of the header compression protocol to generally verify the validity of the semantics of the protocol it compresses for any field, not even for the IP checksum. Therefore, I do not consider this particular issue to be in fact related to transparency, or to impact it in any way. This situation would occur with a packet that is already faulty. The compressor MAY, however, make an additional verification as suggested in the draft, because the regeneration of the checksum is somewhat of a special case as you pointed out. In addition, this type of statement cannot be policed in an implementation, so there is little point in making this a "MUST" anyway. Furthermore, considering that todays L2 are rather strong against residual errors, and that IP stacks that generate erroneous IP checksum are also not the norm, this situation is not expected to occur often enough to make it a case. I am also not too keen in making this extra processing anything else than purely optional, as it would have otherwise to be applied to every packet to catch a potential error with very low probability of occurring. Finally, the TCP checksum is always present to protect TCP (the pseudo header covers the IP source and destination addresses), so would this situation occur the packet will anyway be discarded in the receiving end host. Note finally that there is not a potential failure of the protocol (RoHC-TCP) itself associated with this, i.e. Contexts will not go out of synch and there will be no propagation of this error, if it occurs at all. The sentence that you refer to is there only to highlight that this additional verification is possible, the only other alternative from my perspective (if you deem it to be a problem) would be to remove the sentence. I hope that we can either agree to leave it as it is (with MAY), or alternatively to simply remove it altogether (previous RoHC wg specs don't have such a statement). > Section 8.1: > You provide the TCP sequence number with bits assuming that the MTU > will be 1500 bytes. Can you please explain what happens in cases when > the path MTU is larger than 1500 bytes, like 4k or 9k. I do > understand that this is so far not that likely for systems that needs > header compression. However I do like to understand what affect this > will have.=20 The compressor would have to select a larger packet format, e.g. co_common. > Section 8.2: Please change all the occurances of "tos_tc" to "dscp". Agreed. > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Jan 29 16:52:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBePs-0006j9-GK; Mon, 29 Jan 2007 16:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBePr-0006j4-9s for rohc@ietf.org; Mon, 29 Jan 2007 16:51:55 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBePm-00016e-52 for rohc@ietf.org; Mon, 29 Jan 2007 16:51:55 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l0TLpfNq030599; Mon, 29 Jan 2007 21:51:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Jan 2007 21:51:41 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdBbeIJ/k1u//IvSjez0hefsExC4QCJK6mQABbisEU= References: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> From: "West, Mark" To: "Ghyslain Pelletier \(LU/EAB\)" , "Magnus Westerlund \(KI/EAB\)" , , "Lars-Erik Jonsson" , "Kristofer Sandlund \(LU/EAB\)" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0933592193==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0933592193== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C743EF.A8CED780" This is a multi-part message in MIME format. ------_=_NextPart_001_01C743EF.A8CED780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Section 8.1: > You provide the TCP sequence number with bits assuming that the MTU > will be 1500 bytes. Can you please explain what happens in cases when > the path MTU is larger than 1500 bytes, like 4k or 9k. I do > understand that this is so far not that likely for systems that needs > header compression. However I do like to understand what affect this > will have.=20 The compressor would have to select a larger packet format, e.g. co_common. [Mark] and to put this in context, a co_common packet in a bulk-transfer = environment (in the data-transfer direction) might be something like 10 = - 12 octets. With a 4kbyte packet, this is 0.3% overhead (compared with = 1% for no compression). The bigger cost is in the 'ack' direction, = since all of an 'ack' is overhead. However, where we have a link with = such a large MTU, we are effectively making some assumptions about the = degree of asymmetry and the overall link capacity. But I don't really = see that as a problem... [Mark] I also support Ghyslain's statement on the issue of the = compressor verifying checksums. Cheers, Mark. ------_=_NextPart_001_01C743EF.A8CED780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AD comments on draft-ietf-rohc-tcp-15

> Section 8.1:
> You provide the TCP sequence number with bits assuming that the = MTU
> will be 1500 bytes. Can you please explain what happens in cases = when
> the path MTU is larger than 1500 bytes, like 4k or 9k. I do
> understand that this is so far not that likely for systems that = needs
> header compression. However I do like to understand what affect = this
> will have.

The compressor would have to select a larger packet format, e.g.
co_common.

[Mark] and to put this in context, a co_common packet in a bulk-transfer = environment (in the data-transfer direction) might be something like 10 = - 12 octets.  With a 4kbyte packet, this is 0.3% overhead (compared = with 1% for no compression).  The bigger cost is in the 'ack' = direction, since all of an 'ack' is overhead.  However, where we = have a link with such a large MTU, we are effectively making some = assumptions about the degree of asymmetry and the overall link = capacity.  But I don't really see that as a problem...

[Mark] I also support Ghyslain's statement on the issue of the = compressor verifying checksums.

Cheers,

Mark.

------_=_NextPart_001_01C743EF.A8CED780-- --===============0933592193== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0933592193==-- From rohc-bounces@ietf.org Tue Jan 30 12:12:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwXB-0005JG-17; Tue, 30 Jan 2007 12:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwX9-0005CJ-Ex for rohc@ietf.org; Tue, 30 Jan 2007 12:12:39 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwWx-00043p-OP for rohc@ietf.org; Tue, 30 Jan 2007 12:12:37 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 23C7D20513; Tue, 30 Jan 2007 18:12:25 +0100 (CET) X-AuditID: c1b4fb3e-b06d4bb0000007e1-24-45bf7c79ec70 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F287B2019F; Tue, 30 Jan 2007 18:12:24 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:12:24 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 18:12:24 +0100 Message-ID: <45BF7C78.30207@ericsson.com> Date: Tue, 30 Jan 2007 18:12:24 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Ghyslain Pelletier (LU/EAB)" References: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2007 17:12:24.0271 (UTC) FILETIME=[CF5465F0:01C74491] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Lars-Erik Jonsson , "West, Mark" , rohc@ietf.org Subject: [rohc] Re: AD comments on draft-ietf-rohc-tcp-15 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Ghyslain Pelletier (LU/EAB) skrev: > >> Section 6.4.1: Last paragraph: >> "The compressor MAY use the header checksum to validate the >> correctness of the header before compressing it, to avoid >> compressing a corrupted header." >> >> I wonder how this can be a MAY. To me it should be a requirement to do >> if you are performing HC and infeering the checksum in the compressor. >> Changing the packet from one with non-matching checksum to one with a >> matching one seems pretty serious. > > IMHO I think a MAY here is in fact the only alternative that is proper. > > My understanding is that making this statement anything else than a MAY > would go beyond the scope of a header compression protocol -- there is > no requirement to sanity check the protocols that it compresses. > > While I agree that header compression has the requirement to not produce > a decompressed header that differs from the original header > (transparency), I do not think it is a requirement of the header > compression protocol to generally verify the validity of the semantics > of the protocol it compresses for any field, not even for the IP > checksum. > > Therefore, I do not consider this particular issue to be in fact related > to transparency, or to impact it in any way. This situation would occur > with a packet that is already faulty. > > The compressor MAY, however, make an additional verification as > suggested in the draft, because the regeneration of the checksum is > somewhat of a special case as you pointed out. > > In addition, this type of statement cannot be policed in an > implementation, so there is little point in making this a "MUST" anyway. > Furthermore, considering that todays L2 are rather strong against > residual errors, and that IP stacks that generate erroneous IP checksum > are also not the norm, this situation is not expected to occur often > enough to make it a case. I am also not too keen in making this extra > processing anything else than purely optional, as it would have > otherwise to be applied to every packet to catch a potential error with > very low probability of occurring. > > Finally, the TCP checksum is always present to protect TCP (the pseudo > header covers the IP source and destination addresses), so would this > situation occur the packet will anyway be discarded in the receiving end > host. > > Note finally that there is not a potential failure of the protocol > (RoHC-TCP) itself associated with this, i.e. Contexts will not go out of > synch and there will be no propagation of this error, if it occurs at > all. > > The sentence that you refer to is there only to highlight that this > additional verification is possible, the only other alternative from my > perspective (if you deem it to be a problem) would be to remove the > sentence. > > I hope that we can either agree to leave it as it is (with MAY), or > alternatively to simply remove it altogether (previous RoHC wg specs > don't have such a statement). > Hi, I am not agreeing here. To me it seems that allowing the usage of inferred IPv4 Header checksum without verifying the checksum prior to compression allows for non-transparent header compression. Sure the IP header fields that may be incorrect are limited to the ones outside of the TCP pseudo header. However that includes a number of important fields, including DSCP. The reason I think it is a transparency issue is that a erroneous IP header arrive at the compressor. If the checksum would be checked the compressor would discard the packet. The compressor compresses it using the inferred IPv4 checksum. The decompressor reconstructs the same header as previous with the exception that the IPv4 header checksum now matches the reconstructed header. Thus incomming IPv4 Header is different from outgoing. Transparency failure. Thus I still think this should be a MUST to ensure the transparency of the compression. cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Jan 30 17:53:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1qp-00083S-U2; Tue, 30 Jan 2007 17:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC1qo-00083L-H9 for rohc@ietf.org; Tue, 30 Jan 2007 17:53:18 -0500 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC1qn-0003Ye-Lv for rohc@ietf.org; Tue, 30 Jan 2007 17:53:18 -0500 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l0UMqxGM009074; Tue, 30 Jan 2007 22:52:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 22:52:58 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdEkdnaa7P4jPShSOqLkII0T4W8eAALRh9k References: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> <45BF7C78.30207@ericsson.com> From: "West, Mark" To: "Magnus Westerlund" , "Ghyslain Pelletier \(LU/EAB\)" X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: mark.a.west@roke.co.uk X-Spam-Score: 0.5 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: Lars-Erik Jonsson , rohc@ietf.org Subject: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1784887286==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1784887286== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C744C1.62FCE562" This is a multi-part message in MIME format. ------_=_NextPart_001_01C744C1.62FCE562 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But, playing devil's advocate, does the responsibility for checking and = discarding packets not lie with the receiving interface? That is, the = compressor should never see a packet with an erroneous IP checksum. In = which case, this text seems redundant? Honestly, I'm not sure any more. = But if this isn't in RFC 3095 (or any of the subsequent other = compression profiles, such as UDP-lite, IP-only, ...), then why have we = only just spotted it?! (And I haven't checked the mailing list archive, but I've just had a = definite sense of deja vu about this discussion...) Cheers, Mark. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Tue 30/01/2007 17:12 To: Ghyslain Pelletier (LU/EAB) Cc: rohc@ietf.org; Lars-Erik Jonsson; Kristofer Sandlund (LU/EAB); West, = Mark Subject: Re: AD comments on draft-ietf-rohc-tcp-15 =20 Ghyslain Pelletier (LU/EAB) skrev: >=20 >> Section 6.4.1: Last paragraph: >> "The compressor MAY use the header checksum to validate the >> correctness of the header before compressing it, to avoid >> compressing a corrupted header." >> >> I wonder how this can be a MAY. To me it should be a requirement to = do >> if you are performing HC and infeering the checksum in the = compressor. >> Changing the packet from one with non-matching checksum to one with a >> matching one seems pretty serious. >=20 > IMHO I think a MAY here is in fact the only alternative that is = proper. >=20 > My understanding is that making this statement anything else than a = MAY > would go beyond the scope of a header compression protocol -- there is > no requirement to sanity check the protocols that it compresses.=20 >=20 > While I agree that header compression has the requirement to not = produce > a decompressed header that differs from the original header > (transparency), I do not think it is a requirement of the header > compression protocol to generally verify the validity of the semantics > of the protocol it compresses for any field, not even for the IP > checksum. >=20 > Therefore, I do not consider this particular issue to be in fact = related > to transparency, or to impact it in any way. This situation would = occur > with a packet that is already faulty. >=20 > The compressor MAY, however, make an additional verification as > suggested in the draft, because the regeneration of the checksum is > somewhat of a special case as you pointed out. >=20 > In addition, this type of statement cannot be policed in an > implementation, so there is little point in making this a "MUST" = anyway. > Furthermore, considering that todays L2 are rather strong against > residual errors, and that IP stacks that generate erroneous IP = checksum > are also not the norm, this situation is not expected to occur often > enough to make it a case. I am also not too keen in making this extra > processing anything else than purely optional, as it would have > otherwise to be applied to every packet to catch a potential error = with > very low probability of occurring. >=20 > Finally, the TCP checksum is always present to protect TCP (the pseudo > header covers the IP source and destination addresses), so would this > situation occur the packet will anyway be discarded in the receiving = end > host. >=20 > Note finally that there is not a potential failure of the protocol > (RoHC-TCP) itself associated with this, i.e. Contexts will not go out = of > synch and there will be no propagation of this error, if it occurs at > all. >=20 > The sentence that you refer to is there only to highlight that this > additional verification is possible, the only other alternative from = my > perspective (if you deem it to be a problem) would be to remove the > sentence. >=20 > I hope that we can either agree to leave it as it is (with MAY), or > alternatively to simply remove it altogether (previous RoHC wg specs > don't have such a statement). >=20 Hi, I am not agreeing here. To me it seems that allowing the usage of=20 inferred IPv4 Header checksum without verifying the checksum prior to=20 compression allows for non-transparent header compression. Sure the IP=20 header fields that may be incorrect are limited to the ones outside of=20 the TCP pseudo header. However that includes a number of important=20 fields, including DSCP. The reason I think it is a transparency issue is = that a erroneous IP header arrive at the compressor. If the checksum=20 would be checked the compressor would discard the packet. The compressor = compresses it using the inferred IPv4 checksum. The decompressor=20 reconstructs the same header as previous with the exception that the=20 IPv4 header checksum now matches the reconstructed header. Thus=20 incomming IPv4 Header is different from outgoing. Transparency failure. Thus I still think this should be a MUST to ensure the transparency of=20 the compression. cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------_=_NextPart_001_01C744C1.62FCE562 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AD comments on draft-ietf-rohc-tcp-15

But, playing devil's advocate, does the responsibility = for checking and discarding packets not lie with the receiving = interface?  That is, the compressor should never see a packet with = an erroneous IP checksum.  In which case, this text seems = redundant?  Honestly, I'm not sure any more.  But if this = isn't in RFC 3095 (or any of the subsequent other compression profiles, = such as UDP-lite, IP-only, ...), then why have we only just spotted = it?!

(And I haven't checked the mailing list archive, but I've just had a = definite sense of deja vu about this discussion...)

Cheers,

Mark.



-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@e= ricsson.com]
Sent: Tue 30/01/2007 17:12
To: Ghyslain Pelletier (LU/EAB)
Cc: rohc@ietf.org; Lars-Erik Jonsson; Kristofer Sandlund (LU/EAB); West, = Mark
Subject: Re: AD comments on draft-ietf-rohc-tcp-15

Ghyslain Pelletier (LU/EAB) skrev:
>
>> Section 6.4.1: Last paragraph:
>>    "The compressor MAY use the header = checksum to validate the
>>     correctness of the header before = compressing it, to avoid
>>     compressing a corrupted = header."
>>
>> I wonder how this can be a MAY. To me it should be a = requirement to do
>> if you are performing HC and infeering the checksum in the = compressor.
>> Changing the packet from one with non-matching checksum to one = with a
>> matching one seems pretty serious.
>
> IMHO I think a MAY here is in fact the only alternative that is = proper.
>
> My understanding is that making this statement anything else than a = MAY
> would go beyond the scope of a header compression protocol -- there = is
> no requirement to sanity check the protocols that it = compresses.
>
> While I agree that header compression has the requirement to not = produce
> a decompressed header that differs from the original header
> (transparency), I do not think it is a requirement of the = header
> compression protocol to generally verify the validity of the = semantics
> of the protocol it compresses for any field, not even for the = IP
> checksum.
>
> Therefore, I do not consider this particular issue to be in fact = related
> to transparency, or to impact it in any way. This situation would = occur
> with a packet that is already faulty.
>
> The compressor MAY, however, make an additional verification as
> suggested in the draft, because the regeneration of the checksum = is
> somewhat of a special case as you pointed out.
>
> In addition, this type of statement cannot be policed in an
> implementation, so there is little point in making this a = "MUST" anyway.
> Furthermore, considering that todays L2 are rather strong = against
> residual errors, and that IP stacks that generate erroneous IP = checksum
> are also not the norm, this  situation is not expected to = occur often
> enough to make it a case. I am also not too keen in making this = extra
> processing anything else than purely optional, as it would have
> otherwise to be applied to every packet to catch a potential error = with
> very low probability of occurring.
>
> Finally, the TCP checksum is always present to protect TCP (the = pseudo
> header covers the IP source and destination addresses), so would = this
> situation occur the packet will anyway be discarded in the = receiving end
> host.
>
> Note finally that there is not a potential failure of the = protocol
> (RoHC-TCP) itself associated with this, i.e. Contexts will not go = out of
> synch and there will be no propagation of this error, if it occurs = at
> all.
>
> The sentence that you refer to is there only to highlight that = this
> additional verification is possible, the only other alternative = from my
> perspective (if you deem it to be a problem) would be to remove = the
> sentence.
>
> I hope that we can either agree to leave it as it is (with MAY), = or
> alternatively to simply remove it altogether (previous RoHC wg = specs
> don't have such a statement).
>

Hi,

I am not agreeing here. To me it seems that allowing the usage of
inferred IPv4 Header checksum without verifying the checksum prior = to
compression allows for non-transparent header compression. Sure the = IP
header fields that may be incorrect are limited to the ones outside = of
the TCP pseudo header. However that includes a number of important
fields, including DSCP. The reason I think it is a transparency issue = is
that a erroneous IP header arrive at the compressor. If the checksum
would be checked the compressor would discard the packet. The = compressor
compresses it using the inferred IPv4 checksum. The decompressor
reconstructs the same header as previous with the exception that the
IPv4 header checksum now matches the reconstructed header. Thus
incomming IPv4 Header is different from outgoing. Transparency = failure.
Thus I still think this should be a MUST to ensure the transparency = of
the compression.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A
---------------------------------------------------------------------- Ericsson = AB            = ;    | Phone +46 8 4048287
Torshamsgatan = 23           | = Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------









------_=_NextPart_001_01C744C1.62FCE562-- --===============1784887286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1784887286==-- From rohc-bounces@ietf.org Tue Jan 30 18:33:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Tb-0001zn-Rc; Tue, 30 Jan 2007 18:33:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2TZ-0001zg-Ue for rohc@ietf.org; Tue, 30 Jan 2007 18:33:22 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HC2TY-0001w6-Fc for rohc@ietf.org; Tue, 30 Jan 2007 18:33:21 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id l0UNSGmo026107; Wed, 31 Jan 2007 00:28:16 +0100 (CET) In-Reply-To: References: <026F8EEDAD2C4342A993203088C1FC0504510F45@esealmw109.eemea.ericsson.se> <45BF7C78.30207@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68D2AD6A-C3DE-4E65-AF7E-F99E4BB566B5@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 00:28:15 +0100 To: "West, Mark" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Magnus Westerlund , Carsten Bormann , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" , Lars-Erik Jonsson X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Jan 30 2007, at 23:52, West, Mark wrote: > (And I haven't checked the mailing list archive, but I've just had > a definite sense of deja vu about this discussion...) We sure spent a lot of time on this set of issues on a certain May 29th in 2000... We since had a long-running WG consensus that IPv4 checksums are worthless. (Somehow, the parents of IPv6 must have arrived at the same conclusion six years earlier.) Mark is right that IPv4 packets with header checksum errors should never reach a compressor, as the checksum should have been checked on the incoming interface. (Do routers still do this these days?) Only certain exotic "bridge-mode" configurations would be an exception to this. And, of course, bit errors in memory (where the packet will have lived after checksumming its header) will not be caught. October 27, 1980 notwithstanding*), I wouldn't care. Gruesse, Carsten *) RFC 789, if this reference is opaque to you. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 02:33:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9xP-0001Dd-8Y; Wed, 31 Jan 2007 02:32:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC9xO-0001Av-C9 for rohc@ietf.org; Wed, 31 Jan 2007 02:32:38 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC9xH-0005Uc-UU for rohc@ietf.org; Wed, 31 Jan 2007 02:32:38 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1E34F208A8; Wed, 31 Jan 2007 08:32:21 +0100 (CET) X-AuditID: c1b4fb3c-b17cbbb0000007de-1d-45c0460528ca Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 129D92083A; Wed, 31 Jan 2007 08:32:21 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 08:32:20 +0100 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: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 08:32:19 +0100 Message-ID: In-Reply-To: <68D2AD6A-C3DE-4E65-AF7E-F99E4BB566B5@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdExqasoxBMVnsfSq2S5gBQNg/QNwAQRRKw From: "Kristofer Sandlund \(LU/EAB\)" To: "Carsten Bormann" , "West, Mark" , "Magnus Westerlund \(KI/EAB\)" , "Ghyslain Pelletier \(LU/EAB\)" X-OriginalArrivalTime: 31 Jan 2007 07:32:20.0512 (UTC) FILETIME=[F115FA00:01C74509] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Lars-Erik Jonsson , rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, although it has been ignored in the past ROHC specifications, I agree=20 with Magnus point. But as Mark stated, this will _usually_ be checked by the receiving interface. Maybe we can re-phrase the text a bit so that we don't say that the _compressor_ has to verify the checksum=20 and instead write that: "...MUST NOT compress packets with an invalid IPv4 checksum" That way, most deployments won't have to do anything as the compressor will know that the checksum has already been verified by another layer and we don't risk breaking compression transparency. /Kristofer _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 03:04:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCASW-0006XL-E7; Wed, 31 Jan 2007 03:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCASV-0006WW-AT for rohc@ietf.org; Wed, 31 Jan 2007 03:04:47 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCASL-00052P-Me for rohc@ietf.org; Wed, 31 Jan 2007 03:04:47 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1872520912; Wed, 31 Jan 2007 09:04:33 +0100 (CET) X-AuditID: c1b4fb3c-ae7c5bb0000007de-b6-45c04d91b7ad Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 000F8208F5; Wed, 31 Jan 2007 09:04:32 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:04:32 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:04:32 +0100 Message-ID: <45C04D90.7000603@ericsson.com> Date: Wed, 31 Jan 2007 09:04:32 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Kristofer Sandlund (LU/EAB)" Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 08:04:32.0251 (UTC) FILETIME=[707DF4B0:01C7450E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "West, Mark" , Lars-Erik Jonsson , Carsten Bormann , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Kristofer Sandlund (LU/EAB) skrev: > Hi, > > although it has been ignored in the past ROHC specifications, I agree > with Magnus point. But as Mark stated, this will _usually_ be > checked by the receiving interface. Maybe we can re-phrase the text a > bit > so that we don't say that the _compressor_ has to verify the checksum > and instead write that: > "...MUST NOT compress packets with an invalid IPv4 checksum" > That way, most deployments won't have to do anything as the compressor > will > know that the checksum has already been verified by another layer and we > don't risk breaking compression transparency. > > /Kristofer This sounds like a fine rewording to me. I would also suggest that you qualify this with explicitly stating the assumption that the receiving interface of the device the compressor is running on will perform this check. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 04:08:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBSI-0001eS-Hw; Wed, 31 Jan 2007 04:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBSH-0001dw-OO for rohc@ietf.org; Wed, 31 Jan 2007 04:08:37 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBSB-0005XM-2V for rohc@ietf.org; Wed, 31 Jan 2007 04:08:37 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3713B2139A; Wed, 31 Jan 2007 10:07:20 +0100 (CET) X-AuditID: c1b4fb3e-af6d2bb0000007e1-e6-45c05c48fb57 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20DD721395; Wed, 31 Jan 2007 10:07:20 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:07:19 +0100 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: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 10:07:19 +0100 Message-ID: In-Reply-To: <45C056DA.9010507@effnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdFE4Ird9yFe7DjSZyVa4cNM9idUwAAxs5A From: "Kristofer Sandlund \(LU/EAB\)" To: "Carl Knutsson" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 31 Jan 2007 09:07:19.0663 (UTC) FILETIME=[360B67F0:01C74517] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "West, Mark" , Lars-Erik Jonsson , Carsten Bormann , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Carl Knutsson wrote on den 31 januari 2007 09:44 : > Hi, >=20 > Magnus Westerlund wrote: >> Kristofer Sandlund (LU/EAB) skrev: >>> Hi, >>>=20 >>> although it has been ignored in the past ROHC specifications, I >>> agree with Magnus point. But as Mark stated, this will _usually_ be >>> checked by the receiving interface. Maybe we can re-phrase the text >>> a bit so that we don't say that the _compressor_ has to verify the >>> checksum and instead write that: "...MUST NOT compress packets >>> with an invalid IPv4 checksum" That way, most deployments won't >>> have to do anything as the compressor will know that the checksum >>> has already been verified by another layer and we don't risk >>> breaking compression transparency.=20 >>>=20 >=20 > Before you go ahead with this change, I just want to remind you that a > packet with an incorrect IPv4 checksum can be compressed transparently > with the uncompressed profile. >=20 > /Calle But we're only discussing the ROHC-TCP profile here, so this change should not affect the ability of the uncompressed profile to be used. I guess we _could_ write "..MUST not be compressed using this profile", but I don't think that really adds anything, so I'd prefer not to do that. /Kristofer >=20 >=20 >>> /Kristofer >>=20 >> This sounds like a fine rewording to me. I would also suggest that >> you qualify this with explicitly stating the assumption that the >> receiving interface of the device the compressor is running on will >> perform this check.=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> IETF Transport Area Director & TSVWG Chair >>=20 > ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVA/A >>=20 > ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>=20 > ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> 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 From rohc-bounces@ietf.org Wed Jan 31 04:30:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBnk-0003bk-Gl; Wed, 31 Jan 2007 04:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCB50-0007ex-Jc for rohc@ietf.org; Wed, 31 Jan 2007 03:44:34 -0500 Received: from [194.237.235.30] (helo=effnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCB4z-0007o2-4h for rohc@ietf.org; Wed, 31 Jan 2007 03:44:34 -0500 Received: from [192.168.101.101] (c-ef7c71d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.124.239]) (authenticated bits=0) by effnet.com (8.12.3/8.12.3) with ESMTP id l0V91KYp031476 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 31 Jan 2007 10:01:21 +0100 Message-ID: <45C056DA.9010507@effnet.com> Date: Wed, 31 Jan 2007 09:44:10 +0100 From: Carl Knutsson User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: <45C04D90.7000603@ericsson.com> In-Reply-To: <45C04D90.7000603@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-Mailman-Approved-At: Wed, 31 Jan 2007 04:30:47 -0500 Cc: "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, Magnus Westerlund wrote: > Kristofer Sandlund (LU/EAB) skrev: >> Hi, >> >> although it has been ignored in the past ROHC specifications, I agree >> with Magnus point. But as Mark stated, this will _usually_ be >> checked by the receiving interface. Maybe we can re-phrase the text a >> bit >> so that we don't say that the _compressor_ has to verify the checksum >> and instead write that: >> "...MUST NOT compress packets with an invalid IPv4 checksum" >> That way, most deployments won't have to do anything as the compressor >> will >> know that the checksum has already been verified by another layer and we >> don't risk breaking compression transparency. >> Before you go ahead with this change, I just want to remind you that a packet with an incorrect IPv4 checksum can be compressed transparently with the uncompressed profile. /Calle >> /Kristofer > > This sounds like a fine rewording to me. I would also suggest that you > qualify this with explicitly stating the assumption that the receiving > interface of the device the compressor is running on will perform this > check. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 From rohc-bounces@ietf.org Wed Jan 31 04:42:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBz4-000053-ME; Wed, 31 Jan 2007 04:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBz3-0008TR-Gx for rohc@ietf.org; Wed, 31 Jan 2007 04:42:29 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCBx3-00012H-GN for rohc@ietf.org; Wed, 31 Jan 2007 04:40:32 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CE69220553; Wed, 31 Jan 2007 10:40:20 +0100 (CET) X-AuditID: c1b4fb3e-aeed1bb0000007e1-3e-45c06404e991 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5A1C212CA; Wed, 31 Jan 2007 10:40:20 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:40:04 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 10:03:47 +0100 Message-ID: <45C05B73.5040506@ericsson.com> Date: Wed, 31 Jan 2007 10:03:47 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Carl Knutsson Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com> In-Reply-To: <45C056DA.9010507@effnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 09:03:47.0664 (UTC) FILETIME=[B7AEED00:01C74516] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Carl Knutsson skrev: > Hi, > > Magnus Westerlund wrote: >> Kristofer Sandlund (LU/EAB) skrev: >>> Hi, >>> >>> although it has been ignored in the past ROHC specifications, I agree >>> with Magnus point. But as Mark stated, this will _usually_ be >>> checked by the receiving interface. Maybe we can re-phrase the text a >>> bit >>> so that we don't say that the _compressor_ has to verify the checksum >>> and instead write that: >>> "...MUST NOT compress packets with an invalid IPv4 checksum" >>> That way, most deployments won't have to do anything as the compressor >>> will >>> know that the checksum has already been verified by another layer and we >>> don't risk breaking compression transparency. >>> > > Before you go ahead with this change, I just want to remind you that a > packet with an incorrect IPv4 checksum can be compressed transparently > with the uncompressed profile. > The issue is still that you can't use inferred IPv4 checksum unless you know that it would be correct. Thus you would need to perform the checksum calculation to know this. And in case you have a failure of the checksum you should drop the packet. As I see it there are no need to compress a packet with an erroneous IP header. To me it seems that the fact of this case is that you can't use inferred checksum unless you know that checksum prior to compression matches the header. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 08:36:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFdp-0004Gf-Ke; Wed, 31 Jan 2007 08:36:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFdo-0004Ga-JR for rohc@ietf.org; Wed, 31 Jan 2007 08:36:48 -0500 Received: from mxi.ltu.se ([130.240.42.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFdk-0008He-UA for rohc@ietf.org; Wed, 31 Jan 2007 08:36:48 -0500 Received: from sm.luth.se (lisa.sm.luth.se [130.240.3.1]) by mxi.ltu.se (8.13.1/8.13.1) with ESMTP id l0VDac68019765; Wed, 31 Jan 2007 14:36:38 +0100 Received: from localhost (localhost [127.0.0.1]) by sm.luth.se (8.13.8/8.13.8) with ESMTP id l0VDaJU9017751; Wed, 31 Jan 2007 14:36:19 +0100 (MET) Received: from 217.213.125.0 ([217.213.125.0]) by www.sm.luth.se (IMP) with HTTP for ; Wed, 31 Jan 2007 14:36:19 +0100 Message-ID: <1170250579.45c09b534134f@www.sm.luth.se> Date: Wed, 31 Jan 2007 14:36:19 +0100 From: pelle@cdt.luth.se To: Magnus Westerlund Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com> <45C05B73.5040506@ericsson.com> In-Reply-To: <45C05B73.5040506@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 217.213.125.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , Carl Knutsson , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Magnus, Kristofer, I totally disagree with changing the current wording. I totally agree with Carsten and Mark opinion previously expressed on this thread, which arguments were very much in-line with my initial answer. I think that we should not specify anything in our profiles that would lead to a compressor discarding a packet. Once again, it is not the responsability of header compression to police other protocol/stack behavior. Wrt to the "transparency issue", header compression has always used the assumption that erroneous IP checksums would never reach the compressor, and Carsten in addition pointed out that this has been discussed and agreed long time ago. Furthermore, as Carsten pointed out, IPv6 folks did not even include a cheksum in the IPv6 header for a reason. Personally, I would remove the sentence entirely, and I think that would follow all other other RoHC specs very nicely. Regards, ///Ghyslain Quoting Magnus Westerlund : > Carl Knutsson skrev: > > Hi, > > > > Magnus Westerlund wrote: > >> Kristofer Sandlund (LU/EAB) skrev: > >>> Hi, > >>> > >>> although it has been ignored in the past ROHC specifications, I agree > >>> with Magnus point. But as Mark stated, this will _usually_ be > >>> checked by the receiving interface. Maybe we can re-phrase the text a > >>> bit > >>> so that we don't say that the _compressor_ has to verify the checksum > >>> and instead write that: > >>> "...MUST NOT compress packets with an invalid IPv4 checksum" > >>> That way, most deployments won't have to do anything as the compressor > >>> will > >>> know that the checksum has already been verified by another layer and we > >>> don't risk breaking compression transparency. > >>> > > > > Before you go ahead with this change, I just want to remind you that a > > packet with an incorrect IPv4 checksum can be compressed transparently > > with the uncompressed profile. > > > > The issue is still that you can't use inferred IPv4 checksum unless you > know that it would be correct. Thus you would need to perform the > checksum calculation to know this. And in case you have a failure of the > checksum you should drop the packet. As I see it there are no need to > compress a packet with an erroneous IP header. To me it seems that the > fact of this case is that you can't use inferred checksum unless you > know that checksum prior to compression matches the header. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 From rohc-bounces@ietf.org Wed Jan 31 08:38:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFf1-0004nC-Tk; Wed, 31 Jan 2007 08:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFf0-0004n4-5X for rohc@ietf.org; Wed, 31 Jan 2007 08:38:02 -0500 Received: from mxi.ltu.se ([130.240.42.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFey-0000B1-KG for rohc@ietf.org; Wed, 31 Jan 2007 08:38:02 -0500 Received: from sm.luth.se (lisa.sm.luth.se [130.240.3.1]) by mxi.ltu.se (8.13.1/8.13.1) with ESMTP id l0VDbktc019852; Wed, 31 Jan 2007 14:37:51 +0100 Received: from localhost (localhost [127.0.0.1]) by sm.luth.se (8.13.8/8.13.8) with ESMTP id l0VDbjAY021726; Wed, 31 Jan 2007 14:37:45 +0100 (MET) Received: from 217.213.125.0 ([217.213.125.0]) by www.sm.luth.se (IMP) with HTTP for ; Wed, 31 Jan 2007 14:37:44 +0100 Message-ID: <1170250664.45c09ba8e3362@www.sm.luth.se> Date: Wed, 31 Jan 2007 14:37:44 +0100 From: pelle@cdt.luth.se To: Magnus Westerlund Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com> <45C05B73.5040506@ericsson.com> In-Reply-To: <45C05B73.5040506@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 217.213.125.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , Carl Knutsson , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Magnus, Kristofer, I totally disagree with changing the current wording. I totally agree with Carsten and Mark opinion previously expressed on this thread, which arguments were very much in-line with my initial answer. I think that we should not specify anything in our profiles that would lead to a compressor discarding a packet. Once again, it is not the responsability of header compression to police other protocol/stack behavior. Wrt to the "transparency issue", header compression has always used the assumption that erroneous IP checksums would never reach the compressor, and Carsten in addition pointed out that this has been discussed and agreed long time ago. Furthermore, as Carsten pointed out, IPv6 folks did not even include a cheksum in the IPv6 header for a reason. Personally, I would remove the sentence entirely, and I think that would follow all other other RoHC specs very nicely. Regards, ///Ghyslain Quoting Magnus Westerlund : > Carl Knutsson skrev: > > Hi, > > > > Magnus Westerlund wrote: > >> Kristofer Sandlund (LU/EAB) skrev: > >>> Hi, > >>> > >>> although it has been ignored in the past ROHC specifications, I agree > >>> with Magnus point. But as Mark stated, this will _usually_ be > >>> checked by the receiving interface. Maybe we can re-phrase the text a > >>> bit > >>> so that we don't say that the _compressor_ has to verify the checksum > >>> and instead write that: > >>> "...MUST NOT compress packets with an invalid IPv4 checksum" > >>> That way, most deployments won't have to do anything as the compressor > >>> will > >>> know that the checksum has already been verified by another layer and we > >>> don't risk breaking compression transparency. > >>> > > > > Before you go ahead with this change, I just want to remind you that a > > packet with an incorrect IPv4 checksum can be compressed transparently > > with the uncompressed profile. > > > > The issue is still that you can't use inferred IPv4 checksum unless you > know that it would be correct. Thus you would need to perform the > checksum calculation to know this. And in case you have a failure of the > checksum you should drop the packet. As I see it there are no need to > compress a packet with an erroneous IP header. To me it seems that the > fact of this case is that you can't use inferred checksum unless you > know that checksum prior to compression matches the header. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > 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 From rohc-bounces@ietf.org Wed Jan 31 08:48:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFoe-0001ub-Vb; Wed, 31 Jan 2007 08:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFod-0001qq-BD for rohc@ietf.org; Wed, 31 Jan 2007 08:47:59 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFoX-00031u-SR for rohc@ietf.org; Wed, 31 Jan 2007 08:47:59 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 413DA207F3; Wed, 31 Jan 2007 14:47:53 +0100 (CET) X-AuditID: c1b4fb3c-b0fcabb0000007de-bc-45c09e09ce56 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 222AD205A8; Wed, 31 Jan 2007 14:47:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:47:52 +0100 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:47:52 +0100 Message-ID: <45C09E08.7000502@ericsson.com> Date: Wed, 31 Jan 2007 14:47:52 +0100 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: pelle@cdt.luth.se Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com> <45C05B73.5040506@ericsson.com> <1170250664.45c09ba8e3362@www.sm.luth.se> In-Reply-To: <1170250664.45c09ba8e3362@www.sm.luth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 13:47:52.0342 (UTC) FILETIME=[671A6360:01C7453E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "West, Mark" , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , Carl Knutsson , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org pelle@cdt.luth.se skrev: > Magnus, Kristofer, > > I totally disagree with changing the current wording. > > I totally agree with Carsten and Mark opinion previously expressed on this > thread, which arguments were very much in-line with my initial answer. > > I think that we should not specify anything in our profiles that would lead to > a compressor discarding a packet. Once again, it is not the responsability of > header compression to police other protocol/stack behavior. > > Wrt to the "transparency issue", header compression has always used the > assumption that erroneous IP checksums would never reach the compressor, and > Carsten in addition pointed out that this has been discussed and agreed long > time ago. Furthermore, as Carsten pointed out, IPv6 folks did not even include > a cheksum in the IPv6 header for a reason. > > Personally, I would remove the sentence entirely, and I think that would follow > all other other RoHC specs very nicely. > > Regards, > > ///Ghyslain > If it always has been an assumption that erroneous headers will not reach the compressor, can you please point out where in the current set of document that assumption is documented? In case it is not documented can we please document it. I am fine with removing the normative sentence as long as the assumption is correctly documented and the possible effects of not fulfilling this assumption. From my perspective I think it is important that you document the cases when transparency is only fulfilled as certain assumptions are meet. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 09:05:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG5f-0001wI-VE; Wed, 31 Jan 2007 09:05:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG5d-0001w2-Pg for rohc@ietf.org; Wed, 31 Jan 2007 09:05:33 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCG5X-0000hv-26 for rohc@ietf.org; Wed, 31 Jan 2007 09:05:33 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 835CC2090E; Wed, 31 Jan 2007 15:05:24 +0100 (CET) X-AuditID: c1b4fb3c-b07c9bb0000007de-bf-45c0a2248349 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6483D208DC; Wed, 31 Jan 2007 15:05:24 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:05:24 +0100 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: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 15:05:22 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC0504556156@esealmw109.eemea.ericsson.se> In-Reply-To: <45C09E08.7000502@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Thread-Index: AcdFPmdbidqn19EWQ4GnnheDxAd+wgAAIexg From: "Ghyslain Pelletier \(LU/EAB\)" To: "Magnus Westerlund \(KI/EAB\)" , X-OriginalArrivalTime: 31 Jan 2007 14:05:24.0123 (UTC) FILETIME=[DA036EB0:01C74540] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Carl Knutsson , "West, Mark" , Carsten Bormann , rohc@ietf.org, Lars-Erik Jonsson X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hej Magnus, This could be an acceptable alternative from my perspective, to formulate it as to what it is an assumption of the compression profile, somewhere in section 3. However, I have always been under the impression that that was implicit from the specifications of IPv4 no matter what. Anyway, I will get back with a text proposal shortly. ///Ghyslain Magnus Westerlund wrote: > pelle@cdt.luth.se skrev: >> Magnus, Kristofer, >>=20 >> I totally disagree with changing the current wording. >>=20 >> I totally agree with Carsten and Mark opinion previously expressed >> on this thread, which arguments were very much in-line with my >> initial answer.=20 >>=20 >> I think that we should not specify anything in our profiles that >> would lead to a compressor discarding a packet. Once again, it is >> not the responsability of header compression to police other >> protocol/stack behavior.=20 >>=20 >> Wrt to the "transparency issue", header compression has always used >> the assumption that erroneous IP checksums would never reach the >> compressor, and Carsten in addition pointed out that this has been >> discussed and agreed long time ago. Furthermore, as Carsten pointed >> out, IPv6 folks did not even include a cheksum in the IPv6 header >> for a reason.=20 >>=20 >> Personally, I would remove the sentence entirely, and I think that >> would follow all other other RoHC specs very nicely. >>=20 >> Regards, >>=20 >> ///Ghyslain >>=20 >=20 > If it always has been an assumption that erroneous headers will not > reach the compressor, can you please point out where in the current > set of document that assumption is documented? >=20 > In case it is not documented can we please document it. I am fine with > removing the normative sentence as long as the assumption is correctly > documented and the possible effects of not fulfilling this assumption. >=20 > From my perspective I think it is important that you document the > cases when transparency is only fulfilled as certain assumptions are > meet.=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 09:07:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG7q-00039j-9n; Wed, 31 Jan 2007 09:07:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG7p-00039d-4X for rohc@ietf.org; Wed, 31 Jan 2007 09:07:49 -0500 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCG7n-0005xA-LS for rohc@ietf.org; Wed, 31 Jan 2007 09:07:49 -0500 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id l0VE2dDc005184; Wed, 31 Jan 2007 15:02:39 +0100 (CET) In-Reply-To: <45C09E08.7000502@ericsson.com> References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com> <45C05B73.5040506@ericsson.com> <1170250664.45c09ba8e3362@www.sm.luth.se> <45C09E08.7000502@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 15:02:37 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Carl Knutsson , rohc@ietf.org, Lars-Erik Jonsson , "Ghyslain Pelletier \(LU/EAB\)" , "West, Mark" , Carsten Bormann X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Jan 31 2007, at 14:47, Magnus Westerlund wrote: > you please point out where in the current set of document that > assumption is documented? RFC 3095 says: Header Checksum The header checksum protects individual hops from processing a corrupted header. When almost all IP header information is compressed away, there is no point in having this additional checksum; instead it can be regenerated at the decompressor side. The field is therefore classified as INFERRED. Well, it's rather implicit. This paragraph only makes sense if you read the first sentence as "the previous hop will already have discarded a packet with a bad checksum"; the rest then talks about the lack of need for protecting the next hop (the one with the compressed header). But I think I agree with Magnus' stipulation; this all has been rather implicit in the documents (while it was more explicit in our minds). Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Jan 31 09:41:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGdv-0003Dn-Am; Wed, 31 Jan 2007 09:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGdt-0003Di-TH for rohc@ietf.org; Wed, 31 Jan 2007 09:40:57 -0500 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGds-0003DS-GU for rohc@ietf.org; Wed, 31 Jan 2007 09:40:57 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id B457537F15; Wed, 31 Jan 2007 15:40:28 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9DD6737EA4; Wed, 31 Jan 2007 15:40:28 +0100 (CET) Received: from jymden3 (81-235-130-241-no14.tbcn.telia.com [81.235.130.241]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with SMTP id 859E637E58; Wed, 31 Jan 2007 15:40:52 +0100 (CET) Message-ID: <00a101c74545$d4d61b90$6500a8c0@jymden3> From: "Lars-Erik Jonsson" To: "Carsten Bormann" , "Magnus Westerlund" References: <45C04D90.7000603@ericsson.com> <45C056DA.9010507@effnet.com><45C05B73.5040506@ericsson.com><1170250664.45c09ba8e3362@www.sm.luth.se><45C09E08.7000502@ericsson.com> Subject: Re: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15 Date: Wed, 31 Jan 2007 15:41:00 +0100 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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Carl Knutsson , "West, Mark" , Carsten Bormann , rohc@ietf.org, "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > On Jan 31 2007, at 14:47, Magnus Westerlund wrote: > >> you please point out where in the current set of document that >> assumption is documented? > > RFC 3095 says: > > Header Checksum > > The header checksum protects individual hops from processing a > corrupted header. When almost all IP header information is > compressed away, there is no point in having this additional > checksum; instead it can be regenerated at the decompressor side. > The field is therefore classified as INFERRED. Which is based on what RFC 1144 says, i.e.: "But then the header checksum (bytes 10 and 11), which protects individual hops from processing a corrupted IP header, is essentially the only part of the IP header being sent. It seems rather silly to protect the transmission of information that isn't being transmitted. So, the receiver can check the header checksum when the header is actually sent (i.e., in an uncompressed datagram) but, for compressed datagrams, regenerate it locally at the same time the rest of the IP header is being regenerated." In both cases it is implictly assumed that the IP checksum is only about THIS hop anyway, so its value at the compression point is irrelevant if the checksum is excluded by the compression scheme. There is no transparency issue with the IP checksum field, as it is a per-hop field. I'll wait for Ghyslain's concrete text proposal before I say anything more. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc