From owner-pilc@lerc.nasa.gov Tue Oct 3 12:22:23 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 SMTP id MAA15862 for ; Tue, 3 Oct 2000 12:22:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA19634 for pilc-outgoing; Tue, 3 Oct 2000 11:10:41 -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 SMTP id LAA19586 for ; Tue, 3 Oct 2000 11:10:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA18148; Tue, 3 Oct 2000 11:10:33 -0400 Received: from host60d9.alcatel.com(128.251.96.217) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017986; Tue, 3 Oct 00 11:10:29 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id KAA22767; Tue, 3 Oct 2000 10:10:08 -0500 (CDT) Message-ID: <39D9F705.6E95F72@usa.alcatel.com> Date: Tue, 03 Oct 2000 10:11:02 -0500 From: Vincent Magret X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig , PILC Subject: Re: pilc minutes for IETF 48 References: <4.3.2.7.0.20000918190325.00bb1d10@chapelle.ericsson.se> <4.3.2.7.0.20000920185534.00ae9b30@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > At 13:42 18.09.00 -0500, Vincent Magret wrote: > >Regarding the discussion on the LL-TCP, the draft specifies that it is > >recommended to use link layer information when possible. This can only work > >for the mobile node and the supervisor host. For the correspondent or server, > >how can this node have access to link layer, since it is not connected or > >linked to the wireless network? > > No entity above the link layer needs to have access to link layer > information to solve the problem of link outages. Please, check the > reference to my thesis that I had sent in one of my last mails. This is one point of view. If no other entity has notion of the link outage, what are the possible situation: 1. the source entity will continue to behave as is the link was still up (which is a waste of resources) 2. the link layer will stored packets (hard state, does not allows the mobile node to got via another entity) 3. the link layer will droppred the packets (pretty much useless) > > > >There is indeed a need of having a message sent from the edge node (i.e. the > >supervisor node) to the fixed node to inform this latter about the new status > >of the link. > > I don't think so. Again, it is a point of view. > > > > >I don't like the idea of having packet store in the supervisor node > > I wrote that packets are stored at the link layer sender. Well that a pure hard-state solution, you don't allow a lot of mobility. > > >because it > >is somehow an hard state situation. the mobile node can not "resume" its > >connection with another supervisor node. > > I don't understand your notion of a supervisor node nor do I think that > such a node is needed, assuming you mean that this node sits above the link > layer. All that is needed is a plain old link layer protocol which of > course is hard state. > > ///Reiner Vincent. From owner-pilc@lerc.nasa.gov Thu Oct 5 17:20: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 SMTP id RAA07116 for ; Thu, 5 Oct 2000 17:20:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA04912 for pilc-outgoing; Thu, 5 Oct 2000 15:36: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 SMTP id PAA04794 for ; Thu, 5 Oct 2000 15:35:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA17962; Thu, 5 Oct 2000 15:35:44 -0400 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017714; Thu, 5 Oct 00 15:35:28 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id e95JYjs01112; Thu, 5 Oct 2000 20:34:46 +0100 (BST) Message-ID: <39DCD7D9.B3D4F9B1@erg.abdn.ac.uk> Date: Thu, 05 Oct 2000 20:34:50 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 References: <4.3.2.7.0.20000920200846.00cb2ba0@chapelle.ericsson.se> <4.3.2.7.0.20000921222258.00c0c100@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 Reiner Ludwig wrote: > At 14:01 21.09.00 +0100, Dr G Fairhurst wrote: > > > ***However***, you have to ensure that the link layer does this _only_ for > > > the reliable flows such as the TCP-based flows. > > > >Well, here I think you need to be much more specific. What you are proposing > >may well be of merit where you are able to differentiate individual flows > >AND reliably indicate which are TCP and which are UDP. It also implies > >a sufficiently large link layer retransmission window, so that > >window does not stall during the time to recover the worst case > >loss pattern (which could be a challenge on long-delay links (e.g. > >100 Mbps satellite circuit). > > Sure, a link layer retransmission window should be well designed for its > environment of operation but when it stalls, it stalls. So what? That's not > any different from a link outage caused by some other reason. Who said OUTAGE? There are links out there which do not suffer complete outages for prolonged periods of tens of seconds (or more), but which do exhibit high rates of loss: either through bursts of errors or some other error distribution. Reliable link ARQ with full persistence usually implies you work on retransmitting the oldest packet until the link window runs out, or the transmission suceeds. In traditional link ARQ protocols, this means that you hold other data, when you are having a rough time forwarding one particular packet. When the link consists of many TCP flows, this holds all flows. Even those flows which have sent relatively little data, and are unlikely to be the one needing the retransmission. > As Vernon has pointed out in his last mail: if the link layer cannot get > the packet across the link, TCP won't be able to do that either. So for the > receiving application it doesn't make a difference whether packets cannot > be delivered to it because they are held in some link layer or by TCP. Again, what about the other hosts down-stream which have their packets queued? > >Recommendations for fully reliable ARQ may also need to consider the impact > >of alternate network paths which do not pass over the errored wireless link. > > We are talking of recommendations for a designer of a specific link layer. > Why does that require considering the impact of paths that do not pass over > that very link. > >[...] > >While this may be true in these studies, I'd like a clearer understanding of > >the factors, which influence this before we leap into general conclusions. > > > >Many, although I have not examined all of these, refer to cellular > >phone/wireless > >links, and not to generic radio links which include satellite, high bandwidth > >line of sight, very low bit rate, etc. > > I forgot to mention the Internet Draft presented by NTT DoCoMo about TCP > performance over W-CDMA. W-CDMA clearer qualifies as high bandwidth x > delay. One of their key results (which unfortunately was not on their > conclusion slide) was that they got the best TCP performance when the link > layer error recovery persistency was high. I will be most surprised if this is the case for many TCP flows sharing the link. > >I think there is evidence that at least some of > >these > >links have in the past performed very poorly with reliable ARQ protocols. > ...... > > ///Reiner Gorry Fairhurst -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Thu Oct 5 19:41:15 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 SMTP id TAA08905 for ; Thu, 5 Oct 2000 19:41:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA14179 for pilc-outgoing; Thu, 5 Oct 2000 17:58:57 -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 SMTP id RAA14134 for ; Thu, 5 Oct 2000 17:58:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA21033; Thu, 5 Oct 2000 17:58:51 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020790; Thu, 5 Oct 00 17:58:12 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e95LwAQ03477 for pilc@grc.nasa.gov env-from ; Thu, 5 Oct 2000 15:58:10 -0600 (MDT) Date: Thu, 5 Oct 2000 15:58:10 -0600 (MDT) From: Vernon Schryver Message-Id: <200010052158.e95LwAQ03477@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Dr G Fairhurst > To: Reiner Ludwig > When the link consists of many TCP flows, this holds all flows. Even those > flows which have sent relatively little data, and are unlikely to be the one > needing the retransmission. > > > As Vernon has pointed out in his last mail: if the link layer cannot get > > the packet across the link, TCP won't be able to do that either. So for the > > receiving application it doesn't make a difference whether packets cannot > > be delivered to it because they are held in some link layer or by TCP. > > Again, what about the other hosts down-stream which have their packets queued? > ... I also tried to point out that ARQ (persistent or otherwise) does not necessarily implies that all other streams must wait for one stream that is stuck. Not even TCP is still limited to go-back-N recovery tactics, so why would a newfangled radio link layer be so limited? Isn't it common common wisdom that go-back-N or stop-everything-until-a- sick-packet-gets-through is ok only when both the bandwidth*delay product and the probability of error are low? In other cases, aren't you supposed to overlap as much as possible, and so have selective ACKs or NACs and selective retransmissions? Moreover, by Dr. Fairhurst's assumptions, either 1. no other packets for any TCP stream are flowing because the link is very sick. 2. this particular packet will soon get through because the problem was temporary. 3. something is very badly broken in the design or implementation of the link layer, because one particular packet cannot get through but others can. (#3 is not in the least theoretical to those of us who've fought hardware and software problems that corrupt some packets but not others.) Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Oct 6 06:32: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 SMTP id GAA27559 for ; Fri, 6 Oct 2000 06:32:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA07665 for pilc-outgoing; Fri, 6 Oct 2000 03:32:05 -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 SMTP id DAA07567 for ; Fri, 6 Oct 2000 03:31:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA14249; Fri, 6 Oct 2000 03:31:27 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014218; Fri, 6 Oct 00 03:31:17 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e967VFt15123; Fri, 6 Oct 2000 09:31:15 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-108 [164.48.140.108]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id JAA02828; Fri, 6 Oct 2000 09:31:13 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001006092327.021b4050@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 06 Oct 2000 09:31:12 +0200 To: gorry@erg.abdn.ac.uk From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <39DCD7D9.B3D4F9B1@erg.abdn.ac.uk> References: <4.3.2.7.0.20000920200846.00cb2ba0@chapelle.ericsson.se> <4.3.2.7.0.20000921222258.00c0c100@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 21:34 05.10.00, Dr G Fairhurst wrote: >Reliable link ARQ with full persistence usually implies you work on >retransmitting >the >oldest packet until the link window runs out, or the transmission suceeds. > >In traditional link ARQ protocols, this means that you hold other data, >when you are having a rough time forwarding one particular packet. > >When the link consists of many TCP flows, this holds all flows. Even those >flows which have sent relatively little data, and are unlikely to be the one >needing the retransmission. You describe a poorly designed link layer ARQ protocol causing the head-of-line blocking problem. In this case, the problem is caused only for the other *TCP flows* since my argument was that non-TCP flows are treated separately. To avoid that problem, you can allow the link layer to do out-of-order delivery of packets belonging to different flows. You should only enforce in-order delivery for packets belonging to the same TCP flow to not falsely trigger fast retransmit / fast recovery. Caveat: the link layer must be given the opportunity to distinguish flows. ///Reiner From owner-pilc@lerc.nasa.gov Fri Oct 6 08:24: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 SMTP id IAA00026 for ; Fri, 6 Oct 2000 08:24:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA15907 for pilc-outgoing; Fri, 6 Oct 2000 05:53:09 -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 SMTP id FAA15884 for ; Fri, 6 Oct 2000 05:52:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA08101; Fri, 6 Oct 2000 05:52:32 -0400 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008067; Fri, 6 Oct 00 05:52:31 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id e969qEs03840; Fri, 6 Oct 2000 10:52:15 +0100 (BST) Message-ID: <39DDA0D1.F1B7A020@erg.abdn.ac.uk> Date: Fri, 06 Oct 2000 10:52:17 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver CC: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <200010052158.e95LwAQ03477@calcite.rhyolite.com> 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 don't think we differ as much as you may think we do. Vernon Schryver wrote: > > From: Dr G Fairhurst > > To: Reiner Ludwig > > > When the link consists of many TCP flows, this holds all flows. Even those > > flows which have sent relatively little data, and are unlikely to be the one > > needing the retransmission. > > > > > As Vernon has pointed out in his last mail: if the link layer cannot get > > > the packet across the link, TCP won't be able to do that either. So for the > > > receiving application it doesn't make a difference whether packets cannot > > > be delivered to it because they are held in some link layer or by TCP. > > > > Again, what about the other hosts down-stream which have their packets queued? > > ... > > I also tried to point out that ARQ (persistent or otherwise) does not > necessarily implies that all other streams must wait for one stream that > is stuck. Not even TCP is still limited to go-back-N recovery tactics, > so why would a newfangled radio link layer be so limited? The Selective Repeat ARQ is definitely recommended (I think you'll find when we first wrote the words for the draft it does say this already). Sorry, this debate is less than clear. I was talking only about WINDOW size, in many link ARQ schemes there is a fixed modulus or window which limits the maximum number of packets in flight. This may be determined by either amount of buffer memory or size of frame number field (before everyone shouts and says "but not all" - I know there are exceptions). The HDLC standard works this way - and so do nearly all variants of it, I have seen. Out-of-order forwarding is allowed (again in the draft) - although current recommendations are that this is only allowed when it preserves in-order delivery within each flow. This still doesn't mean an ARQ protocol can transmit for ever if it says it is RELIABLE and if there is a packet still unacknowledged at the low window edge, this can still cause window exhaustion with a finite numbering space (or available memory). > Isn't it common common wisdom that go-back-N or stop-everything-until-a- > sick-packet-gets-through is ok only when both the bandwidth*delay product > and the probability of error are low? In other cases, aren't you supposed > to overlap as much as possible, and so have selective ACKs or NACs and > selective retransmissions? Sure you are (the draft says this, I am sure it meant to anyway). > > Moreover, by Dr. Fairhurst's assumptions, either > 1. no other packets for any TCP stream are flowing because the link > is very sick. > 2. this particular packet will soon get through because the problem > was temporary. > 3. something is very badly broken in the design or implementation of > the link layer, because one particular packet cannot get through > but others can. > > (#3 is not in the least theoretical to those of us who've fought hardware > and software problems that corrupt some packets but not others.) If I understand you: 1 is what I call an OUTAGE - we have text already which recommends what to do (hang on to the last few packets if you can and send them once you are able - not quite the same as recommending persistence!) 2 may happen - but I have seen cases where this can take a long time - particularly with a big packet and periodic interference. 3. This happens too... and can be bizarre. The non-persistent argument seems to help with 2,3. At least it clears out all that old link state and any buffers tied up, so that things can resume orderly in the future. The persistent argument is equivalent to 1 for an outage. What I'm trying to find out is what we should recommend when we have a high (or moderately high) packet loss rate. If we have only one TCP flow, do we care? Probably not, as long the ARQ tries (a few attempts) or forever. The latter may even be better. Good versions of HDLC could work fine with segmentation. If we have many flows - are there other issues? I can think of these two: 1) The ability to classify UDP form TCP seems very desirable (although difficult with tunnels/encapsulation and fundamentally problematic with IPSEC) 2) I suggest sharing with other TCP flows can become an issue - perhaps less so if you are end-system connected to a mobile net, but more so if you are connecting a remote LAN with many hosts over a wireless (or any RF) link. Several factors here: per-flow state, head-of-line block when buffer/window exceeded, forwarding delay (out of order delivery may be desirable) 3) Anything else? > Vernon Schryver vjs@rhyolite.com Gorry Fiarhurst. ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Fri Oct 6 21:27:20 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 SMTP id VAA16215 for ; Fri, 6 Oct 2000 21:27:20 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA06260 for pilc-outgoing; Fri, 6 Oct 2000 19:59: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 SMTP id TAA06250 for ; Fri, 6 Oct 2000 19:59:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA09021; Fri, 6 Oct 2000 19:59:18 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008864; Fri, 6 Oct 00 19:58:26 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e96FWqk21100 for pilc@grc.nasa.gov env-from ; Fri, 6 Oct 2000 09:32:52 -0600 (MDT) Date: Fri, 6 Oct 2000 09:32:52 -0600 (MDT) From: Vernon Schryver Message-Id: <200010061532.e96FWqk21100@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Dr G Fairhurst > I don't think we differ as much as you may think we do. I suspect we differ more than either of us thought. > Sorry, this debate is less than clear. I was talking only about WINDOW size, > in many link ARQ schemes there is a fixed modulus or window which > limits the maximum number of packets in flight. This may be determined by > either amount of buffer memory or size of frame number field (before everyone >shouts and says "but not all" - I know there are exceptions). The HDLC standard > works this way - and so do nearly all variants of it, I have seen. Yes, but if you have a whole window's worth of packets that cannot get through, then the link is very sick. There's little to talk about besides radio things like hand-off that should be inivisible to TCP except possibly for a bunch of lost segments. If you have one stuck packet that is keeping the window from advancing and so you cannot get any other data through the link, then either your window is too small or you have broken hardware or software that cannot be fixed with ARQ or anything else (i.e. my #3). There is absolutely nothing that can or should be done in this case except possibly to change vendors in a forklift upgrade. > ... > > Moreover, by Dr. Fairhurst's assumptions, either > > 1. no other packets for any TCP stream are flowing because the link > > is very sick. > > 2. this particular packet will soon get through because the problem > > was temporary. > > 3. something is very badly broken in the design or implementation of > > the link layer, because one particular packet cannot get through > > but others can. > ... > 1 is what I call an OUTAGE - we have text already which recommends what > to do (hang on to the last few packets if you can and send them once you > are able - not quite the same as recommending persistence!) > > 2 may happen - but I have seen cases where this can take a long time > - particularly with a big packet and periodic interference. > > 3. This happens too... and can be bizarre. > >The non-persistent argument seems to help with 2,3. At least it clears out all > that > old link state and any buffers tied up, so that things can resume orderly > in the > future. No, in those three cases: 1. there is nothing to do. The link is broken and has been broken for at least a little while. Saving packets in the hope that the link might return might be good, but is probably a waste of cycles and memory, and quite possibly worse. You MUST NOT keep any TCP or UDP packet for longer than the MSL. You will break things if you somehow keep a packet for a long time and then eventually regurgitate it. 2. this is ordinary bit rot. If you often find problems with big packets and periodic interference, then you have misdesigned the link layer packet sizes by making it too big. 3. there is nothing that can be done in this case except to ship all of the hardware and software back to the factory, and possibly to fire the poor fellow who messed up the FEC or CRC computation, buffer chaining, or whatever. > What I'm trying to find out is what we should recommend when we have a > high (or moderately high) packet loss rate. > > If we have only one TCP flow, do we care? > Probably not, as long the ARQ tries (a few attempts) or forever. The > latter may > even be better. Good versions of HDLC could work fine with segmentation. > > If we have many flows - are there other issues? > I can think of these two: > > 1) The ability to classify UDP form TCP seems very desirable (although > difficult with tunnels/encapsulation and fundamentally problematic with IPSEC) It's wise to not attempt things that you know are impossible. Given the fact that IPSec exists, the fact that sooner or later people will get paranoid about their bits, and the fact that people are already trained to be paranoid about their voices on radios by analog cellular phone scanners, it is crazy (as in failing to accept reality) to do anything but assume IPSec makes classifying impossible. > 2) I suggest sharing with other TCP flows can become an issue - perhaps less > so if you are end-system connected to a mobile net, but more so if you are > connecting > a remote LAN with many hosts over a wireless (or any RF) link. Several factors > here: > per-flow state, > head-of-line block when buffer/window exceeded, > forwarding delay (out of order delivery may be desirable) Out of order forwarding is not desirable, but it is always far more desirable to get the bits through the link than to second guess the upper layers tolerance to re-ordering. All IP protocols and applications are absolutely required to tolerate absolutely all possible re-orderings of IP packets within the MSL. Any delaying of later packets merely because earlier packets need link layer retransmitting would be *WRONG*. And again, there is the MSL limit on how long you can delay (including retransmitting) any packet. When your window or buffer is full, what can you do beside hs head-of-line block and drop incoming packets? Mentioning that as an alternative makes as much sense as mentioning that when the system melts in a fire, it must stop working. Per-flow state might be handy, but why would you not start with the sorts of things that are already being done or considered for other sorts of routers? For example, why not do a modified RED? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Oct 6 21:44: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 SMTP id VAA17255 for ; Fri, 6 Oct 2000 21:44:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA07491 for pilc-outgoing; Fri, 6 Oct 2000 20:29: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 SMTP id UAA07481 for ; Fri, 6 Oct 2000 20:29:34 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA13903; Fri, 6 Oct 2000 20:29:34 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013805; Fri, 6 Oct 00 20:28:37 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e970SZx11679 for pilc@grc.nasa.gov env-from ; Fri, 6 Oct 2000 18:28:35 -0600 (MDT) Date: Fri, 6 Oct 2000 18:28:35 -0600 (MDT) From: Vernon Schryver Message-Id: <200010070028.e970SZx11679@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > To avoid that problem, you can allow the link layer to do out-of-order > delivery of packets belonging to different flows. You should only enforce > in-order delivery for packets belonging to the same TCP flow to not falsely > trigger fast retransmit / fast recovery. > > Caveat: the link layer must be given the opportunity to distinguish flows. Why go to any trouble to prevent out-of-order delivery? We are talking only about IP, right? Not PPP or various bridging protocols? What is the cost of out-of-order delivery? As far as I know, IP packet re-ordering has at most the following costs: - broken IP fragmentation code goes crazy this is surely not a consideration - broken UDP/IP applications go crazy they are also surely irrelevant. - TCP goes slightly slower, and with sufficient consecutive out-of-order segments, can send duplicate ACKs which can cause retransmissions. Is that last the concern? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Oct 9 08:47: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 SMTP id IAA02921 for ; Mon, 9 Oct 2000 08:47:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA04655 for pilc-outgoing; Mon, 9 Oct 2000 07:31:20 -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 SMTP id HAA04647 for ; Mon, 9 Oct 2000 07:31:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA29435; Mon, 9 Oct 2000 07:31:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029334; Mon, 9 Oct 00 07:30:57 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e99BUsZ17959; Mon, 9 Oct 2000 13:30:55 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-108 [164.48.140.108]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA22799; Mon, 9 Oct 2000 13:30:54 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001009132307.02108080@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 09 Oct 2000 13:30:53 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200010070028.e970SZx11679@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 02:28 07.10.00, Vernon Schryver wrote: > > From: Reiner Ludwig > > > ... > > To avoid that problem, you can allow the link layer to do out-of-order > > delivery of packets belonging to different flows. You should only enforce > > in-order delivery for packets belonging to the same TCP flow to not > falsely > > trigger fast retransmit / fast recovery. > > > > Caveat: the link layer must be given the opportunity to distinguish flows. > >Why go to any trouble to prevent out-of-order delivery? >We are talking only about IP, right? Not PPP or various bridging protocols? > >What is the cost of out-of-order delivery? As far as I know, IP packet >re-ordering has at most the following costs: > > - broken IP fragmentation code goes crazy > this is surely not a consideration > > - broken UDP/IP applications go crazy > they are also surely irrelevant. > > - TCP goes slightly slower, and with sufficient consecutive out-of-order > segments, can send duplicate ACKs which can cause retransmissions. > >Is that last the concern? Yes, it is. As soon as the link's capacity goes beyond 4x MTU, any link layer retransmission would cause a *spurious* fast retransmit / fast recovery in TCP. That assumes that (1) the following 3 packets do not incur a link layer retransmission and (2) out-of-order delivery is permitted even within a flow. For some wireless networks this could become a real pain ... ///Reiner From owner-pilc@lerc.nasa.gov Mon Oct 9 12:32: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 SMTP id MAA06313 for ; Mon, 9 Oct 2000 12:32:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA18099 for pilc-outgoing; Mon, 9 Oct 2000 11:27: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 SMTP id LAA18091 for ; Mon, 9 Oct 2000 11:27:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA27249; Mon, 9 Oct 2000 11:27:37 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027187; Mon, 9 Oct 00 11:27:23 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e99FRHu01670 for pilc@grc.nasa.gov env-from ; Mon, 9 Oct 2000 09:27:17 -0600 (MDT) Date: Mon, 9 Oct 2000 09:27:17 -0600 (MDT) From: Vernon Schryver Message-Id: <200010091527.e99FRHu01670@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > > - TCP goes slightly slower, and with sufficient consecutive out-of-order > > segments, can send duplicate ACKs which can cause retransmissions. > > > >Is that last the concern? > > Yes, it is. > > As soon as the link's capacity goes beyond 4x MTU, any link layer > retransmission would cause a *spurious* fast retransmit / fast recovery in > TCP. That assumes that (1) the following 3 packets do not incur a link > layer retransmission and (2) out-of-order delivery is permitted even within > a flow. > > For some wireless networks this could become a real pain ... Has the pain been simulated or measured on real wireless links? What does it mean to say "link's capacity goes beyond 4x MTU"? I would have thought that a link's capacity is measured in bits/second instead of bits. What TCP implementation ACK's based on MTU instead of MSS? What does the MTU of one link in the path have to do with the MSS? Do you mean something about the size of the queues in the radio modem/routers? In other words, I see the point, but I also wonder if some of the concerns are as valid as the concerns that lead the WAP people to conclude that TCP/IP cannot be used on wireless links because we all know that TCP/IP cannot run on links as slow as 9600 bits/second. So they've said in the main IETF list and elsewhere including the trade rags...and never mind that some of us used TCP over 9600, 2400, and even 1200 bit/sec modems, and that some of those very fast (for the day) 9600 bit/sec modems had ARQ and delays that varied between about 120 ms. and 300 ms. depending on sizes of their queues. (Telebit Trailblazers with PEP) Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Oct 9 14:02:55 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 SMTP id OAA07659 for ; Mon, 9 Oct 2000 14:02:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA25086 for pilc-outgoing; Mon, 9 Oct 2000 13:05: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 SMTP id NAA25080 for ; Mon, 9 Oct 2000 13:05:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA27309; Mon, 9 Oct 2000 13:05:16 -0400 Received: from orchard.hamachi.org(4.255.0.98) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027246; Mon, 9 Oct 00 13:05:07 -0400 Received: by orchard.arlington.ma.us (Postfix, from userid 587) id AF7FF2A1B; Mon, 9 Oct 2000 13:05:04 -0400 (EDT) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 9E56E1FCC; Mon, 9 Oct 2000 13:05:04 -0400 (EDT) To: Vernon Schryver Cc: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 In-Reply-To: Message from Vernon Schryver of "Fri, 06 Oct 2000 18:28:35 MDT." <200010070028.e970SZx11679@calcite.rhyolite.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 09 Oct 2000 13:04:59 -0400 From: Bill Sommerfeld Message-Id: <20001009170504.AF7FF2A1B@orchard.arlington.ma.us> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > What is the cost of out-of-order delivery? As far as I know, IP packet > re-ordering has at most the following costs: > > - broken IP fragmentation code goes crazy > this is surely not a consideration related, but slightly different: - broken packet filtering code goes crazy when fragments are reordered. > - broken UDP/IP applications go crazy > they are also surely irrelevant. > > - TCP goes slightly slower, and with sufficient consecutive out-of-order > segments, can send duplicate ACKs which can cause retransmissions. > > Is that last the concern? > > > Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Oct 9 23:40:27 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 SMTP id XAA15410 for ; Mon, 9 Oct 2000 23:40:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA29256 for pilc-outgoing; Mon, 9 Oct 2000 22:29:27 -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 SMTP id WAA29242 for ; Mon, 9 Oct 2000 22:29:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA00152; Mon, 9 Oct 2000 22:29:25 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000067; Mon, 9 Oct 00 22:28:35 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e99HYi004218 for pilc@grc.nasa.gov env-from ; Mon, 9 Oct 2000 11:34:44 -0600 (MDT) Date: Mon, 9 Oct 2000 11:34:44 -0600 (MDT) From: Vernon Schryver Message-Id: <200010091734.e99HYi004218@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Bill Sommerfeld > > What is the cost of out-of-order delivery? As far as I know, IP packet > > re-ordering has at most the following costs: > > > > - broken IP fragmentation code goes crazy > > this is surely not a consideration > > related, but slightly different: > - broken packet filtering code goes crazy when fragments are > reordered. Yes, but also not a concern, right? > > - TCP goes slightly slower, and with sufficient consecutive out-of-order > > segments, can send duplicate ACKs which can cause retransmissions. In thinking about possible responses to my objections to worrying about that, I've thought of other real life things. If the worry is that wireless base stations will have more than 4 MSS's of queue for each TCP stream (or a common queue for all streams bigger than 4 MSS's), and if link-layer retransmissions can cause out-of-order delivery and so fast-recovery/fast-retransmit, then there is an obvious fix that probably needs doing regardless of wireless ARQ. 4 of today's MSS's is about 6 KBytes, which is a lot more than 0.5 seconds at 14 kbit/sec. Regardless of wireless ARQ triggering false fast-retransmit, I wonder if you really want that much queue space. It is a Bad Thing(tm) for any router to have a queue that is too big. Too much queue space in the path causes bad things in old fashioned land lines. It's important for routers to signal the end points when their queues are big, and without ECN, that is done by dropping packets. For an example of the results of that Bad Thing(tm), - build a cross country intranet that includes a 56kbit/sec link. - configure the routers on the ends of the 56k link to have 60K bytes of queue. - put hosts on both ends of the path with default TCP windows of at least 60KBytes - have one or two hosts do bulk transfers (e.g. move 600 MByte CDROM imags) while the other hosts do interactive things such as rlogin, telnet, DNS, and HTTP. - run `ping` to watch latencies for the interactive jobs You'll find that the interactive jobs experience latencies that vary in a sawtooth between the speed of light and serialization delays (e.g. < 80 ms) and more than 10 seconds (10,000 ms). The solution is fix the routers so that they can tell the bulk transfer hosts to back off, and that is to reduce the queue sizes at the ends of that 56 kbit/sec link from 10 seconds * 56 Kbit/sec to about 0.5 seconds * 56 kbit/sec. I've been painfully explicit and used strange values like 56 kbit/sec because I've "been there and done that" in real life. It should be easy to adjust those strange old numbers to match modern wireless links. Just because DRAM is almost free today does not mean that you should use GBytes of it for queuing in wireless base stations. It is important for wires base stations to signal their congestion, and since you will not always have ECN to all hosts, you must drop packets, and that means you must not have too much queing. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Wed Oct 11 10:51: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 SMTP id KAA12178 for ; Wed, 11 Oct 2000 10:50:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA28327 for pilc-outgoing; Wed, 11 Oct 2000 09:41: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 SMTP id JAA28296 for ; Wed, 11 Oct 2000 09:41:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA22557; Wed, 11 Oct 2000 09:41:10 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022495; Wed, 11 Oct 00 09:41:06 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9BDf3t05009; Wed, 11 Oct 2000 15:41:04 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-108 [164.48.140.108]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA26272; Wed, 11 Oct 2000 15:41:02 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001011151423.0235a6e0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 15:41:02 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200010091527.e99FRHu01670@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:27 09.10.00, Vernon Schryver wrote: > > As soon as the link's capacity goes beyond 4x MTU, any link layer > > retransmission would cause a *spurious* fast retransmit / fast recovery in > > TCP. That assumes that (1) the following 3 packets do not incur a link > > layer retransmission and (2) out-of-order delivery is permitted even > within > > a flow. > > > > For some wireless networks this could become a real pain ... > >Has the pain been simulated or measured on real wireless links? I only know of these two studies (in literature): 1. A Comparison of Mechanisms for Improving TCP Performance over Wireless Links. Hari Balakrishnan, Venkat Padmanabhan, Srinivasan Seshan, and Randy H. Katz. 2. J.C.R. Bennett, C. Partridge and N. Shectman, Packet Reordering is Not Pathological Network Behavior, In IEEE/ACM Transactions on Networking, Decem-ber 1999. >What does it mean to say "link's capacity goes beyond 4x MTU"? I would >have thought that a link's capacity is measured in bits/second instead of >bits. What TCP implementation ACK's based on MTU instead of MSS? What >does the MTU of one link in the path have to do with the MSS? Do you mean >something about the size of the queues in the radio modem/routers? OK, so my wording was a bit loose. With the "link's capacity" I mean the number of TCP segments (MSS) that fit into a *link layer RTT*. ///Reiner From owner-pilc@lerc.nasa.gov Wed Oct 11 10:57:55 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 SMTP id KAA12313 for ; Wed, 11 Oct 2000 10:57:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA01106 for pilc-outgoing; Wed, 11 Oct 2000 09:58:19 -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 SMTP id JAA01062 for ; Wed, 11 Oct 2000 09:58:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA09222; Wed, 11 Oct 2000 09:58:15 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008429; Wed, 11 Oct 00 09:57:27 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9BDvKt11945; Wed, 11 Oct 2000 15:57:21 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-108 [164.48.140.108]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id PAA00403; Wed, 11 Oct 2000 15:57:19 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001011154117.022cc820@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 15:57:18 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200010091734.e99HYi004218@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 19:34 09.10.00, Vernon Schryver wrote: >It is a Bad Thing(tm) for any router to have a queue that is too big. >Too much queue space in the path causes bad things in old fashioned land >lines. It's important for routers to signal the end points when their >queues are big, and without ECN, that is done by dropping packets. I fully agree but also think that this is already discussed in the "Advice for Internet Subnetwork Designers" ID. >The solution is fix the routers >so that they can tell the bulk transfer hosts to back off, and that is to >reduce the queue sizes at the ends of that 56 kbit/sec link from >10 seconds * 56 Kbit/sec to about 0.5 seconds * 56 kbit/sec. If you further restrict this to say that this is the upper limit *per flow*, I would fully agree with you again. The upper limit for the number of bytes allowed for queueing at a link per flow before dropping occurs should be "fixed worst-case e2e RTT" x link speed. You have picked 500 ms for the value of "fixed worst-case RTT". That would be fine with me but might be argued ... >Just because DRAM is almost free today does not mean that you should use >GBytes of it for queuing in wireless base stations. It is important for >wires base stations to signal their congestion, and since you will not >always have ECN to all hosts, you must drop packets, and that means you >must not have too much queing. I think this is already the message of the "Advice for Internet Subnetwork Designers" ID. What is still unclear is a rule-of-thumb for the dimensioning of the queueing buffer as discussed above. ///Reiner From owner-pilc@lerc.nasa.gov Wed Oct 11 11:07:58 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 SMTP id LAA12594 for ; Wed, 11 Oct 2000 11:07:57 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05697 for pilc-outgoing; Wed, 11 Oct 2000 10:24:29 -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 SMTP id KAA05655 for ; Wed, 11 Oct 2000 10:24:25 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA07764; Wed, 11 Oct 2000 10:24:23 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007273; Wed, 11 Oct 00 10:23:51 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9BENn820583 for pilc@grc.nasa.gov env-from ; Wed, 11 Oct 2000 08:23:49 -0600 (MDT) Date: Wed, 11 Oct 2000 08:23:49 -0600 (MDT) From: Vernon Schryver Message-Id: <200010111423.e9BENn820583@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > > > As soon as the link's capacity goes beyond 4x MTU, any link layer > > > retransmission would cause a *spurious* fast retransmit / fast recovery in > > > TCP. That assumes that (1) the following 3 packets do not incur a link > > > layer retransmission and (2) out-of-order delivery is permitted even > > within > > > a flow. > > > > > > For some wireless networks this could become a real pain ... > ... > OK, so my wording was a bit loose. With the "link's capacity" I mean the > number of TCP segments (MSS) that fit into a *link layer RTT*. Given the speed of light and so forth, that must mean that the near end of the link has buffering of at least 4x MSS. The MSS is at least 1500, so 4X is 6 KBytes, and 6 KBytes at 14000 bit/sec is 3.4 seconds. ] From: Reiner Ludwig ] >It is a Bad Thing(tm) for any router to have a queue that is too big. ] ... ] I fully agree but also think that this is already discussed in the "Advice ] for Internet Subnetwork Designers" ID. ] >The solution is fix the routers ] >so that they can tell the bulk transfer hosts to back off, and that is to ] >reduce the queue sizes at the ends of that 56 kbit/sec link from ] >10 seconds * 56 Kbit/sec to about 0.5 seconds * 56 kbit/sec. ] ] If you further restrict this to say that this is the upper limit *per ] flow*, I would fully agree with you again. If each flow gets fair access, then yes. Otherwise, the limit must be shared by all flows. ] The upper limit for the number of bytes allowed for queueing at a link per ] flow before dropping occurs should be "fixed worst-case e2e RTT" x link speed. ] ] You have picked 500 ms for the value of "fixed worst-case RTT". That would ] be fine with me but might be argued ... I wouldn't argue against any reasonable value. 50 ms is too small. 5000 ms (or 3400 ms) is intolerable to essentially everyone. See the 25 year old human factors studies on the upper bounds for responses from timesharing computers. Many people are unhappy with total (not just per-link) RTT's above 300 ms. ] >Just because DRAM is almost free today does not mean that you should use ] >GBytes of it for queuing in wireless base stations. It is important for ] >wires base stations to signal their congestion, and since you will not ] >always have ECN to all hosts, you must drop packets, and that means you ] >must not have too much queing. ] ] I think this is already the message of the "Advice for Internet Subnetwork ] Designers" ID. What is still unclear is a rule-of-thumb for the ] dimensioning of the queueing buffer as discussed above. In that case, what is this about a link having so much buffering that its RTT is 4X MSS? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Oct 12 10:20: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 SMTP id KAA26517 for ; Thu, 12 Oct 2000 10:20:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA00871 for pilc-outgoing; Thu, 12 Oct 2000 09: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 SMTP id JAA00842 for ; Thu, 12 Oct 2000 09:24:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA03759; Thu, 12 Oct 2000 09:24:13 -0400 Received: from rmd250b.roma.alespazio.it(194.20.199.66) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002772; Thu, 12 Oct 00 09:23:24 -0400 Received: from eskycarducci1 ([172.21.5.57] (may be forged)) by rmd250b.roma.alespazio.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA27382 for ; Thu, 12 Oct 2000 15:21:49 +0200 (METDST) Message-ID: <00ca01c0344f$e7247200$390515ac@eskyway> From: "Franco Carducci" To: References: <200010091734.e99HYi004218@calcite.rhyolite.com> Subject: ARQ in the physical layer for satellite links Date: Thu, 12 Oct 2000 15:25:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I suppose the item in subject has been already deeply analysed (pros and cons): someone could point me to those evaluations? Thank you very much Best regards ************************************************************* Franco Carducci Alenia Spazio SpA Via G. V. Bona 85 - 00156 Roma - Italy Phone: + (39) 06 4151 457 Fax: +(39)06 4151 471 E-mail: f.carducci@rmmail.alespazio.it Web: www.alespazio.it ************************************************************* From owner-pilc@lerc.nasa.gov Thu Oct 12 11:03: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 SMTP id LAA28989 for ; Thu, 12 Oct 2000 11:03:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09908 for pilc-outgoing; Thu, 12 Oct 2000 10:16: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 SMTP id KAA09879 for ; Thu, 12 Oct 2000 10:16:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA15487; Thu, 12 Oct 2000 10:16:49 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014766; Thu, 12 Oct 00 10:15:46 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9CEFit19553; Thu, 12 Oct 2000 16:15:44 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-108 [164.48.140.108]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id QAA18523; Thu, 12 Oct 2000 16:15:43 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001012160131.01ec7960@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 12 Oct 2000 16:15:41 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200010111423.e9BENn820583@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 16:23 11.10.00, Vernon Schryver wrote: > > From: Reiner Ludwig > > > > > As soon as the link's capacity goes beyond 4x MTU, any link layer > > > > retransmission would cause a *spurious* fast retransmit / fast > recovery in > > > > TCP. That assumes that (1) the following 3 packets do not incur a link > > > > layer retransmission and (2) out-of-order delivery is permitted even > > > within > > > > a flow. > > > > > > > > For some wireless networks this could become a real pain ... > > > ... > > OK, so my wording was a bit loose. With the "link's capacity" I mean the > > number of TCP segments (MSS) that fit into a *link layer RTT*. > >Given the speed of light and so forth, that must mean that the near end >of the link has buffering of at least 4x MSS. The MSS is at least 1500, >so 4X is 6 KBytes, and 6 KBytes at 14000 bit/sec is 3.4 seconds. Good point. Although I don't agree to the "... must mean that the near end of the link has buffering of at least 4x MSS". It means that the link layer sender can have 4x MSS worth of bytes in flight, i.e., unacked at the link layer. That sender would not need to have any queue at all if it received the next packet from the higher layer (IP) just when it has sent out the (last bit of the) preceding packet/frame. Instead I would say "... the near end of the link should have buffering of at least 4x MSS". The point you raise is that the rule-of-thumb we discussed in the last mail does not work on slow links. Thus, I propose the following modification: The upper limit for the number of bytes allowed for queueing at a link per flow before dropping occurs should be ("fixed worst-case e2e RTT excluding the link layer RTT" + "link layer RTT") x link speed. >] From: Reiner Ludwig > >] >It is a Bad Thing(tm) for any router to have a queue that is too big. > >] ... >] I fully agree but also think that this is already discussed in the "Advice >] for Internet Subnetwork Designers" ID. > >] >The solution is fix the routers >] >so that they can tell the bulk transfer hosts to back off, and that is to >] >reduce the queue sizes at the ends of that 56 kbit/sec link from >] >10 seconds * 56 Kbit/sec to about 0.5 seconds * 56 kbit/sec. >] >] If you further restrict this to say that this is the upper limit *per >] flow*, I would fully agree with you again. > >If each flow gets fair access, then yes. >Otherwise, the limit must be shared by all flows. I agree. In that case, one might need to have some idea of the average number of concurrent flows sharing the link. ///Reiner From owner-pilc@lerc.nasa.gov Thu Oct 12 22:57:10 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 SMTP id WAA14233 for ; Thu, 12 Oct 2000 22:57:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA06324 for pilc-outgoing; Thu, 12 Oct 2000 21:55: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 SMTP id VAA06303 for ; Thu, 12 Oct 2000 21:55:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA05583; Thu, 12 Oct 2000 21:55:35 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005474; Thu, 12 Oct 00 21:55:00 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9CF6H817492 for pilc@grc.nasa.gov env-from ; Thu, 12 Oct 2000 09:06:17 -0600 (MDT) Date: Thu, 12 Oct 2000 09:06:17 -0600 (MDT) From: Vernon Schryver Message-Id: <200010121506.e9CF6H817492@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > > > OK, so my wording was a bit loose. With the "link's capacity" I mean the > > > number of TCP segments (MSS) that fit into a *link layer RTT*. > > > >Given the speed of light and so forth, that must mean that the near end > >of the link has buffering of at least 4x MSS. The MSS is at least 1500, > >so 4X is 6 KBytes, and 6 KBytes at 14000 bit/sec is 3.4 seconds. > > Good point. Although I don't agree to the "... must mean that the near end > of the link has buffering of at least 4x MSS". I did not use the word "must" to mean "required by standards," but to mean "unavoidably implied" by the hypothesis that the link has 4X of RTT of buffering. > It means that the link layer sender can have 4x MSS worth of bytes in > flight, i.e., unacked at the link layer. That sender would not need to have > any queue at all if it received the next packet from the higher layer (IP) > just when it has sent out the (last bit of the) preceding packet/frame. > > Instead I would say "... the near end of the link should have buffering of > at least 4x MSS". You declare "should" while I infer "MUST NOT" (in the RFC sense). > The point you raise is that the rule-of-thumb we discussed in the last mail > does not work on slow links. I strongly disagree. That you don't like the implications is insufficent reason to amend the rule of thumb. The reasons for the rule of thumb are compelling and unavoidable. Any link with frequent (not only typical) delays of 500 milliseconds or more will be considered practically useless by the majority of users. A link that frequently suffers 3 second delays will be completely rejected for any and all interactive applications. It does not matter why the link delay delay is frequently so high; it matters only that essentially all IP applications other than email and possibly instant messaging used by any except an insignificant minority in the 21st Century are too frustrating to use with such delays. Even email, when the words means IMAP or POP, cannot at best barely tolerate 3 second RTT's. On the other hand, if the hand-offs, fade, or whatever else that would cause 3 seconds of delay are infrequent, then there are no reasons to need 4x MSS of buffering and still compelling reasons to not have it. > Thus, I propose the following modification: > > The upper limit for the number of bytes allowed for queueing at a link per > flow before dropping occurs should be > > ("fixed worst-case e2e RTT excluding the link layer RTT" + "link layer RTT") > x link speed. That makes sense only with the familiar wireless-Telco reasoning based on the premises that IP history is irrelevant and that anyone except telco people cares about radio links. Both premises are contrary to fact. 10 or 15 years ago people used TCP/IP over 9600 bit/sec modems with 3-5 seconds of buffering. They hated the results, and so either commonly reduced the buffering or used only non-interactive applications. No user wants to care about any link layer's RTT or other characteristics. Users use TCP/IP for the applications, not to support telcos and telco suppliers. The only RTT that matters to users and applications is the end-to-end RTT. The reasoning says that people will change their behavior and expectations to accomodate whatever a consortium of link layer vendors finds convenient to sell is literally clinically insane, whether used by the WAP forum now or the ATM Forum 10 years ago. If you put too much buffering in any router or other box in the path and so make the path RTT more than about 500 ms, you will do the otherwise impossible and make people care about your link layer's characteristics. Unfortunately, they'll care only about staying away from it. (Yes, the ATM Forum's insanity was more complicated and not as obvious.) Because of government help, it was once true that whatever was good for PTT's was by definition good for their customers. That is no longer true. > >] If you further restrict this to say that this is the upper limit *per > >] flow*, I would fully agree with you again. > > > >If each flow gets fair access, then yes. > >Otherwise, the limit must be shared by all flows. > > I agree. In that case, one might need to have some idea of the average > number of concurrent flows sharing the link. Why? Enough memory for 200-300 ms of buffering for as many flows as can possibly go to a single mobile phone is, if not free, far cheaper than other things. The number of flows that a single mobile phone (or IP host on the far end of a 1985 vintage Telebit Trailblazer using the Packet Ensemble Protocol (?) or PEP) is not infinite. Among its bounds are the reverse bandwidth consumed by TCP ACKs and the serialization delays each flow suffers due to others. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Oct 13 06:22: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 SMTP id GAA01942 for ; Fri, 13 Oct 2000 06:22:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA29333 for pilc-outgoing; Fri, 13 Oct 2000 05:28:19 -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 SMTP id FAA29325 for ; Fri, 13 Oct 2000 05:28:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA08203; Fri, 13 Oct 2000 05:28:17 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008164; Fri, 13 Oct 00 05:28:09 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9D9S4Z10507; Fri, 13 Oct 2000 11:28:04 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (rac174pc.edd.ericsson.se [164.48.123.174]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id LAA15728; Fri, 13 Oct 2000 11:28:00 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001013102256.0252cc50@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 13 Oct 2000 11:26:41 +0200 To: Vernon Schryver From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200010121506.e9CF6H817492@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:06 12.10.00, Vernon Schryver wrote: > > The point you raise is that the rule-of-thumb we discussed in the last > mail > > does not work on slow links. > >I strongly disagree. That's OK. Then we can hopefully continue this productive (and I really mean it) discussion ... >Any link with frequent (not only typical) >delays of 500 milliseconds or more will be considered practically useless >by the majority of users. A link that frequently suffers 3 second delays >will be completely rejected for any and all interactive applications. It >does not matter why the link delay delay is frequently so high; it matters >only that essentially all IP applications other than email and possibly >instant messaging used by any except an insignificant minority in the 21st >Century are too frustrating to use with such delays. Even email, when >the words means IMAP or POP, cannot at best barely tolerate 3 second RTT's. I strongly disagree ... see below ... >10 or 15 years ago people used TCP/IP over 9600 bit/sec modems with 3-5 >seconds of buffering. They hated the results, and so either commonly >reduced the buffering or used only non-interactive applications. So let's stay with that example since 9600 bit/sec (sync. = 1200 bytes/sec) is exactly the ideal (no errors on the link) bit rate you get on state-of-the-art wide area wireless networks: IS95 and GSM. Even if you flame over telco networks so much, if you really need to rely on wide area coverage (beyond nation-wide) then these networks are state-of-the-art. When travelling I (and so do many other people) always and frequently use GSM to download e-mail from our Intranet and if I really need a piece of info I do HTTP. Believe it or not, there are even situations where I have to telnet, and it works OK. I set my MTU to 1500 bytes since I'm mostly doing bulk data stuff and want to get highest throughput (I almost never do telnet and bulk data at the same time ;-). Now, the time it takes to transmit a 1500 bytes segment and the returning 40 bytes ACK over 1200 bytes/sec is about 1300 ms (not counting the PPP framing overhead). Like it or not, but for GSM we need to add another 200 ms latency (propagation delay if you prefer) *one-way* over the GSM hop. We are at an e2e RTT of 1700 ms by now. Adding a worst case Internet RTT of 500 ms which is not unlikely gets us to 2200 ms. Because I want to make sure that the link is always utilized you must allow me to queue at least one packet. Thus, we need to add another 1300 ms for the queueing delay of one single packet. => a sum of 3500 ms. But I don't mind because I really need that e-mail to be downloaded and it's not so bad after all. Even telnet is acceptable if I really need to get something done. As I write this e-mail, I'm dialing in via a landline modem with 28.800 bits/sec which should still be a commonly found link speed. Modems usually have a *one way* latency of 50 ms (depending on the manufacturer you can find much higher numbers!). Doing the same math gets you to a sum of about 1500 ms. Now I mind even less because 28.8 kbit/sec is OK for e-mail, WWW, and telnet. That's why I can't agree with what you wrote above: "delays of 500 milliseconds or more will be considered practically useless" By the way, it's not always the telcos and the modem vendors that are responsible for excessive queueing. Check out the BSD operating system. By default it happily allocates a 50 packet large output buffer for a PPP interface. Given a TCP receiver window of 8 or 16 KBytes, most of those bytes will sit in BSD's output buffer. And then we are talking about RTTs of several seconds! See, e.g., http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html Yes, I know that there are per route metrics that BSD4.4 uses to avoid that. But those metrics are discarded after each PPP session (when the route goes down) so that does not help much. So, you haven't convinced me that the last version of the rule-of-thumb is broken. ///Reiner From owner-pilc@lerc.nasa.gov Fri Oct 13 07:28: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 SMTP id HAA02923 for ; Fri, 13 Oct 2000 07:28:18 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA01894 for pilc-outgoing; Fri, 13 Oct 2000 06:35: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 SMTP id GAA01888 for ; Fri, 13 Oct 2000 06:34:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA21668; Fri, 13 Oct 2000 06:34:58 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021447; Fri, 13 Oct 00 06:34:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02147; Fri, 13 Oct 2000 06:34:17 -0400 (EDT) Message-Id: <200010131034.GAA02147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-error-05.txt Date: Fri, 13 Oct 2000 06:34:16 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : End-to-end Performance Implications of Links with Errors Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya Filename : draft-ietf-pilc-error-05.txt Pages : 20 Date : 12-Oct-00 The rapidly-growing Internet is being accessed by an increasingly wide range of devices over an increasingly wide variety of links. At least some of these links do not provide the reliability that hosts expect, and this expansion into unreliable links causes some Internet protocols, especially TCP [RFC793], to perform poorly. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-error-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-error-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001012120953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-error-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-error-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001012120953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Fri Oct 13 12:53:52 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 SMTP id MAA09198 for ; Fri, 13 Oct 2000 12:53:52 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA13207 for pilc-outgoing; Fri, 13 Oct 2000 11:35: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 SMTP id LAA13164 for ; Fri, 13 Oct 2000 11:35:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA24806; Fri, 13 Oct 2000 11:35:08 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024015; Fri, 13 Oct 00 11:34:11 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9DFY9526099 for pilc@grc.nasa.gov env-from ; Fri, 13 Oct 2000 09:34:09 -0600 (MDT) Date: Fri, 13 Oct 2000 09:34:09 -0600 (MDT) From: Vernon Schryver Message-Id: <200010131534.e9DFY9526099@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Reiner Ludwig > ... > So let's stay with that example since 9600 bit/sec (sync. = 1200 bytes/sec) > is exactly the ideal (no errors on the link) bit rate you get on > state-of-the-art wide area wireless networks: IS95 and GSM. > > Even if you flame over telco networks so much, if you really need to rely > on wide area coverage (beyond nation-wide) then these networks are > state-of-the-art. > > When travelling I (and so do many other people) always and frequently use > GSM to download e-mail from our Intranet and if I really need a piece of > info I do HTTP. Believe it or not, there are even situations where I have > to telnet, and it works OK. > > I set my MTU to 1500 bytes since I'm mostly doing bulk data stuff and want > to get highest throughput (I almost never do telnet and bulk data at the > same time ;-). Now, the time it takes to transmit a 1500 bytes segment and > the returning 40 bytes ACK over 1200 bytes/sec is about 1300 ms (not > counting the PPP framing overhead). Like it or not, but for GSM we need to > add another 200 ms latency (propagation delay if you prefer) *one-way* over > the GSM hop. We are at an e2e RTT of 1700 ms by now. Adding a worst case > Internet RTT of 500 ms which is not unlikely gets us to 2200 ms. Because I > want to make sure that the link is always utilized you must allow me to > queue at least one packet. Thus, we need to add another 1300 ms for the > queueing delay of one single packet. > => a sum of 3500 ms. > > But I don't mind because I really need that e-mail to be downloaded and > it's not so bad after all. Even telnet is acceptable if I really need to > get something done. It does not matter whether you label such fundamentally broken services state of the art, by appointment to the king, or anything else. It is simply impossible to get people to use such services in the ways that make your conclusions valid. Aamong the invalid assumptions are - since X is the best that can by done with Y from industry, consortium or vendor Z, therefore people want and will pay to do X a lot. It is not only the telcos and telco suppliers that use such reasoning, although they perfected it before the computer people arrived. - that other than less than an insignificant number of people will ever use telnet to talk to an HTTP server or even conceive of the possibility. You and I do, but we don't even begin to count. - email over such links to such phones needs 4X MSS of buffering in the routers. How big is the screen on your phone, and how much fun would 99.99% of users have trying to read an SMTP (or POP or IMAP) message that could use 4X MSS? - that people have changed since they rejected 500 ms delays 10-15 years ago and will now embrace them. > As I write this e-mail, I'm dialing in via a landline modem with 28.800 > bits/sec which should still be a commonly found link speed. Modems usually > have a *one way* latency of 50 ms (depending on the manufacturer you can > find much higher numbers!). Doing the same math gets you to a sum of about > 1500 ms. Now I mind even less because 28.8 kbit/sec is OK for e-mail, WWW, > and telnet. Yes, and why don't v.34 modems have 30 KBytes or more of buffering? Why haven't the salescritters that assure us that v.34 modems are really 56 Kbit/sec because we all know that v.42bis gives 4X put another $1 of buffering in their modems? One answer is that 90% of consumers cannot tell the difference between surfing the web at 28-40 kbps with v.34+v.42bis and using a true 56 kbit/sec, but they do notice that any extra buffering hurts a lot. > That's why I can't agree with what you wrote above: "delays of 500 > milliseconds or more will be considered practically useless" Agree or not as you like; for anything except email and by anyone except ubber geeks, it is a fact. We "have been there and done that." Delays of 500 ms or more were found practically useless for interactive applications 10 or 15 years ago by most people. With their home PC's now running at 6 Mbit/sec and less than 20 ms, they will not and cannot care whether a GSM phone with 1700 ms is sold by telcos as state of the art or required by PTT regulations. > By the way, it's not always the telcos and the modem vendors that are > responsible for excessive queueing. Check out the BSD operating system. By > default it happily allocates a 50 packet large output buffer for a PPP > interface. Given a TCP receiver window of 8 or 16 KBytes, most of those > bytes will sit in BSD's output buffer. And then we are talking about RTTs > of several seconds! See, e.g., > http://iceberg.cs.berkeley.edu/papers/Ludwig-Sigmetrics99/index.html You're concluding based on too little data. The commercial PPP code I wrote and caused to be shipped on a system that used the BSD TCP stack to several 10,000 customers didn't do that. Moreover, I caused that commmercial UNIX system to ship with a 30 KByte default TCP window in about 1988 and a 60 K window in about 1993. (That is related to my sad tales of woe concerning Ethernet-FR routers with 50 Kbytes of buffering.) When the company's heavily flogged voice/UDP/IP-multicast application ran over PPP, it configured a PPP queue length of three hundred (300), but a tiny MTU and also marked its packets to allow the three kinds of ToS queuing in the PPP driver to do their things. (1 kind of ToS queuing was the IP TOS byte.) Still more, that particular PPP implementation supported a kind of multilink that causes packets to be re-ordered, which is where I got my prejudices about links that re-order and the results on TCP. > Yes, I know that there are per route metrics that BSD4.4 uses to avoid > that. But those metrics are discarded after each PPP session (when the > route goes down) so that does not help much. The 4.4BSD PPP code is very primitive. Customers forced me to make my PPP code configure routes when links came up. > So, you haven't convinced me that the last version of the rule-of-thumb is > broken. What you, I, the bosses and sales people at telcos and telco suppliers think does not matter. It has been known for 30 years that people start refusing to use interactive computer applications when delays reach 5 seconds. See those ancient studies of timesharing systems. It has also been known for at least 10 years that 500 ms of modem delay on interactive applications is intolerable to the vast majority of users. Look at the history of the Telebit corporation. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Sun Oct 15 17:20: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 SMTP id RAA10562 for ; Sun, 15 Oct 2000 17:20:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA06719 for pilc-outgoing; Sun, 15 Oct 2000 16:10:15 -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 SMTP id QAA06712 for ; Sun, 15 Oct 2000 16:10:14 -0400 (EDT) From: stefan.wiesendanger@epfl.ch Received: by seraph3.lerc.nasa.gov; id QAA08278; Sun, 15 Oct 2000 16:10:14 -0400 Received: from imap.epfl.ch(128.178.50.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008114; Sun, 15 Oct 00 16:09:35 -0400 Received: from imap.epfl.ch (imap.epfl.ch [128.178.50.10]) by imap.epfl.ch (Sun Internet Mail Server sims.4.0.2000.05.17.04.13.p6) with SMTP id <0G2H009A6MNXRN@imap.epfl.ch> for pilc@grc.nasa.gov; Sun, 15 Oct 2000 22:09:33 +0200 (MET DST) Date: Sun, 15 Oct 2000 23:39:33 +0330 (GMT+03:30) Subject: Re: pilc minutes for IETF 48 To: pilc@grc.nasa.gov Message-id: <496992058.971640573502.JavaMail.root@imap.epfl.ch> MIME-version: 1.0 X-Mailer: Sun(TM) Web Access 1.2 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT I'm not taking sides with neither Mr. Schryver nor Mr. Ludwig on the issue of how best to optimize TCP delay performance over wireless links. However, I'd like to point out one thing that Mr. Schryver and many Americans fail to recognize because they may not be witnessing the explosive growth and the convenience of sending short alpha- numeric messages (SMS). The lesson is: many applications needn't be interactive. Of course Mr. Schryver is right and all the research about maximum latency for interactive applications is still valid today: response times > 500 ms will not be accepted by users. But email, to cite one example, is NOT interactive. It's only so when you log on through your home phone line. But a cellular phone is not quite an ordinary phone. It is also a small computer and it's always connected (namely through the cellular control channels). Therefore, the idea is to deliver email directly to the mobile in which case latency is simply not an issue. Taking another example: ordering something doesn't necessarily require an immediate feedback across the network, either. Finally, don't forget that a cellular phone is already equipped for interactive applications when the need arises: just use the voice channel. Now, I'm not a firm believer in voice browsing in light of all the time I've wasted in recorded-voice menu trees, but I do think the user experience could be made much more productive than what is commonplace now. And then there are call centers, of course. With all this, I am not saying you should not minimise delay and I am not saying that interactive applications are not important. All I am saying is that you shouldn't completely dismiss TCP for systems and links where you can't meet the 500ms response time requirement. There may be uses even for that. Stefan Wiesendanger DE-TCOM Swiss Federal Institute of Technology, Lausanne From owner-pilc@lerc.nasa.gov Sun Oct 15 19:35:26 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 SMTP id TAA11238 for ; Sun, 15 Oct 2000 19:35:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11619 for pilc-outgoing; Sun, 15 Oct 2000 18:44: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 SMTP id SAA11605 for ; Sun, 15 Oct 2000 18:44:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA02167; Sun, 15 Oct 2000 18:44:40 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002114; Sun, 15 Oct 00 18:44:29 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9FMiRm23453 for pilc@grc.nasa.gov env-from ; Sun, 15 Oct 2000 16:44:27 -0600 (MDT) Date: Sun, 15 Oct 2000 16:44:27 -0600 (MDT) From: Vernon Schryver Message-Id: <200010152244.e9FMiRm23453@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: stefan.wiesendanger@epfl.ch > ... > However, I'd like to point out one thing that Mr. Schryver and > many Americans fail to recognize because they may not be witnessing > the explosive growth and the convenience of sending short alpha- > numeric messages (SMS). From my prospective, it's not the "explosive growth of short messages," but the "return of short messages." In the old days (staring in the 1960's when I first used email), messages were what you could type in a few seconds on a 10 char/sec model 35 or 33 TTY or 5 char/sec Flexowriter, and did not have zillions of headers (such as X-Face for pity's sake!), not to mention MBytes of spread sheets and pictures, fonts, cryptographic signatures, and complete duplicates of the whole message expanded by 30-100% and encrypted in HTML. Maybe I'm overstating things a little. Informal email (i.e. not to public mailing lists or netnews) was less than 500 but more than 100 bytes. > The lesson is: many applications needn't be > interactive ... I guess I wasn't clear when I tried to say that 4X MSS worth of buffering in radio base stations for short text messages that consist of far less than one MSS is silly. > But email, to cite one example, is NOT interactive. It's only so > when you log on through your home phone line. But a cellular phone is > not quite an ordinary phone. It is also a small computer and it's > always connected (namely through the cellular control channels). > Therefore, the idea is to deliver email directly to the mobile in > which case latency is simply not an issue. Yes, but "email" is not the really the issue either. Do those "state of the art" GSM phones with > 1700 ms of latency also have enough memory to hold enough bits of email to worry about? Do they have even as much as 4X MSS=6KBytes? Are their screens big enough to allow you to read a message longer than 100 bytes? Your message contained 1893 bytes of text. Could you have typed it on a cell phone keypad? Could you have reviewed it for spelling and grammar on a cell phone screen? I couldn't. Thus, whatever phone text messaging is, it's not modern email. There are people with lots of real experience with the ultra-short text messages (50X to 50,000X smaller than 21st Century SMTP) that seem to be what the GSM and third generation phone people are talking about. Instead of using bulk transfer protocols such as TCP/IP, why not look at what the pager people have been doing for decades? > Taking another example: > ordering something doesn't necessarily require an immediate feedback > across the network, either. No, if your order is not instantly acknowledged and you are like most consumers, you will be very unhappy, will complain, and will try to cancel or repeat the order. And never mind how you were able to do the very interactive job of getting enough information to place your order (e.g. bus schedule or take-out restaurant menu) over a 1700 ms RTT link without giving up in frustration. > Finally, don't forget that a cellular phone is already equipped for > interactive applications when the need arises: just use the voice > channel. Now, I'm not a firm believer in voice browsing in light of > all the time I've wasted in recorded-voice menu trees, but I do > think the user experience could be made much more productive than > what is commonplace now. And then there are call centers, of course. That's very true, and it says volumes about the utility and wisdom of worrying about how many MSS of buffer to put in base stations to make HTTP/SMTP/TCP/IP work over links with 1700 ms latency. > With all this, I am not saying you should not minimise delay and I am > not saying that interactive applications are not important. All I am > saying is that you shouldn't completely dismiss TCP for systems and > links where you can't meet the 500ms response time requirement. There > may be uses even for that. As I've repeatedly said, TCP was and even still is used on links with >500 ms latency. It's just that 500 ms doesn't work for interactive applications, and essentially all of the proposed uses of IP-to-GSM uses are interactive, because those "state of the art" phones don't have enough storage to do anything else. Almost all of their storage is in the brain of the user, which is another way of saying the proposed applications are interactive. The possible exception is email, but the keyboard, storage, and screen real estate of phones means that phone-email is something very different from what we are using here. Who would want to read any of the messages in this list on a cell phone's screen? Who could have prepared even a fragment of one on a cell phone? Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Oct 16 12:39: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 SMTP id MAA09615 for ; Mon, 16 Oct 2000 12:39:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA29068 for pilc-outgoing; Mon, 16 Oct 2000 11:31: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 SMTP id LAA29039 for ; Mon, 16 Oct 2000 11:31:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA18019; Mon, 16 Oct 2000 11:31:55 -0400 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017796; Mon, 16 Oct 00 11:31:39 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id e9GFVLw22384; Mon, 16 Oct 2000 16:31:21 +0100 (BST) Message-ID: <39EB1F49.DC60531B@erg.abdn.ac.uk> Date: Mon, 16 Oct 2000 16:31:21 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.73C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Vernon Schryver , pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <200010061532.e96FWqk21100@calcite.rhyolite.com> 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 Vernon Schryver wrote: > > From: Dr G Fairhurst > > > I don't think we differ as much as you may think we do. > > I suspect we differ more than either of us thought. I wrote this to encourage more debate, pleased you responded. > > > > Sorry, this debate is less than clear. I was talking only about WINDOW size, > > in many link ARQ schemes there is a fixed modulus or window which > > limits the maximum number of packets in flight. This may be determined by > > either amount of buffer memory or size of frame number field (before everyone > >shouts and says "but not all" - I know there are exceptions). The HDLC standard > > works this way - and so do nearly all variants of it, I have seen. > > Yes, but if you have a whole window's worth of packets that cannot get > through, then the link is very sick. There's little to talk about besides > radio things like hand-off that should be inivisible to TCP except possibly > for a bunch of lost segments. No, I disagree. Not so sick, for some types of link, just unfortunate: It's not just cellular mobile we are thinking of. > > > If you have one stuck packet that is keeping the window from advancing > and so you cannot get any other data through the link, then either your > window is too small or you have broken hardware or software that cannot > be fixed with ARQ or anything else (i.e. my #3). There is absolutely > nothing that can or should be done in this case except possibly to change > vendors in a forklift upgrade. Window is indeed too small (at least in relation to the problem). A link reset may well fix the problem. If the protocol engines at each end reinitialise (and hopefully log), then you can get them back in sync with no memory issues. > > > > ... > > > Moreover, by Dr. Fairhurst's assumptions, either > > > 1. no other packets for any TCP stream are flowing because the link > > > is very sick. > > > 2. this particular packet will soon get through because the problem > > > was temporary. > > > 3. something is very badly broken in the design or implementation of > > > the link layer, because one particular packet cannot get through > > > but others can. > > > ... > > 1 is what I call an OUTAGE - we have text already which recommends what > > to do (hang on to the last few packets if you can and send them once you > > are able - not quite the same as recommending persistence!) > > > > 2 may happen - but I have seen cases where this can take a long time > > - particularly with a big packet and periodic interference. > > > > 3. This happens too... and can be bizarre. > > > >The non-persistent argument seems to help with 2,3. At least it clears out all > > that > > old link state and any buffers tied up, so that things can resume orderly > > in the > > future. > > No, in those three cases: > 1. there is nothing to do. The link is broken and has been broken for > at least a little while. Saving packets in the hope that the link > might return might be good, but is probably a waste of cycles and > memory, and quite possibly worse. > I'm not convinced the link ARQ platform will always be doing useful work if the link is not moving data - so I'd like to let people think they could use the cycles to do something (if they choose to do so). By "worse", I presume you mean MSL (good point, see below) - are there other bad things I haven't thought of? > > You MUST NOT keep any TCP or UDP packet for longer than the MSL. > You will break things if you somehow keep a packet for a long time > and then eventually regurgitate it. good point. MSL is always to be observed. Incidentally this means that true reliability (with unlimited retransmissions) is not allowed for IP! > 2. this is ordinary bit rot. If you often find problems with big packets > and periodic interference, then you have misdesigned the link layer > packet sizes by making it too big. > Sure, just a badly configured link, or very unfortunate error pattern. Neither are impossible, and can be found in the Internet. > > 3. there is nothing that can be done in this case except to ship all of > the hardware and software back to the factory, and possibly to fire > the poor fellow who messed up the FEC or CRC computation, buffer > chaining, or whatever. > Or do a link reset, possibly drop some frames, and continue. > > > What I'm trying to find out is what we should recommend when we have a > > high (or moderately high) packet loss rate. > > > > If we have only one TCP flow, do we care? > > Probably not, as long the ARQ tries (a few attempts) or forever. The > > latter may > > even be better. Good versions of HDLC could work fine with segmentation. > > > > If we have many flows - are there other issues? > > I can think of these two: > > > > 1) The ability to classify UDP form TCP seems very desirable (although > > difficult with tunnels/encapsulation and fundamentally problematic with IPSEC) > > It's wise to not attempt things that you know are impossible. Given the > fact that IPSec exists, the fact that sooner or later people will get > paranoid about their bits, and the fact that people are already trained > to be paranoid about their voices on radios by analog cellular phone > scanners, it is crazy (as in failing to accept reality) to do anything > but assume IPSec makes classifying impossible. I agree unless the IPSEC user chooses to signal the transport class (by some means) or inhibits IPSEC, then we can not assume an ability to classify the transport protocol. > > > 2) I suggest sharing with other TCP flows can become an issue - perhaps less > > so if you are end-system connected to a mobile net, but more so if you are > > connecting > > a remote LAN with many hosts over a wireless (or any RF) link. Several factors > > here: > > per-flow state, > > head-of-line block when buffer/window exceeded, > > forwarding delay (out of order delivery may be desirable) > > Out of order forwarding is not desirable, but it is always far more > desirable to get the bits through the link than to second guess the upper > layers tolerance to re-ordering. > All IP protocols and applications are absolutely required to tolerate > absolutely all possible re-orderings of IP packets within the MSL. Any > delaying of later packets merely because earlier packets need link layer > retransmitting would be *WRONG*. And again, there is the MSL limit > on how long you can delay (including retransmitting) any packet. MSL - agreed. "desirable" - should be "may prove beneficial in some cases" > > > When your window or buffer is full, what can you do beside hs head-of-line > block and drop incoming packets? Mentioning that as an alternative makes > as much sense as mentioning that when the system melts in a fire, it must > stop working. > Can drop from front or back.... > > Per-flow state might be handy, but why would you not start with the sorts > of things that are already being done or considered for other sorts > of routers? For example, why not do a modified RED? Has anyone done this? > > > Vernon Schryver vjs@rhyolite.com Gorry Fairhurst ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Mon Oct 16 14: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 SMTP id OAA12540 for ; Mon, 16 Oct 2000 14:23:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA17317 for pilc-outgoing; Mon, 16 Oct 2000 13:15: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 SMTP id NAA17280 for ; Mon, 16 Oct 2000 13:15:16 -0400 (EDT) From: mankin@ISI.EDU Received: by seraph3.lerc.nasa.gov; id NAA14595; Mon, 16 Oct 2000 13:15:15 -0400 Received: from east.isi.edu(38.245.76.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013653; Mon, 16 Oct 00 13:14:14 -0400 Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA25653; Mon, 16 Oct 2000 13:14:26 -0400 (EDT) Date: Mon, 16 Oct 00 13:17:49 EDT Posted-Date: Mon, 16 Oct 00 13:17:49 EDT Message-Id: <10010161717.AA07859@maia.east.isi.edu> Received: by maia.east.isi.edu (4.1/4.0.3-6) id ; Mon, 16 Oct 00 13:17:49 EDT To: pilc@grc.nasa.gov Subject: Mark Allman assisting chairs Cc: mankin@ISI.EDU, sob@harvard.edu Sender: owner-pilc@lerc.nasa.gov Precedence: bulk PILC WG, Due to a personal circumstance, Aaron will be offline for some weeks. Spencer and Aaron have asked that Mark Allman be viewed as the co-chair pro-tem during this time. I agree to this and thank Mark in advance for his efforts. Allison From owner-pilc@lerc.nasa.gov Mon Oct 16 20:41:14 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 SMTP id UAA18013 for ; Mon, 16 Oct 2000 20:41:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA05220 for pilc-outgoing; Mon, 16 Oct 2000 19:40: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 SMTP id TAA05201 for ; Mon, 16 Oct 2000 19:39:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA29424; Mon, 16 Oct 2000 19:39:59 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029356; Mon, 16 Oct 00 19:39:09 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19013; Mon, 16 Oct 2000 16:38:59 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id QAA15049; Mon, 16 Oct 2000 16:38:58 -0700 (PDT) Received: from roam (roam.Eng.Sun.COM [129.144.95.192]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9GNcvf909630; Mon, 16 Oct 2000 16:38:57 -0700 (PDT) Date: Mon, 16 Oct 2000 16:38:57 -0700 (PDT) From: Bill Yeager Reply-To: Bill Yeager Subject: Re: pilc minutes for IETF 48 To: Vernon Schryver Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <200010152244.e9FMiRm23453@calcite.rhyolite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk | The possible exception is email, but the keyboard, storage, and screen | real estate of phones means that phone-email is something very different | from what we are using here. Who would want to read any of the messages | in this list on a cell phone's screen? Who could have prepared even a | fragment of one on a cell phone? Exactly the point. Most of those email users who use cell phones will send very short messages to one another. And, when the messages are not short, ie, not sent from a cell phone, then any smart email client using IMAP for example will take advantage of the fetch partial commands and page email messages to telephones in say, 256 byte chunks. The above is not a fantasy. It works quite well even with HTTP proxy to a (shall I dare say) WAP gateway. I did such a product to understand WAP and wireless, and right, it convinced me that WAP MUST converge to the IETF standards on the one hand, but that the email service was quite good on the other hand. The same can be say wrt to calendar access. We are not talking ftp here or even 4xMSS worth of data. I've used HTTP with HandWeb on my Palm Pilot talking to a proxy [http <--> imap/smtp/ldap] using servlets to output compact HTML on the CDPD network here in the bay area. I could hold a WAP enable telephone in the other hand talking to the same proxy that was also WML or HDML enabled. Equal performance because the application was tailored to the device. App designers must be aware of the platform. This same code has been running over GSM networks in Europe. It works well because it was designed with the target device in mind. So, for example, one can provide the phone with a list of pre-defined responses that can be set up on the phone or with a web interface. One finger responses. Make short cuts, take advantage of the smarts in protocols like IMAP for managing low-bandwidth high latency and noisy connections. USE TCP/IP end-2-end!!! That is what moves our industry forward. It is a unifying force. Right, I've been involved in networking since the 60's too. DSN at Nasa-AMES for the pioneer spacecrafts. Kermit was based on my code (ttyftp which I wrote at Stanford in the late 70's) and the cisco routers were initially licensed from Stanford as a derivative of my work, the Sumex-aim etherTip/router code. And remember, real apps will soon be arriving to the phone. Smart apps. They will initially require HTTP/TCP/IP end-2-end and soon after use protocols like IMAP and SMTP. They will be light weight wrt to data use. And, they will use SSL/TLS for security end-2-end. They will tolerate 2 seconds of RTT, and still give a great user experience. THAT is cool, very cool. Finally remember, WAP 2.0 is TCP/IP + basic XHTML + (I'm betting on SSL/TLS when implemented). There will be required legacy support for WML. But, I'm again betting on proxy rather than phone resident WML browers for a great deal of the content. All of the work in pilc has inspired this. Great arguments! Great results. Thanks a lot, Bill From owner-pilc@lerc.nasa.gov Mon Oct 16 22:07:26 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 SMTP id WAA19443 for ; Mon, 16 Oct 2000 22:07:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA10600 for pilc-outgoing; Mon, 16 Oct 2000 21:19:57 -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 SMTP id VAA10590 for ; Mon, 16 Oct 2000 21:19:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA17345; Mon, 16 Oct 2000 21:19:55 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017247; Mon, 16 Oct 00 21:19:25 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9H1JNI19105 for pilc@grc.nasa.gov env-from ; Mon, 16 Oct 2000 19:19:23 -0600 (MDT) Date: Mon, 16 Oct 2000 19:19:23 -0600 (MDT) From: Vernon Schryver Message-Id: <200010170119.e9H1JNI19105@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Bill Yeager > ... > Exactly the point. Most of those email users who use cell phones will send > very short messages to one another. like pages or email before 21st Century SMTP. > ... > We are not talking ftp here or even 4xMSS worth of data. ... No, we clearly are talking aobut FTP sized transfers. If the issue did not involve large streams of data, then the notion of ARQ blocking other packets would make no sense. The issue of re-ordering TCP segments when there are 4 or more outstanding segments (and so 4xMSS=6000 bytes in flight) does not make sense up except for big streams. > ... > And remember, real apps will soon be arriving to the phone. Smart apps. They > will initially require HTTP/TCP/IP end-2-end and soon after use protocols like > IMAP and SMTP. They will be light weight wrt to data use. And, they will use > SSL/TLS for security end-2-end. They will tolerate 2 seconds of RTT, and still > give a great user experience. THAT is cool, very cool. That's not going to happen until phones have reasonable keyboards (or equivalents), displays, and memory (e.g. attachments to PDA's). When that happens, either radio modems will have lower latencies and higher throughputs or those wonderful applications will still not happen. The modern Internet would not exist if it were still based on 56k leased lines connecting IMPs ad TIPs. No matter how cool things seem to us, users do not tolerate the delays implied by several 1700 ms round trips for DNS followed by 3 more round trips to set up an HTTP/TCP/IP session just to get an airline schedule or restaurant menu so they can start to place an order. On the other hand, if those delays and losses go away, much of the PILC proposed improvements to TCP, questions about ARQ below, and so forth become moot. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Tue Oct 17 14:27:30 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 SMTP id OAA18752 for ; Tue, 17 Oct 2000 14:27:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA16573 for pilc-outgoing; Tue, 17 Oct 2000 13:28:36 -0400 (EDT) Received: from guns (guns.lerc.nasa.gov [139.88.87.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA16527; Tue, 17 Oct 2000 13:27:55 -0400 (EDT) Message-Id: <200010171727.NAA16527@lombok-fi.lerc.nasa.gov> To: pilc@grc.nasa.gov Cc: "Spencer Dawkins" , "Aaron Falk" Cc: gab@sun.com, kojo@cs.Helsinki.FI, vincent.magret@aud.alcatel.com, vaidya@cs.tamu.edu From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: WG last call for ERROR Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Pinball Wizard Date: Tue, 17 Oct 2000 13:27:55 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Folks- I'm told that my first task as "co-chair pro tem" is to issue a WG last call on the following document... Title : End-to-end Performance Implications of Links with Errors Author(s) : S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya Filename : draft-ietf-pilc-error-05.txt Pages : 20 Date : 12-Oct-00 http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-05.txt The document has undergone a previous WG last call, but some significant new text has been added (section 1.3) and therefore we'd like to issue another short last call period before forwarding this document to the IESG. Unless hearing otherwise, we will assume there is consensus on this document and that everyone is tired of it on 10/25/2000 and forward it to the IESG for publication as a BCP/Informational(***) RFC. Please take a look at the most recent version and send comments to the authors or the mailing list (positive ACKs ("yep, it looks good") to me or the list would also be appreciated). *** I have lost track of which kind of document ERROR is tracked to be. Can you remind us Spencer? Thanks, allman --- http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Tue Oct 17 15:20:31 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 SMTP id PAA19616 for ; Tue, 17 Oct 2000 15:20:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA25992 for pilc-outgoing; Tue, 17 Oct 2000 14:20: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 SMTP id OAA25918 for ; Tue, 17 Oct 2000 14:20:41 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA17439; Tue, 17 Oct 2000 14:20:38 -0400 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015779; Tue, 17 Oct 00 14:19:06 -0400 Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id OAA03548 for ; Tue, 17 Oct 2000 14:19:05 -0400 (EDT) Message-ID: <39EC9819.1F084952@hns.com> Date: Tue, 17 Oct 2000 14:19:05 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: Re: WG last call for ERROR References: <200010171727.NAA16527@lombok-fi.lerc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit "Yep, it looks good." (I sent a few nit comments to the authors to be addressed before final publication...) John Mark Allman wrote: > > > Folks- > > I'm told that my first task as "co-chair pro tem" is to issue a WG > last call on the following document... > > Title : End-to-end Performance Implications of Links with > Errors > Author(s) : S. Dawkins, G. Montenegro, M. Kojo, > V. Magret, N. Vaidya > Filename : draft-ietf-pilc-error-05.txt > Pages : 20 > Date : 12-Oct-00 > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-05.txt > > The document has undergone a previous WG last call, but some > significant new text has been added (section 1.3) and therefore we'd > like to issue another short last call period before forwarding this > document to the IESG. Unless hearing otherwise, we will assume > there is consensus on this document and that everyone is tired of it > on 10/25/2000 and forward it to the IESG for publication as a > BCP/Informational(***) RFC. Please take a look at the most recent > version and send comments to the authors or the mailing list > (positive ACKs ("yep, it looks good") to me or the list would also > be appreciated). > > *** I have lost track of which kind of document ERROR is tracked to > be. Can you remind us Spencer? > > Thanks, > allman > > --- > http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Tue Oct 17 15:38: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 SMTP id PAA19845 for ; Tue, 17 Oct 2000 15:38:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA29662 for pilc-outgoing; Tue, 17 Oct 2000 14:43: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 SMTP id OAA29621 for ; Tue, 17 Oct 2000 14:42:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA10774; Tue, 17 Oct 2000 14:42:56 -0400 Received: from fortress.fnc.fujitsu.com(204.253.82.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010006; Tue, 17 Oct 00 14:42:26 -0400 Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id NAA08096 for ; Tue, 17 Oct 2000 13:42:15 -0500 (CDT) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Tue, 17 Oct 2000 13:42:16 -0500 Message-ID: From: "Dawkins, Spencer" To: pilc@grc.nasa.gov Subject: RE: WG last call for ERROR Date: Tue, 17 Oct 2000 13:42:08 -0500 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 ERROR, SLOW, and LINK were tracked as BCPs in our previous discussions. Spencer > -----Original Message----- > From: Mark Allman [SMTP:mallman@grc.nasa.gov] > Sent: Tuesday, October 17, 2000 12:28 PM > To: pilc@grc.nasa.gov > Cc: Spencer Dawkins; Aaron Falk; gab@sun.com; kojo@cs.helsinki.fi; vincent.magret@aud.alcatel.com; vaidya@cs.tamu.edu > Subject: WG last call for ERROR > > > Folks- > > I'm told that my first task as "co-chair pro tem" is to issue a WG > last call on the following document... > > Title : End-to-end Performance Implications of Links with > Errors > Author(s) : S. Dawkins, G. Montenegro, M. Kojo, > V. Magret, N. Vaidya > Filename : draft-ietf-pilc-error-05.txt > Pages : 20 > Date : 12-Oct-00 > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-05.txt > > The document has undergone a previous WG last call, but some > significant new text has been added (section 1.3) and therefore we'd > like to issue another short last call period before forwarding this > document to the IESG. Unless hearing otherwise, we will assume > there is consensus on this document and that everyone is tired of it > on 10/25/2000 and forward it to the IESG for publication as a > BCP/Informational(***) RFC. Please take a look at the most recent > version and send comments to the authors or the mailing list > (positive ACKs ("yep, it looks good") to me or the list would also > be appreciated). > > *** I have lost track of which kind of document ERROR is tracked to > be. Can you remind us Spencer? > > Thanks, > allman > > > --- > http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Wed Oct 18 02:05: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 SMTP id CAA12342 for ; Wed, 18 Oct 2000 02:05:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA10647 for pilc-outgoing; Wed, 18 Oct 2000 00:52: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 SMTP id AAA10609 for ; Wed, 18 Oct 2000 00:52:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA00420; Wed, 18 Oct 2000 00:52:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000362; Wed, 18 Oct 00 00:52:34 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9I4qRt27812; Wed, 18 Oct 2000 06:52:27 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (rac182pc.edd.ericsson.se [164.48.123.182]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id GAA25120; Wed, 18 Oct 2000 06:52:25 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001018061114.01da8970@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 18 Oct 2000 06:14:13 +0200 To: gorry@erg.abdn.ac.uk From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 - Persistence Cc: pilc@lerc.nasa.gov In-Reply-To: <39EB1F49.DC60531B@erg.abdn.ac.uk> References: <200010061532.e96FWqk21100@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:31 16.10.00, you wrote: >good point. MSL is always to be observed. Incidentally this means that true >reliability (with unlimited retransmissions) is not allowed for IP! If you check the PILC archive, you will find that I always mentioned the MSL as an upper bound for link layer error recovery persistency. In fact, the maximum RTO of 64 seconds is a more reasonable upper bound. ///Reiner From owner-pilc@lerc.nasa.gov Wed Oct 18 07:07:22 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 SMTP id HAA15456 for ; Wed, 18 Oct 2000 07:07:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA08980 for pilc-outgoing; Wed, 18 Oct 2000 06:04: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 SMTP id GAA08974 for ; Wed, 18 Oct 2000 06:04:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA27958; Wed, 18 Oct 2000 06:04:37 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027719; Wed, 18 Oct 00 06:03:41 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9IA3et19796; Wed, 18 Oct 2000 12:03:40 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (dhcp4-222 [164.48.140.222]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id MAA00119; Wed, 18 Oct 2000 12:03:38 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001018115924.0222cdf0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 18 Oct 2000 12:03:38 +0200 To: gorry@erg.abdn.ac.uk From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 - Persistence Cc: pilc@lerc.nasa.gov In-Reply-To: <39ED6210.8F069984@erg.abdn.ac.uk> References: <200010061532.e96FWqk21100@calcite.rhyolite.com> <5.0.0.25.0.20001018061114.01da8970@chapelle.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 10:40 18.10.00, Dr G Fairhurst wrote: >Yes, but asserting that MSL/TCP RTO should be considered an upper delay bound, >aren't you saying you don't think a fully reliable link ARQ (aka HDLC) is a >good idea? I'm saying (again) that link layer error recovery (aka ARQ) as, e.g., implemented by HDLC, on lossy links or links that suffer transient outages is a great idea, *if* that link also implements flow seperation. The maximum time the link layer sender tries to re-/transmit a single TCP segment should, however, be bound to 64 sec. (TCP's max RTO). >P.S. 64 secs will usually equate to a very large number of >retransmissions...or >a >significant link outage. True. ///Reiner From owner-pilc@lerc.nasa.gov Wed Oct 18 07:23: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 SMTP id HAA15825 for ; Wed, 18 Oct 2000 07:23:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA10676 for pilc-outgoing; Wed, 18 Oct 2000 06:39:09 -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 SMTP id GAA10662 for ; Wed, 18 Oct 2000 06:39:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA09593; Wed, 18 Oct 2000 06:39:06 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009517; Wed, 18 Oct 00 06:39:02 -0400 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13lqcR-0004aA-00; Wed, 18 Oct 2000 11:38:47 +0100 Date: Wed, 18 Oct 2000 11:38:46 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: gorry@erg.abdn.ac.uk, pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence In-Reply-To: <5.0.0.25.0.20001018061114.01da8970@chapelle.ericsson.se> 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 Wed, 18 Oct 2000, Reiner Ludwig wrote: > At 17:31 16.10.00, you wrote: > >good point. MSL is always to be observed. Incidentally this means that true > >reliability (with unlimited retransmissions) is not allowed for IP! > > If you check the PILC archive, you will find that I always mentioned the > MSL as an upper bound for link layer error recovery persistency. In fact, > the maximum RTO of 64 seconds is a more reasonable upper bound. Reasonable for whom? Having an upper bound much more than several times the link delay makes little sense. An upper bound that is a significant fraction or more of the path delay makes little sense. And a telnet session with a lag of 64 seconds is something I can do quite happily without. By increasing persistency you're not increasing link utilisation. You're not helping TCP(-friendly) congestion control algorithms. What are you doing, exactly? L. PGP From owner-pilc@lerc.nasa.gov Wed Oct 18 12:22: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 SMTP id MAA25155 for ; Wed, 18 Oct 2000 12:22:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23499 for pilc-outgoing; Wed, 18 Oct 2000 11:27: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 SMTP id LAA23469 for ; Wed, 18 Oct 2000 11:27:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA29890; Wed, 18 Oct 2000 11:27:18 -0400 Received: from auemail1.lucent.com(192.11.223.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028706; Wed, 18 Oct 00 11:26:20 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA21581 for ; Wed, 18 Oct 2000 11:26:14 -0400 (EDT) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA21552; Wed, 18 Oct 2000 11:26:13 -0400 (EDT) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA26865; Wed, 18 Oct 2000 11:33:07 -0400 Message-ID: <39EDC106.3EB1F3C4@lucent.com> Date: Wed, 18 Oct 2000 11:25:58 -0400 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Zoran Kostic CC: L.Wood@eim.surrey.ac.uk, Reiner Ludwig , gorry@erg.abdn.ac.uk, pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <39EDAD00.FBA6B029@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Zoran, Two questions: A. What is the air link data rate in your case? B. When you say higher persistency, are you also increasing the aggressiveness of the link layer recovery? Meaning, if the 3 round recovery scheme retransmits 1,2 and 3 times then a 5 round one retransmits 1,2,3,4 and 5 times? Zoran Kostic wrote: > > Lloyd, > > This is an example of why and when it makes sense to > have an upper delay more than several times the path delay. > Also, an argument (from yet another individual) in favour > of "higher" persistency. > > In a cellular network with mobile users, you will often find > a user whose performance is just fine most of the time. > Occassionally, it will hit nasty channel conditions, get > stuck for a short amount of time and get out of trouble > after not so long. Well, we do not want to break the > TCP connection while it is stuck, because we know that > it will get out of trouble. And statisctically, this happens often > (in the cellular environment)! > > We've run an extensive set of simulations investigating > interactions between the the cellular environment and TCP. > Indeed, having very persistent lower layer gives the best results > from the performance point of view. Having less than 3 or > 4 retransmissions always screws up things if the channel is > messy or if the system is highly loaded (many users per cell), > and infinite persistency gets decently mimicked by > something on the order of 5-10 retransmission on the RLP > layer. > > So, as an answer to your question > "What are you doing, exactly?", I offer the following: > In the cellular environment, with large number of users, > cumulative distribution functions expressing system throughput > and delay show significant improvements if the persistency on > the lower layers is high. So, we are doing a great deal here ! > > Yes, we want persistency. It is not clear that we need to have > infinite persistency or always as high as 64 seconds, but having > only 3 retransmission (as in IS99) is suboptimal. > I actually think that variable persistency (as a function of > cellular channel conditions) may make sense. > > Zoran From owner-pilc@lerc.nasa.gov Wed Oct 18 12:38: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 SMTP id MAA27514 for ; Wed, 18 Oct 2000 12:38:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA07240 for pilc-outgoing; Wed, 18 Oct 2000 10:01: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 SMTP id KAA07188 for ; Wed, 18 Oct 2000 10:01:45 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA03484; Wed, 18 Oct 2000 10:01:43 -0400 Received: from h-135-207-30-103.research.att.com(135.207.30.103) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002482; Wed, 18 Oct 00 10:00:43 -0400 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id 1FF781E009; Wed, 18 Oct 2000 10:00:39 -0400 (EDT) Received: from research.att.com (pckostic [135.207.130.59]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id KAA20511; Wed, 18 Oct 2000 10:00:36 -0400 (EDT) Message-ID: <39EDAD00.FBA6B029@research.att.com> Date: Wed, 18 Oct 2000 10:00:32 -0400 From: Zoran Kostic X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk Cc: Reiner Ludwig , gorry@erg.abdn.ac.uk, pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Lloyd, This is an example of why and when it makes sense to have an upper delay more than several times the path delay. Also, an argument (from yet another individual) in favour of "higher" persistency. In a cellular network with mobile users, you will often find a user whose performance is just fine most of the time. Occassionally, it will hit nasty channel conditions, get stuck for a short amount of time and get out of trouble after not so long. Well, we do not want to break the TCP connection while it is stuck, because we know that it will get out of trouble. And statisctically, this happens often (in the cellular environment)! We've run an extensive set of simulations investigating interactions between the the cellular environment and TCP. Indeed, having very persistent lower layer gives the best results from the performance point of view. Having less than 3 or 4 retransmissions always screws up things if the channel is messy or if the system is highly loaded (many users per cell), and infinite persistency gets decently mimicked by something on the order of 5-10 retransmission on the RLP layer. So, as an answer to your question "What are you doing, exactly?", I offer the following: In the cellular environment, with large number of users, cumulative distribution functions expressing system throughput and delay show significant improvements if the persistency on the lower layers is high. So, we are doing a great deal here ! Yes, we want persistency. It is not clear that we need to have infinite persistency or always as high as 64 seconds, but having only 3 retransmission (as in IS99) is suboptimal. I actually think that variable persistency (as a function of cellular channel conditions) may make sense. Zoran Lloyd Wood wrote: > On Wed, 18 Oct 2000, Reiner Ludwig wrote: > > > At 17:31 16.10.00, you wrote: > > >good point. MSL is always to be observed. Incidentally this means that true > > >reliability (with unlimited retransmissions) is not allowed for IP! > > > > If you check the PILC archive, you will find that I always mentioned the > > MSL as an upper bound for link layer error recovery persistency. In fact, > > the maximum RTO of 64 seconds is a more reasonable upper bound. > > Reasonable for whom? > > Having an upper bound much more than several times the link delay > makes little sense. An upper bound that is a significant fraction or > more of the path delay makes little sense. And a telnet session with a > lag of 64 seconds is something I can do quite happily without. > > By increasing persistency you're not increasing link > utilisation. You're not helping TCP(-friendly) congestion control > algorithms. What are you doing, exactly? > > L. > > PGP From owner-pilc@lerc.nasa.gov Wed Oct 18 13:52:40 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 SMTP id NAA07218 for ; Wed, 18 Oct 2000 13:52:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA04348 for pilc-outgoing; Wed, 18 Oct 2000 12:41: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 SMTP id MAA04297 for ; Wed, 18 Oct 2000 12:41:31 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA29772; Wed, 18 Oct 2000 12:41:30 -0400 Received: from unknown(202.139.83.23) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029016; Wed, 18 Oct 00 12:40:48 -0400 Received: from nacsvr09.nac.cwo.net.au ([172.25.4.24]) by NACSVR05.nac.cwo.net.au with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Oct 2000 03:40:37 +1100 content-class: urn:content-classes:message Subject: RE: WG last call for ERROR MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 19 Oct 2000 03:40:38 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: Thread-Topic: WG last call for ERROR Thread-Index: AcA4djJ/QK4SC4Y5QR+l1am8bw/1qwAtAxXA From: "Matthew King" To: X-OriginalArrivalTime: 18 Oct 2000 16:40:37.0741 (UTC) FILETIME=[24EAC1D0:01C03922] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id MAA04321 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi. > The document has undergone a previous WG last call, but some > significant new text has been added (section 1.3) and therefore we'd > like to issue another short last call period before forwarding this > document to the IESG. Unless hearing otherwise, we will assume > there is consensus on this document and that everyone is tired of it > on 10/25/2000 and forward it to the IESG for publication as a > BCP/Informational(***) RFC. Please take a look at the most recent > version and send comments to the authors or the mailing list > (positive ACKs ("yep, it looks good") to me or the list would also > be appreciated). Positive ACK. Cya Matthew Matthew King. IP Network Engineer, Cable & Wireless Optus. From owner-pilc@lerc.nasa.gov Wed Oct 18 15:50: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 SMTP id PAA23025 for ; Wed, 18 Oct 2000 15:50:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA23299 for pilc-outgoing; Wed, 18 Oct 2000 14:42: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 SMTP id OAA23265 for ; Wed, 18 Oct 2000 14:42:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA08278; Wed, 18 Oct 2000 14:42:50 -0400 Received: from h-135-207-30-103.research.att.com(135.207.30.103) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007929; Wed, 18 Oct 00 14:42:42 -0400 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-green.research.att.com (Postfix) with ESMTP id D77021E004; Wed, 18 Oct 2000 14:42:33 -0400 (EDT) Received: from research.att.com (pckostic [135.207.130.59]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id OAA29273; Wed, 18 Oct 2000 14:42:33 -0400 (EDT) Message-ID: <39EDEF13.F8C6EEE5@research.att.com> Date: Wed, 18 Oct 2000 14:42:27 -0400 From: Zoran Kostic X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kamesh Medepalli , pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <39EDAD00.FBA6B029@research.att.com> <39EDC106.3EB1F3C4@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Kamesh, * The airlink is the one used in EDGE - thereby there is variability of the rate between roughly 9 and 59 kbps. * The way I think of persistency on the link is the following: Attempt to transmit the block no more than X times. So, I do not have the concept of rounds, just plain number of transmission attempts. On this layer I also use the mode 0 option, whereby if the channel or interference are really bad, I do not even try to retransmit. Zoran Kamesh Medepalli wrote: > Zoran, > > Two questions: > > A. What is the air link data rate in your case? > > B. When you say higher persistency, are you also increasing the aggressiveness > of the link layer recovery? Meaning, if the 3 round recovery scheme > retransmits 1,2 and 3 times then a 5 round one retransmits 1,2,3,4 and 5 times? > > Zoran Kostic wrote: > > > > Lloyd, > > > > This is an example of why and when it makes sense to > > have an upper delay more than several times the path delay. > > Also, an argument (from yet another individual) in favour > > of "higher" persistency. > > > > In a cellular network with mobile users, you will often find > > a user whose performance is just fine most of the time. > > Occassionally, it will hit nasty channel conditions, get > > stuck for a short amount of time and get out of trouble > > after not so long. Well, we do not want to break the > > TCP connection while it is stuck, because we know that > > it will get out of trouble. And statisctically, this happens often > > (in the cellular environment)! > > > > We've run an extensive set of simulations investigating > > interactions between the the cellular environment and TCP. > > Indeed, having very persistent lower layer gives the best results > > from the performance point of view. Having less than 3 or > > 4 retransmissions always screws up things if the channel is > > messy or if the system is highly loaded (many users per cell), > > and infinite persistency gets decently mimicked by > > something on the order of 5-10 retransmission on the RLP > > layer. > > > > So, as an answer to your question > > "What are you doing, exactly?", I offer the following: > > In the cellular environment, with large number of users, > > cumulative distribution functions expressing system throughput > > and delay show significant improvements if the persistency on > > the lower layers is high. So, we are doing a great deal here ! > > > > Yes, we want persistency. It is not clear that we need to have > > infinite persistency or always as high as 64 seconds, but having > > only 3 retransmission (as in IS99) is suboptimal. > > I actually think that variable persistency (as a function of > > cellular channel conditions) may make sense. > > > > Zoran From owner-pilc@lerc.nasa.gov Wed Oct 18 16:19: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 SMTP id QAA26475 for ; Wed, 18 Oct 2000 16:19:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA29561 for pilc-outgoing; Wed, 18 Oct 2000 15:18: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 SMTP id PAA29538 for ; Wed, 18 Oct 2000 15:18:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA12796; Wed, 18 Oct 2000 15:18:38 -0400 Received: from auemail1.lucent.com(192.11.223.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012636; Wed, 18 Oct 00 15:18:33 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA02629 for ; Wed, 18 Oct 2000 15:18:32 -0400 (EDT) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA02607; Wed, 18 Oct 2000 15:18:31 -0400 (EDT) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA11223; Wed, 18 Oct 2000 15:25:25 -0400 Message-ID: <39EDF778.32D977A@lucent.com> Date: Wed, 18 Oct 2000 15:18:16 -0400 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Zoran Kostic CC: pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <39EDAD00.FBA6B029@research.att.com> <39EDC106.3EB1F3C4@lucent.com> <39EDEF13.F8C6EEE5@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Zoran, The reason I asked those questions is for this: 1. It could be possible that for the TCP window size, MSS, RTT and error rate, the max throughput that TCP can achieve is greater than 59Kb/s. In that case, you *can* get away by spending more time at the link layer. This is because there is some room in the latency before TCP "feels" it. 2. If that is not the case, then it is good that the *extra* latency in recovering errored data has indeed paid off. However, there clearly needs to be a limit on the latency you are adding. TCP may just time out too. 3. Regarding the ARQ scheme itself, clearly the residual error decreases with increased retransmissions. Given a fixed number of retransmission, say 5, you could choose to retransmit, for e.g. in two ways: a. For every NAK the receiver sends retransmit and keep doing it for 5 NAKs. If after 5 attempts you still can't recover data, then you leave it to TCP for recovery. b. The other option could be once you receive a NAK, send the retrans. twice and if you still receive another NAK, send the retransmission 3 times. If you still can't recover, then leave it up to TCP for recovery. The performance of these schemes depends on the TCP window size, RTT, MSS, and ofcourse physical channel [correlated errors or uncorrelated errors]. It is interesting how these many parameters come together to give a sensible result in the end! We have summarized these results in our VTC-2000 Spring paper. Infact, as a result of these findings we left the recovery scheme at link layer [for CDMA-2000] up to the vendors and the telco operators. We did, however, provide a default scheme in the RLP [Radio Link Protocol] standard. Kamesh Zoran Kostic wrote: > > Kamesh, > > * The airlink is the one used in EDGE - thereby there is variability > of the rate between roughly 9 and 59 kbps. > > * The way I think of persistency on the link is the following: Attempt > to transmit the block no more than X times. So, I do not have the > concept of rounds, just plain number of transmission attempts. > > On this layer I also use the mode 0 option, whereby if the channel > or interference are really bad, I do not even try to retransmit. > > Zoran > > Kamesh Medepalli wrote: > > > Zoran, > > > > Two questions: > > > > A. What is the air link data rate in your case? > > > > B. When you say higher persistency, are you also increasing the aggressiveness > > of the link layer recovery? Meaning, if the 3 round recovery scheme > > retransmits 1,2 and 3 times then a 5 round one retransmits 1,2,3,4 and 5 times? > > From owner-pilc@lerc.nasa.gov Thu Oct 19 01:24:30 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 SMTP id BAA08517 for ; Thu, 19 Oct 2000 01:24:29 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA15161 for pilc-outgoing; Thu, 19 Oct 2000 00:37: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 SMTP id AAA15144 for ; Thu, 19 Oct 2000 00:37:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA22574; Thu, 19 Oct 2000 00:37:48 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022516; Thu, 19 Oct 00 00:37:28 -0400 Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9J4bQt29780; Thu, 19 Oct 2000 06:37:26 +0200 (MEST) Received: from e00d059101eba.Ericsson.com (rac175pc.edd.ericsson.se [164.48.123.175]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id GAA08972; Thu, 19 Oct 2000 06:37:19 +0200 (MET DST) Message-Id: <5.0.0.25.0.20001019061558.00a1c8e0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 19 Oct 2000 06:22:08 +0200 To: Zoran Kostic From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 - Persistence Cc: pilc@lerc.nasa.gov In-Reply-To: <39EDEF13.F8C6EEE5@research.att.com> References: <39EDAD00.FBA6B029@research.att.com> <39EDC106.3EB1F3C4@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 20:42 18.10.00, Zoran Kostic wrote: > * The way I think of persistency on the link is the following: Attempt > to transmit the block no more than X times. So, I do not have the > concept of rounds, just plain number of transmission attempts. Since (wireless) links have so different properties (frame size, link speed, latency, LL-RTT, ....), I suggest to speak of LL-ARQ persistency in terms of max. delay an IP packet may incur due to LL-ARQ before it is dropped. Usually, it's straight forward to translate from "transmit the block no more than X times" to the mentioned delay. IMO, that will make it much easier to talk about these things without requiring detailed knowledge of the link in question. ///Reiner From owner-pilc@lerc.nasa.gov Thu Oct 19 10:05:22 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 SMTP id KAA01447 for ; Thu, 19 Oct 2000 10:05:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA16750 for pilc-outgoing; Thu, 19 Oct 2000 08:50:12 -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 SMTP id IAA16734 for ; Thu, 19 Oct 2000 08:50:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id IAA26336; Thu, 19 Oct 2000 08:50:09 -0400 Received: from hoemail1.lucent.com(192.11.226.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026246; Thu, 19 Oct 00 08:50:06 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA23112 for ; Thu, 19 Oct 2000 08:50:06 -0400 (EDT) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id IAA23099; Thu, 19 Oct 2000 08:50:05 -0400 (EDT) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA07362; Thu, 19 Oct 2000 08:57:01 -0400 Message-ID: <39EEEDE9.AAF163@lucent.com> Date: Thu, 19 Oct 2000 08:49:45 -0400 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig CC: pilc@lerc.nasa.gov Subject: Re: pilc minutes for IETF 48 - Persistence References: <39EDAD00.FBA6B029@research.att.com> <39EDC106.3EB1F3C4@lucent.com> <5.0.0.25.0.20001019061558.00a1c8e0@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Usually, it's straight forward to translate from "transmit the block no > more than X times" to the mentioned delay. > > IMO, that will make it much easier to talk about these things without > requiring detailed knowledge of the link in question. > > ///Reiner I agree. I was just making a simple comment that within the latency bound there are different optimal speeds for different network level and wireless link level scenarios. Kamesh From owner-pilc@lerc.nasa.gov Fri Oct 20 15:37: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 SMTP id PAA05073 for ; Fri, 20 Oct 2000 15:37:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA14940 for pilc-outgoing; Fri, 20 Oct 2000 13:28: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 SMTP id NAA14928 for ; Fri, 20 Oct 2000 13:28:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA05616; Fri, 20 Oct 2000 13:28:52 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004833; Fri, 20 Oct 00 13:28:08 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21362; Fri, 20 Oct 2000 10:27:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA15664; Fri, 20 Oct 2000 10:27:35 -0700 (PDT) Received: from roam (roam.Eng.Sun.COM [129.144.95.192]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9KHRYf613073; Fri, 20 Oct 2000 10:27:34 -0700 (PDT) Date: Fri, 20 Oct 2000 10:27:34 -0700 (PDT) From: Bill Yeager Reply-To: Bill Yeager Subject: Re: pilc minutes for IETF 48 To: Vernon Schryver Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <200010170119.e9H1JNI19105@calcite.rhyolite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lombok-fi.lerc.nasa.gov id NAA14929 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id NAA14940 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05073 Hi, I don't want this conversation thread to distract from the TCP/IP thread which is really what pilc is about. I'll note the following, and if you like, we can continue offline: | That's not going to happen until phones have reasonable keyboards (or | equivalents), displays, and memory (e.g. attachments to PDA's). When | that happens, either radio modems will have lower latencies and higher | throughputs or those wonderful applications will still not happen. | The modern Internet would not exist if it were still based on 56k leased | lines connecting IMPs ad TIPs. There are phones with color and detachable keyboards much like a PDA. I-mode has them. I too recal IMPs and TIPs having been at Stanford U. from 1974 until 1994. I am quite sure we can do a lot with even 9600 baud packet switched networks. GPRS promises much more, and if we get 30-50kbps that is fine for mobile phones. As I said, applications will be different, and data demands also. Yes, there are plans with 3G to connect laptops into these networks and do ftp. That is where pilc comes in. 3G (WCDMA) is planned for next year in Japan. And, hey, lots of those wonderful Apps are already happening. They do not depend on holding down the repeat key in a telnet session. Right, I had to optimize that once to in my TIP code. Interactive games are a natural. Email is easy. I've done that. Etc ... | No matter how cool things seem to us, users do not tolerate the delays | implied by several 1700 ms round trips for DNS followed by 3 more round | trips to set up an HTTP/TCP/IP session just to get an airline schedule or | restaurant menu so they can start to place an order. Interesting. The experience on the AT&T Cellular-I CDPD network in the bay area was not that bad(9600 baud was what was managed). DNS + HTTP/TCP/IP took about 3 to 5 seconds on the average to set up. The connect was very quick. There was good user feed back. I would lay in bed at night, turn on my palm and read my email using HandWeb, with a servlet proxy, output presentation in compact HTML, manage the session between me and the email backend (IMAP, LDAP, SMTP). It was simple to use. Not much of a boot time, etc ... That was almost two years ago. Smart apps can manage latency when the net data being transferred is small(3 or 4 segments). So, like many of the arguments on this list we agree to disagree. For apps this is in the spirit of let's see what really happens! I see lots of promise and very, very soon. My hard fought battles in the trenches made me an optimist "malgré tout!" More offline --- Bill From owner-pilc@lerc.nasa.gov Fri Oct 20 15:56: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 SMTP id PAA08726 for ; Fri, 20 Oct 2000 15:56:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA22878 for pilc-outgoing; Fri, 20 Oct 2000 14:25: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 SMTP id OAA22846 for ; Fri, 20 Oct 2000 14:25:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA29561; Fri, 20 Oct 2000 14:25:27 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028757; Fri, 20 Oct 00 14:24:37 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9KIOap15783 for pilc@grc.nasa.gov env-from ; Fri, 20 Oct 2000 12:24:36 -0600 (MDT) Date: Fri, 20 Oct 2000 12:24:36 -0600 (MDT) From: Vernon Schryver Message-Id: <200010201824.e9KIOap15783@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Bill Yeager > ... > | No matter how cool things seem to us, users do not tolerate the delays > | implied by several 1700 ms round trips for DNS followed by 3 more round > | trips to set up an HTTP/TCP/IP session just to get an airline schedule or > | restaurant menu so they can start to place an order. > > Interesting. The experience on the AT&T Cellular-I CDPD network in the bay > area was not that bad(9600 baud was what was managed). DNS + HTTP/TCP/IP took > about 3 to 5 seconds on the average to set up. The connect was very quick. > There was good user feed back. I would lay in bed at night, turn on my palm > and read my email using HandWeb, with a servlet proxy, output presentation in > compact HTML, manage the session between me and the email backend (IMAP, LDAP, > SMTP). It was simple to use. Not much of a boot time, etc ... That was almost > two years ago. 1700 ms was not my number. I am not claiming that any wireless systems have 1700 ms round trip delays, since I have no clue about such things except what whose who know tell me. I'm only reasoning from the stated premises of others who say "X is required because Y," where Y is consistently extremely long latency and very high error rates. My fundamental point is that people can't have it both ways: 1. (a) because radio links have 1700 ms delays and 30% packet loss rates (b) things must be done to and below TCP, such as 60 seconds of ARQ. (I think 30% loss rates were given by wireless experts in previous episodes of this discussion. ~60 sec ARQ was recently mentioned.) 2. the same links as in #1 will be used by 1,000,000,000's of happy end users of very interactive Internet applications that involve lots of data realsoonnow, notwithstanding the implications of 1700 ms delays. (1,000,000,000 is also not my number, but appeared in one of the earliest episodes.) If you choose the premise #1(a), then you rule out the conclusions of #2. If you believe in the conclusions of #2, then you cannot believe in the premises of #1(a) or you believe they'll become invalid too soon to justify doing the things repeatedly advocated in this mailing list. If you don't believe in #1(b), then you can't advocate #1(b). It is possible to be sane and support #1(a) and #1(b), provided you give up #2. ARQ that retries for 64 seconds (again not my number) makes good sense for some applications, although not for the applications that have been advocated. For example, a PDA with a mere 100 KByte could use such a link to fetch email while the user is not paying attention, and later, again in the background, send email responses. In other words, such a link can be used just as similar Telebit Trailblazers modem links were used in the 1980s, and as far as users could tell, it would be as on-line and interactive as talking to their ISP. Unfortunately, there is too much telephant thinking in the wireless world for such insights. We are stuck with repetitions of #1 and #2, no matter how crazy that seems. Telcos and telco supplliers cannot admit the possibility of smart customer premise equipment today any more than they could during the Carterphone case 30+ years ago. There is no hope of the wireless telcos admitting that a telephone might be more than a very dumb terminal. Just as the repeated Ericson complaints and proposals of a few years ago to disable PPP authentication were based on the belief that it is impossible for CPE to compute anything in less than large parts of minutes, the so called state of the art 3G phone is assumed to be little smarter than a Western Electric 500C. > Smart apps can manage latency when the net data being transferred is small(3 > or 4 segments). Yes, but applications that involve merely 3 or 4 TCP segments have nothing to do with the issues at hand. Again, if applications that put 4 or fewer segments in flight at a time were relevant, then questions of ARQ for one packet stalling packets or triggering TCP fast retransmissions would never have come up. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Fri Oct 20 15:56:27 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 SMTP id PAA08767 for ; Fri, 20 Oct 2000 15:56:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA26231 for pilc-outgoing; Fri, 20 Oct 2000 14:46:29 -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 SMTP id OAA26173 for ; Fri, 20 Oct 2000 14:46:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA21332; Fri, 20 Oct 2000 14:46:24 -0400 Received: from mercury.sun.com(192.9.25.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020714; Fri, 20 Oct 00 14:45:37 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28719; Fri, 20 Oct 2000 11:45:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id LAA09521; Fri, 20 Oct 2000 11:45:26 -0700 (PDT) Received: from roam (roam.Eng.Sun.COM [129.144.95.192]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9KIjPf630628; Fri, 20 Oct 2000 11:45:26 -0700 (PDT) Date: Fri, 20 Oct 2000 11:45:25 -0700 (PDT) From: Bill Yeager Reply-To: Bill Yeager Subject: Re: pilc minutes for IETF 48 To: Vernon Schryver Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <200010201824.e9KIOap15783@calcite.rhyolite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi Vernon, I think we agree 100% about the underlying TCP issues. I do some work on this link layer stuff too from time-to-time too. Do look at this URL. It tells you what is happening in the App world. I do believe that the phone viewed as a dumb text terminal is dead or very quickly dying. We are back in 1983 just before the Mac hit the markets and killed off the desktop terminal business. The big companies that did not listen are no longer in the business. Change is in the air. It's super stuff: http://www.washingtonpost.com/wp-dyn/articles/A28462-2000Oct17.html Bill From owner-pilc@lerc.nasa.gov Fri Oct 20 16:39:40 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 SMTP id QAA19244 for ; Fri, 20 Oct 2000 16:39:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA00872 for pilc-outgoing; Fri, 20 Oct 2000 15:16:48 -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 SMTP id PAA00807 for ; Fri, 20 Oct 2000 15:16:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA09050; Fri, 20 Oct 2000 15:16:42 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009003; Fri, 20 Oct 00 15:16:21 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id e9KJGKk16912 for pilc@grc.nasa.gov env-from ; Fri, 20 Oct 2000 13:16:20 -0600 (MDT) Date: Fri, 20 Oct 2000 13:16:20 -0600 (MDT) From: Vernon Schryver Message-Id: <200010201916.e9KJGKk16912@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Bill Yeager > I think we agree 100% about the underlying TCP issues. Probably. More than that, I think the telco people have come around, except that they're unwilling to let go of the premise that wireless phones will be the solid state equivalents of WE 500C's but will still be usable for all of the applications of a PC or PDA. > I do some work on this > link layer stuff too from time-to-time too. > > Do look at this URL. It tells you what is happening in the App world. I do > believe that the phone viewed as a dumb text terminal is dead or very quickly > dying. We are back in 1983 just before the Mac hit the markets and killed off > the desktop terminal business. The big companies that did not listen are no > longer in the business. I don't think it's a coincidence that the Telebit Trailblazers appeared about the same time. The revolutionary idea of the TB was not the fancy modem protocol, but putting a real computer and vast amounts (for that era) of memory into a dial-up modem. Modern "state of the art" wireless telephones are equivalent to the 3270 emulators for PC's that were so popular in the same era. Many people still believed that 3270 still had a future, or that the future of PC's had something to do with SDLC connections to glass houses where all of the real computing would be done, controlled, monitored, billed, etc. > Change is in the air. It's super stuff: > > http://www.washingtonpost.com/wp-dyn/articles/A28462-2000Oct17.html Yep. Except that the notion of video phones is just as lame now as it was 25 years ago when AT&T demonstrated them. The reason video phones are still not used, after nearly 10 years of cheap or free (i.e. bundled) good, working products, is that people don't like video calls most of the time. When humans aren't close enough to smell each other, they prefer the greater privacy and safety of yelling from a safe distance. (see recent literature about what happens to chimpanzees that get too close to the wrong troop and aren't big enough to keep from being eaten) In other words, the people I work with really don't want to see me for the first several hours of the day before I'm dressed, and vice versa. See also recent talk about the usefulness of the MBONE to IETF meetings. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Mon Oct 23 13:38:04 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19213 for ; Mon, 23 Oct 2000 13:38:04 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA17040 for pilc-outgoing; Mon, 23 Oct 2000 12:30:14 -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 SMTP id MAA16997 for ; Mon, 23 Oct 2000 12:30:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA19601; Mon, 23 Oct 2000 12:30:10 -0400 Received: from hermes.cti.gr(150.140.7.30) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019503; Mon, 23 Oct 00 12:29:38 -0400 Received: (qmail 22637 invoked by uid 60015); 23 Oct 2000 16:27:41 -0000 Received: from nikole@cti.gr by hermes with scan4virus-0.50 (. Clean. Processed in 0.048275 secs); 23/10/2000 19:27:41 Received: from pc4822.cti.gr (HELO pc4822) (150.140.5.22) by hermes.cti.gr with SMTP; 23 Oct 2000 16:27:41 -0000 Reply-To: From: "Sotiris Nikoletseas" To: Subject: Deadline approaching -- IPDPS Workshop on Mobile Computing Date: Mon, 23 Oct 2000 19:31:24 +0300 Message-ID: <002c01c03d0e$af7fd200$16058c96@cti.gr> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Please accept my apologies if you receive multiple copies of this message. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ PRELIMINARY CALL FOR PAPERS 1st International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2001 WORKSHOPS Hyatt Regency San Francisco April 23-27, 2001 URLs: http://www.ipdps.org http://www.computing.edu.au/~kumar/ipdpswpim.html ++++++++++++++++++++++++++++++++++++++++++++++++ General Chair Sajal K. Das, The University of Texas at Arlington, USA Program Co-Chairs Mohan Kumar, Curtin University of Technology, Perth, Australia and The University of Texas at Arlington, USA Paul Spirakis, Computer Technology Institute, Patras, Greece ********************************************************* Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece ********************************************************* IMPORTANT DATES: October 30, 2000 Workshop Paper Due December 10, 2000 Notification of Acceptance/Rejection January 15, 2001 Camera-Ready Paper Due Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Routing in adhoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed Wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc. may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. **************************************************************************** *************** Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cs.curtin.edu.au or spirakis@cti.gr. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or Paul Spirakis. All manuscripts will be reviewed. Manuscripts must be received by October 30, 2000. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be mailed by December 10, 2000. Camera-ready papers are due January 15, 2001. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar School of Computer Science Curtin University of Technology GPO Box U 1987, Perth WA 1987 AUSTRALIA Fax: +61 8 9266 2819 E-mail: kumar@cs.curtin.edu.au Paul Spirakis Director and Senior Researcher Computer Technology Institute 61 Riga Fereou Str., 26221 Patras, Greece Patras, Greece Fax: +30 61 993 973, +30 61 222086 E-mail: spirakis@cti.gr ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee Somprakash Bandopadhyay, PWC Global, Calcutta, India Stefano Basagni, University of Texas at Dallas, USA Maurizio Bonuccelli University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kwan-Wu Chin, Motorola Australia Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA Xiaohua Jia, City University of Hong Kong Jan van Leeuwen University of Utrecht, The Netherlands John Lui, The Chinese University of Hong Kong Marios Mavronicolas, University of Cyprus, Cyprus Sotiris Nikoletseas, Computer Technology Institute, Greece Cristina Pinnotti, Italian National Research Council Don Sannella University of Edinburgh, Scotland Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Jie Wu, Florida Atlantic University, USA Yongbing Zhang University of Tsukuba, Japan Albert Zomaya University of Western Australia, Perth Australia ---------------------------------------------------------------------------- -------------------- From owner-pilc@lerc.nasa.gov Tue Oct 24 07:12:24 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17699 for ; Tue, 24 Oct 2000 07:12:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA06402 for pilc-outgoing; Tue, 24 Oct 2000 06:11: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 SMTP id GAA06393 for ; Tue, 24 Oct 2000 06:11:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id GAA14770; Tue, 24 Oct 2000 06:11:00 -0400 Received: from odin.ietf.org(132.151.1.176) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014678; Tue, 24 Oct 00 06:10:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02007; Tue, 24 Oct 2000 06:10:43 -0400 (EDT) Message-Id: <200010241010.GAA02007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: pilc@grc.nasa.gov From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pilc-pep-04.txt Date: Tue, 24 Oct 2000 06:10:42 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Performance Implications of Link Characteristics Working Group of the IETF. Title : Performance Enhancing Proxies Author(s) : J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby Filename : draft-ietf-pilc-pep-04.txt Pages : 45 Date : 23-Oct-00 This document provides a high level overview of Performance Enhancing Proxies. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. In addition, motivations for their development and use are described along with some the consequences of using them, especially in the context of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pilc-pep-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pilc-pep-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001023112419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pilc-pep-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pilc-pep-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001023112419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-pilc@lerc.nasa.gov Thu Oct 26 18:42:19 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02433 for ; Thu, 26 Oct 2000 18:42:19 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA19343 for pilc-outgoing; Thu, 26 Oct 2000 17:40: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 SMTP id RAA19284 for ; Thu, 26 Oct 2000 17:40:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA25627; Thu, 26 Oct 2000 17:40:11 -0400 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025519; Thu, 26 Oct 00 17:39:36 -0400 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id OAA09140; Thu, 26 Oct 2000 14:39:33 -0700 (PDT) Date: Thu, 26 Oct 2000 14:39:32 -0700 (PDT) From: Alhussein Abouzeid To: pilc@grc.nasa.gov cc: roy@ee.washington.edu Subject: TCP over lossy links In-Reply-To: <5.0.0.25.2.20001021155034.01c9e240@mail.reed.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi, Enclosed is an abstract of a paper (submitted to ToN, Jan. 2000) re analytical modeling of TCP performance in the presence of wireless links, i.e. random, correlated-loss environments. This is an extension to our Infocom 2000 paper (available at URL below) that attempts to faithfully capture the interplay between TCP's congestion control algorithm, the channel induced loss behavior and the dynamics of the transmit queue. The primary contribution of the work is modeling the impact of all the following on TCP performance: 1. The two modes of packet loss detection: triple duplicates as well as timeouts and the binary exponential backoff; 2. The variation of the RTT due to queuing; 3. The two congestion avoidance phases of TCP; 4. Channel induced i.i.d and/or correlated loss in addition to possible packet loss due to buffer overflow. The papers can be downloaded at http://students.washington.edu/abouzeid/research.htm As usual, all comments are greatly appreciated. Best regards, Alhussein A. Abouzeid. --------------------------------- A Unified Approach to Modeling TCP Performance Over a Lossy Link Alhussein A. Abouzeid, Sumit Roy and Murat Azizoglu Dept. of Electrical Engineering Univ. of Washington Box 352500 Seattle, WA 98195 Abstract: A new, comprehensive analytical framework for modeling the long-term performance of a single TCP session in the presence of random packet loss is presented. A Markovian model is developed for both memoryless channels (independent, identically distributed packet loss) and channels with memory (correlated packet loss) modeled by a two state continuous time Gilbert-Elliott model. The analytical results (throughput) are validated against those obtained from ns simulator and shows very good agreement for a wide range of network parameters - i.e., low (LANs) and high (WANs) bandwidth-delay products. Further, the throughput for the i.i.d. loss model is found to be relatively insensitive to the probability density function (p.d.f) of the loss inter-arrival process. For channels with memory, an empirical rule is presented for categorizing the impact of channel dynamics (fading rate) on TCP performance. From owner-pilc@lerc.nasa.gov Mon Oct 30 14:27:26 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 SMTP id OAA20975 for ; Mon, 30 Oct 2000 14:27:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13654 for pilc-outgoing; Mon, 30 Oct 2000 12:57:27 -0500 (EST) 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 SMTP id MAA13585 for ; Mon, 30 Oct 2000 12:57:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA09726; Mon, 30 Oct 2000 12:57:19 -0500 Received: from mail2.nc3a.nato.int(192.41.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009597; Mon, 30 Oct 00 12:57:00 -0500 Received: by ttpm.mail2.nc3a.nato.int id <43010>; Mon, 30 Oct 2000 20:03:58 +0200 Message-Id: <00Oct30.200358gmt+0200.43010@ttpm.mail2.nc3a.nato.int> From: Segura Ramon To: "'pilc@grc.nasa.gov'" Subject: ACK decimation using WFQ MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Oct 2000 20:03:56 +0200 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hello, Just a few lines in the context of asymmetric networking and forward throughput limitation caused by ACK congestion. I would like to share a recent experience on using router standard mechanisms for boosting the forward throughput beyond the limit established by the available return channel rate. It's basically a simple "ACK decimation" technique which, although not being optimum, has proven to increase significantly the forward throughput for "disadvantaged" receive nodes that use very narrowband and long-latency satellite links to support the return channel (at 2400 bps or 4800 bps). Using IP/DVB-S on the satellite forward path, the RTT when using those return channels can be a high as 1500 ms (Inmarsat Mini-M terminal) and 3000 ms (UHF DAMA satcom radios). The client and server platforms under test support large windows, Fast Retransmit / Fast Recovery with Selective Acknowledgement (SACK), extended time stamps, and the 4-segment start-up, as provided by the OnNet Kernel 4.0 (for Win95/98) and by Windows 2000 TCP/IP stacks. The target bulk transfer throughput on the forward channel is 2 Mbps. To cope with the ACK congestion limitation imposed by the narrowband & long delay return path, we take advantage of the cumulative property of the TCP ACK's and decimate the return ACK flow by tail-dropping them at the router serial interface. For that we use cisco's weighted-fair-queuing (WFQ), which also ensures fairness among the multiple return ACK streams The longer the ACK queue (i.e. the higher the programmed WFQ drop threshold), the more noticeable is the effect of TCP forward flow self-clocking/slaving to the ACK return rate. By setting the WFQ drop threshold to 1, we get one ACK transmitted out of every K (K-1 packets being dropped off the queue). In our case, the return channel (2400 bps) can only serve four to five ACK packets per second (each being 66 bytes long). As expected, the traffic is bursty during the throughput build-up (i.e. slow-start), but goes and remains steady when the pipe gets full, or when the generic traffic-shaping limit for that flow has been reached. Under this configuration, throughputs of 1 Mbps and higher can be achieved and maintained during FTP or HTTP downloads (@2400 bps return rate, 1500 ms RTT). Without ACK decimation, the return channel rate would limit the throughput to less than 100 kbps (assuming delayed ACK's as implemented by Winsock). Since WFQ creates a queue for each "conversation" or TCP connection, multiple FTP or HTTP sessions can be established concurrently. Each object request will go into a different queue, and its ACKs will be "tail-dropped" independently (and 'fairly'). Despite of the ACK's being severely dropped on an existing connection, the SYN segments for establishing new connections will still make it thru additional queues, with little additional delay ('ping' shows an increase of some 100-200 ms compared to an idle channel). Moreover, the return channel can also be used to upload data on to the server from the remote client (e.g. FTP), at very low speeds, without disturbing the downstream-related ACK flow (in that case, the ACK decimation rate obviously increases). When introducing errors on the forward channel, we could see SACK behaving quite well, despite the decimation of the return ACKs (and SACK) at the upstream router interface. Under this ACK-dropping condition, more (than 3) DUP ACK's or SACK need to be transmitted by the client to get the threshold number into the server. Hope this trick may be of help, ramon ---------------------------------------------------------------------- Ramon Segura NATO Consultation, Command and Control Agency, NC3A Communications Systems Division, SATCOM Branch The Hague, Netherlands e-mail: ramon.segura@nc3a.nato.int Tel. + 31 (0)70 314 2432 / 2448 (Lab) Fax.+ 31 (0)70 314 2176 ---------------------------------------------------------------------- From owner-pilc@lerc.nasa.gov Mon Oct 30 19:00:10 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 SMTP id TAA25840 for ; Mon, 30 Oct 2000 19:00:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA02997 for pilc-outgoing; Mon, 30 Oct 2000 17:57:27 -0500 (EST) 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 SMTP id RAA02934 for ; Mon, 30 Oct 2000 17:57:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA21759; Mon, 30 Oct 2000 17:57:24 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021706; Mon, 30 Oct 00 17:56:40 -0500 Received: from erg.abdn.ac.uk (blueberry-mac.erg.abdn.ac.uk [139.133.207.9]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id e9UMuUi22676; Mon, 30 Oct 2000 22:56:31 GMT Message-ID: <39FDFC9F.DA389A1@erg.abdn.ac.uk> Date: Mon, 30 Oct 2000 22:56:52 +0000 From: Mahesh Sooriyabandara Organization: University of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Segura Ramon CC: "'pilc@grc.nasa.gov'" Subject: Re: ACK decimation using WFQ References: <00Oct30.200358gmt+0200.43010@ttpm.mail2.nc3a.nato.int> 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 Hi Ramon, Segura Ramon wrote: > Hello, > > Just a few lines in the context of asymmetric networking and forward > throughput limitation caused by ACK congestion. I would like to share a > recent experience on using router standard mechanisms for boosting the > forward throughput beyond the limit established by the available return > channel rate. It's basically a simple "ACK decimation" technique which, > although not being optimum, has proven to increase significantly the forward > throughput for "disadvantaged" receive nodes that use very narrowband and > long-latency satellite links to support the return channel (at 2400 bps or > 4800 bps). Using IP/DVB-S on the satellite forward path, the RTT when using > those return channels can be a high as 1500 ms (Inmarsat Mini-M terminal) > and 3000 ms (UHF DAMA satcom radios). The client and server platforms under > test support large windows, Fast Retransmit / Fast Recovery with Selective > Acknowledgement (SACK), extended time stamps, and the 4-segment start-up, as > provided by the OnNet Kernel 4.0 (for Win95/98) and by Windows 2000 TCP/IP > stacks. The target bulk transfer throughput on the forward channel is 2 > Mbps. This sounds quite interesting. We have been doing some work on asymmetric networks for quite a sometime. Although it seems not like the "optimum" solution (as you have mentioned) the technique you are proposing seems to be quite different from other available techniques. To me it looks like a straight forward in the sense that it uses off the shelf equipment with some parameter tuning. No need of any sort of end system modifications. I agree with the fact that this networking technology in your case ( which is again new to apply these technique) can be benefited by a proper ACK modification scheme. Although you claim from your experiments that this method works well. I think we have to raise few questions here. See below..... > To cope with the ACK congestion limitation imposed by the narrowband & long > delay return path, we take advantage of the cumulative property of the TCP > ACK's and decimate the return ACK flow by tail-dropping them at the router > serial interface. For that we use cisco's weighted-fair-queuing (WFQ), which > also ensures fairness among the multiple return ACK streams The longer the > ACK queue (i.e. the higher the programmed WFQ drop threshold), the more > noticeable is the effect of TCP forward flow self-clocking/slaving to the > ACK return rate. By setting the WFQ drop threshold to 1, we get one ACK > transmitted out of every K (K-1 packets being dropped off the queue). In our > case, the return channel (2400 bps) can only serve four to five ACK packets > per second (each being 66 bytes long). As expected, the traffic is bursty > during the throughput build-up (i.e. slow-start), but goes and remains > steady when the pipe gets full, or when the generic traffic-shaping limit > for that flow has been reached. Under this configuration, throughputs of 1 > Mbps and higher can be achieved and maintained during FTP or HTTP downloads > (@2400 bps return rate, 1500 ms RTT). Without ACK decimation, the return > channel rate would limit the throughput to less than 100 kbps (assuming > delayed ACK's as implemented by Winsock). > Although use of Fair Queuing scheme in the return path is a nice way to ensure fair queuing ( Some earlier and we have also shown that in our experiments) "drop from tail" ( not the best way ?) while having a small threshold can leads to some problems (drop of data packets flow in the return path). As a solution indeed a larger queue will be required and that can lead to reduce the forward throughput. > > Since WFQ creates a queue for each "conversation" or TCP connection, > multiple FTP or HTTP sessions can be established concurrently. Each object > request will go into a different queue, and its ACKs will be "tail-dropped" > independently (and 'fairly'). Despite of the ACK's being severely dropped on > an existing connection, the SYN segments for establishing new connections > will still make it thru additional queues, with little additional delay > ('ping' shows an increase of some 100-200 ms compared to an idle channel). Yes I believe because of the per-flow queuing probability of loosing SYN can be very low. > > Moreover, the return channel can also be used to upload data on to the > server from the remote client (e.g. FTP), at very low speeds, without > disturbing the downstream-related ACK flow (in that case, the ACK decimation > rate obviously increases). When introducing errors on the forward channel, > we could see SACK behaving quite well, despite the decimation of the return > ACKs (and SACK) at the upstream router interface. Under this ACK-dropping > condition, more (than 3) DUP ACK's or SACK need to be transmitted by the > client to get the threshold number into the server. Even in our experiments we saw that in the presence of losses large number of DUP ACKs flow in the return path can lead a time out( after FR ). Dropping DUP ACKs larger than a threshold ( to allow fast retransmission) is necessary to avoid that ( Some have shown this earlier and we have seen it as well). I think I agree with your your results with SACK as well. Recent experiments we did have shown that in a lossy path back to back SACKs can lead to a time out same as the back to back DUP acks in TCP with out SACK. So we do see the need of dropping SACK to gain any significant benefit by using it. We are trying to model this by using a suitable threshold. It will be interesting to see the effects with SACK deletion. Any body with some experience on this. I like to hear .... Regards, Mahesh. > > > Hope this trick may be of help, > > ramon > > ---------------------------------------------------------------------- > Ramon Segura > NATO Consultation, Command and Control Agency, NC3A > Communications Systems Division, SATCOM Branch > The Hague, Netherlands > > e-mail: ramon.segura@nc3a.nato.int > Tel. + 31 (0)70 314 2432 / 2448 (Lab) > Fax.+ 31 (0)70 314 2176 > ---------------------------------------------------------------------- From owner-pilc@lerc.nasa.gov Mon Oct 30 19:21: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 SMTP id TAA01568 for ; Mon, 30 Oct 2000 19:21:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA05485 for pilc-outgoing; Mon, 30 Oct 2000 18:25:59 -0500 (EST) 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 SMTP id SAA05453 for ; Mon, 30 Oct 2000 18:25:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA24898; Mon, 30 Oct 2000 18:25:55 -0500 Received: from fortress.fnc.fujitsu.com(204.253.82.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024852; Mon, 30 Oct 00 18:25:37 -0500 Received: from rchsemx2.fnc.fujitsu.com (rchsemx2.fnc.fujitsu.com [167.254.105.13]) by fortress.fnc.fujitsu.com (8.8.7/FNC/ITG-2.0.1) with ESMTP id RAA27534 for ; Mon, 30 Oct 2000 17:25:29 -0600 (CST) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 17:25:32 -0600 Message-ID: From: "Dawkins, Spencer" To: "'PILC Mailing List'" Subject: PEP version 04 now available for WG Last Call Date: Mon, 30 Oct 2000 17:25:29 -0600 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 Version 04 of the Performance Enhancing Proxies Internet-Draft is now available at http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-04.txt. The full document details are: Title : Performance Enhancing Proxies Author(s) : J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby Filename : draft-ietf-pilc-pep-04.txt Pages : 45 Date : 23-Oct-00 This draft is a PILC work item, and is slotted as an Informational RFC. It has not been through a previous working group last call. We would like to hold a two-week working group last-call on this document, ending on Tuesday, November 14. Please review this document as appropriate, and send questions or comments to the PILC mailing list. "Yes, it's done" is also an acceptable - in fact, welcome - comment. Spencer, for Spencer, Mark, and Aaron From owner-pilc@lerc.nasa.gov Tue Oct 31 09:38: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 SMTP id JAA10787 for ; Tue, 31 Oct 2000 09:38:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA07454 for pilc-outgoing; Tue, 31 Oct 2000 08:36:29 -0500 (EST) 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 SMTP id IAA07430 for ; Tue, 31 Oct 2000 08:36:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA16657; Tue, 31 Oct 2000 08:36:26 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016599; Tue, 31 Oct 00 08:35:49 -0500 Received: from erg.abdn.ac.uk (blueberry-mac.erg.abdn.ac.uk [139.133.207.9]) by erg.abdn.ac.uk (8.11.1/8.11.1) with ESMTP id e9VDZ1i27589; Tue, 31 Oct 2000 13:35:02 GMT Message-ID: <39FECA86.E78C2D2A@erg.abdn.ac.uk> Date: Tue, 31 Oct 2000 13:35:52 +0000 From: Mahesh Sooriyabandara Organization: University of Aberdeen X-Mailer: Mozilla 4.7 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Hari Balakrishnan CC: "'PILC Mailing List'" Subject: Asymmetry draft ? 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 e9VDZ1i27589 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id IAA07440 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id IAA07454 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10787 Dear Hari, I was following the PILC mailing list for quite a sometime and wonder what is going to happen to asymmetry draft. Last thread on this topic showed that there are lot of disagreements to the draft. For the same reason I believe that it needs to be revised rather than let it disappear. It will be nice to have a document describing the Asymmetry problem and solutions/(best practices) since there are some disadvantage networks which can be benefited from it. The draft should address all ( as much as possible) different asymmetric networks and different techniques. The former draft may lack this generality. To achieve this contributions from everybody dealing with different asymmetric networks will be needed. There are some commercial products out there which uses some mitigation techniques to improve TCP performance. We have done series of experiments on this topic and I have seen quite a lot of techniques ( mainly ACK modification) proposed by various researchers. Generally each technique is addressing a certain type of networking technology. FYI following is a list of techniques I have seen so far: 1) TCP Header Compression [a] 2) ACK filtering/ Sender Adaptation [b] 3) ACK Congestion Control [b] 4) ACK compaction [c] 5) ACK Companding/ Expanding [d] 6) Window Prediction Mechanism [e] 7) Acknowledgement based on Cwnd Estimation [f] 8) ACK decimation [h] [a] Jacobson, V. ,Compressing TCP/IP Headers for Low Speed Serial Lines, RFC 1144,1990, IETF. [b] Balakrishnan H, Padmanathan V.N. Katz R. "The effects of asymmetry on TCP performance" Mobicom Budapest Hungary 1997, ACM/IEEE. [c] Nihal Samaraweera "Return Link optimization for Internet service provision using DVB-S networks ACM CCR June 1999. [d] Johansson G.L , Shakargi, H. Kanljung, C. Kullander, J. ‘ACKNOWLEDGEMENT Compression Rev B’, Technical Report December 1999. [e] A Calveras, Linare, J. Paradells, J. “Window Prediction Mechanism For Improving TCP in Wireless Asymmetric Links”, Globecom 98. [f] Ming-Chit, I.T, Jinsong, D. Wang, W. “Improving TCP Performance Over Asymmetric Networks” ACM Communication Computer Review, July 2000. [g] R. Segura “ Asymmetric Networking Techniques For Hybrid Satellite Communications” NC3A, Technical Note 810. August 2000. Above techniques have been analysed ( or can be used) in different asymmetric networking technologies. (like Cable networks , packet radio, ADSL, DVB-S with return dial-up, Wireless cable modem with dial up return, DVB satellite forward with narrowband Inmarsat return) It is obvious that lot of work has been done in this area during past few years. This may be a correct time to start discussing this to make use of them and get things correct with the Asymmetry draft. I believe there are lot of researchers who are willing to put their input in to this. Regards, Mahesh.