From mailnull@www1.ietf.org Mon Feb 3 07:19:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05426 for ; Mon, 3 Feb 2003 07:19:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13CObn16850 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 07:24:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CObJ16847 for ; Mon, 3 Feb 2003 07:24:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05336 for ; Mon, 3 Feb 2003 07:19:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13COLJ16829; Mon, 3 Feb 2003 07:24:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13CLuJ16740 for ; Mon, 3 Feb 2003 07:21:56 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05086 for ; Mon, 3 Feb 2003 07:16:27 -0500 (EST) Received: (qmail 12449 invoked by uid 510); 3 Feb 2003 12:25:34 -0000 Date: 3 Feb 2003 12:25:34 -0000 Message-ID: <20030203122534.12448.qmail@webmail10.rediffmail.com> Received: from unknown (164.164.94.102) by rediffmail.com via HTTP; 03 feb 2003 12:25:34 -0000 MIME-Version: 1.0 From: "vishal verma" Reply-To: "vishal verma" To: rohc@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [rohc] SigComp related query Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi , I have following questions regarding SigComp 1. How is SigComp message differs from normal SIP text based message? 2. When using static dictionary based compression ,how will text content and a keyword offset of dictionary be differentiated ? regards, vishal _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 08:30:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07445 for ; Mon, 3 Feb 2003 08:30:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13DZZE21410 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 08:35:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13DZZJ21407 for ; Mon, 3 Feb 2003 08:35:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07427 for ; Mon, 3 Feb 2003 08:30:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13DZJJ21393; Mon, 3 Feb 2003 08:35:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13DY9J21294 for ; Mon, 3 Feb 2003 08:34:09 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07387 for ; Mon, 3 Feb 2003 08:28:39 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h13DWEAv021111 for ; Mon, 3 Feb 2003 14:32:14 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 3 Feb 2003 14:32:14 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Mon, 3 Feb 2003 14:30:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [rohc] FW: I-D ACTION:draft-pelletier-rohc-udplite-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, Last year in Minneapolis, an individual draft for a UDP-Lite profile was discussed, and we also agreed to make it a WG draft. However, the work got delayed for various reasons, and the author also wanted to make significant changes to the document. Therefore, we decided the updated draft should stay as an individual draft in this version, although the intention is to soon make it a WG document, and the work should hereafter continue on the list. Please express your opinions about this draft, especially opinions about using this document as the starting point for the ROHC UDP-Lite profile development. Thanks! /Lars-Erik -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: den 3 februari 2003 12:44 Subject: I-D ACTION:draft-pelletier-rohc-udplite-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RObust Header Compression (ROHC):Profiles for UDP Lite Author(s) : G. Pelletier Filename : draft-pelletier-rohc-udplite-01.txt Pages : 19 Date : 2003-1-31 This document defines ROHC (Robust Header Compression) profiles for compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. These profiles are defined based on their differences with the profiles specified in [RFC-3095] for UDP [RFC-768]. Although both transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because it does not share protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field and as a consequence cannot always be inferred anymore. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pelletier-rohc-udplite-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pelletier-rohc-udplite-01.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-pelletier-rohc-udplite-01.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. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 11:14:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11780 for ; Mon, 3 Feb 2003 11:14:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13GJds00942 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 11:19:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GJcJ00939 for ; Mon, 3 Feb 2003 11:19:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11771 for ; Mon, 3 Feb 2003 11:14:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GJIJ00929; Mon, 3 Feb 2003 11:19:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GInJ00904 for ; Mon, 3 Feb 2003 11:18:49 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11757 for ; Mon, 3 Feb 2003 11:13:14 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 16:16:50 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A6@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Ghyslain.Pelletier@epl.ericsson.se'" Cc: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: RE: [rohc] FW: I-D ACTION:draft-pelletier-rohc-udplite-01.txt Date: Mon, 3 Feb 2003 16:16:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, The updated draft is quite a bit longer than the old one - a list of what's changed since the previous version would be much appreciated! One point I noticed is that the new draft supports the compression of multiple IP headers. Is this something that's particularly useful for UDP-Lite (as compared with vanilla UDP), or just a feature that would be good to have in general? Thanks, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Monday, February 03, 2003 1:30 PM > To: Rohc (E-mail) > Subject: [rohc] FW: I-D ACTION:draft-pelletier-rohc-udplite-01.txt > > > ROHCers, > > Last year in Minneapolis, an individual draft for a UDP-Lite profile > was discussed, and we also agreed to make it a WG draft. However, the > work got delayed for various reasons, and the author also wanted to > make significant changes to the document. Therefore, we decided the > updated draft should stay as an individual draft in this version, > although the intention is to soon make it a WG document, and the work > should hereafter continue on the list. > > Please express your opinions about this draft, especially opinions > about using this document as the starting point for the ROHC UDP-Lite > profile development. > > Thanks! > /Lars-Erik > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: den 3 februari 2003 12:44 > Subject: I-D ACTION:draft-pelletier-rohc-udplite-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : RObust Header Compression > (ROHC):Profiles for UDP Lite > Author(s) : G. Pelletier > Filename : draft-pelletier-rohc-udplite-01.txt > Pages : 19 > Date : 2003-1-31 > > This document defines ROHC (Robust Header Compression) profiles for > compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, > User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. > These profiles are defined based on their differences with the > profiles specified in [RFC-3095] for UDP [RFC-768]. > Although both transport protocols are very similar, ROHC profiles > must be defined separately for robust compression of UDP-Lite headers > because it does not share protocol identifier with UDP. Also, the > UDP-Lite Checksum Coverage field does not share the semantics of the > corresponding UDP Length field and as a consequence cannot always be > inferred anymore. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pelletier-rohc-udplite-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pelletier-rohc-udplite-01.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-pelletier-rohc-udplite-01.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. _______________________________________________ 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 mailnull@www1.ietf.org Mon Feb 3 11:28:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12279 for ; Mon, 3 Feb 2003 11:28:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13GXPE01766 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 11:33:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GXPJ01763 for ; Mon, 3 Feb 2003 11:33:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12254 for ; Mon, 3 Feb 2003 11:27:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GX9J01740; Mon, 3 Feb 2003 11:33:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GW1J01685 for ; Mon, 3 Feb 2003 11:32:01 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12206 for ; Mon, 3 Feb 2003 11:26:26 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h13GU2KV008005; Mon, 3 Feb 2003 17:30:02 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MVHR20; Mon, 3 Feb 2003 17:30:02 +0100 Received: by lms001.lu.erisoft.se id RAA12310; Mon, 3 Feb 2003 17:30:04 +0100 (MET) Message-ID: <3E3E998F.DDDC4D77@epl.ericsson.se> Date: Mon, 03 Feb 2003 17:32:15 +0100 X-Sybari-Trust: 14885a42 9ffcebbb 908facde 00000138 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: Re: [rohc] FW: I-D ACTION:draft-pelletier-rohc-udplite-01.txt References: <76C92FBBFB58D411AE760090271ED41804A0F1A6@rsys002a.roke.co.uk> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by lms001.lu.erisoft.se id RAA12310 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13GW1J01686 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Richard, > The updated draft is quite a bit longer than the old one - a list of > what's changed since the previous version would be much appreciated! Most of the content of the draft has changed as the assumptions made regarding the behavior of UDP-Lite flows have evolved, leading to a totally different approach taken for compressing the headers. Also, the previous version was suggesting an approach and was written with the intent to "probe" the group's opinion regarding directions for the work, while this draft is written with the intent to be as much as possible a complete specification of a ROHC profile for UDP-Lite. With this in mind, I suggest that the draft be read as a totally new document, as not much from version 00 is left in version 01. > One point I noticed is that the new draft supports the compression > of multiple IP headers. Is this something that's particularly useful > for UDP-Lite (as compared with vanilla UDP), or just a feature that > would be good to have in general? Something good to have in general. Regards, /Ghyslain Ghyslain Pelletier Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Luleå, Sweden _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 12:19:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13888 for ; Mon, 3 Feb 2003 12:19:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13HOu806403 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 12:24:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HOtJ06400 for ; Mon, 3 Feb 2003 12:24:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13871 for ; Mon, 3 Feb 2003 12:19:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HOZJ06363; Mon, 3 Feb 2003 12:24:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13HLiJ06183 for ; Mon, 3 Feb 2003 12:21:44 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13723 for ; Mon, 3 Feb 2003 12:16:09 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 17:19:43 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A7@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Ghyslain Pelletier'" Cc: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Subject: RE: [rohc] FW: I-D ACTION:draft-pelletier-rohc-udplite-01.txt Date: Mon, 3 Feb 2003 17:19:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > With this in mind, I suggest that the draft be read as a totally new > document, as not much from version 00 is left in version 01. Ok, I guess I'll have to read the whole draft ;-) > > One point I noticed is that the new draft supports the compression > > of multiple IP headers. Is this something that's particularly useful > > for UDP-Lite (as compared with vanilla UDP), or just a feature that > > would be good to have in general? > > Something good to have in general. In this case, would it be worth thinking about some other features that are good to have in general? For the ROHC-TCP work we've developed a number of enhancements (e.g. context replication) that are equally applicable to other protocols such as UDP-Lite. If we're taking the opportunity to improve the profile relative to UDP then these techniques might be worth considering. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 13:39:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16833 for ; Mon, 3 Feb 2003 13:39:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Iijr14407 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 13:44:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IijJ14404 for ; Mon, 3 Feb 2003 13:44:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16799 for ; Mon, 3 Feb 2003 13:39:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IiWJ14381; Mon, 3 Feb 2003 13:44:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13IhdJ14214 for ; Mon, 3 Feb 2003 13:43:39 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16761 for ; Mon, 3 Feb 2003 13:38:03 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h13IiEm05312 for ; Mon, 3 Feb 2003 20:44:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Feb 2003 20:41:37 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 20:41:36 +0200 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 12:41:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Subject: RE: [rohc] RE: DAP issues Date: Mon, 3 Feb 2003 12:41:24 -0600 Message-ID: Thread-Topic: [rohc] RE: DAP issues Thread-Index: AcLJPwV6ZD79Yvi/Q4CdjefLPVJnJACcr4RA To: , , X-OriginalArrivalTime: 03 Feb 2003 18:41:25.0364 (UTC) FILETIME=[DB00C340:01C2CBB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13IheJ14215 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit [Abbie wrote:] > I think Zhigang clarified it in his mail on Tues, but we > could add the following > line to section 2, paragraph 2. > > "The entire DAP message (message-header + CRLF + message-body) > is returned. This allows the sender to compare what it sent > with what the > receiver decompressed." [Zacco wrote:] > >> This is the message header I would not like to have in the > returned message. The uncompressed message is just enough. Do > we need the header information for some special purpose? If > yes, I promise I will not resist. Zacco, Sorry, I couldn't follow you. Do you mean the returned uncompressed message should not include the message-header? But then how can the sender be sure that the *entire* DAP message it sent has been correctly decompressed by the remote endpoint? Note, what SigComp processes is the DAP message, not just the DAP message-body. I thought this was obvious, but I will add the clarification as Abbie suggested above. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 13:58:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17340 for ; Mon, 3 Feb 2003 13:58:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13J3ND15667 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 14:03:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13J3NJ15664 for ; Mon, 3 Feb 2003 14:03:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17318 for ; Mon, 3 Feb 2003 13:57:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13J37J15651; Mon, 3 Feb 2003 14:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13J2FJ15624 for ; Mon, 3 Feb 2003 14:02:15 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17296 for ; Mon, 3 Feb 2003 13:56:38 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h13J0Er23595 for ; Mon, 3 Feb 2003 13:00:14 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Feb 2003 13:00:13 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 12:58:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Subject: RE: [rohc] RE: DAP issues Date: Mon, 3 Feb 2003 12:58:49 -0600 Message-ID: Thread-Topic: [rohc] RE: DAP issues Thread-Index: AcLJOiU/Cub9c3B1TXO1WTlnXYK0QwCeaa1g To: , , X-OriginalArrivalTime: 03 Feb 2003 18:58:50.0120 (UTC) FILETIME=[49B9E080:01C2CBB6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13J2FJ15625 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Either (as it states in DAP 1b) the receiver can set the > need-response field to TRUE and both sender and receiver control the flow, allowing the > possibility of infinite sending (fixed by one end setting the field to FALSE) > or > (as I suggested in my last mail) the sender is in control of > the message flow, the receiver must NOT set the flag to TRUE. > > One thing to take into account is whether either approach > will enable/prevent specific test patterns. The latter seems simpler to me, and I don't > think it prevents anything. What does anyone else think? Abbie, I used the former in the document for two reasons: 1) It allows arbitrary message exchange pattern, e.g., 3-way message exchange: m1 from A to B, m2 from B to A, then m3 from A to B. B can control in this case. 2) Again, I don't think the dead loop is an issue. I mentioned it in the document just as a reminder. The bottom line is the common sense in implementation. If that is not there, no protocol is bullet proof. (No protocol can prevent a bad or incorrect implementation anyway.) In this case, the DAP clearly provides ways to avoid dead loop (I'll make it more redundantly clear). One should not blame DAP for a bad/incorrect implementation. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 3 16:06:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21837 for ; Mon, 3 Feb 2003 16:06:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13LBd526108 for rohc-archive@odin.ietf.org; Mon, 3 Feb 2003 16:11:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LBdJ26105 for ; Mon, 3 Feb 2003 16:11:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21813 for ; Mon, 3 Feb 2003 16:05:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LBOJ26097; Mon, 3 Feb 2003 16:11:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13LA9J26066 for ; Mon, 3 Feb 2003 16:10:09 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21771 for ; Mon, 3 Feb 2003 16:04:28 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h13L8FE11774 for ; Mon, 3 Feb 2003 15:08:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 3 Feb 2003 15:08:04 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Feb 2003 13:08:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2CBC8.571DFB0E" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Mon, 3 Feb 2003 15:08:03 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLF97KJfLDy7a+wS+GaPCuQs2tQTQAI2EpQABEz58ABWVbFsA== To: X-OriginalArrivalTime: 03 Feb 2003 21:08:04.0099 (UTC) FILETIME=[57752D30:01C2CBC8] Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CBC8.571DFB0E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here is version 1c. Based on comments from Zacco and Abbie, I added=20 clarifications on returned uncompressed DAP messages and "need-feedback" header field.=20 As planned, I would like to freeze this as the DAP version 1 for now. At least it's good enough for the first SigComp interop.=20 (Of course, any questions related to the understanding of the document are still welcome. I've been trying to be concise, but may not have covered every fine details ...) Thanks for Abbie, Adam and Zacco for their valuable comments. BR, Zhigang ------_=_NextPart_001_01C2CBC8.571DFB0E Content-Type: text/plain; name="dap-1c.txt" Content-Description: dap-1c.txt Content-Disposition: attachment; filename="dap-1c.txt" Content-Transfer-Encoding: base64 QSBEdW1teSBBcHBsaWNhdGlvbiBQcm90b2NvbCAoREFQKQ0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NDQoNDQoxLiBJbnRyb2R1Y3Rpb24NDQoNDQpUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBzaW1wbGUgZHVtbXkgYXBwbGljYXRpb24gcHJvdG9jb2wgKERBUCkgdGhhdA0NCmNh biBiZSB1c2VkIGZvciBTaWdDb21wIGludGVyb3BlcmFiaWxpdHkgdGVzdC4gVGhpcyBpcyBoYW5k eSBmb3INDQpTaWdDb21wIGltcGxlbWVudGF0aW9ucyB0aGF0IGFyZSBub3QgaW50ZWdyYXRlZCB3 aXRoIFNJUCBzdGFjay4gSXQgYWxzbw0NCnByb3ZpZGVzIHNvbWUgZmVhdHVyZXMgdGhhdCBmYWNp bGl0YXRlIHRoZSB0ZXN0cyBvZiBTaWdDb21wIGludGVybmFsDQ0Kb3BlcmF0aW9ucy4NDQoNDQpU aGUgbWVzc2FnZSBmb3JtYXQgaXMgcXVpdGUgc2ltcGxlLiBFYWNoIG1lc3NhZ2UgY29uc2lzdHMg b2YgYSA4LWxpbmUNDQptZXNzYWdlLWhlYWRlciwgYW4gZW1wdHkgbGluZSwgYW5kIGFuIG9wdGlv bmFsIG1lc3NhZ2UtYm9keS4gWW91IGNhbg0NCnNlZSB0aGUgc3R5bGUgcmVzZW1ibGVzIHRoYXQg b2YgU0lQIGFuZCBIVFRQLg0NCg0NClRoZSBleGFjdCBtZXNzYWdlIGZvcm1hdCBpcyBnaXZlbiBs YXRlciBpbiBhdWdtZW50ZWQgQmFja3VzLU5hdXIgRm9ybSANDQooQUJORikgKHNlZSBSRkMgMjIz NCkuIEhlcmUgYXJlIGEgZmV3IG5vdGVzOg0NCg0NCi0gRWFjaCBsaW5lIG9mIG1lc3NhZ2UtaGVh ZGVyIG11c3QgYmUgdGVybWluYXRlZCB3aXRoIENSIExGLg0NCi0gVGhlIGVtcHR5IGxpbmUgbXVz dCBiZSBwcmVzZW50IGV2ZW4gaWYgdGhlIG1lc3NhZ2UtYm9keSBpcyBub3QuDQ0KLSBCb2R5LWxl bmd0aCBpcyB0aGUgbGVuZ3RoIG9mIHRoZSBtZXNzYWdlLWJvZHksIGV4Y2x1ZGluZyB0aGUgQ1JM Rg0NCndoaWNoIHNlcGFyYXRlcyB0aGUgbWVzc2FnZS1ib2R5IGZyb20gdGhlIG1lc3NhZ2UtaGVh ZGVyLg0NCi0gQWxsIHN0cmluZ3MgaW4gbWVzc2FnZS1oZWFkZXIgYXJlIGNhc2UtaW5zZW5zaXRp dmUuDQ0KLSBGb3IgaW1wbGVtZW50YXRpb24gYWNjb3JkaW5nIHRvIHRoaXMgZG9jdW1lbnQsIHRo ZSBEQVAtdmVyc2lvbiANDQptdXN0IGJlIHNldCB0byAxLiANDQoNDQoNDQoyLiBQcm9jZXNzaW5n IGEgREFQIG1lc3NhZ2U6DQ0KDQ0KLSBBIG1lc3NhZ2Ugd2l0aCBpbnZhbGlkIGZvcm1hdCB3aWxs IGJlIGRpc2NhcmRlZCBieSBhIERBUCByZWNlaXZlcg0NCg0NCi0gRm9yIHRlc3RpbmcgcHVycG9z ZSwgYSBtZXNzYWdlIHdpdGggdmFsaWQgZm9ybWF0IHdpbGwgYmUgcmV0dXJuZWQgdG8NDQp0aGUg b3JpZ2luYWwgc2VuZGVyIChJUCBhZGRyZXNzLCBwb3J0IG51bWJlcikgaW4gY2xlYXIgdGV4dCwg aS5lLiwgDQ0Kd2l0aG91dCBjb21wcmVzc2lvbi4gVGhpcyBpcyB0aGUgY2FzZSBldmVuIGlmIHRo ZSBzZW5kZXIgcmVxdWVzdHMgdGhlDQ0KcmVjZWl2ZXIgdG8gcmVqZWN0IHRoZSBtZXNzYWdlLiBO b3RlIHRoYXQgdGhlIGVudGlyZSBEQVAgbWVzc2FnZQ0NCihtZXNzYWdlLWhlYWRlciArIENSTEYg KyBtZXNzYWdlLWJvZHkpIGlzIHJldHVybmVkLiBUaGlzIGFsbG93cyB0aGUNDQpzZW5kZXIgdG8g Y29tcGFyZSB3aGF0IGl0IHNlbnQgd2l0aCB3aGF0IHRoZSByZWNlaXZlciBkZWNvbXByZXNzZWQu DQ0KDQ0KLSBFbmRwb2ludC1JRCBpcyB0aGUgZ2xvYmFsIGlkZW50aWZpZXIgb2YgdGhlIHNlbmRp bmcgZW5kcG9pbnQuIEl0IGNhbg0NCmJlIHVzZWQgdG8gdGVzdCB0aGUgY2FzZSB3aGVyZSBtdWx0 aXBsZSBTaWdDb21wIGVuZHBvaW50cyBjb21tdW5pY2F0ZQ0NCndpdGggdGhlIHNhbWUgcmVtb3Rl IFNpZ0NvbXAgZW5kcG9pbnQuIEZvciBzaW1wbGljaXR5LCBJUHY0IGFkZHJlc3MgaXMNDQp1c2Vk IGZvciB0aGlzIHB1cnBvc2UuIA0NCg0NCi0gQ29tcGFydG1lbnQtSUQgaXMgdGhlIGlkZW50aWZp ZXIgb2YgdGhlICpjb21wcmVzc29yKiBjb21wYXJ0bWVudA0NCnRoYXQgdGhlICpzZW5kaW5nKiBl bmRwb2ludCB1c2VkIHRvIGNvbXByZXNzIHRoaXMgbWVzc2FnZS4gSXQgaXMNDQphc3NpZ25lZCBi eSB0aGUgc2VuZGVyIGFuZCB0aGVyZWZvcmUgb25seSB1bmlxdWUgcGVyIHNlbmRpbmcgZW5kcG9p bnQuDQ0KSS5lLiwgREFQIG1lc3NhZ2VzIHNlbnQgYnkgZGlmZmVyZW50IGVuZHBvaW50cyBtYXkg Y2Fycnkgc2FtZQ0NCmNvbXBhcnRtZW50LUlELiBUaGVyZWZvcmUsIHRoZSByZWNlaXZlciBzaG91 bGQgdXNlIHRoZSAoZW5kcG9pbnQtSUQsDQ0KY29tcGFydG1lbnQtSUQpIHBhaXIgY2FycmllZCBp biBhIG1lc3NhZ2UgdG8gZGV0ZXJtaW5lIHRoZSBkZWNvbXByZXNzb3INDQpjb21wYXJ0bWVudCBp ZGVudGlmaWVyIGZvciB0aGF0IG1lc3NhZ2UuIFRoZSBleGFjdCBsb2NhbCByZXByZXNlbnRhdGlv bg0NCm9mIHRoZSBkZXJpdmVkIGNvbXBhcnRtZW50IGlkZW50aWZpZXIgaXMgYW4gaW1wbGVtZW50 YXRpb24gY2hvaWNlLg0NCg0NCi0gVG8gdGVzdCBTaWdDb21wIGZlZWRiYWNrIChSRkMgMzMyMCwg c2VjdGlvbiAzLjEpLCBwZWVyIGNvbXBhcnRtZW50cyANDQpiZXR3ZWVuIHR3byBlbmRwb2ludHMg YXJlIGRlZmluZWQgaW4gREFQIGFzIHRob3NlIHdpdGggdGhlIHNhbWUNDQpjb21wYXJ0bWVudC1J RC4gRm9yIGV4YW1wbGUsIChlbmRwb2ludC1BLCAxKSBhbmQgKGVuZHBvaW50LUIsIDEpIGFyZQ0N CnBlZXIgY29tcGFydG1lbnRzLiBUaGF0IG1lYW5zLCBTaWdDb21wIGZlZWRiYWNrIGZvciBhIERB UCBtZXNzYWdlIHNlbnQNDQpmcm9tIGNvbXBhcnRtZW50IDEgb2YgZW5kcG9pbnQtQSB0byBlbmRw b2ludC1CIG11c3QgYmUgcGlnZ3liYWNrZWQgb24gYQ0NCkRBUCBtZXNzYWdlIHNlbnQgZnJvbSBj b21wYXJ0bWVudCAxIG9mIGVuZHBvaW50LUIgdG8gZW5kcG9pbnQtQS4NDQoNDQotIEEgREFQIHJl Y2VpdmVyIHdpbGwgZm9sbG93IHRoZSBpbnN0cnVjdGlvbiBjYXJyaWVkIGluIGhlYWRlciBsaW5l LTUNDQp0byBlaXRoZXIgYWNjZXB0IG9yIHJlamVjdCBhIERBUCBtZXNzYWdlLiBOb3RlOiBsaW5l LTYgYW5kIGxpbmUtNyB3aWxsDQ0KYmUgaWdub3JlZCBpZiB0aGUgbWVzc2FnZSBpcyByZWplY3Rl ZC4NDQoNDQotIEEgREFQIHJlY2VpdmVyIHdpbGwgZm9sbG93IHRoZSBpbnN0cnVjdGlvbiBpbiBs aW5lLTYgdG8gY3JlYXRlIG9yDQ0KY2xvc2UgdGhlIGRlY29tcHJlc3NvciBjb21wYXJ0bWVudCB0 aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVjZWl2ZWQNDQpEQVAgbWVzc2FnZSAoc2VlIGFi b3ZlKS4gDQ0KDQ0KLSBJZiB0aGUgaGVhZGVyIGxpbmUtNyBvZiBhIHJlY2VpdmVkIERBUCBtZXNz YWdlIGNhcnJpZXMgIlRSVUUiLCB0aGUNDQpyZWNlaXZlciB3aWxsIHNlbmQgYmFjayBhIHJlc3Bv bnNlIG1lc3NhZ2UgdG8gdGhlIHNlbmRlci4gVGhpcyBhbGxvd3MNDQp0aGUgdGVzdCBvZiBTaWdD b21wIGZlZWRiYWNrLiBBcyBtZW50aW9uZWQgYWJvdmUsIHRoZSByZXNwb25zZSBtZXNzYWdlIA0N Cm11c3QgYmUgY29tcHJlc3NlZCBieSwgYW5kIHNlbnQgZnJvbSwgdGhlIGxvY2FsIGNvbXByZXNz b3IgY29tcGFydG1lbnQNDQp0aGF0IGlzIHBlZXIgb2YgdGhlIHJlbW90ZSBjb21wcmVzc29yIGNv bXBhcnRtZW50LiBPdGhlciB0aGFuIHRoaXMgDQ0KY29uc3RyYWludCwgdGhlIHJlc3BvbnNlIG1l c3NhZ2UgaXMganVzdCBhIHJlZ3VsYXIgREFQIG1lc3NhZ2UgdGhhdA0NCmNhbiBjYXJyeSBhcmJp dHJhcnkgbWVzc2FnZS1oZWFkZXIgYW5kIG1lc3NhZ2UtYm9keS4gRm9yIGV4YW1wbGUsIHRoZQ0N CiJuZWVkLXJlc3BvbnNlIiBmaWVsZCBvZiB0aGUgcmVzcG9uc2UgY2FuIGFsc28gYmUgc2V0IHRv IFRSVUUsIHdoaWNoDQ0Kd2lsbCB0cmlnZ2VyIGEgcmVzcG9uc2UgdG8gcmVzcG9uc2UsIGFuZCBz byBvbi4gTm90ZSB0aGF0IHNpbmNlIGVpdGhlcg0NCmVuZHBvaW50IGhhcyBjb250cm9sIG92ZXIg dGhlICJuZWVkLXJlc3BvbnNlIiBmaWVsZCBvZiBpdHMgb3duDQ0KbWVzc2FnZXMsIHRoaXMgZG9l cyBub3QgbGVhZCB0byBhIGRlYWQgbG9vcC4gQSBzZW5zaWJsZSBpbXBsZW1lbnRhdGlvbg0NCm9m IGEgREFQIHNlbmRlciBtdXN0IG5vdCBibGluZGx5IHNldCB0aGlzIGZpZWxkIHRvIFRSVUUgdW5s ZXNzIGENDQpyZXNwb25zZSBpcyBkZXNpcmVkLiBGb3IgdGVzdGluZywgdGhlIG1lc3NhZ2UtYm9k eSBvZiBhIHJlc3BvbnNlIG1heQ0NCmNvbnRhaW4gdGhlIG1lc3NhZ2UtaGVhZGVyIG9mIHRoZSBv cmlnaW5hbCBtZXNzYWdlIHRoYXQgdHJpZ2dlcmVkDQ0KdGhlIHJlc3BvbnNlLg0NCg0NCi0gTWVz c2FnZS1zZXEgY2FuIGJlIHVzZWQgYnkgYSBEQVAgc2VuZGVyIHRvIHRyYWNrIGVhY2ggbWVzc2Fn ZSBpdA0NCnNlbmRzLCBlLmcuLCBpbiBjYXNlIG9mIGxvc3Nlcy4gTWVzc2FnZSBsb3NzIGNhbiBo YXBwZW4gZWl0aGVyIG9uIHRoZQ0NCnBhdGggb3IgYXQgdGhlIHJlY2VpdmluZyBlbmRwb2ludCAo aS5lLiBkdWUgdG8gZGVjb21wcmVzc2lvbiBmYWlsdXJlKS4NDQpUaGUgYXNzaWdubWVudCBvZiBt ZXNzYWdlLXNlcSBpcyB1cCB0byB0aGUgc2VuZGVyLiBGb3IgZXhhbXBsZSwgaXQNDQpjb3VsZCBi ZSBlaXRoZXIgYXNzaWduZWQgcGVyIGNvbXBhcnRtZW50IG9yIHBlciBlbmRwb2ludC4gVGhpcyBo YXMgbm8NDQppbXBhY3Qgb24gdGhlIHJlY2VpdmluZyBzaWRlLg0NCg0NCg0NCjMuIERBUCBtZXNz YWdlIGZvcm1hdCBpbiBBQk5GDQ0KDQ0KKE5vdGU6IHNlZSBSRkMgMjIzNCBmb3IgYmFzaWMgcnVs ZXMuKQ0NCg0NCkRBUC1tZXNzYWdlID0gbWVzc2FnZS1oZWFkZXINDQogICAgICAgICAgICAgIENS TEYNDQogICAgICAgICAgICAgIFsgbWVzc2FnZS1ib2R5IF0NDQoNDQptZXNzYWdlLWJvZHkgPSAq T0NURVQNDQoNDQptZXNzYWdlLWhlYWRlciA9IGxpbmUtMSBsaW5lLTIgbGluZS0zIGxpbmUtNCBs aW5lLTUgbGluZS02IGxpbmUtNyBsaW5lLTgNDQoNDQpsaW5lLTEgPSAiREFQLXZlcnNpb24iICI6 IiAxKkRJR0lUIENSTEYNDQpsaW5lLTIgPSAiZW5kcG9pbnQtSUQiICI6IiBJUHY0YWRkcmVzcyBD UkxGDQ0KbGluZS0zID0gImNvbXBhcnRtZW50LUlEIiAiOiIgMSpESUdJVCBDUkxGDQ0KbGluZS00 ID0gIm1lc3NhZ2Utc2VxIiAiOiIgMSpESUdJVCBDUkxGDQ0KbGluZS01ID0gIm1lc3NhZ2UtYXV0 aCIgIjoiICggIkFDQ0VQVCIgLyAiUkVKRUNUIiApIENSTEYNDQpsaW5lLTYgPSAiY29tcGFydG1l bnQtb3AiICI6IiAoICJDUkVBVEUiIC8gIkNMT1NFIiAvICJOT05FIiApIENSTEYNDQpsaW5lLTcg PSAibmVlZC1yZXNwb25zZSIgIjoiICggIlRSVUUiIC8gIkZBTFNFIiApDQ0KbGluZS04ID0gImJv ZHktbGVuZ3RoIiAiOiIgMSpESUdJVCBDUkxGDQ0KDQ0KSVB2NGFkZHJlc3MgPSAxKjNESUdJVCAi LiIgMSozRElHSVQgIi4iIDEqM0RJR0lUICIuIiAxKjNESUdJVA0NCg0NCg0NCjQuIEFuIGV4YW1w bGUgb2YgYSBEQVAgbWVzc2FnZQ0NCg0NCkRBUC12ZXJzaW9uOiAxDQ0KZW5kcG9pbnQtSUQ6IDEy My40NS42Ny44OQ0NCmNvbXBhcnRtZW50LUlEOiAyDQ0KbWVzc2FnZS1zZXE6IDANDQptZXNzYWdl LWF1dGg6IEFDQ0VQVA0NCmNvbXBhcnRtZW50LW9wOiBDUkVBVEUNDQpuZWVkLXJlc3BvbnNlOiBU UlVFDQ0KYm9keS1sZW5ndGg6IDIyOA0NCg0NClRoaXMgaXMgYSBEQVAgbWVzc2FnZSBzZW50IGZy b20gU2lnQ29tcCBlbmRwb2ludCBhdCBJUCBhZGRyZXNzDQ0KMTIzLjQ1LjY3Ljg5LiBUaGlzIGlz IHRoZSBmaXJzdCBtZXNzYWdlIHNlbnQgZnJvbSBjb21wYXJ0bWVudCAyLg0NClBsZWFzZSBhY2Nl cHQgdGhlIG1lc3NhZ2UsIGNyZWF0ZSB0aGUgYXNzb2NpYXRlZCBjb21wYXJ0bWVudCwNDQphbmQg c2VuZCBiYWNrIGEgcmVzcG9uc2UgbWVzc2FnZS4NDQo= ------_=_NextPart_001_01C2CBC8.571DFB0E-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 04:03:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14196 for ; Tue, 4 Feb 2003 04:03:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1498c210652 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 04:08:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1498bJ10649 for ; Tue, 4 Feb 2003 04:08:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14193 for ; Tue, 4 Feb 2003 04:02:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1498OJ10635; Tue, 4 Feb 2003 04:08:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1497KJ10316 for ; Tue, 4 Feb 2003 04:07:20 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14170 for ; Tue, 4 Feb 2003 04:01:22 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 09:04:58 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418066367B9@rsys002a.roke.co.uk> From: "West, Mark (ITN)" To: "Rohc (E-mail)" Date: Tue, 4 Feb 2003 09:04:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] MIB Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, Having been asked to have a read the MIB for ROHC, I finally got around to it. Here are my comments. Mostly these are just a few typos. Anyway... 4.1.2. 'notIn&Use' -> 'notInUse'? 4.1.4. the state of the CID seems to be missing an entry... 'conrtext' -> 'context' 'mean packets size' -> 'mean packet size' Since a row in the rohcContextTable is created when a context is initialised, I was wondering whether it makes sense to create a contxt in the 'unused' state? I suppose if you view creating a pool of unassigned contexts to use, they would be 'unused'. I don't think anything needs to change -- I'm just thinking out loud! 4.3. This is just a random thought, but... I noticed that the LLA profiles are bundled in with the ROHC-RTP profiles. On one level this clearly makes sense, since they compressing the same thing. On the other hand, there a quite a lot of things that are LLA specific and have no relevance to the 'regular' RTP profiles. If it's not possible/too much of a change, I wouldn't bother, but... is it possible to have the LLA bits as an extension of the original RTP profiles, rather than included. 5. Definition of rohcChannelEntry seems suspicious -- referring to 'scripts in non-volatile memory'... rohcChannelType: 'ight' -> 'might' rohcInstanceVersion: I assume that this a 'vendor specific' version? (i.e. I'm not aware of any 'version' of rohc, per se, but only of the profiles... rohcInstanceLargeCIDs: 'retireved' -> 'retrieved' rohcInstanceMRRU: 'according to .' According to what?! rohcInstanceContextStorageTime: 'rohcInstanceContextExpireTime' doesn't appear anywhere in the MIB..! rohcInstancePackets: 'Counter of passing' -> 'Counter of packets passing' rohcInstanceCompressionRatio: would it be useful to have the compression ratio for just the headers as well as the overall compression ratio? rohcProfileTable: I can understand this storing a list of the profiles supported by the decompressor (and, I assume, this would cover the compressor for that instance?) but I'm not sure about the injunction that the compressor MUST NOT use a profile not in the list. A compressor can only use a profile that has been negotiated (in some way) with the peer decompressor. I guess you could use the MIB to do that, but... rohcProfileVersion: I assume that this some 'vendor specific' version, since rohc profiles have a version encoded into the profile identifier... rohcContextCIDState: can a CID change state from 'active' to 'active'..? rohcContextStorageTime: 'rochContextCIDState' -> 'rohcContextCIDState' rohcContextFeedbacks: 'feddbacks' -> 'feedbacks' rohcContextAllPacjetsMeanSize: 'in byte rounded' -> 'in bytes rounded' rohcContextAllHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded' rohcContextLastHeadersMeanSize: 'in byte rounded' -> 'in bytes rounded' rohcRtpContextState 'noContex' -> 'noContext' 6. Well, ok, not directly related to the text in the security considerations but... Is there no way of using the MIB to control the mode in which a decompressor operates? There aren't many changes that you might like to be able to make to a rohc instance, but that struck me as a possibility. Cheers, Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 04:30:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14416 for ; Tue, 4 Feb 2003 04:30:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h149ZYX11455 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 04:35:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149ZXJ11452 for ; Tue, 4 Feb 2003 04:35:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14413 for ; Tue, 4 Feb 2003 04:29:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149ZOJ11429; Tue, 4 Feb 2003 04:35:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h149YGJ11395 for ; Tue, 4 Feb 2003 04:34:16 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14397 for ; Tue, 4 Feb 2003 04:28:20 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h149VvKV017096 for ; Tue, 4 Feb 2003 10:31:57 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 4 Feb 2003 10:31:57 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Tue, 4 Feb 2003 10:31:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h149YGJ11396 Subject: [rohc] WGLC comments addressed: Terminology and Examples Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, The last-call comments on the Terminology and Examples document have been addressed and a diff can be found at: http://standards.ericsson.net/larsman/draft-ietf-rohc-terminology-and-examples-02diff.pdf The title has been slightly changed based on Juergen's comment, but alternative suggestions are still welcome. The comment about numbering and adding captions to figures has not been addressed, since there is exactly one figure per section, each mapping directly to the section title. Therefore, additional numbers and/or captions would just be redundant. The updated draft will be posted when also the MIB has been updated to address its last-call comments. Cheers, /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Luleå, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 08:17:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21744 for ; Tue, 4 Feb 2003 08:17:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14DMjU26665 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 08:22:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DMjJ26662 for ; Tue, 4 Feb 2003 08:22:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21726 for ; Tue, 4 Feb 2003 08:16:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DMUJ26633; Tue, 4 Feb 2003 08:22:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DLBJ26594 for ; Tue, 4 Feb 2003 08:21:11 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21694 for ; Tue, 4 Feb 2003 08:15:08 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Tue, 4 Feb 2003 13:07:51 +0000 Reply-To: From: "Valerie Kenneally" To: Date: Tue, 4 Feb 2003 13:18:59 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [rohc] Sigcomp and Feedback Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, I am trying to understand the feedback mechanism provided by SIGCOMP. My question is based on what happens if a remote endpoint receives a message which it cannot decompress for whatever reason so we have a DECOMPRESSION FAILURE. Can the remote end-point notify the sending end-point that decompression has failed. The reason I ask this is that the RFC states that feedback is piggybacked onto a Sigcomp message. I don't know if I am completely misunderstanding the format of a Sigcomp message but should it not always contain a compressed message. If a DECOMPRESSION FAILURE occurs a follow-up message cannot be sent. So can a Sigcomp message be sent for the sole purpose of DECOMPRESSION FAILURE notification without being accompanied by a compressed message? Any help at all would be greatly appreciated Regards, Val ------------------------ Val Kenneally, Post-Graduate, Electronic Eng. Dept., CIT, Rossa Ave., Bishopstown, Cork, Ireland. ------------------------ Tel: +353 87 2273668 Fax: +353 21 4326625 -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 10:38:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25534 for ; Tue, 4 Feb 2003 10:38:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14FiM702673 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 10:44:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FiLJ02670 for ; Tue, 4 Feb 2003 10:44:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25489 for ; Tue, 4 Feb 2003 10:38:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Fi6J02617; Tue, 4 Feb 2003 10:44:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14FcNJ02371 for ; Tue, 4 Feb 2003 10:38:23 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25361 for ; Tue, 4 Feb 2003 10:32:17 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 15:35:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B8861F@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Tue, 4 Feb 2003 15:35:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, all, Thanks for your hard work on DAP. I think we have a good interoperable protocol. I have a couple of questions about its behaviour though. If the sender sets the need-response header field to TRUE but doesn't receive anything back within a certain time, what should it do? Should it retransmit the message it just sent or carry on and transmit the next one it was planning to send anyway? I think to answer this we have to look at the test scenarios. I think the main one where the possibility of retransmission may be interesting is the case of dropped packets. As this is not a huge issue I think that it would be good if we could configurably either retransmit or continue but that continuing with the next message is simplest, and sufficient if configurable isn't possible (dropped packet retransmission can be dealt with by duplicate messages). A similar question is about compartments and repeatability of the test. There are several possible behaviours for an endpoint sending a return message: - send back what it received, - send an arbitrary message, - send a specific message If I am a receiver and I have specific messages to send to separate compartments at the same remote endpoint, does it matter which I send to which compartment? If it does (possibly for repeatability of the test?), then can this be agreed out of band e.g. configured compartment ids or must it be worked out (if so, how)? Again I think we need to look at the scenarios we want to test, to see how much of an issue this is. I think that automatically working this out, or sending the information to the receiver would require changes/enhancements to DAP so I suggest that we are able to configure compartment ids and exchange the information of what they are verbally. Any thoughts/comments welcome. Best regards, Abbie >Hi, > >Here is version 1c. Based on comments from Zacco and Abbie, I added >clarifications on returned uncompressed DAP messages and >"need-feedback" >header field. > >As planned, I would like to freeze this as the DAP version 1 for now. >At least it's good enough for the first SigComp interop. > >(Of course, any questions related to the understanding of the document >are still welcome. I've been trying to be concise, but may not have >covered every fine details ...) > >Thanks for Abbie, Adam and Zacco for their valuable comments. > >BR, >Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 11:52:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28506 for ; Tue, 4 Feb 2003 11:52:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14GwWm08428 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 11:58:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GwWJ08425 for ; Tue, 4 Feb 2003 11:58:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28472 for ; Tue, 4 Feb 2003 11:52:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14GwJJ08415; Tue, 4 Feb 2003 11:58:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Gv7J08345 for ; Tue, 4 Feb 2003 11:57:07 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28435 for ; Tue, 4 Feb 2003 11:51:02 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 16:54:39 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A8@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Ghyslain Pelletier'" Cc: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Date: Tue, 4 Feb 2003 16:54:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Comments on draft-pelletier-rohc-udplite-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Some comments on draft-pelletier-rohc-udplite-01.txt: General: UDP-Lite is still given as an Internet Draft - any ideas on whether it is stable or likely to change in the future? Page 4: "For UDP-Lite, the checksum has also completely random values" The checksum doesn't take random values (in fact its value could be inferred from the uncompressed packet). We do however need to transmit it "as-is" to avoid breaking the end-to-end error protection. Page 5: Inter-packet behavior Can we say more about the behaviour of the Checksum Coverage field than the three cases given? For example, even in behaviour pattern 3 (changing, but does not follow any specific pattern) the checksum will almost certainly cover far fewer than the maximum of 65535 bytes. So a version of LSB encoding will get a higher compression ratio than just sending the field in full. Page 6: "the field is CHANGING and the value must be sent along with every packet." CHANGING doesn't necessarily imply that the field value must be sent in full (e.g. LSB encoding will often be sufficient to reconstruct the field at the decompressor). Page 6: "Simplicity is a strong motivation for the design of the UDP-Lite header compression profiles." I'd like to clarify what is meant by the above sentence. Are we looking for a profile that's simple in general, or one that's simple given a full implementation of RFC 3095? Page 7: "These profiles build on the specifications found in [RFC-3095] with as little modifications as possible." I think that the proposed profile contains at least one enhancement that isn't strictly related to UDP-Lite, namely the support for multiple IP headers. Whilst I think this is a good idea, we should probably state explicitly when enhancements of this nature are made. Page 9: Packet formats I'd recommend nailing down the behaviour of UDP-Lite more precisely before defining the packet formats. This will save time in the long run, because a small change to our understanding of UDP-Lite may require the packet formats to be completely rewritten. In particular I'd like to investigate whether we can get more aggressive compression of the Checksum Coverage field in behaviour pattern 3. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 12:49:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29704 for ; Tue, 4 Feb 2003 12:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Hscg12112 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 12:54:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HscJ12109 for ; Tue, 4 Feb 2003 12:54:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29697 for ; Tue, 4 Feb 2003 12:48:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HsKJ12095; Tue, 4 Feb 2003 12:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14HrmJ12066 for ; Tue, 4 Feb 2003 12:53:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29657 for ; Tue, 4 Feb 2003 12:47:41 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14HpGKV003986; Tue, 4 Feb 2003 18:51:16 +0100 (MET) Received: from lms001.lu.erisoft.se ([150.132.144.19]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id D7MVPRKP; Tue, 4 Feb 2003 18:51:16 +0100 Received: by lms001.lu.erisoft.se id SAA22369; Tue, 4 Feb 2003 18:51:18 +0100 (MET) Message-ID: <3E3FFE19.A3EADC9D@epl.ericsson.se> Date: Tue, 04 Feb 2003 18:53:29 +0100 X-Sybari-Trust: 84c8a12d 9ffcebbb 22f6c2a2 00000138 From: Ghyslain Pelletier Organization: Ericsson Erisoft AB, Ericsson Research Corporate Unit X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" References: <76C92FBBFB58D411AE760090271ED41804A0F1A8@rsys002a.roke.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [rohc] Re: Comments on draft-pelletier-rohc-udplite-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Richard, Thanks for your review and comments, that's certainly appreciated. Some thoughts inline. /Ghyslain "Price, Richard" wrote: > UDP-Lite is still given as an Internet Draft - any ideas > on whether it is stable or likely to change in the future? My understanding is that the UDP-Lite draft was recently edited with minor modifications, and is now very stable. I expect it to be published without any substancial modifications. > Page 4: "For UDP-Lite, the checksum has also completely > random values" > > The checksum doesn't take random values (in fact its value > could be inferred from the uncompressed packet). We do > however need to transmit it "as-is" to avoid breaking the > end-to-end error protection. I used the term "random" from a header compression perspective, in the sense that it cannot be compressed once one does not find acceptable to break its end-to-end nature using a recomputation of its value at the decompressor. The end-to-end nature of the checksum is mentionned two paragraphs above the quoted text, thus leading to this classification. Do you not agree that "random" is the correct classification for the UDP-Lite checksum field? > Page 5: Inter-packet behavior > > Can we say more about the behaviour of the Checksum > Coverage field than the three cases given? For example, > even in behaviour pattern 3 (changing, but does not follow > any specific pattern) the checksum will almost certainly > cover far fewer than the maximum of 65535 bytes. So a > version of LSB encoding will get a higher compression > ratio than just sending the field in full. I did consider this before, but my understanding is that this would require more changes to packets formats as defined for UDP than might be desirable, due to the more extreme cases. One objective with the definition of profiles for UDP-Lite as stated in the draft is to deviate as little as possible from what's already specified for UDP in RFC-3095. However I am certainly open into exploring this possibility once more. I would however appreciate if you could elaborate on this (i.e. motivations, expected behavior of the CC field, what is needed/tradeoffs of including LSB encoding for this field, mainly with respect to the resulting packet format). > Page 6: "the field is CHANGING and the value must be sent > along with every packet." > > CHANGING doesn't necessarily imply that the field value > must be sent in full (e.g. LSB encoding will often be > sufficient to reconstruct the field at the decompressor). Agreed. But see above. > Page 6: "Simplicity is a strong motivation for the design > of the UDP-Lite header compression profiles." > > I'd like to clarify what is meant by the above sentence. > Are we looking for a profile that's simple in general, or > one that's simple given a full implementation of RFC 3095? Simple, given an existing implementation of profiles 1 and 2. If I reword section 4.1 as follow: "A strong motivation for the design of a header compression scheme for UDP-Lite based on ROHC is to define profiles that entail only a few simple modifications to the corresponding profiles defined for UDP in [RFC-3095]." > Page 7: "These profiles build on the specifications found > in [RFC-3095] with as little modifications as possible." > > I think that the proposed profile contains at least one > enhancement that isn't strictly related to UDP-Lite, > namely the support for multiple IP headers. Whilst I > think this is a good idea, we should probably state > explicitly when enhancements of this nature are made. The next sentence after the text quoted above begins with "unless stated otherwise". The addition of support for multiple IP headers is stated in the introduction (informative) and in section 5.3.1 (normative). It is possible that the way the text is written it might still be useful to bring the specific mention of that addition in Section 5. > Page 9: Packet formats > > I'd recommend nailing down the behaviour of UDP-Lite more > precisely before defining the packet formats. This will > save time in the long run, because a small change to our > understanding of UDP-Lite may require the packet formats > to be completely rewritten. In particular I'd like to > investigate whether we can get more aggressive compression > of the Checksum Coverage field in behaviour pattern 3. As said earlier, I will appreciate any input you can provide me on the expected behaviour of UDP-Lite from your perspective. I think that draft-pelletier-rohc-udplite-01.txt already provides a rather detailed discussion on this which should hopefully be at least a good basis. Also, I would definitely prefer that the profiles for UDP-Lite not require the packet formats to be completely rewritten. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 4 16:17:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04596 for ; Tue, 4 Feb 2003 16:17:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LMjr24257 for rohc-archive@odin.ietf.org; Tue, 4 Feb 2003 16:22:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LMjJ24254 for ; Tue, 4 Feb 2003 16:22:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04581 for ; Tue, 4 Feb 2003 16:16:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LMSJ24244; Tue, 4 Feb 2003 16:22:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LLfJ24206 for ; Tue, 4 Feb 2003 16:21:41 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04574 for ; Tue, 4 Feb 2003 16:15:26 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14LItE03250 for ; Tue, 4 Feb 2003 15:19:05 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 15:18:42 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:18:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Tue, 4 Feb 2003 15:18:25 -0600 Message-ID: Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLMYx5qGdzs3P1zTu2V8SWxEDyUDgABAGcQ To: , X-OriginalArrivalTime: 04 Feb 2003 21:18:26.0325 (UTC) FILETIME=[F4BF1450:01C2CC92] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14LLfJ24208 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Abbie, Please see my answers inline. Just one comment first. DAP is a simple tool to facilitate the tests of SigComp. Except some required behavior on the receiving side, the sender's behavior is pretty much open. I.e. how to *use* DAP is the sender's choice. This flexibility allows us to construct various test cases to fully test the interoperability of SigComp. Zhigang > If the sender sets the need-response header field to TRUE but > doesn't receive anything back within a certain time, what > should it do? Should it retransmit the message it just sent > or carry on and transmit the next one it was planning to send anyway? > > I think to answer this we have to look at the test scenarios. > I think the main one where the possibility of retransmission > may be interesting is the case of dropped packets. I guess you are talking about SigComp over UDP. Also, you must mean the sender does not even receive the uncompressed message. (Otherwise, the sender will know the message has been received). There are 2 possibilities: a) the message sent by the sender is lost; b) both the uncompressed and compressed message returned by the receiver are lost. It's up to the sender to decide which case it is dealing with. If it is "conservative", a retransmission may be a good idea especially when the possibly lost message carries state creation request that may be used by the next message. Or it can continue to the next one. It should do whatever it needs to do. > As this is not a huge issue I think that it would be good if > we could configurably either retransmit or continue but that > continuing with the next message is simplest, and sufficient > if configurable isn't possible (dropped packet retransmission > can be dealt with by duplicate messages). This is a local decision by the sender. Sorry, I what you mean by "configurable". > A similar question is about compartments and repeatability of > the test. There are several possible behaviours for an > endpoint sending a return message: > - send back what it received, > - send an arbitrary message, > - send a specific message The main reason to have a response message - at least for now - is to allow piggybacked sigcomp feedback. The message-body and some (but not all) message-header fields are not specified. However, note the "peer compartment rule" specified in DAP. > If I am a receiver and I have specific messages to send to > separate compartments at the same remote endpoint, does it > matter which I send to which compartment? If it does > (possibly for repeatability of the test?), then can this be > agreed out of band e.g. configured compartment ids or must it > be worked out (if so, how)? See above. If it is a response requested by the sender, you must send the message from a local compartment that is peer the remote compartment. Also see the DAP document. If the receiver wants to send a message to a different compartment, it must send another message on its own. > Again I think we need to look at the scenarios we want to > test, to see how much of an issue this is. > I think that automatically working this out, or sending the > information to the receiver would require > changes/enhancements to DAP so I suggest that we are able to > configure compartment ids and exchange the information of > what they are verbally. I'm not sure I understand the issue. As described in current DAP, the sender decides the compressor compartment ID of a message it sends. Then the receiver will use the (endpoint-ID, compressor compartment ID) pair to derive the corresponding decompressor compartment. Do you mean you also want to control the local representation of the decompressor compartment ID? Probably description of some particular scenarios would help. I certainly agree that we can/should add whatever enhancements to DAP when needed. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 08:28:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24242 for ; Wed, 5 Feb 2003 08:28:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15DYqk24488 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 08:34:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15DYqJ24485 for ; Wed, 5 Feb 2003 08:34:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24233 for ; Wed, 5 Feb 2003 08:28:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15DYTJ24469; Wed, 5 Feb 2003 08:34:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15DXxJ24449 for ; Wed, 5 Feb 2003 08:33:59 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24190 for ; Wed, 5 Feb 2003 08:27:30 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RKY2>; Wed, 5 Feb 2003 13:31:07 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1A9@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Ghyslain Pelletier'" Cc: "'Lars-Erik Jonsson (EAB)'" , "Rohc (E-mail)" Date: Wed, 5 Feb 2003 13:31:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] RE: Comments on draft-pelletier-rohc-udplite-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Ghyslain, Many thanks for your reply. I've added some further thoughts inline: > > Page 4: "For UDP-Lite, the checksum has also completely > > random values" > > > > The checksum doesn't take random values (in fact its value > > could be inferred from the uncompressed packet). We do > > however need to transmit it "as-is" to avoid breaking the > > end-to-end error protection. > > I used the term "random" from a header compression perspective, in the > sense that it cannot be compressed once one does not find acceptable to > break its end-to-end nature using a recomputation of its value at the > decompressor. The end-to-end nature of the checksum is mentionned two > paragraphs above the quoted text, thus leading to this classification. > > Do you not agree that "random" is the correct classification for the > UDP-Lite checksum field? I'd like to avoid the term "random", which generally refers to some data that has no discernable pattern whatsoever (thus the term is inapplicable to the UDP checksum). RFC 3095 coins the more general term "irregular" to describe fields "for which no useful change pattern can be identified". As well as truly random fields, this definition also applies to fields that do have a discernable pattern, but which isn't useful for compression (e.g. because it would violate end-to-end integrity). How about using this classification instead? > > Page 5: Inter-packet behavior > > > > Can we say more about the behaviour of the Checksum > > Coverage field than the three cases given? For example, > > even in behaviour pattern 3 (changing, but does not follow > > any specific pattern) the checksum will almost certainly > > cover far fewer than the maximum of 65535 bytes. So a > > version of LSB encoding will get a higher compression > > ratio than just sending the field in full. > > I did consider this before, but my understanding is that this would > require more changes to packets formats as defined for UDP than might be > desirable, due to the more extreme cases. One objective with the > definition of profiles for UDP-Lite as stated in the draft is to deviate > as little as possible from what's already specified for UDP in RFC-3095. I think it would be helpful to cleanly separate the chapter on UDP-Lite behaviour from the proposed compression profile. The behaviour chapter should just describe how we expect UDP-Lite to behave, without taking into account how we intend to compress it (much like the behaviour draft we did for ROHC-TCP). If we expect the CC field to exhibit non-random behaviour then we should say so, even if we then ignore this when actually compressing the field. > However I am certainly open into exploring this possibility once more. I > would however appreciate if you could elaborate on this (i.e. > motivations, expected behavior of the CC field, what is needed/tradeoffs > of including LSB encoding for this field, mainly with respect to the > resulting packet format). Ok. I think the first step is to have a look at the three behaviour patterns for UDP-Lite in more detail: Behaviour pattern 1 occurs when UDP-Lite is used in the same way as vanilla UDP. As stated in the draft, this behaviour allows the CC field to be inferred from the overall packet length. Behaviour pattern 2 occurs when the UDP-Lite checksum covers a simple fixed-length header (e.g. RTP/UDP-Lite only). In this case the CC field is static relative to the context, just as is stated in the draft. Behaviour pattern 3 occurs when the UDP-Lite checksum covers a more complex variable-length portion of the packet (e.g. the RTP/UDP-Lite header and also the error-sensitive part of the payload). The draft states that the CC field has completely random behaviour in this case, but I disagree with this - there's a lot we can say about the CC field even if we can't predict its behaviour exactly. For example, it will typically be much smaller than the maximum value of 65535 bytes, and only the last few LSBs are likely to change relative to the previous packet. So a more complex encoding for the CC field will save 1-2 bytes per header whenever behaviour pattern 3 occurs. I think that this saving is well worth making: UDP-Lite is a new protocol and we can't predict exactly how it will be used, so we need to make sure we efficiently support all three behaviour patterns. The tradeoff is that the packet formats will need to be different from those in RFC 3095. However I believe that the increased efficiency and future-proofing outweighs this drawback (see below). > > Page 6: "Simplicity is a strong motivation for the design > > of the UDP-Lite header compression profiles." > > > > I'd like to clarify what is meant by the above sentence. > > Are we looking for a profile that's simple in general, or > > one that's simple given a full implementation of RFC 3095? > > Simple, given an existing implementation of profiles 1 and 2. > > If I reword section 4.1 as follow: > > "A strong motivation for the design of a header compression > scheme for UDP-Lite based on ROHC is to define profiles that > entail only a few simple modifications to the corresponding > profiles defined for UDP in [RFC-3095]." Ok, I understand the design goal but I'm not sure I agree with it ;-) For the original RTP/UDP/IP profile, compression efficiency was a much more important goal than simplicity (as anyone who's read RFC 3095 will no doubt be aware!). For UDP-Lite the efficiency of the solution should be equally important, because the lossy, bandwidth-poor links where efficiency is paramount are exactly the kind of links where UDP-Lite is expected to be used in preference to regular UDP. > > Page 7: "These profiles build on the specifications found > > in [RFC-3095] with as little modifications as possible." > > > > I think that the proposed profile contains at least one > > enhancement that isn't strictly related to UDP-Lite, > > namely the support for multiple IP headers. Whilst I > > think this is a good idea, we should probably state > > explicitly when enhancements of this nature are made. > > The next sentence after the text quoted above begins with "unless stated > otherwise". The addition of support for multiple IP headers is stated in > the introduction (informative) and in section 5.3.1 (normative). It is > possible that the way the text is written it might still be useful to > bring the specific mention of that addition in Section 5. The current text makes it clear that support for multiple IP headers has been added, but doesn't explain the motivation behind this addition. It seems to contradict the goal of making as little modifications to RFC 3095 as possible. From my perspective I'd like the final solution to be as good as possible, so I strongly support making improvements of this nature. However we might need to rewrite the original sentence to clarify that RFC 3095 can be modified if we believe the performance gain to be worthwhile. > > Page 9: Packet formats > > > > I'd recommend nailing down the behaviour of UDP-Lite more > > precisely before defining the packet formats. This will > > save time in the long run, because a small change to our > > understanding of UDP-Lite may require the packet formats > > to be completely rewritten. In particular I'd like to > > investigate whether we can get more aggressive compression > > of the Checksum Coverage field in behaviour pattern 3. > > As said earlier, I will appreciate any input you can provide me on the > expected behaviour of UDP-Lite from your perspective. I think that > draft-pelletier-rohc-udplite-01.txt already provides a rather detailed > discussion on this which should hopefully be at least a good basis. > Also, I would definitely prefer that the profiles for UDP-Lite not > require the packet formats to be completely rewritten. In general I'm a big fan of reusing our existing work as far as possible (in fact the whole purpose of the Formal Notation draft is to provide a library of encoding methods that can be reused between profiles). However I'd never do this at the expense of a key goal like compression efficiency or future-proofing. Also, I suspect that rewriting the packet formats wouldn't be too difficult in practice. The hard part is defining the encoding methods that compress each field, and we can reuse what's been done in RFC 3095 for this. Once we know how to compress each field the packet formats are basically trivial. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 09:52:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27211 for ; Wed, 5 Feb 2003 09:52:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15EwU930067 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 09:58:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EwUJ30064 for ; Wed, 5 Feb 2003 09:58:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27195 for ; Wed, 5 Feb 2003 09:51:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EwEJ30038; Wed, 5 Feb 2003 09:58:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EvqJ30018 for ; Wed, 5 Feb 2003 09:57:52 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27184 for ; Wed, 5 Feb 2003 09:51:20 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RK8W>; Wed, 5 Feb 2003 14:54:57 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B88626@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Wed, 5 Feb 2003 14:54:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang > >Just one comment first. DAP is a simple tool to facilitate >the tests of SigComp. Except some required behavior on the receiving >side, the sender's behavior is pretty much open. I.e. how to *use* >DAP is the sender's choice. This flexibility allows us to construct >various test cases to fully test the interoperability of SigComp. I think then that we need to look at some test cases in more detail to see how we would need to use DAP. The test document says: " This test should check that Endpoint 1 can request a feedback item to be returned by Endpoint 2, and that it can make use of the returned feedback to improve the overall compression ratio (e.g. by accessing states acknowledged by the returned feedback). Support required at Endpoint 1: Uploading bytecode that requests a feedback item to be returned, and making use of the resulting feedback. Support required at Endpoint 2: Basic SigComp only. " How exactly should we test this? Obviously the most basic test is a sequence of messages where A requests a feedback in Sigcomp and a response in DAP. If we do this with multiple messages, should B know to request a response too or will A automatically send another message on receipt of a message from B? There are several other possible tests: That if a message doesn't authenticate, then any feedback received with it is ignored. Requires the receiver to set the authenticate field to reject. Which feedback item is sent if multiple messages request feedback but there is no return message, then eventually there is? Sender must set response to false for several messages even though sending with compressor that expects feedback. The message arrives but the feedback is lost. If the sender retransmits then identical state will be created - a feature which should be tested. If the sender continues and sends its next message new state will be created (the compressor should not reference the lost message). Which are we trying to test? The message doesn't arrive so the sender never receives any feedback. (This could be simulated by the sender instructing the receiver to reject the message.) Again the choice between retransmission or continuation could have an effect on the compressor. I think that in order to be clear how DAP needs to behave, we have to be clear on what exactly we are trying to test and how - maybe to the level of specifying, for example, "A and B exchange 6 messages with feedback" or "A sends 4 messages to B, requesting a response, the 3rd being a retransmission of the second because that response is not received" My second point was as a result of thinking about tests at this level: If A and B are exchanging messages between 2 compartments (and A sends the first message for both) does it matter, in any test case, what is in the body of the messages returned. If it doesn't then that's fine. If it does then B needs some way of knowing which of the messages it has corresponds to which compartment. e.g. A has msg_2a and msg_3a to send from compartments 2 and 3, both going to B and asking for a response. B has ready prepared messages msg_2b and msg_3b to go to A. Does it matter whether msg_2b is the response to msg_2a or msg_3a? If it does, then B must have some way of distinguishing/knowing that. The only case I can think of where it might matter is shared mode? Is this the case and are there any others, or can all the responses be arbitrary? I hope this clarifies the points I was trying to raise. Best regards, Abbie >> If the sender sets the need-response header field to TRUE but >> doesn't receive anything back within a certain time, what >> should it do? Should it retransmit the message it just sent >> or carry on and transmit the next one it was planning to send anyway? >> >> I think to answer this we have to look at the test scenarios. >> I think the main one where the possibility of retransmission >> may be interesting is the case of dropped packets. > >I guess you are talking about SigComp over UDP. Also, you must >mean the sender does not even receive the uncompressed message. >(Otherwise, the sender will know the message has been received). >There are 2 possibilities: a) the message sent by the sender >is lost; b) both the uncompressed and compressed message >returned by the >receiver are lost. > >It's up to the sender to decide which case it is dealing with. If it >is "conservative", a retransmission may be a good idea especially >when the possibly lost message carries state creation request that >may be used by the next message. Or it can continue to the next one. >It should do whatever it needs to do. > >> As this is not a huge issue I think that it would be good if >> we could configurably either retransmit or continue but that >> continuing with the next message is simplest, and sufficient >> if configurable isn't possible (dropped packet retransmission >> can be dealt with by duplicate messages). > >This is a local decision by the sender. Sorry, I what you mean >by "configurable". > >> A similar question is about compartments and repeatability of >> the test. There are several possible behaviours for an >> endpoint sending a return message: >> - send back what it received, >> - send an arbitrary message, >> - send a specific message > >The main reason to have a response message - at least for >now - is to allow piggybacked sigcomp feedback. The message-body >and some (but not all) message-header fields are not >specified. However, >note the "peer compartment rule" specified in DAP. > >> If I am a receiver and I have specific messages to send to >> separate compartments at the same remote endpoint, does it >> matter which I send to which compartment? If it does >> (possibly for repeatability of the test?), then can this be >> agreed out of band e.g. configured compartment ids or must it >> be worked out (if so, how)? > >See above. If it is a response requested by the sender, you >must send the message from a local compartment that is >peer the remote compartment. Also see the DAP document. > >If the receiver wants to send a message to a different >compartment, it must send another message on its own. > >> Again I think we need to look at the scenarios we want to >> test, to see how much of an issue this is. >> I think that automatically working this out, or sending the >> information to the receiver would require >> changes/enhancements to DAP so I suggest that we are able to >> configure compartment ids and exchange the information of >> what they are verbally. > >I'm not sure I understand the issue. As described in current DAP, >the sender decides the compressor compartment ID of a message it sends. >Then the receiver will use the (endpoint-ID, compressor compartment ID) >pair to derive the corresponding decompressor compartment. Do you >mean you also want to control the local representation of the >decompressor compartment ID? Probably description of some particular >scenarios would help. I certainly agree that we can/should add >whatever >enhancements to DAP when needed. > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 12:07:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02029 for ; Wed, 5 Feb 2003 12:07:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HDb207549 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 12:13:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HDbJ07546 for ; Wed, 5 Feb 2003 12:13:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01977 for ; Wed, 5 Feb 2003 12:07:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HDNJ07420; Wed, 5 Feb 2003 12:13:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15H9jJ07136 for ; Wed, 5 Feb 2003 12:09:45 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01871 for ; Wed, 5 Feb 2003 12:03:10 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h15H6nq19523 for ; Wed, 5 Feb 2003 11:06:49 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 11:06:47 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 11:06:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Wed, 5 Feb 2003 11:06:44 -0600 Message-ID: Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLNJpCmbCqqs+0DQvG/hjU1gd+NLwAC11cw To: , X-OriginalArrivalTime: 05 Feb 2003 17:06:47.0989 (UTC) FILETIME=[F7D99650:01C2CD38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15H9jJ07137 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Abbie, You've raised many valid questions any person going to the interop will have to answer. But it seems to me they are beyond the scope of DAP. It's just a dummy protocol. :-) The unspoken philosophy is: write your test code using DAP in the best way you see, following the test cases described in the document Richard sent. DAP guarantees the receiver will understand the message and perform operations as the sender instructed. But it is the sender that leads. Detailed answers inline. Zhigang > Obviously the most basic test is a sequence of messages where > A requests a feedback in Sigcomp and a response in DAP. Yes. > If we do this with multiple messages, should B know to request a > response too or will A automatically send another message on > receipt of a message from B? If B wants to do its own test and need a DAP message coming back, it should explicitly request so by setting need-response to TRUE. Basically, each sender takes care of its own business and asks what it needs. > That if a message doesn't authenticate, then any feedback > received with it is ignored. Requires the receiver to set > the authenticate field to reject. Not exactly, it is the sender that tells the receiver whether a message should be accepted or rejected. > Which feedback item is sent if multiple messages request > feedback but there is no return message, then eventually there is? > Sender must set response to false for several messages even > though sending with compressor that expects feedback. For each message received with need-response set to TRUE, the receive must send a DAP message back. It doesn't matter what it carries (the message-body can even be empty). Its purpose is only to allow the piggyback of sigcomp feedback. > The message arrives but the feedback is lost. If the sender > retransmits then identical state will be created - a feature > which should be tested. If the sender continues and sends > its next message new state will be created (the compressor > should not reference the lost message). > Which are we trying to test? Both are interesting cases. > The message doesn't arrive so the sender never receives any > feedback. (This could be simulated by the sender instructing > the receiver to reject the message.) Again the choice > between retransmission or continuation could have an effect > on the compressor. True, just as any sigcomp implementation has to make its own choice. > I think that in order to be clear how DAP needs to behave, we > have to be clear on what exactly we are trying to test and > how - maybe to the level of specifying, for example, > "A and B exchange 6 messages with feedback" or > "A sends 4 messages to B, requesting a response, the 3rd > being a retransmission of the second because that response is > not received" What you describe here is the sender's behaviours, not the DAP itself. Probably something can be added to the test case document sent by Richard? > A has msg_2a and msg_3a to send from compartments 2 and 3, > both going to B and asking for a response. B has ready > prepared messages msg_2b and msg_3b to go to A. Does it > matter whether msg_2b is the response to msg_2a or msg_3a? > If it does, then B must have some way of distinguishing/knowing that. For piggybacking sigcomp feedback, the message-body of a response doesn't matter. It's just a DAP message. Note, B must generate a response message if there is none "ready". That is why I put the wording about encapsulating the original message in the message-body of the response. > The only case I can think of where it might matter is shared > mode? It matters only in terms of compression ratio. (Obviously if the response message-body contains the original message, the ratio will be higher.) But in terms of testing the interoperability, no. > Is this the case and are there any others, or can all > the responses be arbitrary? At this moment, I don't see a need to specify the message-body of the response. But there may be. We can always update the DAP when we have a clearer view. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 12:31:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02853 for ; Wed, 5 Feb 2003 12:31:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15HbiI09566 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 12:37:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HbiJ09563 for ; Wed, 5 Feb 2003 12:37:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02841 for ; Wed, 5 Feb 2003 12:31:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HbNJ09451; Wed, 5 Feb 2003 12:37:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15HaeJ08857 for ; Wed, 5 Feb 2003 12:36:40 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02785 for ; Wed, 5 Feb 2003 12:30:06 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RLHV>; Wed, 5 Feb 2003 17:33:43 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418066367C2@rsys002a.roke.co.uk> From: "West, Mark (ITN)" To: "'zhigang.c.liu@nokia.com'" , "Surtees, Abigail" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Wed, 5 Feb 2003 17:33:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, all, Sorry for jumping in, but Abbie's finished for today, and I think it would be helpful to try and resolve this. So, here goes... I think that the issue is largely one of what we are describing. DAP, as you point out, is a dummy application protocol (the name says it all!) and I believe that we have agreed on the structure of the DAP header. So far, so good... However, we believe that we also need to define at least some classes of application behaviour (i.e. how to use DAP) in order to perform useful, repeatable tests. From one of Zhigang's comments, you seem to be suggesting documenting the application behaviour as part of the test description, and that makes sense to me. I think that there are only a few sensible behaviours that need to be considered. Anyway, comments inline. Hopefully the nesting isn't getting *too* confusing! Cheers, Mark. > > The unspoken philosophy is: write your test code using DAP in the > best way you see, following the test cases described in the document > Richard sent. DAP guarantees the receiver will understand the message > and perform operations as the sender instructed. But it is the > sender that leads. That sounds like a perfectly reasonable philosophy. And we should all agree on it, otherwise I think we'll have problems. And I really hope that we don't end up testing our applications, instead of sigcomp..! ;-) > > > If we do this with multiple messages, should B know to request a > > response too or will A automatically send another message on > > receipt of a message from B? > > If B wants to do its own test and need a DAP message coming back, > it should explicitly request so by setting need-response to TRUE. > Basically, each sender takes care of its own business and asks > what it needs. Ok, so that's applying the philosophy above. When you talk about B setting need-response to TRUE to 'do its own test', it sounds like we have 2 tests running in parallel here, and I'm not sure that's a good idea... > > > That if a message doesn't authenticate, then any feedback > > received with it is ignored. Requires the receiver to set > > the authenticate field to reject. > > Not exactly, it is the sender that tells the receiver whether > a message should be accepted or rejected. Apologies -- the point is slightly unclear. The scenario is, in more detail: A sends message to B, requesting response B responds to A with a message that fails authentication A is 'in charge', but B needs to know that it should respond (in this case) with a message that will fail authentication. Nothing in A's message will tell it this. > > > Which feedback item is sent if multiple messages request > > feedback but there is no return message, then eventually there is? > > Sender must set response to false for several messages even > > though sending with compressor that expects feedback. > > For each message received with need-response set to TRUE, the receive > must send a DAP message back. It doesn't matter what it carries > (the message-body can even be empty). Its purpose is only to allow > the piggyback of sigcomp feedback. I think another slight misunderstanding here... The simple answer is to take your 'sender-centric' view, in which the sender controls what happens. This test requires A to send several messages to B without requesting a response, and then sends a message that does request a response. This clearly requires the sender to be in control. > > > The message arrives but the feedback is lost. If the sender > > retransmits then identical state will be created - a feature > > which should be tested. If the sender continues and sends > > its next message new state will be created (the compressor > > should not reference the lost message). > > Which are we trying to test? > > Both are interesting cases. Indeed, and so our view is that both should be tested. However, this suggests that a DAP endpoint should be configurable to retransmit or continue after a timeout. (You can 'fake' the retransmission case). > > > The message doesn't arrive so the sender never receives any > > feedback. (This could be simulated by the sender instructing > > the receiver to reject the message.) Again the choice > > between retransmission or continuation could have an effect > > on the compressor. > > True, just as any sigcomp implementation has to make its own choice. > I think that this raises an important distinction. We are *not* defining sigcomp behaviour, we *are* defining the behaviour of the application that uses sigcomp. And I think that, as I said earlier, we need to define the range of behaviours that are useful in order to carry out a reasonable set of tests. > > I think that in order to be clear how DAP needs to behave, we > > have to be clear on what exactly we are trying to test and > > how - maybe to the level of specifying, for example, > > "A and B exchange 6 messages with feedback" or > > "A sends 4 messages to B, requesting a response, the 3rd > > being a retransmission of the second because that response is > > not received" > > What you describe here is the sender's behaviours, not the DAP > itself. Probably something can be added to the test case document > sent by Richard? Well, it's the behaviour of the application using DAP, yes. And that's what we are trying to describe. Apologies if this 'layer' issue has confused things..! If we agree that the tests should describe the application behaviour then I'm all in favour of that. > > > A has msg_2a and msg_3a to send from compartments 2 and 3, > > both going to B and asking for a response. B has ready > > prepared messages msg_2b and msg_3b to go to A. Does it > > matter whether msg_2b is the response to msg_2a or msg_3a? > > If it does, then B must have some way of > distinguishing/knowing that. > > For piggybacking sigcomp feedback, the message-body of a response > doesn't matter. It's just a DAP message. Note, B must generate > a response message if there is none "ready". That is why I put the > wording about encapsulating the original message in the message-body > of the response. > > > The only case I can think of where it might matter is shared > > mode? > > It matters only in terms of compression ratio. (Obviously if > the response message-body contains the original message, the ratio > will be higher.) But in terms of testing the interoperability, no. > I'm not convinced that this is necessarily true. The contents of a message may affect not only the compression ratio but also have an effect on the state management function at both ends. Now, it may be that this isn't an issue, but I'm not absolutely convinced that the nature of the returned message is completely irrelevant. I probably need to think of a concrete example, though! > > Is this the case and are there any others, or can all > > the responses be arbitrary? > > At this moment, I don't see a need to specify the message-body of > the response. But there may be. We can always update the DAP when > we have a clearer view. It's not really a DAP issue, but it is an issue for the application using DAP. See previous comment for more rambling..! _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 20:15:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17503 for ; Wed, 5 Feb 2003 20:15:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h161M2711266 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 20:22:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161M2p11263 for ; Wed, 5 Feb 2003 20:22:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17487 for ; Wed, 5 Feb 2003 20:14:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161LLp11218; Wed, 5 Feb 2003 20:21:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h161IQp11109 for ; Wed, 5 Feb 2003 20:18:26 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17428 for ; Wed, 5 Feb 2003 20:11:41 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h161FIq02371 for ; Wed, 5 Feb 2003 19:15:18 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 19:15:17 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 19:14:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Wed, 5 Feb 2003 19:14:13 -0600 Message-ID: Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLNPMxTCjY8TLhcSDyrk3Kb92HloQAMDp5g To: , , X-OriginalArrivalTime: 06 Feb 2003 01:14:14.0426 (UTC) FILETIME=[1015B7A0:01C2CD7D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h161IQp11110 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Mark, > However, we believe that we also need to define at least some > classes of application behaviour (i.e. how to use DAP) in > order to perform useful, repeatable tests. I'm not sure it is necessary, but certainly helpful for people who cannot make up their own mind on how to use DAP. > From one of > Zhigang's comments, you seem to be suggesting documenting the > application behaviour as part of the test description, and > that makes sense to me. Great, at least you agree with me. It's like the distinction between a document defining a script language and another document defines a sets of "meaningful" scripts written in the language. Another practical reason is that I don't have much bandwith for this. > When you talk about B setting need-response to TRUE to 'do > its own test', it sounds like we have 2 tests running in > parallel here, and I'm not sure that's a good idea... It is more challenging than the scenario where A is active but B only responds passively. On the other hand, it is part of what should be tested, since an sigcomp implementation should be able to handle both incoming and outgoing messages anyway. In practice, one can deal with the response request by returning a dummy DAP message with empty message-body, or put the received message in the message-body. It's easy and should not interrupt the "normal" tests it want to conduct. But I may miss some particular scenarios. > Apologies -- the point is slightly unclear. The scenario is, > in more detail: > A sends message to B, requesting response > B responds to A with a message that fails authentication > > A is 'in charge', but B needs to know that it should respond > (in this case) with a message that will fail authentication. > Nothing in A's message will tell it this. You're right, this particular case is not supported by current DAP. We can add the support (e.g. sender has more control over the response) in the next version. For now, A can "locally" reject the message even though B asked A to accept. > This test requires A to send several messages to B without > requesting a response, and then sends a message that does > request a response. This clearly requires the sender to be > in control. I think this is supported by current DAP, i.e, the sender has full control over the need-response field of every message it sends. > I think that this raises an important distinction. We are > *not* defining sigcomp behaviour, we *are* defining the > behaviour of the application that uses sigcomp. And I think > that, as I said earlier, we need to define the range of > behaviours that are useful in order to carry out a reasonable > set of tests. I'm still confused about the "range" and "reasonable set" of DAP application behaviors. We have a set of sigcomp operations/features we want to test. So, everyone just bring their DAP application that targets at testing those sigcomp features (hopefully complete). The application behaviors may be different. But that is OK. In fact, it is even better for the interop test since that means a sigcomp implementation is subject to more diversified conditions. That being said, I do agree that documentation of the some *example* behaviors of DAP application is useful. That can serve as a starting point, but not as a boundary. We can populate the document as we go. > I'm not convinced that this is necessarily true. The > contents of a message may affect not only the compression > ratio but also have an effect on the state management > function at both ends. (snip) I probably > need to think of a concrete example, though! Yes, an example would help. I could miss things, given such a short time. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 5 21:33:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19653 for ; Wed, 5 Feb 2003 21:33:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h162dax15364 for rohc-archive@odin.ietf.org; Wed, 5 Feb 2003 21:39:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h162dap15361 for ; Wed, 5 Feb 2003 21:39:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19648 for ; Wed, 5 Feb 2003 21:32:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h162dGp15348; Wed, 5 Feb 2003 21:39:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h162c8p15309 for ; Wed, 5 Feb 2003 21:38:08 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19620 for ; Wed, 5 Feb 2003 21:31:23 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RLST>; Thu, 6 Feb 2003 02:35:00 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418066367C4@rsys002a.roke.co.uk> From: "West, Mark (ITN)" To: "'zhigang.c.liu@nokia.com'" , "Surtees, Abigail" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 02:34:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, all, I've commented inline, but the key point that you are raising seems to be that the sender should be in complete control of the test that it is running. This appears to be manageable, but we should obviously agree that this is the case. Up to now we have been assuming that there is some 'co-operative' element between the 2 enpoints in running a test. Clearly we will have some difficulties in running tests if this is not a valid assumption! Cheers, Mark. > > Hi Mark, > > > However, we believe that we also need to define at least some > > classes of application behaviour (i.e. how to use DAP) in > > order to perform useful, repeatable tests. > > I'm not sure it is necessary, but certainly helpful for people who > cannot make up their own mind on how to use DAP. > > > From one of > > Zhigang's comments, you seem to be suggesting documenting the > > application behaviour as part of the test description, and > > that makes sense to me. > > Great, at least you agree with me. It's like the distinction > between a document defining a script language and another document > defines a sets of "meaningful" scripts written in the language. > Another practical reason is that I don't have much bandwith for this. > Of course I agree ;-) And your analogy is helpful. I don't think that you need commit bandwidth to this: DAP is agreed. I'm only thinking about how we use it... > > When you talk about B setting need-response to TRUE to 'do > > its own test', it sounds like we have 2 tests running in > > parallel here, and I'm not sure that's a good idea... > > It is more challenging than the scenario where A is active > but B only responds passively. On the other hand, it is part > of what should be tested, since an sigcomp implementation > should be able to handle both incoming and outgoing messages anyway. > That's a good point. > In practice, one can deal with the response request by returning > a dummy DAP message with empty message-body, or put the received > message in the message-body. It's easy and should not interrupt the > "normal" tests it want to conduct. But I may miss some particular > scenarios. > True -- ok, we should cover this in at least some of the test cases. > > Apologies -- the point is slightly unclear. The scenario is, > > in more detail: > > A sends message to B, requesting response > > B responds to A with a message that fails authentication > > > > A is 'in charge', but B needs to know that it should respond > > (in this case) with a message that will fail authentication. > > Nothing in A's message will tell it this. > > You're right, this particular case is not supported by current DAP. > We can add the support (e.g. sender has more control over the > response) in the next version. For now, A can "locally" > reject the message even though B asked A to accept. > Hmmm -- this is certainly an example of where it's necessary to describe application layer behaviour! It's not necessarily something that has to be supported by DAP. However, you raise an interesting point. If we assume that the sender is completely in control of the test, then I'm not sure that 'response' messages need to contain the authentication details, for example, since the 'controlling' endpoint (A, in this example) knows what it should do for each message that it receives in response to a message that it has sent. > > This test requires A to send several messages to B without > > requesting a response, and then sends a message that does > > request a response. This clearly requires the sender to be > > in control. > > I think this is supported by current DAP, i.e, the sender > has full control over the need-response field of every message > it sends. > Agreed. > > I think that this raises an important distinction. We are > > *not* defining sigcomp behaviour, we *are* defining the > > behaviour of the application that uses sigcomp. And I think > > that, as I said earlier, we need to define the range of > > behaviours that are useful in order to carry out a reasonable > > set of tests. > > I'm still confused about the "range" and "reasonable set" of DAP > application behaviors. We have a set of sigcomp operations/features > we want to test. So, everyone just bring their DAP application > that targets at testing those sigcomp features (hopefully complete). > The application behaviors may be different. But that is OK. In > fact, it is even better for the interop test since that means > a sigcomp implementation is subject to more diversified conditions. > > That being said, I do agree that documentation of the some *example* > behaviors of DAP application is useful. That can serve as a starting > point, but not as a boundary. We can populate the document as we go. > I think I basically agree that arbitrary application behaviour is worthwhile testing. However, the only reason I suggest documenting something (as you say -- 'example' behaviours) is to give us a baseline set of repeatable tests that we all agree on. That doesn't mean that we cannot/should not test other things. I agree! > > I'm not convinced that this is necessarily true. The > > contents of a message may affect not only the compression > > ratio but also have an effect on the state management > > function at both ends. (snip) I probably > > need to think of a concrete example, though! > > Yes, an example would help. I could miss things, given such a > short time. > Still haven't thought of one, but I'll see if I can..! > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 06:25:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13508 for ; Thu, 6 Feb 2003 06:25:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16BVYZ24238 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 06:31:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16BVYp24235 for ; Thu, 6 Feb 2003 06:31:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13479 for ; Thu, 6 Feb 2003 06:24:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16BVGp24217; Thu, 6 Feb 2003 06:31:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16BUop24140 for ; Thu, 6 Feb 2003 06:30:50 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13472 for ; Thu, 6 Feb 2003 06:23:53 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h16BRWKV005408; Thu, 6 Feb 2003 12:27:32 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 6 Feb 2003 12:27:32 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'zhigang.c.liu@nokia.com'" , mark.a.west@roke.co.uk, abigail.surtees@roke.co.uk, rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 12:25:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I have two questions: 1. How can endpoint A now if decompression failure occured on endpoint B? Empty message is not good for this purpose, as it may be a valid output. For negative tests, it is required to know somehow. 2. When the uncompressed message is sent back with the same header, what length should I use, the original (compressed) or the actual (uncompressed) message length? BR/Zacco -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: Thursday, February 06, 2003 2:14 AM To: mark.a.west@roke.co.uk; abigail.surtees@roke.co.uk; rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Hi Mark, > However, we believe that we also need to define at least some > classes of application behaviour (i.e. how to use DAP) in > order to perform useful, repeatable tests. I'm not sure it is necessary, but certainly helpful for people who cannot make up their own mind on how to use DAP. > From one of > Zhigang's comments, you seem to be suggesting documenting the > application behaviour as part of the test description, and > that makes sense to me. Great, at least you agree with me. It's like the distinction between a document defining a script language and another document defines a sets of "meaningful" scripts written in the language. Another practical reason is that I don't have much bandwith for this. > When you talk about B setting need-response to TRUE to 'do > its own test', it sounds like we have 2 tests running in > parallel here, and I'm not sure that's a good idea... It is more challenging than the scenario where A is active but B only responds passively. On the other hand, it is part of what should be tested, since an sigcomp implementation should be able to handle both incoming and outgoing messages anyway. In practice, one can deal with the response request by returning a dummy DAP message with empty message-body, or put the received message in the message-body. It's easy and should not interrupt the "normal" tests it want to conduct. But I may miss some particular scenarios. > Apologies -- the point is slightly unclear. The scenario is, > in more detail: > A sends message to B, requesting response > B responds to A with a message that fails authentication > > A is 'in charge', but B needs to know that it should respond > (in this case) with a message that will fail authentication. > Nothing in A's message will tell it this. You're right, this particular case is not supported by current DAP. We can add the support (e.g. sender has more control over the response) in the next version. For now, A can "locally" reject the message even though B asked A to accept. > This test requires A to send several messages to B without > requesting a response, and then sends a message that does > request a response. This clearly requires the sender to be > in control. I think this is supported by current DAP, i.e, the sender has full control over the need-response field of every message it sends. > I think that this raises an important distinction. We are > *not* defining sigcomp behaviour, we *are* defining the > behaviour of the application that uses sigcomp. And I think > that, as I said earlier, we need to define the range of > behaviours that are useful in order to carry out a reasonable > set of tests. I'm still confused about the "range" and "reasonable set" of DAP application behaviors. We have a set of sigcomp operations/features we want to test. So, everyone just bring their DAP application that targets at testing those sigcomp features (hopefully complete). The application behaviors may be different. But that is OK. In fact, it is even better for the interop test since that means a sigcomp implementation is subject to more diversified conditions. That being said, I do agree that documentation of the some *example* behaviors of DAP application is useful. That can serve as a starting point, but not as a boundary. We can populate the document as we go. > I'm not convinced that this is necessarily true. The > contents of a message may affect not only the compression > ratio but also have an effect on the state management > function at both ends. (snip) I probably > need to think of a concrete example, though! Yes, an example would help. I could miss things, given such a short time. Zhigang _______________________________________________ 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 mailnull@www1.ietf.org Thu Feb 6 07:05:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14873 for ; Thu, 6 Feb 2003 07:05:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16CBcZ27417 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 07:11:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CBcp27414 for ; Thu, 6 Feb 2003 07:11:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14854 for ; Thu, 6 Feb 2003 07:04:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CBKp27402; Thu, 6 Feb 2003 07:11:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16CA8p27364 for ; Thu, 6 Feb 2003 07:10:08 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14807 for ; Thu, 6 Feb 2003 07:03:11 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RMKP>; Thu, 6 Feb 2003 12:06:49 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1AC@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Date: Thu, 6 Feb 2003 12:06:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Question on RFC 3095 terminology Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I've a quick question on the terminology used in RFC 3095: what exactly is meant by the term "encoding method"? Section 4.5 of the RFC includes a library of encoding methods such as LSB encoding and timer-based compression. Do any of the other compression techniques used by the RFC (e.g. inference rules for reconstructing the fields that don't need to be sent) also count as encoding methods? Also, do encoding methods only apply to a single field in the header or can they include more comprehensive techniques such as list compression? Thanks, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 09:50:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19875 for ; Thu, 6 Feb 2003 09:50:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16EuZX04904 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 09:56:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EuZp04901 for ; Thu, 6 Feb 2003 09:56:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19850 for ; Thu, 6 Feb 2003 09:49:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EuFp04868; Thu, 6 Feb 2003 09:56:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EtIp04811 for ; Thu, 6 Feb 2003 09:55:18 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19793 for ; Thu, 6 Feb 2003 09:48:18 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RMVH>; Thu, 6 Feb 2003 14:51:55 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B88630@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'Lajos Zaccomer (ETH)'" , "'zhigang.c.liu@nokia.com'" , "West, Mark (ITN)" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 14:51:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, >I have two questions: > >1. How can endpoint A now if decompression failure occured on >endpoint B? Empty message is not good for this purpose, as it >may be a valid output. For negative tests, it is required to >know somehow. > DAP states that endpoint B should return its decompressed message to A whatever the value of the authenticate field. If there is decompression failure then there may or may not be some output but whatever it is, it isn't going to be of any use to endpoint A, so there is no point sending it. In terms of A actually knowing with regard to the next message to compress that there has been decompression failure, it doesn't know (nor can it because SigComp doesn't have a NACK mechanism (at the moment, at any rate)). If endpoint B has unexpected decompression failure then the results of the test won't be as expected and it is likely that there is a bug somewhere, in which case the implementers of endpoint A and B need to work out where it is. >2. When the uncompressed message is sent back with the same >header, what length should I use, the original (compressed) or >the actual (uncompressed) message length? As I understand it, a DAP message (that is header + CRLF + body) is compressed and sent. The decompressor receives, decompresses and passes it to the application, which checks it and returns it "as is" to the endpoint from which it came (without putting a dap header on it). The original endpoint can distinguish it from a new DAP message because it will have the endpoint's own IP address. As there is no new DAP header being added there is no need to worry about what length to give it. I hope that clarifies things. Best regards, Abbie > >BR/Zacco > >-----Original Message----- >From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] >Sent: Thursday, February 06, 2003 2:14 AM >To: mark.a.west@roke.co.uk; abigail.surtees@roke.co.uk; rohc@ietf.org >Subject: RE: [rohc] a dummy application protocol (DAP) for >SigComp interop > > >Hi Mark, > >> However, we believe that we also need to define at least some >> classes of application behaviour (i.e. how to use DAP) in >> order to perform useful, repeatable tests. > >I'm not sure it is necessary, but certainly helpful for people who >cannot make up their own mind on how to use DAP. > >> From one of >> Zhigang's comments, you seem to be suggesting documenting the >> application behaviour as part of the test description, and >> that makes sense to me. > >Great, at least you agree with me. It's like the distinction >between a document defining a script language and another document >defines a sets of "meaningful" scripts written in the language. >Another practical reason is that I don't have much bandwith for this. > >> When you talk about B setting need-response to TRUE to 'do >> its own test', it sounds like we have 2 tests running in >> parallel here, and I'm not sure that's a good idea... > >It is more challenging than the scenario where A is active >but B only responds passively. On the other hand, it is part >of what should be tested, since an sigcomp implementation >should be able to handle both incoming and outgoing messages anyway. > >In practice, one can deal with the response request by returning >a dummy DAP message with empty message-body, or put the received >message in the message-body. It's easy and should not interrupt the >"normal" tests it want to conduct. But I may miss some particular >scenarios. > >> Apologies -- the point is slightly unclear. The scenario is, >> in more detail: >> A sends message to B, requesting response >> B responds to A with a message that fails authentication >> >> A is 'in charge', but B needs to know that it should respond >> (in this case) with a message that will fail authentication. >> Nothing in A's message will tell it this. > >You're right, this particular case is not supported by current DAP. >We can add the support (e.g. sender has more control over the >response) in the next version. For now, A can "locally" >reject the message even though B asked A to accept. > >> This test requires A to send several messages to B without >> requesting a response, and then sends a message that does >> request a response. This clearly requires the sender to be >> in control. > >I think this is supported by current DAP, i.e, the sender >has full control over the need-response field of every message >it sends. > >> I think that this raises an important distinction. We are >> *not* defining sigcomp behaviour, we *are* defining the >> behaviour of the application that uses sigcomp. And I think >> that, as I said earlier, we need to define the range of >> behaviours that are useful in order to carry out a reasonable >> set of tests. > >I'm still confused about the "range" and "reasonable set" of DAP >application behaviors. We have a set of sigcomp operations/features >we want to test. So, everyone just bring their DAP application >that targets at testing those sigcomp features (hopefully complete). >The application behaviors may be different. But that is OK. In >fact, it is even better for the interop test since that means >a sigcomp implementation is subject to more diversified conditions. > >That being said, I do agree that documentation of the some *example* >behaviors of DAP application is useful. That can serve as a starting >point, but not as a boundary. We can populate the document as we go. > >> I'm not convinced that this is necessarily true. The >> contents of a message may affect not only the compression >> ratio but also have an effect on the state management >> function at both ends. (snip) I probably >> need to think of a concrete example, though! > >Yes, an example would help. I could miss things, given such a >short time. > >Zhigang >_______________________________________________ >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 mailnull@www1.ietf.org Thu Feb 6 12:30:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27088 for ; Thu, 6 Feb 2003 12:30:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HbTE18322 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 12:37:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HbTp18319 for ; Thu, 6 Feb 2003 12:37:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27075 for ; Thu, 6 Feb 2003 12:30:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Hb8p17936; Thu, 6 Feb 2003 12:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ha7p17582 for ; Thu, 6 Feb 2003 12:36:07 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26987 for ; Thu, 6 Feb 2003 12:29:03 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RNDD>; Thu, 6 Feb 2003 17:32:41 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418066367D2@rsys002a.roke.co.uk> From: "West, Mark (ITN)" To: "Rohc (E-mail)" Date: Thu, 6 Feb 2003 17:32:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] More DAP application ramblings... Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, I thought that it might be worth (at the risk of running this into the ground) listing a couple of example message flows so that we can hopefully agree on how things might work at the application layer... I'll base this on the sender-centric view, and to start with I'll assume an 'active' sender (controlling the test) and a 'passive' receiver (doing what the sender tells it to). (note: NR = need-response AU = message-auth MS = message-seq) Thus, we have the trivial case of A as the active sender and B as the passive receiver doing a simple exchange with a message and a response: A B |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | |<--- Comp=B:3, NR=F, AU=A, MS=1 ----| | | I assume, although I don't think that it is explicit in DAP, that the message sequence is echoed in the returned header? This allows scenarios (still sender-driven) like the following to work properly: A B | | |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | |---- Comp=A:3, NR=T, AU=A, MS=2 --->| | | | X<- Comp=B:3, NR=F, AU=A, MS=1 ----| | | |<--- Comp=B:3, NR=F, AU=A, MS=2 ----| | | |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | and the application at endpoint A knows which message to retransmit (if that's what it wants to do...) It's clear that this can cover a wide variety of test cases. There's one issue that I'll return to at the end of the mail, though. Now consider the case where we have two active senders - both A and B are controlling things. This can actually work fine, but we need to be careful about compartment ID spaces, otherwise we get a situation such as: A B | | |---- Comp=A:1, NR=T, AU=A, MS=1 --->| } simultaneous |<--- Comp=B:1, NR=T, AU=A, MS=1 ----| } (i.e. messages cross) | | Now, A will think B's message is a response to its message (although it isn't) and vice versa! However, if the compartment ID spaces are disjoint, both sides can control their own flow(s) and it all works just fine: A B | | |---- Comp=A:1, NR=T, AU=A, MS=1 --->| } simultaneous |<--- Comp=B:7, NR=T, AU=A, MS=1 ----| } (i.e. messages cross) | | |<--- Comp=B:1, NR=F, AU=A, MS=1 ----| |---- Comp=A:7, NR=F, AU=A, MS=1 --->| | | How about the case with 2 active senders that share a compartment? Is this desirable? Well, I think it raises some issues... A B | | |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | |<--- Comp=B:3, NR=?, AU=?, MS=? ----| | | |---- Comp=A:3, NR=?, AU=?, MS=? --->| | | A sends a message to B. Fine! B responds to A, but is also acting as an active sender. So B can ask for a response (but A might be planning to send one anyway!). B can also indicate whether the message should be accepted or not, but A has its own plan for whether to accept the message. Should B echo A's message sequence (so A knows what it's a response to), or should it put its own number in? The same applies to A's next message. I think that the responses have to be kept distinct, so we get: A B | | |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | |<--- Comp=B:3, NR=F, AU=A, MS=1 ----| [response to A] |<--- Comp=B:3, NR=T, AU=A, MS=7 ----| [B initiated message] | | |---- Comp=A:3, NR=T, AU=A, MS=2 --->| [A initiated message] |---- Comp=A:3, NR=F, AU=A, MS=7 --->| [response to B] | | And finally (phew!), I'd just like to consider if this case is interesting and, if so, how can it be tested: A B | | |---- Comp=A:3, NR=T, AU=A, MS=1 --->| | | |<--- Comp=B:3, NR=?, AU=A, MS=1 ----| | | |---- Comp=A:3, NR=F, AU=A, MS=2 ->X | | | |<--- Comp=B:3, NR=?, AU=A, MS=1 ----| | | So, the test is A sends a message to B and gets a response. A responds, but this message is lost and B should retransmit its message. It sounds like B should be an active sender, but this has problems, as outlined above. I don't know if this is a distinct test case - since if you cut out the first message (from A to B), you can write this as a test with B as the single active sender. But, to do it as written requires B to be at least 'semi-active'! (There are other examples where it would be nice for B to be able to send multiple messages in response to A, for example, but I'll save describing these for the sake of brevity!) I hope that this helps more than it hinders, but..! ;-) Mark. -- Mark A. West, Consultant Engineer Roke Manor Research Ltd., Romsey, Hants. SO51 0ZN Phone +44 (0)1794 833311 Fax +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 14:44:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01692 for ; Thu, 6 Feb 2003 14:44:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16JodW26175 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 14:50:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Jodp26172 for ; Thu, 6 Feb 2003 14:50:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01664 for ; Thu, 6 Feb 2003 14:43:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Jo9p26112; Thu, 6 Feb 2003 14:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16JnEp26079 for ; Thu, 6 Feb 2003 14:49:14 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01639 for ; Thu, 6 Feb 2003 14:42:07 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16Jjmq19424 for ; Thu, 6 Feb 2003 13:45:48 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 13:45:42 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 13:45:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 13:45:29 -0600 Message-ID: Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLNiFr1fxAYHa0KSgaFd2T/iMP+mwAjd4Aw To: , , X-OriginalArrivalTime: 06 Feb 2003 19:45:30.0300 (UTC) FILETIME=[4E00AFC0:01C2CE18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16JnEp26080 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Mark and all, It looks we are pretty much in agreement. Due to my bandwidth constraints, I suggest we divide the work as follows: - You guys will go ahead with the example test cases using DAP. - During that process and interop tests, we probably will discover cases where DAP needs to modified/enhanced (e.g. more instructions from sender to receiver). I can then take care of updating DAP with new versions. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 14:59:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02117 for ; Thu, 6 Feb 2003 14:59:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16K6Mw26904 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 15:06:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16K6Mp26901 for ; Thu, 6 Feb 2003 15:06:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02091 for ; Thu, 6 Feb 2003 14:59:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16K69p26868; Thu, 6 Feb 2003 15:06:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16K5Ip26814 for ; Thu, 6 Feb 2003 15:05:18 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02043 for ; Thu, 6 Feb 2003 14:58:11 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16K1gq21235 for ; Thu, 6 Feb 2003 14:01:52 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 14:01:40 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 14:01:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 14:01:40 -0600 Message-ID: Thread-Topic: [rohc] a dummy application protocol (DAP) for SigComp interop Thread-Index: AcLN0sE1XBvrkdDeS4yjJ8kNX5adIwARZMgA To: , , , X-OriginalArrivalTime: 06 Feb 2003 20:01:40.0681 (UTC) FILETIME=[90651390:01C2CE1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16K5Jp26815 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Zacco, It seems you may be confused between a DAP message and its message-body. Just in case, it is the entire DAP message (header + CRLF + [body]) that goes through SigComp layer (both the sending side and the receving side). Detailed answer below. Zhigang > 1. How can endpoint A now if decompression failure occured on > endpoint B? It knows if it doesn't receive the uncompressed message retured from B. Of course, this assumes we don't drop the returned message. > Empty message is not good for this purpose, as it > may be a valid output. For negative tests, it is required to > know somehow. There is no empty DAP message, only DAP message with empty message-body. The message-header is alwasy carried in each DAP message. See above. > 2. When the uncompressed message is sent back with the same > header, what length should I use, the original (compressed) > or the actual (uncompressed) message length? The DAP receiver simply takes whatever is delivered by the local SigComp decompressor, check its format and then return it back without any modifications and without going through the local sigcomp compressor. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 17:30:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06987 for ; Thu, 6 Feb 2003 17:30:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16MbST05072 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 17:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16MbSp05069 for ; Thu, 6 Feb 2003 17:37:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06961 for ; Thu, 6 Feb 2003 17:30:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16MbDp04825; Thu, 6 Feb 2003 17:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16MTap04105 for ; Thu, 6 Feb 2003 17:29:36 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06811 for ; Thu, 6 Feb 2003 17:22:27 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RNLL>; Thu, 6 Feb 2003 22:26:05 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418066367D3@rsys002a.roke.co.uk> From: "West, Mark (ITN)" To: "'zhigang.c.liu@nokia.com'" , "Surtees, Abigail" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Thu, 6 Feb 2003 22:26:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, This seems like an effective use of resources! Glad to see we're converging on an answer... ;-) (And that we definitely have enough to do for the interop) Cheers, Mark. > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: 06 February 2003 19:45 > To: West, Mark (ITN); Surtees, Abigail; rohc@ietf.org > Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp > interop > > > Hi Mark and all, > > It looks we are pretty much in agreement. Due to my > bandwidth constraints, I suggest we divide the work as follows: > > - You guys will go ahead with the example test cases using DAP. > - During that process and interop tests, we probably will > discover cases where DAP needs to modified/enhanced (e.g. more > instructions from sender to receiver). I can then take care of > updating DAP with new versions. > > BR, > Zhigang > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 18:36:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08854 for ; Thu, 6 Feb 2003 18:36:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Ngjf08575 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 18:42:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ngjp08572 for ; Thu, 6 Feb 2003 18:42:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08836 for ; Thu, 6 Feb 2003 18:35:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16NgXp08542; Thu, 6 Feb 2003 18:42:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Nfep08481 for ; Thu, 6 Feb 2003 18:41:40 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08812 for ; Thu, 6 Feb 2003 18:34:29 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16Neim06911 for ; Fri, 7 Feb 2003 01:40:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Feb 2003 01:38:04 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Feb 2003 01:38:03 +0200 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 17:37:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] SigComp Interop Date: Thu, 6 Feb 2003 17:37:40 -0600 Message-ID: Thread-Topic: [rohc] SigComp Interop Thread-Index: AcLGKmKN5H/KoUxqTmqLadIWH7OlswIDa27g To: , X-OriginalArrivalTime: 06 Feb 2003 23:37:41.0252 (UTC) FILETIME=[BD7F4440:01C2CE38] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16Nfep08482 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Richard, A quick question. Does the following mean a sender can assume DMS on the receiving side = 131072? ----------------------------- iii) Long messages (up to 64K over UDP) ------------------------------ Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 6 20:34:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11755 for ; Thu, 6 Feb 2003 20:34:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h171fbj15617 for rohc-archive@odin.ietf.org; Thu, 6 Feb 2003 20:41:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171fbp15614 for ; Thu, 6 Feb 2003 20:41:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11750 for ; Thu, 6 Feb 2003 20:34:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171fOp15598; Thu, 6 Feb 2003 20:41:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171edp15573 for ; Thu, 6 Feb 2003 20:40:39 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11730 for ; Thu, 6 Feb 2003 20:33:24 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h171b4H07186 for ; Thu, 6 Feb 2003 19:37:04 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 19:37:03 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 19:37:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 19:37:03 -0600 Message-ID: Thread-Topic: SigComp state creation request, requested feedback, and SMS = 0 Thread-Index: AcLOSUxT5o1ELzm1EdeaNwAQpIbXLw== To: X-OriginalArrivalTime: 07 Feb 2003 01:37:03.0720 (UTC) FILETIME=[6AA92680:01C2CE49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h171edp15574 Subject: [rohc] SigComp state creation request, requested feedback, and SMS = 0 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, (This is not specified on RFC 3320, so I want to double check.) If a message carries state creation request but the receiving endpoint has SMS = 0, I understand that the message can still be accepted but the state creation request will be rejected. Now, what about the requested feedback carried in the message? Will it be returned? If yes, that means the sender must not rely on feedback to determine if the state has been successfully created. Then, is the answer no? Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 02:27:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00117 for ; Fri, 7 Feb 2003 02:27:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h177YXY13087 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 02:34:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h177YXp13084 for ; Fri, 7 Feb 2003 02:34:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00103 for ; Fri, 7 Feb 2003 02:27:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h177YLp13072; Fri, 7 Feb 2003 02:34:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h177Xlp13041 for ; Fri, 7 Feb 2003 02:33:47 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00086 for ; Fri, 7 Feb 2003 02:26:21 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h177UgXw012750 for ; Fri, 7 Feb 2003 15:30:43 +0800 (SGT) Received: from 827300975.icr.a-star.edu.sg ([172.16.3.126]) by mailer.icr.a-star.edu.sg; Fri, 07 Feb 2003 15:23:38 +0800 Message-Id: <4.3.2.7.2.20030207152415.00e12c40@mailer.icr.a-star.edu.sg> X-Sender: chankm@mailer.icr.a-star.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Feb 2003 15:38:02 +0800 To: From: Chan Kwang Mien In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Query about Returned Feedback Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , hi, According to SigComp user guide, my interpretation is that the receiving endpoint returns the acked_state_id in the "returned feedback item" field of SigComp message. However, when referring to RFC 3321, section 6.1, Figure 5 shows that the acked_state_id is in the "Remaining SigComp message" field. Does it mean that acked_state_id can exist in either location in a SigComp message ? regards, Kwang Mien _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 04:07:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02272 for ; Fri, 7 Feb 2003 04:07:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h179EXX19470 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 04:14:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179EXp19467 for ; Fri, 7 Feb 2003 04:14:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02265 for ; Fri, 7 Feb 2003 04:07:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179EEp19442; Fri, 7 Feb 2003 04:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179D8p19399 for ; Fri, 7 Feb 2003 04:13:08 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02236 for ; Fri, 7 Feb 2003 04:05:46 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1799OKV010209; Fri, 7 Feb 2003 10:09:24 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 7 Feb 2003 10:09:24 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'zhigang.c.liu@nokia.com'" , "Lajos Zaccomer (ETH)" , mark.a.west@roke.co.uk, abigail.surtees@roke.co.uk, rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Fri, 7 Feb 2003 10:07:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, No, I'm not confused about what to send. The fact is that some parts are simply not clear enough. See my inline comments below! BR/Zacco -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: Thursday, February 06, 2003 9:02 PM To: Lajos.Zaccomer@eth.ericsson.se; mark.a.west@roke.co.uk; abigail.surtees@roke.co.uk; rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Hi Zacco, It seems you may be confused between a DAP message and its message-body. Just in case, it is the entire DAP message (header + CRLF + [body]) that goes through SigComp layer (both the sending side and the receving side). Detailed answer below. Zhigang > 1. How can endpoint A now if decompression failure occured on > endpoint B? It knows if it doesn't receive the uncompressed message retured from B. Of course, this assumes we don't drop the returned message. [L.Z.] Explicit notification would be better for testing.We could do it very simply in the verification message that is always sent back. > Empty message is not good for this purpose, as it > may be a valid output. For negative tests, it is required to > know somehow. There is no empty DAP message, only DAP message with empty message-body. The message-header is alwasy carried in each DAP message. See above. [L.Z.] You misunderstood me. I wanted to say: an empty string output of the UDVM did't mean decompression failure. Of course, it didn't. But it's useless to build a timeout mechanism to check decompression failure, when we have the possibility of an explicit notification. Abbie, this explicit notificatrion is nothing to do with NACK, as it is not part of SigComp but DAP. > 2. When the uncompressed message is sent back with the same > header, what length should I use, the original (compressed) > or the actual (uncompressed) message length? The DAP receiver simply takes whatever is delivered by the local SigComp decompressor, check its format and then return it back without any modifications and without going through the local sigcomp compressor. [L.Z.] I asked something else. Abbie had an answer that I already knew: it didn't matter. I expected DAP a simple protocol without having optional things in it. For testing, it would have been favourable. I fear we have to spend long hours with adjusting our DAP versions because of the freedom DAP allows. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 04:39:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03021 for ; Fri, 7 Feb 2003 04:39:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h179kO821227 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 04:46:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179kOp21222 for ; Fri, 7 Feb 2003 04:46:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03008 for ; Fri, 7 Feb 2003 04:39:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179kDp21214; Fri, 7 Feb 2003 04:46:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h179jjp21181 for ; Fri, 7 Feb 2003 04:45:45 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03000 for ; Fri, 7 Feb 2003 04:38:22 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RN6P>; Fri, 7 Feb 2003 09:42:00 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1AD@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp Interop Date: Fri, 7 Feb 2003 09:41:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, In general, the sender should assume that DMS = 2048 unless the receiver specifically agrees to offer more (either by prior agreement, or inband using the SigComp feedback mechanism). For this particular case, it would be useful to test the sender behaviour for both extremes (DMS = 2048 and DMS = 131072). If the receiver offers insufficient memory then the sender should just send the long message uncompressed. Regards, Richard > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Thursday, February 06, 2003 11:38 PM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] SigComp Interop > > > Hi Richard, > > A quick question. Does the following mean a sender can > assume DMS on the receiving side = 131072? > > ----------------------------- > iii) Long messages (up to 64K over UDP) > ------------------------------ > > Zhigang > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 05:11:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03729 for ; Fri, 7 Feb 2003 05:11:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AHuj23023 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 05:17:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AHup23020 for ; Fri, 7 Feb 2003 05:17:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03694 for ; Fri, 7 Feb 2003 05:10:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AHjp22975; Fri, 7 Feb 2003 05:17:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AGfp22927 for ; Fri, 7 Feb 2003 05:16:41 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03670 for ; Fri, 7 Feb 2003 05:09:18 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RN7Y>; Fri, 7 Feb 2003 09:58:55 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1AE@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 09:58:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Hi, > > (This is not specified on RFC 3320, so I want to double check.) > > If a message carries state creation request but the receiving > endpoint has SMS = 0, I understand that the message can still be > accepted but the state creation request will be rejected. Hi Zhigang, That's right - state creation requests can be rejected due to lack of memory, even if the decompressed message is accepted. > Now, what about the requested feedback carried in the message? > Will it be returned? The requested feedback can still be returned even if SMS = 0. > If yes, that means the sender must not rely on feedback to determine > if the state has been successfully created. Then, is the answer no? The sender can still rely on the feedback to determine if the state has been successfully created, but only if it takes into account the returned SigComp parameters as well. In particular it needs to check that the receiver has advertised SMS > 0. SigComp-Extended has the following to say on the subject: Note: There is a possibility that state(S) is discarded due to lack of state memory even though the announcement information is successfully forwarded. This possibility must be taken into account (otherwise a decompression failure may occur); this can be done by using the SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism. The endpoint can use this parameter to infer if a state creation request has failed due to lack of memory. Hope this helps! Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 05:11:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03748 for ; Fri, 7 Feb 2003 05:11:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AIHF23066 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 05:18:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AIGp23063 for ; Fri, 7 Feb 2003 05:18:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03707 for ; Fri, 7 Feb 2003 05:10:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AI1p23050; Fri, 7 Feb 2003 05:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AGdp22918 for ; Fri, 7 Feb 2003 05:16:39 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03667 for ; Fri, 7 Feb 2003 05:09:16 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RN91>; Fri, 7 Feb 2003 10:12:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1AF@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Chan Kwang Mien'" , rohc@ietf.org Subject: RE: [rohc] Query about Returned Feedback Date: Fri, 7 Feb 2003 10:12:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > hi, > > According to SigComp user guide, my interpretation is that > the receiving endpoint returns the acked_state_id > in the "returned feedback item" field of SigComp message. > However, when referring to RFC 3321, section > 6.1, Figure 5 shows that the acked_state_id is in the > "Remaining SigComp message" field. > > Does it mean that acked_state_id can exist in either location > in a SigComp message ? Hi Kwang Mien, That's exactly right - the acked_state_id can be carried either in the "returned feedback item", or in the main body of the SigComp message. Where the acked_state_id goes is chosen by the bytecode that is uploaded to the UDVM. The SigComp User Guide contains bytecode to implement both cases (see Section 6.1 and Section 6.5 for more details). Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 05:17:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03854 for ; Fri, 7 Feb 2003 05:17:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AOFX23260 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 05:24:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AOFp23257 for ; Fri, 7 Feb 2003 05:24:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03834 for ; Fri, 7 Feb 2003 05:16:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AO2p23242; Fri, 7 Feb 2003 05:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17ANHp23206 for ; Fri, 7 Feb 2003 05:23:17 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03816 for ; Fri, 7 Feb 2003 05:15:53 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17AJVAv002846; Fri, 7 Feb 2003 11:19:31 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 7 Feb 2003 11:19:31 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Price, Richard'" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 11:17:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, This may help, but sending the returned parameters is not mandatory, moreover not recommended! BR/Zacco -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Friday, February 07, 2003 10:59 AM To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 > Hi, > > (This is not specified on RFC 3320, so I want to double check.) > > If a message carries state creation request but the receiving > endpoint has SMS = 0, I understand that the message can still be > accepted but the state creation request will be rejected. Hi Zhigang, That's right - state creation requests can be rejected due to lack of memory, even if the decompressed message is accepted. > Now, what about the requested feedback carried in the message? > Will it be returned? The requested feedback can still be returned even if SMS = 0. > If yes, that means the sender must not rely on feedback to determine > if the state has been successfully created. Then, is the answer no? The sender can still rely on the feedback to determine if the state has been successfully created, but only if it takes into account the returned SigComp parameters as well. In particular it needs to check that the receiver has advertised SMS > 0. SigComp-Extended has the following to say on the subject: Note: There is a possibility that state(S) is discarded due to lack of state memory even though the announcement information is successfully forwarded. This possibility must be taken into account (otherwise a decompression failure may occur); this can be done by using the SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism. The endpoint can use this parameter to infer if a state creation request has failed due to lack of memory. Hope this helps! Regards, Richard _______________________________________________ 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 mailnull@www1.ietf.org Fri Feb 7 05:49:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04572 for ; Fri, 7 Feb 2003 05:49:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17AuL025036 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 05:56:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AuLp25033 for ; Fri, 7 Feb 2003 05:56:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04567 for ; Fri, 7 Feb 2003 05:48:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AuAp25019; Fri, 7 Feb 2003 05:56:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17AtDp24981 for ; Fri, 7 Feb 2003 05:55:13 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04537 for ; Fri, 7 Feb 2003 05:47:49 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R3BM>; Fri, 7 Feb 2003 10:51:27 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1B0@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lajos Zaccomer (ETH)'" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 10:51:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, It's an implementation decision at the receiver whether to announce that SMS > 0 or not. Note however that if the receiver chooses not to do this, then the sender MUST assume that SMS = 0 (in other words it has to assume that the receiver can't save state). Regards, Richard > -----Original Message----- > From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se] > Sent: Friday, February 07, 2003 10:18 AM > To: Price, Richard; 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, > a nd SMS = 0 > > > Hi, > > This may help, but sending the returned parameters is not > mandatory, moreover not recommended! > > BR/Zacco > > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, February 07, 2003 10:59 AM > To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, a nd SMS = 0 > > > > Hi, > > > > (This is not specified on RFC 3320, so I want to double check.) > > > > If a message carries state creation request but the receiving > > endpoint has SMS = 0, I understand that the message can still be > > accepted but the state creation request will be rejected. > > Hi Zhigang, > > That's right - state creation requests can be rejected due to lack > of memory, even if the decompressed message is accepted. > > > Now, what about the requested feedback carried in the message? > > Will it be returned? > > The requested feedback can still be returned even if SMS = 0. > > > If yes, that means the sender must not rely on feedback to determine > > if the state has been successfully created. Then, is the answer no? > > The sender can still rely on the feedback to determine if the state > has been successfully created, but only if it takes into account the > returned SigComp parameters as well. In particular it needs to check > that the receiver has advertised SMS > 0. > > SigComp-Extended has the following to say on the subject: > > Note: There is a possibility that state(S) is discarded due to lack > of state memory even though the announcement information is > successfully forwarded. This possibility must be taken into account > (otherwise a decompression failure may occur); this can be done by > using the SigComp parameter state_memory_size which is announced by > the SigComp feedback mechanism. The endpoint can use this parameter > to infer if a state creation request has failed due to lack of > memory. > > Hope this helps! > > Regards, > > Richard > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Feb 7 06:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04981 for ; Fri, 7 Feb 2003 06:07:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17BEKP26393 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 06:14:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BEKp26390 for ; Fri, 7 Feb 2003 06:14:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04966 for ; Fri, 7 Feb 2003 06:06:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BE8p26377; Fri, 7 Feb 2003 06:14:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BDqp26355 for ; Fri, 7 Feb 2003 06:13:52 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04956 for ; Fri, 7 Feb 2003 06:06:27 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17BA6KV016409; Fri, 7 Feb 2003 12:10:06 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 7 Feb 2003 12:10:06 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Price, Richard'" , "Lajos Zaccomer (ETH)" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 12:07:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I am aware of this, but I think it is worth to indicate there may be potential problems or low compression efficiency issues because of this. Think of what happens if B does not send the returned parameters: A has to send the bytecode in every message. In such a situation B proves to perform better than than A, unless A is brave enough not to send the bytecode again. Anyway, the RFC does not mandate that "it has to assume that the receiver can't save state." (As far as I can remember, it is not even recommended.) It may be logical, but in situations when every byte spared is a success, the temptation is great to make "reckless" implementations that do not care of such things. Assumptions amongst "friend" softwares work well, which may pave the way before these, handicapping others. BR/Zacco -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Friday, February 07, 2003 11:51 AM To: 'Lajos Zaccomer (ETH)'; 'zhigang.c.liu@nokia.com'; rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Hi Zacco, It's an implementation decision at the receiver whether to announce that SMS > 0 or not. Note however that if the receiver chooses not to do this, then the sender MUST assume that SMS = 0 (in other words it has to assume that the receiver can't save state). Regards, Richard > -----Original Message----- > From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se] > Sent: Friday, February 07, 2003 10:18 AM > To: Price, Richard; 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, > a nd SMS = 0 > > > Hi, > > This may help, but sending the returned parameters is not > mandatory, moreover not recommended! > > BR/Zacco > > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, February 07, 2003 10:59 AM > To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, a nd SMS = 0 > > > > Hi, > > > > (This is not specified on RFC 3320, so I want to double check.) > > > > If a message carries state creation request but the receiving > > endpoint has SMS = 0, I understand that the message can still be > > accepted but the state creation request will be rejected. > > Hi Zhigang, > > That's right - state creation requests can be rejected due to lack > of memory, even if the decompressed message is accepted. > > > Now, what about the requested feedback carried in the message? > > Will it be returned? > > The requested feedback can still be returned even if SMS = 0. > > > If yes, that means the sender must not rely on feedback to determine > > if the state has been successfully created. Then, is the answer no? > > The sender can still rely on the feedback to determine if the state > has been successfully created, but only if it takes into account the > returned SigComp parameters as well. In particular it needs to check > that the receiver has advertised SMS > 0. > > SigComp-Extended has the following to say on the subject: > > Note: There is a possibility that state(S) is discarded due to lack > of state memory even though the announcement information is > successfully forwarded. This possibility must be taken into account > (otherwise a decompression failure may occur); this can be done by > using the SigComp parameter state_memory_size which is announced by > the SigComp feedback mechanism. The endpoint can use this parameter > to infer if a state creation request has failed due to lack of > memory. > > Hope this helps! > > Regards, > > Richard > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Feb 7 06:26:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05400 for ; Fri, 7 Feb 2003 06:26:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17BXOZ27023 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 06:33:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BXOp27020 for ; Fri, 7 Feb 2003 06:33:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05388 for ; Fri, 7 Feb 2003 06:25:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BXDp26976; Fri, 7 Feb 2003 06:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17BWXp26929 for ; Fri, 7 Feb 2003 06:32:33 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05373 for ; Fri, 7 Feb 2003 06:25:06 -0500 (EST) Received: from EEB174W2Kvk (unverified [157.190.81.172]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Fri, 7 Feb 2003 11:17:38 +0000 Reply-To: From: "Valerie Kenneally" To: Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 11:28:58 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I am trying to understand the feedback mechanism provided by SIGCOMP. My question is based on what happens if a remote endpoint receives a message which it cannot decompress for whatever reason so we have a DECOMPRESSION FAILURE. Can the remote end-point notify the sending end-point that decompression has failed. The reason I ask this is that the RFC states that feedback is piggybacked onto a Sigcomp message. I don't know if I am completely misunderstanding the format of a Sigcomp message but should it not always contain a compressed message. If a DECOMPRESSION FAILURE occurs a follow-up message/response cannot be sent. So can a Sigcomp message be sent for the sole purpose of DECOMPRESSION FAILURE notification without being accompanied by a compressed message? Any help at all would be greatly appreciated Regards, Val -----Original Message----- From: rohc-admin@ietf.org [mailto:rohc-admin@ietf.org]On Behalf Of Lajos Zaccomer (ETH) Sent: 07 February 2003 11:08 To: 'Price, Richard'; Lajos Zaccomer (ETH); 'zhigang.c.liu@nokia.com'; rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Hi, I am aware of this, but I think it is worth to indicate there may be potential problems or low compression efficiency issues because of this. Think of what happens if B does not send the returned parameters: A has to send the bytecode in every message. In such a situation B proves to perform better than than A, unless A is brave enough not to send the bytecode again. Anyway, the RFC does not mandate that "it has to assume that the receiver can't save state." (As far as I can remember, it is not even recommended.) It may be logical, but in situations when every byte spared is a success, the temptation is great to make "reckless" implementations that do not care of such things. Assumptions amongst "friend" softwares work well, which may pave the way before these, handicapping others. BR/Zacco -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Friday, February 07, 2003 11:51 AM To: 'Lajos Zaccomer (ETH)'; 'zhigang.c.liu@nokia.com'; rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Hi Zacco, It's an implementation decision at the receiver whether to announce that SMS > 0 or not. Note however that if the receiver chooses not to do this, then the sender MUST assume that SMS = 0 (in other words it has to assume that the receiver can't save state). Regards, Richard > -----Original Message----- > From: Lajos Zaccomer (ETH) [mailto:Lajos.Zaccomer@eth.ericsson.se] > Sent: Friday, February 07, 2003 10:18 AM > To: Price, Richard; 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, > a nd SMS = 0 > > > Hi, > > This may help, but sending the returned parameters is not > mandatory, moreover not recommended! > > BR/Zacco > > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, February 07, 2003 10:59 AM > To: 'zhigang.c.liu@nokia.com'; rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, a nd SMS = 0 > > > > Hi, > > > > (This is not specified on RFC 3320, so I want to double check.) > > > > If a message carries state creation request but the receiving > > endpoint has SMS = 0, I understand that the message can still be > > accepted but the state creation request will be rejected. > > Hi Zhigang, > > That's right - state creation requests can be rejected due to lack > of memory, even if the decompressed message is accepted. > > > Now, what about the requested feedback carried in the message? > > Will it be returned? > > The requested feedback can still be returned even if SMS = 0. > > > If yes, that means the sender must not rely on feedback to determine > > if the state has been successfully created. Then, is the answer no? > > The sender can still rely on the feedback to determine if the state > has been successfully created, but only if it takes into account the > returned SigComp parameters as well. In particular it needs to check > that the receiver has advertised SMS > 0. > > SigComp-Extended has the following to say on the subject: > > Note: There is a possibility that state(S) is discarded due to lack > of state memory even though the announcement information is > successfully forwarded. This possibility must be taken into account > (otherwise a decompression failure may occur); this can be done by > using the SigComp parameter state_memory_size which is announced by > the SigComp feedback mechanism. The endpoint can use this parameter > to infer if a state creation request has failed due to lack of > memory. > > Hope this helps! > > Regards, > > Richard > _______________________________________________ > 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 -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------- ------------ -------------------Legal Disclaimer--------------------------------------- The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt. ---------------------------------------------------------------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 07:30:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06901 for ; Fri, 7 Feb 2003 07:30:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17CbVs31214 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 07:37:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17CbVp31211 for ; Fri, 7 Feb 2003 07:37:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06896 for ; Fri, 7 Feb 2003 07:30:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17CbFp31009; Fri, 7 Feb 2003 07:37:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Cahp30541 for ; Fri, 7 Feb 2003 07:36:43 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06872 for ; Fri, 7 Feb 2003 07:29:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R3JC>; Fri, 7 Feb 2003 12:32:54 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1B1@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lajos Zaccomer (ETH)'" , "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 12:32:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Hi, > > I am aware of this, but I think it is worth to indicate there > may be potential problems or low compression efficiency > issues because of this. Think of what happens if B does not > send the returned parameters: A has to send the bytecode in > every message. In such a situation B proves to perform better > than than A, unless A is brave enough not to send the bytecode again. Hi Zacco, It's worth pointing out that getting a good compression ratio is the responsibility of both the sender and the receiver. Thus, if the compression ratio is worse in the direction A -> B than in the direction B -> A, it's wrong to claim that B is performing better than A. It might be B's fault that the compression ratio is low. > Anyway, the RFC does not mandate that "it has to assume that > the receiver can't save state." (As far as I can remember, it > is not even recommended.) In fact, from Section 5 of RFC 3320: "The compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint." If the compressor assumes that the receiver can save state without first checking that SMS > 0, then it's broken! > It may be logical, but in situations when every byte spared > is a success, the temptation is great to make "reckless" > implementations that do not care of such things. Assumptions > amongst "friend" softwares work well, which may pave the way > before these, handicapping others. I agree completely with the above - the temptation is great to cut corners just to save a few bytes. The result is an implementation that only interoperates with "friendly" software, which is a Bad Thing! We took care to specifically ban this kind of behaviour in RFC 3320. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 07:43:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07257 for ; Fri, 7 Feb 2003 07:43:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17CoJf31746 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 07:50:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17CoIp31743 for ; Fri, 7 Feb 2003 07:50:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07237 for ; Fri, 7 Feb 2003 07:42:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Co7p31720; Fri, 7 Feb 2003 07:50:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17Cnwp31687 for ; Fri, 7 Feb 2003 07:49:58 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07222 for ; Fri, 7 Feb 2003 07:42:30 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R3K1>; Fri, 7 Feb 2003 12:46:09 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B88639@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'Lajos Zaccomer (ETH)'" , "'zhigang.c.liu@nokia.com'" , "West, Mark (ITN)" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Fri, 7 Feb 2003 12:46:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, Comments in-line (hopefully we're not getting too indented). Best regards, Abbie >> 1. How can endpoint A now if decompression failure occured on >> endpoint B? > >It knows if it doesn't receive the uncompressed message retured >from B. Of course, this assumes we don't drop the returned message. > >[L.Z.] Explicit notification would be better for testing.We >could do it very simply in the verification message that is >always sent back. > >> Empty message is not good for this purpose, as it >> may be a valid output. For negative tests, it is required to >> know somehow. > >There is no empty DAP message, only DAP message with empty >message-body. The message-header is alwasy carried in each DAP message. >See above. > >[L.Z.] You misunderstood me. I wanted to say: an empty string >output of the UDVM did't mean decompression failure. Of >course, it didn't. But it's useless to build a timeout >mechanism to check decompression failure, when we have the >possibility of an explicit notification. Abbie, this explicit >notificatrion is nothing to do with NACK, as it is not part of >SigComp but DAP. > [A.S.] I think we are getting confused between empty messages and DECOMPRESSION_FAILURES occurring in the torture tests and those occurring during interoperation between 2 endpoints. In the first case we are not using DAP and these occurrences are either expected (in which case it's fine) or they're not (in which case the implementer has something to debug). In the second case (which is where we will be at SIPit) there are, as Zhigang said, no empty messages because there will always be a DAP header and if there is DECOMPRESSION_FAILURE then (assuming no dropped packets) there is a bug at one endpoint or the other, at which point both implementers need to look at their log files and work out what has gone wrong. From my experience at 3095 interop tests I would say that endpoint A doesn't need to be told there has been a DECOMPRESSION_FAILURE. I would expect that the decompressing endpoint would flag up a DECOMPRESSION_FAILURE to the implementer either in an on-screen message or in a log file. If it's the former then the implementer will spot it and the test can be stopped and debugged or if it's the latter then test may go slightly awry but this will be noted by one end or the other and it can be debugged. As both implementers will be present there can be discussions rather than requiring one endpoint to indicate everything to the other. >> 2. When the uncompressed message is sent back with the same >> header, what length should I use, the original (compressed) >> or the actual (uncompressed) message length? > >The DAP receiver simply takes whatever is delivered by the local >SigComp decompressor, check its format and then return it back >without any modifications and without going through the local >sigcomp compressor. > >[L.Z.] I asked something else. Abbie had an answer that I >already knew: it didn't matter. I expected DAP a simple >protocol without having optional things in it. For testing, it >would have been favourable. I fear we have to spend long hours >with adjusting our DAP versions because of the freedom DAP allows. > [A.S.] I'm not sure I understand the question. There aren't any options in DAP. The length is always the uncompressed length because the DAP header is part of what gets compressed (in the sending direction) and the message is just returned "as is" in the uncompressed direction. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 08:05:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08487 for ; Fri, 7 Feb 2003 08:05:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17DCPp01807 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 08:12:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DCPp01804 for ; Fri, 7 Feb 2003 08:12:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08466 for ; Fri, 7 Feb 2003 08:04:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DC8p01788; Fri, 7 Feb 2003 08:12:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DBgp01765 for ; Fri, 7 Feb 2003 08:11:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08458 for ; Fri, 7 Feb 2003 08:04:14 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h17D7qAw016536; Fri, 7 Feb 2003 14:07:53 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 7 Feb 2003 14:07:52 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'Surtees, Abigail'" , "Lajos Zaccomer (ETH)" , "'zhigang.c.liu@nokia.com'" , "West, Mark (ITN)" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Fri, 7 Feb 2003 14:05:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Regarding decomp failure: In negative tests I may send such messages _on purpose_. This is the case in several of the torture tests. For automatic test suits that can be run without any user intervention, it is essential to have all the information to set verdict without having a look at the other implementation's log file or consulting its owner. Regarding length I quote what you wrote: "As there is no new DAP header being added there is no need to worry about what length to give it." I don't think that "The length is always the uncompressed length" especially when sending the compressed message. I guess you did not mean this. BR/Zacco -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: Friday, February 07, 2003 1:46 PM To: 'Lajos Zaccomer (ETH)'; 'zhigang.c.liu@nokia.com'; West, Mark (ITN); rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Hi Zacco, Comments in-line (hopefully we're not getting too indented). Best regards, Abbie >> 1. How can endpoint A now if decompression failure occured on >> endpoint B? > >It knows if it doesn't receive the uncompressed message retured >from B. Of course, this assumes we don't drop the returned message. > >[L.Z.] Explicit notification would be better for testing.We >could do it very simply in the verification message that is >always sent back. > >> Empty message is not good for this purpose, as it >> may be a valid output. For negative tests, it is required to >> know somehow. > >There is no empty DAP message, only DAP message with empty >message-body. The message-header is alwasy carried in each DAP message. >See above. > >[L.Z.] You misunderstood me. I wanted to say: an empty string >output of the UDVM did't mean decompression failure. Of >course, it didn't. But it's useless to build a timeout >mechanism to check decompression failure, when we have the >possibility of an explicit notification. Abbie, this explicit >notificatrion is nothing to do with NACK, as it is not part of >SigComp but DAP. > [A.S.] I think we are getting confused between empty messages and DECOMPRESSION_FAILURES occurring in the torture tests and those occurring during interoperation between 2 endpoints. In the first case we are not using DAP and these occurrences are either expected (in which case it's fine) or they're not (in which case the implementer has something to debug). In the second case (which is where we will be at SIPit) there are, as Zhigang said, no empty messages because there will always be a DAP header and if there is DECOMPRESSION_FAILURE then (assuming no dropped packets) there is a bug at one endpoint or the other, at which point both implementers need to look at their log files and work out what has gone wrong. From my experience at 3095 interop tests I would say that endpoint A doesn't need to be told there has been a DECOMPRESSION_FAILURE. I would expect that the decompressing endpoint would flag up a DECOMPRESSION_FAILURE to the implementer either in an on-screen message or in a log file. If it's the former then the implementer will spot it and the test can be stopped and debugged or if it's the latter then test may go slightly awry but this will be noted by one end or the other and it can be debugged. As both implementers will be present there can be discussions rather than requiring one endpoint to indicate everything to the other. >> 2. When the uncompressed message is sent back with the same >> header, what length should I use, the original (compressed) >> or the actual (uncompressed) message length? > >The DAP receiver simply takes whatever is delivered by the local >SigComp decompressor, check its format and then return it back >without any modifications and without going through the local >sigcomp compressor. > >[L.Z.] I asked something else. Abbie had an answer that I >already knew: it didn't matter. I expected DAP a simple >protocol without having optional things in it. For testing, it >would have been favourable. I fear we have to spend long hours >with adjusting our DAP versions because of the freedom DAP allows. > [A.S.] I'm not sure I understand the question. There aren't any options in DAP. The length is always the uncompressed length because the DAP header is part of what gets compressed (in the sending direction) and the message is just returned "as is" in the uncompressed direction. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 08:22:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09678 for ; Fri, 7 Feb 2003 08:22:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17DTc002706 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 08:29:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DTcp02703 for ; Fri, 7 Feb 2003 08:29:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09661 for ; Fri, 7 Feb 2003 08:22:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DTAp02627; Fri, 7 Feb 2003 08:29:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DSlp02445 for ; Fri, 7 Feb 2003 08:28:47 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09640 for ; Fri, 7 Feb 2003 08:21:19 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R3MJ>; Fri, 7 Feb 2003 13:24:58 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1B3@rsys002a.roke.co.uk> From: "Price, Richard" To: "'vkenneally@cit.ie'" , rohc@ietf.org Subject: RE: [rohc] SigComp state creation request, requested feedback, a nd SMS = 0 Date: Fri, 7 Feb 2003 13:24:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Val, Basic SigComp (RFC 3320) doesn't have the ability to notify the remote endpoint when decompression failure has occurred. The reason for this is simply that if a SigComp message fails to decompress, how can we work out which remote endpoint sent it? We can't successfully decompress the "From:" header, so we don't know where to send the feedback. In some cases it might be possible to work around this problem by using the IP address and port - a proposal to do this can be found in: http://www.ietf.org/internet-drafts/draft-roach-sigcomp-nack-00.txt However, we haven't got around to standardising the above mechanism just yet... Regards, Richard > -----Original Message----- > From: Valerie Kenneally [mailto:vkenneally@cit.ie] > Sent: Friday, February 07, 2003 11:29 AM > To: rohc@ietf.org > Subject: RE: [rohc] SigComp state creation request, requested > feedback, > a nd SMS = 0 > > > Hi all, > > I am trying to understand the feedback mechanism provided by SIGCOMP. My > question is based on what happens if a remote endpoint receives a message > which it cannot decompress for whatever reason so we have a DECOMPRESSION > FAILURE. > > Can the remote end-point notify the sending end-point that decompression has > failed. The reason I ask this is that the RFC states that feedback is > piggybacked onto a Sigcomp message. > > I don't know if I am completely misunderstanding the format of a Sigcomp > message but should it not always contain a compressed message. If a > DECOMPRESSION FAILURE occurs a follow-up message/response cannot be sent. > So can a Sigcomp message be sent for the sole purpose of DECOMPRESSION > FAILURE notification without being accompanied by a compressed message? > > > Any help at all would be greatly appreciated > Regards, > Val _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 08:38:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10711 for ; Fri, 7 Feb 2003 08:38:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17DjXY04362 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 08:45:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DjXp04359 for ; Fri, 7 Feb 2003 08:45:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10687 for ; Fri, 7 Feb 2003 08:38:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DjEp04315; Fri, 7 Feb 2003 08:45:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17DiYp04256 for ; Fri, 7 Feb 2003 08:44:34 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10612 for ; Fri, 7 Feb 2003 08:37:05 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R3NZ>; Fri, 7 Feb 2003 13:40:43 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804B8863C@rsys002a.roke.co.uk> From: "Surtees, Abigail" To: "'Lajos Zaccomer (ETH)'" , "'zhigang.c.liu@nokia.com'" , "West, Mark (ITN)" , rohc@ietf.org Subject: RE: [rohc] a dummy application protocol (DAP) for SigComp interop Date: Fri, 7 Feb 2003 13:40:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zacco, >Regarding decomp failure: > >In negative tests I may send such messages _on purpose_. This >is the case in several of the torture tests. For automatic >test suits that can be run without any user intervention, it >is essential to have all the information to set verdict >without having a look at the other implementation's log file >or consulting its owner. I agree that the torture tests can quite legitimately produce decompression failure. However, these don't run with DAP, they are stand alone messages. When we are running with DAP (assuming no corruption or packet loss) there shouldn't be any decompression failure. Why do we need to run without any intervention? The implementers are all going to be at SIPit. As we said before, we can extend DAP in the future if we want to, but we have enough for the interop tests which are fast approaching, so we should freeze DAP in order to implement it. > >Regarding length I quote what you wrote: > >"As there is no new DAP header being added there is no need to >worry about what length to give it." >I don't think that "The length is always the uncompressed >length" especially when sending the compressed message. I >guess you did not mean this. > I'm afraid I still don't understand the question you are asking. The diagram below shows how I see things working (correct me if I'm wrong) and there is know need to know about the length to give the returned uncompressed header. (I am assuming that endpoint A has a body_msg of length x already known from somewhere (e.g. file)) Endpoint A overall msg overall length <----x-------> |body_msg | x DAP layer: adds a DAP header (length y) with line 8: "body-length: x" <--y--><-------x---> |DAP |body_msg | x + y Sigcomp layer: compresses (x+y) bytes to z bytes <------z----> |Sigcomp msg| z z bytes are sent to endpoint B. endpoint B: <------z----> |Sigcomp msg| z Sigcomp layer: decompresses z bytes to (x + y) bytes <--y--><-------x---> |DAP |body_msg | x + y DAP layer: reads and verifies DAP header (length y) with line 8: "body-length: x" returns the (x + y) bytes it received uncompressed to endpoint A. <--y--><-------x---> |DAP |body_msg | x + y Endpoint A receives the original message it compressed. Nowhere has the receiving endpoint had to fill in a length value. Hence my not understanding the question. There is nothing optional in DAP. Best regards, Abbie _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 7 12:24:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16060 for ; Fri, 7 Feb 2003 12:24:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17HVRk17408 for rohc-archive@odin.ietf.org; Fri, 7 Feb 2003 12:31:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17HVRp17405 for ; Fri, 7 Feb 2003 12:31:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16054 for ; Fri, 7 Feb 2003 12:23:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17HVFp17393; Fri, 7 Feb 2003 12:31:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17HUZp17358 for ; Fri, 7 Feb 2003 12:30:35 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16020 for ; Fri, 7 Feb 2003 12:23:02 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h17HQgH05949 for ; Fri, 7 Feb 2003 11:26:42 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Feb 2003 11:26:38 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Feb 2003 11:24:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] SigComp Interop Date: Fri, 7 Feb 2003 11:24:53 -0600 Message-ID: Thread-Topic: [rohc] SigComp Interop Thread-Index: AcLOjUOfct81pqzYSS2HdDPZUpSWmgAQBe6w To: , X-OriginalArrivalTime: 07 Feb 2003 17:24:54.0035 (UTC) FILETIME=[D4028E30:01C2CECD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h17HUdp17360 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit So, the answer is that just for this test case, the sender can assume the receiver support DMS = 131072? Zhigang > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: February 07, 2003 3:42 AM > To: Liu Zhigang.C (NRC/Dallas); rohc@ietf.org > Subject: RE: [rohc] SigComp Interop > > > Hi Zhigang, > > In general, the sender should assume that DMS = 2048 unless > the receiver specifically agrees to offer more (either by > prior agreement, or inband using the SigComp feedback mechanism). > > For this particular case, it would be useful to test the > sender behaviour for both extremes (DMS = 2048 and DMS = 131072). > If the receiver offers insufficient memory then the sender > should just send the long message uncompressed. > > Regards, > > Richard > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Thursday, February 06, 2003 11:38 PM > > To: Price, Richard; rohc@ietf.org > > Subject: RE: [rohc] SigComp Interop > > > > > > Hi Richard, > > > > A quick question. Does the following mean a sender can > > assume DMS on the receiving side = 131072? > > > > ----------------------------- > > iii) Long messages (up to 64K over UDP) > > ------------------------------ > > > > Zhigang > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Feb 9 22:12:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13245 for ; Sun, 9 Feb 2003 22:12:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A3Kun05337 for rohc-archive@odin.ietf.org; Sun, 9 Feb 2003 22:20:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3Kup05334 for ; Sun, 9 Feb 2003 22:20:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13229 for ; Sun, 9 Feb 2003 22:12:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3Kdp05324; Sun, 9 Feb 2003 22:20:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A3JIp05263 for ; Sun, 9 Feb 2003 22:19:18 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13184 for ; Sun, 9 Feb 2003 22:10:29 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h1A3EtXw003103 for ; Mon, 10 Feb 2003 11:14:55 +0800 (SGT) Received: from 827300975.icr.a-star.edu.sg ([172.16.3.126]) by mailer.icr.a-star.edu.sg; Mon, 10 Feb 2003 11:07:51 +0800 Message-Id: <4.3.2.7.2.20030210111137.00df95e0@mailer.icr.a-star.edu.sg> X-Sender: chankm@mailer.icr.a-star.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Feb 2003 11:28:05 +0800 To: "Price, Richard" , rohc@ietf.org From: Chan Kwang Mien Subject: RE: [rohc] Query about Returned Feedback In-Reply-To: <76C92FBBFB58D411AE760090271ED41804A0F1AF@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , hi Richard, Can the shared_state_id also be included in the "returned feedback item" field ? for e.g A sends a compressed message to B. B decompresses and saves the state. In the next SigComp message to B, A includes the shared_state_id of the previous message in the "returned feedback item" field. i have the impression that the "returned feedback item" field should only contain items requested by the other remote host. is that true ? regards, Kwang Mien > > hi, > > > > According to SigComp user guide, my interpretation is that > > the receiving endpoint returns the acked_state_id > > in the "returned feedback item" field of SigComp message. > > However, when referring to RFC 3321, section > > 6.1, Figure 5 shows that the acked_state_id is in the > > "Remaining SigComp message" field. > > > > Does it mean that acked_state_id can exist in either location > > in a SigComp message ? > >Hi Kwang Mien, > >That's exactly right - the acked_state_id can be carried either >in the "returned feedback item", or in the main body of the >SigComp message. Where the acked_state_id goes is chosen by the >bytecode that is uploaded to the UDVM. > >The SigComp User Guide contains bytecode to implement both >cases (see Section 6.1 and Section 6.5 for more details). > >Regards, > >Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 10 12:19:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16447 for ; Mon, 10 Feb 2003 12:19:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHRXD29653 for rohc-archive@odin.ietf.org; Mon, 10 Feb 2003 12:27:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHRXp29650 for ; Mon, 10 Feb 2003 12:27:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16411 for ; Mon, 10 Feb 2003 12:18:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHRIp29569; Mon, 10 Feb 2003 12:27:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHI3p29186 for ; Mon, 10 Feb 2003 12:18:03 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15999 for ; Mon, 10 Feb 2003 12:09:02 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RRQQ>; Mon, 10 Feb 2003 17:12:43 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1B4@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , rohc@ietf.org Subject: RE: [rohc] SigComp Interop Date: Mon, 10 Feb 2003 17:12:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Zhigang, If possible I'd like to test both cases. Firstly, the receiver should offer DMS = 131072 and the sender should compress the long message using as much memory as it likes. Secondly, the receiver should offer DMS = 2048 to see what happens. If the sender is implemented correctly then decompression failure won't occur (if the sender can't compress the long message with DMS = 2048 then it should just send it uncompressed). Regards, Richard > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Friday, February 07, 2003 5:25 PM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] SigComp Interop > > > So, the answer is that just for this test case, the sender > can assume the receiver support DMS = 131072? > > Zhigang > > > -----Original Message----- > > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: February 07, 2003 3:42 AM > > To: Liu Zhigang.C (NRC/Dallas); rohc@ietf.org > > Subject: RE: [rohc] SigComp Interop > > > > > > Hi Zhigang, > > > > In general, the sender should assume that DMS = 2048 unless > > the receiver specifically agrees to offer more (either by > > prior agreement, or inband using the SigComp feedback mechanism). > > > > For this particular case, it would be useful to test the > > sender behaviour for both extremes (DMS = 2048 and DMS = 131072). > > If the receiver offers insufficient memory then the sender > > should just send the long message uncompressed. > > > > Regards, > > > > Richard > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: Thursday, February 06, 2003 11:38 PM > > > To: Price, Richard; rohc@ietf.org > > > Subject: RE: [rohc] SigComp Interop > > > > > > > > > Hi Richard, > > > > > > A quick question. Does the following mean a sender can > > > assume DMS on the receiving side = 131072? > > > > > > ----------------------------- > > > iii) Long messages (up to 64K over UDP) > > > ------------------------------ > > > > > > Zhigang > > > > > > > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 10 12:27:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17098 for ; Mon, 10 Feb 2003 12:27:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHaMH30116 for rohc-archive@odin.ietf.org; Mon, 10 Feb 2003 12:36:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHaMp30113 for ; Mon, 10 Feb 2003 12:36:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17071 for ; Mon, 10 Feb 2003 12:27:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHa7p30096; Mon, 10 Feb 2003 12:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHZep30057 for ; Mon, 10 Feb 2003 12:35:40 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17056 for ; Mon, 10 Feb 2003 12:26:38 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RRSD>; Mon, 10 Feb 2003 17:30:20 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1B5@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Chan Kwang Mien'" , rohc@ietf.org Subject: RE: [rohc] Query about Returned Feedback Date: Mon, 10 Feb 2003 17:30:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Kwang Mien, The "returned feedback item" field sent in the direction A -> B is controlled by the endpoint B. So it will contain the shared_state_id if and only if endpoint B requests that this should be the case (by sending the appropriate bytecode to endpoint A). Endpoint A must do exactly what B tells it, so it MUST NOT include the shared_state_id unless B asks it to. Regards, Richard > -----Original Message----- > From: Chan Kwang Mien [mailto:chankm@icr.a-star.edu.sg] > Sent: Monday, February 10, 2003 3:28 AM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] Query about Returned Feedback > > > > hi Richard, > > Can the shared_state_id also be included in the "returned feedback item" > field ? for e.g A sends a compressed message to B. B decompresses > and saves the state. In the next SigComp message to B, A includes the > shared_state_id of the previous message in the "returned feedback item" > field. > > i have the impression that the "returned feedback item" field should only > contain items requested by the other remote host. is that true ? > > regards, > Kwang Mien _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 10 12:39:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17485 for ; Mon, 10 Feb 2003 12:39:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1AHmOK31369 for rohc-archive@odin.ietf.org; Mon, 10 Feb 2003 12:48:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHmNp31366 for ; Mon, 10 Feb 2003 12:48:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17474 for ; Mon, 10 Feb 2003 12:39:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHm8p31341; Mon, 10 Feb 2003 12:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1AHl1p31305 for ; Mon, 10 Feb 2003 12:47:01 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17454 for ; Mon, 10 Feb 2003 12:37:59 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1AHfgO20199 for ; Mon, 10 Feb 2003 11:41:42 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 11:41:37 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Feb 2003 11:41:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] SigComp Interop Date: Mon, 10 Feb 2003 11:41:35 -0600 Message-ID: Thread-Topic: [rohc] SigComp Interop Thread-Index: AcLRJ69A0oz4vEURSc67cYDEQGBqawAAe4PQ To: , X-OriginalArrivalTime: 10 Feb 2003 17:41:35.0672 (UTC) FILETIME=[A8457B80:01C2D12B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1AHl1p31306 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Secondly, the receiver should offer DMS = 2048 to see what > happens. If the sender is implemented correctly then > decompression failure won't occur (if the sender can't compress > the long message with DMS = 2048 then it should just send it > uncompressed). I don't think sender can ever compress a 64KB message, unless it can compress it down to something like 1KB. By definition, part of DMS is used to buffer the compressed message. So, basically if the receiver does not advertise any DMS, this test is to check if the sender is "smart" enough to send the message uncompressed. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 11 01:17:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10594 for ; Tue, 11 Feb 2003 01:17:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B6PtT10798 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 01:25:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6Ptp10795 for ; Tue, 11 Feb 2003 01:25:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10558 for ; Tue, 11 Feb 2003 01:16:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6PQp10782; Tue, 11 Feb 2003 01:25:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6Ovp10759 for ; Tue, 11 Feb 2003 01:24:57 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10537 for ; Tue, 11 Feb 2003 01:15:38 -0500 (EST) From: alreddy@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h1B5n8a12622 for ; Tue, 11 Feb 2003 11:19:09 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CCA.00223882 ; Tue, 11 Feb 2003 11:43:46 +0530 X-Lotus-FromDomain: HSSBLR To: rohc@ietf.org Message-ID: <65256CCA.002236BD.00@sampark.hss.hns.com> Date: Tue, 11 Feb 2003 11:43:42 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [rohc] context update in case of packet loss Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Can some one tell me how the packet is updated on the decompressor side when there is packet loss in the transit. I would really appreciate some pointers in this regard. thanks alphonse This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 11 01:24:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10751 for ; Tue, 11 Feb 2003 01:24:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B6XMK11036 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 01:33:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6XMp11033 for ; Tue, 11 Feb 2003 01:33:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10735 for ; Tue, 11 Feb 2003 01:24:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6X2p11023; Tue, 11 Feb 2003 01:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B6WRp11005 for ; Tue, 11 Feb 2003 01:32:27 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10722 for ; Tue, 11 Feb 2003 01:23:03 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1B6Qfv08624 for ; Tue, 11 Feb 2003 11:56:41 +0530 (IST) Received: from hyd-lax-msg.wipro.com ([10.151.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Feb 2003 11:56:36 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rohc] context update in case of packet loss X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 11 Feb 2003 11:56:35 +0530 Message-ID: <85C103B6E3FDC440A06792E90FDF21A1163BB6@hyd-lax-msg.wipro.com> Thread-Topic: [rohc] context update in case of packet loss Thread-Index: AcLRla4aJFxxhhqKQkWHwLFCE+SOggAARZVw From: "Ashok Kumar" To: , X-OriginalArrivalTime: 11 Feb 2003 06:26:36.0092 (UTC) FILETIME=[870DBFC0:01C2D196] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1B6WRp11006 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Alphonse, When a packet is lost in transit, decompressor will not receive the packet. So nothing needs to be done at decompressor. The subsequent packets received by decompressor will indicate how the context should be updated at decompressor. -Ashok -----Original Message----- From: alreddy@hss.hns.com [mailto:alreddy@hss.hns.com] Sent: Tuesday, February 11, 2003 11:44 AM To: rohc@ietf.org Subject: [rohc] context update in case of packet loss Hi Can some one tell me how the packet is updated on the decompressor side when there is packet loss in the transit. I would really appreciate some pointers in this regard. thanks alphonse This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ 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 mailnull@www1.ietf.org Tue Feb 11 03:22:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23238 for ; Tue, 11 Feb 2003 03:22:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1B8VcY28497 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 03:31:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8Vcp28494 for ; Tue, 11 Feb 2003 03:31:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23230 for ; Tue, 11 Feb 2003 03:22:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8VKp28474; Tue, 11 Feb 2003 03:31:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1B8UQp28419 for ; Tue, 11 Feb 2003 03:30:26 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23212 for ; Tue, 11 Feb 2003 03:21:08 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1B8OnAv028117; Tue, 11 Feb 2003 09:24:49 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Feb 2003 09:24:49 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'zhigang.c.liu@nokia.com'" , richard.price@roke.co.uk, rohc@ietf.org Subject: RE: [rohc] SigComp Interop Date: Tue, 11 Feb 2003 09:22:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I don't think this is an interoperability issue. It can be checked fine alone. It is true that decomp failure does not happen, but compression failure does. That is why it is an internal affair. BR/Zacco -----Original Message----- From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] Sent: Monday, February 10, 2003 6:42 PM To: richard.price@roke.co.uk; rohc@ietf.org Subject: RE: [rohc] SigComp Interop > Secondly, the receiver should offer DMS = 2048 to see what > happens. If the sender is implemented correctly then > decompression failure won't occur (if the sender can't compress > the long message with DMS = 2048 then it should just send it > uncompressed). I don't think sender can ever compress a 64KB message, unless it can compress it down to something like 1KB. By definition, part of DMS is used to buffer the compressed message. So, basically if the receiver does not advertise any DMS, this test is to check if the sender is "smart" enough to send the message uncompressed. Zhigang _______________________________________________ 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 mailnull@www1.ietf.org Tue Feb 11 05:45:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26415 for ; Tue, 11 Feb 2003 05:45:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BAsVx04094 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 05:54:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BAsVp04091 for ; Tue, 11 Feb 2003 05:54:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26406 for ; Tue, 11 Feb 2003 05:45:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BAsHp04082; Tue, 11 Feb 2003 05:54:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BArnp04059 for ; Tue, 11 Feb 2003 05:53:49 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26387 for ; Tue, 11 Feb 2003 05:44:20 -0500 (EST) From: alreddy@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h1BAH8a14895; Tue, 11 Feb 2003 15:47:08 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CCA.003AC3DF ; Tue, 11 Feb 2003 16:11:52 +0530 X-Lotus-FromDomain: HSSBLR To: "Ashok Kumar" , rohc@ietf.org Message-ID: <65256CCA.003AC2CA.00@sampark.hss.hns.com> Date: Tue, 11 Feb 2003 16:11:48 +0530 Subject: RE: [rohc] context update in case of packet loss Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Ashok Please can you tell me where exactly does the compressor and decompressor fit in a traditional layer 7 model. My understanding is that it fits between layer 2 (data link layer) and layer 3 (network layer or IP). If that is the case, if a solution has to be implemented then dont we have to tweak into layer2, layer3 implementation of the stacks on respective platforms?? This doubt is specific to wireline implementatio of ROHC. since IP packet is also compressed. how is the data transmission done incase there is a router or some entity in between which doesnt support ROHC. Basically the question is should all the entities in the route support ROHC or is it suffcient if ROHC is implemented just on the endpoints?? i would be really glad to hear back from you thanks alphonse "Ashok Kumar" on 02/11/2003 11:56:35 AM To: alreddy, rohc@ietf.org cc: Subject: RE: [rohc] context update in case of packet loss Hi Alphonse, When a packet is lost in transit, decompressor will not receive the packet. So nothing needs to be done at decompressor. The subsequent packets received by decompressor will indicate how the context should be updated at decompressor. -Ashok -----Original Message----- From: alreddy@hss.hns.com [mailto:alreddy@hss.hns.com] Sent: Tuesday, February 11, 2003 11:44 AM To: rohc@ietf.org Subject: [rohc] context update in case of packet loss Hi Can some one tell me how the packet is updated on the decompressor side when there is packet loss in the transit. I would really appreciate some pointers in this regard. thanks alphonse This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. *************************************************************************** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 11 05:58:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26830 for ; Tue, 11 Feb 2003 05:58:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BB7KJ05277 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 06:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB7Kp05266 for ; Tue, 11 Feb 2003 06:07:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26786 for ; Tue, 11 Feb 2003 05:57:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB79p04983; Tue, 11 Feb 2003 06:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BB65p04697 for ; Tue, 11 Feb 2003 06:06:05 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26748 for ; Tue, 11 Feb 2003 05:56:37 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1BB0Ev02663 for ; Tue, 11 Feb 2003 16:30:14 +0530 (IST) Received: from blr-ec-msg03.wipro.com ([10.200.52.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Feb 2003 16:29:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rohc] context update in case of packet loss Date: Tue, 11 Feb 2003 16:29:45 +0530 Message-ID: Thread-Topic: [rohc] context update in case of packet loss Thread-Index: AcLRu1mJZRAyubVKRLy0w47NV5eexwAAC31Q From: "kamaldeep dham" To: , "Ashok Kumar" , X-OriginalArrivalTime: 11 Feb 2003 10:59:45.0825 (UTC) FILETIME=[B0188910:01C2D1BC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BB65p04698 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I guess, RFC 3095 does not specify, whether ROHC is a layer concept between L2 and L3 or It's a sub layer in side L2 (data link). With respect to PDCP, ROHC should be a part of PDCP implementation. Basically your ROHC implementation will provide rcv and snd iinterfaces to the PDCP where it receives & sends IP packets. In my understanding ROHC is designed for point to point links only. That's why you can have redundant information in the IP header. -Kamal -----Original Message----- From: alreddy@hss.hns.com [mailto:alreddy@hss.hns.com] Sent: Tuesday, February 11, 2003 4:12 PM To: Ashok Kumar; rohc@ietf.org Subject: RE: [rohc] context update in case of packet loss Hi Ashok Please can you tell me where exactly does the compressor and decompressor fit in a traditional layer 7 model. My understanding is that it fits between layer 2 (data link layer) and layer 3 (network layer or IP). If that is the case, if a solution has to be implemented then dont we have to tweak into layer2, layer3 implementation of the stacks on respective platforms?? This doubt is specific to wireline implementatio of ROHC. since IP packet is also compressed. how is the data transmission done incase there is a router or some entity in between which doesnt support ROHC. Basically the question is should all the entities in the route support ROHC or is it suffcient if ROHC is implemented just on the endpoints?? i would be really glad to hear back from you thanks alphonse "Ashok Kumar" on 02/11/2003 11:56:35 AM To: alreddy, rohc@ietf.org cc: Subject: RE: [rohc] context update in case of packet loss Hi Alphonse, When a packet is lost in transit, decompressor will not receive the packet. So nothing needs to be done at decompressor. The subsequent packets received by decompressor will indicate how the context should be updated at decompressor. -Ashok -----Original Message----- From: alreddy@hss.hns.com [mailto:alreddy@hss.hns.com] Sent: Tuesday, February 11, 2003 11:44 AM To: rohc@ietf.org Subject: [rohc] context update in case of packet loss Hi Can some one tell me how the packet is updated on the decompressor side when there is packet loss in the transit. I would really appreciate some pointers in this regard. thanks alphonse This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ************************************************************************ *** _______________________________________________ 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 mailnull@www1.ietf.org Tue Feb 11 06:03:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27078 for ; Tue, 11 Feb 2003 06:03:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BBCaY05666 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 06:12:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBCap05663 for ; Tue, 11 Feb 2003 06:12:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27066 for ; Tue, 11 Feb 2003 06:03:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBC2p05646; Tue, 11 Feb 2003 06:12:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBBpp05625 for ; Tue, 11 Feb 2003 06:11:51 -0500 Received: from wiprom2mx1.wipro.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27047 for ; Tue, 11 Feb 2003 06:02:23 -0500 (EST) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h1BB64v03739 for ; Tue, 11 Feb 2003 16:36:04 +0530 (IST) Received: from hyd-lax-msg.wipro.com ([10.151.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Feb 2003 16:35:59 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [rohc] context update in case of packet loss X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 11 Feb 2003 16:35:58 +0530 Message-ID: <85C103B6E3FDC440A06792E90FDF21A1163CF2@hyd-lax-msg.wipro.com> Thread-Topic: [rohc] context update in case of packet loss Thread-Index: AcLRuwxr9bGW4oegTv+dI1lt3FmdUAAAbtHQ From: "Ashok Kumar" To: , X-OriginalArrivalTime: 11 Feb 2003 11:05:59.0142 (UTC) FILETIME=[8E9C3060:01C2D1BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1BBBpp05626 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Alphanso, Please see the comments inline. Regards, Ashok Hi Ashok Please can you tell me where exactly does the compressor and decompressor fit in a traditional layer 7 model. My understanding is that it fits between layer 2 (data link layer) and layer 3 (network layer or IP). If that is the case, if a solution has to be implemented then dont we have to tweak into layer2, layer3 implementation of the stacks on respective platforms?? Ashok >> Since ROHC involves compression of Network Level PDU, so certainly the compression can only be done once you have got network level PDU from the upper layer. ROHC can be implemented as part of Data Link Layer. How you implement ROHC to fit in a particular stack is responsibility of the specific implementaion. >> This doubt is specific to wireline implementatio of ROHC. since IP packet is also compressed. how is the data transmission done incase there is a router or some entity in between which doesnt support ROHC. Basically the question is should all the entities in the route support ROHC or is it suffcient if ROHC is implemented just on the endpoints?? Ashok >> ROHC is primarily aimed for Point to Point Links. Both ends of link should support ROHC. >> i would be really glad to hear back from you thanks alphonse "Ashok Kumar" on 02/11/2003 11:56:35 AM To: alreddy, rohc@ietf.org cc: Subject: RE: [rohc] context update in case of packet loss Hi Alphonse, When a packet is lost in transit, decompressor will not receive the packet. So nothing needs to be done at decompressor. The subsequent packets received by decompressor will indicate how the context should be updated at decompressor. -Ashok -----Original Message----- From: alreddy@hss.hns.com [mailto:alreddy@hss.hns.com] Sent: Tuesday, February 11, 2003 11:44 AM To: rohc@ietf.org Subject: [rohc] context update in case of packet loss Hi Can some one tell me how the packet is updated on the decompressor side when there is packet loss in the transit. I would really appreciate some pointers in this regard. thanks alphonse This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ************************************************************************ *** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 11 06:41:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28131 for ; Tue, 11 Feb 2003 06:41:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1BBoQr07633 for rohc-archive@odin.ietf.org; Tue, 11 Feb 2003 06:50:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBoPp07630 for ; Tue, 11 Feb 2003 06:50:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28124 for ; Tue, 11 Feb 2003 06:41:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBoEp07622; Tue, 11 Feb 2003 06:50:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1BBnqp07599 for ; Tue, 11 Feb 2003 06:49:52 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28114 for ; Tue, 11 Feb 2003 06:40:28 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1BBi2KW011149; Tue, 11 Feb 2003 12:44:02 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 11 Feb 2003 12:44:02 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'alreddy@hss.hns.com'" , rohc@ietf.org Subject: RE: [rohc] context update in case of packet loss Date: Tue, 11 Feb 2003 12:38:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > Please can you tell me where exactly does the compressor and > decompressor fit in a traditional layer 7 model. My understanding > is that it fits between layer 2 (data link layer) and layer 3 > (network layer or IP). If that is the case, if a solution has to > be implemented then dont we have to tweak into layer2, layer3 > implementation of the stacks on respective platforms?? I would say that ROHC is "on top of" layer 2, i.e. the layer 2 technology must provide means to support ROHC. In the ROHC WG, we have defined this for PPP as L2, see RFC 3241, which is the only L2 protocol we have considered us (the IETF) responsible for. Take a look at RFC 3241, it is a good example of L2 support for ROHC. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 13 22:01:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27669 for ; Thu, 13 Feb 2003 22:01:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1E34lt08905 for rohc-archive@odin.ietf.org; Thu, 13 Feb 2003 22:04:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E34lp08902 for ; Thu, 13 Feb 2003 22:04:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27617 for ; Thu, 13 Feb 2003 22:00:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E34Xp08892; Thu, 13 Feb 2003 22:04:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1E33Ip08866 for ; Thu, 13 Feb 2003 22:03:18 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27562 for ; Thu, 13 Feb 2003 21:59:21 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RXRZ>; Fri, 14 Feb 2003 03:03:06 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC06AD@rsys002a.roke.co.uk> From: "West, Mark" To: "Rohc (E-mail)" Date: Fri, 14 Feb 2003 03:03:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] SigComp/DAP message flows Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, For those interested in the (fast approaching) SigComp test at SIPit, we said that we would put together some example DAP message flows. So, hopefully (!), the following link will give you some indications of the sort of things that we've been thinking of: http://sigcomp.srmr.co.uk/cgi-bin/extract_flow.cgi Obviously, comments are welcome! Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 14 06:36:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16412 for ; Fri, 14 Feb 2003 06:36:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBdb918041 for rohc-archive@odin.ietf.org; Fri, 14 Feb 2003 06:39:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBdbp18038 for ; Fri, 14 Feb 2003 06:39:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16399 for ; Fri, 14 Feb 2003 06:35:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBdOp18024; Fri, 14 Feb 2003 06:39:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBcKp17992 for ; Fri, 14 Feb 2003 06:38:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16365 for ; Fri, 14 Feb 2003 06:34:12 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1EBbuAx022264; Fri, 14 Feb 2003 12:37:56 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <18KT8BWC>; Fri, 14 Feb 2003 12:37:55 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Price, Richard'" , "Ghyslain Pelletier (EAB)" Cc: "Rohc (E-mail)" Date: Fri, 14 Feb 2003 12:32:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [rohc] UDP-Lite compression Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, Ghyslain, and others, > > Do you not agree that "random" is the correct classification for the > > UDP-Lite checksum field? > > I'd like to avoid the term "random", which generally refers to some > data that has no discernable pattern whatsoever (thus the term is > inapplicable to the UDP checksum). RFC 3095 coins the more general > term "irregular" to describe fields "for which no useful change > pattern can be identified". As well as truly random fields, this > definition also applies to fields that do have a discernable pattern, > but which isn't useful for compression (e.g. because it would violate > end-to-end integrity). How about using this classification instead? I agree that IRREGULAR might be the right word to use when we discuss the classification, as that is the classification we used in 3095, and when we now address the differences in UDP-Lite we should be consistent. > I think it would be helpful to cleanly separate the chapter > on UDP-Lite behavior from the proposed compression profile. > The behavior chapter should just describe how we expect UDP-Lite > to behave, without taking into account how we intend to compress > it (much like the behavior draft we did for ROHC-TCP). If we > expect the CC field to exhibit non-random behavior then we > should say so, even if we then ignore this when actually > compressing the field. I agree, and that is what the current draft seems to do by providing an analysis of the behavior in chapter 3, listing the design rationales for the profile in chapter 4, and defining the actual profile in chapter 5. > The current text makes it clear that support for multiple > IP headers has been added, but doesn't explain the motivation > behind this addition. It seems to contradict the goal of > making as little modifications to RFC 3095 as possible. Not necessarily. One could actually say that this is a very simple fix to allow compression of more than 2 IP headers. The profiles in 3095 would be able to handle that in IR/IR-DYN headers, but it has not been defined how to carry additional information in compressed headers. The solution (as defined by the IP profile) imposes really no change to the profiles in 3095, it just requires a minor addition. The header field structure for the added field is the same as the one used in IR/IR-DYN headers. The actual compressed header formats are thus not changed. In general, it should be noted that UDP-Lite is very similar to UDP, and the difference is only about the checksum coverage (the fact that the checksum can not be disabled does not affect the compression, it is already supported by the RTP/UDP and UPD profiles). One of the reasons UDP-Lite has been defined as it is, is to simplify deployment by making it implementable through a rather small modification to an existing UDP implementation, and the same argument apply as well to the UDP-Lite compression profile. We should make sure to minimize the effort needed to modify existing ROHC profile 1,2 implementations to get UDP-Lite compression. This will make life easier for implementers, as well as it will simplify deployment of UDP-Lite compression. This way, we should also be able to get interoperability verified easily, as we already have had several interoperability tests of the current profiles, and almost all parts have now been tested. The WG has already completed its UDP and UDP/RTP tasks, and what is left here is only to address the differences in UDP-Lite. Of course, we should try to do our best to anticipate how UDP-Lite usage could have implications for the coverage field behavior, and use this when we incorporate coverage field handling in the profile(s). The current draft has the means to exclude the coverage field or include it as a two-octet field. However, I agree with Richard that it might make sense to use some variable length approach so that (when sufficient) only one byte can be sent as W-LSB coded bits, and we should investigate how to achieve this. The current draft shows that we can do this without having to require significant changes to the UDP profiles, we just have to focus on getting the last bit of the puzzle right without breaking the rest of it. Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 14 06:47:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17203 for ; Fri, 14 Feb 2003 06:47:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EBocs18778 for rohc-archive@odin.ietf.org; Fri, 14 Feb 2003 06:50:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBocp18775 for ; Fri, 14 Feb 2003 06:50:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17184 for ; Fri, 14 Feb 2003 06:46:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBoSp18764; Fri, 14 Feb 2003 06:50:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EBmhp18616 for ; Fri, 14 Feb 2003 06:48:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16988; Fri, 14 Feb 2003 06:44:37 -0500 (EST) Message-Id: <200302141144.GAA16988@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 14 Feb 2003 06:44:37 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-terminology-and-examples-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : RObust Header Compression (ROHC):Terminology and Channel Mapping Examples Author(s) : L. Jonsson Filename : draft-ietf-rohc-terminology-and-examples-02.txt Pages : 20 Date : 2003-2-13 RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms like network elements and IP interfaces, commonly used for example when addressing MIB issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-terminology-and-examples-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-terminology-and-examples-02.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-terminology-and-examples-02.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: <2003-2-13152855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-terminology-and-examples-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-terminology-and-examples-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13152855.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Sun Feb 16 19:27:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01476 for ; Sun, 16 Feb 2003 19:27:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1H0Vvl04861 for rohc-archive@odin.ietf.org; Sun, 16 Feb 2003 19:31:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H0Vvp04858 for ; Sun, 16 Feb 2003 19:31:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01472 for ; Sun, 16 Feb 2003 19:26:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H0Vcp04844; Sun, 16 Feb 2003 19:31:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1H0Ucp04782 for ; Sun, 16 Feb 2003 19:30:38 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01451 for ; Sun, 16 Feb 2003 19:25:07 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h1H0TeXw022039 for ; Mon, 17 Feb 2003 08:29:40 +0800 (SGT) Received: from 827300975.icr.a-star.edu.sg ([172.16.3.126]) by mailer.icr.a-star.edu.sg; Mon, 17 Feb 2003 08:22:24 +0800 Message-Id: <4.3.2.7.2.20030217083429.00e1b370@mailer.icr.a-star.edu.sg> X-Sender: chankm@mailer.icr.a-star.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Feb 2003 08:42:55 +0800 To: rohc@ietf.org From: Chan Kwang Mien In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC06AD@rsys002a.roke.co. uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [rohc] Use of User-specific Dictionary Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , hi, i would like to refer to the test on Use of User-Specific Dictionary. i) Should the User-Specific Dictionary be uploaded as plain text or included as part of a SigComp message which means it has to be compressed ? ii) How does endpoint 1 inform endpoint 2 that it is uploading the Dictionary to it ? is there a special flag to indicate this ? Thanks !! regards, Kwang Mien _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 17 12:29:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26647 for ; Mon, 17 Feb 2003 12:29:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HHYJ809016 for rohc-archive@odin.ietf.org; Mon, 17 Feb 2003 12:34:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HHYJp09013 for ; Mon, 17 Feb 2003 12:34:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26641 for ; Mon, 17 Feb 2003 12:28:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HHY7p08999; Mon, 17 Feb 2003 12:34:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HHXBp08953 for ; Mon, 17 Feb 2003 12:33:11 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26610 for ; Mon, 17 Feb 2003 12:27:27 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R743>; Mon, 17 Feb 2003 17:31:14 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1BB@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Chan Kwang Mien'" , rohc@ietf.org Subject: RE: [rohc] Use of User-specific Dictionary Date: Mon, 17 Feb 2003 17:31:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > i would like to refer to the test on Use of User-Specific Dictionary. > > i) Should the User-Specific Dictionary be uploaded as plain text or included > as part of a SigComp message which means it has to be compressed ? Hi Kwang Mien, The choice of how to upload the User-Specific Dictionary is made by the compressor. The dictionary will always be part of a SigComp message, but it's up to the compressor to decide whether to send the dictionary compressed or as plain text. > ii) How does endpoint 1 inform endpoint 2 that it is uploading the > Dictionary to it ? > is there a special flag to indicate this ? Endpoint 1 informs endpoint 2 that it is uploading the dictionary by sending a piece of UDVM bytecode. This code should tell endpoint 2 to decompress the dictionary (if necessary) and then to save it as state, so that it can be retrieved when later messages need to be decompressed. Regards, Richard > Thanks !! > > regards, > Kwang Mien > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Feb 18 21:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15059 for ; Tue, 18 Feb 2003 21:14:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J2Jts14148 for rohc-archive@odin.ietf.org; Tue, 18 Feb 2003 21:19:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J2Jtp14145 for ; Tue, 18 Feb 2003 21:19:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15018 for ; Tue, 18 Feb 2003 21:13:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J2Jfp14134; Tue, 18 Feb 2003 21:19:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J2I0p14088 for ; Tue, 18 Feb 2003 21:18:00 -0500 Received: from hellmouth5.gatech.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14993 for ; Tue, 18 Feb 2003 21:11:37 -0500 (EST) Received: from hellmouth5.gatech.edu (localhost [127.0.0.1]) by hellmouth5.gatech.edu (Postfix) with SMTP id 7AF211D199A for ; Tue, 18 Feb 2003 21:15:26 -0500 (EST) (envelope-from vkm@ece.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 hellmouth5.gatech.edu (Postfix) with ESMTP id 66A5E1D1990 for ; Tue, 18 Feb 2003 21:15:26 -0500 (EST) (envelope-from vkm@ece.gatech.edu) Received: from localhost (localhost [127.0.0.1]) by mailprx5.gatech.edu (Postfix) with ESMTP id E5A173A60D for ; Tue, 18 Feb 2003 21:15:24 -0500 (EST) (envelope-from vkm@ece.gatech.edu) Received: from 24.98.180.29 ( [24.98.180.29]) as user vm10@tunnel.mail.gatech.edu by webmail.mail.gatech.edu with HTTP; Tue, 18 Feb 2003 21:15:24 -0500 Message-ID: <1045620924.3e52e8bca2857@webmail.mail.gatech.edu> Date: Tue, 18 Feb 2003 21:15:24 -0500 From: "Vijay K. Madisetti" Reply-To: madisetti@ieee.org To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 24.98.180.29 X-Authenticated-User: vm10 Content-Transfer-Encoding: 8bit Subject: [rohc] Inernet Draft on Robust Compression - FYI Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit FYI. ========================================================================== INTERNET DRAFT V. Madisetti Date: Jan 30, 2003 S. Rao Expires: June 30, 2003 N. Suresh Georgia Institute of Technology Enhancements to ECRTP with Applications to Robust Header Compression for Wireless Abstract Enhanced Compressed RTP (ECRTP) and Robust Header Compression (ROHC) are IP header compression schemes that have been proposed for use in wireless applications, primarily for voice and audio applications. While ROHC offers a high degree of compression and is robust, it is also computationally expensive. On the other hand, ECRTP does not achieve as high a compression, while being less expensive computationally. Our proposal, E2CRTP, is an enhanced version of ECRTP that offers a middleground between the ROHC and ECRTP, providing robustness, compression efficiency, and moderate computational complexity. TABLE OF CONTENTS 1. Introduction ..................................... 2 2. Proposed enhancements to ECRTP - E2CRTP .......... 2 2.1 W-LSB encoding of fields 2.1.1 Packet Structure .............. 2 2.2 Reduced frequency of Checksum transmissions 2.2.1 Packet Structure 3. Assumptions. ..................................... 6 4. Simulation Results ............................... 7 5. Observations and Conclusions ..................... 8 6. Summary & Future Work ............................ 9 7. Security Considerations .......................... 9 8. References ....................................... 10 9. Authors' Addresses ............................... 10 http://www.ietf.org/internet-drafts/draft-madisetti-rao-suresh-rohc-00.txt =================== -- Vijay K. Madisetti Professor, ECE Georgia Institute of Technology http://www.ece.gatech.edu/~vkm/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 19 07:06:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20216 for ; Wed, 19 Feb 2003 07:06:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCCWk03013 for rohc-archive@odin.ietf.org; Wed, 19 Feb 2003 07:12:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCCVp03010 for ; Wed, 19 Feb 2003 07:12:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20210 for ; Wed, 19 Feb 2003 07:05:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCCIp02987; Wed, 19 Feb 2003 07:12:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCBJp02937 for ; Wed, 19 Feb 2003 07:11:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20138; Wed, 19 Feb 2003 07:04:45 -0500 (EST) Message-Id: <200302191204.HAA20138@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Feb 2003 07:04:44 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-sctp-requirements-02.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : Requirements for RoHC IP/SCTP Robust Header Compression Author(s) : C. Schmidt, M. Tuexen Filename : draft-ietf-rohc-sctp-requirements-02.txt Pages : 13 Date : 2003-2-14 This document contains requirements for the IP/SCTP header compression scheme (profile) to be developed by the ROHC WG. The structure of this document is inherited from the document defining IP/TCP requirements for ROHC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-sctp-requirements-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctp-requirements-02.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-sctp-requirements-02.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: <2003-2-14105238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-sctp-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-sctp-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105238.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 19 10:09:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27469 for ; Wed, 19 Feb 2003 10:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFG5r17887 for rohc-archive@odin.ietf.org; Wed, 19 Feb 2003 10:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFG5p17884 for ; Wed, 19 Feb 2003 10:16:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27415 for ; Wed, 19 Feb 2003 10:09:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFFpp17866; Wed, 19 Feb 2003 10:15:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFCpp17685 for ; Wed, 19 Feb 2003 10:12:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27310; Wed, 19 Feb 2003 10:06:12 -0500 (EST) Message-Id: <200302191506.KAA27310@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Feb 2003 10:06:12 -0500 Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --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 : Interoperability of RFC 3095 Author(s) : L. Jonsson Filename : draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt Pages : 30 Date : 2003-2-18 RFC 3095 defines a Proposed Standard protocol for RObust Header Compression (ROHC). In order to move the standard further to Draft Standard status, it is required to demonstrate interoperability for all functionality defined by the RFC. This document outlines those features to be tested, and also the test status for each feature, based on reports from interoperability tests or other proof of interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rtp-rfc3095-interoperability-01.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-rtp-rfc3095-interoperability-01.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: <2003-2-18161211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-18161211.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Mon Feb 24 03:51:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04962 for ; Mon, 24 Feb 2003 03:51:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O8xpg07934 for rohc-archive@odin.ietf.org; Mon, 24 Feb 2003 03:59:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8xpp07931 for ; Mon, 24 Feb 2003 03:59:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04959 for ; Mon, 24 Feb 2003 03:50:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8xYp07916; Mon, 24 Feb 2003 03:59:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8wjp07887 for ; Mon, 24 Feb 2003 03:58:45 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04931 for ; Mon, 24 Feb 2003 03:49:46 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 08:53:39 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4180663681F@rsys002a.roke.co.uk> From: "West, Mark" To: "'rohc@ietf.org'" Date: Mon, 24 Feb 2003 08:53:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] TCP 'shareable' fields Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, Whilst there are a few nits, random references and other odd bits to finalise on the behaviour draft, the main outstanding item appears to be the discussion of 'shareable' TCP fields. (Although, at the risk of making words up, I've changed the name to 'replicable', since I don't think that 'sharing' [old argument!] is an accurate description of how they are used). Having finally got around to updating this, I thought I'd post some updated text for comments, prior to submitting the revised draft. So, here it is... 4. Classification of replicable header fields Where multiple flows either overlap in time or occur sequentially within a short space of time there can be a great deal of similarity in header field values. Such commonality of field values is reflected in the compression context. Thus, it should be possible to utilise links between fields across different flows to improve the compression ratio. In order to do this, it is important to understand the 'replicable' characteristics of the various header fields. The key concept is that of 'replication', where an existing context is used as a baseline and replicated to initialise a new context. Those fields that are the same are then automatically initialised in the new context. Those that have changed will be updated or overwritten with values from the initialisation packet that triggered the replication. This section considers the commonality between fields in different flows. It should be noted, however, that replication is based on contexts (rather than just field values) and so 'meta-fields' that are part of the context should also be included. These, of course, are dependent upon the nature of the compression algorithm being applied. A brief analysis of the relationship of TCP/IP fields among 'replicable' packet streams follows. 'N/A' -- The field need not be considered in the replication process as it is inferred or known 'a priori' (and, therefore, does not appear in the context). 'No' -- The field cannot be replicated since its change pattern between two packet flows is uncorrelated. 'Yes' -- The field may be replicated. This does not guarantee that the field value will be the same across two candidate streams, only that it might be possible to exploit replication to increase the compression ratio. Specific encoding methods can be used to improve the compression efficiency. 4.1 IPv4 Header (inner and/or outer) +-----------------------+---------------+------------+ | Field | Class | Replicable | +-----------------------+---------------+------------+ | Version | STATIC | N/A | | Header Length | STATIC-KNOWN | N/A | | DSCP | CHANGING | No (1) | | ECT flag | CHANGING | No (2) | | CE flag | CHANGING | No (2) | | Packet Length | INFERRED | N/A | | Identification | CHANGING | Yes (3) | | Reserved flag | CHANGING | No (4) | | Don't Fragment flag | CHANGING | No | | More Fragments flag | STATIC-KNOWN | N/A | | Fragment Offset | STATIC-KNOWN | N/A | | Time To Live | CHANGING | Yes | | Protocol | STATIC | N/A | | Header Checksum | INFERRED | N/A | | Source Address | STATIC-DEF | Yes | | Destination Address | STATIC-DEF | Yes | +-----------------------+---------------+------------+ (1) The DSCP is marked based on the application's requirements. If it can be assumed that replicable connections often carry the same type of traffic, the DSCP may be regarded as replicable. However, issues such as re-marking will need to be taken into account. (2) It is not possible for the ECN bits to be replicated (note that use of the ECN nonce scheme is anticipated). However, it seems likely that all TCP flows between ECN-capable hosts will use ECN, the use (or not) of ECN for flows between the same end-points might be considered replicable. See also note (4). (3) The replicable context for this field includes the IP-ID, NBO, and RND flags (as described in ROHC RTP). This highlights that the replication is of the context, rather than just the header field values and, as such, needs to be considered based on the exact nature of compression applied to each field. (4) Since the possible future behavior of the 'Reserved Flag' cannot be predicted, it is not considered as replicable. However, it might be expected that the behaviour of the reserved flag between the same end-points will be similar. In this case, any selection of packet formats (for example) based on this behaviour might carry across to the new flow. In the case of packet formats, this can probably be considered as a compressor-local decision. 4.2 IPv6 Header (inner and/or outer) +-----------------------+---------------+------------+ | Field | Class | Replicable | +-----------------------+---------------+------------+ | Version | STATIC | N/A | | Traffic Class | CHANGING | Yes (1) | | ECT flag | CHANGING | No (2) | | CE flag | CHANGING | No (2) | | Flow Label | STATIC-DEF | N/A | | Payload Length | INFERRED | N/A | | Next Header | STATIC | N/A | | Hop Limit | CHANGING | Yes | | Source Address | STATIC-DEF | Yes | | Destination Address | STATIC-DEF | Yes | +-----------------------+---------------+------------+ (1) See comment for IPv4, above. (2) See comment for IPv4, above. 4.3 TCP Header +-----------------------+---------------+------------+ | Field | Class | Replicable | +-----------------------+---------------+------------+ | Source Port | STATIC-DEF | Yes (1) | | Destination Port | STATIC-DEF | Yes (1) | | Sequence Number | CHANGING | No (2) | | Acknowledgement Number| CHANGING | No | | Data Offset | INFERRED | N/A | | Reserved Bits | CHANGING | No (3) | | Flags | | | | CWR | CHANGING | No (4) | | ECE | CHANGING | No (4) | | URG | CHANGING | No | | ACK | CHANGING | No | | PSH | CHANGING | No | | RST | CHANGING | No | | SYN | CHANGING | No | | FIN | CHANGING | No | | Window | CHANGING | Yes | | Checksum | CHANGING | No | | Urgent Pointer | CHANGING | Yes (5) | +-----------------------+---------------+------------+ (1) On the server side, the port number is likely to be a well-known value. On the client side, the port number is generally selected by the stack automatically. Whether the port number is replicable depends upon how the stack chooses the port number. However, most implementations use a simple scheme which sequentially picks the next available port number. This is clearly exploitable in a compression scheme. (2) With the recommendation (and expected deployment) of TCP Initial Sequence Number randomization, defined in RFC 1948 [13], it will be impossible to share the sequence number. Thus, this field will not be regarded as replicable. (3) See comment (4) for the IPv4 header, above. (4) See comment (2) on ECN flags for the IPv4 header, above. (5) The urgent pointer is very rarely used. This means that, in practice, the field may be considered replicable. 4.4 TCP Options +---------------------------+--------------+------------+ | Option | SYN-only (1) | Replicable | +---------------------------+--------------+------------+ | End of Option List | No | No (2) | | No-Operation | No | No (2) | | Maximum Segment Size | Yes | Yes | | Window Scale | Yes | Yes | | SACK-Permitted | Yes | Yes | | SACK | No | No | | Timestamp | No | No | +---------------------------+--------------+------------+ (1) This indicates whether the option only appears in SYN packet or not. Options that are not 'SYN-only' may appear in any packet. Many TCP options are used only in SYN packets. Some options, such as MSS, Window Scale, SACK-Permitted etc., will tend to have the same value among replicable packet streams. Thus, to support context sharing, the compressor should maintain such TCP options in the context (even though they only appear in the SYN segment). (2) Since these options have fixed values, they could be regarded as replicable. However, the only interesting thing to convey about these options is their presence: if it is known that such an option exists, its value is defined. 4.5 Summary of replication From the above analysis, it can be seen that there are reasonable grounds for exploiting redundancy between flows, as well as between packets within a flow. Simply consider the advantage of being able to elide the source and destination addresses for a repeated connection between two IPv6 endpoints. The final point to note for the use of replication is that it requires the compressor to have a suitable degree of confidence that the source data is present and correct at the decompressor. This may place some restrictions on which of the 'changing' fields, in particular, can be utilised during replication. ... comments welcome! Cheers, Mark. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 25 07:38:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27879 for ; Tue, 25 Feb 2003 07:38:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PClwx25581 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 07:47:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PClwp25578 for ; Tue, 25 Feb 2003 07:47:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27864 for ; Tue, 25 Feb 2003 07:38:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PClWp25562; Tue, 25 Feb 2003 07:47:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCkXp25523 for ; Tue, 25 Feb 2003 07:46:33 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27836 for ; Tue, 25 Feb 2003 07:37:02 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PCesYf023040 for ; Tue, 25 Feb 2003 13:40:55 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 13:40:54 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Tue, 25 Feb 2003 13:30:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Updating the ROHC impl. guide Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, The Berlin interop generated a couple of questions on 3095, and some new issues have also been raised on the mailing list since October when we made the last update of the impl. guide. I've tried to collect these, address the questions and find answers. My proposals for how to capture these issues in the implementer's guide can be found below. Please let me know if something is not clear or if there are ideas for improving the clarifying texts. Thanx! /L-E NOTE: All section references in this document refer to 3095, if not explicitly stated otherwise. 1) Section 4.9 should clarify that a UO-1-ID packet with an Extension 3 must never be sent with RND flags that changes the packet interpretation, i.e. that would violate the base condition for UO-1-ID (at least one RND value must be 0). The last line of the first paragraph is also redundant and unclear. * Proposed modified text for the first paragraph of section 4.9: "Extension-3 is applied to give values and indicate changes to fields other than SN, TS and IP-ID in IP header(s) and RTP header. In case of UO-1-ID packets, it should be noted that values provided in extensions do not update the context, with an exception for SN, TS and IP-ID fields, which always update the context (Section 5.7.3.). It should also be noted that a UO-1-ID packet with Extension 3 must never be sent with RND flags that changes the packet interpretation, i.e. that would violate the base condition for UO-1-ID (at least one RND value must be 0)." 2) It should be clarified that W-LSB encoding is used for TS, both if it is sent unscaled or scaled. Further, it should be noted that TS_OFFSET must be recalculated when an unscaled TS is received. * Proposed modification of section 4.2: - Change 4.2 to become "TS encoding considerations" - Renumber current 4.2 to 4.2.2. - Add 4.2.1., "Encoding of TS values" "RTP Timestamp values (TS) are always encoded using W-LSB encoding, both when sent scaled and when sent unscaled. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable-length format (section 4.5.6), and this applies to both scaled and unscaled values." - Add 4.2.4, "Recalculating TS_OFFSET" "TS can be sent unscaled if the TS value change does not match the established TS_STRIDE, but the TS_STRIDE might still stay unchanged. To ensure correct decompression of subsequent packets, the decompressor should therefore always recalculate the RTP TS modulo, TS_OFFSET, when a packet with an unscaled TS value is received." 3) It has been noted that there is an ambiguity about the "CC" and "Generic CSRC list" in 5.7.7.6. The question is whether CC=0 actually means that there are no CSRC items present at all (as the CC field means in RTP), or if an "empty" generic compressed CSRC list of at least 1 octet must still be present. The former should be the obvious interpretation as the CC field would otherwise have no meaning at all, and as the latter interpretation would just waste useless octets. However, this is not totally clear from the text, and it is currently not discussed in the implementer's guide. Another list compression question is whether a 7-bit bit mask can be used also when there are more than 7 items in the list. * Proposed addition to the impl. guide: - Change 4.3 to become "List compression issues" - Rename current section 4.5 to "CSRC list items in RTP dynamic chain" - Renumber current sections 4.3-4.5 to 4.3.1-4.3.3 - Renumber current section 4.15 to 4.3.4 - Renumber subsequent sections 4.6-4.14 to 4.4-4.12 - Rewrite the beginning of current section 4.5. to say: "Section 5.7.7.6 defines the static and dynamic parts of the RTP header. In the dynamic part, a 'CC' field indicates the number of CSRC items present in the 'Generic CSRC list'. It should be noted that when the value of this CC field is equal to zero, there is no Generic CSRC list present in the dynamic chain, i.e. the field comment should have said "variable length, present if CC > 0". A 'CC' field can also be found within the 'Generic CSRC list' (when present), and these fields would then have the same meaning. In order..." - Add subsection 4.3.5, "Bit masks in list compression" "A 7-bit or 15-bit mask may be used in the insertion and/or removal schemes for compressed lists. It should be noted that even if a list has more than 7 items, a 7-bit mask can be used as long as changes are only applied in the first part of the reference list, and all items with an index not covered by the 7-bit mask are then kept unchanged." 4) Section 4.11 seems to be totally incorrect, as RTP SN is only 16 bits long, and feedback packets can carry 16 bits. I do not know where this section comes from, but it should be removed. 5) For the UDP profile, all formats are the same as for profile 1, if not explicitly stated otherwise. However, it is rather unclear from section 5.11.3 whether "New format:" for UOR-2 means the format is changed for UOR-2-only, or if this new format replaces UOR-2, UOR-2-ID, and UOR-2-TS. In fact, it does replace all of them. * Proposed addition to the impl. guide: - Add new section 4.xx, "UOR-2 in profile 2 (UDP)": "One single new format is defined for UOR-2 in profile 2, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 1. The same UOR-2 format is thus used independent of if there are IP headers with a corresponding RND=1 or not." 6) As suggested by Zhigang and agreed on the list, we should give an additional clarification in section 4.7. * Proposed additional paragraph in 4.7: "An updating packet thus updates the reference values of all header fields, either explicitly or implicitly. In UO-mode, all packets are updating packets (except for UO-1-ID, which only updates TS, SN and IP-ID, see 5.7.3), while in R-mode all packets with a CRC are updating packets." 7) As Carsten noted on the list, the logical union of suboptions for IPCP and IPV6CP negotiations, as specified by RFC 3241, can not be used for the PROFILES suboption, as the whole union must then be considered within each of the two IPCP negotiations to avoid getting an ambiguous profile set. * Proposed new section 6, "PROFILES suboption in ROHC-over-PPP" "The logical union of suboptions for IPCP and IPV6CP negotiations, as specified by RFC 3241, can not be used for the PROFILES suboption, as the whole union would then have to be considered within each of the two IPCP negotiations, to avoid getting an ambiguous profile set. An implementation of RFC 3241 must therefore make sure the same profile set is negotiated for both IPv4 and IPv6 (IPCP and IPV6CP)." ----------------------------------- Lars-Erik Jonsson, M.Sc Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Luleå, Sweden E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 25 08:11:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00004 for ; Tue, 25 Feb 2003 08:11:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDKOY28032 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 08:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDKOp28029 for ; Tue, 25 Feb 2003 08:20:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29967 for ; Tue, 25 Feb 2003 08:10:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDKAp28020; Tue, 25 Feb 2003 08:20:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDJUp27934 for ; Tue, 25 Feb 2003 08:19:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29925 for ; Tue, 25 Feb 2003 08:09:58 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PDDpYe001731; Tue, 25 Feb 2003 14:13:51 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 14:13:51 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'West, Mark'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP 'shareable' fields Date: Tue, 25 Feb 2003 14:13:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Mark, This is a nice update and I do not have many comments. I think the classification looks good, and overall we now seem to be consistent with what we have agreed to during the last 9 months. A few comments below! Rgds, /L-E > Whilst there are a few nits, random references and other odd > bits to finalise on the behaviour draft, the main outstanding > item appears to be the discussion of 'shareable' TCP fields. > (Although, at the risk of making words up, I've changed the > name to 'replicable', since I don't think that 'sharing' [old > argument!] is an accurate description of how they are used). Yes, this seems to be the common understanding since May -02. Let's stick to that term, hopefully we will now at least be consistent at some places...=) > It should be noted, however, that replication is based on > contexts (rather than just field values) and so 'meta-fields' > that > are part of the context should also be included. > These, of course, are dependent upon the nature of the > compression algorithm being applied. The last line would become clearer in our context if we modify and extend it to: "...the compression protocol (ROHC profile) being applied." By the way, is it clear what is meant with "meta-fields"? It is not to me. I guess you mean "data not part of the original headers", but does it make sense to replicate that? Do we need to analyze what information might be considerable for that purpose? > 4.2 IPv6 Header (inner and/or outer) > > +-----------------------+---------------+------------+ > | Field | Class | Replicable | > +-----------------------+---------------+------------+ > | Version | STATIC | N/A | > | Traffic Class | CHANGING | Yes (1) | > | ECT flag | CHANGING | No (2) | > | CE flag | CHANGING | No (2) | > | Flow Label | STATIC-DEF | N/A | > | Payload Length | INFERRED | N/A | > | Next Header | STATIC | N/A | > | Hop Limit | CHANGING | Yes | > | Source Address | STATIC-DEF | Yes | > | Destination Address | STATIC-DEF | Yes | > +-----------------------+---------------+------------+ > > (1) See comment for IPv4, above. Which comment for IPv4? We should probably clarify that the field has a different name, i.e. refer to the actual v4 field. > 4.5 Summary of replication > > From the above analysis, it can be seen that there are reasonable > grounds for exploiting redundancy between flows, as well as between > packets within a flow. Simply consider the advantage of being able > to elide the source and destination addresses for a repeated > connection between two IPv6 endpoints. This summary is fine, but maybe we should also note already in this summary that it is important to find a suitable trade-off, providing the means of replicating a field will always imply a cost, and must thus be justified by a reasonably gain. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 25 08:37:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00821 for ; Tue, 25 Feb 2003 08:37:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDkBA29919 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 08:46:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDkBp29916 for ; Tue, 25 Feb 2003 08:46:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00785 for ; Tue, 25 Feb 2003 08:36:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDiPp29822; Tue, 25 Feb 2003 08:44:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDh3p29752 for ; Tue, 25 Feb 2003 08:43:03 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00699 for ; Tue, 25 Feb 2003 08:33:21 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 13:37:04 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806636837@rsys002a.roke.co.uk> From: "West, Mark" To: "'Lars-Erik Jonsson (EAB) '" , "''rohc@ietf.org' '" Subject: RE: [rohc] TCP 'shareable' fields Date: Tue, 25 Feb 2003 13:37:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi from SIPit... I agree with and will incorporate your comments -- thanks! BTW - yes 'meta-fields' means what you think it means; I will try to clarify. My understanding is that you would actually replicate *context*, and the context is more than just the fields (e.g. the IP-ID Network Byte Order). However, the behaviour of these additional things in the context is slightly outside of just the protocol behaviour. I think... Although, having said that, we do discuss the way the IP-ID behaves. So perhaps I can bound the description a bit better. Cheers, Mark. -----Original Message----- From: Lars-Erik Jonsson (EAB) To: West, Mark; 'rohc@ietf.org' Sent: 25/02/03 13:13 Subject: RE: [rohc] TCP 'shareable' fields Mark, This is a nice update and I do not have many comments. I think the classification looks good, and overall we now seem to be consistent with what we have agreed to during the last 9 months. A few comments below! Rgds, /L-E > Whilst there are a few nits, random references and other odd > bits to finalise on the behaviour draft, the main outstanding > item appears to be the discussion of 'shareable' TCP fields. > (Although, at the risk of making words up, I've changed the > name to 'replicable', since I don't think that 'sharing' [old > argument!] is an accurate description of how they are used). Yes, this seems to be the common understanding since May -02. Let's stick to that term, hopefully we will now at least be consistent at some places...=) > It should be noted, however, that replication is based on > contexts (rather than just field values) and so 'meta-fields' > that > are part of the context should also be included. > These, of course, are dependent upon the nature of the > compression algorithm being applied. The last line would become clearer in our context if we modify and extend it to: "...the compression protocol (ROHC profile) being applied." By the way, is it clear what is meant with "meta-fields"? It is not to me. I guess you mean "data not part of the original headers", but does it make sense to replicate that? Do we need to analyze what information might be considerable for that purpose? > 4.2 IPv6 Header (inner and/or outer) > > +-----------------------+---------------+------------+ > | Field | Class | Replicable | > +-----------------------+---------------+------------+ > | Version | STATIC | N/A | > | Traffic Class | CHANGING | Yes (1) | > | ECT flag | CHANGING | No (2) | > | CE flag | CHANGING | No (2) | > | Flow Label | STATIC-DEF | N/A | > | Payload Length | INFERRED | N/A | > | Next Header | STATIC | N/A | > | Hop Limit | CHANGING | Yes | > | Source Address | STATIC-DEF | Yes | > | Destination Address | STATIC-DEF | Yes | > +-----------------------+---------------+------------+ > > (1) See comment for IPv4, above. Which comment for IPv4? We should probably clarify that the field has a different name, i.e. refer to the actual v4 field. > 4.5 Summary of replication > > From the above analysis, it can be seen that there are reasonable > grounds for exploiting redundancy between flows, as well as between > packets within a flow. Simply consider the advantage of being able > to elide the source and destination addresses for a repeated > connection between two IPv6 endpoints. This summary is fine, but maybe we should also note already in this summary that it is important to find a suitable trade-off, providing the means of replicating a field will always imply a cost, and must thus be justified by a reasonably gain. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 25 09:29:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01902 for ; Tue, 25 Feb 2003 09:29:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PEcZH01384 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 09:38:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEcZp01381 for ; Tue, 25 Feb 2003 09:38:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01898 for ; Tue, 25 Feb 2003 09:29:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEcJp01366; Tue, 25 Feb 2003 09:38:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEbLp01163 for ; Tue, 25 Feb 2003 09:37:21 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01890 for ; Tue, 25 Feb 2003 09:27:47 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 14:31:40 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1CE@rsys002a.roke.co.uk> From: "Price, Richard" To: "West, Mark" , "'Lars-Erik Jonsson (EAB) '" , "''rohc@ietf.org' '" Subject: RE: [rohc] TCP 'shareable' fields Date: Tue, 25 Feb 2003 14:31:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, The so-called 'meta-fields' are mentioned in ROHC-TCP and also the Formal Notation, but in these drafts they're known as 'control fields'. It would be nice to use a consistent term between all of the drafts. I'm not sure that either of the current terms is particularly descriptive - how about adopting a more explicit term such as 'compressor-created fields'? Regards, Richard > -----Original Message----- > From: West, Mark > Sent: Tuesday, February 25, 2003 1:37 PM > To: 'Lars-Erik Jonsson (EAB) '; ''rohc@ietf.org' ' > Subject: RE: [rohc] TCP 'shareable' fields > > > > Hi from SIPit... > > I agree with and will incorporate your comments -- thanks! > > BTW - yes 'meta-fields' means what you think it means; I will > try to clarify. My understanding is that you would actually > replicate *context*, and the context is more than just the > fields (e.g. the IP-ID Network Byte Order). However, the > behaviour of these additional things in the context is > slightly outside of just the protocol behaviour. I think... > Although, having said that, we do discuss the way the IP-ID > behaves. So perhaps I can bound the description a bit better. > > Cheers, > > Mark. > > > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > To: West, Mark; 'rohc@ietf.org' > Sent: 25/02/03 13:13 > Subject: RE: [rohc] TCP 'shareable' fields > > Mark, > > This is a nice update and I do not have many comments. I think > the classification looks good, and overall we now seem to be > consistent with what we have agreed to during the last 9 months. > > A few comments below! > > Rgds, > /L-E > > > > > Whilst there are a few nits, random references and other odd > > bits to finalise on the behaviour draft, the main outstanding > > item appears to be the discussion of 'shareable' TCP fields. > > (Although, at the risk of making words up, I've changed the > > name to 'replicable', since I don't think that 'sharing' [old > > argument!] is an accurate description of how they are used). > > Yes, this seems to be the common understanding since May -02. > Let's stick to that term, hopefully we will now at least be > consistent at some places...=) > > > > It should be noted, however, that replication is based on > > contexts (rather than just field values) and so 'meta-fields' > > that > are part of the context should also be included. > > These, of course, are dependent upon the nature of the > > compression algorithm being applied. > > The last line would become clearer in our context if we modify and > extend it to: > "...the compression protocol (ROHC profile) being applied." > > By the way, is it clear what is meant with "meta-fields"? It is > not to me. I guess you mean "data not part of the original > headers", but does it make sense to replicate that? Do we need > to analyze what information might be considerable for that > purpose? > > > > 4.2 IPv6 Header (inner and/or outer) > > > > +-----------------------+---------------+------------+ > > | Field | Class | Replicable | > > +-----------------------+---------------+------------+ > > | Version | STATIC | N/A | > > | Traffic Class | CHANGING | Yes (1) | > > | ECT flag | CHANGING | No (2) | > > | CE flag | CHANGING | No (2) | > > | Flow Label | STATIC-DEF | N/A | > > | Payload Length | INFERRED | N/A | > > | Next Header | STATIC | N/A | > > | Hop Limit | CHANGING | Yes | > > | Source Address | STATIC-DEF | Yes | > > | Destination Address | STATIC-DEF | Yes | > > +-----------------------+---------------+------------+ > > > > (1) See comment for IPv4, above. > > Which comment for IPv4? We should probably clarify that the field > has a different name, i.e. refer to the actual v4 field. > > > > 4.5 Summary of replication > > > > From the above analysis, it can be seen that there are reasonable > > grounds for exploiting redundancy between flows, as well as between > > packets within a flow. Simply consider the advantage of being able > > to elide the source and destination addresses for a repeated > > connection between two IPv6 endpoints. > > This summary is fine, but maybe we should also note already in this > summary that it is important to find a suitable trade-off, providing > the means of replicating a field will always imply a cost, and must > thus be justified by a reasonably gain. > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Feb 25 10:08:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02774 for ; Tue, 25 Feb 2003 10:08:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PFHeP03726 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 10:17:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFHep03723 for ; Tue, 25 Feb 2003 10:17:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02753 for ; Tue, 25 Feb 2003 10:08:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFHHp03687; Tue, 25 Feb 2003 10:17:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFG6p03639 for ; Tue, 25 Feb 2003 10:16:06 -0500 Received: from sune.degermark.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02700 for ; Tue, 25 Feb 2003 10:06:30 -0500 (EST) Received: from gaston (gaston.DEGERMARK.NET [192.168.1.8]) by sune.degermark.net (8.12.6/8.12.6) with SMTP id h1PFAlAI013370; Tue, 25 Feb 2003 08:10:48 -0700 (MST) (envelope-from micke@cs.arizona.edu) Message-ID: <005b01c2dce0$4e8ccab0$0801a8c0@gaston> From: "Mikael Degermark" To: "Lars-Erik Jonsson \(EAB\)" , "Rohc \(E-mail\)" References: Subject: Re: [rohc] Updating the ROHC impl. guide Date: Tue, 25 Feb 2003 08:12:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Couple of comments below. ----- Original Message ----- From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Sent: Tuesday, February 25, 2003 5:30 AM Subject: [rohc] Updating the ROHC impl. guide > 4) Section 4.11 seems to be totally incorrect, as RTP SN is only > 16 bits long, and feedback packets can carry 16 bits. I do > not know where this section comes from, but it should be removed. I don't have the document in front of me, but the ESP SN is 32 bits, so that may explain it. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Tue Feb 25 12:31:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07712 for ; Tue, 25 Feb 2003 12:31:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PHf1216111 for rohc-archive@odin.ietf.org; Tue, 25 Feb 2003 12:41:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHf1p16108 for ; Tue, 25 Feb 2003 12:41:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07680 for ; Tue, 25 Feb 2003 12:31:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHeZp16079; Tue, 25 Feb 2003 12:40:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHdNp15906 for ; Tue, 25 Feb 2003 12:39:23 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07591 for ; Tue, 25 Feb 2003 12:29:44 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PHXanS018055; Tue, 25 Feb 2003 18:33:36 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Feb 2003 18:33:35 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Mikael Degermark'" , "Rohc (E-mail)" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Tue, 25 Feb 2003 18:33:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Micke, > -----Original Message----- > From: Mikael Degermark [mailto:micke@cs.arizona.edu] > Sent: den 25 februari 2003 16:12 > To: Lars-Erik Jonsson (EAB); Rohc (E-mail) > Subject: Re: [rohc] Updating the ROHC impl. guide > > > 4) Section 4.11 seems to be totally incorrect, as RTP SN is only > > 16 bits long, and feedback packets can carry 16 bits. I do > > not know where this section comes from, but it should be removed. > > I don't have the document in front of me, but the ESP SN is 32 bits, > so that may explain it. The current text says: "4.11. Multiple SN options in one feedback packet The length of the sequence number field in the original RTP header is 32 bits. A decompressor can't send back all the 32 bits in a feedback packet unless it uses multiple SN options in one feedback packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can contain variable number of feedback options and the options can appear in any order. A compressor - that wants to be conform to the specification - should be able to process multiple SN options in one feedback packet." You might be correct that it should have said ESP instead of RTP. Any opinions about what to do with this section? /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 26 05:20:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29970 for ; Wed, 26 Feb 2003 05:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QAUOZ27985 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 05:30:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAUOp27982 for ; Wed, 26 Feb 2003 05:30:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29961 for ; Wed, 26 Feb 2003 05:20:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QAUCp27967; Wed, 26 Feb 2003 05:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QATWp27902 for ; Wed, 26 Feb 2003 05:29:32 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29948 for ; Wed, 26 Feb 2003 05:19:34 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QANTnS004193 for ; Wed, 26 Feb 2003 11:23:29 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 11:23:28 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "Rohc (E-mail)" Date: Wed, 26 Feb 2003 11:23:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC interoperability test case draft updated Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all, The 3095 test case draft has been updated: draft-ietf-rohc-rtp-rfc3095-interoperability-01.txt A few test cases have been added for the RTP profile, based on observations from collecting interoperability status. Further, applicable tests have been listed also for the UDP and ESP profiles. Please let me know if there is something that is not covered by current tests. The updated draft marks tests (*) for which interoperability has been reported, but it should be noted that the current status documentation is neither complete nor guaranteed correct. The intension was to indicate how status is planned to be documented, and I am currently starting to collect interoperability reports. I will ask for interoperability reports from those I know have done interoperability testing of 3095, and all reports will be cross-verified. The detailed information on who have reported what will only be known to me and Carsten, while the draft will just show the status summary. /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 26 08:39:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04036 for ; Wed, 26 Feb 2003 08:39:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QDn1N09237 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 08:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QDn1p09226 for ; Wed, 26 Feb 2003 08:49:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04033 for ; Wed, 26 Feb 2003 08:38:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QDmLp09190; Wed, 26 Feb 2003 08:48:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QDlOp09108 for ; Wed, 26 Feb 2003 08:47:24 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03980 for ; Wed, 26 Feb 2003 08:37:22 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QDfDYg011947; Wed, 26 Feb 2003 14:41:14 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 14:41:13 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Mikael Degermark'" , "Rohc (E-mail)" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Wed, 26 Feb 2003 14:39:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > > 4) Section 4.11 seems to be totally incorrect, as RTP SN is > > > only 16 bits long, and feedback packets can carry 16 bits. > > > I do not know where this section comes from, but it should > > > be removed. > > > > I don't have the document in front of me, but the ESP SN is > > 32 bits, so that may explain it. > > The current text says: > > "4.11. Multiple SN options in one feedback packet > > The length of the sequence number field in the original RTP > header is 32 bits. A decompressor can't send back all the > 32 bits in a feedback packet unless it uses multiple SN options > in one feedback packet. Section 5.7.6.1 declares that a > FEEDABCK-2 packet can contain variable number of feedback > options and the options can appear in any order. > > A compressor - that wants to be conform to the specification - > should be able to process multiple SN options in one feedback > packet." > > You might be correct that it should have said ESP instead of RTP. > Any opinions about what to do with this section? What about rewriting the section to apply only to profile 3, ESP? /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 26 09:00:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05054 for ; Wed, 26 Feb 2003 09:00:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QEAJ310830 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 09:10:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEAJp10826 for ; Wed, 26 Feb 2003 09:10:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04911 for ; Wed, 26 Feb 2003 09:00:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEA7p10809; Wed, 26 Feb 2003 09:10:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QE8qp10700 for ; Wed, 26 Feb 2003 09:08:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04517; Wed, 26 Feb 2003 08:58:51 -0500 (EST) Message-Id: <200302261358.IAA04517@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 26 Feb 2003 08:58:51 -0500 Subject: [rohc] I-D ACTION:draft-ozegovic-mornar-dccp-epic-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DCCP Profile for EPIC Author(s) : J. Ozegovic, M. Mornar Filename : draft-ozegovic-mornar-dccp-epic-00.txt Pages : 20 Date : 2003-2-25 This draft describes a profile for compressing Datagram Congestion Control Protocol DCCP/IP using the Efficient Protocol Independent Compression (EPIC) [2] scheme. The RObust Header Compression [1] scheme is designed to compress packet headers over error prone channels. It is built around an extensible core framework that can be tailored to compress new protocol stacks by adding additional ROHC profiles. DCCP [3] is a relatively new protocol and has not yet entered the process of wide implementation. It is intended to provide a unified congestion control interface to the end user applications. It should offer the same unreliable transport as UDP does, and on the other hand, include mechanisms for congestion avoidance and control. This profile describes a new profile for ROHC which will allow DCCP/ IP headers to be compressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ozegovic-mornar-dccp-epic-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ozegovic-mornar-dccp-epic-00.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-ozegovic-mornar-dccp-epic-00.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: <2003-2-25155837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ozegovic-mornar-dccp-epic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ozegovic-mornar-dccp-epic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25155837.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 26 09:31:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07216 for ; Wed, 26 Feb 2003 09:31:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QEfSM13750 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 09:41:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEfSp13747 for ; Wed, 26 Feb 2003 09:41:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07160 for ; Wed, 26 Feb 2003 09:31:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEfCp13729; Wed, 26 Feb 2003 09:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEesp13699 for ; Wed, 26 Feb 2003 09:40:54 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07086 for ; Wed, 26 Feb 2003 09:30:51 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 14:34:45 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1D3@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Date: Wed, 26 Feb 2003 14:34:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] TCP compression profile Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, In the interests of kick-starting the discussion on TCP compression, we'd like to make our current implementation of a TCP profile available to the WG. We've based the implementation on the latest published TCP compression drafts, filling in the gaps where necessary to get a working solution. The main piece currently missing from the drafts is a description of how to encode each field in the TCP/IP header, so we've added a very simple proposal for this based on the current behaviour draft. We're hoping that the profile will evolve based on further input from the WG, so any comments would be gratefully received ;-) You can download the complete implementation from: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tcp.zip The zip file contains the following 5 modules, described below: http://sigcomp.srmr.co.uk/~rjp/RohcFn_TcpEncoding.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_StandardLibrary.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Primitives.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Harness.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tests.hs TCP encoding: Defines how to compress each field in a TCP/IP header, using encoding methods from the standard library (see below). The choice of encoding methods is based on the behaviour draft , but greatly simplified - we'd appreciate suggestions on how to make the profile more efficient, robust and future-proof. Standard library: The library of encoding methods from Chapter 7 of . Primitives: The basic maths functions and encoding methods from Chapter 6 of . Test harness: A simple front-end that can compress and decompress headers. It includes a really simple state machine based on - all it does at present is store the context between successive headers in a flow. More complex state management stuff (feedback, context replication) is on the to-do list. Tests: Some example TCP/IP flows, and a generic test suite to make sure that the implementation is working correctly. There's also some documentation, namely: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Instructions.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_To_Do_List.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Let us know if you have any problems running the code, or any suggestions for improvements etc. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed Feb 26 09:50:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08212 for ; Wed, 26 Feb 2003 09:50:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QF0NF14872 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 10:00:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QF0Np14869 for ; Wed, 26 Feb 2003 10:00:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08182 for ; Wed, 26 Feb 2003 09:50:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QF0Ap14853; Wed, 26 Feb 2003 10:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QExTp14768 for ; Wed, 26 Feb 2003 09:59:29 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08145 for ; Wed, 26 Feb 2003 09:49:26 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1QErEYf001533; Wed, 26 Feb 2003 15:53:15 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Feb 2003 15:53:14 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Mikael Degermark'" Cc: "Rohc (E-mail)" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Wed, 26 Feb 2003 15:51:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , That is ok with me. Then we keep it as it is, just changing the motivating example to ESP SN (which actually is 32 bits). OK? /L-E > -----Original Message----- > From: Mikael Degermark [mailto:micke@cs.arizona.edu] > Sent: den 26 februari 2003 22:27 > To: Lars-Erik Jonsson (EAB) > Subject: Re: [rohc] Updating the ROHC impl. guide > > > Wouldn't it be simplest to have a general rule that multiple > SN options > are allowed? The reason for having this rule is of course > ESP, but it seems > simplest to have an implementation allow it for any CID. > > Fits "be conservative in what you send, liberal in what you receive" > principle. > > Cheers, > > Micke > ----- Original Message ----- > From: "Lars-Erik Jonsson (EAB)" > To: "'Mikael Degermark'" ; "Rohc (E-mail)" > > Sent: Wednesday, February 26, 2003 6:39 AM > Subject: RE: [rohc] Updating the ROHC impl. guide > > > > > > > 4) Section 4.11 seems to be totally incorrect, as RTP SN is > > > > > only 16 bits long, and feedback packets can carry 16 bits. > > > > > I do not know where this section comes from, but it should > > > > > be removed. > > > > > > > > I don't have the document in front of me, but the ESP SN is > > > > 32 bits, so that may explain it. > > > > > > The current text says: > > > > > > "4.11. Multiple SN options in one feedback packet > > > > > > The length of the sequence number field in the original RTP > > > header is 32 bits. A decompressor can't send back all the > > > 32 bits in a feedback packet unless it uses multiple SN options > > > in one feedback packet. Section 5.7.6.1 declares that a > > > FEEDABCK-2 packet can contain variable number of feedback > > > options and the options can appear in any order. > > > > > > A compressor - that wants to be conform to the specification - > > > should be able to process multiple SN options in one feedback > > > packet." > > > > > > You might be correct that it should have said ESP instead of RTP. > > > Any opinions about what to do with this section? > > > > What about rewriting the section to apply only to profile 3, ESP? > > > > /L-E > > _______________________________________________ > > 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 mailnull@www1.ietf.org Wed Feb 26 12:31:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17031 for ; Wed, 26 Feb 2003 12:31:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QHfCp28923 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 12:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHfBp28919 for ; Wed, 26 Feb 2003 12:41:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17013 for ; Wed, 26 Feb 2003 12:31:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHevp28880; Wed, 26 Feb 2003 12:40:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QHddp28799 for ; Wed, 26 Feb 2003 12:39:39 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16900 for ; Wed, 26 Feb 2003 12:29:28 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 17:33:23 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1D5@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Cc: "'Lars-Erik Jonsson (EAB)'" Date: Wed, 26 Feb 2003 17:33:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] Updating the Formal Notation draft Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, Now that our TCP compression code is available, I'd like to think about updating the Formal Notation draft. As usual I've left this till the last minute, so there's no time left to discuss any major technical changes - fortunately I don't think that any are required at this stage. Based on our implementation experience, the only technical changes I'd like to propose are the following: 1. We should add "Self-describing variable-length values" from Section 4.5.6 of RFC 3095 to the library of encoding methods. 2. A function for calculating an n-bit CRC should be added to the maths library. Obviously, both of the above would be nice to have when generating the final TCP profile. I'd also like to propose some terminology changes to make the notation draft more readable, and to hopefully fix the inconsistencies between the notation draft and other TCP-related drafts. A list of these terminology changes is available from http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Comments on the above proposed changes would be much appreciated! Regards, Richard -----Original Message----- From: Price, Richard Sent: Wednesday, February 26, 2003 2:35 PM To: 'rohc@ietf.org' Subject: [rohc] TCP compression profile Hi, In the interests of kick-starting the discussion on TCP compression, we'd like to make our current implementation of a TCP profile available to the WG. We've based the implementation on the latest published TCP compression drafts, filling in the gaps where necessary to get a working solution. The main piece currently missing from the drafts is a description of how to encode each field in the TCP/IP header, so we've added a very simple proposal for this based on the current behaviour draft. We're hoping that the profile will evolve based on further input from the WG, so any comments would be gratefully received ;-) You can download the complete implementation from: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tcp.zip The zip file contains the following 5 modules, described below: http://sigcomp.srmr.co.uk/~rjp/RohcFn_TcpEncoding.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_StandardLibrary.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Primitives.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Harness.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tests.hs TCP encoding: Defines how to compress each field in a TCP/IP header, using encoding methods from the standard library (see below). The choice of encoding methods is based on the behaviour draft , but greatly simplified - we'd appreciate suggestions on how to make the profile more efficient, robust and future-proof. Standard library: The library of encoding methods from Chapter 7 of . Primitives: The basic maths functions and encoding methods from Chapter 6 of . Test harness: A simple front-end that can compress and decompress headers. It includes a really simple state machine based on - all it does at present is store the context between successive headers in a flow. More complex state management stuff (feedback, context replication) is on the to-do list. Tests: Some example TCP/IP flows, and a generic test suite to make sure that the implementation is working correctly. There's also some documentation, namely: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Instructions.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_To_Do_List.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Let us know if you have any problems running the code, or any suggestions for improvements etc. Regards, Richard _______________________________________________ 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 mailnull@www1.ietf.org Wed Feb 26 17:18:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29303 for ; Wed, 26 Feb 2003 17:18:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QMSdk16623 for rohc-archive@odin.ietf.org; Wed, 26 Feb 2003 17:28:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMSdp16620 for ; Wed, 26 Feb 2003 17:28:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29274 for ; Wed, 26 Feb 2003 17:18:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMSLp16607; Wed, 26 Feb 2003 17:28:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMRrp16582 for ; Wed, 26 Feb 2003 17:27:53 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29173 for ; Wed, 26 Feb 2003 17:17:39 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1QMOim11583 for ; Thu, 27 Feb 2003 00:24:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 00:21:34 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 00:21:33 +0200 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 14:21:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Wed, 26 Feb 2003 16:21:30 -0600 Message-ID: Thread-Topic: [rohc] Updating the ROHC impl. guide Thread-Index: AcLcy1V/3S+FZ2qJQRuh77wPWUWRpgBExQNw To: , X-OriginalArrivalTime: 26 Feb 2003 22:21:31.0028 (UTC) FILETIME=[69B16D40:01C2DDE5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QMRrp16583 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, Some comments below. Zhigang > 1) Section 4.9 should clarify that a UO-1-ID packet with an > Extension 3 must never be sent with RND flags that changes > the packet interpretation, i.e. that would violate the base > condition for UO-1-ID (at least one RND value must be 0). > The last line of the first paragraph is also redundant and > unclear. > > * Proposed modified text for the first paragraph of section 4.9: > > "Extension-3 is applied to give values and indicate changes to > fields other than SN, TS and IP-ID in IP header(s) and RTP > header. In case of UO-1-ID packets, it should be noted that > values provided in extensions do not update the context, with > an exception for SN, TS and IP-ID fields, which always update > the context (Section 5.7.3.). It should also be noted that a > UO-1-ID packet with Extension 3 must never be sent with RND > flags that changes the packet interpretation, i.e. that would > violate the base condition for UO-1-ID (at least one RND value > must be 0)." Sorry, I probably missed the discussions in the past, but what is the reason for this section? Why Extension-3 needs special clarification, but not other extensions? I thought the following texts from RFC 3095 are already clear. Section 5.7: (The same text is repeated in section 5.7.5.1. I remember we intentionally make it redundantly clear, as it is a crucial point for correct parsing.) "When no IPv4 header is present in the static context, or the RND flags for all IPv4 headers in the context have been established to be 1, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used. While in the transient state in which an RND flag is being established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used. This implies that the RND flag(s) of the Extension 3 may have to be inspected before the format of a base header carrying an Extension 3 can be determined." Section 5.7.3: "Note: UO-1-ID cannot be used if there is no IPv4 header in the context or if value(RND) and value(RND2) are both 1." Section 5.7.3: UO-1-ID packets update context(IP-ID). Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context. > 6) As suggested by Zhigang and agreed on the list, we should give > an additional clarification in section 4.7. > > * Proposed additional paragraph in 4.7: > "An updating packet thus updates the reference values of all > header fields, either explicitly or implicitly. In UO-mode, > all packets are updating packets (except for UO-1-ID, which > only updates TS, SN and IP-ID, see 5.7.3), while in R-mode > all packets with a CRC are updating packets." The above text has some self-contradiction. For example, the text seems to say UO-1-ID is not an updating packet, which is untrue. It looks to me that we are clarifying two things here: a) what are updating packets, and b) what do they update. So, can we re-arrange above text as follows? "In UO-mode, all packets are updating packets, while in R-mode all packets with a CRC are updating packets. An updating packet in R-mode updates the reference values of all header fields, either explicitly or implicitly. Same is true for updating packets in UO-mode, except for UO-1-ID, which only updates TS, SN and IP-ID (see 5.7.3)." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 04:09:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23501 for ; Thu, 27 Feb 2003 04:09:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R9Jj201354 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 04:19:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9Jip01351 for ; Thu, 27 Feb 2003 04:19:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23493 for ; Thu, 27 Feb 2003 04:09:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9JTp01339; Thu, 27 Feb 2003 04:19:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R9Ijp01290 for ; Thu, 27 Feb 2003 04:18:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23478 for ; Thu, 27 Feb 2003 04:08:19 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1R9CEnS017126 for ; Thu, 27 Feb 2003 10:12:14 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 27 Feb 2003 10:12:14 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the ROHC impl. guide Date: Thu, 27 Feb 2003 10:06:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Zhigang, The issues addressed in the implemeter's guide are mainly issues identified during implementation (interoperability test discussions). Some of the issues are clear from 3095, but repeated questions still indicate that additional reminders to implementers are useful. > > 1) Section 4.9 should clarify that a UO-1-ID packet with an > > Extension 3 must never be sent with RND flags that changes > > the packet interpretation, i.e. that would violate the base > > condition for UO-1-ID (at least one RND value must be 0). > > The last line of the first paragraph is also redundant and > > unclear. > > > > * Proposed modified text for the first paragraph of section 4.9: > > > > "Extension-3 is applied to give values and indicate changes to > > fields other than SN, TS and IP-ID in IP header(s) and RTP > > header. In case of UO-1-ID packets, it should be noted that > > values provided in extensions do not update the context, with > > an exception for SN, TS and IP-ID fields, which always update > > the context (Section 5.7.3.). It should also be noted that a > > UO-1-ID packet with Extension 3 must never be sent with RND > > flags that changes the packet interpretation, i.e. that would > > violate the base condition for UO-1-ID (at least one RND value > > must be 0)." > > Sorry, I probably missed the discussions in the past, but what is the > reason for this section? Why Extension-3 needs special clarification, > but not other extensions? I thought the following texts from RFC 3095 > are already clear. Section 4.9 of the implementer's guide was originally written for the purpose of reminding implementers of something that is actually clear in 3095, as there seemed to be confusion about UO-1-ID and its updating properties for fields in Extension 3. This should be clear from 3095, but all questions motivated an additional reminder. The point about RND in such packets is however something that is not clear from 3095. If RND is changed in an UOR-2 with Extension 3, the decompressor must re-parse the packet (as explained in 4.10), but if this happens for UO-1-ID, something is obviously wrong. > > 6) As suggested by Zhigang and agreed on the list, we should give > > an additional clarification in section 4.7. > > > > * Proposed additional paragraph in 4.7: > > "An updating packet thus updates the reference values of all > > header fields, either explicitly or implicitly. In UO-mode, > > all packets are updating packets (except for UO-1-ID, which > > only updates TS, SN and IP-ID, see 5.7.3), while in R-mode > > all packets with a CRC are updating packets." > > The above text has some self-contradiction. For example, the text > seems to say UO-1-ID is not an updating packet, which is untrue. OK, let's put it this way then: "An updating packet thus updates the reference values of all header fields, either explicitly or implicitly. In UO-mode, all packets are updating packets (note that UO-1-ID packets only update TS, SN and IP-ID, see 5.7.3), while in R-mode all packets with a CRC are updating packets." Thanks! /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 05:16:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24355 for ; Thu, 27 Feb 2003 05:16:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RAQP704954 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 05:26:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RAQPp04951 for ; Thu, 27 Feb 2003 05:26:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24326 for ; Thu, 27 Feb 2003 05:15:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RAQAp04936; Thu, 27 Feb 2003 05:26:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RAPEp04880 for ; Thu, 27 Feb 2003 05:25:14 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24306 for ; Thu, 27 Feb 2003 05:14:46 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1RAIfnS012240; Thu, 27 Feb 2003 11:18:41 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 27 Feb 2003 11:18:40 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Price, Richard'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Thu, 27 Feb 2003 11:13:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, I hope this input will be useful for the further TCP profile work, i.e. for defining the compressed header formats, but it is a rather substantial material to read and understand (especially considering previous problems of getting people involved in these notation discussions) so we will have to give this some time. Anyway, I have to provide some comments and guidelines on procedural matters, considering this input. This is an IETF WG, and input is expected to be provided either: 1) in internet-drafts, or 2) in messages to the WG mail list Some material, like implementations, might of course be difficult to provide through those channels, and then exceptions may have to be made. However, such exceptions should only be made when really necessary, both because we have common IETF principles to simplify for all involved parties and be consistent, and because of archival reasons. Except for implementations, material for the WG to consider must be posted through our official channels (drafts or mail list). /L-E -------------------------------------- Lars-Erik Jonsson IETF ROHC WG Chair E-mail: lars-erik.jonsson@ericsson.com Phone: +46 920 20 21 07 Home: +46 920 999 57 My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 05:18:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24399 for ; Thu, 27 Feb 2003 05:18:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RASF905080 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 05:28:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RASFp05077 for ; Thu, 27 Feb 2003 05:28:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24394 for ; Thu, 27 Feb 2003 05:17:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RAS2p05063; Thu, 27 Feb 2003 05:28:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RARgp05048 for ; Thu, 27 Feb 2003 05:27:42 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24390 for ; Thu, 27 Feb 2003 05:17:14 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1RAL9Yf026829 for ; Thu, 27 Feb 2003 11:21:09 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 27 Feb 2003 11:21:09 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Thu, 27 Feb 2003 11:15:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > The main piece currently missing from the drafts is a description > of how to encode each field in the TCP/IP header, so we've added a > very simple proposal for this based on the current behavior draft. How to encode the original fields are rather well "suggested" in the behavior draft, but what we are still missing in the profile draft is (1) a description and summary of what "control information" is needed (e.g. context replication), (2) a summary of how we then have decided to compress each piece of information (original fields+control), and (3, most concrete) defining the actual compressed header formats, i.e. the bits on the wire. 1) is partially already done in the draft, but some pieces are still missing. The notation was intended to either be used as a descriptive language to do 2) in the draft, or be used as a tool to by-pass 2) and together with some encoding method produce 3) directly for inclusion in the draft. It is not clear to me at this point whether people are considering the former or the latter approach. If we do put 2) in the profile draft, we have taken one step and may then decide how to go further to define the actual compressed formats. On the other hand, if we decide to go directly to 3), we need to agree on how to use the notation as a tool to generate compressed header formats, and we must find a good way of documenting these in the profile specification. A third approach is of course not to use the notation at all, but just define the compressed formats as we did in RFC 3095. Assuming that we do not take this third approach, the first step would in any case be to agree on the notation. Any opinions on if the notation would be about the same independent of how it will be used. BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 07:49:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28276 for ; Thu, 27 Feb 2003 07:49:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RCxoA15089 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 07:59:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCxop15086 for ; Thu, 27 Feb 2003 07:59:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28225 for ; Thu, 27 Feb 2003 07:49:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCxXp15027; Thu, 27 Feb 2003 07:59:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCtkp14693 for ; Thu, 27 Feb 2003 07:55:46 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27836 for ; Thu, 27 Feb 2003 07:45:15 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 12:49:11 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1D6@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Thu, 27 Feb 2003 12:49:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, So, just to check, is there any part of our implementation that would be useful to document separately (either in internet-drafts or on the mailing list)? The implementation has two new encoding methods not currently described in the notation draft (see my previous post on updating the formal notation). I believe it would be good to add these to the next version of the draft - if no-one objects, I can make this update before the deadline next week. The other new material that we've provided is a set of test vectors for the implementation (including some TCP flows, as well as some generic tests to make sure that the implementation is working correctly). Might it be worth putting these in a draft at some stage, like we did for the SigComp torture tests? Regards, Richard > -----Original Message----- > From: Lars-Erik Jonsson (EAB) > [mailto:Lars-Erik.Jonsson@epl.ericsson.se] > Sent: Thursday, February 27, 2003 10:13 AM > To: Price, Richard; 'rohc@ietf.org' > Subject: RE: [rohc] TCP compression profile > > > Richard, > > I hope this input will be useful for the further TCP profile work, > i.e. for defining the compressed header formats, but it is a rather > substantial material to read and understand (especially considering > previous problems of getting people involved in these notation > discussions) so we will have to give this some time. > > Anyway, I have to provide some comments and guidelines on procedural > matters, considering this input. This is an IETF WG, and input is > expected to be provided either: > 1) in internet-drafts, or > 2) in messages to the WG mail list > > Some material, like implementations, might of course be difficult > to provide through those channels, and then exceptions may have to > be made. However, such exceptions should only be made when really > necessary, both because we have common IETF principles to simplify > for all involved parties and be consistent, and because of archival > reasons. Except for implementations, material for the WG to consider > must be posted through our official channels (drafts or mail list). > > /L-E > > -------------------------------------- > Lars-Erik Jonsson > IETF ROHC WG Chair > E-mail: lars-erik.jonsson@ericsson.com > Phone: +46 920 20 21 07 > Home: +46 920 999 57 > > My opinions are my personal opinions and should not be considered > as the opinions of my employer, if not explicitly stated. > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 10:54:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09011 for ; Thu, 27 Feb 2003 10:54:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RG4S029917 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 11:04:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RG4Rp29914 for ; Thu, 27 Feb 2003 11:04:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08996 for ; Thu, 27 Feb 2003 10:53:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RG2rp29827; Thu, 27 Feb 2003 11:02:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RG1pp29783 for ; Thu, 27 Feb 2003 11:01:51 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08889 for ; Thu, 27 Feb 2003 10:51:17 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:55:12 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1D8@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Lars-Erik Jonsson (EAB)'" , "'rohc@ietf.org'" Subject: RE: [rohc] TCP compression profile Date: Thu, 27 Feb 2003 15:55:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > The main piece currently missing from the drafts is a description > > of how to encode each field in the TCP/IP header, so we've added a > > very simple proposal for this based on the current behavior draft. > > How to encode the original fields are rather well "suggested" in the > behavior draft This certainly seems to be the case based on our initial test TCP flows. One interesting open issue, however, is the level of complexity needed in the final TCP encoding. Our current implementation only uses a very basic set of packet formats, designed specifically to be human-readable. We could improve the efficiency, robustness and future-proofing by following the behaviour draft more exactly, at a cost of making the resulting packet formats harder to understand. > but what we are still missing in the profile draft > is (1) a description and summary of what "control information" is > needed (e.g. context replication), (2) a summary of how we then have > decided to compress each piece of information (original fields+control), > and (3, most concrete) defining the actual compressed header formats, > i.e. the bits on the wire. 1) is partially already done in the draft, > but some pieces are still missing. The notation was intended to either > be used as a descriptive language to do 2) in the draft, or be used as > a tool to by-pass 2) and together with some encoding method produce 3) > directly for inclusion in the draft. It is not clear to me at this > point whether people are considering the former or the latter approach. > If we do put 2) in the profile draft, we have taken one step and may > then decide how to go further to define the actual compressed formats. If we choose the former approach then the notation defines which encoding methods are applied to which fields (including the "control" fields not present in the original TCP/IP header). To get from this to "bits on the wire", we just need to define a library of 4 or 5 basic encoding methods for the notation to use. > On the other hand, if we decide to go directly to 3), we need to agree > on how to use the notation as a tool to generate compressed header > formats, and we must find a good way of documenting these in the > profile specification. A third approach is of course not to use the > notation at all, but just define the compressed formats as we did in > RFC 3095. The above is a good summary of the two ways the formal notation could be used to provide the "bits on the wire" for the TCP profile. In both cases we need to somehow define a basic library of encoding methods - in RFC 3095 this is just done by hand, and in the current notation draft we do exactly the same. The difference between the two approaches is therefore quite simple: we need to define "packet formats" that apply one or more encoding methods to each field, and we can do this either using the formal notation, or in the "RFC 3095 style" using a combination of diagrams and accompanying text. Which of the above approaches to use is a matter of opinion (we could even provide the packet formats using both, although I'm not keen on this as we then have the additional worry of synchronising the two approaches and making sure that they define the same bits on the wire). My own preference is that the packet formats should be defined using the formal notation (not that I'm biased of course!). The main advantage of this is that, as Carsten pointed out in Atlanta, several programming languages have a compiler for the formal notation already built-in. So all of the packet formats can be implemented for free, just by pasting the description of TCP/IP into the compiler. As a bonus, this will help to eliminate misunderstandings about how the packet formats behave (e.g. which fields update the context, which offsets to use for LSB encoding etc.) > Assuming that we do not take this third approach, the first step would > in any case be to agree on the notation. Any opinions on if the > notation would be about the same independent of how it will be used. I don't believe that the notation will need to change depending on which of the above approaches is used. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 12:22:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12554 for ; Thu, 27 Feb 2003 12:22:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RHWLn05394 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 12:32:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHWLp05391 for ; Thu, 27 Feb 2003 12:32:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12500 for ; Thu, 27 Feb 2003 12:21:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHW7p05360; Thu, 27 Feb 2003 12:32:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHVBp05290 for ; Thu, 27 Feb 2003 12:31:11 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12464 for ; Thu, 27 Feb 2003 12:20:30 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 17:24:25 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F1D9@rsys002a.roke.co.uk> From: "Price, Richard" To: "'rohc@ietf.org'" Subject: FW: [rohc] Updating the Formal Notation draft Date: Thu, 27 Feb 2003 17:24:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, I have a couple of editorial proposals for making the notation draft a bit simpler and more readable. Comments welcome! Section 3.1 talks about ordinary BNF, which is irrelevant to the definition of the formal notation. For clarity I propose to delete this section from the draft. Section 4.6 on "control fields" is redundant given the information contained in . Since Ghyslain explains how control fields work much better than I do, I propose to leave the ROHC-TCP draft as it is and delete Section 4.6 from the formal notation. Conversely, one issue that the current draft doesn't explain very well is the scope of the formal notation - what it does, what it doesn't do, how it relates to the ROHC framework and to ROHC profiles etc. I'd like to add a new section to clarify this issue: 3.X. Scope of ROHC-FN The following section describes the scope of ROHC-FN, and explains how it relates to the overall ROHC framework and to specific ROHC profiles. The ROHC framework is common to all profiles, and provides generic features such as padding and segmentation of the compressed packets (useful if the link layer can only handle a limited range of packet sizes). A ROHC profile is a description of how to compress a certain protocol stack over a certain type of link. For example, ROHC profiles are available for RTP/UDP/IP and many other protocol stacks. Each ROHC profile can be further subdivided into the following two components: a) Packet formats for compressing and decompressing headers b) State machine The job of the packet formats is to define how to compress and decompress headers. The packet formats must define the compressed version of each uncompressed header (and vice versa). The packet formats will typically compress headers relative to a "context" of field values from previous headers in a flow. This improves the overall compression ratio, due to taking into account redundancies between successive headers. The job of the state machine is to ensure that the profile is robust against bit errors and dropped packets. The state machine manages the context, providing feedback and other mechanisms to ensure that the compressor and decompressor contexts are kept in sync. ROHC-FN is designed to help provide the packet formats for use in new ROHC profiles. It offers a library of encoding methods for compressing fields, and a mechanism for combining these encoding methods to create new packet formats tailored to a specific protocol stack. Note however that the state machine for the new profiles is beyond the scope of ROHC-FN, and must be provided separately. Comments on the above text would be much appreciated! Regards, Richard -----Original Message----- From: Price, Richard Sent: Wednesday, February 26, 2003 5:33 PM To: 'rohc@ietf.org' Cc: 'Lars-Erik Jonsson (EAB)' Subject: [rohc] Updating the Formal Notation draft Hi, Now that our TCP compression code is available, I'd like to think about updating the Formal Notation draft. As usual I've left this till the last minute, so there's no time left to discuss any major technical changes - fortunately I don't think that any are required at this stage. Based on our implementation experience, the only technical changes I'd like to propose are the following: 1. We should add "Self-describing variable-length values" from Section 4.5.6 of RFC 3095 to the library of encoding methods. 2. A function for calculating an n-bit CRC should be added to the maths library. Obviously, both of the above would be nice to have when generating the final TCP profile. I'd also like to propose some terminology changes to make the notation draft more readable, and to hopefully fix the inconsistencies between the notation draft and other TCP-related drafts. A list of these terminology changes is available from http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Comments on the above proposed changes would be much appreciated! Regards, Richard -----Original Message----- From: Price, Richard Sent: Wednesday, February 26, 2003 2:35 PM To: 'rohc@ietf.org' Subject: [rohc] TCP compression profile Hi, In the interests of kick-starting the discussion on TCP compression, we'd like to make our current implementation of a TCP profile available to the WG. We've based the implementation on the latest published TCP compression drafts, filling in the gaps where necessary to get a working solution. The main piece currently missing from the drafts is a description of how to encode each field in the TCP/IP header, so we've added a very simple proposal for this based on the current behaviour draft. We're hoping that the profile will evolve based on further input from the WG, so any comments would be gratefully received ;-) You can download the complete implementation from: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tcp.zip The zip file contains the following 5 modules, described below: http://sigcomp.srmr.co.uk/~rjp/RohcFn_TcpEncoding.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_StandardLibrary.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Primitives.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Harness.hs http://sigcomp.srmr.co.uk/~rjp/RohcFn_Tests.hs TCP encoding: Defines how to compress each field in a TCP/IP header, using encoding methods from the standard library (see below). The choice of encoding methods is based on the behaviour draft , but greatly simplified - we'd appreciate suggestions on how to make the profile more efficient, robust and future-proof. Standard library: The library of encoding methods from Chapter 7 of . Primitives: The basic maths functions and encoding methods from Chapter 6 of . Test harness: A simple front-end that can compress and decompress headers. It includes a really simple state machine based on - all it does at present is store the context between successive headers in a flow. More complex state management stuff (feedback, context replication) is on the to-do list. Tests: Some example TCP/IP flows, and a generic test suite to make sure that the implementation is working correctly. There's also some documentation, namely: http://sigcomp.srmr.co.uk/~rjp/RohcFn_Instructions.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_To_Do_List.txt http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt Let us know if you have any problems running the code, or any suggestions for improvements etc. Regards, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 14:48:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18809 for ; Thu, 27 Feb 2003 14:48:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RJwVU16790 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 14:58:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJwVp16787 for ; Thu, 27 Feb 2003 14:58:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18788 for ; Thu, 27 Feb 2003 14:47:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJwIp16777; Thu, 27 Feb 2003 14:58:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RJvhp16753 for ; Thu, 27 Feb 2003 14:57:43 -0500 Received: from nmh.informatik.uni-bremen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18783 for ; Thu, 27 Feb 2003 14:47:03 -0500 (EST) Received: from ringo.informatik.uni-bremen.de.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id h1RJout21002; Thu, 27 Feb 2003 20:50:59 +0100 (MET) X-Mailer: emacs 21.3.50.1 (via feedmail 8 I) Original-Sender: cabo@ringo.local. To: rohc@ietf.org Subject: [rohc] Updating the Formal Notation draft From: cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann) Date: 27 Feb 2003 20:50:54 +0100 Message-ID: Lines: 132 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , ROHCers, some comments (WG chair hat off) on http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt below. Gruesse, Carsten Based on our implementation experience we'd like to propose a few changes to the current formal notation draft (see ): Terminology changes: The following changes have no technical effect on the notation, but will hopefully make the draft easier to understand: 1. We should give the notation a better name, e.g. ROHC-FN (Formal Notation for Robust Header Compression). If, as you explain in a later message, it is just about packet formats, it probably should be named ROHC-FNPF or some such? 2. The "rules" should be called "encoding methods" to bring the terminology in line with RFC 3095. d/c (don't care). 3. The "labels" should be renamed "temporary variables" to make it clearer what they actually do! Hmm, this creates the impression the notation has imperative semantics. I thought we were trying to avoid this. Bindings? 4. The names of encoding methods and variables should be cleanly separated, e.g. by using lowercase for the names of encoding methods and uppercase for variable names. This might conflict with the choice of Haskell (uppercase is reserved for specific things in that language). (It also would conflict with Prolog.) Parsing the notation using Haskell: A drawback with the current notation draft is that even though it's based on a well-known language (namely BNF from RFC 2234), some proprietary extensions are needed to make the notation powerful enough to describe the headers we're interested in. This means that off-the-shelf BNF parsers like yacc can't handle the notation in its current form. A simpler approach would be to base the notation on a more powerful language, which already offers all of the features we need as standard. A number of sufficiently powerful languages are already available (Prolog, Haskell, Mercury etc.) - we propose to use Haskell because its syntax is closest to the notation currently documented in . This is a quite weak argument for the choice of notational basis. Obviously, we need to have a better one. (I'm making this argument not only because I did my first prototype in Prolog...) Only a handful of changes are needed to convert the notation into executable Haskell code: 1. We should create new encoding methods using the symbol "=" rather than "::=". d/c (in Prolog, it's something different again). 2. In a list expression (e.g. [2 * j for j in 0..n]) the reserved words "for" and "in" should be replaced by the symbols "|" and "<-". The base language wins. Miscellaneous changes: The following changes aren't required to make the notation Haskell-compatible, but we think that they're a good idea anyway: 1. We should add "Self-describing variable-length values" from Section 4.5.6 of RFC 3095 to the library of encoding methods. Sure. The Library will grow with our use of the notation. 2. A function for calculating an n-bit CRC should be added to the maths library. Sure. 3. We should make the notation more readable by removing the unnecessary parentheses and commas, and just delimiting the parameters of an encoding method using whitespace instead. Readability is in the eye of the beholder... In contrast to the lambda crowd, I prefer the assignment of roles to things to be clearly visible. In the end, of course, the base language we choose wins... 4. Lists of elements should be clearly marked using a well-known symbol (e.g. square braces). 5. Currently the lower bound for the number of elements in a list is inclusive but the upper bound is exclusive. This is confusing - for consistency, both bounds should be inclusive. 6. The "floor" function should be renamed "div" (because "floor" is a well-known term that means something completely different). 7. The "Null" keyword should be renamed "Nil" (because "Null" is a well-known term that means something completely different). 8. When we need the integer value of a field, we currently just quote the field name and assume that readers know that we want the integer value rather than the bits. This might get confusing, so for clarity we propose to explicitly indicate whenever we need the integer value of a field (e.g. by writing "val" before the field name). This is obviously required. 9. In the current notation, when we define new parameters we need to explicitly state the parameter type (integer, text string etc.). It isn't actually necessary to do this, because a compiler can infer the parameter types just by looking at the expressions in which the parameters are used. For example, if we encounter the expression "m + n" then we know that m and n must both be integers. So for simplicity, we should make parameter types optional (or not bother with them at all). Stating the types may increase understandability. Again, of course, the base language wins. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu Feb 27 15:44:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22074 for ; Thu, 27 Feb 2003 15:44:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RKsHq20471 for rohc-archive@odin.ietf.org; Thu, 27 Feb 2003 15:54:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKsHp20468 for ; Thu, 27 Feb 2003 15:54:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21970 for ; Thu, 27 Feb 2003 15:43:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKs6p20453; Thu, 27 Feb 2003 15:54:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKrwp20438 for ; Thu, 27 Feb 2003 15:53:58 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21919 for ; Thu, 27 Feb 2003 15:43:18 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1RKlPO16353 for ; Thu, 27 Feb 2003 14:47:25 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Feb 2003 14:47:13 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 27 Feb 2003 12:47:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Thu, 27 Feb 2003 14:47:12 -0600 Message-ID: Thread-Topic: [rohc] Updating the ROHC impl. guide Thread-Index: AcLeQHiICi0fGwVeS8qWyxSWEs1RiAAP+ufQ To: , X-OriginalArrivalTime: 27 Feb 2003 20:47:13.0835 (UTC) FILETIME=[682807B0:01C2DEA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKrwp20439 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, > Some of the issues are clear from 3095, but repeated questions still > indicate that additional reminders to implementers are useful. The reason I asked was that my proposal to add some texts back in April 2002 were rejected on the basis that they were clear from 3095, even though they addressed questions that have been raised in ROHC mailing list. So, I guess above is the new criteria for content of the user guide? > The point about RND > in such packets is however something that is not clear from 3095. If > RND is changed in an UOR-2 with Extension 3, the decompressor must > re-parse the packet (as explained in 4.10), but if this happens for > UO-1-ID, something is obviously wrong. I thought it's clear from the following text in 3095. "While in the transient state in which an RND flag is being established, the packet types R-1-ID, R-1-TS, UO-1-ID, and UO-1-TS MUST NOT be used." > > The above text has some self-contradiction. For example, the text > > seems to say UO-1-ID is not an updating packet, which is untrue. > > OK, let's put it this way then: > > "An updating packet thus updates the reference values of all > header fields, either explicitly or implicitly. In UO-mode, > all packets are updating packets (note that UO-1-ID packets > only update TS, SN and IP-ID, see 5.7.3), while in R-mode > all packets with a CRC are updating packets." But there is still a controdiction between the first sentence and the second one. In fact, the first sentence is correct only for R-mode. For UO-mode, what an updating packet updates depends on packet type. My proposed text in earlier email (copied below again) solves the above problem. I'm wondering do you disagree with any particular point in the text? "In UO-mode, all packets are updating packets, while in R-mode all packets with a CRC are updating packets. An updating packet in R-mode updates the reference values of all header fields, either explicitly or implicitly. Same is true for updating packets in UO-mode, except for UO-1-ID, which only updates TS, SN and IP-ID (see 5.7.3)." BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 28 03:48:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17593 for ; Fri, 28 Feb 2003 03:48:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1S8wRe08664 for rohc-archive@odin.ietf.org; Fri, 28 Feb 2003 03:58:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S8wQp08661 for ; Fri, 28 Feb 2003 03:58:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17581 for ; Fri, 28 Feb 2003 03:47:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S8wDp08651; Fri, 28 Feb 2003 03:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S8ulp08567 for ; Fri, 28 Feb 2003 03:56:47 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17548 for ; Fri, 28 Feb 2003 03:45:53 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1S8nmnS009556 for ; Fri, 28 Feb 2003 09:49:48 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Feb 2003 09:49:48 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: rohc@ietf.org Subject: RE: [rohc] Updating the ROHC impl. guide Date: Fri, 28 Feb 2003 09:49:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , > > Some of the issues are clear from 3095, but repeated questions still > > indicate that additional reminders to implementers are useful. > > So, I guess above is the new criteria for content of the user guide? Well, the section we talk about has been there for quite a while. Anyway, there is no single criteria, we have to look at each case. We do not want this document to grow too much, but when questions are repeatedly asked, we have to consider adding something. When things have been added during the last year, it has been a result of repeated questions on the interops, and/or the mailing list. The additions we have made have lately been related to very special details, which probably (hopefully) indicates that we should not have to add much more to this document (but it will stay as an I-D, as previously agreed). Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 28 10:14:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01103 for ; Fri, 28 Feb 2003 10:14:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SFOlm03344 for rohc-archive@odin.ietf.org; Fri, 28 Feb 2003 10:24:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFOkp03341 for ; Fri, 28 Feb 2003 10:24:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01094 for ; Fri, 28 Feb 2003 10:13:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFOLp03317; Fri, 28 Feb 2003 10:24:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFLHp03121 for ; Fri, 28 Feb 2003 10:21:17 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01025 for ; Fri, 28 Feb 2003 10:10:15 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1SFEAnT020281 for ; Fri, 28 Feb 2003 16:14:10 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 28 Feb 2003 16:14:10 +0100 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'rohc@ietf.org'" Subject: RE: [rohc] Updating the Formal Notation draft Date: Fri, 28 Feb 2003 16:14:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Richard, In general, I think we should not make any changes to the actual notation at this point (although the draft might be updated for other reasons), as we do not have a common view either of how to proceed with this, or for example if we should do this "Haskell"-step, or something similar using another functional language. We need to discuss this more, then we can get a stable ground for the content before we do the changes. However, we might want to update it just to change the title, and maybe some of the "environmental texts". I've provided some comments on this below. BR /L-E > Section 4.6 on "control fields" is redundant given the > information contained in . Well, it might be worth mentioning that information that can be noted is either original header fields, or additional control fields introduced by the compression scheme. > I propose to leave the ROHC-TCP draft as it is and delete > Section 4.6 from the formal notation. Of course, the TCP control field can not be discussed as part of the general notation. > Conversely, one issue that the current draft doesn't explain > very well is the scope of the formal notation - what it does, > what it doesn't do, how it relates to the ROHC framework and > to ROHC profiles etc. This is indeed very important, and should be done before we go much further. However, I do not think we do have a common understanding about that, as it has never been settled. > I'd like to add a new section to clarify this issue: > > 3.X. Scope of ROHC-FN > > The following section describes the scope of ROHC-FN, and > explains how it relates to the overall ROHC framework and to > specific ROHC profiles. > > The ROHC framework is common to all profiles, and provides > generic features such as padding and segmentation of the > compressed packets (useful if the link layer can only handle > a limited range of packet sizes). Well, the framework provides the base for all ROHC compression. It defines the profile concept, which makes ROHC a general platform for compression schemes. It sets link layer requirements, and especially negotiation requirements for all ROHC profiles. It defines a set of common functions, as segmentation, CID's, and padding. It also defines common packet formats (IR, IR-DYN, Feedback, Short-CID expander, etc), and it defines a generic, profile independent, handling of feedback. One can also say that it defines the general principles for doing ROHC compression. > A ROHC profile is a description of how to compress a certain > protocol stack over a certain type of link. For example, ROHC > profiles are available for RTP/UDP/IP and many other protocol > stacks. > > Each ROHC profile can be further subdivided into the following > two components: > > a) Packet formats for compressing and decompressing headers I would say "compressed packet formats" > b) State machine I am not sure "state machine" captures all the rest that is there, but I'll think more about this. > ROHC-FN is designed to help provide the packet formats for use > in new ROHC profiles. It is a notation form for the information to compress, it is not clear to me at this point how far you really get with the notation. > Comments on the above text would be much appreciated! This is a good start, as I think it is essential that we try to define what the notation is, what it will be used for, and how it fits in the "big ROHC picture". _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 28 11:14:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03377 for ; Fri, 28 Feb 2003 11:14:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGPTg07982 for rohc-archive@odin.ietf.org; Fri, 28 Feb 2003 11:25:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGPSp07979 for ; Fri, 28 Feb 2003 11:25:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03331 for ; Fri, 28 Feb 2003 11:14:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGPDp07945; Fri, 28 Feb 2003 11:25:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGOhp07899 for ; Fri, 28 Feb 2003 11:24:43 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03293 for ; Fri, 28 Feb 2003 11:13:39 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SGHkO16510 for ; Fri, 28 Feb 2003 10:17:46 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 10:17:33 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 10:16:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Fri, 28 Feb 2003 10:16:39 -0600 Message-ID: Thread-Topic: [rohc] Updating the ROHC impl. guide Thread-Index: AcLfBqoUCCfE/rG/SJOLyrZI8QQcTAAOxsYA To: , X-OriginalArrivalTime: 28 Feb 2003 16:16:43.0199 (UTC) FILETIME=[C85B44F0:01C2DF44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SGOhp07900 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Anyway, there is no single criteria, we have to look at each case. Since this is a WG document, it would help to have some kind of criteria/rules for what should be included and what should not. Also, if the criteria change, it should be announced/documented. This can help discussions and save time, especially when there is disagreement. Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri Feb 28 11:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03926 for ; Fri, 28 Feb 2003 11:30:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1SGfJm09723 for rohc-archive@odin.ietf.org; Fri, 28 Feb 2003 11:41:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGfJp09720 for ; Fri, 28 Feb 2003 11:41:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03915 for ; Fri, 28 Feb 2003 11:30:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGf6p09674; Fri, 28 Feb 2003 11:41:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SGe3p09606 for ; Fri, 28 Feb 2003 11:40:03 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03898 for ; Fri, 28 Feb 2003 11:28:59 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SGX7O20106 for ; Fri, 28 Feb 2003 10:33:07 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 10:32:55 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 10:32:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] Updating the ROHC impl. guide Date: Fri, 28 Feb 2003 10:32:10 -0600 Message-ID: Thread-Topic: [rohc] Updating the ROHC impl. guide Thread-Index: AcLfBqoUCCfE/rG/SJOLyrZI8QQcTAAPmvsA To: , X-OriginalArrivalTime: 28 Feb 2003 16:32:11.0689 (UTC) FILETIME=[F1C79990:01C2DF46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1SGe3p09607 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Lars-Erik, Any thoughts on my proposed text for section 4.7? In particular, if you have think it is correct? Note that I added UO-0 in the last sentence. Also, what about UO-1 and UO-1-TS? Do they update all the header fields or just a subset? ------------------ "In UO-mode, all packets are updating packets, while in R-mode all packets with a CRC are updating packets. An updating packet in R-mode updates the reference values of all header fields, either explicitly or implicitly. Same is true for updating packets in UO-mode, except for UO-1-ID and UO-0, which only update TS, SN and IP-ID (see 5.7.3)." ------------------ Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc