From owner-pilc@lerc.nasa.gov Mon Sep 4 11:13:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04520 for ; Mon, 4 Sep 2000 11:13:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA07893 for pilc-outgoing; Mon, 4 Sep 2000 10:06: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 KAA07881 for ; Mon, 4 Sep 2000 10:06:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA16325; Mon, 4 Sep 2000 10:06:13 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016294; Mon, 4 Sep 00 10:05:27 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0/8.11.0) with ESMTP id e84E5Fc26718 for ; Mon, 4 Sep 2000 15:05:17 +0100 (BST) Message-ID: <39B3AC1C.8E3DD3A4@erg.abdn.ac.uk> Date: Mon, 04 Sep 2000 15:05:10 +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: "'pilc@grc.nasa.gov'" Subject: Re: Reminder: WG last call for ERROR References: <4.3.2.7.0.20000831235740.00b56c80@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 11:58 31.08.00 -0400, Falk, Aaron wrote: > >Working group last call is coming to an end for ERROR. Spencer will be > >following up with a summary of comments/changes for the draft before we > >submit it to the IESG. > ... > Some comments: > > - Page 7 / 1st para: > "... constantly closing 'trained' TCP connections ... . This is true even > with HTTP1.1 ..." > I don't understand this last sentence. HTTP1.1 is *not* constantly closing > 'trained' TCP connections. It might do so after some idle time (RTO) > though. Is that was it meant? I took the phrase "This is true even with HTTP1.1 in spite of its support for persistent connections." to mean that persistence is part of 1.1, but is not often (as yet) widely used. However, the above comments perhaps suggest another possible interpretation is that the window information should be aged when the session becomes idle and that therefore a pause in the application transfer, causes the available window to reduce. I think both are valid - perhaps it should be clarified? Gorry P.S. Page 6 sect 2.1, - During Slow Start Note that a small MTU is not of benefit to a less-reliable link, unless Path-MTU discovery is used. If it is not, the smaller MTU will result in IP fragmentation - increasing the data being sent, and does not decrease the unit of retransmission - hence it reduces throughput. With PMTU it helps. (Transparent fragmentation by the link layer is an all together better mechanism if link ARQ is used.) Page 10 sect 4.0, - para 3. Appropriate byte counting is just one option to reduce burstiness caused by missing ACK packets - there are others! e.g. ACK rate control within the network, TCP transmit pacing at the sender. ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Mon Sep 4 11: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 ESMTP id LAA04561 for ; Mon, 4 Sep 2000 11:22:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09066 for pilc-outgoing; Mon, 4 Sep 2000 10:37: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 KAA09062 for ; Mon, 4 Sep 2000 10:37:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA18205; Mon, 4 Sep 2000 10:37:16 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018197; Mon, 4 Sep 00 10:37:08 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13VxMq-0003Tj-00; Mon, 04 Sep 2000 15:37:00 +0100 Date: Mon, 4 Sep 2000 15:36:56 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: "'pilc@grc.nasa.gov'" Subject: Re: Reminder: WG last call for ERROR In-Reply-To: <39B3AC1C.8E3DD3A4@erg.abdn.ac.uk> 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 Mon, 4 Sep 2000, Dr G Fairhurst wrote: > P.S. > Page 6 sect 2.1, - During Slow Start > > Note that a small MTU is not of benefit to a less-reliable link, ^link > unless Path-MTU discovery is used. If it is not, the smaller MTU ^link > will result in IP fragmentation - increasing the data being sent, and > does not decrease the unit of retransmission - hence it reduces > throughput. With PMTU it helps. (Transparent fragmentation > by the link layer is an all together better mechanism if link ARQ is used.) I think 'link MTU' needs to be explicitly mentioned here for clarity; the first time I read Gorry's paragraph I did a double take, saying 'no, it's a _larger_ (path) MTU that leads to IP fragmentation!' L. that and IPSec encapsulation, whose added header tends to break the assumptions in MTU implementations. PGP From owner-pilc@lerc.nasa.gov Mon Sep 4 12:04:12 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04890 for ; Mon, 4 Sep 2000 12:04:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA10608 for pilc-outgoing; Mon, 4 Sep 2000 11:22: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 LAA10596 for ; Mon, 4 Sep 2000 11:22:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA21229; Mon, 4 Sep 2000 11:22:17 -0400 Received: from neo.it.comsat.com(134.133.200.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021214; Mon, 4 Sep 00 11:22:05 -0400 Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84FGpw29637; Mon, 4 Sep 2000 11:16:51 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84FGjo29633; Mon, 4 Sep 2000 11:16:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA07893 for pilc-outgoing; Mon, 4 Sep 2000 10:06: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 KAA07881 for ; Mon, 4 Sep 2000 10:06:14 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA16325; Mon, 4 Sep 2000 10:06:13 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016294; Mon, 4 Sep 00 10:05:27 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0/8.11.0) with ESMTP id e84E5Fc26718 for ; Mon, 4 Sep 2000 15:05:17 +0100 (BST) Message-ID: <39B3AC1C.8E3DD3A4@erg.abdn.ac.uk> Date: Mon, 04 Sep 2000 15:05:10 +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: "'pilc@grc.nasa.gov'" Subject: Re: Reminder: WG last call for ERROR References: <4.3.2.7.0.20000831235740.00b56c80@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Reiner Ludwig wrote: > At 11:58 31.08.00 -0400, Falk, Aaron wrote: > >Working group last call is coming to an end for ERROR. Spencer will be > >following up with a summary of comments/changes for the draft before we > >submit it to the IESG. > ... > Some comments: > > - Page 7 / 1st para: > "... constantly closing 'trained' TCP connections ... . This is true even > with HTTP1.1 ..." > I don't understand this last sentence. HTTP1.1 is *not* constantly closing > 'trained' TCP connections. It might do so after some idle time (RTO) > though. Is that was it meant? I took the phrase "This is true even with HTTP1.1 in spite of its support for persistent connections." to mean that persistence is part of 1.1, but is not often (as yet) widely used. However, the above comments perhaps suggest another possible interpretation is that the window information should be aged when the session becomes idle and that therefore a pause in the application transfer, causes the available window to reduce. I think both are valid - perhaps it should be clarified? Gorry P.S. Page 6 sect 2.1, - During Slow Start Note that a small MTU is not of benefit to a less-reliable link, unless Path-MTU discovery is used. If it is not, the smaller MTU will result in IP fragmentation - increasing the data being sent, and does not decrease the unit of retransmission - hence it reduces throughput. With PMTU it helps. (Transparent fragmentation by the link layer is an all together better mechanism if link ARQ is used.) Page 10 sect 4.0, - para 3. Appropriate byte counting is just one option to reduce burstiness caused by missing ACK packets - there are others! e.g. ACK rate control within the network, TCP transmit pacing at the sender. ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Mon Sep 4 12:09:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04970 for ; Mon, 4 Sep 2000 12:09:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA10955 for pilc-outgoing; Mon, 4 Sep 2000 11:29: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 LAA10944 for ; Mon, 4 Sep 2000 11:29:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA21602; Mon, 4 Sep 2000 11:29:17 -0400 Received: from neo.it.comsat.com(134.133.200.200) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021567; Mon, 4 Sep 00 11:28:22 -0400 Received: (from smadmin@localhost) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) id e84FMl829651; Mon, 4 Sep 2000 11:22:47 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by neo.it.comsat.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84FMjo29647; Mon, 4 Sep 2000 11:22:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09066 for pilc-outgoing; Mon, 4 Sep 2000 10:37: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 KAA09062 for ; Mon, 4 Sep 2000 10:37:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA18205; Mon, 4 Sep 2000 10:37:16 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018197; Mon, 4 Sep 00 10:37:08 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13VxMq-0003Tj-00; Mon, 04 Sep 2000 15:37:00 +0100 Date: Mon, 4 Sep 2000 15:36:56 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: "'pilc@grc.nasa.gov'" Subject: Re: Reminder: WG last call for ERROR In-Reply-To: <39B3AC1C.8E3DD3A4@erg.abdn.ac.uk> 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 X-Mail-Filter: omnivore ver 1.0.0 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk On Mon, 4 Sep 2000, Dr G Fairhurst wrote: > P.S. > Page 6 sect 2.1, - During Slow Start > > Note that a small MTU is not of benefit to a less-reliable link, ^link > unless Path-MTU discovery is used. If it is not, the smaller MTU ^link > will result in IP fragmentation - increasing the data being sent, and > does not decrease the unit of retransmission - hence it reduces > throughput. With PMTU it helps. (Transparent fragmentation > by the link layer is an all together better mechanism if link ARQ is used.) I think 'link MTU' needs to be explicitly mentioned here for clarity; the first time I read Gorry's paragraph I did a double take, saying 'no, it's a _larger_ (path) MTU that leads to IP fragmentation!' L. that and IPSec encapsulation, whose added header tends to break the assumptions in MTU implementations. PGP From owner-pilc@lerc.nasa.gov Tue Sep 5 11:22:13 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04752 for ; Tue, 5 Sep 2000 11:22:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA25391 for pilc-outgoing; Tue, 5 Sep 2000 10:14: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 KAA25329 for ; Tue, 5 Sep 2000 10:14:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA01956; Tue, 5 Sep 2000 10:14:03 -0400 Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001447; Tue, 5 Sep 00 10:13:33 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA06871 for ; Tue, 5 Sep 2000 07:13:32 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA04515 for ; Tue, 5 Sep 2000 07:13:31 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA13947 for ; Tue, 5 Sep 2000 10:13:30 -0400 (EDT) Message-Id: <200009051413.KAA13947@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: pilc@grc.nasa.gov Subject: QoS replacement text for Links draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Sep 2000 10:13:30 -0400 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Per my assignment from Pittsburgh, here is a first pass at QoS text. It might stand a bit more polishing, but it's probably time to see what the rest of the group has to say about it. Dan Existing text: Quality of Service, Fairness vs Performance, Congestion signalling The IP header includes a 1-byte TOS (type of service) field. This field is broken into two parts: a 3-bit precedence field that indicates the relative importance of this packet compared to others, and a 4-bit "qualitative tradeoff" field to indicate if low delay, high throughput, high reliability or low cost is qualitatively more important for this particular packet. One TOS bit is reserved. Although the TOS field has not been heavily used in the past, it is becoming increasingly important to the provision of Quality of Service (QoS) features necessary for services such as Voice over IP (VoIP). Many subnetwork designers are faced with inherent tradeoffs between delay, throughput, reliability and cost. When this is the case, the subnetwork should provide an interface to IP that allows the IP TOS bits to control these tradeoffs on a per-packet basis. For example, when a subnetwork implements a hop-by-hop retransmission scheme to improve reliability, this invariably comes at the cost of increased delay variance. An IP packet presented to this subnetwork with the "low delay" bit set in its TOS field should disable hop-by-hop retransmission within the subnetwork for that particular packet. Another example is link forward error correction, which can increase reliability at the expense of throughput without significantly affecting delay. ---------------------- New text Quality-of-Service (QoS) Considerations QoS is best understood in terms of a layered communications architecture. It is most broadly defined as that set of parameters and attributes concerning an instance of communication that a service provider offers a service user, from the perspective of the service user. In this context: .in +5 -- a "service provider" (in lower case) is not the same thing as a "network operator" or ISP. Rather, it is the entities (or concatenation of entities) at a layer, combined with the services which support them, which offer service to an entity (the service user) at the next higher layer. -- Parameters are objectives for values of attributes which are offered (e.g., during connection/flow establishment or as installed by policy management) to the service users by the service provider. -- Attributes are actual values of some measurable characteristic, resulting from a set of measurements over a number of interactions between the service users and the service provider. .in -5 Each of the QoS parameters and attributes offered by a service provider can be broadly characterized as relating to one of performance, availability, security and cost. Of these categories, parameters and attributes in the performance category are the best understood, to the extent that most people equate QoS with the performance parameters and attributes. The entities at a layer cooperate with each other through the protocol(s) that operate(s) between them to maintain, enhance or degrade QoS attributes of the service offered to them by the lower layers, and to map these to the QoS attributes offered to the next higher layer. This often implies some tradeoffs within a layer, selecting mechanisms that enhance one attribute at the expense of another. For example, a link layer may enhance packet loss performance at the expense of delay jitter performance by operating a retransmission mechanism, or it may enhance packet loss performance at the expense of fixed delay performance by operating a FEC mechanism. The performance that results from the selected mechanism is mapped to the service offered by the link layer to the next higher layer (i.e., the IP layer). QoS parameters and attributes are quantitative and measureable. They relate to the abstract service offered by the service provider to the service user, rather than the mechanisms used within the service provider: for example, "100 mS fixed delay" is a QoS parameter, while "FEC ON" is not. Relative priority is often misunderstood to be a QoS parameter. It is not. There can be no measurable attribute associated with relative priority. The service user has no way to verify that it has received priority, or to assess the effect of priority on its own performance relative to that of other service users. Relative priorities alone do not offer any kind of assurance that any particular performance objective will be met for higher priority users. Particularly when used with greedy sources and TCP, it can provide excessively good performance to high priority users and excessivly poor performance to low priority users. Priorities are also difficult to manage. However, priorities can be used in mechanisms like schedulers and contention resolution schemes that are components of systems which do offer QoS guarantees. Objective values of QoS attributes are expressed as a QoS parameter set. QoS parameters may be subject to multiparty negotiation between the service users and the service provider, or they may be subject to policy set by the service provider. Negotiation, if any, is performed by a control protocol, such as Q.2931 (at the subnet layer when the subnet is an ATM network) or RSVP (at the IP layer). Sometimes, sets of particular QoS parameter values are standardized as a profile or class. This approach is inflexibile, often unscalable, usually creates contentiousness in standards committees, and is difficult to administer. Negotiation of individual parameters based on the capabilities of the service provider is preferable. Support for QoS guarantees in the Internet is not yet mature. However, it is generally recognized that such guarantees are needed to support real-time multimedia, toll quality telephony and other performance critical applications. There are presently two architectural approaches to providing QoS support in the Internet. .in +5 IP Integrated Services (Intserv) [RFC1633] provides fine-grained service guarantees to individual flows. Flows are identified by a flow specification (flowspec), which creates a stateful association between individual packets by matching fields in the packet header. Bandwidth is reserved for the flow, and appropriate traffic conditioning and scheduling is installed in routers along the path. The ReSerVation Protocol (RSVP) [RFC2205, RFC2210] usually, but not necessarily, is used to install flows. Intserv defines two services, in addition to the Default (best effort) service. .in +5 -- Guaranteed Service (GS) [RFC 2212] offers hard upper bounds on delay to flows that conform to a traffic specification (TSpec). It uses a fluid flow model to relate the TSpec and reserved bandwidth (RSpec) to variable delay. Non-conforming packets are forwarded on a best-effort basis. -- Controlled Load Service (CLS) [RFC2211] offers delay and packet loss equivalent to that of an unloaded network to flows that conform to a TSpec, but no hard bounds. Non-conforming packets are forwarded on a best-effort basis. .in -5 Intserv requires installation of state information in each participating routers, and absent this state in every router along the path, performance guarantees cannot be ensured. This, along with RSVP processing and the need for usage-based accounting is believed to lead to scalability problems, particularly in the core of the Internet. [RFC2208] IP Differentiated Services (Diffserv) [RFC2475] provides at "toolkit" that can be used to offer coarse-grained controls on aggregated flows. Diffserv in itself does NOT provide services or QoS guarantees, but can be used to construct services with QoS guarantees across a Differv domain. It attempts to address the scaling issues associated with Intserv by requiring state awareness only in the edge of a Diffserv domain. At the edge, packets are classified into flows, and the flows are conditioned (marked, policed or shaped) to a traffic conditioning specification (TCS). A Diffserv Codepoint (DSCP), which identifies a per-hop behavior (PHB) is set in each packet header. The DSCP is carried in the DS-field, which subsumes six bits of the former TOS byte of the IP header [RFC2474]. The PHB is the forwarding behavior which is to be applied to the packet in each node in the Diffserv domain. Although there is a "recommended" DSCP associated with each PHB, the mappings from DSCPs to PHBs are defined by the DS-domain. In fact, there can be several DSCPs associated with the same PHB. Diffserv presently defines three PHB groups. .in +5 The class selector PHB [RFC2474] subsumes the IP precedence semantics of the former TOS byte. It offers relative forwarding priorities. The Expedited Forwarding (EF) PHB [RFC2598] gurantees that packets will have a well-defined minimum departure rate which, if not exceeded, ensures that the associated queues are short or empty. EF is intended to support services that offer tightly bounded loss, delay and delay jitter. The Assured Forwarding (AF) PHB group [RFC2597] offers different levels of forwarding assurances for packets belonging to an aggregated flow. Each AF group is independently allocated forwarding resources. Packets are marked with one of three drop precedences, such that those with the highest drop precedence are dropped with lower probability than those marked with the lowest drop precedence. DSCPs are recommended for four independent AF groups, although a DS domain can have more or fewer AF groups. .in -5 The scope, field of application and correct use of Diffserv has been widely misunderstood. Diffserv was intended as a set of tools to allow ISPs to offer service level agreements to aggregates of customer traffic. It was not intended to allow individual flows to request and receive QoS guarantees. It does not, in itself, offer any particular QoS guarantees. There are no intrisic guarantees associated with marking a packet with a DSCP. Any QoS guarantees are subject of a service offered by an ISP. They underwritten by the use of classification, conditioning and scheduling at the edge of the Diffserv domain, traffic engineering and bandwidth management as well at the PHB selected by the DSCP. Ongoing work in the IETF is addressing ways to support Intserv with Diffserv; however, the Diffserv domain must be correctly engineered to support this. Similarly, there is ongoing work to create a set of Per-domain Behaviors (PDBs), which define the services offered by a Diffserv domain; note that these are NOT end-to-end services. .in -5 Support for QoS guarantees at the IP layer requires the correct operation of a set of cooperating mechanisms. These may include bandwidth reservation and admission control, policy management, routing, traffic classification, traffic conditioning (marking, policing and/or shaping), selective discard, queueing and scheduling. Note that some of these mechanisms require per-flow (or per-aggregate) state. Support for QoS in subnets may require similar mechanisms, especially when these subnets are general topology subnets (e.g., ATM, frame relay or MPLS) or shared media subnets. In some cases, subnet layer and IP layer mechanisms may be combined or coordinated within the devices at the edge of the subnet. More sophisticated mechanisms may allow more efficient use of lower layer resources and/or more fine grained QoS guarantees, at the expense of complexity. The following capabilities are desirable at the subnet layer (although some may be trivial or moot if the subnet is a simple point-to-point link): .in +5 - ability to reserve bandwidth for a connection or flow and schedule packets accordingly - bandwidth reservations should be based on a one- or two- token bucket model, depending on whether the service is intended to support constant rate or bursty traffic - if a connection or flow does not use its reserved bandwidth at a given time, the unused bandwidth should be able to be used by other flows. - packets in excess of a connection or flow's agreed rate should be able to be forwarded as best effort or discarded, depending on the service offered by the subnet to the IP layer. - if a subnet contains error control mechanisms (retransmission and/or FEC), it should be possible for the IP layer to trade errors and/or packet loss for fixed or variable delay. It should also be able to either discard or deliver to the IP layer any packets received with detected but uncorrected errors. These capabilities at the subnet/IP layer service boundary translate inside the subnet layer to selection of more or less error control and/or to selection of particular error control mechanisms. - the subnet layer should know, and be able to inform the IP layer, how much fixed delay and delay jitter it offers for a flow or connection. If the Intserv model is used, the delay jitter component may best be expresed in terms of the TSpec/RSpec model described in [RFC2212]. - although relative priority is not a QoS parameter, support of the Diffserv class selectors [RFC2474] does suggest that the subnet might also consider mechanisms that support priorities. - what else? .in -5 From owner-pilc@lerc.nasa.gov Tue Sep 5 17:03: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 ESMTP id RAA13769 for ; Tue, 5 Sep 2000 17:03:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA03660 for pilc-outgoing; Tue, 5 Sep 2000 16:05:40 -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 QAA03626 for ; Tue, 5 Sep 2000 16:05:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA13222; Tue, 5 Sep 2000 16:05:32 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012596; Tue, 5 Sep 00 16:04:40 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id NAA04646; Tue, 5 Sep 2000 13:04:37 -0700 (PDT) Message-ID: <39B55158.52C3919D@isi.edu> Date: Tue, 05 Sep 2000 13:02:32 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: pilc@grc.nasa.gov, touch@ISI.EDU Subject: Re: QoS replacement text for Links draft References: <200009051413.KAA13947@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Per my assignment from Pittsburgh, here is a first pass at QoS text. It might > stand a bit more polishing, but it's probably time to see what the rest of the > group has to say about it. ... > ---------------------- > New text > Quality-of-Service (QoS) Considerations ... > QoS parameters and attributes are quantitative and measureable. They relate > to the abstract service offered by the service provider to the service user, > rather than the mechanisms used within the service provider: for example, > "100 mS fixed delay" is a QoS parameter, while "FEC ON" is not. > > Relative priority is often misunderstood to be a QoS parameter. It is not. > There can be no measurable attribute associated with relative priority. The > service user has no way to verify that it has received priority, or to assess > the effect of priority on its own performance relative to that of other > service users. This seems overstated. First, anything that differentiates service can be a QoS parameter; it need not be quantitative or measurable. Just because it is not objectively verifiable does not prohibit its use; it may be difficult to charge or confirm, but it does allow differentiated service. While I agree that it may be difficult to assess in terms of others' performance, its usefulness may be intra-user, e.g., in differentiating the streams of a single customer. > Sometimes, sets of particular QoS parameter values are > standardized as a profile or class. This approach is inflexibile, often > unscalable, usually creates contentiousness in standards committees, and is > difficult to administer. The second sentence here appears to be a 'position'; I feel PILC documents should avoid such positions where possible. It would be better to discuss technical issues only. Joe From owner-pilc@lerc.nasa.gov Tue Sep 5 18:39: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 SAA15050 for ; Tue, 5 Sep 2000 18:39:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA16067 for pilc-outgoing; Tue, 5 Sep 2000 17:48: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 RAA16040 for ; Tue, 5 Sep 2000 17:48:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA12984; Tue, 5 Sep 2000 17:48:34 -0400 Received: from motgate2.mot.com(136.182.1.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012857; Tue, 5 Sep 00 17:48:17 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA04305; Tue, 5 Sep 2000 14:48:15 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA25663; Tue, 5 Sep 2000 14:48:14 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA07667; Tue, 5 Sep 2000 17:48:14 -0400 (EDT) Message-Id: <200009052148.RAA07667@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Joe Touch cc: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft In-reply-to: Your message of "Tue, 05 Sep 2000 13:02:32 EDT." <39B55158.52C3919D@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Sep 2000 17:48:10 -0400 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > ... > > QoS parameters and attributes are quantitative and measureable. They relate > > to the abstract service offered by the service provider to the service user, > > rather than the mechanisms used within the service provider: for example, > > "100 mS fixed delay" is a QoS parameter, while "FEC ON" is not. > > > > Relative priority is often misunderstood to be a QoS parameter. It is not. > > There can be no measurable attribute associated with relative priority. The > > service user has no way to verify that it has received priority, or to assess > > the effect of priority on its own performance relative to that of other > > service users. > > This seems overstated. First, anything that differentiates service > can be a QoS parameter; it need not be quantitative or measurable. I think we have a fundamental point of disagreement. I think of QoS from the perspective of the service user, and ultimately the application and the end user. QoS attempts to get to the issue of how satisfied the end user application are. Shenker, Clark et al have treated it in terms of microeconomic utility, and thus "satisfied" means "utility is maximized". If you can't measure it, then you can't evaluate how satisfied the end user is. There's no accountability (which is an important issue in anything other than a monthly flat-rate charging regime). > Just because it is not objectively verifiable does not prohibit I didn't say to prohibit it's use... we can't do that... but we should make it clear that priority is not QoS. > its use; it may be difficult to charge or confirm, but it > does allow differentiated service. Which is not the same thing as QoS. Maybe I should create some words to this effect. > > While I agree that it may be difficult to assess in terms of > others' performance, its usefulness may be intra-user, e.g., > in differentiating the streams of a single customer. I assume you're talking about N>1 independent flows having the same source host and the same destination host(s). It sounds like you'd like to isolate these flows from all other flows and allow some to have priority over the others. Why is this preferable to giving each flow independent performance objectives, such that the flows that you would give higher priority get more bandwidth and lower loss probability? Also, is this a sufficiently important case to create special mechanisms to allow related flows to be identified, isolated and prioritized throughout the Internet? > > > Sometimes, sets of particular QoS parameter values are > > standardized as a profile or class. This approach is inflexibile, often > > unscalable, usually creates contentiousness in standards committees, and is > > difficult to administer. > > The second sentence here appears to be a 'position'; I feel PILC > documents should avoid such positions where possible. It would be > better to discuss technical issues only. > Seems that we've taken some pretty strong positions elsewhere in this draft, in PEP, in Error and elsewhere. These are all technical concerns. Even, arguably, the problem of contentiousness in standards committees: I've been in these discussions... not a pretty sight. What happens is that in order to create these profiles (QoS classes or the like), the committee has to pick some end-to-end objective numbers and then allocate the impairments to various parts of the network. Everybody want's the lion's share of the allocation to play with in their network, the application folks want no impairment, the geo satellite folks demand that no QoS class have a guaranteed delay less than 300 mS, which starts a competitive battle with terrestrial folks, the standard comes out with lots of caveats and reservations and 'provisional assignments'... and, in the end, the actual service attributes depend on network toplology anyway. To my knowledge, IETF has wisely never permitted itself to get involved in this particular kind of bun fight. ITU-T and ETSI had a need to do so before the advent of modern QoS routing protocols and extensible control protocols. They would now be wise to get out of that business. > Joe Dan From owner-pilc@lerc.nasa.gov Tue Sep 5 19:56: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 ESMTP id TAA15620 for ; Tue, 5 Sep 2000 19:56:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA16970 for pilc-outgoing; Tue, 5 Sep 2000 17:58: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 RAA16947 for ; Tue, 5 Sep 2000 17:58:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA16315; Tue, 5 Sep 2000 17:58:37 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016213; Tue, 5 Sep 00 17:57:52 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id OAA22769; Tue, 5 Sep 2000 14:57:50 -0700 (PDT) Message-ID: <39B56BDE.95398358@isi.edu> Date: Tue, 05 Sep 2000 14:55:42 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009052148.RAA07667@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > > ... > > > QoS parameters and attributes are quantitative and measureable. They relate > > > to the abstract service offered by the service provider to the service user, > > > rather than the mechanisms used within the service provider: for example, > > > "100 mS fixed delay" is a QoS parameter, while "FEC ON" is not. > > > > > > Relative priority is often misunderstood to be a QoS parameter. It is not. > > > There can be no measurable attribute associated with relative priority. The > > > service user has no way to verify that it has received priority, or to assess > > > the effect of priority on its own performance relative to that of other > > > service users. > > > > This seems overstated. First, anything that differentiates service > > can be a QoS parameter; it need not be quantitative or measurable. > > I think we have a fundamental point of disagreement. > > I think of QoS from the perspective of the service user, and ultimately the > application and the end user. QoS attempts to get to the issue of how > satisfied the end user application are. Shenker, Clark et al have treated it > in terms of microeconomic utility, and thus "satisfied" means "utility is > maximized". If you can't measure it, then you can't evaluate how satisfied > the end user is. There's no accountability (which is an important issue in > anything other than a monthly flat-rate charging regime). > > > Just because it is not objectively verifiable does not prohibit > I didn't say to prohibit it's use... we can't do that... but we should make it > clear that priority is not QoS. I don't think it is our job to define QoS. If there is a document you can point to that clearly asserts that, esp. in the context of the IETF, that would be great. But PILC should not make these assertions of our own, but rather be as inclusive as possible. > > its use; it may be difficult to charge or confirm, but it > > does allow differentiated service. > Which is not the same thing as QoS. Maybe I should create some words to this > effect. If you have a reference to back it up, fine. If not, generality would be preferable, as above. > > While I agree that it may be difficult to assess in terms of > > others' performance, its usefulness may be intra-user, e.g., > > in differentiating the streams of a single customer. > I assume you're talking about N>1 independent flows having the same source > host and the same destination host(s). It sounds like you'd like to isolate > these flows from all other flows and allow some to have priority over the > others. Yes. > Why is this preferable to giving each flow independent performance > objectives, such that the flows that you would give higher priority get more > bandwidth and lower loss probability? Because it may exactly be relative performance that I require. Stating these in terms of absolute requirements is overconstraining. > Also, is this a sufficiently important > case to create special mechanisms to allow related flows to be identified, > isolated and prioritized throughout the Internet? As much as creating absolute guarantees across the internet is (i.e., yes). ... > > > Sometimes, sets of particular QoS parameter values are > > standardized as a profile or class. This approach is inflexibile, often > > unscalable, usually creates contentiousness in standards committees, and is > > difficult to administer. > > > The second sentence here appears to be a 'position'; I feel PILC > > documents should avoid such positions where possible. It would be > > better to discuss technical issues only. > > > Seems that we've taken some pretty strong positions elsewhere in this draft, > in PEP, in Error and elsewhere. These are all technical concerns. Even, > arguably, the problem of contentiousness in standards committees: I've been > in these discussions... not a pretty sight. What happens is that in order to > create these profiles (QoS classes or the like), the committee has to pick > some end-to-end objective numbers and then allocate the impairments to various > parts of the network. Everybody want's the lion's share of the allocation to > play with in their network, the application folks want no impairment, the geo > satellite folks demand that no QoS class have a guaranteed delay less than 300 > mS, which starts a competitive battle with terrestrial folks, the standard > comes out with lots of caveats and reservations and 'provisional > assignments'... and, in the end, the actual service attributes depend on > network toplology anyway. To my knowledge, IETF has wisely never permitted > itself to get involved in this particular kind of bun fight. ITU-T and ETSI > had a need to do so before the advent of modern QoS routing protocols and > extensible control protocols. They would now be wise to get out of that > business. It may be sufficient to express the problems without assessing blame, i.e.,: "This approach is difficult to coordinate." I would see it as being inherently scalable (as the number of flows increases, contrasted to RSVP) and easy to administer, at the expense of flexibility. Joe From owner-pilc@lerc.nasa.gov Tue Sep 5 21:22:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17036 for ; Tue, 5 Sep 2000 21:22:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA20840 for pilc-outgoing; Tue, 5 Sep 2000 18:44: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 SAA20807 for ; Tue, 5 Sep 2000 18:44:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA25656; Tue, 5 Sep 2000 18:43:59 -0400 Received: from mail1.pa.bell-labs.com(135.250.8.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025613; Tue, 5 Sep 00 18:43:10 -0400 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAP00972 (AUTH gja); Tue, 5 Sep 2000 15:43:05 -0700 (PDT) Message-ID: <39B577FC.8D0217A0@dnrc.bell-labs.com> Date: Tue, 05 Sep 2000 15:47:24 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman CC: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009051413.KAA13947@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: [..] > The IP header includes a 1-byte TOS (type of service) field. This > field is broken into two parts: a 3-bit precedence field that > indicates the relative importance of this packet compared to others, > and a 4-bit "qualitative tradeoff" field to indicate if low delay, > high throughput, high reliability or low cost is qualitatively more > important for this particular packet. One TOS bit is reserved. I believe the full octet is properly referred to as the "ToS byte" or "ToS octet", with the subsidiary fields being the "Precedence bits" and "ToS bits" (or "Precedence field" and "ToS field") respectively. Fwiw, it seems rather torturous to introduce the four ToS bits as '..a 4-bit "qualitative tradeoff" field...' cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-pilc@lerc.nasa.gov Tue Sep 5 21:47:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18218 for ; Tue, 5 Sep 2000 21:47:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA26347 for pilc-outgoing; Tue, 5 Sep 2000 20:19: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 UAA26325 for ; Tue, 5 Sep 2000 20:19:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA06826; Tue, 5 Sep 2000 20:19:11 -0400 Received: from imr1.ericy.com(208.237.135.240) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006760; Tue, 5 Sep 00 20:18:12 -0400 Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.9.3/8.9.3) with ESMTP id TAA03157; Tue, 5 Sep 2000 19:18:10 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.9.3/8.9.3) with ESMTP id TAA29248; Tue, 5 Sep 2000 19:18:10 -0500 (CDT) Received: from b02c25.exu.ericsson.se (b02c25 [138.85.32.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA15662; Tue, 5 Sep 2000 19:18:09 -0500 (CDT) Received: (from exumus@localhost) by b02c25.exu.ericsson.se (8.9.1/8.9.1) id TAA12785; Tue, 5 Sep 2000 19:18:08 -0500 (CDT) From: Mustafa Kocaturk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14773.36159.787014.686270@gargle.gargle.HOWL> Date: Tue, 5 Sep 2000 19:18:07 -0500 (CDT) To: "Falk, Aaron" Cc: "'pilc@grc.nasa.gov'" , "Spencer Dawkins (E-mail)" Subject: Reminder: WG last call for ERROR In-Reply-To: <8046A317B5F4D21186610008C7EBB696020FD092@grnexch1.panamsat.com> References: <8046A317B5F4D21186610008C7EBB696020FD092@grnexch1.panamsat.com> X-Mailer: VM 6.75 under 21.1 (patch 3) "Acadia" XEmacs Lucid Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Below are some remarks from my "proofreading": In Section 2.2, the second paragraph, the first sentence "... when data when is received ..." please remove the second instance of "when". In Section 4.1, last part of the first sentence "... injecting packets into errored connections as fast as possible, but no faster." sounds too circular. Could it be reworded, as in: "... injecting packets into errored connections as fast as possible, but no faster than the connection can carry."? In Appendix C, second sentence, please explain what the acronym "cwnd" stands for. Kindest regards, Mustafa Kocaturk -- Ericsson Research @ Texas +1 972 583 5801 EUS/SO/HM (Wireless System Characteristics) Falk, Aaron writes: Working group last call is coming to an end for ERROR. Spencer will be following up with a summary of comments/changes for the draft before we submit it to the IESG. If there are any further comments, now is the time. --aaron > -----Original Message----- > From: Falk, Aaron [mailto:aaron@panamsat.com] > Sent: Monday, August 14, 2000 10:23 AM > To: 'pilc@grc.nasa.gov' > Cc: Spencer Dawkins (E-mail); 'gab@sun.com'; 'kojo@cs.helsinki.fi'; > 'vaidya@cs.tamu.edu'; 'vincent.magret@aud.alcatel.com' > Subject: WG last call for ERROR > > > The document "End-to-end Performance Implications of Links > with Errors" is > ready for working group last call. Please send comments to > the PILC mail > list. > > A current version of the draft can be obtained from > http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-04.txt > > From owner-pilc@lerc.nasa.gov Wed Sep 6 12:12:08 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16070 for ; Wed, 6 Sep 2000 12:12:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09034 for pilc-outgoing; Wed, 6 Sep 2000 11:07: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 LAA08974 for ; Wed, 6 Sep 2000 11:07:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA07709; Wed, 6 Sep 2000 11:07:26 -0400 Received: from unknown(144.189.100.103) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007036; Wed, 6 Sep 00 11:06:34 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA09808; Wed, 6 Sep 2000 08:04:27 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA28111; Wed, 6 Sep 2000 08:06:30 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA23350; Wed, 6 Sep 2000 11:06:29 -0400 (EDT) Message-Id: <200009061506.LAA23350@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Joe Touch cc: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft In-reply-to: Your message of "Tue, 05 Sep 2000 14:55:42 EDT." <39B56BDE.95398358@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Sep 2000 11:06:24 -0400 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > > > > Just because it is not objectively verifiable does not prohibit > > I didn't say to prohibit it's use... we can't do that... but we should make it > > clear that priority is not QoS. > > I don't think it is our job to define QoS. This is a tutorial. Defining QoS for uninformed readers is well within its scope, in much the same way that we teach about the end-to-end principle and how TCP works. > If there is a document > you can point to that clearly asserts that, esp. in the context > of the IETF, that would be great. Unfortunately, IETF has tended to assume that those who work in this area read the research literature on the subject. There's nothing new here. It's well documented in the literature. > But PILC should not make > these assertions of our own, but rather be as inclusive as possible. > > > > its use; it may be difficult to charge or confirm, but it > > > does allow differentiated service. > > Which is not the same thing as QoS. Maybe I should create some words to this > > effect. > > If you have a reference to back it up, fine. If not, generality > would be preferable, as above. What do you mean by "generality"? > > > > While I agree that it may be difficult to assess in terms of > > > others' performance, its usefulness may be intra-user, e.g., > > > in differentiating the streams of a single customer. > > I assume you're talking about N>1 independent flows having the same source > > host and the same destination host(s). It sounds like you'd like to isolate > > these flows from all other flows and allow some to have priority over the > > others. > > Yes. > > > Why is this preferable to giving each flow independent performance > > objectives, such that the flows that you would give higher priority get more > > bandwidth and lower loss probability? > > Because it may exactly be relative performance that I require. Why would an application want two streams with some unspecified differentiation between them? > Stating these in terms of absolute requirements is overconstraining. Well, we need some constraints. > > > Also, is this a sufficiently important > > case to create special mechanisms to allow related flows to be identified, > > isolated and prioritized throughout the Internet? > > As much as creating absolute guarantees across the internet is (i.e., > yes). Except that we have absolute guarantees in Intserv and (at least arguably) in Diffserv (draft-ietf-diffserv-pdb-def-00.txt). And we have absolute guarantees in ATM. And at least a hint of absolute guarantees in MPLS. We don't have any architecture or mechanism that allows small groups of flows to be given resources and priority to be assigned within those groups on a fine-grained basis end-to-end. > > ... > > > > > Sometimes, sets of particular QoS parameter values are > > > standardized as a profile or class. This approach is inflexibile, often > > > unscalable, usually creates contentiousness in standards committees, and is > > > difficult to administer. > > > > > The second sentence here appears to be a 'position'; I feel PILC > > > documents should avoid such positions where possible. It would be > > > better to discuss technical issues only. > > > > > Seems that we've taken some pretty strong positions elsewhere in this draft, > > in PEP, in Error and elsewhere. These are all technical concerns. Even, > > arguably, the problem of contentiousness in standards committees: I've been > > in these discussions... not a pretty sight. What happens is that in order to > > create these profiles (QoS classes or the like), the committee has to pick > > some end-to-end objective numbers and then allocate the impairments to various > > parts of the network. Everybody want's the lion's share of the allocation to > > play with in their network, the application folks want no impairment, the geo > > satellite folks demand that no QoS class have a guaranteed delay less than 300 > > mS, which starts a competitive battle with terrestrial folks, the standard > > comes out with lots of caveats and reservations and 'provisional > > assignments'... and, in the end, the actual service attributes depend on > > network toplology anyway. To my knowledge, IETF has wisely never permitted > > itself to get involved in this particular kind of bun fight. ITU-T and ETSI > > had a need to do so before the advent of modern QoS routing protocols and > > extensible control protocols. They would now be wise to get out of that > > business. > > It may be sufficient to express the problems without assessing blame, > i.e.,: "This approach is difficult to coordinate." Nobody is assessing blame. It's a case where an architectural decision has bad consequences. One of these consequences is that it is guaranteed to create conflicts in standards committees. > I would see it as > being inherently scalable (as the number of flows increases, contrasted > to RSVP) It is inherently topologically inscalable. The objective values of the parameters has to increase as the diameter of the network and/or the composition of the worst-case characteristics of the links. As a result, the guarantees offered become more and more diluted. And the applications don't have a clue as to what kind of performance to expect, absent knowledge of network topology, since the difference between the performance of the best path and the performance of the worst path is so large. > and easy to administer, No... it pushes to the administrative realm concerns that are best handled by control protocols and routing. What happens is that network design and engineering becomes complicated by the constraints of the QoS Classes. In multi-provider environments, customer complaints of failure to achieve a fixed objective for a particular QoS class becomes a finger pointing contest between providers. QoS classes lack economy of scope: every time somebody creates an application with different needs, a new class has to be created and supporting machinery disseminated in the network. > at the expense of flexibility. > Dan From owner-pilc@lerc.nasa.gov Wed Sep 6 12:21:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16565 for ; Wed, 6 Sep 2000 12:21:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA13715 for pilc-outgoing; Wed, 6 Sep 2000 11:30:53 -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 LAA13681 for ; Wed, 6 Sep 2000 11:30:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA01650; Wed, 6 Sep 2000 11:30:47 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000682; Wed, 6 Sep 00 11:29:52 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Wh8r-0003kq-00; Wed, 06 Sep 2000 16:29:37 +0100 Date: Wed, 6 Sep 2000 16:29:34 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dan Grossman cc: Joe Touch , pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft In-Reply-To: <200009061506.LAA23350@noah.dma.isg.mot.com> 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, 6 Sep 2000, Dan Grossman wrote: > > > > Just because it is not objectively verifiable does not prohibit > > > I didn't say to prohibit it's use... we can't do that... but we should make it > > > clear that priority is not QoS. > > > > I don't think it is our job to define QoS. > > This is a tutorial. Defining QoS for uninformed readers is well within its > scope, in much the same way that we teach about the end-to-end principle and > how TCP works. Since really informed readers can't decide on what QoS is either (see Crowcroft's post today to the main IETF discussion list) I frankly don't see the point of doing so. Pointers to further reading, fine. But prescriptive text? > Except that we have absolute guarantees in Intserv and (at least arguably) in > Diffserv (draft-ietf-diffserv-pdb-def-00.txt). 'absolute' is meaningless outside a single administrative domain. Downstream degradation in diffserv, etc. L. PGP From owner-pilc@lerc.nasa.gov Wed Sep 6 12:26:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16722 for ; Wed, 6 Sep 2000 12:26:41 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA13710 for pilc-outgoing; Wed, 6 Sep 2000 11:30:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA13679 for ; Wed, 6 Sep 2000 11:30:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA01654; Wed, 6 Sep 2000 11:30:47 -0400 Received: from mail1.pa.bell-labs.com(135.250.8.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001500; Wed, 6 Sep 00 11:30:33 -0400 Received: from dnrc.bell-labs.com (ex-vpn65.pa.bell-labs.com [135.250.1.65]) by mail1.pa.bell-labs.com (Mirapoint) with ESMTP id AAP01974 (AUTH gja); Wed, 6 Sep 2000 08:30:27 -0700 (PDT) Message-ID: <39B6631F.F34A6397@dnrc.bell-labs.com> Date: Wed, 06 Sep 2000 08:30:39 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Grossman , pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009051413.KAA13947@noah.dma.isg.mot.com> <39B577FC.8D0217A0@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Tired, sleepy, stupid - you name it, I'm sure that's why I commented on the old text rather than the new text Dan's proposing. Duh :( cheers, gja From owner-pilc@lerc.nasa.gov Wed Sep 6 13:03:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17852 for ; Wed, 6 Sep 2000 13:03:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA20918 for pilc-outgoing; Wed, 6 Sep 2000 12:12: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 MAA20878 for ; Wed, 6 Sep 2000 12:12:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA08649; Wed, 6 Sep 2000 12:12:33 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008153; Wed, 6 Sep 00 12:12:12 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07869; Wed, 6 Sep 2000 09:12:10 -0700 (PDT) Message-ID: <39B66C4B.72B2D356@isi.edu> Date: Wed, 06 Sep 2000 09:09:47 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009061506.LAA23350@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > > > > > > > Just because it is not objectively verifiable does not prohibit > > > I didn't say to prohibit it's use... we can't do that... but we should make it > > > clear that priority is not QoS. > > > > I don't think it is our job to define QoS. > > This is a tutorial. Defining QoS for uninformed readers is well within its > scope, in much the same way that we teach about the end-to-end principle and > how TCP works. Agreed - I was asserting that it not our job to _uniquely_ define QoS. If there is a reference for the definition given, that's fine. New definitions should be avoided (esp. in a tutorial). > > If there is a document > > you can point to that clearly asserts that, esp. in the context > > of the IETF, that would be great. > > Unfortunately, IETF has tended to assume that those who work in this area read > the research literature on the subject. There's nothing new here. It's well > documented in the literature. ^^^^^^^^^^^^^^^^^ OK - so a non-IETF reference is fine. > > But PILC should not make > > these assertions of our own, but rather be as inclusive as possible. > > > > > > its use; it may be difficult to charge or confirm, but it > > > > does allow differentiated service. > > > Which is not the same thing as QoS. Maybe I should create some words to this > > > effect. > > > > If you have a reference to back it up, fine. If not, generality > > would be preferable, as above. > > What do you mean by "generality"? Your definition of QoS precludes relative services. I would prefer a more general definition, e.g., one that allows relative service. > > > > While I agree that it may be difficult to assess in terms of > > > > others' performance, its usefulness may be intra-user, e.g., > > > > in differentiating the streams of a single customer. > > > I assume you're talking about N>1 independent flows having the same source > > > host and the same destination host(s). It sounds like you'd like to isolate > > > these flows from all other flows and allow some to have priority over the > > > others. > > > > Yes. > > > > > Why is this preferable to giving each flow independent performance > > > objectives, such that the flows that you would give higher priority get more > > > bandwidth and lower loss probability? > > > > Because it may exactly be relative performance that I require. > > Why would an application want two streams with some unspecified > differentiation between them? I didn't say that it was unspecified, only that it was relative. E.g., that queuing loss on stream A should be twice that of stream B, e.g. > > > Also, is this a sufficiently important > > > case to create special mechanisms to allow related flows to be identified, > > > isolated and prioritized throughout the Internet? > > > > As much as creating absolute guarantees across the internet is (i.e., > > yes). > > Except that we have absolute guarantees in Intserv and (at least arguably) in > Diffserv (draft-ietf-diffserv-pdb-def-00.txt). And we have absolute > guarantees in ATM. And at least a hint of absolute guarantees in MPLS. We > don't have any architecture or mechanism that allows small groups of flows to > be given resources and priority to be assigned within those groups on a > fine-grained basis end-to-end. Sure we do - that's what happens anytime muxing occurs within a flow, e.g., BXXP. > Nobody is assessing blame. It's a case where an architectural decision has > bad consequences. One of these consequences is that it is guaranteed to create > conflicts in standards committees. The architectural decision requires standards committees agree. Any such requirement generates conflicts in such committees. Does that imply that any standards-based solution is architecturally bad? What properties about this solution _uniquely_ make it more difficult to standardize than, say, _any_ system that requires protocol agreement? > > I would see it as > > being inherently scalable (as the number of flows increases, contrasted > > to RSVP) > It is inherently topologically inscalable. Ahh - then perhaps that could be indicated. As a few others have pointed out, "scale" requires indicating what parameter doesn't scale. > > and easy to administer, > No... it pushes to the administrative realm concerns that are best handled by > control protocols and routing. That sounds like religion, not architecture. > What happens is that network design and > engineering becomes complicated by the constraints of the QoS Classes. In > multi-provider environments, customer complaints of failure to achieve a fixed > objective for a particular QoS class becomes a finger pointing contest between > providers. That is an organizational failure, not necessarily a protocol failure. > QoS classes lack economy of scope: every time somebody creates an > application with different needs, a new class has to be created and supporting > machinery disseminated in the network. The same is true for parameters - say you create a QoS system that specifies delay, jitter, rate, and loss. Then someone comes along and cares about some other parameter, e.g., variance of the jitter. The system similarly has to be re-engineered. Joe From owner-pilc@lerc.nasa.gov Wed Sep 6 16:38:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22889 for ; Wed, 6 Sep 2000 16:38:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA20720 for pilc-outgoing; Wed, 6 Sep 2000 15:22:40 -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 PAA20672 for ; Wed, 6 Sep 2000 15:22:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA27421; Wed, 6 Sep 2000 15:22:35 -0400 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027024; Wed, 6 Sep 00 15:21:45 -0400 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Wed, 6 Sep 2000 15:21:42 -0400 Message-ID: <8046A317B5F4D21186610008C7EBB696020FD0D6@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'Reiner Ludwig'" Cc: "'pilc@grc.nasa.gov'" , "Spencer Dawkins (E-mail)" , "'gab@sun.com'" , "'kojo@cs.helsinki.fi'" , "'vaidya@cs.tamu.edu'" , "'vincent.magret@aud.alcatel.com'" Subject: RE: Reminder: WG last call for ERROR Date: Wed, 6 Sep 2000 15:15:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk ...getting caught up... > -----Original Message----- > From: Reiner Ludwig [mailto:Reiner.Ludwig@ericsson.com] > >Working group last call is coming to an end for ERROR. > > Asking the IESG for what? Informational RFC? BCP. From owner-pilc@lerc.nasa.gov Thu Sep 7 15:52: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 PAA25179 for ; Thu, 7 Sep 2000 15:52:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA04288 for pilc-outgoing; Thu, 7 Sep 2000 14:49: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 OAA04251 for ; Thu, 7 Sep 2000 14:49:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA29854; Thu, 7 Sep 2000 14:49:34 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029543; Thu, 7 Sep 00 14:49:08 -0400 Received: from isi.edu (pen-bc.isi.edu [128.9.144.252]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA16960; Thu, 7 Sep 2000 11:49:06 -0700 (PDT) Message-ID: <39B7E318.4BE53F3D@isi.edu> Date: Thu, 07 Sep 2000 11:48:56 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dan Grossman CC: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009071836.OAA23420@noah.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dan Grossman wrote: > > Your definition of QoS precludes relative services. I would prefer a > > more general definition, e.g., one that allows relative service. > > Ok... see RFC1633: > It is true that simply giving higher priority to real-time > traffic would lead to adequate real-time service at some > times and under some conditions. But priority is an > implementation mechanism, not a service model. If we define > the service by means of a specific mechanism, we may not get > the exact features we want. In the case of simple priority, > the issue is that as soon as there are too many real-time > streams competing for the higher priority, every stream is > degraded. Restricting our service to this single failure > mode is unacceptable. In some cases, users will demand that > some streams succeed while some new requests receive a "busy > signal". > We could reference RFC1633 here. If that is the limit of what you are suggesting that link layers support. > > > Except that we have absolute guarantees in Intserv and (at least arguably) in > > > Diffserv (draft-ietf-diffserv-pdb-def-00.txt). And we have absolute > > > guarantees in ATM. And at least a hint of absolute guarantees in MPLS. We > > > don't have any architecture or mechanism that allows small groups of flows to > > > be given resources and priority to be assigned within those groups on a > > > fine-grained basis end-to-end. > > > > Sure we do - that's what happens anytime muxing occurs within a flow, > > e.g., BXXP. > Are we talking about drop precedence, as in AFxy and CLP (in ATM) or are we > talking about scheduling priority? Scheduling priority is more likely to be intra-stream. Making drop precedence intrastream is hard, excepting intra-packet relationships (e.g., EPD). > > The architectural decision requires standards committees agree. Any such > > requirement generates conflicts in such committees. Does that imply that > > any standards-based solution is architecturally bad? What properties > > about this solution _uniquely_ make it more difficult to standardize > > than, say, _any_ system that requires protocol agreement? > It forces the committee to make decisions that advantage or disadvantage some > service > providers relative to others, or service providers relative to equipment > manufacturers. A different architecture would simply obviate these issues. That is not a property of the architure - it is a property of any finite set of decisions. > > > > I would see it as > > > > being inherently scalable (as the number of flows increases, contrasted > > > > to RSVP) > > > It is inherently topologically inscalable. > > > > Ahh - then perhaps that could be indicated. As a few others have pointed > > out, "scale" requires indicating what parameter doesn't scale. > > > I'll agree with that. > > > > and easy to administer, > > > No... it pushes to the administrative realm concerns that are best handled by > > > control protocols and routing. > > > > That sounds like religion, not architecture. > Ad homenem attack. > > The point is that dynamic, real-time and short-term predictive controls built > into protocols and distributed algorithms are more granular (read efficient) > and require less human intervention (read: cost and opportunity for human > error) than administration, albeit at a cost of complexity and protocol > overhead. Better stated. Can a variant of that be included? > > > What happens is that network design and > > > engineering becomes complicated by the constraints of the QoS Classes. In > > > multi-provider environments, customer complaints of failure to achieve a fixed > > > objective for a particular QoS class becomes a finger pointing contest between > > > providers. > > > > That is an organizational failure, not necessarily a protocol failure. > It is an architectural failure. State the architectural requirement then, as such. I.e., you want a distributed, objective system which allows independent assessment. It would be much better than talking about the undesireable side effects which are believed to be the result of alternate architectures, e.g., organizational confusion, etc. Joe From owner-pilc@lerc.nasa.gov Thu Sep 7 15:53:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25263 for ; Thu, 7 Sep 2000 15:53:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA02569 for pilc-outgoing; Thu, 7 Sep 2000 14:37:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA02529 for ; Thu, 7 Sep 2000 14:37:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA18368; Thu, 7 Sep 2000 14:37:28 -0400 Received: from ftpbox.mot.com(129.188.136.101) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017691; Thu, 7 Sep 00 14:36:29 -0400 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA00594; Thu, 7 Sep 2000 11:36:27 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA18124; Thu, 7 Sep 2000 11:35:16 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA23420; Thu, 7 Sep 2000 14:36:24 -0400 (EDT) Message-Id: <200009071836.OAA23420@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Joe Touch cc: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft In-reply-to: Your message of "Wed, 06 Sep 2000 09:09:47 EDT." <39B66C4B.72B2D356@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Sep 2000 14:36:23 -0400 From: Dan Grossman Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > > > Dan Grossman wrote: > > > > > > > > > > > Just because it is not objectively verifiable does not prohibit > > > > I didn't say to prohibit it's use... we can't do that... but we should make it > > > > clear that priority is not QoS. > > > > > > If there is a document > > > you can point to that clearly asserts that, esp. in the context > > > of the IETF, that would be great. > > > > Unfortunately, IETF has tended to assume that those who work in this area read > > the research literature on the subject. There's nothing new here. It's well > > documented in the literature. > ^^^^^^^^^^^^^^^^^ > > OK - so a non-IETF reference is fine. I'm having trouble finding a comprehensive reference. By "in the literature", I meant a significant body of work over the past decade or so. I'd be grateful if somebody could point out a (or a few) comprehensive papers that reflect the proposed text. > > > > But PILC should not make > > > these assertions of our own, but rather be as inclusive as possible. > > > > > > > > its use; it may be difficult to charge or confirm, but it > > > > > does allow differentiated service. > > > > Which is not the same thing as QoS. Maybe I should create some words to this > > > > effect. > > > > > > If you have a reference to back it up, fine. If not, generality > > > would be preferable, as above. > > > > What do you mean by "generality"? > > Your definition of QoS precludes relative services. I would prefer a > more general definition, e.g., one that allows relative service. Ok... see RFC1633: It is true that simply giving higher priority to real-time traffic would lead to adequate real-time service at some times and under some conditions. But priority is an implementation mechanism, not a service model. If we define the service by means of a specific mechanism, we may not get the exact features we want. In the case of simple priority, the issue is that as soon as there are too many real-time streams competing for the higher priority, every stream is degraded. Restricting our service to this single failure mode is unacceptable. In some cases, users will demand that some streams succeed while some new requests receive a "busy signal". We could reference RFC1633 here. > > > Except that we have absolute guarantees in Intserv and (at least arguably) in > > Diffserv (draft-ietf-diffserv-pdb-def-00.txt). And we have absolute > > guarantees in ATM. And at least a hint of absolute guarantees in MPLS. We > > don't have any architecture or mechanism that allows small groups of flows to > > be given resources and priority to be assigned within those groups on a > > fine-grained basis end-to-end. > > Sure we do - that's what happens anytime muxing occurs within a flow, > e.g., BXXP. Are we talking about drop precedence, as in AFxy and CLP (in ATM) or are we talking about scheduling priority? > > > Nobody is assessing blame. It's a case where an architectural decision has > > bad consequences. One of these consequences is that it is guaranteed to create > > conflicts in standards committees. > > The architectural decision requires standards committees agree. Any such > requirement generates conflicts in such committees. Does that imply that > any standards-based solution is architecturally bad? What properties > about this solution _uniquely_ make it more difficult to standardize > than, say, _any_ system that requires protocol agreement? It forces the committee to make decisions that advantage or disadvantage some service providers relative to others, or service providers relative to equipment manufacturers. A different architecture would simply obviate these issues. > > > > I would see it as > > > being inherently scalable (as the number of flows increases, contrasted > > > to RSVP) > > It is inherently topologically inscalable. > > Ahh - then perhaps that could be indicated. As a few others have pointed > out, "scale" requires indicating what parameter doesn't scale. > I'll agree with that. > > > and easy to administer, > > No... it pushes to the administrative realm concerns that are best handled by > > control protocols and routing. > > That sounds like religion, not architecture. Ad homenem attack. The point is that dynamic, real-time and short-term predictive controls built into protocols and distributed algorithms are more granular (read efficient) and require less human intervention (read: cost and opportunity for human error) than administration, albeit at a cost of complexity and protocol overhead. > > What happens is that network design and > > engineering becomes complicated by the constraints of the QoS Classes. In > > multi-provider environments, customer complaints of failure to achieve a fixed > > objective for a particular QoS class becomes a finger pointing contest between > > providers. > > That is an organizational failure, not necessarily a protocol failure. It is an architectural failure. > > > QoS classes lack economy of scope: every time somebody creates an > > application with different needs, a new class has to be created and supporting > > machinery disseminated in the network. > > The same is true for parameters - say you create a QoS system that > specifies delay, jitter, rate, and loss. Then someone comes along and > cares about some other parameter, e.g., variance of the jitter. The > system similarly has to be re-engineered. Far more rarely, if ever. By way of drawing on others' experiences, I'm aware of at least three occasions where ITU-T has needed to define additional QoS classes for ATM since the initial publication of I.356 (sorry, don't remember details). Neither ITU-T nor ATM Forum have needed to add new QoS parameters. Also, the ATM Forum approach of individually negotiated QoS parameters, in conjunction with supporting machinery in PNNI is being adopted by network operators, including some who'd opposed it originally. But this is off topic. As was pointed out in Pittsburgh (by the retiring IAB chair and our A-D), IETF doesn't standardize performance objectives. From owner-pilc@lerc.nasa.gov Fri Sep 8 15:09: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 PAA28376 for ; Fri, 8 Sep 2000 15:09:30 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA29340 for pilc-outgoing; Fri, 8 Sep 2000 13:30: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 NAA29284 for ; Fri, 8 Sep 2000 13:29:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA18595; Fri, 8 Sep 2000 13:29:52 -0400 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018468; Fri, 8 Sep 00 13:29:40 -0400 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Fri, 8 Sep 2000 10:37:22 -0400 Message-ID: <8046A317B5F4D21186610008C7EBB696020FD0FC@grnexch1.panamsat.com> From: "Falk, Aaron" To: "'minutes@ietf.org'" , "'pilc@grc.nasa.gov'" Cc: "'Spencer Dawkins (E-mail)'" , "Allison Mankin (E-mail)" Subject: pilc minutes for IETF 48 Date: Fri, 8 Sep 2000 09:39:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Performance Implications of Link-layer Characteristics (PILC) Minutes August 2, 2000, Pittsburgh, PA Reported by Jim Griner (jgriner@grc.nasa.gov) Edited by Aaron Falk (aaron@panamsat.com) Charts and documents are available from the PILC Web page at http://pilc.grc.nasa.gov ************ Aaron Falk opened the meeting at 3:30pm and reviewed the agenda, Agenda bashing, with no comments milestones & status TCP over Wireless draft. The working group charter specifies that PILC will produce a 'TCP over Wireless' RFC that is a meta list of the existing PILC recommendations. This was reported in Adelaide as being completed in October 1999 because Aaron had confused it with the LTN draft. Actually, it requires some work. Gabe Montenegro has volunteered to sync up with the WAP forum to see if we can build this document on a work in progress that already exists in that body. The document should be only 3 or 4 pages long and should go to wg last call by January 2001. Gabe noted that there is currently no buy in by the WAP forum as yet, he will attend a forum meeting in September and try to resolve. Several members of WAP were in the room and volunteered to assist if needed. ERROR draft. A rough poll was taken indicating the group felt ERROR was ready for wg last call. SLOW draft. One of the SLOW authors wanted to incorporate some additional comments before submitting the draft for wg last call. When polled, there was no clear consensus of the group. Will see what comments come up on mail list during last call. Last call should take place in September. There was some discussion about interactions between slow and errored networks and that there should be a way to document interactions when you have multiple characteristics in a network. In particular, it was pointed out that these interactions are not well understood. However, most of the understood ones exist in some of the PILC documents (ERROR, SLOW, and LINK). It was suggested that appropriate cross references be added to ensure readers of one document are aware of relevant interactions described in another document. Suggested this issue gets raised on the list to see if there are interactions that need to be captured somewhere. (Some interactions were captured in RFC2488 but these are appropriate for all environments since that document focuses on long delay links.) Updated Working Group Milestones Aug 2000: ERROR (BCP) to working group last call Sep 2000: SLOW (BCP) to working group last call PEP (Informational) to working group last call Nov 2000: LINK (BCP) to working group last call Jan 2001: TCP over Wireless (BCP) to working group last call Note: ASYM is in limbo right now until we get an updated draft. Phil Karn - LINK document status Placing emphasis on end-to-end model. The multicast section is still incomplete. Didn't add much to this revision of the document. Assymetry section overlaps with asym draft. May rip out section on QoS because there may not be much well understood advice that can be given. Document still needs text on: o) delay interaction with tcp o) link layer retransmission o) does the subnetwork need its own routing mechanism? o) security Comments: Dan Grossman thinks there is some parts of QoS that are not overlapping with diff serv, and will provide some text. John Border - PEP document status Didn't receive many comments on -02 draft. Draft-03 released prior to this meeting. A disclaimer was added to say it is an overview document and does not include all PEP mechanisms. Document needs text on: o) section 3.6 on protocol boosters o) section 4.4.1 pep scalability implications o) section 4.4.2 and 4.4.3 multi-homing (maybe delete these section if no input received) o) add DoCoMo examples section, from DoCoMo draft o) W-LAN section needs text Plan next release (-04 draft) at end of September Aaron - PEP comments PEPs are being used in many environments, and we ignore them at our peril. One reason this document is being written is that we need to show what the downsides are to using peps. Outside organizations who are using these types of mechanisms (such as WAP) are being directed to pilc by the IESG so that they can understand how the IETF views these mechanisms. The PEP document is the place to show the problems of using PEPs. We need more information from members of the working group to add to the document. Specifically, we have not received adequate comments from an architectural perspective. Geoff pointed out that things like multi-homing are being used as a surrogate for reliability. Joe Touch suggested to limit PEP document to IP layer discussions, rather than the link layer problem. John Border noted that we were deferring link layer mechanisms to the link document, due to the scope of pep. There was also a comment mentioning that PEPs are being used to put QoS in wireless links, and maybe need to include this in PEP. Discussion on DoCoMo draft (draft-inamura-docomo-00.txt) Aaron noted that DoCoMo would like to publish this as informational RFC, but we don't want to get in a mode of publishing RFCs each time someone does this and requested input from the group. A speaker noted that the recommendations are pretty generic and suggested the working group use this as a starting point for the TCP over wireless document, or as an appendix to this document. Aaron suggested it might be necessary to take the simulation results out in order to use this document for the TCP over wireless document. Another speaker suggested using path MTU discovery instead of fixing it at 1500. Question: Maybe your tcp stack in the Opnet simulator is not the best TCP. Have you run this on real stacks, rather than on a simulator. Imaura - yes they have, but no published results. Aaron noted that another alternative was that the DoCoMo would be sent forth as informational, and would not be a recommendation. Tim Shepard asked why would one want to disseminate this information? Doesn't seem to make sense to have multiples of TCP/some link technology. Is this advice on how to tune TCP for the handset? Response from author: yes. Comment: This shows that tcp stack works over wireless error prone links. Comment: Doesn't think these results are any different from what a modern TCP stack does anyway. Gabe: This is similar to what was done in ecn document Comment: Thinks this should be published in academic journals, and not as an RFC Question: What bandwidth was used in the simulations? Imaura: 384kbs Comment: Doesn't think this is realistic, since this is only the rate if you are the only one in the cell. WAP is designed to use slower links. Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) Comment: this is probably not a good idea -- leads to ICMP flooding. Also, if there is a long outage you do want to go through slow start again, because the network has changed. There are better link level solutions to this problem. Question: Why do you need a proxy and not just use end-to-end signaling? Response: The supervisor is in a better position to determine if there is an interruption. Response: In this case you need a proxy, and can't do it end-to-end. From owner-pilc@lerc.nasa.gov Tue Sep 12 16:09:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13408 for ; Tue, 12 Sep 2000 16:09:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA15899 for pilc-outgoing; Tue, 12 Sep 2000 14:46: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 OAA15871 for ; Tue, 12 Sep 2000 14:46:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA06548; Tue, 12 Sep 2000 14:46:10 -0400 Received: from fortress.fnc.fujitsu.com(204.253.82.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005192; Tue, 12 Sep 00 14:45:27 -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 NAA21261 for ; Tue, 12 Sep 2000 13:45:24 -0500 (CDT) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Sep 2000 13:45:25 -0500 Message-ID: From: "Dawkins, Spencer" To: "'PILC Mailing List'" Subject: Updates for ERROR after WG last call Date: Tue, 12 Sep 2000 13:45:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk These are the changes that I'm looking at, after the comments received during WG last call. Section 2.1, second bullet: Was: - During slow start, the sender increases its window in units of segments. This is why it is important to use an appropriately sized MTU - and less reliable link layers often use smaller MTUs. Suggested: - Less-reliable link layers often use small link MTUs. This slows the rate of increase in the sender's window size during slow start, because the sender's window is increased in units of segments. Small link MTUs alone don't improve things unless Path MTU discovery is also used to prevent fragmentation. Path MTU discovery allows the most rapid opening of the sender's window size during slow start, but a number of round trips may still be required to open the window completely. (editorial) Section 2.2, second paragraph, first line has an extra "when" at the end of the line - needs to be removed. Section 2.2, seventh paragraph: Was: Not all causes of small windows are related to errors. For example, HTTP commonly closes TCP connections to indicate boundaries between requested resources. This means that these applications are constantly closing "trained" TCP connections and opening "untrained" TCP connections which will execute slow start, beginning with one or two segments. This is true even with HTTP1.1 in spite of its support for persistent connections. Suggested: Not all causes of small windows are related to errors. For example, HTTP/1.0 commonly closes TCP connections to indicate boundaries between requested resources. This means that these applications are constantly closing "trained" TCP connections and opening "untrained" TCP connections which will execute slow start, beginning with one or two segments. This can happen even with HTTP/1.1, if webmasters configure their HTTP/1.1 servers to close connections instead of waiting to see if the connection will be useful again Section 2.3, fourth paragraph: Was: In low-speed, high error-rate environments (for example, the wireless WAN environment), TCP windows are much smaller, and burst errors must be much longer in duration in order to damage multiple segments. Accordingly, the complexity of SACK may not be justified. Suggested: (delete this EXCELLENT paragraph, which was written so long ago that SACK was controversial...) Section 4.0, third paragraph: Was: Losses that take place on the ACK stream, especially while a TCP is learning network characteristics, can make the data stream quite bursty (resulting in losses on the data stream, as well). "Appropriate Byte Counting" [ALL99] has been proposed as a way of limiting this burstiness. Suggested: Losses that take place on the ACK stream, especially while a TCP is learning network characteristics, can make the data stream quite bursty (resulting in losses on the data stream, as well). Several ways of limiting this burstiness have been proposed, including "Appropriate Byte Counting" [ALL99], TCP transmit pacing at the sender, and ACK rate control within the network. Section 4.1, first paragraph: Was: The recommendations described in this document will aid TCPs in injecting packets into ERRORed connections as fast as possible, but no faster. The goal here is to optimize the use of available bandwidth in a way that does not destabilize the Internet. Suggested: The recommendations described in this document will aid TCPs in injecting packets into ERRORed connections as fast as possible without destabilizing the Internet, and so optimizing the use of available bandwidth. Appendix A, third paragraph: Was: Delayed dupacks makes very little assumptions about the TCP implementations. If, however, one assumes that the implementations support TCP timestamps, then other schemes are possible. For example, the Eifel algorithm [LK00] uses timestamps to eliminate the deleterious effect of a spurious timeout on TCP performance. Additionally, Eifel uses two of the currently unused bits in the TCP header and makes certain assumptions about the link-layer being able to treat flows that benefit from reliable service differently from real-time flows. Suggested: Delayed dupacks makes very little assumptions about the TCP implementations. If, however, one assumes that the implementations support TCP timestamps, then other schemes are possible. For example, the Eifel algorithm [LK00] uses timestamps to eliminate the deleterious effect of a spurious timeout on TCP performance. Appendix C, second paragraph: Was: This proposal is still at the experimental stage, but implementors may wish to follow this work, because the effect is that cwnd is opening more aggressively when ACKs are lost during the initial slow-start exchange, but this aggressiveness does not act to the detriment of other flows. Suggested: This proposal is still at the experimental stage, but implementors may wish to follow this work, because the effect is that the congestion window is opening more aggressively when ACKs are lost during the initial slow-start exchange, but this aggressiveness does not act to the detriment of other flows. Meta-comments: - I've gotten a couple of questions about whether the appendices are really necessary. My inclination is to leave them in, but I could be wrong. - I've gotten a couple of questions about using contractions in formal specifications. A quick content search says the contraction "don't" appears in RFCs from RFC 2 to RFC 2906, including 52 with Jon Postel's name on them, so I'm not sure this is a bad thing. Thanks to all who read this draft. Spencer From owner-pilc@lerc.nasa.gov Wed Sep 13 08:11:53 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 IAA05680 for ; Wed, 13 Sep 2000 08:11:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA27671 for pilc-outgoing; Wed, 13 Sep 2000 07:09: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 HAA27663 for ; Wed, 13 Sep 2000 07:09:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA20483; Wed, 13 Sep 2000 07:09:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020257; Wed, 13 Sep 00 07:08:56 -0400 Received: from esealnt409 (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id e8DB8sw02450 for ; Wed, 13 Sep 2000 13:08:54 +0200 (MEST) Received: FROM esealnt172.ericsson.se BY esealnt409 ; Mon Sep 11 12:46:08 2000 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Wed, 13 Sep 2000 13:00:59 +0200 Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D70107440A@esemont203.gbg.edt.ericsson.se> From: "Jan Kullander (ERV)" To: "'pilc@grc.nasa.gov'" Cc: "'Dawkins, Spencer'" Subject: RE: Updates for ERROR after WG last call Date: Wed, 13 Sep 2000 13:00:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >-----Original Message----- >From: Dawkins, Spencer [SMTP:Spencer.DAWKINS@fnc.fujitsu.com] >Sent: Tuesday, September 12, 2000 8:45 PM >To: 'PILC Mailing List' >Subject: Updates for ERROR after WG last call > >These are the changes that I'm looking at, after the comments received >during WG last call. > >Section 2.1, second bullet: > >Was: > > - During slow start, the sender increases its window in > units of segments. This is why it is important to use an > appropriately sized MTU - and less reliable link layers > often use smaller MTUs. > >Suggested: > > - Less-reliable link layers often use small link MTUs. This slows > the rate of increase in the sender's window size during slow > start, because the sender's window is increased in units of > segments. Small link MTUs alone don't improve things unless > Path MTU discovery is also used to prevent fragmentation. > Path MTU discovery allows the most rapid opening > of the sender's window size during slow start, but a number of > round trips may still be required to open the window completely. > [snip] It is an unfortunate property of TCP congestion control that a connection generally benefits more from larger MTUs even if it means that more correctly received data is needlessly retransmitted. In other words, the performance of a single TCP connection may benefit from a large MTU size regardless of fragmentation. (This can be perceived from the ADVICE draft formula: MSS 1 BW = 0.93 --- ------- RTT sqrt(p) where p is the packet loss rate. If we assume that p = MSS * BER (of the ERROR link) we see that BW is proportional to sqrt(MSS). All this is of course simplifications but it hold true for reasonable values.) So what conclusions are there? One is to advice link layer designers to consider the ADVICE formula and not only optimise link layer transmission without knowing the implications on TCP. Another is to point out that it pays to make the link reliable (according to the formula a doubled RTT is balanced by reduction on packet loss to 25% which should not be difficult to do better than). These are however advice for link designers and I do not know if this paper also addresses them (these issues are crucial so I wouldn't mind a repetition though). The conclusion from e2e point of view of the first two sentences of the suggested bullet is to NOT use PMTU discovery or put a lower limit to it. But that would be antisocial competition for resources. If this draft is intended for e2e designers, I suggest that the bullet is removed since I can only see implications in this direction from e2e point of view. /Jan Kullander From owner-pilc@lerc.nasa.gov Wed Sep 13 13:00:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12732 for ; Wed, 13 Sep 2000 13:00:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA13047 for pilc-outgoing; Wed, 13 Sep 2000 11:45:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA13004 for ; Wed, 13 Sep 2000 11:45:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA16582; Wed, 13 Sep 2000 11:45:48 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016291; Wed, 13 Sep 00 11:45:41 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13ZEjB-0006RU-00; Wed, 13 Sep 2000 16:45:37 +0100 Date: Wed, 13 Sep 2000 16:45:17 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Jan Kullander (ERV)" cc: "'pilc@grc.nasa.gov'" , "'Dawkins, Spencer'" Subject: RE: Updates for ERROR after WG last call In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D70107440A@esemont203.gbg.edt.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, 13 Sep 2000, Jan Kullander (ERV) wrote: > It is an unfortunate property of TCP congestion control that a > connection generally benefits more from larger MTUs even if it > means that more correctly received data is needlessly retransmitted. > In other words, the performance of a single TCP connection may > benefit from a large MTU size regardless of fragmentation. so you design a link to advertise a large MTU size, and to do implicit fragmentation and reassembly of submultiples of that size below the IP layer itself. (Hence >9000 bytes for SMDS, ATM, etc. - RFC1626. Worth sticking a pointer to this in somewhere.) > (This can be perceived from the ADVICE draft formula: > > MSS 1 > BW = 0.93 --- ------- > RTT sqrt(p) which doesn't look anything like e.g. equation 3.4 of [OKM96], not least because TCP throughput or usage is *not* bandwidth. I'd expect link designers to understand bandwidth to mean *their* link bandwidth (as Jan illustrates below), so this worries me. (Everywhere I look on http://www.psc.edu/networking/tcp_friendly.html I find different values for the constant; I'd just put k there and indicate a range for k, to emphasise that the models are rules of thumb rather than something that can be used rigidly or axiomatically. This isn't a trig formula; it depends on a large number of assumptions about behaviour subject to change, not on unchanging axioms.) > where p is the packet loss rate. I'd just like to point our here that packet != segment != unit of bandwidth. Dimensional analysis shows the formula's a rule of thumb. > If we assume that > > p = MSS * BER (of the ERROR link) > > we see that BW is proportional to sqrt(MSS). and what do you (and the draft) mean by BW? > All this is of course simplifications but it hold true for > reasonable values.) oversimplifications, I suspect. > So what conclusions are there? One is to advice link layer designers > to consider the ADVICE formula which might be why it's in the advice draft. I'm not convinced that's _that_ good an idea, though. A lot depends on what the link-level designers use the formula _for_. > and not only optimise link layer > transmission without knowing the implications on TCP. that much is good advice in general; very much the thrust of pilc. > Another is to > point out that it pays to make the link reliable (according to the > formula a doubled RTT is balanced by reduction on packet loss to 25% > which should not be difficult to do better than). That's making some assumptions about the applicability of and invariance of the formula. Note that BW in the formula is *not* the (fixed) link bandwidth, but TCP's use of it: its overall throughput (as opposed to goodput). Phrases like 'the bandwidth of a TCP connection' (in http://www.psc.edu/networking/papers/tcp_friendly.html) just confuse the issue. Lousy non-engineering jargon, if you ask me. Since throughput's not an invariant and depends on the other values, and the formula is merely giving an indication of TCP's use of available unlimited end-to-end capacity, I believe your use of the formula in that way is... well, unwarranted. You're jumping from an equation describing a _path_ to detailed _link_ design. If your argument was correct, then implementing a reliable service *under* TCP end-to-end would suddenly seem to be be a Good Thing. Which it isn't. (and the URL in [OKM96] in the advice draft and linked to from the TCP friendly website is no more. There's a copy at: http://citeseer.nj.nec.com/ott-stationary.html ) A doubled RTT suggests that you're considering some form of link ARQ (and that you're thinking about endhosts at each end of the link, rather than longer paths just using the link), and that the link time is tiny compared to the RTOs of the TCP connections using the link. Fine for a mobile cellular hop, not so good for geostationary satellite. You could get a reliable-enough-for-TCP link by just using better error control coding etc... the more I look at the formulae glibly quoted in the advice draft, the more I think those sections need some tweaking and an even stronger caveat detailing the differences between link and path. These formulae _will_ be misused if we're not careful. BW isn't even explicitly defined, which has to be an oversight. cheers, L. PGP From owner-pilc@lerc.nasa.gov Thu Sep 14 11:58:37 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17746 for ; Thu, 14 Sep 2000 11:58:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA26502 for pilc-outgoing; Thu, 14 Sep 2000 10:46:27 -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 KAA26490; Thu, 14 Sep 2000 10:46:23 -0400 (EDT) Message-Id: <200009141446.KAA26490@lombok-fi.lerc.nasa.gov> To: "Dawkins, Spencer" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: They're Coming to Take Me Away Date: Thu, 14 Sep 2000 10:46:23 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Spencer- I think most of the changes look good. I'd still love to see the tcp friendly equation in this document, much as it is in the LINK document. I.e., if the error rate is low enough for a given available bandwidth throughput is not impacted and you don't have to worry. But, my real comment is about... > Losses that take place on the ACK stream, especially while a > TCP is learning network characteristics, can make the data > stream quite bursty (resulting in losses on the data stream, as > well). Several ways of limiting this burstiness have been > proposed, including "Appropriate Byte Counting" [ALL99], TCP > transmit pacing at the sender, and ACK rate control within the > network. I still don't understand how ABC limits burstiness. I believe quite the opposite, actually. I threw the following slide up during the tsvwg meeting in Pittsburgh on the disadvantages of ABC: .Assuming $L~=~2~MSS$, we see increased burstiness: -Micro-burstiness increase: The number of data segments sent in response to an ACK is increased by 1~segment. -Macro-burstiness increase: During slow start \textit{cwnd} is currently increased by roughly 50\% per RTT (assuming delayed ACKs) whereas ABC will cause an increase of roughly 100\% per RTT. I agree that ABC can help mitigate the window growth problem that occurs when ACKs are lost (for whatever reason). However, it does so in a bursty fashion. And, I believe it is *more* bursty than the standard algorithm. I'd **really, really** like to see the above reworked in the ERROR document. (Or, be proven wrong...) allman --- http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Thu Sep 14 13:54: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 NAA19636 for ; Thu, 14 Sep 2000 13:54:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA17999 for pilc-outgoing; Thu, 14 Sep 2000 12:48:46 -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 MAA17954 for ; Thu, 14 Sep 2000 12:48:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA29630; Thu, 14 Sep 2000 12:48:42 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028181; Thu, 14 Sep 00 12:48:05 -0400 Received: from esealnt406 (esealnt406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e8EGm3t29564 for ; Thu, 14 Sep 2000 18:48:03 +0200 (MEST) Received: FROM esealnt172.ericsson.se BY esealnt406 ; Thu Sep 14 18:47:56 2000 +0200 Received: by esealnt172 with Internet Mail Service (5.5.2651.58) id ; Thu, 14 Sep 2000 18:48:02 +0200 Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D70107440B@esemont203.gbg.edt.ericsson.se> From: "Jan Kullander (ERV)" To: "'Lloyd Wood'" Cc: "'pilc@grc.nasa.gov'" Subject: RE: Updates for ERROR after WG last call Date: Thu, 14 Sep 2000 17:33:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > -----Original Message----- From: Lloyd Wood [SMTP:l.wood@eim.surrey.ac.uk] > >On Wed, 13 Sep 2000, Jan Kullander (ERV) wrote: > >> It is an unfortunate property of TCP congestion control that a >> connection generally benefits more from larger MTUs even if it >> means that more correctly received data is needlessly retransmitted. >> In other words, the performance of a single TCP connection may >> benefit from a large MTU size regardless of fragmentation. > >so you design a link to advertise a large MTU size, and to do implicit >fragmentation and reassembly of submultiples of that size below the IP >layer itself. (Hence >9000 bytes for SMDS, ATM, etc. - RFC1626. Worth >sticking a pointer to this in somewhere.) > > >> (This can be perceived from the ADVICE draft formula: >> >> MSS 1 >> BW = 0.93 --- ------- >> RTT sqrt(p) > >which doesn't look anything like e.g. equation 3.4 of [OKM96], not >least because TCP throughput or usage is *not* bandwidth. I'd expect >link designers to understand bandwidth to mean *their* link >bandwidth (as Jan illustrates below), so this worries me. Do I? My English must be stinking. > >(Everywhere I look on > http://www.psc.edu/networking/tcp_friendly.html > I find different values for the constant; I'd just put k there and > indicate a range for k, to emphasise that the models are rules of > thumb rather than something that can be used rigidly or > axiomatically. This isn't a trig formula; it depends on a large > number of assumptions about behaviour subject to change, not on > unchanging axioms.) > > >> where p is the packet loss rate. > >I'd just like to point our here that packet != segment != unit of >bandwidth. Dimensional analysis shows the formula's a rule of thumb. > > >> If we assume that >> >> p = MSS * BER (of the ERROR link) >> >> we see that BW is proportional to sqrt(MSS). > >and what do you (and the draft) mean by BW? > > >> All this is of course simplifications but it hold true for >> reasonable values.) > >oversimplifications, I suspect. > > >> So what conclusions are there? One is to advice link layer designers >> to consider the ADVICE formula > >which might be why it's in the advice draft. I'm not convinced that's >_that_ good an idea, though. A lot depends on what the link-level >designers use the formula _for_. > > >> and not only optimise link layer >> transmission without knowing the implications on TCP. > >that much is good advice in general; very much the thrust of pilc. > > >> Another is to >> point out that it pays to make the link reliable (according to the >> formula a doubled RTT is balanced by reduction on packet loss to 25% >> which should not be difficult to do better than). > >That's making some assumptions about the applicability of and >invariance of the formula. Note that BW in the formula is *not* the >(fixed) link bandwidth, but TCP's use of it: its overall throughput >(as opposed to goodput). I make no assumptions of the applicability of the formula, I just point out that a reduction to a quarter of the packet loss is worth a doubled RTT according to the formula. If you do accept the formula as rule of thumb you may see this as a distinct indication that it is likely that even a modest improvement of link reliability is worth quite some delay (from TCP connection point of view). > >Phrases like 'the bandwidth of a TCP connection' (in >http://www.psc.edu/networking/papers/tcp_friendly.html) just confuse >the issue. Lousy non-engineering jargon, if you ask me. > >Since throughput's not an invariant and depends on the other values, >and the formula is merely giving an indication of TCP's use of >available unlimited end-to-end capacity, I believe your use of the >formula in that way is... well, unwarranted. You're jumping from an >equation describing a _path_ to detailed _link_ design. If your >argument was correct, then implementing a reliable service *under* TCP >end-to-end would suddenly seem to be be a Good Thing. Which it isn't. No, it would not be a good idea to implement an e2e reliable service under TCP since it would either nullify the congestion control in TCP or reinvent it (and then we wouldn't gain anything). To implement a reliable service over a link on the other hand might be beneficial for TCP, especially if that service didn't have to implement any congestion control (since it knew available link capacity anyway). (It would of course have to drop packets exceeding link capacity if you call that congestion control). > >(and the URL in [OKM96] in the advice draft and linked to from the >TCP friendly website is no more. There's a copy at: >http://citeseer.nj.nec.com/ott-stationary.html ) > >A doubled RTT suggests that you're considering some form of link ARQ >(and that you're thinking about endhosts at each end of the link, >rather than longer paths just using the link), and that the link time >is tiny compared to the RTOs of the TCP connections using the link. You are making a lot of assumptions, why? To make a conversation? > >Fine for a mobile cellular hop, not so good for geostationary >satellite. You could get a reliable-enough-for-TCP link by just using >better error control coding etc... It might indeed make sense even to implement a reliable service over a satellite if that service knew the available link bandwidth! Then a lost packet could be retransmitted without the multiplicative decrease. Now I do not claim that this would be to prefer to "better error control etc..." and I dot even claim that it would be a good idea under all circumstances. It would e.g. be difficult foresee the penalty of the prolonged RTO if other parts of the TCP path were lossy or congested. Still, the formula suggests that the penalty might be worth while... (And if spurious retransmissions would prove to be a problem (which I doubt) a semi- reliable link service with limited ARQ would probably still be worth while). > >the more I look at the formulae glibly quoted in the advice draft, the >more I think those sections need some tweaking and an even stronger >caveat detailing the differences between link and path. These formulae >_will_ be misused if we're not careful. > >BW isn't even explicitly defined, which has to be an oversight. > >cheers, > >L. > >PGP Regards Jan Kullander From owner-pilc@lerc.nasa.gov Thu Sep 14 14:24: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 OAA20114 for ; Thu, 14 Sep 2000 14:24:53 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA24967 for pilc-outgoing; Thu, 14 Sep 2000 13:23:13 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA24927 for ; Thu, 14 Sep 2000 13:23:10 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA01887; Thu, 14 Sep 2000 13:23:08 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000068; Thu, 14 Sep 00 13:22:08 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13Zchu-0000Xy-00; Thu, 14 Sep 2000 18:21:54 +0100 Date: Thu, 14 Sep 2000 18:21:44 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: "Jan Kullander (ERV)" cc: "'pilc@grc.nasa.gov'" Subject: RE: Updates for ERROR after WG last call In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D70107440B@esemont203.gbg.edt.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 Thu, 14 Sep 2000, Jan Kullander (ERV) wrote: > I make no assumptions of the applicability of the formula, You're assuming that the formula is applicable in that way. > I just point out > that a reduction to a quarter of the packet loss is worth a doubled RTT > according to the formula. You do not control packet loss of the entire TCP path. You do not control RTT of the entire TCP path. TCP throughput depends on the entire path. The formula does not reflect slowstart well, either; it simply gives an upper bound on performance. > No, it would not be a good idea to implement an e2e reliable service under > TCP since it would either nullify the congestion control in TCP or reinvent > it (and then we wouldn't gain anything). but you're effectively using the formula to advocate just that, since with an e2e reliable service under TCP, then TCP would see a longer RTT but less packet loss, allowing TCP's throughput to remain the same. (Which, in reality, it won't.) This is something of an indication that the formula may not actually be applicable, yes? > Still, the formula suggests that the penalty might be worth > while... an approximation is no substitute for reality. remember, you're assuming that the TCP throughput is at its upper bound in order to make the packet loss/RTT tradeoff feasible, whereas it's far more likely to be somewhere else in the continuum. (We need another formula that says how often TCP within 5% of its predicted upper bound, to give us a degree of confidence in the bound formula...) > >the more I look at the formulae glibly quoted in the advice draft, the > >more I think those sections need some tweaking and an even stronger > >caveat detailing the differences between link and path. These formulae > >_will_ be misused if we're not careful. > > > >BW isn't even explicitly defined, which has to be an oversight. L. PGP From owner-pilc@lerc.nasa.gov Thu Sep 14 14:32:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20214 for ; Thu, 14 Sep 2000 14:32:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21160 for pilc-outgoing; Thu, 14 Sep 2000 13:07: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 NAA21116 for ; Thu, 14 Sep 2000 13:06:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA03761; Thu, 14 Sep 2000 13:06:53 -0400 Received: from out4.prserv.net(32.97.166.34) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003187; Thu, 14 Sep 00 13:06:36 -0400 Received: from attglobal.net ([32.100.71.211]) by prserv.net (out4) with SMTP id <20000914170633239010e4qce>; Thu, 14 Sep 2000 17:06:33 +0000 Message-ID: <39C105E7.DBE85684@attglobal.net> Date: Thu, 14 Sep 2000 10:07:51 -0700 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call References: <200009141446.KAA26490@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 Mark, what is "low enough" and "given available" speed? In my experience, <1% pkt loss can have a 20% throughput hit for non SACK TCPs and a still- noticeable affect on better ones. We need to start weaning ourselves of the misuse of "bandwidth", by the way. It makes networking folks look like they don't understand signal theory and things like modems and how they work. Alex Mark Allman wrote: > > Spencer- > > I think most of the changes look good. I'd still love to see the > tcp friendly equation in this document, much as it is in the LINK > document. I.e., if the error rate is low enough for a given > available bandwidth throughput is not impacted and you don't have to > worry. > > But, my real comment is about... > > > Losses that take place on the ACK stream, especially while a > > TCP is learning network characteristics, can make the data > > stream quite bursty (resulting in losses on the data stream, as > > well). Several ways of limiting this burstiness have been > > proposed, including "Appropriate Byte Counting" [ALL99], TCP > > transmit pacing at the sender, and ACK rate control within the > > network. > > I still don't understand how ABC limits burstiness. I believe quite > the opposite, actually. I threw the following slide up during the > tsvwg meeting in Pittsburgh on the disadvantages of ABC: > > .Assuming $L~=~2~MSS$, we see increased burstiness: > -Micro-burstiness increase: The number of data segments sent in > response to an ACK is increased by 1~segment. > -Macro-burstiness increase: During slow start \textit{cwnd} is > currently increased by roughly 50\% per RTT (assuming delayed > ACKs) whereas ABC will cause an increase of roughly 100\% per > RTT. > > I agree that ABC can help mitigate the window growth problem that > occurs when ACKs are lost (for whatever reason). However, it does > so in a bursty fashion. And, I believe it is *more* bursty than the > standard algorithm. > > I'd **really, really** like to see the above reworked in the ERROR > document. (Or, be proven wrong...) > > allman > > --- > http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Thu Sep 14 14:41: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 OAA20335 for ; Thu, 14 Sep 2000 14:41:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA25505 for pilc-outgoing; Thu, 14 Sep 2000 13:26: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 NAA25470 for ; Thu, 14 Sep 2000 13:26:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA07370; Thu, 14 Sep 2000 13:26:07 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006440; Thu, 14 Sep 00 13:25:42 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13ZclN-0000Zk-00; Thu, 14 Sep 2000 18:25:29 +0100 Date: Thu, 14 Sep 2000 18:25:26 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Cannara cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call In-Reply-To: <39C105E7.DBE85684@attglobal.net> 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 Thu, 14 Sep 2000, Cannara wrote: > We need to start weaning ourselves of the misuse of "bandwidth", by the way. when people say 'bandwidth', they're generally talking about link speed, or about throughput, or about the maximum link capacity required. I see this month's IEEE Spectrum Sep 2000, the QoS article on page 57, gets in a grumble about this term, too. L. PGP From owner-pilc@lerc.nasa.gov Thu Sep 14 17:45: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 RAA26000 for ; Thu, 14 Sep 2000 17:45:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA29010 for pilc-outgoing; Thu, 14 Sep 2000 16:36: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 QAA28975 for ; Thu, 14 Sep 2000 16:36:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA03690; Thu, 14 Sep 2000 16:36:07 -0400 Received: from out4.prserv.net(32.97.166.34) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002713; Thu, 14 Sep 00 16:35:10 -0400 Received: from attglobal.net ([32.100.71.211]) by prserv.net (out4) with SMTP id <2000091420345923900hdg0fe>; Thu, 14 Sep 2000 20:35:00 +0000 Message-ID: <39C136C1.3EDE3BE1@attglobal.net> Date: Thu, 14 Sep 2000 13:36:17 -0700 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: L.Wood@eim.surrey.ac.uk CC: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Yes, and it's doubly wrong to use "bandwidth" as a proxy for baud, bitrate, speed, capacity or throughput, as you say. It does a disservice to students and others new to networking. The "bandwidth" of an ordinary phone line may be 4kHz, but the imagination of modem engineers has improved the usable "bitrate" of the link from 110b/s to beyond 56000, via canny use of symbol definitions and signal theory. So, I hope we can expunge the word from the documents discussed and strive for correct terms. Alex Lloyd Wood wrote: > > On Thu, 14 Sep 2000, Cannara wrote: > > > We need to start weaning ourselves of the misuse of "bandwidth", by the way. > > when people say 'bandwidth', they're generally talking about link > speed, or about throughput, or about the maximum link capacity > required. > > I see this month's IEEE Spectrum Sep 2000, the QoS article on page 57, > gets in a grumble about this term, too. > > L. > > PGP From owner-pilc@lerc.nasa.gov Fri Sep 15 00:04:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01867 for ; Fri, 15 Sep 2000 00:04:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA25126 for pilc-outgoing; Thu, 14 Sep 2000 22:55:46 -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 WAA25102 for ; Thu, 14 Sep 2000 22:55:44 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA06583; Thu, 14 Sep 2000 22:55:43 -0400 Received: from tc107.bbn.com(128.33.238.107) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006485; Thu, 14 Sep 00 22:55:10 -0400 Received: from lawyers.grc.nasa.gov (IDENT:mallman@localhost [127.0.0.1]) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id WAA16882; Thu, 14 Sep 2000 22:41:27 -0400 Message-Id: <200009150241.WAA16882@lawyers.grc.nasa.gov> To: cannara@attglobal.net From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: They're Coming to Take Me Away Date: Thu, 14 Sep 2000 22:41:27 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Mark, what is "low enough" and "given available" speed? In my > experience, <1% pkt loss can have a 20% throughput hit for non > SACK TCPs and a still- noticeable affect on better ones. It all depends. In general what I would like to see is something that says more concretely what kinds of error rates matter to TCP and what sorts of error rates do not. I think we can agree that one packet getting hosed on my lab's ethernet every day does not make my network an ERRORed environment. This one packet error may well hurt throughput on a transfer, but it's only one transfer a day and so I really can't complain. That is very clear (I hope!), but some other networks with lower speeds and higher error rates are not nearly as clear cut. So, what I'm saying is that if you plug a packet loss rate into the TCP friendly equation it gives you a certain number of bytes/second that a TCP should be able to obtain (also given the RTT and packet size). If this number of bytes/second is greater than the number of bytes/second supported by the link supporting the least number of bytes/second in your network path you should be OK (and, in many cases you know which link this is because you're directly connected to it). If the equation predicts a number of bytes/second less than supported by the bottleneck link the error rate is going to have an impact on performance. This is not perfect, but I believe it to be a good first cut at figuring out whether the noise on your link is really going to have an impact on performance. allman From owner-pilc@lerc.nasa.gov Fri Sep 15 01:14:03 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03652 for ; Fri, 15 Sep 2000 01:14:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA29018 for pilc-outgoing; Fri, 15 Sep 2000 00:17: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 AAA28999 for ; Fri, 15 Sep 2000 00:17:04 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA20699; Fri, 15 Sep 2000 00:17:02 -0400 Received: from out5.prserv.net(32.97.166.35) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020561; Fri, 15 Sep 00 00:16:16 -0400 Received: from attglobal.net ([32.100.71.251]) by prserv.net (out5) with SMTP id <20000915041610205037r60ee>; Fri, 15 Sep 2000 04:16:11 +0000 Message-ID: <39C1A2D7.8A7AA55B@attglobal.net> Date: Thu, 14 Sep 2000 21:17:27 -0700 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call References: <200009150241.WAA16882@lawyers.grc.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 Ok Mark, got it. So, we need also to include how "a TCP" works and how its default parameters may be changed. Certainly there's a big, easily observed difference between older and newer (e.g., SACK) TCPs -- order of magnitude differences in delays to get good data through (Throughput). So, the equation needs some TCP parameters and there needs to be a way for the user to decide how to set them, including the likely possibility for end-end mismatch in version. This would qualify as a "first cut", in my opinion. Alex Mark Allman wrote: > > > Mark, what is "low enough" and "given available" speed? In my > > experience, <1% pkt loss can have a 20% throughput hit for non > > SACK TCPs and a still- noticeable affect on better ones. > > It all depends. > > In general what I would like to see is something that says more > concretely what kinds of error rates matter to TCP and what sorts of > error rates do not. I think we can agree that one packet getting > hosed on my lab's ethernet every day does not make my network an > ERRORed environment. This one packet error may well hurt throughput > on a transfer, but it's only one transfer a day and so I really > can't complain. That is very clear (I hope!), but some other > networks with lower speeds and higher error rates are not nearly as > clear cut. > > So, what I'm saying is that if you plug a packet loss rate into the > TCP friendly equation it gives you a certain number of bytes/second > that a TCP should be able to obtain (also given the RTT and packet > size). If this number of bytes/second is greater than the number of > bytes/second supported by the link supporting the least number of > bytes/second in your network path you should be OK (and, in many > cases you know which link this is because you're directly connected > to it). If the equation predicts a number of bytes/second less than > supported by the bottleneck link the error rate is going to have an > impact on performance. > > This is not perfect, but I believe it to be a good first cut at > figuring out whether the noise on your link is really going to have > an impact on performance. > > allman From owner-pilc@lerc.nasa.gov Fri Sep 15 11:09: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 LAA20732 for ; Fri, 15 Sep 2000 11:09:37 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA28168 for pilc-outgoing; Fri, 15 Sep 2000 08:40:47 -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 IAA28164; Fri, 15 Sep 2000 08:40:45 -0400 (EDT) Message-Id: <200009151240.IAA28164@lombok-fi.lerc.nasa.gov> To: cannara@attglobal.net From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Freeze-Frame Date: Fri, 15 Sep 2000 08:40:45 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Certainly there's a big, easily observed difference between older > and newer (e.g., SACK) TCPs -- order of magnitude differences in > delays to get good data through (Throughput). I agree. > So, the equation needs some TCP parameters and there needs to be a > way for the user to decide how to set them, including the likely > possibility for end-end mismatch in version. This would qualify > as a "first cut", in my opinion. I disagree. I don't think we need to make this all that complicated. I think it is enough to put the appropriate caveats around the current TCP friendly equation. It is true that the equation does not model every TCP. But it is a decent projection of TCP as it is currently being deployed and will be even stronger in the future as SACK-based stacks become even more prevelant (which is the trend). Is there a better way to give folks an idea about whether they should consider their link ERRORed or not? allman From owner-pilc@lerc.nasa.gov Fri Sep 15 21:04: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 VAA26487 for ; Fri, 15 Sep 2000 21:04:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA27857 for pilc-outgoing; Fri, 15 Sep 2000 16:10:23 -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 QAA27826 for ; Fri, 15 Sep 2000 16:10:20 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA14333; Fri, 15 Sep 2000 16:10:20 -0400 Received: from out1.prserv.net(32.97.166.31) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014246; Fri, 15 Sep 00 16:09:51 -0400 Received: from attglobal.net ([32.102.91.140]) by prserv.net (out1) with SMTP id <20000915180519252020jegje>; Fri, 15 Sep 2000 18:05:19 +0000 Message-ID: <39C260F5.AD2E9996@attglobal.net> Date: Fri, 15 Sep 2000 10:48:37 -0700 From: Cannara Reply-To: cannara@attglobal.net X-Mailer: Mozilla 4.6 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call References: <200009151240.IAA28164@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 Mark, I see what you're trying to accomplish and maybe the approach should be to describe two possibilities: a) newer transports that handle error loss reasonably; and b) older TCPs that create large delays in retransmission. You needn't parameterize the quations beyond this. Then emphasis should be on what error rate is then 'bad' for each of these two situations, since there's not one answer, even within a factor of 5. Alex Mark Allman wrote: > > > Certainly there's a big, easily observed difference between older > > and newer (e.g., SACK) TCPs -- order of magnitude differences in > > delays to get good data through (Throughput). > > I agree. > > > So, the equation needs some TCP parameters and there needs to be a > > way for the user to decide how to set them, including the likely > > possibility for end-end mismatch in version. This would qualify > > as a "first cut", in my opinion. > > I disagree. I don't think we need to make this all that > complicated. I think it is enough to put the appropriate caveats > around the current TCP friendly equation. It is true that the > equation does not model every TCP. But it is a decent projection of > TCP as it is currently being deployed and will be even stronger in > the future as SACK-based stacks become even more prevelant (which is > the trend). > > Is there a better way to give folks an idea about whether they > should consider their link ERRORed or not? > > allman From owner-pilc@lerc.nasa.gov Sun Sep 17 09:21:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08728 for ; Sun, 17 Sep 2000 09:21:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA01806 for pilc-outgoing; Sun, 17 Sep 2000 07:53: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 HAA01802; Sun, 17 Sep 2000 07:53:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA24184; Sun, 17 Sep 2000 07:53:16 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024155; Sun, 17 Sep 00 07:52:44 -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 e8HBqhZ19932; Sun, 17 Sep 2000 13:52:43 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id NAA21778; Sun, 17 Sep 2000 13:52:26 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000916160315.00b2a870@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Sep 2000 13:48:48 +0200 To: mallman@grc.nasa.gov From: Reiner Ludwig Subject: Re: Updates for ERROR after WG last call Cc: pilc@grc.nasa.gov In-Reply-To: <200009151240.IAA28164@lombok-fi.lerc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 08:40 15.09.00 -0400, Mark Allman wrote: >Is there a better way to give folks an idea about whether they >should consider their link ERRORed or not? I tried to formulate such a rule of thumb in the last three paragraphs of section 2.3.3 in my thesis: http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html This might serve as a basis for discussing this further. ///Reiner From owner-pilc@lerc.nasa.gov Mon Sep 18 05:31: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 FAA00387 for ; Mon, 18 Sep 2000 05:31:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA12497 for pilc-outgoing; Mon, 18 Sep 2000 04:30:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA12484 for ; Mon, 18 Sep 2000 04:30:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id EAA08600; Mon, 18 Sep 2000 04:30:28 -0400 Received: from shell9.ba.best.com(206.184.139.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008580; Mon, 18 Sep 00 04:30:24 -0400 Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id BAA15024; Mon, 18 Sep 2000 01:29:57 -0700 (PDT) Date: Mon, 18 Sep 2000 01:29:57 -0700 (PDT) From: "James P. Salsman" Message-Id: <200009180829.BAA15024@shell9.ba.best.com> To: afalk@PanAmSat.com, mankin@east.isi.edu, paf@cisco.com, rludwig@huginn.CS.Berkeley.EDU, sob@harvard.edu, spencer_dawkins@fnc.fujitsu.com Subject: Re: Mobile Multimedia Messaging Service Cc: discuss@apps.ietf.org, ietf-mmms@IMC.ORG, ietf@ietf.org, pilc@grc.nasa.gov In-Reply-To: Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Patrik, Thank you for your reply: >>... guidelines for TCP operation during >> indefinite wireless link downtime.... > > I think this must be syncronized with the work of the PILC wg. See > http://www.ietf.org/html.charters/pilc-charter.html Yes, the next document milestone from PLIC seems to have been delayed: Done Draft on asymmetric network paths. Oct 99 Draft of TCP Over Wireless document to the IESG as BCP Nov 99 Document on low bandwidth links to IESG for publication as BCP. Does anyone know who is supposed to be working on the PLIC Wireless document? The closest I could find was: http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/index.html Cheers, James From owner-pilc@lerc.nasa.gov Mon Sep 18 06:38:54 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 GAA01420 for ; Mon, 18 Sep 2000 06:38:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA16768 for pilc-outgoing; Mon, 18 Sep 2000 05:48:37 -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 FAA16744; Mon, 18 Sep 2000 05:48:33 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA16514; Mon, 18 Sep 2000 05:48:32 -0400 Received: from shell9.ba.best.com(206.184.139.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016475; Mon, 18 Sep 00 05:48:25 -0400 Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id CAA29716; Mon, 18 Sep 2000 02:48:08 -0700 (PDT) Date: Mon, 18 Sep 2000 02:48:08 -0700 (PDT) From: "James P. Salsman" Message-Id: <200009180948.CAA29716@shell9.ba.best.com> To: aaron@PanAmSat.com, jgriner@grc.nasa.gov, pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Cc: discuss@apps.ietf.org, ietf-mmms@IMC.ORG, ietf@ietf.org Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Here are some questions about the plic minutes: http://pilc.grc.nasa.gov/pilc/list/archive/0967.html > TCP over Wireless draft. The working group charter specifies that > PILC will produce a 'TCP over Wireless' RFC that is a meta list of > the existing PILC recommendations. This was reported in Adelaide as > being completed in October 1999 because Aaron had confused it with > the LTN draft. Actually, it requires some work. Gabe Montenegro has > volunteered to sync up with the WAP forum to see if we can build > this document on a work in progress that already exists in that > body. The document should be only 3 or 4 pages long and should go to > wg last call by January 2001. Gabe noted that there is currently no > buy in by the WAP forum as yet, he will attend a forum meeting in > September and try to resolve. Several members of WAP were in the > room and volunteered to assist if needed. Is this WAP "work in progress" available for public inspection and review? If not, would someone who can see it please abstract it and post (anonymously if need be) please? Does any WAP product use TCP at all? > Discussion on DoCoMo draft (draft-inamura-docomo-00.txt) http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt > Aaron noted that DoCoMo would like to publish this as informational > RFC, but we don't want to get in a mode of publishing RFCs each time > someone does this and requested input from the group. I would certainly support doing anything that would encourage DoCoMo to use end-to-end Internet protocols, and if they are as close as that draft suggests, publishing it as an Information RFC might help them provide TCP application services more easily. > A speaker noted that the recommendations are pretty generic and > suggested the working group use this as a starting point for the TCP > over wireless document, or as an appendix to this document. Aaron > suggested it might be necessary to take the simulation results out > in order to use this document for the TCP over wireless > document. Another speaker suggested using path MTU discovery instead > of fixing it at 1500. Question: Maybe your tcp stack in the Opnet > simulator is not the best TCP. Have you run this on real stacks, > rather than on a simulator. Imaura - yes they have, but no > published results. > > Aaron noted that another alternative was that the DoCoMo would be > sent forth as informational, and would not be a recommendation. Tim > Shepard asked why would one want to disseminate this information? > Doesn't seem to make sense to have multiples of TCP/some link > technology. Is this advice on how to tune TCP for the handset? > Response from author: yes. > > Comment: This shows that tcp stack works over wireless error prone links. > > Comment: Doesn't think these results are any different from what a > modern TCP stack does anyway. I think the TCP parameters and resulting behavior might be more different than typical TCP stacks than whoever made that comment might think. There seems to be a lack of understanding about the parameters involved, and most if not all of the important ones are at least touched on in the DoCoMo I-D and the documents it cites. > Gabe: This is similar to what was done in ecn document What is the ecn document? > Question: What bandwidth was used in the simulations? > Imaura: 384kbs > Comment: Doesn't think this is realistic, since this is only the > rate if you are the only one in the cell. WAP is designed > to use slower links. WAP is designed as if Moore's Law didn't exist. > Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) http://search.ietf.org/internet-drafts/draft-magret-pilc-lltcp-00.txt > Comment: this is probably not a good idea -- leads to ICMP flooding. Is there any evidence to back this comment up? It seems that ICMP traffic is specifically addressed by Magret and Yang. > Also, if there is a long outage you do want to go through slow start > again, because the network has changed. There are better link level > solutions to this problem. Like what? Thanks. Cheers, James From owner-pilc@lerc.nasa.gov Mon Sep 18 10:21: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 KAA08510 for ; Mon, 18 Sep 2000 10:21:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA14132 for pilc-outgoing; Mon, 18 Sep 2000 09:08:43 -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 JAA14128; Mon, 18 Sep 2000 09:08:40 -0400 (EDT) Message-Id: <200009181308.JAA14128@lombok-fi.lerc.nasa.gov> To: cannara@attglobal.net From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Jailhouse Rock Date: Mon, 18 Sep 2000 09:08:40 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > Mark, I see what you're trying to accomplish and maybe the > approach should be to describe two possibilities: a) newer > transports that handle error loss reasonably; and b) older TCPs > that create large delays in retransmission. You needn't > parameterize the quations beyond this. Exactly what I meant. Give the equation and mention the caveats. That is as good as we can do (in a general context), I think. allman From owner-pilc@lerc.nasa.gov Mon Sep 18 12:16:12 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 MAA13186 for ; Mon, 18 Sep 2000 12:16:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06062 for pilc-outgoing; Mon, 18 Sep 2000 10:59:45 -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 KAA05988; Mon, 18 Sep 2000 10:59:39 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA11378; Mon, 18 Sep 2000 10:59:38 -0400 Received: from fe5.southeast.rr.com(24.93.67.52) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010547; Mon, 18 Sep 00 10:59:12 -0400 Received: from v3f6b5 ([24.25.25.53]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.357.35); Mon, 18 Sep 2000 10:58:02 -0400 From: "Injong Rhee" To: , Cc: "'PILC Mailing List'" Subject: RE: Updates for ERROR after WG last call Date: Mon, 18 Sep 2000 10:55:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009181308.JAA14128@lombok-fi.lerc.nasa.gov> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Well there is an alternative. Please check our my TEAR page: http://www.csc.ncsu.edu/faculty/rhee/export/tear_page/ We found that equation-based flow control does not work very well when the amount of bw is low. This is because the window is too small to measure any accurate loss rate. -----Original Message----- From: owner-pilc@lerc.nasa.gov [mailto:owner-pilc@lerc.nasa.gov]On Behalf Of Mark Allman Sent: Monday, September 18, 2000 6:09 AM To: cannara@attglobal.net Cc: 'PILC Mailing List' Subject: Re: Updates for ERROR after WG last call > Mark, I see what you're trying to accomplish and maybe the > approach should be to describe two possibilities: a) newer > transports that handle error loss reasonably; and b) older TCPs > that create large delays in retransmission. You needn't > parameterize the quations beyond this. Exactly what I meant. Give the equation and mention the caveats. That is as good as we can do (in a general context), I think. allman From owner-pilc@lerc.nasa.gov Mon Sep 18 13:04: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 NAA14879 for ; Mon, 18 Sep 2000 13:04:25 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA16089 for pilc-outgoing; Mon, 18 Sep 2000 11:44:17 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA16057 for ; Mon, 18 Sep 2000 11:44:13 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA25748; Mon, 18 Sep 2000 11:44:11 -0400 Received: from fortress.fnc.fujitsu.com(204.253.82.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025549; Mon, 18 Sep 00 11:44:06 -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 KAA26878 for ; Mon, 18 Sep 2000 10:44:03 -0500 (CDT) Received: by rchsemx2.fnc.fujitsu.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Sep 2000 10:44:05 -0500 Message-ID: From: "Dawkins, Spencer" To: "'PILC Mailing List'" Subject: RE: Updates for ERROR after WG last call Date: Mon, 18 Sep 2000 10:43:44 -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 Mark - I agree about including the tcp friendly equation in ERROR, and I'll try to steal the right words from LINK, where we've already discussed it, before submitting the IESG last call version of ERROR. And this is something I agreed to do a long time ago, before aborting the transfer! But my real comment is about Appropriate Byte Counting. I've changed mail systems since we had this conversation, but I believe that the paragraph you're looking at dates from an early conversation we had about ABC, that wasn't comparing ABC to standard TCP, but to previous flavors of byte counting like "limited byte counting", which I remember you characterizing as "slightly too aggressive". So I'm pretty sure the text that's giving you heartburn may be taking this conversation out of context. I believe the most recent conversation we had about ABC was that ABC helped to deal with application protocols like SMTP, that follow a couple of short packet exchanges ("enter userid", "enter password") with full-length packets as actual transfers start to take place - so that a standard TCP implementation would be happily thinking "well, I could send two (short) packets, so let's crank the window"). Does this sound familiar to you? If so, I need to rework this paragraph! Spencer > -----Original Message----- > From: Mark Allman [SMTP:mallman@grc.nasa.gov] > Sent: Thursday, September 14, 2000 9:46 AM > To: Dawkins, Spencer > Cc: 'PILC Mailing List' > Subject: Re: Updates for ERROR after WG last call > > > Spencer- > > I think most of the changes look good. I'd still love to see the > tcp friendly equation in this document, much as it is in the LINK > document. I.e., if the error rate is low enough for a given > available bandwidth throughput is not impacted and you don't have to > worry. > > But, my real comment is about... > > > Losses that take place on the ACK stream, especially while a > > TCP is learning network characteristics, can make the data > > stream quite bursty (resulting in losses on the data stream, as > > well). Several ways of limiting this burstiness have been > > proposed, including "Appropriate Byte Counting" [ALL99], TCP > > transmit pacing at the sender, and ACK rate control within the > > network. > > I still don't understand how ABC limits burstiness. I believe quite > the opposite, actually. I threw the following slide up during the > tsvwg meeting in Pittsburgh on the disadvantages of ABC: > > .Assuming $L~=~2~MSS$, we see increased burstiness: > -Micro-burstiness increase: The number of data segments sent in > response to an ACK is increased by 1~segment. > -Macro-burstiness increase: During slow start \textit{cwnd} is > currently increased by roughly 50\% per RTT (assuming delayed > ACKs) whereas ABC will cause an increase of roughly 100\% per > RTT. > > I agree that ABC can help mitigate the window growth problem that > occurs when ACKs are lost (for whatever reason). However, it does > so in a bursty fashion. And, I believe it is *more* bursty than the > standard algorithm. > > I'd **really, really** like to see the above reworked in the ERROR > document. (Or, be proven wrong...) > > allman > > > --- > http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Mon Sep 18 13:36: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 NAA15651 for ; Mon, 18 Sep 2000 13:36:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA22604 for pilc-outgoing; Mon, 18 Sep 2000 12:16:13 -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 MAA22578; Mon, 18 Sep 2000 12:16:10 -0400 (EDT) Message-Id: <200009181616.MAA22578@lombok-fi.lerc.nasa.gov> To: "Dawkins, Spencer" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Jailhouse Rock Date: Mon, 18 Sep 2000 12:16:10 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > I believe the most recent conversation we had about ABC was that > ABC helped to deal with application protocols like SMTP, that > follow a couple of short packet exchanges ("enter userid", "enter > password") with full-length packets as actual transfers start to > take place - so that a standard TCP implementation would be > happily thinking "well, I could send two (short) packets, so let's > crank the window"). > > Does this sound familiar to you? If so, I need to rework this > paragraph! Ah, yes! Thanks for the kick. Obviously in that case ABC does, in fact, limit bursts as it only allows you to raise cwnd based on the actual number of bytes transmitted (i.e., the validated network capacity). The paragraph should be changed to make this a little more clear, though. Thanks! allman From owner-pilc@lerc.nasa.gov Mon Sep 18 14:34: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 OAA16999 for ; Mon, 18 Sep 2000 14:34:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12965 for pilc-outgoing; Mon, 18 Sep 2000 13:29:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA12925 for ; Mon, 18 Sep 2000 13:29:51 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA15372; Mon, 18 Sep 2000 13:29:49 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014339; Mon, 18 Sep 00 13:29:08 -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 e8IHT6Z16741; Mon, 18 Sep 2000 19:29:06 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (ki-17.kiedt.ericsson.se [147.214.100.17]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id TAA04523; Mon, 18 Sep 2000 19:28:56 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000918190325.00bb1d10@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Sep 2000 19:24:55 +0200 To: "James P. Salsman" From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200009180948.CAA29716@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 02:48 18.09.00 -0700, James P. Salsman wrote: >Does any WAP product use TCP at all? Yes, the WAP2.0 does. I don't know about the availability of the specs, though. Have you checked www.wapforum.org? >[...] >I think the TCP parameters and resulting behavior might be more >different than typical TCP stacks than whoever made that comment >might think. There seems to be a lack of understanding about the >parameters involved, and most if not all of the important ones are >at least touched on in the DoCoMo I-D and the documents it cites. You need to be more precise. Which parameters are you talking about? > > Gabe: This is similar to what was done in ecn document > >What is the ecn document? RFC2481. > > Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) > > http://search.ietf.org/internet-drafts/draft-magret-pilc-lltcp-00.txt > > > Comment: this is probably not a good idea -- leads to ICMP flooding. > >Is there any evidence to back this comment up? It seems that ICMP >traffic is specifically addressed by Magret and Yang. Since, it was my comment: One piece of evidence is the problem created by the ICMP Source Quench. In general, you want to avoid having the network signal to the end-points if it's not absolutely necessary. Here it's not necessary because you can solve this problem at the link layer (see below). This was discussed before on this list and you can check the archive pilc.grc.nasa.gov/pilc/list/archive and look for the subjects: "Kicking TCP" and "Why we don't need ICMP SE". > > Also, if there is a long outage you do want to go through slow start > > again, because the network has changed. There are better link level > > solutions to this problem. > >Like what? Like having the link layer hold on to (at least some of) the flow's packets for a time on the order of TCP's maximum RTO of 64 seconds. Note, that this requires a link layer that is capable of seperating the TCP flows from the rest to not cause head-of-line blocking for delay sensitive UDP flows. Check out section 4.1.4 of http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html to see how this works in real measurements. ///Reiner From owner-pilc@lerc.nasa.gov Mon Sep 18 15:47: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 PAA18374 for ; Mon, 18 Sep 2000 15:47:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA25598 for pilc-outgoing; Mon, 18 Sep 2000 14:43: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 OAA25506 for ; Mon, 18 Sep 2000 14:43:02 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA12819; Mon, 18 Sep 2000 14:42:54 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012179; Mon, 18 Sep 00 14:42:38 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0/8.11.0) with ESMTP id e8IIgMU00615; Mon, 18 Sep 2000 19:42:23 +0100 (BST) Message-ID: <39C66211.7BCBCF58@erg.abdn.ac.uk> Date: Mon, 18 Sep 2000 19:42:24 +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: Dan Grossman CC: pilc@grc.nasa.gov Subject: Re: QoS replacement text for Links draft References: <200009071836.OAA23420@noah.dma.isg.mot.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 Dan Grossman wrote: > .... > > > > > > Unfortunately, IETF has tended to assume that those who work in this area read > > > the research literature on the subject. There's nothing new here. It's well > > > documented in the literature. > > ^^^^^^^^^^^^^^^^^ > > > > OK - so a non-IETF reference is fine. > I'm having trouble finding a comprehensive reference. By "in the literature", > I meant a significant body of work over the past decade or so. I'd be > grateful if somebody could point out a (or a few) comprehensive papers that > reflect the proposed text. > > Presume you're aware of : Paul Fergusson and Geof Houston's Book: QoS:Delivering QoS on the Internet and in Corporate Networks Wiley. Just wondered whether the discussion has drifted away from "best practice", as accumulated over the past years, and into the (probably more interesting - at least from my perspective) "research isues and current mode of thinking". Please can we be clear which is being discussed in the QoS issues, I'm beginning to have my vision blurred. As someone once said about RSVP: developed =/= deployed. Gorry P.S. I wonder if the old concept of ToS - with well known - yet vague - classes could possibly prove be most beneficial from the **link** perspective. ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Mon Sep 18 15:48:33 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 PAA18395 for ; Mon, 18 Sep 2000 15:48:32 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA25533 for pilc-outgoing; Mon, 18 Sep 2000 14:42:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA25454 for ; Mon, 18 Sep 2000 14:42:52 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA12675; Mon, 18 Sep 2000 14:42:51 -0400 Received: from host60d9.alcatel.com(128.251.96.217) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011047; Mon, 18 Sep 00 14:41:55 -0400 Received: from usa.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id NAA16724; Mon, 18 Sep 2000 13:41:22 -0500 (CDT) Message-ID: <39C66203.129CE738@usa.alcatel.com> Date: Mon, 18 Sep 2000 13:42:11 -0500 From: Vincent Magret X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Reiner Ludwig , PILC CC: Mingguey Yang , Vincent Magret Subject: Re: pilc minutes for IETF 48 References: <4.3.2.7.0.20000918190325.00bb1d10@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 Hi, 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? 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. Concerning the flooding fear, I don't think there is a risk of getting in such situation by the time the tuning (i.e. when the message is sent) is correctly realized. I would agree that we have to work a little bit on this specific point. I don't like the idea of having packet store in the supervisor node because it is somehow an hard state situation. the mobile node can not "resume" its connection with another supervisor node. Our protocol allows this scheme as the supervisor node does not store copies of messages when there is a link failure. Vincent. Reiner Ludwig wrote: > At 02:48 18.09.00 -0700, James P. Salsman wrote: > >Does any WAP product use TCP at all? > > Yes, the WAP2.0 does. I don't know about the availability of the specs, > though. Have you checked www.wapforum.org? > > >[...] > >I think the TCP parameters and resulting behavior might be more > >different than typical TCP stacks than whoever made that comment > >might think. There seems to be a lack of understanding about the > >parameters involved, and most if not all of the important ones are > >at least touched on in the DoCoMo I-D and the documents it cites. > > You need to be more precise. Which parameters are you talking about? > > > > Gabe: This is similar to what was done in ecn document > > > >What is the ecn document? > > RFC2481. > > > > Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt) > > > > http://search.ietf.org/internet-drafts/draft-magret-pilc-lltcp-00.txt > > > > > Comment: this is probably not a good idea -- leads to ICMP flooding. > > > >Is there any evidence to back this comment up? It seems that ICMP > >traffic is specifically addressed by Magret and Yang. > > Since, it was my comment: > One piece of evidence is the problem created by the ICMP Source Quench. > > In general, you want to avoid having the network signal to the end-points > if it's not absolutely necessary. Here it's not necessary because you can > solve this problem at the link layer (see below). > > This was discussed before on this list and you can check the archive > pilc.grc.nasa.gov/pilc/list/archive and look for the subjects: "Kicking > TCP" and "Why we don't need ICMP SE". > > > > Also, if there is a long outage you do want to go through slow start > > > again, because the network has changed. There are better link level > > > solutions to this problem. > > > >Like what? > > Like having the link layer hold on to (at least some of) the flow's packets > for a time on the order of TCP's maximum RTO of 64 seconds. Note, that this > requires a link layer that is capable of seperating the TCP flows from the > rest to not cause head-of-line blocking for delay sensitive UDP flows. > Check out section 4.1.4 of > http://iceberg.cs.berkeley.edu/papers/Ludwig-Diss00/index.html to see how > this works in real measurements. > > ///Reiner From owner-pilc@lerc.nasa.gov Mon Sep 18 15:53: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 PAA18547 for ; Mon, 18 Sep 2000 15:53:17 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA27437 for pilc-outgoing; Mon, 18 Sep 2000 14:53: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 OAA27398 for ; Mon, 18 Sep 2000 14:53:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA28518; Mon, 18 Sep 2000 14:53:10 -0400 Received: from f204.law3.hotmail.com(209.185.241.204) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027434; Mon, 18 Sep 00 14:52:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Sep 2000 11:52:29 -0700 Received: from 206.17.239.228 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 18 Sep 2000 18:52:29 GMT X-Originating-IP: [206.17.239.228] From: "Al-hussein Abou-zeid" To: pilc@grc.nasa.gov Subject: Re: Updates for ERROR after WG last call Date: Mon, 18 Sep 2000 18:52:29 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Sep 2000 18:52:29.0311 (UTC) FILETIME=[983008F0:01C021A1] Sender: owner-pilc@lerc.nasa.gov Precedence: bulk With all due respect for the utility of the equation, I think we need to remember what it actually provides. It does not provide an upper bound, nor does it provide a lower bound. Thus, speaking of a bound seems to be an obvious mistake (at least to me!). It does provide a _reasonable_ estimate of the throughput of bulk TCP-like transfers in _certain_ situations. Thus, in my opinion, the mention of the equation should reflect that, and the guidelines the equation provides can be, at most, as loose as the assumptions made when deriving it. Overstretching the results in this case can be quite a risk. Best regards, Hussein. >From: Cannara >Reply-To: cannara@attglobal.net >CC: "'PILC Mailing List'" >Subject: Re: Updates for ERROR after WG last call >Date: Fri, 15 Sep 2000 10:48:37 -0700 > >Mark, I see what you're trying to accomplish and maybe the approach should >be >to describe two possibilities: a) newer transports that handle error loss >reasonably; and b) older TCPs that create large delays in retransmission. >You >needn't parameterize the quations beyond this. Then emphasis should be on >what error rate is then 'bad' for each of these two situations, since >there's >not one answer, even within a factor of 5. > >Alex > > >Mark Allman wrote: > > > > > Certainly there's a big, easily observed difference between older > > > and newer (e.g., SACK) TCPs -- order of magnitude differences in > > > delays to get good data through (Throughput). > > > > I agree. > > > > > So, the equation needs some TCP parameters and there needs to be a > > > way for the user to decide how to set them, including the likely > > > possibility for end-end mismatch in version. This would qualify > > > as a "first cut", in my opinion. > > > > I disagree. I don't think we need to make this all that > > complicated. I think it is enough to put the appropriate caveats > > around the current TCP friendly equation. It is true that the > > equation does not model every TCP. But it is a decent projection of > > TCP as it is currently being deployed and will be even stronger in > > the future as SACK-based stacks become even more prevelant (which is > > the trend). > > > > Is there a better way to give folks an idea about whether they > > should consider their link ERRORed or not? > > > > allman > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-pilc@lerc.nasa.gov Mon Sep 18 17:03:21 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 RAA19666 for ; Mon, 18 Sep 2000 17:03:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA09614 for pilc-outgoing; Mon, 18 Sep 2000 15:58:10 -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 PAA09589 for ; Mon, 18 Sep 2000 15:58:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA04070; Mon, 18 Sep 2000 15:58:06 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003429; Mon, 18 Sep 00 15:57:40 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0/8.11.0) with ESMTP id e8IJvSU00802; Mon, 18 Sep 2000 20:57:29 +0100 (BST) Message-ID: <39C673AB.AF30C440@erg.abdn.ac.uk> Date: Mon, 18 Sep 2000 20:57:31 +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: "Dawkins, Spencer" , "'PILC Mailing List'" Subject: Re: Updates for ERROR after WG last call References: 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 "Dawkins, Spencer" wrote: > ... > > But my real comment is about Appropriate Byte Counting. > > I've changed mail systems since we had this conversation, but I believe that > the paragraph you're looking at dates from an early conversation we had > about ABC, that wasn't comparing ABC to standard TCP, but to previous > flavors of byte counting like "limited byte counting", which I remember you > characterizing as "slightly too aggressive". So I'm pretty sure the text > that's giving you heartburn may be taking this conversation out of context. > > I believe the most recent conversation we had about ABC was that ABC helped > to deal with application protocols like SMTP, that follow a couple of short > packet exchanges ("enter userid", "enter password") with full-length packets > as actual transfers start to take place - so that a standard TCP > implementation would be happily thinking "well, I could send two (short) > packets, so let's crank the window"). > > Does this sound familiar to you? If so, I need to rework this paragraph! Sounds plausible, although the rework is probably wise now. I was re-reading the paragraph and became muddled. I finally came to the same conclusion: that you were saying ABC is one of the "best" of the byte-counting algorithms. The other schemes mentioned at the end of the paragraph, such as sender pacing and network/receiver modifications to the ACK rate seem to provide more direct support for the reduction of bursts of data segments from ACK Compression or opening of cwnd. (There's also a cwnd modification by Packeteer where the network changes the cwnd value in forwarded ACKs - but this may be patented - and could be thought of as somewhat similar to ACK rate control). Gorry Fairhurst > > > Spencer > > > -----Original Message----- > > From: Mark Allman [SMTP:mallman@grc.nasa.gov] > > Sent: Thursday, September 14, 2000 9:46 AM > > To: Dawkins, Spencer > > Cc: 'PILC Mailing List' > > Subject: Re: Updates for ERROR after WG last call > > > > > > Spencer- > > > > I think most of the changes look good. I'd still love to see the > > tcp friendly equation in this document, much as it is in the LINK > > document. I.e., if the error rate is low enough for a given > > available bandwidth throughput is not impacted and you don't have to > > worry. > > > > But, my real comment is about... > > > > > Losses that take place on the ACK stream, especially while a > > > TCP is learning network characteristics, can make the data > > > stream quite bursty (resulting in losses on the data stream, as > > > well). Several ways of limiting this burstiness have been > > > proposed, including "Appropriate Byte Counting" [ALL99], TCP > > > transmit pacing at the sender, and ACK rate control within the > > > network. > > > > I still don't understand how ABC limits burstiness. I believe quite > > the opposite, actually. I threw the following slide up during the > > tsvwg meeting in Pittsburgh on the disadvantages of ABC: > > > > .Assuming $L~=~2~MSS$, we see increased burstiness: > > -Micro-burstiness increase: The number of data segments sent in > > response to an ACK is increased by 1~segment. > > -Macro-burstiness increase: During slow start \textit{cwnd} is > > currently increased by roughly 50\% per RTT (assuming delayed > > ACKs) whereas ABC will cause an increase of roughly 100\% per > > RTT. > > > > I agree that ABC can help mitigate the window growth problem that > > occurs when ACKs are lost (for whatever reason). However, it does > > so in a bursty fashion. And, I believe it is *more* bursty than the > > standard algorithm. > > > > I'd **really, really** like to see the above reworked in the ERROR > > document. (Or, be proven wrong...) > > > > allman > > > > > > --- > > http://roland.grc.nasa.gov/~mallman/ -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Tue Sep 19 00:10:45 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 AAA26326 for ; Tue, 19 Sep 2000 00:10:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA21953 for pilc-outgoing; Mon, 18 Sep 2000 23:09:52 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA21942 for ; Mon, 18 Sep 2000 23:09:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id XAA22526; Mon, 18 Sep 2000 23:09:49 -0400 Received: from shell9.ba.best.com(206.184.139.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022472; Mon, 18 Sep 00 23:09:11 -0400 Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id UAA13157; Mon, 18 Sep 2000 20:08:26 -0700 (PDT) Date: Mon, 18 Sep 2000 20:08:26 -0700 (PDT) From: "James P. Salsman" Message-Id: <200009190308.UAA13157@shell9.ba.best.com> To: pilc@grc.nasa.gov, Reiner.Ludwig@ericsson.com Subject: Re: pilc minutes for IETF 48 Cc: discuss@apps.ietf.org, ietf-mmms@IMC.ORG, ietf@ietf.org In-Reply-To: <4.3.2.7.0.20000918190325.00bb1d10@chapelle.ericsson.se> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Reiner, Thanks for your reply: >>... There seems to be a lack of understanding about the >> parameters involved, and most if not all of the important ones are >> at least touched on in the DoCoMo I-D and the documents it cites. > > You need to be more precise. Which parameters are you talking about? These from http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt Feature Parameter/Recommendation RFC/Status ------------------------------------------------------------------- MTU size 1500B N/A Window size 64KB RFC 793 Standard Initial window 2 mss RFC 2581 Proposed Standard Initial window up to 4380B RFC 2414 Experimental Use of SACK Recommend RFC 2018 Proposed Standard So, given the ECN-like properties of Radio Link Control -- 3G TS 25.322; which also seems to be incorporated in current versions of GSM -- http://webapp.etsi.org/action/OP/OP20000929/en_301349v080400o.pdf -- is there really any need to add explicit link condition adaptation at the TCP or ICMP protocol levels? I don't want to be in a position of advocating the change or addition of anything to those protocols unless absolutely necessary. As far as robust wireless TCP goes, you are absolutely right that good service requires a maximum RTO shorter than the standard 64 seconds. What is that value in your TCP-Eiffel? And one parameter that the DoCoMo draft doesn't mention (perhaps it goes without saying to most people) is a total retransmit timeout much longer than the typical 2-9 minutes. Again, what do you use; an hour? Cheers, James P.S. Please keep at least ietf-mmms@imc.org in on this, as the lack of ubiquitous wireless TCP is related to Mobile Multimedia Messaging applications. From owner-pilc@lerc.nasa.gov Tue Sep 19 11:19:12 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17373 for ; Tue, 19 Sep 2000 11:19:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA28267 for pilc-outgoing; Tue, 19 Sep 2000 10:10:02 -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 KAA28198; Tue, 19 Sep 2000 10:09:26 -0400 (EDT) Message-Id: <200009191409.KAA28198@lombok-fi.lerc.nasa.gov> To: "James P. Salsman" From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: pilc@grc.nasa.gov, Reiner.Ludwig@ericsson.com, discuss@apps.ietf.org, ietf-mmms@IMC.ORG Subject: Re: pilc minutes for IETF 48 Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Welcome to the Jungle Date: Tue, 19 Sep 2000 10:09:26 -0400 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > As far as robust wireless TCP goes, you are absolutely right that > good service requires a maximum RTO shorter than the standard 64 > seconds. What is that value in your TCP-Eiffel? Why should the maximum RTO be less than 64 seconds? If the RTO gets to that point it was because of exponential backoff. So, one of two things has happened... * Extreme congestion. In this case you want your RTO timer to be backed off to a large time to avoid aggrivating the congestion even more. * An outage. In this case, it is potentially painful when the link is re-established because you have to wait for some (likely large) amount of time before re-starting transmission. So, for this case, we'd like to have a lower maximum RTO. But, how does the end host figure out which situation it is in? There may be heuristics, but it seems to me that having an explicit mechanism that "kicks" TCP in the second case is likely the way to go (i.e., an ICMP or holding on to the last segment(s) to trigger the restart of the connection). allman --- http://roland.grc.nasa.gov/~mallman/ From owner-pilc@lerc.nasa.gov Tue Sep 19 13:48:13 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 NAA21343 for ; Tue, 19 Sep 2000 13:48:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21982 for pilc-outgoing; Tue, 19 Sep 2000 12:37: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 MAA21923 for ; Tue, 19 Sep 2000 12:37:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA14216; Tue, 19 Sep 2000 12:36:59 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013169; Tue, 19 Sep 00 12:36:20 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA09750; Tue, 19 Sep 2000 09:36:01 -0700 (PDT) Message-ID: <39C795E1.27C96560@isi.edu> Date: Tue, 19 Sep 2000 09:35:45 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Kathleen Nichols CC: karn@qualcomm.com, pilc@grc.nasa.gov, karn@ka9q.ampr.org Subject: Re: Comments to "Advice for Internet Subnetwork Designers" References: <4.3.2.7.0.20000719150341.00b3bef0@chapelle.ericsson.se> <4.3.2.7.0.20000720140709.00b6cb60@chapelle.ericsson.se> <4.3.2.7.0.20000721081744.00d1c780@chapelle.ericsson.se> <4.3.2.7.0.20000721112423.00af8af0@chapelle.ericsson.se> <398598BE.1162C4D1@packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Kathleen Nichols wrote: > > Phil Karn wrote: > > > ... > > So what about a "TOS" field that simply indicates how many IP packets > > make up this application's transaction size? Where does this information come from? And why is it useful? Regarding the first question: In particular, how many IP packets an application 'write' gets translated into depends on a number of factors, many of which aren't available at any particular time (listed in no particular order): - currently pending outgoing data - IP fragmentation - ACK frequency (1 every 2 MTUs is recommended, but not required) and it hiccups with timeout-generated ACKs, - Nagle status (on/off) - PUSH requests (which can hiccup the stream) - MTU (which can change on the fly, e.g., PMTU) The problem is that there is no one number that describes, or even approximates usefully, a transaction size. Further, applications have varying transaction sizes. It is even further muddied by application-layer (or above-the-transport) muxing. > > While the analogy isn't > > perfect, think of it as a distant cousin of the TCP "push" bit, which > > was originally defined to permit implementations to gain efficiency by > > aggregating data when immediate delivery wasn't necessary. This wasn't a network issue; it was an end-system issue. --- Regarding the second question, why is it useful, I could imagine it potentially being used for IP-level EPD, e.g., at a RED router, dropping the remainder of a transaction when a part is dropped. However, in ATM it requires that there not be reordering (e.g., that reordering be checked and out-of-order cells be dropped PRIOR to the EPD). Given IP reordering, how can this information be used?? Joe From owner-pilc@lerc.nasa.gov Tue Sep 19 16:34:11 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 QAA24470 for ; Tue, 19 Sep 2000 16:34:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA19559 for pilc-outgoing; Tue, 19 Sep 2000 15:14:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA19510 for ; Tue, 19 Sep 2000 15:14:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA19205; Tue, 19 Sep 2000 15:14:51 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018626; Tue, 19 Sep 00 15:14: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 e8JJEMt15324; Tue, 19 Sep 2000 21:14:22 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160147.am.ericsson.se [138.85.160.147]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id VAA24903; Tue, 19 Sep 2000 21:14:09 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000919143529.00dbdef0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Sep 2000 15:19:51 +0200 To: "James P. Salsman" From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov, ietf-mmms@IMC.ORG In-Reply-To: <200009190308.UAA13157@shell9.ba.best.com> References: <4.3.2.7.0.20000918190325.00bb1d10@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 20:08 18.09.00 -0700, James P. Salsman wrote: > >>... There seems to be a lack of understanding about the > >> parameters involved, and most if not all of the important ones are > >> at least touched on in the DoCoMo I-D and the documents it cites. > > > > You need to be more precise. Which parameters are you talking about? > >These from http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt > > Feature Parameter/Recommendation RFC/Status > ------------------------------------------------------------------- > MTU size 1500B N/A So PMTU discovery is the mechanism that should be used as it provides the largest MTU the path allows and that is really what we are after. Who knows, maybe (probably) in a few years MTUs larger than 1500B are more common. So, we should not recommend any fixed value like the 1500B just because that is the largest MTU found in the wide-area *today*. But, really, this goes without saying. PMTU is a standards track RFC, so your TCP should have it, anyway. > Window size 64KB RFC 793 Standard I see that this is required for connections over some high bandwidth x delay links but I'm still not sure what the PILC group should recommend here. Should every OS allocate 64KB socket buffers by default? Probably not. Or should window scaling (RFC1323) be recommended? > Initial window 2 mss RFC 2581 Proposed Standard Goes without saying: it's a standards track RFC, so your TCP should have it, anyway. > Initial window up to 4380B RFC 2414 Experimental Since this is an experimental RFC, this should better not be recommended at this stage. > Use of SACK Recommend RFC 2018 Proposed Standard Goes without saying: it's a standards track RFC, so your TCP should have it, anyway. So really, there are not many "TCP parameters" that need to be tuned for wireless. In fact, I don't think there is any such parameter. The only one that is left from the above list is the socket buffer size, but that is not wireless specific but rather required by the bandwidth x delay properties of your path. Something the satellite people have dealt with for more than 10 years. >So, given the ECN-like properties of Radio Link Control What does that mean? >-- is there really any need to add explicit link condition adaptation >at the TCP or ICMP protocol levels? I don't think so. There is no such thing like a "Wireless-TCP" and more important: there is also no need for it. TCP over wireless works just fine if you have the right link layer. >As far as robust wireless TCP goes, you are absolutely right that good >service requires a maximum RTO shorter than the standard 64 seconds. I never said that. I do *not* want to change TCP's max. RTO. I said that ***if*** your link layer is capable of separating TCP flows (more generally reliable flows including Reliable-Multicast, NFS, etc.) from other flows to avoid HOL blocking, ***then*** the link layer error recovery persistency for the TCP flows should be set to TCP's max. RTO, i.e., 64 seconds. That means that such a link layer sender will try for up to 64 seconds to successfully transmit a TCP packet. By the way, this helps you through some fairly hefty link outages. ***If***, on the other hand, your link layer is "transport blind", i.e., cannot separate flow types, ***then*** the error recovery persistency must be low (on the order of a second) again to avoid HOL blocking for delay sensitive flows. >What is that value in your TCP-Eiffel? It's TCP-Eifel (one 'f') ;-) Although, TCP-Eifel implements a new retransmission timer that reacts quicker to packet losses than the standard timer, I have not changed the max. RTO. >And one parameter that the DoCoMo draft doesn't mention (perhaps it >goes without saying to most people) is a total retransmit timeout much >longer than the typical 2-9 minutes. Again, what do you use; an hour? TCP-Eifel implements a "retransmit forever" feature, i.e., ultimately the oldest outstanding packet is retransmitted every 64 seconds, until the application closes the connection. Currently this is only implemented as a compile option. Really it should be a socket option that the application could choose to enable or not. Clearly, having TCP retransmit "forever" (read: until the application closes the connection) will be somewhat controversial ;-) >P.S. Please keep at least ietf-mmms@imc.org in on this, as the lack >of ubiquitous wireless TCP is related to Mobile Multimedia Messaging >applications. I did it in this case but in general people interested in how these issues are discussed in the IETF should tune into the PILC mailing list. ///Reiner From owner-pilc@lerc.nasa.gov Wed Sep 20 03:04: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 DAA15671 for ; Wed, 20 Sep 2000 03:04:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA11593 for pilc-outgoing; Wed, 20 Sep 2000 02:08: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 CAA11560; Wed, 20 Sep 2000 02:08:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id CAA06135; Wed, 20 Sep 2000 02:07:56 -0400 Received: from shell9.ba.best.com(206.184.139.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006076; Wed, 20 Sep 00 02:07:48 -0400 Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id XAA25948; Tue, 19 Sep 2000 23:07:19 -0700 (PDT) Date: Tue, 19 Sep 2000 23:07:19 -0700 (PDT) From: "James P. Salsman" Message-Id: <200009200607.XAA25948@shell9.ba.best.com> To: mallman@grc.nasa.gov Subject: TCP timeout parameters and wireless (was Re: pilc minutes for IETF 48) Cc: discuss@apps.ietf.org, ietf-mmms@IMC.ORG, ietf@ietf.org, pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Mark, Thank you for your message: >... how does the end host figure out which situation (congestion > or outage) it is in? There are two end hosts. Only one of them has a good chance of knowing, and the other doesn't usually care these days. I agree that a well-designed signaling method (whether by TCP extensions or ICMP extensions) is a good idea, and I am sure that will be better-used in the future. For now, though, in the situation most nets are in, if people want services that can be accessed reliably by wireless communications, they might want to at least lower their TCP maximum retransmition timeout values, consider lowering their RTO maximum, read Reiner's comments on the DoCoMo draft: http://pilc.grc.nasa.gov/pilc/list/archive/0996.html and have a look at his TCP-Eifel page: http://iceberg.cs.berkeley.edu/downloads/tcp-eifel Now, I wonder which cellphone will be the first to play MIME audio/mpeg attachments AND have PPP available on a DB-9 RS-232. Cheers, James From owner-pilc@lerc.nasa.gov Wed Sep 20 04:47:43 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 EAA16611 for ; Wed, 20 Sep 2000 04:47:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA17483 for pilc-outgoing; Wed, 20 Sep 2000 03: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 DAA17470 for ; Wed, 20 Sep 2000 03:39:07 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id DAA17257; Wed, 20 Sep 2000 03:39:06 -0400 Received: from fe3.southeast.rr.com(24.93.67.50) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017189; Wed, 20 Sep 00 03:38:58 -0400 Received: from v3f6b5 ([24.25.25.53]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.357.35); Wed, 20 Sep 2000 03:38:33 -0400 From: "Injong Rhee" To: "Reiner Ludwig" , "James P. Salsman" Cc: , Subject: RE: pilc minutes for IETF 48 Date: Wed, 20 Sep 2000 03:36:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <4.3.2.7.0.20000919143529.00dbdef0@chapelle.ericsson.se> Importance: Normal Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Agreed. Even the order of a second (or a few seconds) like current network provides is still harmful for real-time flows like video streaming. Currently we are experiencing more than 2 second delays on sprint pcs. Is there any work addressing this delay issue? >-----Original Message----- From: owner-pilc@lerc.nasa.gov [mailto:owner-pilc@lerc.nasa.gov]On Behalf Of Reiner Ludwig Sent: Tuesday, September 19, 2000 6:20 AM To: James P. Salsman Cc: pilc@grc.nasa.gov; ietf-mmms@IMC.ORG Subject: Re: pilc minutes for IETF 48 .......[][] ***If***, on the other hand, your link layer is "transport blind", i.e., cannot separate flow types, ***then*** the error recovery persistency must be low (on the order of a second) again to avoid HOL blocking for delay sensitive flows. From owner-pilc@lerc.nasa.gov Wed Sep 20 15:35:15 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02639 for ; Wed, 20 Sep 2000 15:35:14 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26183 for pilc-outgoing; Wed, 20 Sep 2000 13:58: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 NAA26171 for ; Wed, 20 Sep 2000 13:58:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA29269; Wed, 20 Sep 2000 13:16:35 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029216; Wed, 20 Sep 00 13:16:19 -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 e8KHGFZ24491; Wed, 20 Sep 2000 19:16:15 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (ki-179.kiedt.ericsson.se [147.214.100.179]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id TAA16317; Wed, 20 Sep 2000 19:16:00 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000920185534.00ae9b30@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Sep 2000 19:14:14 +0200 To: Vincent Magret From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <39C66203.129CE738@usa.alcatel.com> References: <4.3.2.7.0.20000918190325.00bb1d10@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 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. >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. >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. >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 From owner-pilc@lerc.nasa.gov Wed Sep 20 15:36: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 PAA02665 for ; Wed, 20 Sep 2000 15:36:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA25922 for pilc-outgoing; Wed, 20 Sep 2000 13:57: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 NAA25917 for ; Wed, 20 Sep 2000 13:57:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA00377; Wed, 20 Sep 2000 13:24:49 -0400 Received: from f238.law3.hotmail.com(209.185.241.238) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000325; Wed, 20 Sep 00 13:24:04 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Sep 2000 10:24:02 -0700 Received: from 206.17.239.228 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 20 Sep 2000 17:24:02 GMT X-Originating-IP: [206.17.239.228] From: "Al-hussein Abou-zeid" To: Reiner.Ludwig@ericsson.com, bovik@best.com Cc: pilc@grc.nasa.gov, ietf-mmms@IMC.ORG Subject: Re: pilc minutes for IETF 48 Date: Wed, 20 Sep 2000 17:24:02 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Sep 2000 17:24:02.0760 (UTC) FILETIME=[92101C80:01C02327] Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >From: Reiner Ludwig >To: "James P. Salsman" >CC: pilc@grc.nasa.gov, ietf-mmms@IMC.ORG >Subject: Re: pilc minutes for IETF 48 >Date: Tue, 19 Sep 2000 15:19:51 +0200 > >At 20:08 18.09.00 -0700, James P. Salsman wrote: >> >>... There seems to be a lack of understanding about the >> >> parameters involved, and most if not all of the important ones are >> >> at least touched on in the DoCoMo I-D and the documents it cites. >> > >> > You need to be more precise. Which parameters are you talking about? >> >>These from >>http://search.ietf.org/internet-drafts/draft-inamura-docomo-00.txt >> >> Feature Parameter/Recommendation RFC/Status >> ------------------------------------------------------------------- >> MTU size 1500B N/A > >..... > >> Window size 64KB RFC 793 Standard > >..... >> Initial window 2 mss RFC 2581 Proposed Standard > >..... > >..... >> Use of SACK Recommend RFC 2018 Proposed Standard > >.... >So really, there are not many "TCP parameters" that need to be tuned for >wireless. In fact, I don't think there is any such parameter. The only one >that is left from the above list is the socket buffer size, but that is not >wireless specific but rather required by the bandwidth x delay properties >of your path. Something the satellite people have dealt with for more than >10 years. > >.... >I don't think so. There is no such thing like a "Wireless-TCP" and more >important: there is also no need for it. TCP over wireless works just fine >if you have the right link layer. > Two comments; First, the performance of TCP is sensitive to the specific wireless medium characteristics, especially loss behavior - see TCP studies on this issue in Sigcomm, Sigmetrics and Infocom 2000. So, there are no magic TCP values that would work for any wireless link. Second, what do you mean by a "right link layer". Is there such a thing? If you mean a wireless link that is as pure as an optical link, or even a twisted pair, then, this it is probably a very special case of a wireless link. Regards. Hussein. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-pilc@lerc.nasa.gov Wed Sep 20 16:20:54 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 QAA06154 for ; Wed, 20 Sep 2000 16:20:49 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA09202 for pilc-outgoing; Wed, 20 Sep 2000 15:00: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 PAA09177 for ; Wed, 20 Sep 2000 15:00:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA12133; Wed, 20 Sep 2000 15:00:03 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011980; Wed, 20 Sep 00 14:59:19 -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 e8KIxGt25231; Wed, 20 Sep 2000 20:59:17 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (ki-68.kiedt.ericsson.se [147.214.100.68]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id UAA28176; Wed, 20 Sep 2000 20:59:04 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000920200846.00cb2ba0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Sep 2000 20:23:46 +0200 To: "Al-hussein Abou-zeid" From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 17:24 20.09.00 +0000, Al-hussein Abou-zeid wrote: >Two comments; First, the performance of TCP is sensitive to the specific >wireless medium characteristics, especially loss behavior If you have a reliable link layer protocol (ARQ) _and_ you tune the error recovery persistency of that protocol to a high value like 64 seconds (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. ***However***, you have to ensure that the link layer does this _only_ for the reliable flows such as the TCP-based flows. There are number of studies that confirm that. Taken from a mail I had sent to PILC on Aug. 1st: 1. P. Bhagwat, P. Bhattacharya, A. Krishna, S. K. Tripathi, Using channel state dependent packet scheduling to improve TCP throughput over wireless LANs, ACM/Baltzer Wireless Networks Journal, Vol. 3, No. 1, January 1997. 2. D. A. Eckhardt, P. Steenkiste, Improving Wireless LAN Performance via Adap-tive Local Error Control, In Proceedings of IEEE ICNP 98. 3. R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, A. Joseph, Multi-Layer Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings of ACM SIGMETRICS 99. 4. M. Meyer, TCP Performance over GPRS, In Proceedings of IEEE WCNC 99. >Second, what do you mean by a "right link layer". See above. Such a link layer also eliminates the problem of link outages as discussed before. So, my position is: before we start thinking of "wireless specific" changes to TCP and/or ICMP, let's first see what we can do at the link layer to solve the problem. And yes, the known problems ***can be solved at the link layer***, we need to be able to distinguish flow types, though. ///Reiner From owner-pilc@lerc.nasa.gov Wed Sep 20 19:20: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 TAA10733 for ; Wed, 20 Sep 2000 19:20:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA11578 for pilc-outgoing; Wed, 20 Sep 2000 18:12:15 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (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 SAA11543; Wed, 20 Sep 2000 18:12:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA04542; Wed, 20 Sep 2000 18:12:12 -0400 Received: from shell9.ba.best.com(206.184.139.140) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004491; Wed, 20 Sep 00 18:11:39 -0400 Received: (from bovik@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id PAA17944; Wed, 20 Sep 2000 15:11:07 -0700 (PDT) Date: Wed, 20 Sep 2000 15:11:07 -0700 (PDT) From: "James P. Salsman" Message-Id: <200009202211.PAA17944@shell9.ba.best.com> To: mallman@grc.nasa.gov Subject: Re: TCP timeout parameters and wireless (was Re: pilc minutes for IETF 48) Cc: discuss@apps.ietf.org, ietf-mmms@IMC.ORG, ietf@ietf.org, pilc@grc.nasa.gov In-Reply-To: <200009201409.KAA28296@lawyers.grc.nasa.gov> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Mark, Thanks for your message: >... It is my opinion that it is a mistake to reduce the maximum > RTO too low.... Absolutly; I'm worried that even mentioning the RTO maximum will detract attention from the maximum retransmition timeout which is the REAL problem with TCP over wireless, more than all the other TCP parameters combined, certainly. I mean, what difference does it make if you have to wait an extra minute to get a connection back as long as you can get it back instead of having it dropped after nine minutes? Cheers, James From owner-pilc@lerc.nasa.gov Thu Sep 21 10:22: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 KAA06233 for ; Thu, 21 Sep 2000 10:22:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA08283 for pilc-outgoing; Thu, 21 Sep 2000 09:04:04 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (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 JAA08216 for ; Thu, 21 Sep 2000 09:04:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA01024; Thu, 21 Sep 2000 09:03:57 -0400 Received: from percy.erg.abdn.ac.uk(139.133.204.86) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000963; Thu, 21 Sep 00 09:03:18 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.0/8.11.0) with ESMTP id e8LD1tU17891; Thu, 21 Sep 2000 14:01:56 +0100 (BST) Message-ID: <39CA06C4.4F3ADA4@erg.abdn.ac.uk> Date: Thu, 21 Sep 2000 14:01:55 +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 , Al-hussein Abou-zeid , pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 References: <4.3.2.7.0.20000920200846.00cb2ba0@chapelle.ericsson.se> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I agree we need to think clearly about what we are saying. Reiner Ludwig wrote: > At 17:24 20.09.00 +0000, Al-hussein Abou-zeid wrote: > >Two comments; First, the performance of TCP is sensitive to the specific > >wireless medium characteristics, especially loss behavior > > If you have a reliable link layer protocol (ARQ) _and_ you tune the error > recovery persistency of that protocol to a high value like 64 seconds > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. > > ***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). If you lump all flows into one link queue (perhaps because you feel some network flows are actually GRE tunnels, IPSEC encrypted, or whatever, then you have to be much more cautious with this recommendation, particularly I feel when you have high link bandwidth and some UDP traffic. 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. > > There are number of studies that confirm that. Taken from a mail I had sent > to PILC on Aug. 1st: > > 1. P. Bhagwat, P. Bhattacharya, A. Krishna, S. K. Tripathi, Using channel > state dependent packet scheduling to improve TCP throughput over wireless > LANs, ACM/Baltzer Wireless Networks Journal, Vol. 3, No. 1, January 1997. > > 2. D. A. Eckhardt, P. Steenkiste, Improving Wireless LAN Performance via > Adap-tive Local Error Control, In Proceedings of IEEE ICNP 98. > > 3. R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, A. Joseph, Multi-Layer > Tracing of TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings > of ACM SIGMETRICS 99. > > 4. M. Meyer, TCP Performance over GPRS, In Proceedings of IEEE WCNC 99. > 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 think there is evidence that at least some of these links have in the past performed very poorly with reliable ARQ protocols. > > >Second, what do you mean by a "right link layer". > > See above. Such a link layer also eliminates the problem of link outages as > discussed before. Link outages are a specific characteristic. May be our recommendations for outages should differ from other types of errors (I can see merit in this). During an outage no retransmission scheme is going to succeed at the link layer - some physical layer (coding, etc) may succeed - After an outage, we need to resume transmission at the link layer of the data which failed to be sent. This is what the current draft advises subnet designers with outages. It is in effect a support for reliable ARQ, although doesn't imply you HAVE to do it this way. . > > So, my position is: before we start thinking of "wireless specific" changes > to TCP and/or ICMP, let's first see what we can do at the link layer to > solve the problem. I agree. The problem with wireless add-ins to TCP is that they are even less likely to be generic to all types of links. The information provided by any network is almost always transmitted unreliably to the end systems, and it can not always be be assumed that this is the only path between the end systems. > > And yes, the known problems ***can be solved at the link layer***, we need > to be able to distinguish flow types, though. > Yes, I think we need at least two scenarios here - since the advice may need to be different in each. > > ///Reiner -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-pilc@lerc.nasa.gov Thu Sep 21 11:55:54 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 LAA08577 for ; Thu, 21 Sep 2000 11:55:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA22626 for pilc-outgoing; Thu, 21 Sep 2000 10:31:42 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (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 KAA22588 for ; Thu, 21 Sep 2000 10:31:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA12742; Thu, 21 Sep 2000 10:31:35 -0400 Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012656; Thu, 21 Sep 00 10:31:30 -0400 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id e8LEVPu26392 for ; Thu, 21 Sep 2000 09:31:25 -0500 (CDT) Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.11.0/8.11.0) id e8LEUkY26251 for pilc@grc.nasa.gov; Thu, 21 Sep 2000 09:30:46 -0500 (CDT) Date: Thu, 21 Sep 2000 09:30:46 -0500 (CDT) From: Nitin H Vaidya Message-Id: <200009211430.e8LEUkY26251@sun.cs.tamu.edu> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> > If you have a reliable link layer protocol (ARQ) _and_ you tune the error >> > recovery persistency of that protocol to a high value like 64 seconds >> > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. >> > >> > ***However***, you have to ensure that the link layer does this _only_ for >> > the reliable flows such as the TCP-based flows. Some folks seem to be arguing that we can solve the errored-link problem at the link layer by doing ARQ-for-ever & differentiating between TCP and UDP. I have seen some of the papers which show that link layer retransmission can solve the problem in some environments - I agree that "limited" ARQ can help reliable flows ... ... however, I am not convinced that retransmitting for 64 seconds or some such large interval of time is always terribly useful. Even if we grant (for the sake of the argument) that this might always improve throughput of a TCP transfer, is that necessarily better from a user's perspective ? May be, for some TCP connections, response time is also relevant. What if we are looking at a web user who gets impatient and starts clicking "reload" every 10 seconds? Or, gives up and decides to look up some other web page ? The work done in buffering and retransmitting-to-eternity may be wasted/redundant in this case. The point is that there is something of a continuum between "reliable" and "non-reliable" flows, and a greater granularity of information is necessary to do the right thing at the link layer. If such information is not available, why not use a generic feedback mechanism to inform the transport layer (e.g., ICMP), and let each transport layer (or application) do what it deems best. (I am not suggesting that we discard ARQ - the feedback can be used in conjunction with limited ARQ, or when limited ARQ fails). Also, it may not be possible to reduce non-congestion losses to a negligible level in all wireless environments. Even if we somehow manage this in the last-hop wireless scenario, in multi-hop mobile environment, this may not be practical - here, we may have frequent losses due to route changes (carrying the "fully reliable ARQ" argument to this case would require the network layer to be "fully" reliable too!). Best regards. - nitin From owner-pilc@lerc.nasa.gov Thu Sep 21 13:52: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 NAA11059 for ; Thu, 21 Sep 2000 13:52:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13213 for pilc-outgoing; Thu, 21 Sep 2000 12:35: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 MAA13181 for ; Thu, 21 Sep 2000 12:35:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA03161; Thu, 21 Sep 2000 12:35:35 -0400 Received: from fe3.southeast.rr.com(24.93.67.50) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003071; Thu, 21 Sep 00 12:35:18 -0400 Received: from v3f6b5 ([24.25.25.53]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.357.35); Thu, 21 Sep 2000 12:34:50 -0400 From: "Injong Rhee" To: "Nitin H Vaidya" , Subject: RE: pilc minutes for IETF 48 Date: Thu, 21 Sep 2000 12:32:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <200009211430.e8LEUkY26251@sun.cs.tamu.edu> Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Nitin. I want to go even further by leaving all arq decisions to the transport (supported by TCP) or sometimes to the application (supported by UDP). I think just some hints like why packets are lost (even in some cases, corrupted packets delivered are useful with indication that it is corrupted) would help applications a lot. My point is that applications have to have some flexibility as to what kind of reliability they want. What if applications do not want any arq at all? I can see why some perf. improvement can be achieved by doing link-level arq when applications want it. However, is this benefit good enough to trade the flxibility at the application? Just some thoughts from an application designer. Injong Rhee --- Injong Rhee NCSU www.csc.ncsu.edu/faculty/rhee -----Original Message----- From: owner-pilc@lerc.nasa.gov [mailto:owner-pilc@lerc.nasa.gov]On Behalf Of Nitin H Vaidya Sent: Thursday, September 21, 2000 7:31 AM To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 >> > If you have a reliable link layer protocol (ARQ) _and_ you tune the error >> > recovery persistency of that protocol to a high value like 64 seconds >> > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. >> > >> > ***However***, you have to ensure that the link layer does this _only_ for >> > the reliable flows such as the TCP-based flows. Some folks seem to be arguing that we can solve the errored-link problem at the link layer by doing ARQ-for-ever & differentiating between TCP and UDP. I have seen some of the papers which show that link layer retransmission can solve the problem in some environments - I agree that "limited" ARQ can help reliable flows ... ... however, I am not convinced that retransmitting for 64 seconds or some such large interval of time is always terribly useful. Even if we grant (for the sake of the argument) that this might always improve throughput of a TCP transfer, is that necessarily better from a user's perspective ? May be, for some TCP connections, response time is also relevant. What if we are looking at a web user who gets impatient and starts clicking "reload" every 10 seconds? Or, gives up and decides to look up some other web page ? The work done in buffering and retransmitting-to-eternity may be wasted/redundant in this case. The point is that there is something of a continuum between "reliable" and "non-reliable" flows, and a greater granularity of information is necessary to do the right thing at the link layer. If such information is not available, why not use a generic feedback mechanism to inform the transport layer (e.g., ICMP), and let each transport layer (or application) do what it deems best. (I am not suggesting that we discard ARQ - the feedback can be used in conjunction with limited ARQ, or when limited ARQ fails). Also, it may not be possible to reduce non-congestion losses to a negligible level in all wireless environments. Even if we somehow manage this in the last-hop wireless scenario, in multi-hop mobile environment, this may not be practical - here, we may have frequent losses due to route changes (carrying the "fully reliable ARQ" argument to this case would require the network layer to be "fully" reliable too!). Best regards. - nitin From owner-pilc@lerc.nasa.gov Thu Sep 21 14:04: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 OAA11282 for ; Thu, 21 Sep 2000 14:04:08 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA14800 for pilc-outgoing; Thu, 21 Sep 2000 12:45: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 MAA14771 for ; Thu, 21 Sep 2000 12:45:55 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA04915; Thu, 21 Sep 2000 12:45:53 -0400 Received: from f215.law3.hotmail.com(209.185.241.215) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004839; Thu, 21 Sep 00 12:45:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Sep 2000 09:45:24 -0700 Received: from 206.17.239.228 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 21 Sep 2000 16:45:24 GMT X-Originating-IP: [206.17.239.228] From: "Al-hussein Abou-zeid" To: Reiner.Ludwig@ericsson.com Cc: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Date: Thu, 21 Sep 2000 16:45:24 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2000 16:45:24.0446 (UTC) FILETIME=[56A737E0:01C023EB] Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >From: Reiner Ludwig >To: "Al-hussein Abou-zeid" >CC: pilc@grc.nasa.gov >Subject: Re: pilc minutes for IETF 48 >Date: Wed, 20 Sep 2000 20:23:46 +0200 > >At 17:24 20.09.00 +0000, Al-hussein Abou-zeid wrote: >>Two comments; First, the performance of TCP is sensitive to the specific >>wireless medium characteristics, especially loss behavior > >If you have a reliable link layer protocol (ARQ) _and_ you tune the error >recovery persistency of that protocol to a high value like 64 seconds >(TCP's max. RTO), you pretty much eliminate losses but trade them for >delay. > And, is this good/acceptable? How will this affect your TCP link? Also, could you please give a pointer to where exactly in your thesis (since you have referenced it in many previous e-mails) do you analyse this case? >>Second, what do you mean by a "right link layer". > >See above. Such a link layer also eliminates the problem of link outages as >discussed before. I do not think that the problems an erroneous link poses on TCP can be treated by assuming we have a magic ARQ that turns it to a high quality link, without paying something for that ARQ (If we had such an ARQ, we would have solved all erroneous link problems whether or not we are using them for TCP). In theory, there _may_ exist an ARQ that would reduce the error probability as small as we want, but we may not want to do that - due to cost or due to loss of goodput (=application size / _delay_). Also, the correlation structure of the packet losses may come into play, so much as the link outage patterns, both being affected by the mobility, ...etc. > >So, my position is: before we start thinking of "wireless specific" changes >to TCP and/or ICMP, let's first see what we can do at the link layer to >solve the problem. > I fully agree that this approach is legitimate. But, I haven't seen the link changes you are proposing. ARQ infinitely overlooks a lot of tradeoffs. In fact, it has been known that feedback and forward error correction are not so different in terms of performance, so I don't see the analysis of the link layer changes that you seem to imply that they are solving problems. >And yes, the known problems ***can be solved at the link layer***, we need >to be able to distinguish flow types, though. > >///Reiner > Even assuming we can distinguish flows at the link layer, I think the link layer proposal "ARQ forever" deserves, at least, some evalution of its impact from an end-to-end prespective, as well as a per-link prespective, in addition to the previous comments above. Regards, Hussein. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-pilc@lerc.nasa.gov Thu Sep 21 14:07:07 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 OAA11393 for ; Thu, 21 Sep 2000 14:07:06 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13635 for pilc-outgoing; Thu, 21 Sep 2000 12:38: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 MAA13607 for ; Thu, 21 Sep 2000 12:38:46 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA03632; Thu, 21 Sep 2000 12:38:42 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003575; Thu, 21 Sep 00 12:38:27 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8LGcQ829132 for pilc@grc.nasa.gov env-from ; Thu, 21 Sep 2000 10:38:26 -0600 (MDT) Date: Thu, 21 Sep 2000 10:38:26 -0600 (MDT) From: Vernon Schryver Message-Id: <200009211638.e8LGcQ829132@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Nitin H Vaidya > ... > Some folks seem to be arguing that we can solve the errored-link > problem at the link layer by doing ARQ-for-ever & differentiating > between TCP and UDP. > > I have seen some of the papers which show that link layer > retransmission can solve the problem in some environments - I > agree that "limited" ARQ can help reliable flows ... > > ... however, I am not convinced that retransmitting for 64 seconds > or some such large interval of time is always terribly useful. > > Even if we grant (for the sake of the argument) that this > might always improve throughput of a TCP transfer, is that > necessarily better from a user's perspective ? What is the alternative? For TCP, the choice is among ARQ, retransmissions by the hosts, and breaking the connection. The only valid argument against ARQ that I've heard are the potential congestion problems and bandwidth wastes of having both link-layer ARQ and TCP retransmissions. In other words, the reason it makes sense to do ARQ on TCP while dropping drop broken UDP packets is that UDP applications must tolerate out-of-order and missing packets. TCP is a reliable stream protocol. You canot drop or change even a single bit. A single drop or rotten bit "MUST" stop the whole TCP stream until it is corrected either by link-layer ARQ or an end-to-end retransmission. > May be, for some TCP connections, response time is also relevant. Yes, response time matters, but if the link layer can't pass a particular TCP segment, then the link layer can't pass that particular TCP segment and any later bits in that TCP connection are also blocked. Moreover, I hope that except in extremely rare cases, if one particular segment won't fly for 64 seconds, then no other TCP segments or UDP/IP packets will fly, that the whole link is busted and not simply filtering a particular bit pattern. Unlike voice, TCP and UDP are all or nothing (modulo proposals for UDP) stream and packet protocols, respectively. Most Internet applications are unlike plain ol' telephones, and cannot tolerate getting some of the right bits plus a few wrong bits. > What if we are looking at a web user who gets impatient and > starts clicking "reload" every 10 seconds? Or, gives up > and decides to look up some other web page ? The work done > in buffering and retransmitting-to-eternity may be wasted/redundant > in this case. Consider what happens when the web user clicks 'reload'. > The point is that there is something of a continuum between > "reliable" and "non-reliable" flows, and a greater granularity of > information is necessary to do the right thing at the link layer. > If such information is not available, why not use > a generic feedback mechanism to inform the transport layer (e.g., ICMP), > and let each transport layer (or application) do what it deems best. > (I am not suggesting that we discard ARQ - the feedback can be used > in conjunction with limited ARQ, or when limited ARQ fails). If the radios won't pass the data, then who are you going to inform of what and what do you want them to do about whatever they're told? In the 64 second ARQ example, what do you propose instead? Do you want the HTTP server to break the TCP connection? Retransmit? Not retransmit? In other words, please reconsider the famous "End to End Principle." > Also, it may not be possible to reduce non-congestion losses > to a negligible level in all wireless environments. Even if we > somehow manage this in the last-hop wireless scenario, in > multi-hop mobile environment, this may not be practical - here, we > may have frequent losses due to route changes (carrying the > "fully reliable ARQ" argument to this case would require the > network layer to be "fully" reliable too!). Routing changes in the familiar part of the Internet do not necessarily imply packet loses. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Sep 21 14:17: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 OAA11572 for ; Thu, 21 Sep 2000 14:17:13 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA18207 for pilc-outgoing; Thu, 21 Sep 2000 13:05: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 NAA18188 for ; Thu, 21 Sep 2000 13:05:35 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA09096; Thu, 21 Sep 2000 13:05:33 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008998; Thu, 21 Sep 00 13:05:18 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13c9mY-0000cA-00; Thu, 21 Sep 2000 18:05:10 +0100 Date: Thu, 21 Sep 2000 18:04:57 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Nitin H Vaidya cc: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 In-Reply-To: <200009211430.e8LEUkY26251@sun.cs.tamu.edu> 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 Thu, 21 Sep 2000, Nitin H Vaidya wrote: > >> > If you have a reliable link layer protocol (ARQ) _and_ you tune the error > >> > recovery persistency of that protocol to a high value like 64 seconds > >> > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. > >> > > >> > ***However***, you have to ensure that the link layer does this _only_ for > >> > the reliable flows such as the TCP-based flows. > > Some folks seem to be arguing that we can solve the errored-link > problem at the link layer by doing ARQ-for-ever & differentiating > between TCP and UDP. I'd _really_ like to know how you can differentiate between TCP and UDP given e.g. use of IPSec. (In a diffserv framework you cannot expect TCP and UDP to be marked separately, particularly if you're downstream. And, again, there's IPSec.) Watching flow behaviour can tell you which flows are controlled and congestion-sensitive or uncontrolled and not, so that you can treat them differently and ensure fairness, but it won't tell you whether a flow is intended as reliable or unreliable by its application, or whether it's (gack) TCP or UDP. L. layeringabstractionlayeringabstractionlayeringabstraction. PGP From owner-pilc@lerc.nasa.gov Thu Sep 21 15:34: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 PAA12975 for ; Thu, 21 Sep 2000 15:34:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA00874 for pilc-outgoing; Thu, 21 Sep 2000 14:24:07 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA00848 for ; Thu, 21 Sep 2000 14:24:05 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA26146; Thu, 21 Sep 2000 14:24:03 -0400 Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026058; Thu, 21 Sep 00 14:23:32 -0400 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id e8LINUu06589; Thu, 21 Sep 2000 13:23:31 -0500 (CDT) Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.11.0/8.11.0) id e8LIMpE26476; Thu, 21 Sep 2000 13:22:51 -0500 (CDT) Date: Thu, 21 Sep 2000 13:22:51 -0500 (CDT) From: Nitin H Vaidya Message-Id: <200009211822.e8LIMpE26476@sun.cs.tamu.edu> To: L.Wood@eim.surrey.ac.uk Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Lloyd: >> From l.wood@eim.surrey.ac.uk Thu Sep 21 12:05:17 2000 >> >> On Thu, 21 Sep 2000, Nitin H Vaidya wrote: >> >> > >> > If you have a reliable link layer protocol (ARQ) _and_ you tune the error >> > >> > recovery persistency of that protocol to a high value like 64 seconds >> > >> > (TCP's max. RTO), you pretty much eliminate losses but trade them for delay. >> > >> > >> > >> > ***However***, you have to ensure that the link layer does this _only_ for >> > >> > the reliable flows such as the TCP-based flows. >> > >> > Some folks seem to be arguing that we can solve the errored-link >> > problem at the link layer by doing ARQ-for-ever & differentiating >> > between TCP and UDP. >> >> I'd _really_ like to know how you can differentiate between TCP and >> UDP given e.g. use of IPSec. (In a diffserv framework you cannot >> expect TCP and UDP to be marked separately, particularly if you're >> downstream. And, again, there's IPSec.) >> >> Watching flow behaviour can tell you which flows are controlled and >> congestion-sensitive or uncontrolled and not, so that you can treat >> them differently and ensure fairness, but it won't tell you whether a >> flow is intended as reliable or unreliable by its application, or >> whether it's (gack) TCP or UDP. Lest you get the wrong idea, the text I quoted (>> > ...) is not mine - I believe it was from an e-mail from Reiner. I do agree with you about the difficulties in distinguishing between TCP and UDP (not to mention differentiating between TCP flows which need to responsive, and UDPs which need to be reasonably reliable - this was partly a point of my earlier e-mail. *If* we are going to have some mechanism to convey information to the link layer, it needs to have a greater resolution). - nitin >> >> L. >> >> layeringabstractionlayeringabstractionlayeringabstraction. >> >> PGP >> >> >> >> From owner-pilc@lerc.nasa.gov Thu Sep 21 17:31: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 RAA14835 for ; Thu, 21 Sep 2000 17:31:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA21170 for pilc-outgoing; Thu, 21 Sep 2000 16:35:07 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA21102 for ; Thu, 21 Sep 2000 16:35:01 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA24209; Thu, 21 Sep 2000 16:34:59 -0400 Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024093; Thu, 21 Sep 00 16:34:20 -0400 Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id e8LKYGu11887; Thu, 21 Sep 2000 15:34:16 -0500 (CDT) Received: (from vaidya@localhost) by sun.cs.tamu.edu (8.11.0/8.11.0) id e8LKXaC26571; Thu, 21 Sep 2000 15:33:36 -0500 (CDT) Date: Thu, 21 Sep 2000 15:33:36 -0500 (CDT) From: Nitin H Vaidya Message-Id: <200009212033.e8LKXaC26571@sun.cs.tamu.edu> To: pilc@grc.nasa.gov, vjs@calcite.rhyolite.com Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk hi Vernon: >> From: Vernon Schryver ... >> Yes, response time matters, but if the link layer can't pass a particular >> TCP segment, then the link layer can't pass that particular TCP segment >> and any later bits in that TCP connection are also blocked. This presumes a single reachable wireless host - not true in general. If TCP segment to host A cannot get through, the link layer may be able to pass bits to some other host ? Of course, I am assuming that the wireless channel is shared between several hosts (if you have assigned fixed slots to a given host, then the above argument does not apply). A related issue: The buffer space for the packet that sits there for a long time could be used for other packets that are destined on more reliable channels (i.e., to other hosts). Again, this presumes that buffer space is a shared resources, and not pre-allocated on a per host basis. >> Moreover, I hope that except in extremely rare cases, if one particular >> segment won't fly for 64 seconds, then no other TCP segments or UDP/IP >> packets will fly, that the whole link is busted and not simply filtering >> a particular bit pattern. Like I said above, even if the channel to a given host may be busted, the channel to another host may be fine. >> Unlike voice, TCP and UDP are all or nothing (modulo proposals for UDP) >> stream and packet protocols, respectively. >> Most Internet applications are unlike plain ol' telephones, and >> cannot tolerate getting some of the right bits plus a few wrong bits. I think it is not reasonable to assume that because existing applications behave in a certain way, future applications will behave the same way. Older applications may not have been written for error-prone links. What prevents me from incorporating redundancy in an UDP stream? (such proposals have been made for multicasting, by the way, but for other reasons). By the way, since you are contrasting "voice" with "TCP/UDP", I guess you are ignoring voice-over-IP as a potential application for wireless. ... >> If the radios won't pass the data, then who are you going to inform of >> what and what do you want them to do about whatever they're told? In the Consider this picture: A --------------- B .... C where A is sending data to C, and link B-C is wireless. Even if link B-C is experiencing errors, B can send a message to node A. There have been several proposals on this theme. Of course, your point is valid if C were sending data packets to A. >> 64 second ARQ example, what do you propose instead? Do you want the HTTP >> server to break the TCP connection? Retransmit? Not retransmit? Breaking the TCP connection may be a reasonable option (it all depends on the application). >> In other words, please reconsider the famous "End to End Principle." Can you please elaborate on that? Do you mean that the "end-to-end principle" may not be valid anymore (so we need to reconsider it), or have I ignored the end-to-end principle? >> > Also, it may not be possible to reduce non-congestion losses >> > to a negligible level in all wireless environments. Even if we >> > somehow manage this in the last-hop wireless scenario, in >> > multi-hop mobile environment, this may not be practical - here, we >> > may have frequent losses due to route changes (carrying the >> > "fully reliable ARQ" argument to this case would require the >> > network layer to be "fully" reliable too!). >> >> Routing changes in the familiar part of the Internet do not necessarily >> imply packet loses. Protocols currently being proposed/implemented for ad hoc networks do result in plenty of packet losses on route changes. - nitin From owner-pilc@lerc.nasa.gov Thu Sep 21 19:22:49 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15839 for ; Thu, 21 Sep 2000 19:22:48 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA00554 for pilc-outgoing; Thu, 21 Sep 2000 18:36:39 -0400 (EDT) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA00543 for ; Thu, 21 Sep 2000 18:36:37 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id RAA03943; Thu, 21 Sep 2000 17:43:02 -0400 Received: from unknown(194.237.142.116) by seraph2.lerc.nasa.gov via smap (V5.5) id xma003314; Thu, 21 Sep 00 17:41: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 e8LLcPt13442; Thu, 21 Sep 2000 23:38:25 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160157.am.ericsson.se [138.85.160.157]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA29194; Thu, 21 Sep 2000 23:38:14 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000921225529.00c09aa0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 23:04:24 +0200 To: L.Wood@eim.surrey.ac.uk From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: References: <200009211430.e8LEUkY26251@sun.cs.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 18:04 21.09.00 +0100, Lloyd Wood wrote: >I'd _really_ like to know how you can differentiate between TCP and >UDP given e.g. use of IPSec. And also this had been discussed before. But, so what ... Yes, Lloyd, you're right with IPsec there is really no way you can distinguish TCP flows from the rest since the IP proto-ID field gets overwritten by IPsec. This is why I really wish we still had the old TOS-byte semantics which would have been ideal for such "application to link layer" signalling. It could have been used by the source to say: "hey, this flow is marked as being a reliable flow (TCP, Reliable Multicast, NFS, ...)". On the other hand, with IPsec also any ICMP-Kick-TCP scheme is screwed because the port numbers are also encrypted. Or do we want to tell the receiving Web server to forward the ICMP signal to all 1000 of it's TCP connections? (one might get around this if the entire packet is returned with the ICMP message *and* the source is able to decrypt it again). ///Reiner From owner-pilc@lerc.nasa.gov Thu Sep 21 19:22:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15850 for ; Thu, 21 Sep 2000 19:22:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA00096 for pilc-outgoing; Thu, 21 Sep 2000 18:35: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 SAA00028 for ; Thu, 21 Sep 2000 18:35:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA13674; Thu, 21 Sep 2000 18:32:33 -0400 Received: from unknown(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006221; Thu, 21 Sep 00 17:41:03 -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 e8LLcBZ19687; Thu, 21 Sep 2000 23:38:11 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160157.am.ericsson.se [138.85.160.157]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA29183; Thu, 21 Sep 2000 23:37:53 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000921222258.00c0c100@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 22:52:15 +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: <39CA06C4.4F3ADA4@erg.abdn.ac.uk> References: <4.3.2.7.0.20000920200846.00cb2ba0@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 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. 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. >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 think there is evidence that at least some of >these >links have in the past performed very poorly with reliable ARQ protocols. So, now I'm really interested in that evidence. Where is it? >Link outages are a specific characteristic. May be our recommendations for >outages >should differ from other types of errors (I can see merit in this). I still haven't seen any good reasons for it. >During an >outage >no retransmission scheme is going to succeed at the link layer and the transport layer. That's the point! TCP will not make any progress no matter whether TCP or the link layer holds on to the packets. >- some physical >layer (coding, etc) may succeed Right. FEC and other physical layer mechanisms are an orthogonal issue. They need to be in place, anyway. >- After an outage, we need to resume >transmission >at the link layer of the data which failed to be sent. This is what the >current >draft >advises subnet designers with outages. It is in effect a support for reliable >ARQ, Resuming transmission at the link layer after an outage is what I call persistent link layer error recovery (ARQ). It doesn't mean that the link layer really tries to transmit frames all the time during the outage. It also doesn't mean that it buffers packets beyond a reasonable buffer size. ///Reiner From owner-pilc@lerc.nasa.gov Thu Sep 21 19:24:50 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 TAA15874 for ; Thu, 21 Sep 2000 19:24:50 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02247 for pilc-outgoing; Thu, 21 Sep 2000 18:40:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA02203 for ; Thu, 21 Sep 2000 18:40:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA16273; Thu, 21 Sep 2000 18:40:27 -0400 Received: from unknown(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006263; Thu, 21 Sep 00 17:41:23 -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 e8LLcZt13450; Thu, 21 Sep 2000 23:38:35 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160157.am.ericsson.se [138.85.160.157]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA29224; Thu, 21 Sep 2000 23:38:29 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000921230500.00c0e490@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 23:15:34 +0200 To: Nitin H Vaidya From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: <200009211822.e8LIMpE26476@sun.cs.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 13:22 21.09.00 -0500, Nitin H Vaidya wrote: >I do agree with you about the difficulties in distinguishing between TCP >and UDP (not to mention differentiating between TCP flows which >need to responsive, No matter how delay-sensitive the application ontop of TCP is (e.g. telnet vs. ftp), *all* those packets have to make it across the link. Thus, *for those packets* you can afford to be as persistent with ARQ at the link layer as TCP is at the transport layer. >*If* we are going to have some >mechanism to convey information to the link layer, it needs to have a >greater resolution). I agree with you here. ///Reiner From owner-pilc@lerc.nasa.gov Thu Sep 21 19:28:32 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 TAA15924 for ; Thu, 21 Sep 2000 19:28:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA00076 for pilc-outgoing; Thu, 21 Sep 2000 18:35:21 -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 SAA00030 for ; Thu, 21 Sep 2000 18:35:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA13843; Thu, 21 Sep 2000 18:33:54 -0400 Received: from unknown(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006281; Thu, 21 Sep 00 17:41:40 -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 e8LLcmt13454; Thu, 21 Sep 2000 23:38:48 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160157.am.ericsson.se [138.85.160.157]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA29231; Thu, 21 Sep 2000 23:38:38 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000921231927.00c0e7f0@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Sep 2000 23:33:10 +0200 To: "Al-hussein Abou-zeid" From: Reiner Ludwig Subject: Re: pilc minutes for IETF 48 Cc: pilc@grc.nasa.gov In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@lerc.nasa.gov Precedence: bulk At 16:45 21.09.00 +0000, Al-hussein Abou-zeid wrote: If you have a reliable link layer protocol (ARQ) _and_ you tune the error >>recovery persistency of that protocol to a high value like 64 seconds >>(TCP's max. RTO), you pretty much eliminate losses but trade them for delay. > >And, is this good/acceptable? How will this affect your TCP link? Also, >could you please give a pointer to where exactly in your thesis (since you >have referenced it in many previous e-mails) do you analyse this case? Sections 4.1.4 and 4.3.3. Which you can also read as a paper: http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/ >I do not think that the problems an erroneous link poses on TCP can be >treated by assuming we have a magic ARQ that turns it to a high quality >link, without paying something for that ARQ What you pay is delay. But, for TCP this rarely becomes a problem because the TCP retransmission timer is way conservative (section 5.3 of my thesis or http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Xmit/index.html) and if it becomes a problem is can easily be solved in TCP (section 5.1 & 5.2 of my thesis or http://iceberg.cs.berkeley.edu/papers/Ludwig-Eifel-Alg/index.html) >(If we had such an ARQ, we would have solved all erroneous link problems >whether or not we are using them for TCP). No, we should only use persistent link layer ARQ for reliable flows such as those based on TCP. Not for delay-sensitive UDP. >Even assuming we can distinguish flows at the link layer, I think the link >layer proposal "ARQ forever" deserves, at least, some evalution of its >impact from an end-to-end prespective, as well as a per-link prespective, >in addition to the previous comments above. You're welcome to do that evaluation. Just remember that there are number of such evaluations by a number of authors in the literature already that you might want to check out first. ///Reiner From owner-pilc@lerc.nasa.gov Thu Sep 21 19:46:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16026 for ; Thu, 21 Sep 2000 19:46:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03202 for pilc-outgoing; Thu, 21 Sep 2000 18:43: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 SAA03195 for ; Thu, 21 Sep 2000 18:43:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA13101; Thu, 21 Sep 2000 18:28:30 -0400 Received: from unknown(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006280; Thu, 21 Sep 00 17:41:35 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8LLclb04460 for pilc@grc.nasa.gov env-from ; Thu, 21 Sep 2000 15:38:47 -0600 (MDT) Date: Thu, 21 Sep 2000 15:38:47 -0600 (MDT) From: Vernon Schryver Message-Id: <200009212138.e8LLclb04460@calcite.rhyolite.com> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Nitin H Vaidya > >> Yes, response time matters, but if the link layer can't pass a particular > >> TCP segment, then the link layer can't pass that particular TCP segment > >> and any later bits in that TCP connection are also blocked. > > This presumes a single reachable wireless host - not true in general. > If TCP segment to host A cannot get through, the link layer may be > able to pass bits to some other host ? > Of course, I am assuming that the wireless channel is shared between > several hosts (if you have assigned fixed slots to a given host, then > the above argument does not apply). It seems as if you are assuming that link layer ARQ treats the stream much as TCP does a single TCP connection. I don't see why link layer ARQ cannot transmit and retransmit upper layer packets (IP) independently of each other. TCP/IP and UDP/IP are not voice that cannot tolerate re-ordering. All IP applications are required to deal with out-of-order IP packets. TCP does not like its segments re-ordered but it does cope. Any UDP application must also cope with out-of-order delivery. See also TCP SAK, which allows TCP to retransmit smarter than go-back-N. > A related issue: > The buffer space for the packet that sits there for a long time > could be used for other packets that are destined on more > reliable channels (i.e., to other hosts). > Again, this presumes that buffer space is a shared resources, and > not pre-allocated on a per host basis. I suspect you're also assuming that the buffer space is a simplistic ring buffer of bytes instead of a more sophisticated structure that supports continuing to retry packet N while receiving and passing on packets N+1 through N+many. > >> Moreover, I hope that except in extremely rare cases, if one particular > >> segment won't fly for 64 seconds, then no other TCP segments or UDP/IP > >> packets will fly, that the whole link is busted and not simply filtering > >> a particular bit pattern. > > Like I said above, even if the channel to a given host may be busted, > the channel to another host may be fine. Would you do ARQ for a bunch of mobile stations in concert, so that if one packet to one station doesn't get Ack'ed, then all packets to all stations stall? If not then I don't understand what you mean. I hope that the link between each pair of stations (whether one mobile and one fixed or a pair of mobile or a pair of fixed) would be handled independently of the links between all other pairs of stations. > >> Unlike voice, TCP and UDP are all or nothing (modulo proposals for UDP) > >> stream and packet protocols, respectively. > >> Most Internet applications are unlike plain ol' telephones, and > >> cannot tolerate getting some of the right bits plus a few wrong bits. > > I think it is not reasonable to assume that because existing > applications behave in a certain way, future applications will > behave the same way. That sounds like the familiar wireless "all the world is going to change to accomodate wireless as it was seen in 1997" thinking (yes, 1997 or maybe 199). Applications will change, but wireless link layers will do far more changing, and will end acting more like a land line. Land data lines started out about where wireless data is now, and they got to where they are now for good reasons. Yes, the physics of wireless will always differ, but the services offered to upper layers will converge. > Older applications may not have been written > for error-prone links. The reason we have link layer CRC's, FCS's, and FEC is because in the last 40 years it has been found better to put error detection, correction, and recovery below the applications and even mostly below transport. However, there are plenty of applications that tolerate the only errors that can get past UDP (esp. various voice/IP for the last 10+ years--yes, 10+ in my personal experince) > What prevents me from incorporating redundancy > in an UDP stream? (such proposals have been made for multicasting, by > the way, but for other reasons). UDP packets can be dropped, but you wrote about TCP. Besides, each UDP packet is an all or nothing proposition. Your only choice is between link-layer ARQ and discarding UDP packets, or some combination of the two (e.g. ARQ for a while and then give up). > By the way, since you are contrasting "voice" with "TCP/UDP", I guess > you are ignoring voice-over-IP as a potential application for wireless. No, I was pointing out that unlike plain old telephone where plenty of wrong or missing bits are just fine, broken TCP and UDP bits must either be discarded and retransmitted (at least for TCP) or you have link layer ARQ (and/or FEC). > ... > >> If the radios won't pass the data, then who are you going to inform of > >> what and what do you want them to do about whatever they're told? In the > > Consider this picture: > > A --------------- B .... C > > where A is sending data to C, and link B-C is wireless. > Even if link B-C is experiencing errors, B can send a message > to node A. There have been several proposals on this theme. > Of course, your point is valid if C were sending data > packets to A. People exerienced with IP stuff generally assume there are several links between then ends. I think most would also treat A<-->C, A<-->B, and B<-->C as three independent cases. IP multicast complicates that a little, but only a little. > ... > >> In other words, please reconsider the famous "End to End Principle." > > Can you please elaborate on that? > Do you mean that the "end-to-end principle" may not be valid anymore > (so we need to reconsider it), or have I ignored the end-to-end principle? Anything that wants to tell the TCP or UDP state machines at either end of a path something about one link in the middle of the path is certainly stretching the end-to-end principle and probably completely ignoring it. > ... > >> Routing changes in the familiar part of the Internet do not necessarily > >> imply packet loses. > > Protocols currently being proposed/implemented for ad hoc networks > do result in plenty of packet losses on route changes. I bristle at that sentence and most at the phrase "ad hoc networks" that seems to suggest that wireless links are revolutionary as far as IP is concerned. I don't quite know why, but IP over wireless has a history claims that wireless links are completely different from any kind of links that IP has ever seen before. The incredibly ignornat claim I recently found in a trade rag that TCP/IP cannot run on a 9600 bit/sec link and therefore we must use WAP is merely an extreme example of the syndrome. As I see them, wireless links are merely very fast (yes, fast) old style modems with slightly higher than usual error rates (yes, only slightly). The errors wireless people worry about wireless modems don't sound much different from what happened when someone picked up an extension on your TCP/IP/SLIP/modem connection, not to mention the purely analogy phone lines that made Telebit Trailblazers so popular. Even the choice between ARQ (e.g. Trailblazer or years later, v.42) and ~u or other noise (type 103 through various 9600 bps) is familiar. Vernon Schryver vjs@rhyolite.com From owner-pilc@lerc.nasa.gov Thu Sep 21 20:21: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 UAA16328 for ; Thu, 21 Sep 2000 20:21:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA05747 for pilc-outgoing; Thu, 21 Sep 2000 19:11:21 -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 TAA05733 for ; Thu, 21 Sep 2000 19:11:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA24072; Thu, 21 Sep 2000 19:11:18 -0400 Received: from f249.law3.hotmail.com(209.185.241.249) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023872; Thu, 21 Sep 00 19:10:41 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Sep 2000 16:10:40 -0700 Received: from 206.17.239.228 by lw3fd.law3.hotmail.msn.com with HTTP; Thu, 21 Sep 2000 23:10:40 GMT X-Originating-IP: [206.17.239.228] From: "Al-hussein Abou-zeid" To: Reiner.Ludwig@ericsson.com Cc: pilc@grc.nasa.gov, hussein@wins.hrl.com Subject: Re: pilc minutes for IETF 48 Date: Thu, 21 Sep 2000 23:10:40 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Sep 2000 23:10:40.0612 (UTC) FILETIME=[28F63A40:01C02421] Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Hi Reiner, >From: Reiner Ludwig >To: "Al-hussein Abou-zeid" >CC: pilc@grc.nasa.gov >Subject: Re: pilc minutes for IETF 48 >Date: Thu, 21 Sep 2000 23:33:10 +0200 > >At 16:45 21.09.00 +0000, Al-hussein Abou-zeid wrote: >If you have a reliable link layer protocol (ARQ) _and_ you tune the error >>>recovery persistency of that protocol to a high value like 64 seconds >>>(TCP's max. RTO), you pretty much eliminate losses but trade them for >>>delay. >> >>And, is this good/acceptable? How will this affect your TCP link? Also, >>could you please give a pointer to where exactly in your thesis (since you >>have referenced it in many previous e-mails) do you analyse this case? > >Sections 4.1.4 and 4.3.3. Which you can also read as a paper: >http://iceberg.cs.berkeley.edu/papers/Ludwig-WINET99/ Your above mentioned paper states that "link layer error recovery over wireless links for reliable flows", "based on a case study of the circuit-switched data channel imlementation in GSM" "yields an improvement of up to 25 percent when the channel quality is good and 18 percent even under poor radio conditions". "The improvement is accomplished by using a larger (fixed) link layer frame size". "These results highlight the importance of measurement-based analysis in wireless networks where protocol performance is highly dependent on the error characteristcis of the wirless channel". which is surprisingly close in principle to my original e-mail, >>Two comments; First, the performance of TCP is sensitive to the specific >>wireless medium characteristics, especially loss behavior >>So, there are no magic TCP values that would work for any wireless >>link. Second, what do you mean by a "right link layer". Is there such a >>thing? If you mean a wireless link that is as pure >>as an optical link, or even a twisted pair, then, this >>it is probably a very special case of a wireless link. Also, the paper you site has no mention of ARQ schemes or their tuning, which is the point of discussion! Regards, Hussein. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-pilc@lerc.nasa.gov Thu Sep 21 20:47:11 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 UAA16493 for ; Thu, 21 Sep 2000 20:47:10 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA08423 for pilc-outgoing; Thu, 21 Sep 2000 19:52: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 TAA08400 for ; Thu, 21 Sep 2000 19:52:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA04375; Thu, 21 Sep 2000 19:52:54 -0400 Received: from mail6.southeast.rr.com(24.93.67.53) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004297; Thu, 21 Sep 00 19:52:36 -0400 Received: from v3f6b5 ([24.25.25.53]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.357.35); Thu, 21 Sep 2000 19:48:52 -0400 From: "Injong Rhee" To: "Reiner Ludwig" , Cc: Subject: RE: pilc minutes for IETF 48 Date: Thu, 21 Sep 2000 19:46:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.0.20000921225529.00c09aa0@chapelle.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Then with IP-sec, how should we solve the differentiation problem? It seems there is no solution. Then should we apply arq at all? I guess the best option is no-arq. -----Original Message----- From: owner-pilc@lerc.nasa.gov [mailto:owner-pilc@lerc.nasa.gov]On Behalf Of Reiner Ludwig Sent: Thursday, September 21, 2000 2:04 PM To: L.Wood@eim.surrey.ac.uk Cc: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 At 18:04 21.09.00 +0100, Lloyd Wood wrote: >I'd _really_ like to know how you can differentiate between TCP and >UDP given e.g. use of IPSec. And also this had been discussed before. But, so what ... Yes, Lloyd, you're right with IPsec there is really no way you can distinguish TCP flows from the rest since the IP proto-ID field gets overwritten by IPsec. This is why I really wish we still had the old TOS-byte semantics which would have been ideal for such "application to link layer" signalling. It could have been used by the source to say: "hey, this flow is marked as being a reliable flow (TCP, Reliable Multicast, NFS, ...)". On the other hand, with IPsec also any ICMP-Kick-TCP scheme is screwed because the port numbers are also encrypted. Or do we want to tell the receiving Web server to forward the ICMP signal to all 1000 of it's TCP connections? (one might get around this if the entire packet is returned with the ICMP message *and* the source is able to decrypt it again). ///Reiner From owner-pilc@lerc.nasa.gov Thu Sep 21 21:30: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 VAA16854 for ; Thu, 21 Sep 2000 21:30:46 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA10792 for pilc-outgoing; Thu, 21 Sep 2000 20:32: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 UAA10770 for ; Thu, 21 Sep 2000 20:32:27 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA13629; Thu, 21 Sep 2000 20:32:27 -0400 Received: from comm.engr.uvic.ca(142.104.96.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013451; Thu, 21 Sep 00 20:31:33 -0400 Received: from blake (blake [142.104.115.103]) by engr.UVic.CA (8.10.2/8.10.2-Engr.UVic.CA-G) with SMTP id e8M0Uhx07907; Thu, 21 Sep 2000 17:30:43 -0700 (PDT) Date: Thu, 21 Sep 2000 17:31:44 -0700 (PDT) From: Ekram Hossain X-Sender: ekram@blake To: Reiner Ludwig cc: gorry@erg.abdn.ac.uk, pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 In-Reply-To: <4.3.2.7.0.20000921222258.00c0c100@chapelle.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > 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. Hi Reiner: I want to mention about some of our recent experimentations regarding the performance of wide-area TCP connections in a cellular WCDMA environment. What we have observed is, persistence on retransmission in the link layer is effective only under certain channel load condition. In fact, in a WCDMA environment (which allows variable rate transmission at the link layer), increasing the number of allowable retransmissions in the link layer improves TCP goodput when the channel load is neither too small nor too high. As the number of active TCP connections (passing through the BS) becomes large, link layer retransmissions are no longer beneficial. Anyway, some of the results will be presented in the coming IEEE ICPWC'2000 in India (http://www.citr.ece.uvic.ca/ICPWC2000/). ----------- Ekram From owner-pilc@lerc.nasa.gov Thu Sep 21 23:12: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 XAA19486 for ; Thu, 21 Sep 2000 23:12:24 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16212 for pilc-outgoing; Thu, 21 Sep 2000 22:05: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 WAA16198 for ; Thu, 21 Sep 2000 22:05:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA04790; Thu, 21 Sep 2000 22:05:39 -0400 Received: from clavin.cs.tamu.edu(128.194.130.106) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004642; Thu, 21 Sep 00 22:05:30 -0400 Received: from photon.cs.tamu.edu (IDENT:2654@photon [128.194.134.1]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id e8M24lP22104 for ; Thu, 21 Sep 2000 21:04:47 -0500 (CDT) Received: (from vaidya@localhost) by photon.cs.tamu.edu (8.11.0/8.11.0) id e8M24rC09823 for pilc@grc.nasa.gov; Thu, 21 Sep 2000 21:04:53 -0500 (CDT) Date: Thu, 21 Sep 2000 21:04:53 -0500 (CDT) From: Nitin H Vaidya Message-Id: <200009220204.e8M24rC09823@photon.cs.tamu.edu> To: pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >> From: Vernon Schryver >> >> > I think it is not reasonable to assume that because existing >> > applications behave in a certain way, future applications will >> > behave the same way. >> >> That sounds like the familiar wireless "all the world is going to change >> to accomodate wireless as it was seen in 1997" thinking (yes, 1997 or >> maybe 199). Applications will change, but wireless link layers will do >> far more changing, and will end acting more like a land line. I agree that wireless link layers might do a lot of changing. Not as confident that they will in the end look more like a land line - hopefully, you are right, >> > What prevents me from incorporating redundancy >> > in an UDP stream? (such proposals have been made for multicasting, by >> > the way, but for other reasons). >> >> UDP packets can be dropped, but you wrote about TCP. >> Besides, each UDP packet is an all or nothing proposition. >> Your only choice is between link-layer ARQ and discarding UDP packets, >> or some combination of the two (e.g. ARQ for a while and then give up). What I was refering to is redundant UDP packets (e.g., one "check" packet for every 8 "data" packets), not redundancy "within" a UDP packet, (incidentally, there is an interesting issue here regarding the trade-offs between the ability to "correct" a packet loss using the redundancy, and the potential increase in loss rate due to increased congestion.) >> > Consider this picture: >> > >> > A --------------- B .... C >> > >> > where A is sending data to C, and link B-C is wireless. >> > Even if link B-C is experiencing errors, B can send a message >> > to node A. There have been several proposals on this theme. >> > Of course, your point is valid if C were sending data >> > packets to A. >> >> People exerienced with IP stuff generally assume there are several links >> between then ends. I think most would also treat A<-->C, A<-->B, and >> B<-->C as three independent cases. IP multicast complicates that a little, >> but only a little. I do not understand what you are saying. Granted that the A--B path will usually have multiple hops (which is what I was suggesting by a long -------------- link as opposed to short ---- link -:) But I do not get what you saying here. >> > Do you mean that the "end-to-end principle" may not be valid anymore >> > (so we need to reconsider it), or have I ignored the end-to-end principle? >> >> Anything that wants to tell the TCP or UDP state machines at either >> end of a path something about one link in the middle of the path >> is certainly stretching the end-to-end principle and probably completely >> ignoring it. Well, the feedback does not have to say that "link from B to C lost packet P due to errors" - it is enough to feed back that "packet P was lost due to errors. Would this violate the end-to-end principle ? Incidentally, would a "fully reliable link layer" conform to the end-to-end principle ? >> I bristle at that sentence and most at the phrase "ad hoc networks" that >> seems to suggest that wireless links are revolutionary as far as IP >> is concerned. >> I don't quite know why, but IP over wireless has a history claims that >> wireless links are completely different from any kind of links that IP >> has ever seen before. Clearly, the fact that a link is wireless by itself makes it no different from a wired links. The question I guess is whether the designers will ever design a wireless link to look like today's wireline links. >> The incredibly ignornat claim I recently found in a trade rag that TCP/IP >> cannot run on a 9600 bit/sec link and therefore we must use WAP is merely >> an extreme example of the syndrome. I will be happy to join in WAP-bashing ... I am not a fan of WAP either (although I hear WAP 2.0, or whatever the number is these days, is an improvement). Enough said. I do not think I have much more to add to what I have already said ... so I will shut up for a little while. Regards. - nitin From owner-pilc@lerc.nasa.gov Fri Sep 22 06:42: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 GAA04920 for ; Fri, 22 Sep 2000 06:42:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA11195 for pilc-outgoing; Fri, 22 Sep 2000 05:41:28 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA11180 for ; Fri, 22 Sep 2000 05:41:26 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA02870; Fri, 22 Sep 2000 05:41:25 -0400 Received: from albatross-ext.wise.edt.ericsson.se(194.237.142.116) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002816; Fri, 22 Sep 00 05:41:13 -0400 Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id e8M9fBt16521 for ; Fri, 22 Sep 2000 11:41:11 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Sep 22 11:34:29 2000 +0200 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 22 Sep 2000 11:40:21 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941019EF74C@edeacnt100.eed.ericsson.se> From: "Michael Meyer (EED)" To: "'Ekram Hossain'" Cc: pilc@grc.nasa.gov Subject: RE: pilc minutes for IETF 48 Date: Fri, 22 Sep 2000 11:40:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk >I want to mention about some of our recent experimentations regarding >the performance of wide-area TCP connections >in a cellular WCDMA environment. What we have observed is, >persistence on >retransmission in the link layer is effective only under >certain channel >load condition. In fact, in a WCDMA environment (which allows variable >rate transmission at the link layer), increasing the number of >allowable >retransmissions in the link layer improves TCP goodput when the channel >load is neither too small nor too high. As the number of active TCP >connections (passing through the BS) becomes large, link layer >retransmissions are no longer beneficial. > I would like to know more about your assumptions on WCDMA. I can not see the reasons why retransmissions are not longer beneficial any more for many connections in a cell. Do you mean that the interference becomes too high and therefore also the block error rate? Which mechanisms do you consider to control the block eror rate? /Michael From owner-pilc@lerc.nasa.gov Fri Sep 22 07:06: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 HAA05458 for ; Fri, 22 Sep 2000 07:06:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA11728 for pilc-outgoing; Fri, 22 Sep 2000 05:54: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 FAA11710 for ; Fri, 22 Sep 2000 05:54:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA05371; Fri, 22 Sep 2000 05:54:28 -0400 Received: from comm.engr.uvic.ca(142.104.96.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005223; Fri, 22 Sep 00 05:53:34 -0400 Received: from blake (blake [142.104.115.103]) by engr.UVic.CA (8.10.2/8.10.2-Engr.UVic.CA-G) with SMTP id e8M9r0x25610; Fri, 22 Sep 2000 02:53:00 -0700 (PDT) Date: Fri, 22 Sep 2000 02:54:03 -0700 (PDT) From: Ekram Hossain X-Sender: ekram@blake To: "Michael Meyer (EED)" cc: pilc@grc.nasa.gov Subject: RE: pilc minutes for IETF 48 In-Reply-To: <5E5172B4DE05D311B3AB0008C75DA941019EF74C@edeacnt100.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > >I want to mention about some of our recent experimentations regarding > >the performance of wide-area TCP connections > >in a cellular WCDMA environment. What we have observed is, > >persistence on > >retransmission in the link layer is effective only under > >certain channel > >load condition. In fact, in a WCDMA environment (which allows variable > >rate transmission at the link layer), increasing the number of > >allowable > >retransmissions in the link layer improves TCP goodput when the channel > >load is neither too small nor too high. As the number of active TCP > >connections (passing through the BS) becomes large, link layer > >retransmissions are no longer beneficial. > > > > I would like to know more about your assumptions on WCDMA. I can not > see the reasons why retransmissions are not longer beneficial any more > for many connections in a cell. Do you mean that the interference > becomes too high and therefore also the block error rate? Which > mechanisms do you consider to control the block eror rate? As the no. of active TCP connections increases, the link layer transmission rate (which is chosen according to a sub-optimal rate selection algorithm to have the minimum block error rate) decreases. This increases the RTT value and presumably there are more timeouts. As a result, for a fixed maximum window size, the steady-state TCP throughput decreases. In fact, TCP throughput can be very sensitive to the number of active TCP connections in a WCDMA environment. Adaptive FEC at the link level might be a better solution than ARQ in such an environment. Regards. Ekram From owner-pilc@lerc.nasa.gov Fri Sep 22 10:07:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14447 for ; Fri, 22 Sep 2000 10:07:35 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA13057 for pilc-outgoing; Fri, 22 Sep 2000 09:00:13 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA13039 for ; Fri, 22 Sep 2000 09:00:11 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA18245; Fri, 22 Sep 2000 09:00:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se(194.237.142.110) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017666; Fri, 22 Sep 00 08:59:30 -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 e8MCxPZ15785; Fri, 22 Sep 2000 14:59:25 +0200 (MEST) Received: from E00D05905E94A.eed.ericsson.se (rmt160163.am.ericsson.se [138.85.160.163]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id OAA04132; Fri, 22 Sep 2000 14:59:14 +0200 (MET DST) Message-Id: <4.3.2.7.0.20000922144817.00aefd90@chapelle.ericsson.se> X-Sender: eedrel@chapelle.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Sep 2000 14:53:27 +0200 To: "Injong Rhee" From: Reiner Ludwig Subject: RE: pilc minutes for IETF 48 Cc: In-Reply-To: References: <4.3.2.7.0.20000921225529.00c09aa0@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 19:46 21.09.00 -0700, Injong Rhee wrote: >Then with IP-sec, how should we solve the differentiation problem? It seems >there is no solution. I agree. This is a difficult problem that remains to be solved. Maybe we need to get some e2e semantics back into the DS field .... ? >Then should we apply arq at all? I guess the best >option is no-arq. I agree. No link layer ARQ at all or at least with a very low error recovery persistency (<< 1 second). ///Reiner From owner-pilc@lerc.nasa.gov Fri Sep 22 10:40:42 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15714 for ; Fri, 22 Sep 2000 10:40:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA17207 for pilc-outgoing; Fri, 22 Sep 2000 09:27:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA17171 for ; Fri, 22 Sep 2000 09:27:53 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA14659; Fri, 22 Sep 2000 09:27:52 -0400 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014118; Fri, 22 Sep 00 09:27:22 -0400 Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 13cSr7-0004BD-00; Fri, 22 Sep 2000 14:27:09 +0100 Date: Fri, 22 Sep 2000 14:27:06 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Reiner Ludwig cc: Nitin H Vaidya , pilc@grc.nasa.gov Subject: Re: pilc minutes for IETF 48 In-Reply-To: <4.3.2.7.0.20000921230500.00c0e490@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 Thu, 21 Sep 2000, Reiner Ludwig wrote: > At 13:22 21.09.00 -0500, Nitin H Vaidya wrote: > >I do agree with you about the difficulties in distinguishing between TCP > >and UDP (not to mention differentiating between TCP flows which > >need to responsive, > > No matter how delay-sensitive the application ontop of TCP is (e.g. telnet > vs. ftp), *all* those packets have to make it across the link. that's a fallacy. a single copy of the data that the packets contain has to make it across the link - eventually. You can afford to drop some packets. L. > Thus, *for > those packets* you can afford to be as persistent with ARQ at the link > layer as TCP is at the transport layer. PGP From owner-pilc@lerc.nasa.gov Fri Sep 22 13:52:13 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 NAA21787 for ; Fri, 22 Sep 2000 13:52:12 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA28366 for pilc-outgoing; Fri, 22 Sep 2000 12:05: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 MAA28279 for ; Fri, 22 Sep 2000 12:05:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA20795; Fri, 22 Sep 2000 12:05:11 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020272; Fri, 22 Sep 00 12:04:46 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8MG4iX25698 env-from ; Fri, 22 Sep 2000 10:04:44 -0600 (MDT) Date: Fri, 22 Sep 2000 10:04:44 -0600 (MDT) From: Vernon Schryver Message-Id: <200009221604.e8MG4iX25698@calcite.rhyolite.com> To: pilc@grc.nasa.gov, vaidya@cs.tamu.edu Subject: Re: pilc minutes for IETF 48 Sender: owner-pilc@lerc.nasa.gov Precedence: bulk > From: Nitin H Vaidya > ... > >> > Consider this picture: > >> > > >> > A --------------- B .... C > >> > > >> > where A is sending data to C, and link B-C is wireless. > >> > Even if link B-C is experiencing errors, B can send a message > >> > to node A. There have been several proposals on this theme. > >> > Of course, your point is valid if C were sending data > >> > packets to A. > ... > I do not understand what you are saying. Granted that the A--B > path will usually have multiple hops (which is what I was suggesting > by a long -------------- link as opposed to short ---- link -:) > But I do not get what you saying here. I'm saying that you must pick one of the three links, A--C, A--B, or B--C, to talk about. You shouldn't argue, as you seemed to, that what A and B can do is relevant to what A and C can do. Or in perhaps better words, you cannot assume that there is exactly one dotted line "...." link in the path between A and C or even that the number of dotted line links is constant. > ... > >> Anything that wants to tell the TCP or UDP state machines at either > >> end of a path something about one link in the middle of the path > >> is certainly stretching the end-to-end principle and probably completely > >> ignoring it. > > Well, the feedback does not have to say that "link from B to C > lost packet P due to errors" - it is enough to feed back > that "packet P was lost due to errors. Would this violate the > end-to-end principle ? Depending on many things including what it means, I think the answer to that is "probably but not necessarily." The ends already know that "packet P was lost due to errors" if they care--else TCP could not be a reliable protocol. The most that a link can affect is when the ends know. > Incidentally, would a "fully reliable link layer" conform > to the end-to-end principle ? That's the wrong kind of question. The only answer is "huh?" My take on the end-to-end principle is that the ends worry about everything related to the overall application, while individual links are dumb and do no more than make best efforts to get through packets their little parts of the path. Individual links are the tail of the dog. Whenever you propose making even the slightest change in TCP, UDP, the end hosts, or the applications to accomodate the special characteristics of a link, whether it is a link with ~9600 bit/sec throughput, 80 or 300 millisecond delays, and suffers burst errors lasting 1-20 seconds or some other kind, you are probably breaking the end to end principle and making a serious design error. (Anyone who thinks I'm trying to describe a wireless link is wrong. I'm describing something popular 12 years ago.) > >> I don't quite know why, but IP over wireless has a history claims that > >> wireless links are completely different from any kind of links that IP > >> has ever seen before. > > Clearly, the fact that a link is wireless by itself makes > it no different from a wired links. The question I guess is whether > the designers will ever design a wireless link to look like > today's wireline links. That's very interesting but not as interesting as the questions 1. how do wireless links differ from other links used for IP 2. has TCP been run or is it run over links similar to wireless links? The standard wireless answers, "completely" and "never at all," are not impressive. The real answers to those two questions and the reasons many have never heard of counterexamples to the standard wireless answers bear on the question of how wireless links will change. It wasn't that those old links didn't work or that their principles of operation would not be useful today. From owner-pilc@lerc.nasa.gov Fri Sep 22 15:33: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 PAA25324 for ; Fri, 22 Sep 2000 15:33:15 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA10691 for pilc-outgoing; Fri, 22 Sep 2000 14:33: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 OAA10612 for ; Fri, 22 Sep 2000 14:33:49 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA21308; Fri, 22 Sep 2000 14:33:48 -0400 Received: from motgate.mot.com(129.188.136.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020696; Fri, 22 Sep 00 14:32:59 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA03932 for ; Fri, 22 Sep 2000 11:32:59 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA05483 for ; Fri, 22 Sep 2000 11:32:19 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Sep 2000 13:31:31 -0500 Message-ID: From: Crocker Ron-QA1007 To: pilc@grc.nasa.gov Subject: RE: pilc minutes for IETF 48 Date: Fri, 22 Sep 2000 13:31:29 -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 > -----Original Message----- > > Clearly, the fact that a link is wireless by itself makes > > it no different from a wired links. The question I guess is whether > > the designers will ever design a wireless link to look like > > today's wireline links. > > That's very interesting but not as interesting as the questions > 1. how do wireless links differ from other links used for IP They're completely different. :) (Sorry, couldn't resist) Wireless links (in a public network setting, like cellular) exhibit 3 characteristics counter to other links providing an IP: a) Slow (relative to other media - 9.6Kbps - 14.4Kbps typical, though higher rates are coming) b) Noisy (bit error rates on the order of 10**-2 - 10**-4, 3 to 5 orders of magnitude worse than wires) c) Expensive (relative to PSTN/ISDN connections of equivalent capability) In exchange for these characteristics, you get the ability to move about freely (so to speak), within certain boundaries, without being tethered to some place. The "trick" in building cellular systems is to find a way to balance those three characteristics to provide a cost-effective solution. Wireless often implies [public] cellular radio, but that's not necessarily accurate. 802.11 is wireless. I get pretty good service on it too, if I'm close enough to the access point and not too many other people are around. 802.11 is DS spread spectrum, but it's not public in the same sense as cellular. It's low power in an unlicensed band. It will compete with garage door openers and cordless telephones as interference sources. Cable modems are RF, but on wires. DOCSIS says that it's 64QAM; my interpretation (after 5 minutes of study, so I can likely be wrong) is that's to everyone all the time. In a cellular system, that modulation is available in nominally 3% of the cell. > 2. has TCP been run or is it run over links similar to > wireless links? Yes, of course it has. IIRC, the problems with TCP have been related to interactions between 1 particular characteristic above (noise), its mediations (retransmissions on the link), and TCP characteristics. > > The standard wireless answers, "completely" and "never at > all," are not > impressive. > The real answers to those two questions and the reasons many > have never > heard of counterexamples to the standard wireless answers bear on the > question of how wireless links will change. It wasn't that those old > links didn't work or that their principles of operation would not be > useful today. ["Didn't work" is, I'll claim, a matter of opinion. You probably wouldn't run streaming video or voice over them, but you could (generally) do SMTP/POP and HTTP services, even with CDPD. These services are TCP-based, aren't they?] Maybe I'm being particularly dense today, but I thought that was the charter of this group, to define the principles of operations for these kinds of links. That definition would be useful to both camps - the wireless guys and the internet guys - to better understand both worlds. Ron From owner-pilc@lerc.nasa.gov Mon Sep 25 02:49:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28017 for ; Mon, 25 Sep 2000 02:49:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA08534 for pilc-outgoing; Mon, 25 Sep 2000 01:10: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 BAA08524 for ; Mon, 25 Sep 2000 01:10:16 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id BAA01442; Mon, 25 Sep 2000 01:10:15 -0400 Received: from atoll.cs.jcu.edu.au(137.219.47.12) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001354; Mon, 25 Sep 00 01:10:01 -0400 Received: from cs.jcu.edu.au (tg1b73.cs.jcu.edu.au [137.219.47.73]) by atoll.cs.jcu.edu.au (8.9.1a/8.9.1) with ESMTP id PAA15780; Mon, 25 Sep 2000 15:09:53 +1000 (EST) Message-ID: <39CEDCD1.498FB45D@cs.jcu.edu.au> Date: Mon, 25 Sep 2000 15:04:18 +1000 From: Huan Pham X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: PILC mailing list , dtvt@egroups.com Subject: Application Traffic characteristic over wireless Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi everyone, According to IntServ/RSVP model, users (applications) need to indentify their traffic characteristics such as average bitrate, maximum bitrate, burst size in order to do resource reservation. Let's suppose that an application such as Internet Phone Call at host A wouldlike to communicate with host D through an IntServ network. Link between host A and Router B is Wireless (any kind of LMDS, MMDS or Wireless LAN): host A ........ Router B ------IntServ--------router C ---------- host D I think that wireless link (with error, and reliable link mechanism) may have some influence on the original traffic especially burst size. As a result of it, different resource (capacity and memory in the IntServ region) need to be reserved for that session compared to the _same_ request for the _same service_ from an user using wireline link. (that sound unusual but interesting to me!!!). I am considering to investigate the implication of reliable link layer on application traffic characteristics. Any pointer to relevant publications on this issue, or comments/suggestion about this question are be very appreciated. Thanks From owner-pilc@lerc.nasa.gov Fri Sep 29 12:13:44 2000 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02078 for ; Fri, 29 Sep 2000 12:13:44 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA11595 for pilc-outgoing; Fri, 29 Sep 2000 10:54: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 KAA11542 for ; Fri, 29 Sep 2000 10:54:12 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA04873; Fri, 29 Sep 2000 10:54:07 -0400 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004755; Fri, 29 Sep 00 10:54:00 -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 KAA04175; Fri, 29 Sep 2000 10:53:59 -0400 (EDT) Message-ID: <39D4AD06.8D04A6E1@hns.com> Date: Fri, 29 Sep 2000 10:53:58 -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 CC: border@hns.com Subject: PEP Implications re Qos Transparency and Multi-Homing References: <39D4AB87.E7740438@hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit At the Pittsburgh PILC meeting, I brought up the idea of deleting the PEP implications re QoS Transparency and Multi-Homing sections because the authors do not know what to put into these sections (and they did not seem that important to us). Objections were raised to this plan, i.e. some people still think these sections are important. But, we are still stuck with not knowing exactly what to write into these sections. So, we are looking for volunteers to write some text. Barring that, some feedback explaining what the working group thinks are the issues related to PEPs versus QoS Transparency and PEPs versus Multi-Homing might provide us enough information to write the text ourselves... John From owner-pilc@lerc.nasa.gov Fri Sep 29 12:25: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 MAA02292 for ; Fri, 29 Sep 2000 12:25:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA10564 for pilc-outgoing; Fri, 29 Sep 2000 10:48:10 -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 KAA10517 for ; Fri, 29 Sep 2000 10:48:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA00579; Fri, 29 Sep 2000 10:48:01 -0400 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000313; Fri, 29 Sep 00 10:47:55 -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 KAA02894; Fri, 29 Sep 2000 10:47:46 -0400 (EDT) Message-ID: <39D4AB87.E7740438@hns.com> Date: Fri, 29 Sep 2000 10:47:36 -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 CC: border@hns.com Subject: PEP Implications re End-to-end Failure Diagnostics References: Content-Type: multipart/mixed; boundary="------------65F104140541C1F62AD53502" Sender: owner-pilc@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. --------------65F104140541C1F62AD53502 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The attached text below is the PEP implications re end-to-end failure diagnostics text we have added to the PILC PEP draft. Since this section was previously blank, we decided to send this text to get early feedback rather than wait for the next version of the document to be released. (I realize that feedback might be affected by not having the entire document for context but...) John --------------65F104140541C1F62AD53502 Content-Type: text/plain; charset=us-ascii; name="failure_diagnostics.txt" Content-Disposition: inline; filename="failure_diagnostics.txt" Content-Transfer-Encoding: 7bit 4.1.4 End-to-end Failure Diagnostics Another aspect of the end-to-end argument is the ability to support end-to-end failure diagnostics when problems are encountered. If a network problem occurs which breaks a connection, the end points of the connection will detect the failure via timeouts. However, the existence of a PEP in between the two end points could delay (sometimes significantly) the detection of the failure by one or both of the end points. (Of course, some PEPs are intentionally designed to hide these types of failures as described in Section 3.4.) The implications of delayed detection of a failed connection depend on the applications being used. Possibilities range from no impact at all (or just minor annoyance to the end user) all the way up to impacting mission critical business functions by delaying switchovers to alternate communications paths. In addition, tools used to debug connection failures may be affected by the use of a PEP. For example, PING (described in [RFC792] and [RFC2151]) is often used to test for connectivity. But, because PING is based on ICMP instead of TCP (i.e. it is implemented using ICMP Echo and Replay commands at the network layer), it is possible that the configuration of the network might route PING traffic around the PEP. Thus, PING could indicate that an end-to-end path exists between two hosts when it does not actually exist for TCP traffic. Even when the PING traffic does go through the PEP, the diagnostics indications provided by the PING traffic are altered. For example, if the PING traffic goes transparently through the PEP, PING does not provide any indication that the PEP exists and since the PING traffic is not being subjected to the same processing as TCP traffic, it may not necessarily provide an accurate indication of the network delay being experienced by TCP traffic. On the other hand, if the PEP terminates the PING and responds to it on behalf of the end host, then the PING provides information only on the connectivity to the PEP. Traceroute (also described in [RFC2151]) is similarly affected by the presence of the PEP. --------------65F104140541C1F62AD53502--