From owner-pilc@lerc.nasa.gov Tue Apr 4 19:23:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20419 for ; Tue, 4 Apr 2000 19:23:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA16468 for pilc-outgoing; Tue, 4 Apr 2000 17:28:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA16440 for ; Tue, 4 Apr 2000 17:28:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA08693; Tue, 4 Apr 2000 17:28:34 -0400 (EDT) Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.0) id xma008641; Tue, 4 Apr 00 17:27:52 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA15630; Tue, 4 Apr 2000 14:27:50 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA04123; Tue, 4 Apr 2000 14:27:50 -0700 (MST)] Received: from cig.mot.com (d42-2435 [160.44.36.53]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id QAA09107; Tue, 4 Apr 2000 16:27:40 -0500 (CDT) Message-ID: <38EA5BEA.D50EACE5@cig.mot.com> Date: Tue, 04 Apr 2000 16:17:30 -0500 From: Phil Neumiller Organization: Aspira Exploratory Testbed X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group , pilc@grc.nasa.gov Subject: Comments on PILC draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Disclaimer: I have not read through all 800+ messages in the PILC archive. That will take some time. There are some subjects of interest to Mobile-IP folks, that is why I cross posted. I have read through the PILC draft. It suggests many different proven methods for link layer adaptation to IP. I found errors of omission rather than of commission. What could be done is to expand the current draft (or introduce a new draft) that specifically addresses problems faced by the implementors of "wireless Internet". This document was very TCP specific and the wireless world is also concerned about RTP among other things. I believe that wireless links are sufficiently different (not to mention increasingly prevalent) that they deserve their own set of "standard" link layer adaptation techniques. I suggest that we (enhance the existing) or prepare a draft that defines "Canonical Wireless Link Layer Adaptation for IP". In this draft the important issues of QoS, AAA, and handover could be addressed in an abstract way, suitable and useable by Wireless LANS (femto, pico, nano-cellular) and conventional macro-cellular (i.e. 2G, 2.5G, 3G). I am also hoping that the proposed Bluetooth BOF planned for Pittsburgh could be generalized in scope to include the more generic notion of "personal area networking" rather than being just a link adaptation fest for Bluetooth. Other link layers such as 802.11a, 802.11b, HomeRF, Hyperlan, and Hyperlan2 must be considered world players as well and the more commonality the better. I would also hope that the MWIF contribution could be combined with a previously proposed BOF for open base station protocols. It is my hope that the IETF can help unify wireless access by providing specific link layer hooks that are universal across diverse radio access networks. Does this fall into the PILC or Mobile-IP scope or somewhere else? I am not sure. Thanks, Phil QA2757@email.mot.com 847-632-4118 From owner-pilc@lerc.nasa.gov Tue Apr 4 20:21:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20864 for ; Tue, 4 Apr 2000 20:21:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA24369 for pilc-outgoing; Tue, 4 Apr 2000 19:09:13 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA24352 for ; Tue, 4 Apr 2000 19:09:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA20542; Tue, 4 Apr 2000 19:09:10 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020504; Tue, 4 Apr 00 19:08:41 -0400 Received: from mbb6.ericsson.se (mbb6.ericsson.se [136.225.151.211]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id BAA18994 for ; Wed, 5 Apr 2000 01:08:39 +0200 (MET DST) Received: from assc00.epa.ericsson.se (assc00.epa.ericsson.se [146.11.4.14]) by mbb6.ericsson.se (PMDF V5.2-29 #39353) with ESMTP id <0FSI00L6SLMBH3@mbb6.ericsson.se> for pilc@lerc.nasa.gov; Wed, 5 Apr 2000 01:08:39 +0200 (MET DST) Received: from aspc051.epa.ericsson.se ([146.11.4.151] helo=asac.ericsson.se ident=epaanwo) by assc00.epa.ericsson.se with esmtp (Exim 3.01 #2) id 12ccR0-0003He-00; Wed, 05 Apr 2000 09:08:34 +1000 Date: Wed, 05 Apr 2000 09:08:33 +1000 From: Andrew Worsley Subject: Re: [MOBILE-IP] Comments on PILC draft In-reply-to: Message from Phil Neumiller "of Tue, 04 Apr 2000 16:17:30 EST." <38EA5BEA.D50EACE5@cig.mot.com> To: Phil Neumiller Cc: rohc@cdt.luth.se, pilc@lerc.nasa.gov Message-id: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I am not posting this follow up to mobileIP but to the two groups that I think it is most relevant to, rohc and pilc. Hand over issues are being discussed in the mobileIP group but link layer stuff isn't. My comments are about IP over link layer issues. I am quoting the article in full because it was not originally posted to these groups. > Folks, > > Disclaimer: I have not read through all 800+ messages in the > PILC archive. That will take some time. There are some subjects > of interest to Mobile-IP folks, that is why I cross posted. > > I have read through the PILC draft. It suggests many different > proven methods for link layer adaptation to IP. I found errors > of omission rather than of commission. What could be done > is to expand the current draft (or introduce a new draft) that > specifically addresses problems faced by the implementors of > "wireless Internet". This document was very TCP specific and > the wireless world is also concerned about RTP among other > things. > > I believe that wireless links are sufficiently different (not > to mention increasingly prevalent) that they deserve their own > set of "standard" link layer adaptation techniques. > > I suggest that we (enhance the existing) or prepare a draft that > defines "Canonical Wireless Link Layer Adaptation for IP". In this > draft the important issues of QoS, AAA, and handover could be > addressed in an abstract way, suitable and useable by Wireless LANS > (femto, pico, nano-cellular) and conventional macro-cellular (i.e. > 2G, 2.5G, 3G). I am also hoping that the proposed Bluetooth BOF > planned for Pittsburgh could be generalized in scope to includethe > more generic notion of "personal area networking" rather than being > just a link adaptation fest for Bluetooth. Other link layers such > as 802.11a, 802.11b, HomeRF, Hyperlan, and Hyperlan2 must be > considered world players as well and the more commonality the > better. These issues are being addressed by the Robust header compression working group. see http://www.ietf.org/html.charters/rohc-charter.html > > I would also hope that the MWIF contribution could be combined with > a previously proposed BOF for open base station protocols. It is my > hope that the IETF can help unify wireless access by providing > specific link layer hooks that are universal across diverse radio > access networks. This sounds like a worthy goal and I believe some what compatible with rohc groups agenda which covers giving guidelines to link layer designers and defining compression schemes for specific link technologies. > > Does this fall into the PILC or Mobile-IP scope or somewhere else? > I am not sure. > > Thanks, > > Phil QA2757@email.mot.com > 847-632-4118 The ROHC group's work so far is mainly for RTP and not so much support is provided for TCP. Correct me if am wrong but the ROHC schemes assume that the packets sent have little or no error detection in them but that is how things are wanted for Voice over IP over the air as they would rather have corrupted data than have the whole packet dropped. The draft-jonsson-robust-hc-04.txt working document spells out having checksums only of the headers and presumably only dropping packets whoose header is corrupted (when it's compressed to a few bytes this is likely to be rare). Presumably corrupt packets with good headers are better than no packets. One question I have about that is that UDP for IPv6 requires mandatory checksums. Does this imply that the implementation would still try to use the failing packets? It's not clear to me that exactly how this is going to work. Finally I would like to suggest that a reliable profile transfer where there is bidirectional links be produced using a simple Nack (Negative acknowledgement) scheme like that described by Phil Karn in his paper: http://people.qualcomm.com/karn/papers/usenix.ps.gz I suggest segmentation using small segments and Nacks. There must be a large amount of theory on this and some formulas about it. I did some maths and found that surprisingly low segmentation numbers for even quite modest BER values. I assumed packets were segemented into segements of size f with with two bytes of overhead per segment (1 byte CRC and 1 byte count?), ignored the Nack traffic (as it's in the other direction?) and got for the average amount transmitted (in the one direction) for a packet of length D: T = ((D/f)+1)*(f + c)/p where f = segement size (I called it fragment) c = size of segement overhead p = probability of segment transmission, assuming a constant BER. i.e. p = 1 - (1 - BER)**(f+c) and I assume the last segment is truncated to only contain the remaining data, if not you need an upper bound on the segment size say 50 bytes. For c = 2, D = 640 Optimal values for f were: BER = .01 f = 4 p = 0.617290 efficiency = 2.430 BER = .001 f = 16 p = 0.865825 efficiency = 1.299 BER = 0.0001 f = 50 p = 0.959251 efficiency = 1.084 BER = 1e-05 f = 150 p = 0.987914 efficiency = 1.026 (efficiency is how much data is transmitted in the one direction divided by the size of the original data) Admittedly my maths may be off but although surprisingly low, I think it's about right. I also came up with the following approximation for the ideal segment size : sqrt(c**2 + c/8e) which depends only on the segment overhead and the BER value (e). The formula appears to work pretty good from my simulation data. I think that the ROCCO system could use this for TCP support. I think the ideal fragment size calculation could be done on the number of packets lost over a period. The result from this calculation could be used to update the size of the segement size used. This would allow the system to migrate to an appropriate value for the link dynamically as the environment changes. With f values < 200 this might only take a few seconds between adjustments. It needs a lot of work to turn the idea into a practical scheme, but the basic principle seems sound to me. e.g. Issues of frame size, handling sequence count wrap around and so on. Admittedly a lot of assumptions are made about the distribution of error bits but the general principal of using moderate segment sizes and Nacks seems to be a very robust approach. i.e. Erring on the side of small segments allows people to use large MTUs on their link (to avoid IPv4 fragmentation problems) and minimise the damage that long or short error bursts will do. This scheme might actually be useful with some UDP systems. Possibly the sending of a packet over this profile as opposed to another more lossy profile but lower latency profile could be chosen on a packet stream basis? i.e. Using QoS or protocol TCP vs UDP. Finally the selection of what to send over such a reliable profile needs to be judged based on the latency of the Nacks. If segments are small enough and Nacks can be returned quickly enough then the scheme would be practical for time constrained media like voice. Andrew Worsley From owner-pilc@lerc.nasa.gov Wed Apr 5 00:00:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24350 for ; Wed, 5 Apr 2000 00:00:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA06115 for pilc-outgoing; Tue, 4 Apr 2000 22:41:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA06103 for ; Tue, 4 Apr 2000 22:41:30 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA10796; Tue, 4 Apr 2000 22:41:28 -0400 (EDT) Received: from optima.cs.arizona.edu(192.12.69.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010754; Tue, 4 Apr 00 22:40:50 -0400 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id TAA02956; Tue, 4 Apr 2000 19:40:48 -0700 (MST) Received: from micke-P (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id TAA04455; Tue, 4 Apr 2000 19:40:46 -0700 (MST) Message-Id: <200004050240.TAA04455@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 05 Apr 2000 04:41:30 +0200 To: Andrew Worsley From: Mikael Degermark Subject: Re: [rohc] Re: [MOBILE-IP] Comments on PILC draft Cc: Phil Neumiller , rohc@cdt.luth.se, pilc@lerc.nasa.gov In-Reply-To: References: <38EA5BEA.D50EACE5@cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Andrew Worsley wrote: > This sounds like a worthy goal and I believe some what compatible with > rohc groups agenda which covers giving guidelines to link layer designers > and defining compression schemes for specific link technologies. The "guidelines for link layer designers" document developed by ROHC is ONLY intended to provide guidelines on what properties the link layer must and should have in order to run ROHC header compression over it. It is emphatically NOT a general-purpose guideline document for wireless link-layer designers. > Correct me if am wrong but the ROHC schemes assume that the packets sent > have little or no error detection in them No, that is not an assumption. We do, however, want (some instance of) the ROHC schemes to work IF there isn't strong error detection on the link layer. > but that is how things are wanted > for Voice over IP over the air as they would rather have corrupted data > than have the whole packet dropped. Some voice coders want that, yes. Not all, but some that some people care about. > The draft-jonsson-robust-hc-04.txt working document spells out having > checksums only of the headers and presumably only dropping packets whoose > header is corrupted (when it's compressed to a few bytes this is likely to > be rare). Presumably corrupt packets with good headers are better than no > packets. 1. The ROCCO checksum covers the original header, before compression. Its primary purpose is to allow dependable verification of correct decompression. 2. Using that checksum to detect corruption of compressed headers as well will weaken it for its original purpose. That may or may not be acceptable depending on a) how resilient the scheme needs to be against production of erroneous headers, and b) the error properties of the link. > One question I have about that is that UDP for IPv6 requires mandatory > checksums. Does this imply that the implementation would still try to use > the failing packets? It's not clear to me that exactly how this is going to > work. 1. Even if UDP prevents the packet to be delivered to the application, it will enhance performance it the header decompression module sees it. 2. The reason that IPv6 mandates using the UDP checksum is that IPv6 does not have a header checksum, so in order to ensure correct delivery for UDP, IPv6 had to mandate turning the UDP checksum on. That gives some assurance that the UDP payload is delivered to the app it is intended for. 3. Applications that want to have corrupted payloads delivered to them, clearly cannot use UDP with an enabled checksum to do so. Thus they cannot use UDP over IPv6. 4. A transport protocol that optionally allows such applications to receive corrupted payloads is UDP Lite, but it remains to be seen whether it is acceptable to the IETF. UDP Lite might be presented to the transport area WG and will be discussed on its list sometime before the next IETF meeting. This is clearly out of scope for the ROHC WG. People who want to discuss issues related to UDP and UDP Lite should do so on the Transport Area WG mailing list: General Discussion: tsvwg@ietf.org To Subscribe: tsvwg-request@ietf.org In Body: subscribe email_address Archive: ftp://ftp.ietf.org/ietf-mail-archive/tsvwg/ > Finally I would like to suggest that a reliable profile transfer where > there is bidirectional links be produced using a simple Nack > (Negative acknowledgement) scheme like that described by Phil Karn > in his paper: > > http://people.qualcomm.com/karn/papers/usenix.ps.gz > > I suggest segmentation using small segments and Nacks. For TCP and most of the non-audio and non-video UDP, I agree that the link should be almost error-free. This will be achieved by some some combination of (channel) FEC and ARQ. Most links that ROHC is explicitly intended for can be run in such a mode. The price paid for this is delay, but that is ok for TCP and some UDP. NOTE that the added delay does not primarily come from the ARQ scheme, but from the increased interleaving needed to make the FEC work well. > There must be a large amount of theory on this and some formulas about it. > I did some maths and found that surprisingly low segmentation numbers for > even quite modest BER values. < deletion of some theory...> > BER = .01 f = 4 p = 0.617290 efficiency = 2.430 > BER = .001 f = 16 p = 0.865825 efficiency = 1.299 > BER = 0.0001 f = 50 p = 0.959251 efficiency = 1.084 > BER = 1e-05 f = 150 p = 0.987914 efficiency = 1.026 > > (efficiency is how much data is transmitted in the one direction > divided by the size of the original data) > > Admittedly my maths may be off but although surprisingly low, I think it's > about right. I am not surprised. This suggests that performance-enhancing ARQ schemes over the link should use frames significantly smaller than typical TCP segments. > I think that the ROCCO system could use this for TCP support. I think > the ideal fragment size calculation could be done on the number of > packets lost over a period. The result from this calculation could > be used to update the size of the segement size used. This would > allow the system to migrate to an appropriate value for the link > dynamically as the environment changes. With f values < 200 this > might only take a few seconds between adjustments. It seems like a tall order for the ROHC WG to develop an ARQ scheme given that the radio links explicitly mentioned in the charter already have such schemes. But, if the WG so desires, we can ask the ADs to add it to our charter. I would hesitate to do so before we're done with the tasks currently at hand, though. > It needs a lot of work to turn the idea into a practical scheme, but the > basic principle seems sound to me. e.g. Issues of frame size, handling > sequence count wrap around and so on. > Admittedly a lot of assumptions are made about the distribution of error > bits but the general principal of using moderate segment sizes and Nacks > seems to be a very robust approach. i.e. Erring on the side of small > segments allows people to use large MTUs on their link (to avoid IPv4 > fragmentation problems) and minimise the damage that long or short error > bursts will do. > > This scheme might actually be useful with some UDP systems. Possibly > the sending of a packet over this profile as opposed to another more > lossy profile but lower latency profile could be chosen on a packet stream > basis? i.e. Using QoS or protocol TCP vs UDP. I agree that different packet streams need different service from the radio system. The dividing line is not primarily UDP vs TCP, but rather interactive audio & video vs. traditional TCP & UDP. I also expect that some games and other interactive apps will prefer low delay to error-freeness. > Finally the selection of what to send over such a reliable profile needs > to be judged based on the latency of the Nacks. If segments are small > enough and Nacks can be returned quickly enough then the scheme would > be practical for time constrained media like voice. For the links explicitly mentioned in the ROHC chater, the delay budget for interactive voice will not tolerate using such a nack scheme. That is the primary reason for doing the ROHC work in the first place. Moreover, if the delay budget allowed using the nack scheme, it would almost certainly be a better overall system trade-off to improve the performance of the channel coding by adding interleaving than to deploy the nack scheme. Mikael Degermark > Andrew Worsley >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ > From owner-pilc@lerc.nasa.gov Wed Apr 5 12:48:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12757 for ; Wed, 5 Apr 2000 12:48:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA08748 for pilc-outgoing; Wed, 5 Apr 2000 11:45:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA08723 for ; Wed, 5 Apr 2000 11:45:30 -0400 (EDT) From: zhigang.liu@nokia.com Received: by seraph3.lerc.nasa.gov; id LAA25644; Wed, 5 Apr 2000 11:45:29 -0400 (EDT) Received: from mgw-x1.nokia.com(131.228.20.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma025591; Wed, 5 Apr 00 11:44:53 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA26309; Wed, 5 Apr 2000 18:44:50 +0300 (EETDST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA23842; Wed, 5 Apr 2000 18:44:48 +0300 (EETDST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Apr 2000 10:44:47 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2469A54C5@daeis05nok> To: epaanwo@asac.ericsson.se, neumille@cig.mot.com Cc: rohc@cdt.luth.se, pilc@lerc.nasa.gov Subject: RE: [rohc] Re: [MOBILE-IP] Comments on PILC draft Date: Wed, 5 Apr 2000 10:43:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > -----Original Message----- > From: EXT Andrew Worsley [mailto:epaanwo@asac.ericsson.se] > Sent: Tuesday, April 04, 2000 6:09 PM > To: Phil Neumiller > Cc: rohc@cdt.luth.se; pilc@lerc.nasa.gov > Subject: [rohc] Re: [MOBILE-IP] Comments on PILC draft > ...... > I assumed packets were segemented into segements of size f > with with two > bytes of overhead per segment (1 byte CRC and 1 byte count?), > ignored the Nack traffic (as it's in the other direction?) and got > for the average amount transmitted (in the one direction) > for a packet of > length D: > > T = ((D/f)+1)*(f + c)/p > > where f = segement size (I called it fragment) > c = size of segement overhead > p = probability of segment transmission, assuming a > constant BER. > i.e. p = 1 - (1 - BER)**(f+c) Just want to point out a typo here. If p is the probability that a segment is transmitted successfully, p should equal to (1 - BER)**(f+c). The p above actually gives the probability of a failed transmission. Zhigang Liu > > and I assume the last segment is truncated to only > contain the remaining > data, if not you need an upper bound on the segment size > say 50 bytes. > > For c = 2, D = 640 > Optimal values for f were: > > BER = .01 f = 4 p = 0.617290 efficiency = 2.430 > BER = .001 f = 16 p = 0.865825 efficiency = 1.299 > BER = 0.0001 f = 50 p = 0.959251 efficiency = 1.084 > BER = 1e-05 f = 150 p = 0.987914 efficiency = 1.026 > > (efficiency is how much data is transmitted in the one direction > divided by the size of the original data) > ...... > > Andrew Worsley > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ > From owner-pilc@lerc.nasa.gov Thu Apr 6 15:04:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13176 for ; Thu, 6 Apr 2000 15:04:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA05248 for pilc-outgoing; Thu, 6 Apr 2000 13:30:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA05198 for ; Thu, 6 Apr 2000 13:29:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA18706; Thu, 6 Apr 2000 13:29:53 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma018684; Thu, 6 Apr 00 13:29:22 -0400 Received: from puh.eritel.se (puh.erv.ericsson.se [194.22.140.20]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id TAA22602 for ; Thu, 6 Apr 2000 19:29:19 +0200 (MET DST) Received: from esegsnt003.erv.ericsson.se (esegsnt003 [194.22.140.6]) by puh.eritel.se (8.8.8+Sun/8.8.8) with ESMTP id RAA27420 for ; Thu, 6 Apr 2000 17:00:56 +0200 (MET DST) Received: by esegsnt003.erv.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Apr 2000 17:00:56 +0200 Message-ID: <2DADC88F8F19D31193340090277A3661030F5C86@esegsnt003.erv.ericsson.se> From: "Jan Kullander (ERV)" To: pilc@grc.nasa.gov Subject: SLOW draft and TCP Auto-tuning Date: Thu, 6 Apr 2000 17:00:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi! As summarised in section 2.5, the auto-tuning technique adjusts the buffer size based on the utilised window. This entails increased advertised window until packets are lost. This thus contradicts section 2.3 that recommends the advertised window to be limited to avoid buffer overflow in the queue to the bottleneck link. We believe the latter recommendation to be valid for slow links. We are however much in favour of TCP auto-tuning since the bw*delay product could be considerable over some wireless links and a mobile node could roam between different access links. We would thus like the auto-tuning section to remain somewhere, somehow in the output from PILC but it is not needed for the slow links. Sorry for the late comment. Haider Shakargi & Jan Kullander PS It would be nice to combine auto-tuning with an optional max window associated with interfaces... DS From owner-pilc@lerc.nasa.gov Thu Apr 6 16:07:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14062 for ; Thu, 6 Apr 2000 16:07:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA17153 for pilc-outgoing; Thu, 6 Apr 2000 14:49:33 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA17060 for ; Thu, 6 Apr 2000 14:49:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA29400; Thu, 6 Apr 2000 14:49:27 -0400 (EDT) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029385; Thu, 6 Apr 00 14:49:21 -0400 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id <2H1426K1>; Thu, 6 Apr 2000 14:49:21 -0400 Message-ID: <8046A317B5F4D21186610008C7EBB696F057A2@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'pilc@grc.nasa.gov'" Cc: "Spencer Dawkins (E-mail)" , "'Gabriel Montenegro'" , "'vincent.magret@aud.alcatel.com'" , "Markku Kojo (E-mail)" , "'vaidya@cs.tamu.edu'" , "Vern Paxson (E-mail)" Subject: Extended (again): Working group last call for ERROR and SLOW Date: Thu, 6 Apr 2000 14:43:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I've been requested to extend the last call on SLOW and ERROR to allow some additional commentary. Let's give things another couple of weeks until 4/21. Again, the drafts can be found at: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-03.txt http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-03.txt Thanks, --aaron From owner-pilc@lerc.nasa.gov Thu Apr 6 22:27:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19329 for ; Thu, 6 Apr 2000 22:27:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA21597 for pilc-outgoing; Thu, 6 Apr 2000 20:46:36 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA21585 for ; Thu, 6 Apr 2000 20:46:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA10827; Thu, 6 Apr 2000 20:46:34 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma010816; Thu, 6 Apr 00 20:46:27 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id RAA24360; Thu, 6 Apr 2000 17:46:25 -0700 Reply-To: mahdavi@novell.com To: "pilc@grc.nasa.gov" Subject: ERROR draft comments... From: Jamshid Mahdavi Date: 06 Apr 2000 17:46:25 -0700 In-Reply-To: "Falk, Aaron"'s message of "Thu, 6 Apr 2000 14:43:45 -0400" Message-ID: Lines: 112 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I've finally gotten around to reading Error, and I have a few additional comments on it: > 2.1 Slow Start and Congestion Avoidance [RFC2581] > > Slow Start and Congestion Avoidance [RFC2581] are essential to > the Internet's stability. These mechanisms were designed to > accommodate networks that didn't provide explicit congestion > notification. I'd recommend changing the wording slightly here: "These mechanisms were designed to accomodate networks that didn't provide any form of explicit congestion control". (we aren't just talking about ECN in this sentence. And ECN in fact uses SS and CA...) Section 2.2: > NewReno [RFC2582] apparently does help a sender > better handle partial ACKs and multiple losses in a single > window, but at this point is not recommended due to its > experimental nature. Instead, SACK (Selective Acknowledgements) > is the preferred mechanism. Both NewReno and SACK are becoming popular. I'd say that the bad thing about NewReno is that it takes N RTTs to recover if there are N losses. The good thing about it is that it requires only one side of the connection to implement the protocol. SACK appears to be a much better solution. Unless there is objection, I'd say recommend SACK generally and NewReno (in addition, not instead) for situations where SACK won't work (this would normally be because the person reading this would only be able to install a solution on the transmitting end of the connection). Here is new text: Recommendation: Implement Fast Retransmit and Fast Recovery at this time. This is a widely-implemented optimization and is currently at Proposed Standard level. [RFC2488] recommends implementation of Fast Retransmit/Fast Recovery in satellite environments. In cases where SACK (see next section) can not be enabled for both sides of a connection, NewReno [RFC2582] may be used by TCP senders to better handle partial ACKs and multiple losses in a single window. Section 2.3: > In low-speed, high error-rate environments (for example, the > wireless WAN environment), TCP windows are much smaller, and burst > errors must be much longer in duration in order to damage multiple > segments. Accordingly, the complexity of SACK may not be > justifiable, unless there is a high probability of both burst > errors and congestion. This logic doesn't make a lot of sense to me. I suppose that if your error rate is high, and you are constantly timing out, SACK is not going to make any difference. But if there is congestion too (i.e. the total error rate is even higher), SACK is going to help even less. I'm not an expert, but I would think that in wireless environments, changes in surroundings (i.e. someone walks in front of the wireless card) would cause a high probability of correlated errors. This would imply to me multiple losses per window, exactly the thing that SACK is good for. So if things mostly *don't* suck, SACK will help for the times when they do. If things mostly *do* suck, not much is going to help. Here is a proposed change/addition: In low-speed, high error-rate environments (for example, the wireless WAN environment), TCP windows are much smaller, and burst errors must be much longer in duration in order to damage multiple segments. Accordingly, the complexity of SACK may not be justifiable. On the other hand, if error rates are generally low but occasionally increase due to interference, TCP will have the opportunity to increase its window to larger values. When interference occurs, multiple losses within a window are likely to occur. In this case, SACK would provide benefits in speeding the recovery and preventing unnecessary extra reduction of window size. Section 4: I promised Aaron a note on "explicit notification of transmission error" based on a discussion Phil and Aaron and I had at IETF. I'll try to emit that tomorrow. It probably doesn't impact the draft once (except maybe to change this one sentence), but it ought to spark some interesting discussions. Section 4.1: Playing something of the devil's advocate here... I don't see that the recommendations are impacted at all by whether connections are short or long. Even in the current world with lots of short flows, sometimes in parallel, we still want people to do SS/CA, FR/FR and SACK. I don't think there is any question that it would be of additional benefit if parallel TCP connections shared congestion state either through 2140 or ECM. I don't necessarily think I'd argue that they are "crucial to the long-term stability of the Internet" (we've lasted this long, after all!), but they should definitely be beneficial to performance. The recent CCR paper by Eggert, Heidemann, and Touch on Ensemble TCP showed some of the benefits of combining congestion state for http traffic. I'd kind of like to see the same work done in an "error" environment to see what effect it would have on performance... --Jamshid From owner-pilc@lerc.nasa.gov Fri Apr 7 06:00:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05386 for ; Fri, 7 Apr 2000 06:00:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA15993 for pilc-outgoing; Fri, 7 Apr 2000 05:06:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA15972 for ; Fri, 7 Apr 2000 05:06:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA22448; Fri, 7 Apr 2000 05:06:08 -0400 (EDT) Received: from alc110.alcatel.be(195.207.101.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022410; Fri, 7 Apr 00 05:05:54 -0400 Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id LAA25443; Fri, 7 Apr 2000 11:05:41 +0200 (MET DST) Received: from alcatel.be (bt00t9 [138.203.66.143]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id LAA25849; Fri, 7 Apr 2000 11:05:24 +0200 (MET DST) Message-ID: <38EDA4C0.25F14E4C@alcatel.be> Date: Fri, 07 Apr 2000 11:05:04 +0200 From: Omar Elloumi Organization: Alcatel Corporate Research Center X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mahdavi@novell.com CC: "pilc@grc.nasa.gov" Subject: Re: ERROR draft comments... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Jamshid, all I'm not following this track but just a small comments on NewReno, see below Jamshid Mahdavi wrote: > I've finally gotten around to reading Error, and I have a few > additional comments on it: > > > Section 2.2: > > > NewReno [RFC2582] apparently does help a sender > > better handle partial ACKs and multiple losses in a single > > window, but at this point is not recommended due to its > > experimental nature. Instead, SACK (Selective Acknowledgements) > > is the preferred mechanism. > > Both NewReno and SACK are becoming popular. I'd say that the bad > thing about NewReno is that it takes N RTTs to recover if there are N > losses. The good thing about it is that it requires only one side of > the connection to implement the protocol. SACK appears to be a much > better solution. Unless there is objection, I'd say recommend SACK > generally and NewReno (in addition, not instead) for situations where > SACK won't work (this would normally be because the person reading > this would only be able to install a solution on the transmitting end > of the connection). Here is new text: > NewReno Takes *at most* N RTTs to recover, because since you're sending two packets for each incoming ACK it may be the case that you retransmit two lost packet for the same incoming ACK. I would also say that SACK is *generally* a much better solution. I did some simulations two years ago and I found some scenarios in which NewReno outperforms SACK. The reason is simple: SACK is very aggressive and it may be the case that for heavy congestions, retransmitted packets can be lost leading to a timeout. While with NewReno which is less aggressive the probability of loosing a retransmitted packets may be in some scenarios less than with SACK. Unfortunately I don't have anymore the simulation results. But I think this makes sens and it should also be pointed out in some papers. Kind regards. -- ____________________________________________________________ Omar Elloumi Alcatel Research - Network Architecture - Traffic Technology Francis Wellesplein 1, 2018 Antwerp, Belgium Phone: + 32 3 240 78 33 Fax: + 32 3 240 99 32 http://www.alcatel.com/crc/ ____________________________________________________________ Opinions expressed are those of the sender and do not reflect Alcatel policy or agreement From owner-pilc@lerc.nasa.gov Fri Apr 7 11:32:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10578 for ; Fri, 7 Apr 2000 11:32:19 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA14894 for pilc-outgoing; Fri, 7 Apr 2000 10:21:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA14865 for ; Fri, 7 Apr 2000 10:21:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA22892; Fri, 7 Apr 2000 10:21:14 -0400 (EDT) Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.0) id xma022758; Fri, 7 Apr 00 10:20:42 -0400 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id <2H1420HS>; Fri, 7 Apr 2000 10:20:41 -0400 Message-ID: <8046A317B5F4D21186610008C7EBB696F057BB@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'minutes@ietf.org'" , "'pilc@grc.nasa.gov'" Cc: "Markku Kojo (E-mail)" , "Jim Griner (E-mail)" , "Spencer Dawkins (E-mail)" Subject: FW: PILC minutes from IETF-47 Date: Fri, 7 Apr 2000 10:16:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFA09C.7421F2EC" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFA09C.7421F2EC Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Markku Kojo [mailto:kojo@cs.Helsinki.FI] Sent: Friday, April 07, 2000 9:19 AM To: afalk@PanAmSat.com Subject: PILC minutes Aaron, please find attached the pilc wg meeting minutes that Jim and I gathered. Just got an email from Jim saying he is still in Australia, so I am sending these to you. Some comments were probably not captured, but I think most are there. Rgds, /Markku ------_=_NextPart_000_01BFA09C.7421F2EC Content-Type: TEXT/plain; name="pilc-minutesFINAL.txt" Content-Disposition: attachment; filename="pilc-minutesFINAL.txt" Content-Description: IETF-47 PILC meeting minutes Content-ID: Content-Transfer-Encoding: quoted-printable Aaron opened the meeting at 2:15PM on 3/28/00 Went over the agenda, with no comments. Defered discussion of assymetric draft, since authors are=20 not at this meeting WG status: ---------- -Submitted "Long Thin Networks" to IESG in October 99 =20 -Should submit PEP draft as informational to IESG by Nov 00 -ASYM document needs more discussion on the list=20 -Aaron: ASYM will go away if there is consensus that these =20 mechanisms are not needed =20 -Should submit LINK draft to IESG by Nov 00 -SLOW and ERROR are expected to become BCPs during spring 2000, =20 now in last call =20 John Border gave the status on the PEP draft: --------------------------------------------- -The -01 draft missed the DC meeting deadline but was submitted after DC meeting. For the -00 we got valuable comments, but for -01 we =20 didn't get any commnets; maybe as a result of being late? =20 -Looking for input in the following sections protocol booster mechanisims ACK filtering and regeneration Partial ACK mechanisims Others?? -Some additional example environments where PEPs are in use may be =20 added, but only if they illustriate new types or mechanisms not =20 already covered =20 -Need help on completing the section on WAP =20 -Mainly looking for input on implications of using PEPS =20 End-to-end failure diagnostics Multi-homing environments QoS transparency Security implications Others? Need further terminology refinment Comments: ??: Can get more information on the WAP section from=20 the IAB worksop BOF and plenary WAP discussion John?: Some problems between asym and pep draft as what happens=20 to ASYM is not known John Border: Leave specific information in asym draft, if it=20 doesn't go away Aaron Falk: ASYM will go away if the mechanisims are not real and needed PEP document should only contain mechanisims=20 that are used or are going to be used, and not just=20 academic mechanisims John Border: We have to draw the line somewhere ??: Are web caches considered peps? John Border: There is a fine line to whether they are peps or not Markku Kojo: They are considered PEPs in this doc only when they are related to specific link characteristic(s), i.e. they =20 use some specific mechanisms to mitigate problems due =20 to link behavior =20 Phil Karn gave the status on the link draft: -------------------------------------------- -Goal of document is to give advice to designers of subnetworks that=20 intend to carry IP -Emphasis on end-to-end model, awareness of inter-layer interactions, and eliminating redundancy (between what IP already provides and what link designers are providing) -01 draft submitted for nov99 IETF Changes include: address delays, MTUs, error recovery,=20 connection-oriented subnetworks, framing, Bandwidth on Demand -02 was submitted for this IETF =20 Reflects current versions of mailing list comments =20 Added congestion and flow control QoS, multicast, etc. -Changes to the current draft (since -01) =20 refinement of all sections esp those on impacts on net asym=20 -end to end philosophy =20 -all sections related to fundamental link design =20 added sections -QoS management and flow control have some redundent parts compression -mobility -broadcast/multicast =09 Sections needing work -QoS & Congestion Control -Delay and delay variance characteritics -routing & mobility =20 (how much routing should IP provide and how much should the subnetwork provide?) -multicast support -QoS management next steps=20 -revisit draft -seek advice and agree on end to end (QoS ?) =20 Jamashid: How much delay can a subnetwork add? If many people=20 all take the same advice then the delay can addup Phil Karn: No one is adding gratituas delay; give us hooks to tell whether the pkt is delay sensitive ??: Connection oriented subnetworks section is biased might want to look at MPLS (MPLS introduces some connection-orientinesh to nets) Phil Karn: The section advises one to avoid connection oriented subnetworks, some of these topics should be added to=20 congestion management section Aaron Falk: This is a really important document, and now is the time to add new sections or add/correct current sections,=20 since the document is maturing Phil Karn: The more people that add to the document, the more=20 credibility it will have Jamashid: Is there some way to add a short summary of key points Phil Karn: Thinks this is a good idea, since some sections are long ??: What about FDDI switches that fragment IP packets Phil Karn: Maybe add this as an example Gabe Montenagro gave the status of the SLOW and ERROR drafts ------------------------------------------------------------ -Most of the changes are cosmetic -Changed from explicit corruption notification to explicit=20 transmission error notification in error draft -New section were added in both drafts to separate: -recommended mechanisms -topics for further work =09 -Both drafts are currently in last call till april 7 -Issues with SLOW draft (as seen by the authors) -Need to redo receive and router buffer size example in section 2.3 and address the issues related to the router buffer size more clearly -Should we reccomend RED? (we think yes) -Should we recomment ECN? -Need to beef up MTU section, maybe steal some of link text -Issues with ERROR draft (as seen by the authors) -Need editing on section 1.2 (relationship with LINK draft) -Section 2.2 on AIMD is not accurate -Section 2.2, why cwnd remains small: -#2 is inaccurate -#3 must be removed, cannot be generalised, applies LTNs only -Need to update section 4.0=20 -on SACK-EXT as it is no onger experimental -Delayed DUPACKs section needs clarification =09 -Some changes are desirable in both drafts Do we need a second last call? Aaron: if the changes are substantial Comments: Phil Karn: The wording may not carry over from link document,=20 since audiences are different (on whether duplicating text, using pointers to other pilc docs) Aaron and John: Said that we should make it clear that the topics for further work in appendicies are not part of the recommendations Gabe Montenagro: Maybe a paragraphs stating that the appencicies are=20 not the emphasis of the document Geoff Huston: Should say active queue management is important and use RED as an example of this ------_=_NextPart_000_01BFA09C.7421F2EC-- From owner-pilc@lerc.nasa.gov Fri Apr 7 15:10:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15753 for ; Fri, 7 Apr 2000 15:10:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA18267 for pilc-outgoing; Fri, 7 Apr 2000 14:05:02 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA18222 for ; Fri, 7 Apr 2000 14:04:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA24454; Fri, 7 Apr 2000 14:04:57 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024426; Fri, 7 Apr 00 14:04:49 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id LAA25873; Fri, 7 Apr 2000 11:04:48 -0700 Reply-To: mahdavi@novell.com To: "pilc@grc.nasa.gov" Subject: Re: FW: PILC minutes from IETF-47 References: <8046A317B5F4D21186610008C7EBB696F057BB@grnexch1.panamsat.com> From: Jamshid Mahdavi Date: 07 Apr 2000 11:04:48 -0700 In-Reply-To: "Falk, Aaron"'s message of "Fri, 7 Apr 2000 10:16:05 -0400" Message-ID: Lines: 70 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Additional notes on ERROR. I noticed in the meeting comments about errors in section 2.2 and sure enough there are some. Here is some proposed revised text: Old text: After a fast retransmit, a sender invokes the fast recovery [RFC2581] algorithm, whereby it invokes congestion avoidance, but not slow start from a one-segment congestion window. This also saves time. It's important to be realistic about the maximum throughput that TCP can have over a connection that traverses a high error-rate link. Even using Fast Retransmit/Fast Recovery, the sender will halve the congestion window each time a window contains one or more segments that is lost, and will re-open the window by one additional segment for each acknowledgement that is received. If a connection path traverses a link that loses one or more segments during recovery, the one-half reduction takes place again, this time on a reduced congestion window - and this downward spiral will continue until the connection is able to recover completely without experiencing loss. In general, TCP can increase its congestion window beyond the delay-bandwidth product. In links with high error rates, the TCP window may remain rather small for long periods of time due to any of the following reasons: ... New Text: After a fast retransmit, a sender invokes the fast recovery [RFC2581] algorithm. This allows it to remains in congestion avoidance, rather than falling back to slow start from a one-segment congestion window. This also saves time. TCP implementations which follow these algorithms as specified in RFC2581 are genericly referred to as Reno TCP implementations. It's important to be realistic about the maximum throughput that TCP can have over a connection that traverses a high error-rate link. Even using Fast Retransmit/Fast Recovery, the sender will halve the congestion window each time a window contains one or more segments that is lost, and will only re-open the window by one additional segment for each subsequent window of data that is sent and acknowledged. For most Reno TCP implementations, multiple losses within a single window are very likely to result in a retransmission timeout, resulting in further performance degradation. Further, if a connection path traverses a link that loses segments in several consecutive windows, the one-half reduction takes place each time once for each window of data which includes a loss. This causes a downward spiral which will continue until the connection returns to an error-free state, at which time it can begin to increase the congestion window at the rate of one additional segment per window of data sent and acknowledged. In general, TCP is able to increase its congestion window beyond the delay-bandwidth product for the connection path. However, for paths with high error rates, TCP's congestion window may remain rather small for long periods of time due to one or more of the following reasons: ... From owner-pilc@lerc.nasa.gov Fri Apr 7 15:11:04 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15775 for ; Fri, 7 Apr 2000 15:11:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA20081 for pilc-outgoing; Fri, 7 Apr 2000 14:17:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA20049 for ; Fri, 7 Apr 2000 14:17:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA26337; Fri, 7 Apr 2000 14:16:57 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026310; Fri, 7 Apr 00 14:16:46 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id LAA25925; Fri, 7 Apr 2000 11:16:45 -0700 Reply-To: mahdavi@novell.com To: "pilc@grc.nasa.gov" Subject: ERROR: Apologies for doing these items one at a time... References: <8046A317B5F4D21186610008C7EBB696F057BB@grnexch1.panamsat.com> From: Jamshid Mahdavi Date: 07 Apr 2000 11:16:45 -0700 In-Reply-To: "Falk, Aaron"'s message of "Fri, 7 Apr 2000 10:16:05 -0400" Message-ID: Lines: 35 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk I hope this doesn't too thoroughly annoy anyone. Suggested text for items 2 and 3 under section 2.2 in ERROR. Old Text: 2. TCP's congestion avoidance strategy is additive-increase, multiplicative-decrease, which means that if additional errors are encountered during recovery, the effect on the congestion window is a "downward spiral" - "reduce by 50 percent, recover by 20 percent, reduce by 50 percent due to the next error ...". 3. Often small socket buffers are recommended with high error-rate links in order to prevent the RTO from inflating. New Text: 2. As described above, TCP's congestion avoidance strategy treats packet loss as an indication of congestion. In links with frequent errors (which result in packet corruption/loss), this can effectively clamp the window at a low value. 3. In some cases, links with high error rates are also low-bandwidth links. People may mistakenly believe that by reducing socket buffer sizes, they will improve overall performance by preventing the RTT from rising (due to buffering). See the document for more details on these practices. I've got several comments on SLOW which this point is tied to. I plan to write these up today also. --Jamshid From owner-pilc@lerc.nasa.gov Fri Apr 7 17:14:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18655 for ; Fri, 7 Apr 2000 17:14:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA09284 for pilc-outgoing; Fri, 7 Apr 2000 16:24:00 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA09251 for ; Fri, 7 Apr 2000 16:23:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA14634; Fri, 7 Apr 2000 16:23:56 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma014609; Fri, 7 Apr 00 16:23:43 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id NAA26314; Fri, 7 Apr 2000 13:23:42 -0700 Reply-To: mahdavi@novell.com To: pilc Subject: ICMP EaTEN message... From: Jamshid Mahdavi Date: 07 Apr 2000 13:23:41 -0700 Message-ID: Lines: 87 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk [Now that it has a cute name, we'll just *have* to implement it :-)]. This is a summary of some discussion we had at the IETF on the concept of an ICMP message for "Explicit Transmission Error Notification". I couldn't think of a good word that starts with "A" but "EaTEN" is clearly the correct sentiment. The basic problem, which has been discussed quite a bit in pilc, is for wireless links. It is impossible to completely avoid transmission errors, and people in the WG have argued that in some cases providing suitable amounts of FEC to reduce errors to a suitable low level is too costly (for whatever reason). As outlined in ERROR, losses due to transmission errors have a bad impact on TCP. TCP must assume that these losses are caused by congestion (because there is no information to the contrary), and therefore back off its congestion window. The proposed solution, therefore, is to create a mechanism to communication this information about corruption back to the sending TCP. I assume that the receiving wireless node computes a link-layer checksum and determines that the packet has been corrupted. Normally at this point, it would simply drop the packet as it is no longer forwardable. In addition to dropping the packet, the proposal is to send an ICMP EaTEN message back to the origin, in effect saying that the packet was "eaten". (The ICMP includes the original IP and TCP headers). The sending TCP would respond to this ICMP message in two ways. First, it would immediately perform a fast retransmit of the corrupted segment. Second, because it knows that the loss was *not* due to congestion, it would *not* reduce cwnd. This would eliminate the major detriment (to TCP) of having an error-prone link in the path. (For security, the considerations discussed in TSVWG for Phil's ICMP kick-tcp message would be need to be included. I think this means matching the ICMP messages to actual packet losses in order to eliminate various forms of DoS attacks and probably also using some type of detection for floods of these messages. This also means that you don't actually immediately retransmit the corrupted packet, but still wait until you get 3 dupacks -- treating the ICMP message in an advisory fashion.) Note that with this solution, the error-prone hop can be anywhere in the path; it is not restricted to being an endpoint. And it works fine whether there are 1 or 5 or 20 wireless hops in the path. Cons to the EaTEN ICMP concept: 1. Phil posed the following question: if all this message is going to accomplish is to have TCP retransmit the packet, why not just have the link layer do this via an ARQ mechanism? This would get the data there quicker, and be more efficient for the network. 2. The other problem is that if the part of the original segment which was corrupted included the packet headers, the ICMP might be sent to the wrong host or connection. Since the IETF, I came up with a counter-argument for Phil's point. If the link layer can accomplish the ARQ within 3 packets of the original transmission, there is no problem. However, if it takes longer than this, it will be out of order by enough to trigger fast retransmit anyway, which mean that the ARQ had no useful effect. There are some things we can talk about doing to TCP to make this less of a problem (basicly delaying fast retransmit under certain well-defined circumstances), but for long delay links such as satellites, this might not be possible to overcome. I don't have a good answer for point 2. I suppose the security checks mentioned above would provide some insurance that a misrouted message didn't do any harm, however. I pose all of this to the list because I've heard suggestions from various fronts that such a thing would be useful. I've also heard a lot of comments to the effect that if we just design the subnetworks correctly in the first place, this doesn't need to be a problem. Personally, I am entirely on the fence and am usually swayed by the arguments of whoever I happen to have spoken with most recently. --Jamshid From owner-pilc@lerc.nasa.gov Fri Apr 7 20:12:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21454 for ; Fri, 7 Apr 2000 20:12:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA23059 for pilc-outgoing; Fri, 7 Apr 2000 19:11:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA23038 for ; Fri, 7 Apr 2000 19:11:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA03535; Fri, 7 Apr 2000 19:11:15 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003521; Fri, 7 Apr 00 19:11:13 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id QAA26833; Fri, 7 Apr 2000 16:11:08 -0700 Reply-To: mahdavi@novell.com To: pilc Subject: Comments on SLOW... From: Jamshid Mahdavi Date: 07 Apr 2000 16:11:08 -0700 Message-ID: Lines: 131 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Note: This is recommending a lot of changes. I'm happy to write all of the text, but I wanted to run the ideas through the group first for comments before doing all of the writing. --J =================================================================== I propose that we do some reorganization on section 2 of SLOW. In particular, 2.3 and 2.5 kind of go together, so let's move the MTU stuff before the TCP stuff, and make it section 2.3. I like the MTU content, but I'd change the phrase "effectively turns off delayed ACKs". We TCP weenies tend to equate delayed ACK with ACK per 2 packets. We should be more clear, and say that using an MTU that takes more than 200 milliseconds to transmit will cause an ACK to be generated for every segment, rather than one per two segments as is normal with most TCP implementations. (The gripe is that the ACKs are still delayed by 200 msec, so they should still be called delayed ACKs. They do still have the other benefits of delaying, such as piggybacking ACKs and data). Under the TCP sections, I suggest that we reorganize them as follows: 2.4 Interactions with TCP Congestion Avoidance [RFC2581] * Keep the description of CA. * However, the current description confuses rate and window. I'd like to clarify this. * Explain the issues of increased RTT due to queuing in this section also. 2.4.1 Recommendations for network elements connected to SLOW links. * This section would include a recommendation to limit queue lengths to reasonable values. This would be minimum of 3 segments (for FR/FR), and a maximum based on the delay imposed by the queue. For single user links (i.e. modems), a bandwidth-delay product is probably a good value to recommend here. * Also include recommendations for RED and ECN in this section. Interesting question is whether RED makes sense for single user devices (modem pools) with short queues. This might actually be a case where drop-tail is better (or at least equivalent -- how long does it take to go over the max threshold if the queue is only 3 packets?) 2.4.2 Recommendations for TCP implementations * In general, I'd say that the management responsibility for SLOW connections should be applied in the following order: 1. Network queues 2. TCP sender 3. TCP receiver 4. Applications and Sysadmins In other words, whatever performance problems we have should first be fixed by making the network more suitable to work correctly with a standard TCP implementation. These are the queuing recommendations above. If the network is messed up (i.e. has queues that can fill up to 3 seconds worth of data, or no queues at all), the sender TCP is in the best position to detect this and compensate for it. Senders can also implement shared congestion state and persistent connections which would help because you could remember certain parameters from one flow to the next. If all of these fail, then the receiver TCP might try to do something using the receiver window. We should try to make it clear that, only as an absolute last ditch effort, should applications or operating system parameters be used to make improvements to performance. My logic on this last point is as follows. First, applications might actually have a legitimate application reason to want to set socket buffer sizes. This is the actual point in having settable socket buffer sizes: managing system resources, *not* managing network resources. So I don't like the recommendation that apps not set socket buffers. Second, a single system default is a pretty poor way to manage network resources. For example, if I dial in on my laptop sometimes, and other times hook up via a 100 Mb/s PC card, what should I do? Do I use different values when my modem negotiates 56 kb/s than when it negotiates 9.6 kb/s? If we are going to recommend that OS vendors add a "dialup/LAN" dialog, lets instead recommend that they actually fix the problem in a way that handles both the SLOW and FAST needs. This means changes in the TCP stack along the same lines as autotuning, but more specificly targetted to this problem. Section 3: Summary of recommendations. Implementors should consider the possibility that a host will be directly connected to a low-speed link when choosing default TCP receive window sizes. We should replace this recommendation with something suitable based on the above discussion. Application developers should consider the possibility that an application will be used on a host that is directly connected to a low-speed link, before increasing the TCP receive window size beyond the default for TCP connections used by this application. I'd replace this with: Application developers should not attempt to manually manage network bandwidth using socket buffer sizes. Only in very rare circumstances will an application actually know both the bandwidth and delay of a path and be able to choose a suitably low (or high) value for the socket buffer size to obtain good network performance. I'd also be in favor of recommending the implementation of new APIs which let applications find out information about how much network bandwidth (or window or RTT or whatnot) is currently available from the transport layer. Perhaps something like what ecm is toying with... --Jamshid From owner-pilc@lerc.nasa.gov Fri Apr 7 21:33:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22413 for ; Fri, 7 Apr 2000 21:33:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA27480 for pilc-outgoing; Fri, 7 Apr 2000 20:39:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA27471 for ; Fri, 7 Apr 2000 20:39:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA11728; Fri, 7 Apr 2000 20:39:01 -0400 (EDT) Received: from pluris.com(208.227.9.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011696; Fri, 7 Apr 00 20:38:52 -0400 Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA26427; Fri, 7 Apr 2000 17:38:50 -0700 (PDT) Message-ID: <38EE7F9B.509B3344@pluris.com> Date: Fri, 07 Apr 2000 17:38:51 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mahdavi@novell.com CC: pilc Subject: Re: ICMP EaTEN message... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit One concern: How does a wireless network router know who a corrupted packet belongs to in a shared medium network so that it can send this message. Very likely, what this will boil to is sending a message to all TCP sessions that it has seen recently on this link. This will work OK for wireless nodes that are transmitting to other nodes, but for wireline nodes, the sheer number of them that are out there may "eat" away at the benefits of such a message. You are much better of giving some sort of piggy back feedback between wireless nodes involved in the connection to their TCPs if they happen to be at the same place. For example: if you have wireless router A, and wireless node B, then if B got some sort of feedback on the link quality than it can give explicit feedback to hosts that it has TCP connections to. If on the other hand two nodes happen to be connecting through a wireless link, then we are out of luck. In a nutshell, I think that this idea even though it sounds useful at first, is really not that useful. Regards Bora Akyol ps. You may want to check on some old research done in the late 70s, early 80s on wireless packet data networks if you have not done so already. Jamshid Mahdavi wrote: > [Now that it has a cute name, we'll just *have* to implement it :-)]. > > This is a summary of some discussion we had at the IETF on the concept > of an ICMP message for "Explicit Transmission Error Notification". I > couldn't think of a good word that starts with "A" but "EaTEN" is > clearly the correct sentiment. > > The basic problem, which has been discussed quite a bit in pilc, is > for wireless links. It is impossible to completely avoid transmission > errors, and people in the WG have argued that in some cases providing > suitable amounts of FEC to reduce errors to a suitable low level is > too costly (for whatever reason). > > As outlined in ERROR, losses due to transmission errors have a bad > impact on TCP. TCP must assume that these losses are caused by > congestion (because there is no information to the contrary), and > therefore back off its congestion window. > > The proposed solution, therefore, is to create a mechanism to > communication this information about corruption back to the sending > TCP. I assume that the receiving wireless node computes a link-layer > checksum and determines that the packet has been corrupted. Normally > at this point, it would simply drop the packet as it is no longer > forwardable. In addition to dropping the packet, the proposal is to > send an ICMP EaTEN message back to the origin, in effect saying that > the packet was "eaten". (The ICMP includes the original IP and TCP > headers). > > The sending TCP would respond to this ICMP message in two ways. > First, it would immediately perform a fast retransmit of the corrupted > segment. Second, because it knows that the loss was *not* due to > congestion, it would *not* reduce cwnd. This would eliminate the > major detriment (to TCP) of having an error-prone link in the path. > > (For security, the considerations discussed in TSVWG for Phil's ICMP > kick-tcp message would be need to be included. I think this means > matching the ICMP messages to actual packet losses in order to > eliminate various forms of DoS attacks and probably also using some > type of detection for floods of these messages. This also means that > you don't actually immediately retransmit the corrupted packet, but > still wait until you get 3 dupacks -- treating the ICMP message in an > advisory fashion.) > > Note that with this solution, the error-prone hop can be anywhere in > the path; it is not restricted to being an endpoint. And it works > fine whether there are 1 or 5 or 20 wireless hops in the path. > > Cons to the EaTEN ICMP concept: > > 1. Phil posed the following question: if all this message is going to > accomplish is to have TCP retransmit the packet, why not just have > the link layer do this via an ARQ mechanism? This would get the > data there quicker, and be more efficient for the network. > > 2. The other problem is that if the part of the original segment which > was corrupted included the packet headers, the ICMP might be sent > to the wrong host or connection. > > Since the IETF, I came up with a counter-argument for Phil's point. > If the link layer can accomplish the ARQ within 3 packets of the > original transmission, there is no problem. However, if it takes > longer than this, it will be out of order by enough to trigger fast > retransmit anyway, which mean that the ARQ had no useful effect. > > There are some things we can talk about doing to TCP to make this less > of a problem (basicly delaying fast retransmit under certain > well-defined circumstances), but for long delay links such as > satellites, this might not be possible to overcome. > > I don't have a good answer for point 2. I suppose the security checks > mentioned above would provide some insurance that a misrouted message > didn't do any harm, however. > > I pose all of this to the list because I've heard suggestions from > various fronts that such a thing would be useful. I've also heard a > lot of comments to the effect that if we just design the subnetworks > correctly in the first place, this doesn't need to be a problem. > Personally, I am entirely on the fence and am usually swayed by the > arguments of whoever I happen to have spoken with most recently. > > --Jamshid From owner-pilc@lerc.nasa.gov Mon Apr 10 11:56:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19880 for ; Mon, 10 Apr 2000 11:56:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA24799 for pilc-outgoing; Mon, 10 Apr 2000 10:34:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA24760 for ; Mon, 10 Apr 2000 10:34:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA23728; Mon, 10 Apr 2000 10:34:54 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023571; Mon, 10 Apr 00 10:34:17 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id HAA30747; Mon, 10 Apr 2000 07:34:15 -0700 Reply-To: mahdavi@novell.com To: pilc Subject: Re: ICMP EaTEN message... References: <38EE7F9B.509B3344@pluris.com> From: Jamshid Mahdavi Date: 10 Apr 2000 07:34:15 -0700 In-Reply-To: Bora Akyol's message of "Fri, 07 Apr 2000 17:38:51 -0700" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Bora Akyol writes: > One concern: > > How does a wireless network router know who a corrupted packet belongs to > in a shared medium network so that it can send this message. > > Very likely, what this will boil to is sending a message to all TCP > sessions that it has seen recently on this link. This was not what I had in mind. Rather, I thought that the router could simply look at the IP header in the corrupted packet and hope that the source IP address was not corrupted. My assumption (not knowing a lot about wireless) was that there is a reasonably good chance that four bytes early in the packet would have made it through OK. However, perhaps this is not a good assumption... > You are much better of giving some sort of piggy back feedback between > wireless nodes involved in the connection to their TCPs if they happen to > be at the same place. > > For example: > > if you have wireless router A, and wireless node B, then if B got some > sort of feedback on the link quality than it can give explicit feedback to > hosts that it has TCP connections to. If on the other hand two nodes > happen to be connecting through a wireless link, then we are out of > luck. > > In a nutshell, I think that this idea even though it sounds useful at > first, is really not that useful. I'm not completely understanding your argument here, but it does sound similar to other arguments against doing this sort of thing. What I hope to see on the mailing list is some consensus on whether this is in fact a useful idea or not, and then change the text in section 4 of the error draft to match. So far, the score seems to be two votes against :-). --J From owner-pilc@lerc.nasa.gov Mon Apr 10 12:06:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20872 for ; Mon, 10 Apr 2000 12:06:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA28275 for pilc-outgoing; Mon, 10 Apr 2000 10:55:58 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA28240 for ; Mon, 10 Apr 2000 10:55:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA26725; Mon, 10 Apr 2000 10:55:55 -0400 (EDT) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026699; Mon, 10 Apr 00 10:55:49 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12efbL-0002b5-00; Mon, 10 Apr 2000 15:55:43 +0100 Date: Mon, 10 Apr 2000 15:55:40 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Jamshid Mahdavi cc: pilc Subject: Re: ICMP EaTEN message... In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On 10 Apr 2000, Jamshid Mahdavi wrote: > Bora Akyol writes: > > > One concern: > > > > How does a wireless network router know who a corrupted packet belongs to > > in a shared medium network so that it can send this message. > > > > Very likely, what this will boil to is sending a message to all TCP > > sessions that it has seen recently on this link. > > This was not what I had in mind. Rather, I thought that the router > could simply look at the IP header in the corrupted packet and hope > that the source IP address was not corrupted. My assumption (not > knowing a lot about wireless) was that there is a reasonably good > chance that four bytes early in the packet would have made it through > OK. However, perhaps this is not a good assumption... Depends on whether the IPv4 header checksum passed or not. L. PGP From owner-pilc@lerc.nasa.gov Mon Apr 10 12:26:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22567 for ; Mon, 10 Apr 2000 12:26:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA05684 for pilc-outgoing; Mon, 10 Apr 2000 11:37:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA05633 for ; Mon, 10 Apr 2000 11:37:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA03106; Mon, 10 Apr 2000 11:37:15 -0400 (EDT) Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.0) id xma003081; Mon, 10 Apr 00 11:37:14 -0400 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id KAA04732; Mon, 10 Apr 2000 10:37:10 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.9.3/8.9.3) id KAA29779; Mon, 10 Apr 2000 10:36:02 -0500 (CDT) Date: Mon, 10 Apr 2000 10:36:02 -0500 (CDT) Message-Id: <200004101536.KAA29779@sun.cs.tamu.edu> To: mahdavi@novell.com, pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> From: Jamshid Mahdavi ... >> So far, the score seems to be two votes against :-). Here is a vote partially in favor and partially against -:) There are two related possibilities for sending ICMP EaTEN type message, of which only the first one below seems to be considered in this thread: * Unnecessary fast retransmits: As you note, the receiver may determine that a packet is corrupted, and inform its sender (provided that the header info is intact). This approach may be beneficial when the channel encounters a "random" loss (as opposed to an extended period of bad state). However, in such situations, as someone else also pointed out, it may be possible to implement link level retransmissions to deal with the transmission errors (for large delay*bw links, need to ensure that link layer delivers packets "almost" in-order). * Unnecessary timeouts: An alternative situation that is not handled well by link level retransmissions is that of extended bad periods (for instance, driving through a tunnel with link broken, or losing connectivity during hand-off between non-overlapping cells, or a long error burst for whatever reason). I believe that explicit notifications are of greater value in such situations, than when you have occassional packet being corrupted by errors. In such cases, the ICMP can be generated at the base station rather than the wireless receiver, for packets destined to the wireless host (fortunately, the base station has packet header information available). If the lower layers would deliver some packets despite the above events - such as the TCP kickstart proposal - then there is less need for a new ICMP even with bursty losses. The second situation above is also why I do not much like the name ICMP EaTEN (I agree it is cute, but could misrepresent the cause of packet loss). Regards. - nitin From owner-pilc@lerc.nasa.gov Mon Apr 10 15:09:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00641 for ; Mon, 10 Apr 2000 15:09:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29100 for pilc-outgoing; Mon, 10 Apr 2000 14:05:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA29070 for ; Mon, 10 Apr 2000 14:05:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA25121; Mon, 10 Apr 2000 14:05:55 -0400 (EDT) Received: from pluris.com(208.227.9.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma024926; Mon, 10 Apr 00 14:05:11 -0400 Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA27345; Mon, 10 Apr 2000 11:05:05 -0700 (PDT) Message-ID: <38F217D0.AE7C6C4A@pluris.com> Date: Mon, 10 Apr 2000 11:05:04 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mahdavi@novell.com CC: pilc Subject: Re: ICMP EaTEN message... References: <38EE7F9B.509B3344@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Jamshid There is no way for the receiver to know which particular pieces of the header are corrupt when the checksum fails. Therefore you can assume that the source address is OK. Overall, this message will not be useful. Regards Bora Jamshid Mahdavi wrote: > Bora Akyol writes: > > > One concern: > > > > How does a wireless network router know who a corrupted packet belongs to > > in a shared medium network so that it can send this message. > > > > Very likely, what this will boil to is sending a message to all TCP > > sessions that it has seen recently on this link. > > This was not what I had in mind. Rather, I thought that the router > could simply look at the IP header in the corrupted packet and hope > that the source IP address was not corrupted. My assumption (not > knowing a lot about wireless) was that there is a reasonably good > chance that four bytes early in the packet would have made it through > OK. However, perhaps this is not a good assumption... > > > You are much better of giving some sort of piggy back feedback between > > wireless nodes involved in the connection to their TCPs if they happen to > > be at the same place. > > > > For example: > > > > if you have wireless router A, and wireless node B, then if B got some > > sort of feedback on the link quality than it can give explicit feedback to > > hosts that it has TCP connections to. If on the other hand two nodes > > happen to be connecting through a wireless link, then we are out of > > luck. > > > > In a nutshell, I think that this idea even though it sounds useful at > > first, is really not that useful. > > I'm not completely understanding your argument here, but it does sound > similar to other arguments against doing this sort of thing. What I > hope to see on the mailing list is some consensus on whether this is > in fact a useful idea or not, and then change the text in section 4 of > the error draft to match. > > So far, the score seems to be two votes against :-). > > --J From owner-pilc@lerc.nasa.gov Mon Apr 10 21:36:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08460 for ; Mon, 10 Apr 2000 21:36:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA12273 for pilc-outgoing; Mon, 10 Apr 2000 20:42:47 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA12267 for ; Mon, 10 Apr 2000 20:42:46 -0400 (EDT) Received: from katrinaljoy (ras145.lerc.nasa.gov [139.88.123.145]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id UAA26194; Mon, 10 Apr 2000 20:42:26 -0400 (EDT) Message-Id: <4.1.20000410171641.00a93220@popserve.lerc.nasa.gov> Message-Id: <4.1.20000410171641.00a93220@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Apr 2000 17:24:53 -0400 To: pilc@grc.nasa.gov From: William D Ivancic Subject: Re: ICMP EaTEN message... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk For the router to see the IP header and check sum, the layer 2 protocol would first have to pass the corrupted layer 2 data to layer 3. Layer 2 usually has its own check sum. Assuming this is the case and the IP checksum does not pass, I would be reluctant to believe anything in the header. It seams to easy to implement denial of services attacks and other bad things here. Also, I've seen ECN used in two forms: Explicit Congestion Notification and Explicit Corruption Notification. These are not interchangeable. Any suggestions on renaming Explicate Corruption Notification? I believe ECN was first used for Explicit Congestion Notification. Will Ivancic > >Bora Akyol writes: > >> One concern: >> >> How does a wireless network router know who a corrupted packet belongs to >> in a shared medium network so that it can send this message. >> >> Very likely, what this will boil to is sending a message to all TCP >> sessions that it has seen recently on this link. > >This was not what I had in mind. Rather, I thought that the router >could simply look at the IP header in the corrupted packet and hope >that the source IP address was not corrupted. My assumption (not >knowing a lot about wireless) was that there is a reasonably good >chance that four bytes early in the packet would have made it through >OK. However, perhaps this is not a good assumption... From owner-pilc@lerc.nasa.gov Mon Apr 10 21:53:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09506 for ; Mon, 10 Apr 2000 21:53:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA13598 for pilc-outgoing; Mon, 10 Apr 2000 21:06:18 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA13580 for ; Mon, 10 Apr 2000 21:06:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA15676; Mon, 10 Apr 2000 21:06:16 -0400 (EDT) Received: from sabre.sjf.novell.com(130.57.86.42) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015634; Mon, 10 Apr 00 21:05:43 -0400 Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id SAA32564; Mon, 10 Apr 2000 18:05:40 -0700 Reply-To: mahdavi@novell.com To: William D Ivancic Cc: pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... References: <4.1.20000410171641.00a93220@popserve.lerc.nasa.gov> From: Jamshid Mahdavi Date: 10 Apr 2000 18:05:40 -0700 In-Reply-To: William D Ivancic's message of "Mon, 10 Apr 2000 17:24:53 -0400" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk William D Ivancic writes: > For the router to see the IP header and check sum, the layer 2 protocol > would first have to pass the corrupted layer 2 data to layer 3. Layer 2 > usually has its own check sum. Assuming this is the case and the IP > checksum does not pass, I would be reluctant to believe anything in the > header. It seams to easy to implement denial of services attacks and other > bad things here. > > Also, I've seen ECN used in two forms: Explicit Congestion Notification > and Explicit Corruption Notification. These are not interchangeable. Any > suggestions on renaming Explicate Corruption Notification? I believe ECN > was first used for Explicit Congestion Notification. ETEN (or EaTEN) is our attempt to rename Explicit Corruption Notification, so there isn't a clash of abbreviations. I added my thoughts on one way to implement it, with ICMP. Other suggestions are also welcome! ECN should mean Explicit Congestion Notification and nothing else. --Jamshid From owner-pilc@lerc.nasa.gov Tue Apr 11 09:59:18 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04434 for ; Tue, 11 Apr 2000 09:59:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA22385 for pilc-outgoing; Tue, 11 Apr 2000 08:50:44 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA22358 for ; Tue, 11 Apr 2000 08:50:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA12843; Tue, 11 Apr 2000 08:50:40 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012720; Tue, 11 Apr 00 08:49:59 -0400 Received: from puh.eritel.se (puh.erv.ericsson.se [194.22.140.20]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA14357 for ; Tue, 11 Apr 2000 14:49:46 +0200 (MET DST) Received: from esegsnt003.erv.ericsson.se (esegsnt003 [194.22.140.6]) by puh.eritel.se (8.8.8+Sun/8.8.8) with ESMTP id OAA16216 for ; Tue, 11 Apr 2000 14:48:13 +0200 (MET DST) Received: by esegsnt003.erv.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Apr 2000 14:48:14 +0200 Message-ID: <2DADC88F8F19D31193340090277A3661030F5C92@esegsnt003.erv.ericsson.se> From: "Jan Kullander (ERV)" To: pilc@grc.nasa.gov Subject: Header compression in the LINK draft (or a new draft?) Date: Tue, 11 Apr 2000 14:48:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi, It is obvious to a link designer that extra money could be earned if header compression is made non-transparent (i.e. if e.g. IP ID is generated by the decompressor, the header checksum is recalculated, not all TCP timestamp options are transferred etc.). There are however no guidelines describing consequences (cost) of lost transparency other than general wording. I see a need for a detailed consequence description of lost transparency for each specific TCP/UDP/RTP header field. The consequences should be related to the standards as they are, to current implementations as known and maybe even to currently proposed standards as they often seem to superimpose new functionality on existing fields. I've noticed that the ROCH charter requires the decompressed result to be semantically identical to the original. This decision has surely been preceded by discussions that could be documented. maybe it could be a draft of its own If the detail level of my proposed documentation doesn't fit in the LINK draft ? /Jan Kullander ---------------------------- Ericsson Mobile Data Design AB Jan Kullander Tel (Direct): +46 31 344 6057 Fax: +46 31 344 6033 Email: Jan.Kullander@erv.ericsson.se Address: S:t Sigfridsgatan 89 / 412 66 Gothenburg / Sweden From owner-pilc@lerc.nasa.gov Tue Apr 11 14:47:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16785 for ; Tue, 11 Apr 2000 14:47:58 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA08815 for pilc-outgoing; Tue, 11 Apr 2000 13:42:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA08777 for ; Tue, 11 Apr 2000 13:42:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA26250; Tue, 11 Apr 2000 13:42:49 -0400 (EDT) Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026218; Tue, 11 Apr 00 13:42:08 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e3BHg5u09409; Tue, 11 Apr 2000 10:42:05 -0700 (PDT) Message-Id: <200004111742.e3BHg5u09409@daffy.ee.lbl.gov> To: "Jan Kullander (ERV)" Cc: pilc@grc.nasa.gov Subject: Re: Header compression in the LINK draft (or a new draft?) In-reply-to: Your message of Tue, 11 Apr 2000 14:48:13 PDT. Date: Tue, 11 Apr 2000 10:42:05 PDT From: Vern Paxson Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > I've noticed that the ROCH charter requires the decompressed result to be > semantically identical to the original. This decision has surely been > preceded by discussions that could be documented. Actually, "semantically identical" was chosen over "bitwise identical" to allow for some wiggle room, and the hairsplitting arguments about just what are the semantics have *not* yet been thrashed out. This would be a good discussion to have. Vern From owner-pilc@lerc.nasa.gov Tue Apr 11 22:14:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27233 for ; Tue, 11 Apr 2000 22:14:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA27797 for pilc-outgoing; Tue, 11 Apr 2000 21:19:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA27781 for ; Tue, 11 Apr 2000 21:19:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA26817; Tue, 11 Apr 2000 21:19:52 -0400 (EDT) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma026795; Tue, 11 Apr 00 21:19:36 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06069; Tue, 11 Apr 2000 18:19:34 -0700 (PDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA23049; Tue, 11 Apr 2000 18:19:32 -0700 (PDT) Received: from sunray-mpkd (sunray-mpkd [129.146.6.31]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA29537; Tue, 11 Apr 2000 18:19:32 -0700 (PDT) Date: Tue, 11 Apr 2000 18:19:32 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ICMP EaTEN message... To: mahdavi@novell.com Cc: William D Ivancic , pilc@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2160706241R-4A-955502373=:23136NCE.IlHAFeR" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk ---LA_F2160706241R-4A-955502373=:23136NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII i agree that it is quite hard in practice to use the first of the two message types as per nitin's classification below: "Nitin H Vaidya" said: > There are two related possibilities for sending > ICMP EaTEN type message, of which only the first one > below seems to be considered in this thread: > > * Unnecessary fast retransmits: As you note, the receiver > may determine that a packet is corrupted, and inform its > sender (provided that the header info is intact). > > This approach may be beneficial when the channel encounters > a "random" loss (as opposed to an extended period of bad state). ... > * Unnecessary timeouts: > An alternative situation that is not handled well by link level > retransmissions is that of extended bad periods (for instance, > driving through a tunnel with link broken, or losing connectivity > during hand-off between non-overlapping cells, or a long error > burst for whatever reason). > > I believe that explicit notifications are of greater value > in such situations, than when you have occassional packet > being corrupted by errors. > In such cases, the ICMP can be generated at the base > station rather than the wireless receiver, for packets > destined to the wireless host (fortunately, > the base station has packet header information available). couldn't agree more here. i presented such a solution reusing an existing (but unused) icmp msg during the TSVWG meeting in adelaide. there was pushback from van jacobson, steve deering and geoff huston primarily on the grounds that it is easy to launch DOS attacks by using this "host isolated" icmp unreachable. the DOS risk can be alleviated by applying the ttl = 255 rule to limit the DOS to neighboring systems, a mechanism originally suggested by bob gilligan for use in ipv6 neighbor discovery and also used in reverse tunneling for mobile ipv4 (rfc2344). once this is in place, the extended link outage could not be signalled from several hops away, but thems the breaks. this would still be useful in the common case in the future in which cell phones become routers between a cellular network and a local network (bluetooth, for example). i'll be writing this up as an (individual) internet draft for pittsburgh. for a quick summary see attachment. "William D Ivancic" said: > Also, I've seen ECN used in two forms: Explicit Congestion Notification > and Explicit Corruption Notification. These are not interchangeable. Any > suggestions on renaming Explicate Corruption Notification? I believe ECN > was first used for Explicit Congestion Notification. only the first usage is correct. there is text to clarify this confusion in the ERROR draft (appendices). -gabriel ---LA_F2160706241R-4A-955502373=:23136NCE.IlHAFeR Content-Type: TEXT/plain; name="isolated.txt"; charset=us-ascii Content-Description: default Error conditions can be reported with an ICMP Host Unreachable message. IP is required to pass any such messages up to transport layers like UDP and TCP, and these, in turn, to applications above them [RFC1122]. What is not clearly defined is what code within an ICMP Host Unreachable message should be used to notify of an error condition. For conditions of network outage, a currently unused 'host isolated' (code 8) was introduced for routers (actually, IMP's) to inform hosts of an outage. Additionally, [MD95] argues for the application of 'host isolated' for notifications emanating from a host's lower layers. In summary, these notifications to upper layers can originate either from within a host itself or in another host altogether. ICMP includes the necessary information to determine the sender of the notification, as well as a part of the datagram which encountered the error. --------------------------------------------------------------- [RFC1122] Robert Braden, RFC-1122, Requirements for Internet hosts- communication layers, October 1989. [MD95] Gabriel Montenegro and Steve Drach, "System Isolation and Network Fast-Fail Capability in Solaris," Second USENIX Symposium on Mobile and Location-Independent, April 1995. http://www.usenix.org/publications/library/proceedings/mob95/montenegro.html ---LA_F2160706241R-4A-955502373=:23136NCE.IlHAFeR-- From owner-pilc@lerc.nasa.gov Wed Apr 12 01:54:34 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06136 for ; Wed, 12 Apr 2000 01:54:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA08248 for pilc-outgoing; Wed, 12 Apr 2000 00:59:42 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA08233 for ; Wed, 12 Apr 2000 00:59:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA16586; Wed, 12 Apr 2000 00:59:39 -0400 (EDT) Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma016564; Wed, 12 Apr 00 00:59:13 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e3C4xC414628; Tue, 11 Apr 2000 21:59:12 -0700 (PDT) Message-Id: <200004120459.e3C4xC414628@daffy.ee.lbl.gov> To: Gabriel Montenegro Cc: mahdavi@novell.com, William D Ivancic , pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... In-reply-to: Your message of Tue, 11 Apr 2000 18:19:32 PDT. Date: Tue, 11 Apr 2000 21:59:12 PDT From: Vern Paxson Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > couldn't agree more here. i presented such a solution reusing > an existing (but unused) icmp msg during the TSVWG meeting in > adelaide. there was pushback from van jacobson, steve deering > and geoff huston primarily on the grounds > that it is easy to launch DOS attacks by using this "host > isolated" icmp unreachable. Actually, I think that's misreading their comments. Their point, I believe, was instead that there may well be multipathing available to the network, such that the failure of a particular link just means that routing will have to change to fix the problem. It's important not to take today's model where there's always a single wireless access link and from it extrapolate that that will always be the architecture. Vern From owner-pilc@lerc.nasa.gov Wed Apr 12 05:43:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14328 for ; Wed, 12 Apr 2000 05:43:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA19832 for pilc-outgoing; Wed, 12 Apr 2000 04:45:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA19817 for ; Wed, 12 Apr 2000 04:45:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA05498; Wed, 12 Apr 2000 04:45:27 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma005489; Wed, 12 Apr 00 04:45:24 -0400 Received: from puh.eritel.se (puh.erv.ericsson.se [194.22.140.20]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA19718; Wed, 12 Apr 2000 10:45:22 +0200 (MET DST) Received: from esegsnt003.erv.ericsson.se (esegsnt003 [194.22.140.6]) by puh.eritel.se (8.8.8+Sun/8.8.8) with ESMTP id KAA16746; Wed, 12 Apr 2000 10:45:21 +0200 (MET DST) Received: by esegsnt003.erv.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Apr 2000 10:45:21 +0200 Message-ID: <2DADC88F8F19D31193340090277A3661030F5C94@esegsnt003.erv.ericsson.se> From: "Jan Kullander (ERV)" To: "'Vern Paxson'" Cc: pilc@grc.nasa.gov Subject: RE: Header compression in the LINK draft (or a new draft?) Date: Wed, 12 Apr 2000 10:45:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> I've noticed that the ROCH charter requires the decompressed result to be >> semantically identical to the original. This decision has surely been >> preceded by discussions that could be documented. > >Actually, "semantically identical" was chosen over "bitwise identical" >to allow for some wiggle room, and the hairsplitting arguments about >just what are the semantics have *not* yet been thrashed out. This >would be a good discussion to have. Not being American I missed that nicety... Still, I think a documentation on the consequences of breaking the e2e transparency for each field would be more beneficial than a general discussion of principles. A ban on non-transparency will not prevent link designers from doing it but if they know the consequences, at least there will be fewer surprises. /Jan Kullander From owner-pilc@lerc.nasa.gov Wed Apr 12 11:28:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24367 for ; Wed, 12 Apr 2000 11:28:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA18066 for pilc-outgoing; Wed, 12 Apr 2000 10:03:43 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA18001 for ; Wed, 12 Apr 2000 10:03:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA06440; Wed, 12 Apr 2000 10:03:36 -0400 (EDT) Received: from taurus.cs.albany.edu(169.226.2.109) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006331; Wed, 12 Apr 00 10:02:50 -0400 Received: from karp.cs.albany.edu (karp.cs.albany.edu [169.226.2.52]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id KAA09436; Wed, 12 Apr 2000 10:01:47 -0400 (EDT) From: "S.S.Ravi" Received: (from ravi@localhost) by karp.cs.albany.edu (SMI-8.6/CLI2) id KAA23803; Wed, 12 Apr 2000 10:01:49 -0400 Date: Wed, 12 Apr 2000 10:01:49 -0400 Message-Id: <200004121401.KAA23803@karp.cs.albany.edu> To: announce@tcos.org, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@ieee.org, dbworld@cs.wisc.edu, itc@attrh1.attrh.att.com, multicomm@research.panasonic.com, pilc@grc.nasa.gov, sig-dsm@doc.ic.ac.uk, tcgn@ieee.org, testnet@canarie.ca, xtp-relay@cs.concordia.ca Subject: DIAL M Workshop (Final Call for Papers) Sender: owner-pilc@lerc.nasa.gov Precedence: bulk (Please accept our apologies if you receive multiple copies.) FINAL CALL FOR PAPERS 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Sponsored by ACM SIGMOBILE Submission Deadline: April 25, 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The workshop encourages submission of papers based on work-in-progress. Proposals for panels designed to generate lively discussions are also invited. Contributions are solicited in all areas related to mobile computing and communications where discrete algorithms and methods are utilized, including, but not limited to: distributed algorithms frequency allocation scheduling location tracking site allocation multihop packet radio networks wireless networks synchronization cryptography and security error correcting codes handover (handoff) telecommunications modeling optimization routing satellite communication PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S.S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. SUBMISSION GUIDELINES: All paper submissions and panel proposals will be handled electronically. Authors should e-mail a PostScript version of their full paper to elloyd@udel.edu. The font size should be at least 10 pt. The paper should not be longer than 10 single spaced pages using a standard 10point font. Panel proposals may be submitted in ASCII or PostScript format. A panel proposal should include panel topic, sample questions the panel would address, and proposed panel members and moderator. Since deadlines overlap, dual submission of papers to MobiCom and DIALM is encouraged. Any paper accepted for MobiCom will automatically be removed from consideration for DIALM. To ensure that the PostScript versions of the papers can be printed, use PostScript version 2 or later. Also ensure that the paper fits on "US Letter" size paper (8.5X11 inches). Reference only standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. Authors will receive a short email ack of their submission within two days of submission. If this is not received, the authors should contact the Program Chair immediately. Authors should separately email the title, authors, mailing address, and abstract to elloyd@udel.edu. All accepted papers will appear (7 to 10 pages per paper) in the workshop proceedings, which will be published by ACM. A special issue of Discrete Applied Mathematics will be devoted to a selection of submitted papers from this workshop. Full versions of the DIALM papers selected to appear in this special issue of Discrete Applied Mathematics will be subjected to the standard thorough journal refereeing process before final acceptance for the journal. IMPORTANT DATES: Submissions due : April 25, 2000 Acceptance notification: May 15, 2000 Final paper due : June 1, 2000 Workshop : August 11, 2000 From owner-pilc@lerc.nasa.gov Wed Apr 12 13:27:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28501 for ; Wed, 12 Apr 2000 13:27:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA11341 for pilc-outgoing; Wed, 12 Apr 2000 12:22:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA11324 for ; Wed, 12 Apr 2000 12:22:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA27960; Wed, 12 Apr 2000 12:22:36 -0400 (EDT) Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma027825; Wed, 12 Apr 00 12:21:54 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20318; Wed, 12 Apr 2000 09:21:51 -0700 (PDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA12618; Wed, 12 Apr 2000 09:21:49 -0700 (PDT) Received: from sunray-mpkd (sunray-mpkd [129.146.6.31]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA13156; Wed, 12 Apr 2000 09:21:47 -0700 (PDT) Date: Wed, 12 Apr 2000 09:21:48 -0700 (PDT) From: Gabriel Montenegro Reply-To: Gabriel Montenegro Subject: Re: ICMP EaTEN message... To: Vern Paxson Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <200004120459.e3C4xC414628@daffy.ee.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > couldn't agree more here. i presented such a solution reusing > > an existing (but unused) icmp msg during the TSVWG meeting in > > adelaide. there was pushback from van jacobson, steve deering > > and geoff huston primarily on the grounds > > that it is easy to launch DOS attacks by using this "host > > isolated" icmp unreachable. > > Actually, I think that's misreading their comments. Their point, I believe, > was instead that there may well be multipathing available to the network, > such that the failure of a particular link just means that routing will > have to change to fix the problem. It's important not to take today's > model where there's always a single wireless access link and from it > extrapolate that that will always be the architecture. point taken. actually they made both comments (DOS and multipath). there may have been others (are there any minutes for tsvwg meetings?). at any rate, on the multipath comment: there's plenty of occasions when it is useful, in particular when one looks at the predictions of how common the following scenario will be: cell phone with two interfaces: cellular bluetooth laptop or pda accessing the internet via the cell phone's routing services in this case (or replace "bluetooth" with "serial cable" etc) there is no multipath, the cell phone is not only the default but also the exclusive router for the laptop/pda. the icmp msg by itself just has enough information about where the link is down. of course if there is multipath one could take that as a hint to go try another route or apply whatever heuristic may apply. -gabriel From owner-pilc@lerc.nasa.gov Wed Apr 12 14:14:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00058 for ; Wed, 12 Apr 2000 14:14:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA17912 for pilc-outgoing; Wed, 12 Apr 2000 13:10:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA17872 for ; Wed, 12 Apr 2000 13:10:44 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA04757; Wed, 12 Apr 2000 13:10:40 -0400 (EDT) Received: from cse.uta.edu(129.107.12.1) by seraph3.lerc.nasa.gov via smap (V5.0) id xma004723; Wed, 12 Apr 00 13:10:37 -0400 Received: from cse.uta.edu (IDENT:ramesh@[129.107.22.67]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id MAA01964; Wed, 12 Apr 2000 12:10:20 -0500 (CDT) Message-ID: <38F4AEE8.59AECBE8@cse.uta.edu> Date: Wed, 12 Apr 2000 12:14:16 -0500 From: Ramesh Yerraballi Reply-To: ramesh@cse.uta.edu Organization: UTA Computer Science and Engineering X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: announce@tcos.org, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@ieee.org, dbworld@cs.wisc.edu, itc@attrh1.attrh.att.com, multicomm@research.panasonic.com, pilc@grc.nasa.gov, sig-dsm@doc.ic.ac.uk, xtp-relay@cs.concordia.ca Subject: WoWMoM-2000: Call for Papers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Please accept our apologies if you receive multiple copies of this call for papers (FINAL CALL FOR PAPERS) ------------------------------------------------------------------------- The Third ACM International Workshop on WIRELESS MOBILE MULTIMEDIA (WoWMoM-2000) (to be held in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center Boston, Massachusetts, USA Sponsored by ACM SIGMOBILE with support from Nortel Networks, Microsoft Research, University of California at Riverside, and DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science, and CReWMaN at the University of Texas at Arlington URL: http://www.cse.uta.edu/crew/wowmom-2000/ SUBMISSION DEADLINE: April 25, 2000 GENERAL CHAIR Sajal K. Das, Director Center for Research in Wireless Mobility and Networking (CReWMaN) Department of Computer Science and Engineering Tel: (817) 272-7405 The University of Texas at Arlington Fax: (817) 272-3784 Arlington, TX 76019-0015 E-mail: das@cse.uta.edu PROGRAM CO-CHAIRS Satish K. Tripathi, Dean Kalyan Basu, Director William R. Johnson, Jr. Family Professor Wireless Technologies Bourns College of Engineering Nortel Networks University of California 2201 Lakeside Blvd Riverside, CA 92521-0425 Richardson, TX 75083 USA USA Phone: (909) 787-6374 Phone : (972) 684-5399 Fax: (909) 787-3188 Fax : (972) 684-3775 E-mail: tripathi@engr.ucr.edu E-mail: kbasu@nortelnetworks.com ------------------------------------------------------------------------- IMPORTANT DATES: Paper Submissions Deadline: April 25, 2000 Acceptance Notification: June 1, 2000 Camera-ready Manuscripts: June 15, 2000 Workshop August 11, 2000 ------------------------------------------------------------------------- SCOPE: Over the last decade there has been a rapid growth of wireless communication technology. Voice communication using cellular phones has matured and become a significant part of our life today. In the recent past, the emergence of portable computing devices such as notebook computers and personal digital assistants have led to the opportunity of such services as electronic mail, fax and calendar/diary programs being provided to mobile or roving users. Observing this trend, it can be predicted that the traffic over next generation, high-speed wireless networks will be dominated by personal multimedia applications such as video/news-on-demand, telemetry services, traveler information systems, WWW browsing, and so on. The 3rd Generation Wireless activities are focused through the effort of UMTS and IMT-2000 are considering the ATM technologies for the network implementation. The recent activities at 3GIP forum is actively considering the use of IP technology for the future wireless network. The wideband wireless network using IP technology is becoming an important industry issue and the seamless integration of the wireless standards and wireless IP and mobility standard are necessary to create this future network. The role of the different IP technologies like SIP, HTML, XML, Netmeeting for wireless and mobility are not finalized and will require considerable discussion to obtain the resolution. Also, the wireless access techniques like Bluetooth, WAP etc may require seamless integration to the 2.5G (GPRS) and 3G wireless standards. The objective of this workshop is to provide a forum for researchers and technologists to present new ideas and contributions in the form of technical paper, panel discussions, as well as online demos of service applications or technology related to wireless multimedia. The issues and challenges for the development of wireless multimedia networks not only encompass a broad spectrum of research topics such as quality-of-service provisioning, broadband wireless, network support, protocols, or handover, but also involves a way to envision the evolution of multimedia networks in the future. TOPICS: Technical papers and/or product demos are solicited in all areas related to wireless multimedia and its interfaces (or co-existence) with the conventional wireline networks. Topics include but are not limited to: - Third Generation Systems - Multimedia Applications - Fixed or Mobile Wireless Multimedia Access - Wireless Network Evolution - Broadband Wireless - Wireless ATM and Wireless IP - Multicasting in Wireless Services - Delay and Jitter Management for Multimedia Services - Synchronization of Multimedia Wireless services using ATM and IP - Quality-of-Service and Admission Control - Multimedia Network Architecture and Protocols - Compression Techniques - Mobility Management & Handover Issues - Routing - WWW Browsing - Telemetry Services - Broadcast Data - Mobile Agents ------------------------------------------------------------- SUBMISSION GUIDELINES: All submissions will be handled electronically. Authors should E-mail a Postscript version of their full paper to wowmom-2000@engr.ucr.edu . This E-mail address will become available by February 15, 2000. In order to ensure that the Postscript versions of the papers can be printed, authors should be careful that their papers meet the following restrictions: - Postscript version 2 or later. - Fits properly on "US Letter" size paper (8.5 X 11 inches) - Reference only Computer Modern or standard Adobe printer fonts (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the Postscript file. - No longer than 20 pages including, pictures, tables and references. In addition, authors should separately E-mail the title, author names and full address, and abstract of their paper to the Program Co-Chairs: Satish K. Tripathi at tripathi@engr.ucr.edu and Kalyan Basu at kbasu@nortel.com. It is expected that all accepted papers will be presented at the workshop. The Workshop Proceedings will be published by the ACM Press. Selected papers will be considered for publication in the ACM/Baltzer WINET and MONET journals. (WoWMoM'99 and WoWMoM'98 proceedings are available on the ACM digital library.) TECHNICAL PROGRAM COMMITTEE * Azzedine Boukerche (Univ of North Texas, USA) * Pravin Bhagwat (IBM Watson Research Center, USA) * Andrew Campbell (Columbia Univ, USA) * Yanghee Choi (Seoul National Univ, Korea) * K.-C. Chua (National University of Singapore) * Marco Conti (CNUCE, Pisa, Italy) * Subir Das (Telcordia Technologies, USA) * Lorenzo Donatiello (Univ of Bologna, Italy) * Anthony Joseph (UC Berkeley, USA) * Anurag Kumar (Indian Inst of Science, Bangalore) * Mohan Kumar (Curtin Univ, Perth, Australia) * Giri Mandyam (Nokia Research, Irving, USA) * Hiroyuki Morikawa (University of Tokyo, Japan) * S. Muthukrishnan (At&T Research) * Raja Neogi (Intel, Portland, USA) * Venkat Padmanabhan (Microsoft Research, USA) * Vasant Prabhu (Univ of Texas at Arlington, USA) * Jason Redi (BBN Technologies, USA) * Sumit Roy (Univ of Washington, USA) * Sanjoy Sen (Nortel Networks, USA) * Krishna Sivalingam (Washington State Univ, USA) * Mani Srivastava (Univ of California at Los Angeles, USA) * Violet Syrotiuk (Univ of Texas at Dallas, USA) * Philip Whiting (Lucent/Bell Labs, USA) STEERING COMMITTEE * Prathima Agrawal (Telcordia) * Ian Akyildiz (Georgia Institute of Technology) * Kalyan Basu (Nortel Networks) * Maurizio Bonuccelli (University of Pisa) * Imrich Chlamtac (University of Texas at Dallas) * Sajal K. Das (Univ of Texas at Arlington) * Randy Katz (University of California at Berkeley) * Mahmoud Naghshineh (IBM Watson Research) * Christopher Rose (Rutgers University) * Mischa Schwartz (Columbia University) * Satish Tripathi (University of California at Riverside) FINANCE CHAIR * Tom Jacob, University of North Texas PUBLICITY CO-CHAIRS * Dhawal Moghe, Nortel Networks * Ramesh Yerraballi, Univ of Texas at Arlington * Claude Castelluccia, INRIA Rhone-Alpes * Amitava Mukherjee, Pricewaterhouse Coopers Ltd. From owner-pilc@lerc.nasa.gov Wed Apr 12 14:24:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00362 for ; Wed, 12 Apr 2000 14:24:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA19961 for pilc-outgoing; Wed, 12 Apr 2000 13:24:16 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA19914 for ; Wed, 12 Apr 2000 13:24:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA06652; Wed, 12 Apr 2000 13:24:10 -0400 (EDT) Received: from pluris.com(208.227.9.12) by seraph3.lerc.nasa.gov via smap (V5.0) id xma006604; Wed, 12 Apr 00 13:23:35 -0400 Received: from pluris.com (root@lightning.pluris.com [172.16.55.100]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA28525; Wed, 12 Apr 2000 10:23:24 -0700 (PDT) Message-ID: <38F4B10C.A4576078@pluris.com> Date: Wed, 12 Apr 2000 10:23:24 -0700 From: Bora Akyol X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vern Paxson CC: Gabriel Montenegro , mahdavi@novell.com, William D Ivancic , pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... References: <200004120459.e3C4xC414628@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit On the other hand, sometimes the laws of physics and financial reality set in. There may be multi-pathing when devices have two or more different wireless interfaces, such as a LAN and a WAN interface, but in the general WAN environment, it is hard to get even decent single path coverage. Moreover, the existing model of base stations and wireless nodes provides far more control to the service provider than an ad-hoc packet radio network (even though I would prefer this). Finally, with fiber coming everywhere but the last mile pretty soon, the base station model provides good cost benefits. Hence, it is not easy to assume away the current architecture either. Also note that the problem is not limited to a wireless node connecting to the Internet, but there may be two routers that are connected via a wireless link (as in the connection between SLAC and Stanford for the longest time) and the end hosts may not have a clue on what to do with the feedback they are getting. Bora Vern Paxson wrote: > > couldn't agree more here. i presented such a solution reusing > > an existing (but unused) icmp msg during the TSVWG meeting in > > adelaide. there was pushback from van jacobson, steve deering > > and geoff huston primarily on the grounds > > that it is easy to launch DOS attacks by using this "host > > isolated" icmp unreachable. > > Actually, I think that's misreading their comments. Their point, I believe, > was instead that there may well be multipathing available to the network, > such that the failure of a particular link just means that routing will > have to change to fix the problem. It's important not to take today's > model where there's always a single wireless access link and from it > extrapolate that that will always be the architecture. > > Vern From owner-pilc@lerc.nasa.gov Thu Apr 13 03:13:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23728 for ; Thu, 13 Apr 2000 03:13:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA25678 for pilc-outgoing; Thu, 13 Apr 2000 01:56:51 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA25673 for ; Thu, 13 Apr 2000 01:56:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id BAA29475; Thu, 13 Apr 2000 01:56:48 -0400 (EDT) Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.0) id xma029466; Thu, 13 Apr 00 01:56:14 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e3D5uAT17757; Wed, 12 Apr 2000 22:56:10 -0700 (PDT) Message-Id: <200004130556.e3D5uAT17757@daffy.ee.lbl.gov> To: Gabriel Montenegro Cc: pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... In-reply-to: Your message of Wed, 12 Apr 2000 09:21:48 PDT. Date: Wed, 12 Apr 2000 22:56:10 PDT From: Vern Paxson Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > point taken. actually they made both comments (DOS and multipath). > there may have been others (are there any minutes for tsvwg meetings?). Here's the relevant portion of the draft minutes (which I'll send out to the tsvwg list shortly). Vern Link Outage ICMP Notification -- Gabriel Montenegro, Sun Both link-outage and link-outage-over are useful. Link outage was a valid message at one time, worth revisiting. Easy to send, no state, simple synchronous response using ICMP which stacks and apps already know about: use 'host unreachable' message. RFC1122 says IP must pass these messages to transport. But can't overload existing 'unreachable' codes. Recommend using code #8: 'host isolated.' Introduced for routers (IMPs, actually). Contains enough message to identify originating host. Actions could include local disk caching, activate browser use of caches, freeze timers, etc. Possible issues include whether errors are hard or soft. Could decide based on whether message comes from local host or router. Steve Deering: some links will send 'destination unreachable' messages when link goes down. What is an example of a hard error? Gabe: one in which the upper layers won't retransmit forever. Like unhooking ethernet during an NFS transaction. Steve: would need an AI to guess what the right response is. Give me an example when you'd know what to do? Geoff Houston: what about the denial of service implications? This would be a great way to take down a network. (Steve: minumum ICMP format include IP header plus 8 bytes.) Jamshid: ICMP net down + ICMP kick won't work to manage TCP because you can't be sure you'll get the kick. Van Jacobson: because one router can't reach a destination doesn't mean the packets won't reach the destination. Most vendors tend to misinterpret this information. Many firewalls filter out these ICMP messages. Suggest you don't do this because you can't know enough about your topology except for very simple networks. Steve: one use for ICMP message is to print out a diagnostic when application finally quits. From owner-pilc@lerc.nasa.gov Fri Apr 14 07:34:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05945 for ; Fri, 14 Apr 2000 07:34:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA19846 for pilc-outgoing; Fri, 14 Apr 2000 06:17:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA19835 for ; Fri, 14 Apr 2000 06:17:15 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA21527; Fri, 14 Apr 2000 06:17:15 -0400 (EDT) Received: from kruuna.helsinki.fi(128.214.205.14) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021492; Fri, 14 Apr 00 06:16:34 -0400 Received: from localhost (ssyreeni@localhost) by kruuna.Helsinki.FI (8.8.8/8.8.0) with ESMTP id NAA08325; Fri, 14 Apr 2000 13:16:21 +0300 (EET DST) X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Fri, 14 Apr 2000 13:16:20 +0300 (EET DST) From: Sampo A Syreeni Reply-To: Sampo Syreeni To: Bora Akyol cc: pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... In-Reply-To: <38F4B10C.A4576078@pluris.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Wed, 12 Apr 2000, Bora Akyol wrote: >There may be multi-pathing when devices have two or more different wireless >interfaces, such as a LAN and a WAN interface, but in the general WAN >environment, it is hard to get even decent single path coverage. GSM/GPRS plus LEO satellite capability would be a good example, at least in Europe. The service is becoming available. Sampo Syreeni , aka decoy, student/math/Helsinki university From owner-pilc@lerc.nasa.gov Sat Apr 15 23:24:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10397 for ; Sat, 15 Apr 2000 23:24:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16249 for pilc-outgoing; Sat, 15 Apr 2000 22:09:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA16245 for ; Sat, 15 Apr 2000 22:09:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA15965; Sat, 15 Apr 2000 22:09:49 -0400 (EDT) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma015957; Sat, 15 Apr 00 22:09:09 -0400 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.3) with ESMTP id TAA37611; Sat, 15 Apr 2000 19:09:07 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200004160209.TAA37611@elk.aciri.org> To: Bora Akyol cc: pilc From: Sally Floyd Subject: Re: ICMP EaTEN message... Date: Sat, 15 Apr 2000 19:09:07 -0700 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >How does a wireless network router know who a corrupted packet belongs to >in a shared medium network so that it can send this message. One possibility for ETEN might be the following: Assume that the link-level protocol uses FEC and/or link-level retransmission, as a good link-level protocol for a lossy link should, but that, at some point, the link-level protocol decides to give up on trying to retransmit the corrupted packet. At this point, the link-level *receiver* does not necessarily know the correct packet header for the corrupted packet, but the link-level *sender* does know the correct header. So it would seem that the link-level receiver could tell the link-level sender to send a short notification message, to the correct destination, that the link-level has given up trying to correctly transmit the data packet with this packet header. (Yes, this short message could get corrupted also; in this case, the loss will be interpreted by the end node as a congestion-related loss.) One possible scenario for ETEN is for a TCP that has had a single packet loss, has detected this loss with Fast Retransmit, and has successfully retransmitted this packet and reduced its congestion window in half. If the TCP sender learns, perhaps some time later, that this loss was in fact due to corruption and not congestion, then the TCP sender can, after the fact, "undo" its reduction of the congestion window, by slow-starting back up to its previous value. (I don't know the correct response of a TCP sender to the routine loss of packets due to corruption, but reducing the congestion window in half in response to a single packet lost due to corruption seems like overkill to me...) A second possible scenario for ETEN would be for an unreliable, unicast transport protocol that uses equation-based congestion control (e.g., "http://www.aciri.org/tfrc/"). Instead of reducing the sending rate in half in response to each specific packet loss, with equation-based congestion control the sender adjusts the sending rate to the TCP-compatible sending rate that fits the packet loss rate observed over a longer time interval. Again, if the sender learns after the fact that a loss was due to corruption rather than to congestion, then the sender could adjust its sending rate appropriately (whatever is the appropriate adjustment of the sending rate to occasional packet corruption). Yes? No? Did I forget something? The ideas are that in cooperation, the link-level sender and the link-level receiver should know the correct packet header for the corrupted packet; and that it could be useful for the sender to find that a loss was due to corruption rather than congestion even if the sender receives this information some time after it has made a congestion-control response to the packet loss. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Sun Apr 16 12:06:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08655 for ; Sun, 16 Apr 2000 12:06:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA11343 for pilc-outgoing; Sun, 16 Apr 2000 11:08:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA11335 for ; Sun, 16 Apr 2000 11:08:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA00587; Sun, 16 Apr 2000 11:08:20 -0400 (EDT) Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.0) id xma000558; Sun, 16 Apr 00 11:08:00 -0400 Received: from photon.cs.tamu.edu (IDENT:2654@photon [128.194.134.1]) by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id KAA03527; Sun, 16 Apr 2000 10:07:58 -0500 (CDT) From: Nitin H Vaidya Received: (from vaidya@localhost) by photon.cs.tamu.edu (8.9.3/8.9.3) id KAA04829; Sun, 16 Apr 2000 10:07:47 -0500 (CDT) Date: Sun, 16 Apr 2000 10:07:47 -0500 (CDT) Message-Id: <200004161507.KAA04829@photon.cs.tamu.edu> To: floyd@aciri.org Subject: Re: ICMP EaTEN message... Cc: pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> From owner-pilc@lerc.nasa.gov Sat Apr 15 21:20:53 2000 >> To: Bora Akyol >> cc: pilc >> From: Sally Floyd >> Subject: Re: ICMP EaTEN message... >> Date: Sat, 15 Apr 2000 19:09:07 -0700 >> >> >How does a wireless network router know who a corrupted packet belongs to >> >in a shared medium network so that it can send this message. >> >> One possibility for ETEN might be the following: >> >> Assume that the link-level protocol uses FEC and/or link-level >> retransmission, as a good link-level protocol for a lossy link >> should, but that, at some point, the link-level protocol decides >> to give up on trying to retransmit the corrupted packet. At this >> point, the link-level *receiver* does not necessarily know the >> correct packet header for the corrupted packet, but the link-level >> *sender* does know the correct header. So it would seem that the >> link-level receiver could tell the link-level sender to send a >> short notification message, to the correct destination, that the The link level sender could do this without having to be told by the link level receiver. Is there a disadvantge to link level sender acting on its own? We have previously suggested a couple of related approaches (named Partial Ack, and Explicit Bad State Notification), which differ in the amount of information provided in the feedback to TCP sender (www.cs.tamu.edu/faculty/vaidya/mobile/). >> link-level has given up trying to correctly transmit the data packet >> with this packet header. (Yes, this short message could get >> corrupted also; in this case, the loss will be interpreted by the >> end node as a congestion-related loss.) >> >> One possible scenario for ETEN is for a TCP that has had a single >> packet loss, has detected this loss with Fast Retransmit, and has >> successfully retransmitted this packet and reduced its congestion >> window in half. If the TCP sender learns, perhaps some time later, >> that this loss was in fact due to corruption and not congestion, >> then the TCP sender can, after the fact, "undo" its reduction of >> the congestion window, by slow-starting back up to its previous >> value. This sounds like a good idea - if I understand correctly, Reiner Ludwig's Eiffel algorithm behaves similarly. >> (I don't know the correct response of a TCP sender to the routine >> loss of packets due to corruption, but reducing the congestion >> window in half in response to a single packet lost due to corruption >> seems like overkill to me...) >> >> A second possible scenario for ETEN would be for an unreliable, >> unicast transport protocol that uses equation-based congestion >> control (e.g., "http://www.aciri.org/tfrc/"). Instead of reducing >> the sending rate in half in response to each specific packet loss, >> with equation-based congestion control the sender adjusts the >> sending rate to the TCP-compatible sending rate that fits the packet >> loss rate observed over a longer time interval. Again, if the >> sender learns after the fact that a loss was due to corruption >> rather than to congestion, then the sender could adjust its sending >> rate appropriately (whatever is the appropriate adjustment of the >> sending rate to occasional packet corruption). >> >> Yes? No? Did I forget something? >> >> The ideas are that in cooperation, the link-level sender and the >> link-level receiver should know the correct packet header for the >> corrupted packet; and that it could be useful for the sender to find >> that a loss was due to corruption rather than congestion even if >> the sender receives this information some time after it has made >> a congestion-control response to the packet loss. This may sounds like nitpicking, but I would suggest we also consider congestion versus non-congstion losses, rather than just congestion versus corruption (for instance, packet loss during hand-off is not a corruption loss, but has similar impact as a bursty error loss). - nitin >> >> - Sally >> -------------------------------- >> http://www.aciri.org/floyd/ >> -------------------------------- >> From owner-pilc@lerc.nasa.gov Mon Apr 17 05:10:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27774 for ; Mon, 17 Apr 2000 05:10:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA15640 for pilc-outgoing; Mon, 17 Apr 2000 03:57:55 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA15626 for ; Mon, 17 Apr 2000 03:57:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA07344; Mon, 17 Apr 2000 03:57:53 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007335; Mon, 17 Apr 00 03:57:44 -0400 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA27398; Mon, 17 Apr 2000 09:57:41 +0200 (MET DST) Received: from eifel.eed.ericsson.se (eifel [164.48.194.242]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id JAA06933; Mon, 17 Apr 2000 09:57:37 +0200 (MET DST) Message-Id: <4.2.0.58.20000417093818.00b88c40@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 17 Apr 2000 09:57:26 +0200 To: mahdavi@novell.com From: Reiner Ludwig Subject: Re: ERROR draft comments... Cc: "pilc@grc.nasa.gov" In-Reply-To: References: <"Falk, Aaron"'s message of "Thu, 6 Apr 2000 14:43:45 -0400"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 02:46 07.04.00 , Jamshid Mahdavi wrote: >Section 2.3: > > > In low-speed, high error-rate environments (for example, the > > wireless WAN environment), TCP windows are much smaller, and burst > > errors must be much longer in duration in order to damage multiple > > segments. Accordingly, the complexity of SACK may not be > > justifiable, unless there is a high probability of both burst > > errors and congestion. > >This logic doesn't make a lot of sense to me. I suppose that if your >error rate is high, and you are constantly timing out, SACK is not >going to make any difference. But if there is congestion too >(i.e. the total error rate is even higher), SACK is going to help even >less. > >I'm not an expert, but I would think that in wireless environments, >changes in surroundings (i.e. someone walks in front of the wireless >card) would cause a high probability of correlated errors. This would >imply to me multiple losses per window, exactly the thing that SACK >is good for. So if things mostly *don't* suck, SACK will help for the >times when they do. In http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/ we present measurements from a low-speed wireless WAN environment (9.6 Kb/s GSM circuit-switched data) and we do find the mentioned correlated losses. This would speak in favor of SACK which we believe is a win anyway (at least it never hurts). However, we believe that persistent link layer ARQ for the class of reliable flows (TCP, Reliable-Multicast, etc.) is an even better solution. Still, SACK helps for correlated congestion losses and on wireless links that do not (or cannot, e.g., unidirectional satellite) implement link layer ARQ. Also note, that (unlike stated in the above cited section 2.3) the fact that an environment is low-speed has little influence on the TCP sender's congestion window if router buffers are large enough. The advertized window remains to be the limit and the congestion window will usually get there. ///Reiner From owner-pilc@lerc.nasa.gov Mon Apr 17 05:20:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27867 for ; Mon, 17 Apr 2000 05:20:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA16615 for pilc-outgoing; Mon, 17 Apr 2000 04:23:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA16611 for ; Mon, 17 Apr 2000 04:23:23 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA09054; Mon, 17 Apr 2000 04:23:23 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009022; Mon, 17 Apr 00 04:22:44 -0400 Received: from chapelle.eed.ericsson.se (chapelle.eed.ericsson.se [164.48.194.130]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA18399; Mon, 17 Apr 2000 10:22:42 +0200 (MET DST) Received: from eifel.eed.ericsson.se (eifel [164.48.194.242]) by chapelle.eed.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA22651; Mon, 17 Apr 2000 10:22:39 +0200 (MET DST) Message-Id: <4.2.0.58.20000417101951.00994560@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 17 Apr 2000 10:22:28 +0200 To: mahdavi@novell.com From: Reiner Ludwig Subject: Re: ICMP EaTEN message... Cc: pilc In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 22:23 07.04.00 , Jamshid Mahdavi wrote: >Since the IETF, I came up with a counter-argument for Phil's point. >If the link layer can accomplish the ARQ within 3 packets of the >original transmission, there is no problem. However, if it takes >longer than this, it will be out of order by enough to trigger fast >retransmit anyway, which mean that the ARQ had no useful effect. Link layer ARQ is *commonly* implemented together with the in-order delivery property, i.e., no packet can "overtake" the other. Thus, the scenario you decribe is unlikely to happen in today's wireless systems implementing link layer ARQ. ///Reiner From owner-pilc@lerc.nasa.gov Mon Apr 17 08:53:06 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01501 for ; Mon, 17 Apr 2000 08:53:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA26583 for pilc-outgoing; Mon, 17 Apr 2000 07:56:28 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA26564 for ; Mon, 17 Apr 2000 07:56:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA23957; Mon, 17 Apr 2000 07:56:25 -0400 (EDT) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma023908; Mon, 17 Apr 00 07:55:49 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0/8.10.0) with ESMTP id e3HBsdh01045; Mon, 17 Apr 2000 12:54:39 +0100 (BST) Message-ID: <38FAFB8C.B0505A89@erg.abdn.ac.uk> Date: Mon, 17 Apr 2000 12:55:10 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: mahdavi@novell.com, pilc Subject: Re: ICMP EaTEN message... References: <4.2.0.58.20000417101951.00994560@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I suggest we don't ***exclude*** the possibility of out-of-sequence delivery for future "wireless links" (i.e. RF environment). Someone said, link layer ARQ is *commonly* implemented together with the in-order delivery property.... I agree. Where the link delay is longer (an obvious example is packet satellite) there ***may*** be advantage in allowing out of sequence delivery (by which I mean the receiver ARQ does not buffer correctly received out-of-sequence packets, but forwards each good packet on arrival, retransmitting any corrupted packets later out-of-sequence). We have implemented such schemes more than once in our lab based on a modified HDLC., N.B. Lack of sequencing may also arise from routing over alternate paths / links. Gorry Fairhurst P.S. I agree with nitin, we should talk about congestion losses (meaning sender rate is too high for the moment) with non-congestion losses (i.e. the loss is not a function of the sender rate, but is a function of RF environment, access protocols, etc). Reiner Ludwig wrote: > At 22:23 07.04.00 , Jamshid Mahdavi wrote: > >Since the IETF, I came up with a counter-argument for Phil's point. > >If the link layer can accomplish the ARQ within 3 packets of the > >original transmission, there is no problem. However, if it takes > >longer than this, it will be out of order by enough to trigger fast > >retransmit anyway, which mean that the ARQ had no useful effect. > > Link layer ARQ is *commonly* implemented together with the in-order > delivery property, i.e., no packet can "overtake" the other. Thus, the > scenario you decribe is unlikely to happen in today's wireless systems > implementing link layer ARQ. > > ///Reiner From owner-pilc@lerc.nasa.gov Tue Apr 18 08:12:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02025 for ; Tue, 18 Apr 2000 08:11:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA02895 for pilc-outgoing; Tue, 18 Apr 2000 07:06:21 -0400 (EDT) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA02888 for ; Tue, 18 Apr 2000 07:06:19 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id HAA10889; Tue, 18 Apr 2000 07:06:19 -0400 (EDT) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph2.lerc.nasa.gov via smap (V5.0) id xma010526; Tue, 18 Apr 00 07:05:51 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.0/8.10.0) with ESMTP id e3IAKZh06724; Tue, 18 Apr 2000 11:21:45 +0100 (BST) Message-ID: <38FC3700.6F29B889@erg.abdn.ac.uk> Date: Tue, 18 Apr 2000 11:23:54 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Nitin H Vaidya , pilc@grc.nasa.gov Subject: Re: ICMP EaTEN message... References: <200004161507.KAA04829@photon.cs.tamu.edu> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Nitin H Vaidya wrote: > >> > >> >How does a wireless network router know who a corrupted packet belongs to > >> >in a shared medium network so that it can send this message. > >> > >> One possibility for ETEN might be the following: > >> > >> Assume that the link-level protocol uses FEC and/or link-level > >> retransmission, as a good link-level protocol for a lossy link > >> should, but that, at some point, the link-level protocol decides > >> to give up on trying to retransmit the corrupted packet. At this > >> point, the link-level *receiver* does not necessarily know the > >> correct packet header for the corrupted packet, but the link-level > >> *sender* does know the correct header. So it would seem that the > >> link-level receiver could tell the link-level sender to send a > >> short notification message, to the correct destination, that the > > The link level sender could do this without having to be told > by the link level receiver. > Is there a disadvantge to link level sender acting on its own? What you say is entirely possible - but I guess it is wise to provide this on a best effort basis - would the "request for the notification message" take a similar bandwidth to a NAK? As you say, it is probably only wise to send the notification itself using a best effort service - or you end-up needing reliability mechanisms. How valuable all this is will depend, I guess on the processes covering the probability of loss. In some cases this a shorter message may have a better chance of transmission than a longer one. In a general wireless/RF case, conditions could be very variable and this may not be necessarily so. I wonder if the problem is that you really need complete information about all losses being "link related" to inhibit CA. Whereas you only need one unexplained loss to trigger CA? > We have previously suggested a couple of related approaches > (named Partial Ack, and Explicit Bad State Notification), which > differ in the amount of information provided in the feedback > to TCP sender (www.cs.tamu.edu/faculty/vaidya/mobile/). > > >> link-level has given up trying to correctly transmit the data packet > >> with this packet header. (Yes, this short message could get > >> corrupted also; in this case, the loss will be interpreted by the > >> end node as a congestion-related loss.) > >> > >> One possible scenario for ETEN is for a TCP that has had a single > >> packet loss, has detected this loss with Fast Retransmit, and has > >> successfully retransmitted this packet and reduced its congestion > >> window in half. If the TCP sender learns, perhaps some time later, > >> that this loss was in fact due to corruption and not congestion, > >> then the TCP sender can, after the fact, "undo" its reduction of > >> the congestion window, by slow-starting back up to its previous > >> value. > > This sounds like a good idea - if I understand correctly, Reiner > Ludwig's Eiffel algorithm behaves similarly. Have you thought of what would happen if both congestion and link loss were simultaneously present? If you have one ICMP EaTEN message per missing IP fragment (not MSS?) you may be convinced that all losses are link related? > >> (I don't know the correct response of a TCP sender to the routine > >> loss of packets due to corruption, but reducing the congestion > >> window in half in response to a single packet lost due to corruption > >> seems like overkill to me...) > >> > >> A second possible scenario for ETEN would be for an unreliable, > >> unicast transport protocol that uses equation-based congestion > >> control (e.g., "http://www.aciri.org/tfrc/"). Instead of reducing > >> the sending rate in half in response to each specific packet loss, > >> with equation-based congestion control the sender adjusts the > >> sending rate to the TCP-compatible sending rate that fits the packet > >> loss rate observed over a longer time interval. Again, if the > >> sender learns after the fact that a loss was due to corruption > >> rather than to congestion, then the sender could adjust its sending > >> rate appropriately (whatever is the appropriate adjustment of the > >> sending rate to occasional packet corruption). > >> > >> Yes? No? Did I forget something? Are you suggesting a proxy/gateway? > > >> > >> The ideas are that in cooperation, the link-level sender and the > >> link-level receiver should know the correct packet header for the > >> corrupted packet; and that it could be useful for the sender to find > >> that a loss was due to corruption rather than congestion even if > >> the sender receives this information some time after it has made > >> a congestion-control response to the packet loss. > > This may sounds like nitpicking, but I would suggest we > also consider congestion versus non-congstion losses, rather than > just congestion versus corruption (for instance, packet loss > during hand-off is not a corruption loss, but has similar > impact as a bursty error loss). > > - nitin > > >> > >> - Sally > >> -------------------------------- > >> http://www.aciri.org/floyd/ > >> -------------------------------- > >> -Gorry Fairhurst. From owner-pilc@lerc.nasa.gov Tue Apr 18 14:20:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09495 for ; Tue, 18 Apr 2000 14:20:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA27824 for pilc-outgoing; Tue, 18 Apr 2000 13:23:35 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA27803 for ; Tue, 18 Apr 2000 13:23:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA11878; Tue, 18 Apr 2000 13:23:32 -0400 (EDT) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma011858; Tue, 18 Apr 00 13:23:28 -0400 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.3) with ESMTP id KAA62244; Tue, 18 Apr 2000 10:23:22 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200004181723.KAA62244@elk.aciri.org> To: Nitin H Vaidya cc: pilc@grc.nasa.gov From: Sally Floyd Subject: Re: ICMP EaTEN message... Date: Tue, 18 Apr 2000 10:23:22 -0700 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Nitin - >The link level sender could do this without having to be told >by the link level receiver. >Is there a disadvantge to link level sender acting on its own? No. It is just that the link level sender has to know that the link level receiver did not correctly receive the earlier transmission of that packet. >We have previously suggested a couple of related approaches >(named Partial Ack, and Explicit Bad State Notification), which >differ in the amount of information provided in the feedback >to TCP sender (www.cs.tamu.edu/faculty/vaidya/mobile/). Thanks, I will look at them. >This may sounds like nitpicking, but I would suggest we >also consider congestion versus non-congstion losses, rather than >just congestion versus corruption (for instance, packet loss >during hand-off is not a corruption loss, but has similar >impact as a bursty error loss). Yes, I agree. - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Tue Apr 18 14:27:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09573 for ; Tue, 18 Apr 2000 14:27:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29058 for pilc-outgoing; Tue, 18 Apr 2000 13:31:07 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA29006 for ; Tue, 18 Apr 2000 13:31:03 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA12978; Tue, 18 Apr 2000 13:31:02 -0400 (EDT) Received: from elk.aciri.org(192.150.187.21) by seraph3.lerc.nasa.gov via smap (V5.0) id xma012903; Tue, 18 Apr 00 13:30:25 -0400 Received: from elk.aciri.org (localhost [127.0.0.1]) by elk.aciri.org (8.9.3/8.9.3) with ESMTP id KAA62313; Tue, 18 Apr 2000 10:30:21 -0700 (PDT) (envelope-from floyd@elk.aciri.org) Message-Id: <200004181730.KAA62313@elk.aciri.org> To: gorry@erg.abdn.ac.uk cc: pilc From: Sally Floyd Subject: Re: ICMP EaTEN message... Date: Tue, 18 Apr 2000 10:30:21 -0700 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >I suggest we don't ***exclude*** the possibility of out-of-sequence >delivery >for future "wireless links" (i.e. RF environment). I agree. One of the purposes of the proposed D-SACK (duplicate-SACK) extension to SACK, now finishing up its last call before going to Proposed Standard ("http://search.ietf.org/internet-drafts/draft-floyd-sack-00.txt"), is to allow the development of mechanisms that make TCP more robust in the presence of out-of-order delivery of packets. And TCP is not likely to be the only transport protocol operating over future "wireless links"... - Sally -------------------------------- http://www.aciri.org/floyd/ -------------------------------- From owner-pilc@lerc.nasa.gov Sat Apr 22 05:57:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14373 for ; Sat, 22 Apr 2000 05:57:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA15344 for pilc-outgoing; Sat, 22 Apr 2000 04:21:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA15335 for ; Sat, 22 Apr 2000 04:21:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA07560; Sat, 22 Apr 2000 04:21:22 -0400 (EDT) Received: from unknown(202.106.187.151) by seraph3.lerc.nasa.gov via smap (V5.0) id xma007533; Sat, 22 Apr 00 04:21:08 -0400 Received: (qmail 15422 invoked by uid 99); 22 Apr 2000 08:21:37 -0000 Message-ID: <20000422082137.15421.qmail@sina.com> From: myzhai To: pilc@grc.nasa.gov Subject: about loss rate of wireless link Date: Sat Apr 22 16:21:37 CST 2000 X-Mailer: SinaMail 3.0Beta (FireToad) Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi, I have a question about wireless comm. to ask you.The problem is: if a wireless user, for example, a wireless phone user establishes a number of connections to a webserver at the same time, assumed three connections ,one bit rate is 1Mbps, one is 3Mbps and the third is 10Mbps.we only consider the condition that the last hop is wireless or satellite, then if there are losses occur on the wireless hop for example because of handoff or interference, I want to know do the three connections have the same loss rates under the same condition? How can we model the loss of wireless channel, random loss or bursty loss? thx Zhai ______________________________________ =================================================================== ÐÂÀËÃâ·Ñµç×ÓÓÊÏä http://mail.sina.com.cn From owner-pilc@lerc.nasa.gov Mon Apr 24 06:11:29 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29446 for ; Mon, 24 Apr 2000 06:11:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA16617 for pilc-outgoing; Mon, 24 Apr 2000 04:57:34 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA16613 for ; Mon, 24 Apr 2000 04:57:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA09058; Mon, 24 Apr 2000 04:57:32 -0400 (EDT) Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.0) id xma009029; Mon, 24 Apr 00 04:56:57 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.10.1/8.10.1) with ESMTP id e3O8nFF24350; Mon, 24 Apr 2000 09:49:16 +0100 (BST) Message-ID: <39040A9D.547709CD@erg.abdn.ac.uk> Date: Mon, 24 Apr 2000 10:02:32 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: myzhai CC: pilc@grc.nasa.gov Subject: Re: about loss rate of wireless link References: <20000422082137.15421.qmail@sina.com> Content-Type: text/plain; charset=iso-8859-1; x-mac-type="54455854"; x-mac-creator="4D4F5353" X-MIME-Autoconverted: from 8bit to quoted-printable by erg.abdn.ac.uk id e3O8nFF24350 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id EAA16614 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit I'm not sure relates to the Internet Protocol over wireless or satellite... Basically the answer to what you are asking will depend upon the power budgets for each case, and the modulation/FEC schemes used. If all things are equal, the packet loss rate is given by the bit error rate, the packet (frame) size: Packet Success rate = p = (1-b)**m. b= ber. m=packet size in bits. The bit error rate is related to the signal to noise ratio, or bit energy divided by noise. Naturally for the same given power, the bit error rate is much smaller if the energy per bit is smaller (i.e. at higher data rates where bits are smaller). The situation would be more complex if the different data rates each used different parameters, or an adaptive system was used. Interference poses a different problem - generally interference results in a very significant increase in noise. Unless an adaptive technique is used, it is likely that a packet sent at any rate would be corrupted - performance could be independent of rate. I think you may need to look at electronics/communications/propagation references to get your answer, I believe the PILC mailing list focusses on Internet protocol issues, not the physical medium. Best wishes, Gorry Fairhurst. myzhai wrote: > Hi, > I have a question about wireless comm. to ask you.The problem is: > if a wireless user, for example, a wireless phone user establishes a number of connections > to a webserver at the same time, assumed three connections ,one bit rate is 1Mbps, one is > 3Mbps and the third is 10Mbps.we only consider the condition that the last hop is wireless or satellite, > then if there are losses occur on the wireless hop for example because of handoff > or interference, I want to know do the three connections have the same loss rates under the > same condition? How can we model the loss of wireless channel, random loss or bursty loss? > > thx > Zhai > > ______________________________________ > > =================================================================== > ?ÂÀËÃâ·ÑµçxÓÓÊÏä http://mail.sina.com.cn From owner-pilc@lerc.nasa.gov Fri Apr 28 02:07:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25029 for ; Fri, 28 Apr 2000 02:07:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA16183 for pilc-outgoing; Fri, 28 Apr 2000 01:02:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA16173 for ; Fri, 28 Apr 2000 01:02:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id BAA20334; Fri, 28 Apr 2000 01:02:35 -0400 (EDT) Received: from swan.prod.itd.earthlink.net(207.217.120.123) by seraph3.lerc.nasa.gov via smap (V5.0) id xma020294; Fri, 28 Apr 00 01:01:52 -0400 Received: from vaio (1Cust19.tnt3.stafford.tx.da.uu.net [63.17.28.19]) by swan.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id WAA28035 for ; Thu, 27 Apr 2000 22:01:49 -0700 (PDT) From: "Shirley Tseng" To: Subject: IEEE 802.16 Broadband wireless meeting May 1-5 Date: Thu, 27 Apr 2000 22:06:31 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit FYI - apologies for the late posting. Shirley Tseng * SESSION #7 IN MARYLAND 802.16 Working Group on Broadband Wireless Access Session #7 takes place on 1-5 May 2000 at the Gaithersburg Hilton in Gaithersburg, Maryland, USA (near Washington, DC). The host is Yunsang Park of Hughes Network Systems, which is serving as corporate host. The session web site provides all logistical information and lists the various Calls for Contributions seeking input documents for the meetings. ETSI BRAN HIPERACCESS has accepted an invitation from 802.16 to co-locate their Meeting 18.5 along with 802.16 Session #7. Joint 802.16/HIPERACCESS Plenary Meetings will be included. The session host is Yunsang Park, Hughes Network Systems, which is serving as the corporate host. Agenda [agenda details depend on responses to Calls for Contributions] 802.16.1 PHY Task Group: Call for Contributions: Session #7 802.16.1 MAC Task Group: Call for Contributions [not published] Call for Evaluations and Improvements: IEEE 802.16.1, Session #7 802.16.2 Coexistence Task Group: Call for Comments [not published] 802.16.3 (2-11 GHz): Call For Comments on Functional Requirements Call for Contributions: Requirements for WirelessHUMANTM Systems Tutorial Open Forum Registration, Logistics, and From owner-pilc@lerc.nasa.gov Sat Apr 29 03:43:39 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07864 for ; Sat, 29 Apr 2000 03:43:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA12263 for pilc-outgoing; Sat, 29 Apr 2000 02:41:30 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id CAA12259 for ; Sat, 29 Apr 2000 02:41:25 -0400 (EDT) From: jeffallen@spotbuy.com Received: by seraph3.lerc.nasa.gov; id CAA21536; Sat, 29 Apr 2000 02:41:25 -0400 (EDT) Received: from host-209-214-98-67.sav.bellsouth.net(209.214.98.67) by seraph3.lerc.nasa.gov via smap (V5.0) id xma021513; Sat, 29 Apr 00 02:40:47 -0400 To: pilc@grc.nasa.gov Subject: Would you like to save 30% on your phone bills and... Date: Sat, 29 Apr 2000 02:47:05 Message-Id: <99.816895.205296@spotbuy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like some information on saving 30% on your Phone bills each month and how to get up to 8% back each month on your Utilities including phone. This service works for both business and residential, domestic and international. Sign up is FREE Reply with "MORE INFO" in the subject field