From owner-pilc@grc.nasa.gov Tue Jan 1 13:04:46 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14160 for ; Tue, 1 Jan 2002 13:04:45 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id DA358C6953; Tue, 1 Jan 2002 13:03:34 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAbVaOWa; Tue, 1 Jan 02 13:03:34 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA05325 for pilc-outgoing; Tue, 1 Jan 2002 12:55:00 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA05321 for ; Tue, 1 Jan 2002 12:54:59 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA22636 for ; Tue, 1 Jan 2002 12:54:58 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 8266FC68F8; Tue, 1 Jan 2002 12:54:58 -0500 (EST) Received: from ruby.he.net(216.218.187.2) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA9Oaq25; Tue, 1 Jan 02 12:54:58 -0500 Received: from eif.net ([212.161.14.187] (may be forged)) by ruby.he.net (8.8.6/8.8.2) with SMTP id JAA10645; Tue, 1 Jan 2002 09:54:47 -0800 Message-Id: <200201011754.JAA10645@ruby.he.net> From: "HAPPY NEW YEAR FROM EIF" To: Subject: NEW YEAR EIF OFFER + CHASE OFFER Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Tue, 1 Jan 2002 17:51:04 -0800 X-Priority: 1 (Highest) Content-Transfer-Encoding: 8bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Eif Security Solutions and Rapid Traffic Search Optimization

WISHING YOU ALL A VERY HAPPY AND PROSPEROUS NEW YEAR!

FREE PC FIREWALL AND ANTIVIRUS TO ALL THE HUMAN BEINGS CONTACTING US!

THANKS

I TAKE THIS OPPORTUNITY TO TAKE YOU THE MESSAGE FOR THE END OF THE YEAR OF THE PRESIDENT:

'THE ALMOST BEST FUTURE CAN BE MADE BETTER' G CRASTI PRESIDENT HYKSOS GROUP

Rob Tel + 39 32 00 25 80 44

Fax + 1 212 656 1546

Rob Photo

www.eif.net

Apply Now for the Chase Platinum Credit Card iCard Holiday Rewards_468 Shop Safely_468X60 Outtatown 468x60 Platinum Lollipops 468x60

NOTE: If you have asked to be removed from our mailing list, and are continuing to receive our emails, please send us the names of any older or alias email addresses. These sometimes are forwarded to the new mail address and we must delete these older or alias addresses from our list in order to stop mail from reaching your current address. We apologize for any inconvenience and appreciate your continued patience and cooperation.Your address is Opt in under G law.

If you require I will send you $ 6 + apologies having your address.

remove@eif.net From owner-pilc@grc.nasa.gov Fri Jan 4 02:09:20 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28615 for ; Fri, 4 Jan 2002 02:09:18 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 9A6606412A; Fri, 4 Jan 2002 02:07:43 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAxVaq1l; Fri, 4 Jan 02 02:07:43 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA07779 for pilc-outgoing; Fri, 4 Jan 2002 01:59:13 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA06838; Fri, 4 Jan 2002 01:42:01 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA24825; Fri, 4 Jan 2002 01:42:01 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 3E439C6900; Fri, 4 Jan 2002 01:41:58 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg(137.132.163.102) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAnnaixR; Fri, 4 Jan 02 01:41:57 -0500 Received: from admin.cwc.nus.edu.sg ([172.16.2.67]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id OAA22804; Fri, 4 Jan 2002 14:39:31 +0800 (SGT) Message-Id: <4.3.2.7.2.20020104143110.00c73910@postman.cwc.nus.edu.sg> X-Sender: chankm@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Jan 2002 14:44:30 +0800 To: karn@ka9q.net, dab@restless.weston.bsdi.com, mallman@grc.nasa.gov, Reiner.Ludwig@ericsson.com, gurtov@cs.Helsinki.FI, pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov, vern@aciri.org From: Chan Kwang Mien Subject: Network Duplication In-Reply-To: <4.3.2.7.2.20011212100651.00b11590@postman.cwc.nus.edu.sg> References: <200112111921.fBBJLeQ00986@maggie.ka9q.net> <200112111658.fBBGwd000600@restless.weston.bsdi.com> <200112111658.fBBGwd000600@restless.weston.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@grc.nasa.gov Precedence: bulk hi, I am looking into solving problems caused by spurious retransmission. according to the internet draft on Eifel algorithm and DSACK (RFC 2883), it was mentioned that spurious fast retransmit can be caused by network duplication. Can anyone tell me how does network duplication occur in the internet and how frequent does network duplication occur ? Does network duplication of packets occur during handoff from one wireless cell to another, or some dysfunctional routers duplicating the packets,etc. Thank you. cheers, Kwang Mien From owner-pilc@grc.nasa.gov Fri Jan 4 13:46:04 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10866 for ; Fri, 4 Jan 2002 13:46:04 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id AE54A6415F; Fri, 4 Jan 2002 13:43:17 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA0Uaizo; Fri, 4 Jan 02 13:43:17 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA17034 for pilc-outgoing; Fri, 4 Jan 2002 13:36:54 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id NAA17017 for ; Fri, 4 Jan 2002 13:36:53 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id NAA12153 for ; Fri, 4 Jan 2002 13:36:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 8DF2FC694A; Fri, 4 Jan 2002 13:35:33 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAnwaay0; Fri, 4 Jan 02 13:35:33 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04IZMQ07057; Fri, 4 Jan 2002 12:35:22 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 12:33:51 -0600 Message-ID: From: "Farid Khafizov" To: "'Aaron Falk '" , "'pilc@grc.nasa.gov'" , "'Hiroshi INAMURA'" , "'Andrei Gurtov'" Cc: "Mehmet Yavuz" , "Farid Khafizov" Subject: RE: large RTT variation caused by bandwidth oscillation Date: Fri, 4 Jan 2002 12:15:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1954B.DA91AB30" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1954B.DA91AB30 Content-Type: text/plain; charset="iso-8859-1" In the previous discussion with Andrei Gurtov, it was pointed out that Solaris TCP is not rfc2988 compliant and therefore (under "bandwidth oscillation" conditions) was suffering frequent spurious re-transmissions. Even after adjusting minRTO to 1 sec, spurious re-transmissions were still there. Then Phil Karn and Aaron suggested that we look into the performance of other TCP stacks. Thus in addition to Solaris (5.6 and 5.8) TCP stack, we also looked at the following TCP implementations: Linux (kernel 2.4), Free BSD 4.4, HP-UX (9000 series) WinNT (build 1381, SP6) To the best of our knowledge, RTO management algorithm in all these OSs is compliant with Sec 5.3 of RFC 2988. As for the min RTO, based on the source code, Linux 2.4 has minRTO=200 ms (HZ/5 with HZ=100), and Free BSD 4.4 has 1000 ms (1*hz with hz=100). TCP traces suggest that HP has RTO_min = 1second as well. We do not know what the minRTO is for WinNT. We performed two sets of measurements: in corporate and public networks. We used the same configuration where Solaris was experiencing frequent re-transmissions. As expected, in the absence of any other factors spurious retransmissions are significantly reduced with RFC 2988 compliant TCPs. Results vary, but there is evidence of significant improvement. This was clearly seen while running FTP session within corporate network. However, when we ran FTP sessions over public network, spurious retransmissions were still there. The picture seemed to be far more complex than originally observed. We need more time to understand what exactly is going on, but certainly bandwidth oscillation in *combination* with some other factors is bringing throughput down (in some cases by 30-40%). It is important to note that throughput values measured in the absence of bandwidth oscillation (BO) were close to the maximum, which clearly suggests that BO is one of the factors degrading performance. In order to explain what we think might be going on when we say "BO in *combination* with some other factors ", we describe what was observed in earlier measurements. We were able to interpret TCP traces and understand (at least in one case) how bandwidth oscillation in combination with TCP segment losses were keeping throughput low. One way to ensure that RTO doesn't expire is to keep RTT sufficiently large. RTT can be made larger by increasing CWND. If there is at least one RTO expiration between the bursts, TCP may not take advantage of large CWND during the next bursts and/or FTP sessions for the following reason. When connection brakes, slow start threshold is being set to 1/2 of current CWND. Then TCP goes to congestion avoidance phase sooner than needed, CWND does not reach desirable value before the end of the burst, bandwidth oscillation is causing RTO expiration, and the vicious cycle continued until the end of the data call. In the next FTP session SSTHRESH, which was stored in the routing table during the previous FTP session, is causing same effects again. As the result TCP throughput does not reach maximum value because CWND can never reach BDP. However, if the same measurement is repeated in the absence of BO, throughput is very close to maximum value because CWND reaches maximum value and network capacity is fully utilized. Summarizing our experience, we think that bandwidth oscillation is a factor that (alone or in combination with other factors) presents a significant challenge for achieving maximum possible TCP throughput. Perhaps, it is best dealt by proper network design, however, there are situations when redesigning of networks is not possible. Considering the cost of RF spectrum, wireless operators will need recommendations on how to configure TCP to minimize throughput degradation. Therefore, we think that this issue needs to be addressed in 2.5g/3g as well as LINK ID. --Farid > -----Original Message----- > From: Aaron Falk [SMTP:falk@ISI.EDU] > > If it turns out that this behavior is really only exhibited on a few > deployed stacks, we should mention it with the appropriate caveats and > move > on. If, instead, that this is widespread among many TCPs it may be worthy > of futher attention. Can you give us some details on implementations > which > displayed the spurious timeouts? > > ------_=_NextPart_001_01C1954B.DA91AB30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: large RTT variation caused by bandwidth oscillation

In the previous = discussion with Andrei Gurtov, it was pointed out that Solaris TCP is = not rfc2988 compliant and therefore (under "bandwidth = oscillation" conditions) was suffering  frequent spurious = re-transmissions. Even after adjusting minRTO to 1 sec, spurious = re-transmissions were still there. Then Phil Karn and Aaron suggested = that we look into the performance of other TCP stacks. Thus in addition = to Solaris (5.6 and 5.8) TCP stack, we also looked at the following TCP = implementations:

        Linux (kernel 2.4),
        Free BSD 4.4, 
        HP-UX (9000 series)
        WinNT (build 1381, SP6)
To the best of our = knowledge, RTO management algorithm in all these OSs is compliant with = Sec 5.3 of RFC 2988. As for the min RTO, based on the source code, = Linux 2.4 has minRTO=3D200 ms (HZ/5 with HZ=3D100), and Free BSD 4.4 = has 1000 ms (1*hz with hz=3D100).  TCP traces suggest that HP = has  RTO_min =3D 1second as well. We do not know what the minRTO = is for WinNT.

We performed two = sets of measurements: in corporate and public networks. We used the = same configuration where Solaris was experiencing frequent = re-transmissions.

As expected, in the = absence of any other factors spurious retransmissions are significantly = reduced with RFC 2988 compliant TCPs. Results vary, but there is = evidence of significant improvement. This was clearly seen while = running FTP session within corporate network.

However, when we ran = FTP sessions over public network, spurious retransmissions were still = there. The picture seemed to be far more complex than originally = observed. We need more time to understand what exactly is going on, but = certainly bandwidth oscillation in *combination* with some other = factors is bringing throughput down (in some cases by 30-40%). =

It is important to = note that throughput values measured in the absence of bandwidth = oscillation (BO) were close to the maximum, which clearly suggests that = BO is one of the factors degrading performance.

In order to explain = what we think might be going on when we say "BO in *combination* = with some other factors ", we describe what was observed in = earlier measurements. We were able to interpret TCP traces and = understand (at least in one case) how bandwidth oscillation in = combination with TCP segment losses were keeping throughput low. =

One way to ensure = that RTO doesn't expire is to keep RTT sufficiently large. RTT can be = made larger by increasing CWND. If there is at least one RTO expiration = between the bursts, TCP may not take advantage of  large CWND = during the next bursts and/or FTP sessions for the following reason. = When connection brakes, slow start threshold is being set to 1/2 of = current CWND. Then TCP goes to congestion avoidance phase sooner than = needed, CWND does not reach desirable value before the end of the = burst, bandwidth oscillation is causing RTO expiration, and the vicious = cycle continued until the end of the data call. In the next FTP session = SSTHRESH, which was stored in the routing table during the previous FTP = session, is causing same effects again. As the result TCP throughput = does not reach maximum value because CWND can never reach BDP. However, = if the same measurement is repeated in the absence of BO, throughput is = very close to maximum value because CWND reaches maximum value and = network capacity is fully utilized.

Summarizing our = experience, we think that bandwidth oscillation is a factor that (alone = or in combination with other factors) presents a significant challenge = for achieving maximum possible TCP throughput. Perhaps, it is best = dealt by proper network design, however, there are situations when = redesigning of networks is not possible. Considering the cost of RF = spectrum, wireless operators will need recommendations on how to = configure TCP to minimize throughput degradation. Therefore, we think = that this issue needs to be addressed in 2.5g/3g as well as LINK = ID.

--Farid

    -----Original Message-----
    From:   Aaron Falk [SMTP:falk@ISI.EDU]

    If it turns out that this behavior is = really only exhibited on a few
    deployed stacks, we should mention it = with the appropriate caveats and move
    on.  If, instead, that this is = widespread among many TCPs it may be worthy
    of futher attention.  Can you = give us some details on implementations which
    displayed the spurious = timeouts? 


------_=_NextPart_001_01C1954B.DA91AB30-- From owner-pilc@grc.nasa.gov Sat Jan 5 04:03:39 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02870 for ; Sat, 5 Jan 2002 04:03:38 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 81F2EC6926; Sat, 5 Jan 2002 04:03:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAd8aqOe; Sat, 5 Jan 02 04:03:40 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA10408 for pilc-outgoing; Sat, 5 Jan 2002 03:54:43 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA10404 for ; Sat, 5 Jan 2002 03:54:42 -0500 (EST) From: OrderMusic@eudoramail.com Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id DAA27197 for ; Sat, 5 Jan 2002 03:54:42 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id CAD56640A4; Sat, 5 Jan 2002 03:54:41 -0500 (EST) Received: from webserver.mki.co.jp(150.67.32.191) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAzAaatr; Sat, 5 Jan 02 03:54:41 -0500 Received: from mx1.eudoramail.com - 67.203.81.152 by webserver.mki.co.jp with Microsoft SMTPSVC(5.5.1775.675.6); Sat, 5 Jan 2002 17:52:48 +0900 Message-ID: <000028076694$00007c48$000010de@mx1.eudoramail.com> To: Subject: $10 off CD's , DVD's JNCFNAT Date: Sat, 05 Jan 2002 02:50:50 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: OrderMusic51@eudoramail.com Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable OrderMusic.com
<= tr>
3DOrdermusic.com

This is a Flash Enabled Email. If you do no= t have flash, please download it here

We respect your online privacy. We have inc= luded contact information and a way for removal from our mailing list. If = you wish to be removed from this list, please click here and pr= ovide the address(es) to be deleted from our list. Any inconvenience cause= d is sincerely regretted
<= /p>

 

 

From owner-pilc@grc.nasa.gov Sun Jan 6 08:48:41 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23468 for ; Sun, 6 Jan 2002 08:48:40 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 8B36CC698B; Sun, 6 Jan 2002 08:48:23 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAJxaW4P; Sun, 6 Jan 02 08:48:23 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA27621 for pilc-outgoing; Sun, 6 Jan 2002 08:37:50 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA27018; Sun, 6 Jan 2002 08:22:22 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id IAA08252; Sun, 6 Jan 2002 08:22:21 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A8279C68DF; Sun, 6 Jan 2002 08:22:09 -0500 (EST) Received: from smtp.dave.sonera.fi(131.177.130.21) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAsgaauL; Sun, 6 Jan 02 08:22:09 -0500 Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:2184 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Sun, 6 Jan 2002 15:21:51 +0200 Message-ID: <03be01c196b5$15aa16c0$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "Noritoshi Demizu" , , References: <200112111658.fBBGwd000600@restless.weston.bsdi.com> <20011227175859X.demizu@dd.iij4u.or.jp> Subject: Re: Doubt regarding the MANAGING THE RTO TIMER Date: Sun, 6 Jan 2002 15:21:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Noritoshi- I agree with you. According to a comment on Steven's page this fix is used by all modern TCPs. Do you happen to have some experimental data that show RFC1323-like and fixed behavior? In addtion to inflating RTO value, echoing old timestamps can cause problems to the Eifel algorithm. According to Pasi Sarolahti, Linux follows RFC1323 that lets Eifel to incorrectly conclude a spurious timeout in a scenario with lost packets and ACKs. Andrei ----- Original Message ----- From: "Noritoshi Demizu" To: ; Sent: Thursday, December 27, 2001 10:58 AM Subject: Re: Doubt regarding the MANAGING THE RTO TIMER > > When using Timestamps, even in the face of packet loss, > > you can guarantee to get at least one valid timing per RTT. > > Or, more correctly, with Timestamps, anytime you get an > > ack for new data, you can reliably use it's timestamp > > to get a new RTT measurement. > > I think RFC1323 needs to be updated as described in [1] and [2] bellow. > > If one implemented timestamps option just as described in RFC1323, and > when a data packet was retransmitted because the ACK packet was lost, > the measured RTT could be larger than the real value. To fix this > problem, at least the condition of the rule (2) of section 3.4 in > RFC1323 needs to be updated. > > The condition of the rule (2) of Section 3.4 in RFC1323 is: > SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN > > The condition of [1] and [2] is: > SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent > > The condition of FreeBSD 4.4R is: SEG.SEQ <= Last.ACK.sent > The condition of NetBSD 1.5.2 is the same as RFC1323. > The condition of OpenBSD 3.0 is the same as [1] and [2]. > (Sorry, I do not know of the Linux implementation.) > > [1] R. Braden, "TCP Extensions for High Performance: An Update", Jun 1993 > http://www.kohala.com/start/tcplw-extensions.txt > [2] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High > Performance", Feb 1997 > http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt > > I hope RFC1323 will be updated. > > Noritoshi Demizu > From owner-pilc@grc.nasa.gov Mon Jan 7 04:10:10 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12124 for ; Mon, 7 Jan 2002 04:10:10 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A36B3C691B; Mon, 7 Jan 2002 04:10:11 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAC8a4Zp; Mon, 7 Jan 02 04:10:11 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA01662 for pilc-outgoing; Mon, 7 Jan 2002 04:01:57 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA00543; Mon, 7 Jan 2002 03:48:54 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id DAA16533; Mon, 7 Jan 2002 03:48:53 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 2A344640D4; Mon, 7 Jan 2002 03:48:53 -0500 (EST) Received: from h086.p106.iij4u.or.jp(210.130.106.86) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAWmaOOs; Mon, 7 Jan 02 03:48:50 -0500 Received: from localhost (localhost [127.0.0.1]) by viola.demizu.org (8.11.0/8.11.0) with ESMTP id g078kDe00424; Mon, 7 Jan 2002 17:46:13 +0900 (JST) From: Noritoshi Demizu To: gurtov@cs.Helsinki.FI Cc: pilc@grc.nasa.gov, tcp-impl@grc.nasa.gov Subject: Re: Doubt regarding the MANAGING THE RTO TIMER In-Reply-To: Your message of "Sun, 6 Jan 2002 15:21:43 +0200" References: <03be01c196b5$15aa16c0$6b24b183@etela.sonera.fi> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020107174613M.demizu@dd.iij4u.or.jp> Date: Mon, 07 Jan 2002 17:46:13 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 68 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Andrei, > I agree with you. According to a comment on Steven's page this fix is > used by all modern TCPs. Do you happen to have some experimental data that > show RFC1323-like and fixed behavior? Yes. I have implemented the features listed in "WAP Wireless Profiled TCP (WAP-225-TCP)" and , including TCP timestamps options, for the TCP/IP stack of ACCESS (www.access.co.jp) which I am working for. During the test period, I found the problem. I tried to reproduce the phenomena today. Here are two traces at the receivers side. Both the sender and the receiver are ACCESS's stacks. The RTT is approximately 50ms. The timestamp counts up every 500ms. ------------------------------------------------------------------------- When both the sender and the receiver follow RFC1323: i.e. SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN Scenario: - Packet (1) triggers Fast Retransmit(2) at the sender. - The receiver sent an ACK(3) for data(2), but the ACK was dropped. - The sender retransmitted data twice, but they both were dropped. - The receiver sent an ACK(5) for data(4), and the ACK arrived at the sender. - The sender sent new data(6). The recever sent an ACK(7). See the timestamp echo value of ACK(5). Because this is the first ACK of 66609 for the sender, the sender calculates RTT with this very old value. The calculated RTT might be about 10sec (= (36 - 15) * 500ms). Too big... (1) 16:04:15.927928 receiver.9 > sender.1128: . ack 59369 win 32768 (DF) (2) 16:04:15.979703 sender.1128 > receiver.9: . 59369:60817(1448) ack 1 win 32768 (DF) (3) 16:04:15.979947 receiver.9 > sender.1128: . ack 66609 win 32768 (DF) (4) 16:04:27.228887 sender.1128 > receiver.9: . 59369:60817(1448) ack 1 win 32768 (DF) (5) 16:04:27.229154 receiver.9 > sender.1128: . ack 66609 win 32768 (DF) (6)16:04:27.280868 sender.1128 > receiver.9: . 66609:68057(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (7) 16:04:27.294183 receiver.9 > sender.1128: . ack 68057 win 32768 (DF) ------------------------------------------------------------------------- When both the sender and the receiver follow fixed RFC1323: i.e. SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent Scenario: - The sender sent data(1)&(2). The receiver sent an ACK(3), but dropped. - The sender sent data(4)&(5). The receiver sent an ACK(6), but dropped. - The sender retransmitted data(7), the same data as data(1). - The receiver sent an ACK(8) with correct timestamp echo value. - The sender sent new data(9). The recever sent an ACK(10). See the timestamp echo value of ACK(8). Because this is the first ACK of 215753 for the sender, the sender calculates RTT with this value. The calculated RTT might be about 500ms (= (26 - 25) * 500ms). Not bad. (1) 15:54:26.170476 sender.1558 > receiver.9: . 209961:211409(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (2) 15:54:26.201471 sender.1558 > receiver.9: . 211409:212857(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (3) 15:54:26.201615 receiver.9 > sender.1558: . ack 212857 win 32768 (DF) (4) 15:54:26.232467 sender.1558 > receiver.9: . 212857:214305(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (5) 15:54:26.263466 sender.1558 > receiver.9: . 214305:215753(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (6) 15:54:26.263617 receiver.9 > sender.1558: . ack 215753 win 32768 (DF) (7) 15:54:27.359400 sender.1558 > receiver.9: . 209961:211409(1448) ack 1 win 32768 (DF) (8) 15:54:27.359632 receiver.9 > sender.1558: . ack 215753 win 32768 (DF) (9) 15:54:27.411389 sender.1558 > receiver.9: . 215753:217201(1448) ack 1 win 32768 (DF) [tos 0x2,ECT] (10) 15:54:27.435141 receiver.9 > sender.1558: . ack 217201 win 32768 (DF) ------------------------------------------------------------------------- Regards, Noritoshi Demizu From owner-pilc@grc.nasa.gov Tue Jan 8 16:17:32 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10713 for ; Tue, 8 Jan 2002 16:17:32 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id CB24864147; Tue, 8 Jan 2002 16:14:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAACGaiD2; Tue, 8 Jan 02 16:14:41 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA05338 for pilc-outgoing; Tue, 8 Jan 2002 16:03:09 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA05325 for ; Tue, 8 Jan 2002 16:03:08 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA00464 for ; Tue, 8 Jan 2002 16:02:58 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id CD64164111; Tue, 8 Jan 2002 16:01:03 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAcWaWqZ; Tue, 8 Jan 02 16:01:03 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08L0x003084 for ; Tue, 8 Jan 2002 15:01:00 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 14:59:14 -0600 Message-ID: From: "Farid Khafizov" To: "'pilc@grc.nasa.gov'" Cc: "Mehmet Yavuz" , "Farid Khafizov" Subject: RE: LINK, 2.5g3g and CDMA2000 Date: Tue, 8 Jan 2002 14:59:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19887.4E5A9250" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19887.4E5A9250 Content-Type: text/plain; charset="iso-8859-1" As a follow up on IETF-52 meeting discussions, we suggest adding the following text to 2.5g/3g ID: - a paragraph on VJC - a section on Bandwidth Oscillation We also think that some info about CDMA2000 should be in the document. It could go into the same section where specifics of UMTS are being discussed (Section 2), or be part of Bandwidth Oscillation section. Please provide your feedback. --Farid ----------------------------------- 1. Disabling Van Jacobson TCP/IP Header Compression Van Jacobson TCP/IP header compression (VJC) algorithm [35] is negotiated between peer PPP layers. In CDMA2000 networks it could be implemented between the Mobile Terminal Equipment, such as laptop computer, and the Packet Data Serving Node. The algorithm was designed to increases application layer throughput by reducing packetization overhead. In the absence of TCP segment errors, for MTU=1000 Bytes, enabling VJC increases throughput by about 4%. However, experiments have shown that in the presence of TCP segment errors, VJC is not desirable because it does not allow TCP to take advantage of Fast Retransmit Fast Recovery mechanism [n4]. VJC algorithm transmits not the TCP/IP headers but only the changes in the headers of consecutive segments. Therefore, a segment error causes the transmitting and receiving TCP sequence numbers to go out of synch. When a TCP segment is lost, none of the following segment will go through until RTO expires. It is recommended to disable VJC algorithm unless TCP segment errors are very low. 2. Bandwidth Oscillation Limited RF spectrum along with high data rate requirement for 2.5G/3G wireless systems necessitate dynamic resource sharing among concurrent data users. Various scheduling mechanisms can be deployed in order to maximize resource utilization. Some of the limited resources in CDMA based systems (e.g., UMTS, CDMA2000) are orthogonal codes and RF transmit power. Shared channels in UMTS [N1] and supplemental channels in CDMA2000 [N2], designed for high speed traffic, utilize relatively high RF power and require higher portion of orthogonal code resources. Time division sharing of these resources may result in TCP throughput degradation. Usually these resources are allocated on per needed bases (bandwidth on demand) and released when there is no data to send. There could, however, be situations when resources are de-allocated while significant amount of data is still waiting in the queue. If a number of users require large data file transfer at the same time, the system (e.g., the scheduler) may have to repeatedly to allocate and de-allocate resources from each user. In this section we refer to periodic allocation and de-allocation of high-speed channel as Bandwidth Oscillation (BO). BO effects such as spurious retransmission were identified elsewhere (e.g., [17]) as throughput degradation factors. However, it is important to note that in case of some 3G wireless network configurations BO can be the single most important factor in reducing throughput by as much as 30%-50%. In the next paragraph we give an example of how BO effects TCP performance, and define notation needed for further discussion. Although, the example is based on CDMA2000 system, the same considerations are applicable to many (wireless) systems with time scheduling of high-speed data traffic. CDMA2000 1x standard, IS-2000.2 [n2], provides means of transmitting data over two type of traffic channels: Fundamental (FCH) and Supplemental (SCH). Fundamental channel has a fixed low bandwidth (e.g., 9.6 kbps). Bandwidth of SCH is a multiple of that and could be as high as 32 times of FCH bandwidth. To simplify notation, we assume that FCH rate is fixed at 9.6 kbps, we denote (SCH+FCH)/FCH bandwidth ratio by O. Hence, O is proportional to the SCH rate. FCH is always assigned before data transmission begins. SCH is assigned on per needed basis. When SCH is being used we say that the call is in burst. There are two type of SCH assignments: finite and infinite [n3], which will be referred to as finite burst and infinite burst, respectively. Infinite burst means that SCH can be used for transmitting data until a release command is issued. Finite burst mode of operation limits the SCH usage to one of fourteen finite time intervals [n3] before it must be released. We denote the duration of SCH allocation by B. After SCH is released, it can be acquired again after certain delay (D). One of the ways of detecting congestion in TCP is RTO expiration. RTO computation algorithm [32] was designed to follow closely round trip time (RTT), but is known to work poorly when delay variance is high [11]. During high bandwidth (FCH+SCH) RTT is low and, if B is relatively long (e.g., 5.12 seconds), RTO converges to RTT. When SCH is released, suddenly RTT increases (proportionally to O) and low RTO expires forcing TCP into the Slow Start state, while actually none of the TCP segments were lost. B |<--------------->| |-----------------| | | | | | | | SCH+FCH | D | | | ---| |<---->| |------| FCH ------------------------------------------------------ Figure 1. Bandwidth oscillation. Full cycle time is B+D. SCH and FCH are used for transmitting data for time B, then SCH is released and only FCH carries data for time D. The best approach to avoiding adverse effects of BO, is, perhaps, proper wireless sub-network design. Simulation results as well as lab measurements suggest [N4] that when TCP parameters (and FCH rate) are fixed the level of throughput degradation (and achievable throughput) is a function of . For some combinations degradation of throughput could reach 55%. When B and/or D are low, the throughput degradation is less severe. However, deploying some 2.5/3G wireless systems with low B and/or D values could be impractical. Higher throughput is achieved when B is high, while signaling delays impose limits on reducing D. Avoiding finite burst mode of operation is also not practical because limited RF resources require time-sharing of SCH resources (e.g., scheduling users). Therefore, one has to consider other techniques that could reduce spurious retransmissions due to bandwidth oscillation. One obvious method was to adjust computed RTO value (or configure appropriately the minimum RTO value) at sending TCP. This technique, however, can not be recommended as a practical solution. Experiments have shown that RTO algorithm implementation compliant with RFC2988 (e.g., minimum RTO=1 sec and initial RTO=3 sec) reduce number of spurious re-transmissions. Although RTO timer management specified in RFC2988 is not mandatory, implementation of retransmission timer restart when an ACK is received (section 5.3 of RFC2988) will further reduce (or even eliminate) spurious retransmissions. However, secondary effects, such as TCP segment loss, in combination with BO may not allow avoiding all spurious re-transmissions. Analysis of RTO algorithm along with an alternative (Eifel) algorithm are presented in [17]. Eifel algorithm requires timestamp option and at least one RTO expiration before TCP "learns" that retransmission was not necessary. Even in the absence of Eifel algorithm enabling timestamp option reduces spurious re-transmissions due to BO. Other options that could reduce spurious re-transmissions due to BO are increase CWND and reduce delay ACK timer at Receiving TCP to < 100 ms (this technique may have side effects in case bandwidth is limited in the opposite direction). [n1] "WCDMA for UMTS", edited by Harri Holma and Antti Toskala, John Wiley & Sons, Ltd., 2000 [n2] TIA/EIA/IS-2000.2-A, March, 2000, "Physical Layer Standard for cdma2000 Spread Spectrum Systems", [n3] TIA/EIA/IS-2000.5-A, "Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems", March, 2000 [n4] F.Khafizov, M.Yavuz, "TCP over IS-2000", to appear in Proc. of IEEE ICC 2002 ------_=_NextPart_001_01C19887.4E5A9250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: LINK, 2.5g3g and CDMA2000

As a follow up on IETF-52 meeting = discussions, we
suggest adding the following text to = 2.5g/3g ID:
 - a paragraph on VJC
 - a section on Bandwidth = Oscillation

We also think that some info about = CDMA2000 should be in the
document. It could go into the same = section where specifics of
UMTS are being discussed (Section 2), or = be part of Bandwidth
Oscillation section.

Please provide your feedback.
--Farid




-----------------------------------
1. Disabling Van Jacobson TCP/IP Header = Compression

    Van Jacobson TCP/IP header compression = (VJC) algorithm [35] is negotiated between peer PPP layers. In CDMA2000 = networks it could be implemented between the Mobile Terminal Equipment, = such as laptop computer, and the Packet Data Serving Node. The = algorithm was designed to increases application layer throughput by = reducing packetization overhead. In the absence of TCP segment errors, = for MTU=3D1000 Bytes, enabling VJC increases throughput by about 4%. = However, experiments have shown that in the presence of TCP segment = errors, VJC is not desirable because it does not allow TCP to take = advantage of Fast Retransmit Fast Recovery mechanism [n4]. VJC = algorithm transmits not the TCP/IP headers but only the changes in the = headers of consecutive segments. Therefore, a segment error causes the = transmitting and receiving TCP sequence numbers to go out of synch. = When a TCP segment is lost, none of the following segment will go = through until RTO expires.

    It is recommended to disable VJC = algorithm unless TCP segment errors are very low.


2. Bandwidth Oscillation

    Limited RF spectrum along with high data = rate requirement for 2.5G/3G wireless systems necessitate dynamic = resource sharing among concurrent data users. Various scheduling = mechanisms can be deployed in order to maximize resource utilization. = Some of the limited resources in CDMA based systems (e.g., UMTS, = CDMA2000) are orthogonal codes and RF transmit power. Shared channels = in UMTS [N1] and supplemental channels in CDMA2000 [N2], designed for = high speed traffic, utilize relatively high RF power and require higher = portion of orthogonal code resources. Time division sharing of these = resources may result in TCP throughput degradation. Usually these = resources are allocated on per needed bases (bandwidth on demand) and = released when there is no data to send. There could, however, be = situations when resources are de-allocated while significant amount of = data is still waiting in the queue. If a number of users require large = data file transfer at the same time, the system (e.g., the scheduler) = may have to repeatedly to allocate and de-allocate resources from each = user.

    In this section we refer to periodic = allocation and de-allocation of high-speed channel as Bandwidth = Oscillation (BO). BO effects such as spurious retransmission were = identified elsewhere (e.g., [17]) as throughput degradation factors. = However, it is important to note that in case of some 3G wireless = network configurations BO can be the single most important factor in = reducing throughput by as much as 30%-50%. In the next paragraph we = give an example of how BO effects TCP performance, and define notation = needed for further discussion. Although, the example is based on = CDMA2000 system, the same considerations are applicable to many = (wireless) systems with time scheduling of high-speed data traffic. =

    CDMA2000 1x standard, IS-2000.2 [n2], = provides means of transmitting data over two type of traffic channels: = Fundamental (FCH) and Supplemental (SCH). Fundamental channel has a = fixed low bandwidth (e.g., 9.6 kbps). Bandwidth of SCH is a multiple of = that and could be as high as 32 times of FCH bandwidth. To simplify = notation, we assume that FCH rate is fixed at 9.6 kbps, we denote = (SCH+FCH)/FCH bandwidth ratio by O. Hence, O is proportional to the SCH = rate. FCH is always assigned before data transmission begins. SCH is = assigned on per needed basis. When SCH is being used we say that the = call is in burst. There are two type of SCH assignments: finite and = infinite [n3], which will be referred to as finite burst and infinite = burst, respectively. Infinite burst means that SCH can be used for = transmitting data until a release command is issued. Finite burst mode = of operation limits the SCH usage to one of fourteen finite time = intervals [n3] before it must be released. We denote the duration of = SCH allocation by B. After SCH is released, it can be acquired again = after certain delay (D).

    One of the ways of detecting congestion = in TCP is RTO expiration. RTO computation algorithm [32] was designed = to follow closely round trip time (RTT), but is known to work poorly = when delay variance is high [11]. During high bandwidth (FCH+SCH) RTT = is low and, if B is relatively long (e.g., 5.12 seconds), RTO converges = to RTT. When SCH is released, suddenly RTT increases (proportionally to = O) and low RTO expires forcing TCP into the Slow Start state, while = actually none of the TCP segments were lost.

                = B            =
       = |<--------------->|      = |-----------------|      |
       = |            = ;     |      = |            = ;     |      |
       |   = SCH+FCH       |   D  = |            = ;     |      |
    ---|          &nb= sp;      = |<---->|         &nbs= p;       |------|  
               &= nbsp;           = FCH
    ------------------------------------------------------
    Figure 1. Bandwidth oscillation. Full = cycle time is B+D. SCH and FCH are used for transmitting data for time = B, then SCH is released and only FCH carries data for time = D.

    The best approach to avoiding adverse = effects of BO, is, perhaps, proper wireless sub-network design. = Simulation results as well as lab measurements suggest [N4] that when = TCP parameters (and FCH rate) are fixed the level of throughput = degradation (and achievable throughput) is a function of <O, B, = D>. For some combinations degradation of throughput could reach 55%. = When B and/or D are low, the throughput degradation is less severe. = However, deploying some 2.5/3G wireless systems with low B and/or D = values could be impractical. Higher throughput is achieved when B is = high, while signaling delays impose limits on reducing D. Avoiding = finite burst mode of operation is also not practical because limited RF = resources require time-sharing of SCH resources (e.g., scheduling = users).

    Therefore, one has to consider other = techniques that could reduce spurious retransmissions due to bandwidth = oscillation. One obvious method was to adjust computed RTO value (or = configure appropriately the minimum RTO value) at sending TCP. This = technique, however, can not be recommended as a practical solution. =

    Experiments have shown that RTO algorithm = implementation compliant with RFC2988 (e.g., minimum RTO=3D1 sec and = initial RTO=3D3 sec) reduce number of spurious re-transmissions. = Although RTO timer management specified in RFC2988 is not mandatory, = implementation of retransmission timer restart when an ACK is received = (section 5.3 of RFC2988) will further reduce (or even eliminate) = spurious retransmissions. However, secondary effects, such as TCP = segment loss, in combination with BO may not allow avoiding all = spurious re-transmissions.

    Analysis of RTO algorithm along with an = alternative (Eifel) algorithm are presented in [17]. Eifel algorithm = requires timestamp option and at least one RTO expiration before TCP = "learns" that retransmission was not necessary. Even in the = absence of Eifel algorithm enabling timestamp option reduces spurious = re-transmissions due to BO. Other options that could reduce spurious = re-transmissions due to BO are increase CWND and reduce delay ACK timer = at Receiving TCP to < 100 ms (this technique may have side effects = in case bandwidth is limited in the opposite direction).




    [n1] "WCDMA for UMTS", edited = by Harri Holma and Antti Toskala, John Wiley & Sons, Ltd., = 2000
    [n2] TIA/EIA/IS-2000.2-A, March, 2000, = "Physical Layer Standard for cdma2000 Spread Spectrum = Systems",
    [n3] TIA/EIA/IS-2000.5-A, "Upper = Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum = Systems", March, 2000
    [n4] F.Khafizov, M.Yavuz, "TCP over = IS-2000", to appear in Proc. of IEEE ICC 2002


------_=_NextPart_001_01C19887.4E5A9250-- From owner-pilc@grc.nasa.gov Tue Jan 8 22:29:46 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18070 for ; Tue, 8 Jan 2002 22:29:45 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 91A9CC698D; Tue, 8 Jan 2002 22:26:53 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAaNaiw2; Tue, 8 Jan 02 22:26:53 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA23357 for pilc-outgoing; Tue, 8 Jan 2002 22:18:19 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA23349 for ; Tue, 8 Jan 2002 22:18:17 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id WAA13112 for ; Tue, 8 Jan 2002 22:18:13 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 39C1B640D9; Tue, 8 Jan 2002 22:16:46 -0500 (EST) Received: from patan.sun.com(192.18.98.43) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAhtay_Y; Tue, 8 Jan 02 22:16:45 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11706 for ; Tue, 8 Jan 2002 20:16:27 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA16403 for ; Tue, 8 Jan 2002 19:16:44 -0800 (PST) Date: Tue, 8 Jan 2002 19:16:04 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: large RTT variation caused by bandwidth oscillation To: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <00ea01c183f7$f8834dc0$24c9830c@ietfslc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@grc.nasa.gov Precedence: bulk Sorry for the late reply in this thread. I was on vacation the last month. I just want to make several comments since Solaris was mentioned several times in this thread. It was mentioned that Solaris always had a problem with spurious retransmission. In pre-Solaris 2.6, Karn's algorithm (maybe this is the reason why Phil Karn stopped using Solaris...) was not implemented correctly. One can see that what this can cause when a timeout due to congestion happens. And there were various other little things which caused problems with slow link. I guess this all leads to the now "infamous" quote about Solaris having serious spurious retransmission problem... I hope this can be straightened out. Another comment is about RFC 2988 compliant. We have several reservations about RFC 2988. And it may be better not to conform to it. For example, in section 2, rule 2.2, one can easily see that if G is not a big value (say at least 500ms or 1s), this can cause problem in a slow link. For example, consider the case that the first segment which is used for RTT sampling has only a few bytes and the next segment sent is actually a full MSS size segments. If G is in the range of 100ms and the slowest link speed of the route is 9600bps, the second segment will trigger a timeout. This problem is masked by rule 2.4, which restricts the minimum RTO to be 1s. But as mentioned in the RFC, this is quite conservative. And I beleive many implementations choose not to comply with it. As a matter of fact, I believe having a fixed RTO of 1s for land links (no wireless) should be able to aovid most spurious retransmission in today's Internet (oops, I cannot substantiate this claim with facts )-:) We don't need to do RTT sampling at all (-: There is one comment specifically saying that Solaris does not comply with Section 5, rule 5.3. It is correct, Solaris does not implement the part of restarting timer in rule 5.3. The timer is restarted when a fast retransmit happens or during the fast recovery phase when missing segments are retransmitted. Rule 5.3 simply says that the RTO calculation is not good enough so that implementations should add a little fudge factor to it. For example, if 2 segments are sent and the receiver does not delay ack'ing. The second segment is dropped. After the ACK for the first segment arrives, rule 5.3 suggests that the timer should be restarted. This means that the actual timeout value for the second segment is RTO+RTT. The arrival of first data segment correlates weakly, if there is any correlation, to the fate of the next segment. This point has been mentioned by a lot of other people. And the fact that it helps spurious retransmission is that it makes the timeout longer and longer. If we make RTO a fixed 5s, I conjecture that there will be no spurious retransmission, even for wireless links (-: (Please don't take those "smiley points" seriously (-:) And I believe Farid Khafizov's last email (there are too many emails in my various mailboxes, I may have missed some...) mentioned that even with this timeout fudge factor, RTT oscillation is still a problem. His earlier mails suggesting that RFC 2988 compliant TCP implementations could handle his earlier experiements may just be "pure luck..." The current TCP RTO algorithm is not designed to handle this kind of wireless environment. And we all know that the current assumption of the RTO calculation is that the round trip route does not change much. So it seems to me that we may need a better way to deal with this in the RTO calculation. A quick hack for Solaris admin is to set tcp_rexmit_interval_extra to a value which is appropriate for the kind of RTT oscillation of the particular network. This knob is there to handle cases when the RTO algorithm fails, and I believe this kind of oscillation in the wireless medium may be one of them. In any case, we are open to suggestions to what we should do to accomodate different network environments. I have another minor comment about what actually happens after a timeout. I believe all modern TCP implementations will not have the false fast retransmit after timeout problem mentioned in this thread. K. Poon. kcpoon@eng.sun.com From owner-pilc@grc.nasa.gov Wed Jan 9 06:44:53 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02626 for ; Wed, 9 Jan 2002 06:44:52 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id BFA07C697C; Wed, 9 Jan 2002 06:41:45 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAiSai2c; Wed, 9 Jan 02 06:41:45 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA04193 for pilc-outgoing; Wed, 9 Jan 2002 06:34:42 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA04189 for ; Wed, 9 Jan 2002 06:34:41 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA07101 for ; Wed, 9 Jan 2002 06:34:40 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 480DB6408E; Wed, 9 Jan 2002 06:34:40 -0500 (EST) Received: from smtp.dave.sonera.fi(131.177.130.21) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAmYaOr5; Wed, 9 Jan 02 06:34:40 -0500 Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1738 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Wed, 9 Jan 2002 13:34:26 +0200 Message-ID: <006101c19901$95b3f360$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "Kacheong Poon" , References: Subject: Re: large RTT variation caused by bandwidth oscillation Date: Wed, 9 Jan 2002 13:34:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit In my opinion, connections using SACK and Limited transmit can afford having a conservative RTO since they suffer non-spurious timeouts infrequently. RFC2988 is a good starting point to provide a conservative enough timer suitable for wireless environment. The next step could be to use non-decreasing version of the timer, i.e. to use only RTT samples that increase the RTO value. This way the RTO timer becomes the estimate of the highest RTT value observed on this connection so far. Andrei ----- Original Message ----- From: "Kacheong Poon" To: Sent: Wednesday, January 09, 2002 5:16 AM Subject: Re: large RTT variation caused by bandwidth oscillation > Sorry for the late reply in this thread. I was on vacation the > last month. I just want to make several comments since Solaris > was mentioned several times in this thread. > > It was mentioned that Solaris always had a problem with spurious > retransmission. In pre-Solaris 2.6, Karn's algorithm (maybe this > is the reason why Phil Karn stopped using Solaris...) was not > implemented correctly. One can see that what this can cause when a > timeout due to congestion happens. And there were various other > little things which caused problems with slow link. I guess this all > leads to the now "infamous" quote about Solaris having serious > spurious retransmission problem... I hope this can be straightened > out. > > Another comment is about RFC 2988 compliant. We have several > reservations about RFC 2988. And it may be better not to conform > to it. > > For example, in section 2, rule 2.2, one can easily see that if G > is not a big value (say at least 500ms or 1s), this can cause problem > in a slow link. For example, consider the case that the first > segment which is used for RTT sampling has only a few bytes and the > next segment sent is actually a full MSS size segments. If G is > in the range of 100ms and the slowest link speed of the route is > 9600bps, the second segment will trigger a timeout. This problem > is masked by rule 2.4, which restricts the minimum RTO to be 1s. > But as mentioned in the RFC, this is quite conservative. And I > beleive many implementations choose not to comply with it. As > a matter of fact, I believe having a fixed RTO of 1s for land > links (no wireless) should be able to aovid most spurious > retransmission in today's Internet (oops, I cannot substantiate > this claim with facts )-:) We don't need to do RTT sampling at > all (-: > > There is one comment specifically saying that Solaris does not > comply with Section 5, rule 5.3. It is correct, Solaris does > not implement the part of restarting timer in rule 5.3. The timer > is restarted when a fast retransmit happens or during the fast > recovery phase when missing segments are retransmitted. > > Rule 5.3 simply says that the RTO calculation is not good enough so > that implementations should add a little fudge factor to it. For > example, if 2 segments are sent and the receiver does not delay > ack'ing. The second segment is dropped. After the ACK for the > first segment arrives, rule 5.3 suggests that the timer should > be restarted. This means that the actual timeout value for the > second segment is RTO+RTT. The arrival of first data segment > correlates weakly, if there is any correlation, to the fate of the > next segment. This point has been mentioned by a lot of other people. > And the fact that it helps spurious retransmission is that it makes > the timeout longer and longer. If we make RTO a fixed 5s, I conjecture > that there will be no spurious retransmission, even for wireless > links (-: (Please don't take those "smiley points" seriously (-:) > > And I believe Farid Khafizov's last email (there are too many emails > in my various mailboxes, I may have missed some...) mentioned that > even with this timeout fudge factor, RTT oscillation is still a > problem. His earlier mails suggesting that RFC 2988 compliant > TCP implementations could handle his earlier experiements may just > be "pure luck..." The current TCP RTO algorithm is not designed to > handle this kind of wireless environment. And we all know that the > current assumption of the RTO calculation is that the round trip route > does not change much. So it seems to me that we may need a better way > to deal with this in the RTO calculation. A quick hack for Solaris > admin is to set tcp_rexmit_interval_extra to a value which is appropriate > for the kind of RTT oscillation of the particular network. This > knob is there to handle cases when the RTO algorithm fails, and I > believe this kind of oscillation in the wireless medium may be one > of them. In any case, we are open to suggestions to what we should > do to accomodate different network environments. > > I have another minor comment about what actually happens after a timeout. > I believe all modern TCP implementations will not have the false fast > retransmit after timeout problem mentioned in this thread. > > K. Poon. > kcpoon@eng.sun.com > > > From owner-pilc@grc.nasa.gov Wed Jan 9 08:54:56 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03823 for ; Wed, 9 Jan 2002 08:54:55 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E3D4BC697E; Wed, 9 Jan 2002 08:51:43 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA_HaaTz; Wed, 9 Jan 02 08:51:43 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA23633 for pilc-outgoing; Wed, 9 Jan 2002 08:45:17 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA23624 for ; Wed, 9 Jan 2002 08:45:16 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id IAA20895 for ; Wed, 9 Jan 2002 08:45:10 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E833CC68D6; Wed, 9 Jan 2002 08:45:09 -0500 (EST) Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAJuainy; Wed, 9 Jan 02 08:45:09 -0500 Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 16OJ0r-0004Iz-00; Wed, 09 Jan 2002 13:43:29 +0000 Date: Wed, 9 Jan 2002 13:43:21 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Farid Khafizov Cc: "'pilc@grc.nasa.gov'" , Mehmet Yavuz Subject: RE: LINK, 2.5g3g and CDMA2000 In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16OJ0r-0004Iz-00*ijw6ZdTkfMk* (SECM, UniS) Sender: owner-pilc@grc.nasa.gov Precedence: bulk On Tue, 8 Jan 2002, Farid Khafizov wrote: > As a follow up on IETF-52 meeting discussions, we > suggest adding the following text to 2.5g/3g ID: > - a paragraph on VJC > - a section on Bandwidth Oscillation some very brief comments below from a quick pass: > We also think that some info about CDMA2000 should be in the > document. It could go into the same section where specifics of > UMTS are being discussed (Section 2), or be part of Bandwidth > Oscillation section. > > Please provide your feedback. > --Farid > > ----------------------------------- > 1. Disabling Van Jacobson TCP/IP Header Compression > > Van Jacobson TCP/IP header compression (VJC) algorithm [35] is > negotiated between peer PPP layers. In CDMA2000 networks it could be > implemented between the Mobile Terminal Equipment, such as laptop computer, > and the Packet Data Serving Node. The algorithm was designed to increases > application layer throughput by reducing packetization overhead. In the > absence of TCP segment errors, for MTU=1000 Bytes, enabling VJC increases > throughput by about 4%. However, experiments have shown that in the presence > of TCP segment errors, VJC is not desirable because it does not allow TCP to > take advantage of Fast Retransmit Fast Recovery mechanism [n4]. VJC > algorithm transmits not the TCP/IP headers but only the changes in the > headers of consecutive segments. Therefore, a segment error causes the > transmitting and receiving TCP sequence numbers to go out of synch. When a > TCP segment is lost, none of the following segment will go through until RTO > expires. > > It is recommended to disable VJC algorithm unless TCP segment errors > are very low. I can't see the ROHC crowd being comfortable with this; I see Carsten's got PPP/ROHC in last call. http://www.normos.org/ietf/draft/draft-ietf-rohc-over-ppp-04.txt Do similar comments apply to the increasing number of ROHC variants in that ever-growing ROHC bubble? Some comments on ROHC work (and even how expanding stateful compression relying on flow ordering beyond a single link to a network path is just silly due to the failure modes and expectations imposed on the network, where congestion can be a fact of life) may well be appropriate. On bandwidth oscillation (also really including extreme capacity oscillations? I like the BO=undesirable connotations, though): > The best approach to avoiding adverse effects of BO, is, perhaps, > proper wireless sub-network design. here is a good place to reference Phil's link design draft. L. PGP From owner-pilc@grc.nasa.gov Wed Jan 9 09:50:15 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04689 for ; Wed, 9 Jan 2002 09:50:15 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B9E3AC6A6A; Wed, 9 Jan 2002 09:49:38 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAN3aO0N; Wed, 9 Jan 02 09:49:38 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA08172 for pilc-outgoing; Wed, 9 Jan 2002 09:44:33 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA08153 for ; Wed, 9 Jan 2002 09:44:32 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA29390 for ; Wed, 9 Jan 2002 09:44:31 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A6929C696B; Wed, 9 Jan 2002 09:43:06 -0500 (EST) Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAvdayJL; Wed, 9 Jan 02 09:43:06 -0500 Received: from [10.0.1.3] (maxp18.abdn.ac.uk [139.133.7.177]) by erg.abdn.ac.uk (8.12.2.Beta3/8.12.2.Beta3) with SMTP id g09EgReo016170; Wed, 9 Jan 2002 14:42:28 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 09 Jan 2002 14:42:23 +0000 Subject: Re: LINK, 2.5g3g and CDMA2000 From: Gorry Fairhurst To: Lloyd Wood , Farid Khafizov Cc: "'pilc@grc.nasa.gov'" , Mehmet Yavuz Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Please provide your feedback. > --Farid > > ----------------------------------- > 1. Disabling Van Jacobson TCP/IP Header Compression > > Van Jacobson TCP/IP header compression (VJC) algorithm [35] is > negotiated between peer PPP layers. In CDMA2000 networks it could be > implemented between the Mobile Terminal Equipment, such as laptop computer, > and the Packet Data Serving Node. The algorithm was designed to increases > application layer throughput by reducing packetization overhead. In the > absence of TCP segment errors, for MTU=1000 Bytes, enabling VJC increases > throughput by about 4%. "enabling VJC increases throughput by about 4%" - but you can only quote numbers for packets with a specific TCP segment size. MTU =/= segment size. > However, experiments have shown that in the presence > of TCP segment errors, "errors" is a bad term - I suggest you say "packet loss", if you mean loss. > VJC is not desirable because it does not allow TCP to > take advantage of Fast Retransmit Fast Recovery mechanism [n4]. When the loss occurs on the link using VJC - loss of a TCP data segment could occur elsewhere along the forward path, and then FR/FR would work. > VJC > algorithm transmits not the TCP/IP headers but only the changes in the > headers of consecutive segments. Therefore, a segment error "error" should be "loss a TCP segment on the VJC link" > causes the > transmitting and receiving TCP sequence numbers to go out of synch. When a > TCP segment is lost, none of the following segment will go through until RTO > expires. "go through" should be "will be forwarded by the link" Suggest you refer to "draft-ietf-pilc-link-design" > It is recommended to disable VJC algorithm unless TCP segment errors > are very low. I agree with Lloyd, it seems foolish at this stage not to also mention ROHC for TCP, which is planning to address these issues directly. Gorry Fairhurst From owner-pilc@grc.nasa.gov Wed Jan 9 09:54:49 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04787 for ; Wed, 9 Jan 2002 09:54:48 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 03683640EB; Wed, 9 Jan 2002 09:49:16 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAnKayqK; Wed, 9 Jan 02 09:49:16 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA07657 for pilc-outgoing; Wed, 9 Jan 2002 09:43:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id JAA07649 for ; Wed, 9 Jan 2002 09:43:14 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id JAA29174 for ; Wed, 9 Jan 2002 09:43:13 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 920F3640C2; Wed, 9 Jan 2002 09:43:13 -0500 (EST) Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAiVayyI; Wed, 9 Jan 02 09:43:12 -0500 Received: from [10.0.1.3] (maxp18.abdn.ac.uk [139.133.7.177]) by erg.abdn.ac.uk (8.12.2.Beta3/8.12.2.Beta3) with SMTP id g09EgRep016170; Wed, 9 Jan 2002 14:42:31 GMT User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 09 Jan 2002 14:42:23 +0000 Subject: Re: large RTT variation caused by bandwidth oscillation From: Gorry Fairhurst To: Andrei Gurtov , Message-ID: In-Reply-To: <006101c19901$95b3f360$6b24b183@etela.sonera.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-ERG-MailScanner: Found to be clean Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit on 9/1/02 11:34 am, Andrei Gurtov at gurtov@cs.Helsinki.FI wrote: > In my opinion, connections using SACK and Limited transmit can afford having > a conservative RTO since they suffer non-spurious timeouts infrequently. > > RFC2988 is a good starting point to provide a conservative enough timer > suitable for wireless environment. The next step could be to use > non-decreasing version of the timer, i.e. to use only RTT samples that > increase the RTO value. This way the RTO timer becomes the estimate of the > highest RTT value observed on this connection so far. But, what about path changes, from a slow/long path to a short delay path? --- surely there must be some grounds for reducing the RTO. Even if, the tendency is to fix the RTO much larger than the RTT measurements, MAX seems excessive... Gorry > > Andrei > > ----- Original Message ----- > From: "Kacheong Poon" > To: > Sent: Wednesday, January 09, 2002 5:16 AM > Subject: Re: large RTT variation caused by bandwidth oscillation > > >> Sorry for the late reply in this thread. I was on vacation the >> last month. I just want to make several comments since Solaris >> was mentioned several times in this thread. >> >> It was mentioned that Solaris always had a problem with spurious >> retransmission. In pre-Solaris 2.6, Karn's algorithm (maybe this >> is the reason why Phil Karn stopped using Solaris...) was not >> implemented correctly. One can see that what this can cause when a >> timeout due to congestion happens. And there were various other >> little things which caused problems with slow link. I guess this all >> leads to the now "infamous" quote about Solaris having serious >> spurious retransmission problem... I hope this can be straightened >> out. >> >> Another comment is about RFC 2988 compliant. We have several >> reservations about RFC 2988. And it may be better not to conform >> to it. >> >> For example, in section 2, rule 2.2, one can easily see that if G >> is not a big value (say at least 500ms or 1s), this can cause problem >> in a slow link. For example, consider the case that the first >> segment which is used for RTT sampling has only a few bytes and the >> next segment sent is actually a full MSS size segments. If G is >> in the range of 100ms and the slowest link speed of the route is >> 9600bps, the second segment will trigger a timeout. This problem >> is masked by rule 2.4, which restricts the minimum RTO to be 1s. >> But as mentioned in the RFC, this is quite conservative. And I >> beleive many implementations choose not to comply with it. As >> a matter of fact, I believe having a fixed RTO of 1s for land >> links (no wireless) should be able to aovid most spurious >> retransmission in today's Internet (oops, I cannot substantiate >> this claim with facts )-:) We don't need to do RTT sampling at >> all (-: >> >> There is one comment specifically saying that Solaris does not >> comply with Section 5, rule 5.3. It is correct, Solaris does >> not implement the part of restarting timer in rule 5.3. The timer >> is restarted when a fast retransmit happens or during the fast >> recovery phase when missing segments are retransmitted. >> >> Rule 5.3 simply says that the RTO calculation is not good enough so >> that implementations should add a little fudge factor to it. For >> example, if 2 segments are sent and the receiver does not delay >> ack'ing. The second segment is dropped. After the ACK for the >> first segment arrives, rule 5.3 suggests that the timer should >> be restarted. This means that the actual timeout value for the >> second segment is RTO+RTT. The arrival of first data segment >> correlates weakly, if there is any correlation, to the fate of the >> next segment. This point has been mentioned by a lot of other people. >> And the fact that it helps spurious retransmission is that it makes >> the timeout longer and longer. If we make RTO a fixed 5s, I conjecture >> that there will be no spurious retransmission, even for wireless >> links (-: (Please don't take those "smiley points" seriously (-:) >> >> And I believe Farid Khafizov's last email (there are too many emails >> in my various mailboxes, I may have missed some...) mentioned that >> even with this timeout fudge factor, RTT oscillation is still a >> problem. His earlier mails suggesting that RFC 2988 compliant >> TCP implementations could handle his earlier experiements may just >> be "pure luck..." The current TCP RTO algorithm is not designed to >> handle this kind of wireless environment. And we all know that the >> current assumption of the RTO calculation is that the round trip route >> does not change much. So it seems to me that we may need a better way >> to deal with this in the RTO calculation. A quick hack for Solaris >> admin is to set tcp_rexmit_interval_extra to a value which is appropriate >> for the kind of RTT oscillation of the particular network. This >> knob is there to handle cases when the RTO algorithm fails, and I >> believe this kind of oscillation in the wireless medium may be one >> of them. In any case, we are open to suggestions to what we should >> do to accomodate different network environments. >> >> I have another minor comment about what actually happens after a timeout. >> I believe all modern TCP implementations will not have the false fast >> retransmit after timeout problem mentioned in this thread. >> >> K. Poon. >> kcpoon@eng.sun.com >> >> >> > > From owner-pilc@grc.nasa.gov Wed Jan 9 11:30:05 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06697 for ; Wed, 9 Jan 2002 11:30:04 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id AB76CC69E5; Wed, 9 Jan 2002 11:28:46 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA3_aODh; Wed, 9 Jan 02 11:28:46 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA05806 for pilc-outgoing; Wed, 9 Jan 2002 11:20:38 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA05775 for ; Wed, 9 Jan 2002 11:20:36 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA15430 for ; Wed, 9 Jan 2002 11:20:30 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 9A791C698F; Wed, 9 Jan 2002 11:19:51 -0500 (EST) Received: from smtp4.cluster.oleane.net(195.25.12.62) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAGvaahe; Wed, 9 Jan 02 11:19:51 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id g09GJnK62688 for ; Wed, 9 Jan 2002 17:19:49 +0100 (CET) Message-ID: <001101c19929$2f45d8a0$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPCN 2002 (IP-based Cellular Networks) Date: Wed, 9 Jan 2002 16:13:02 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FA_01C19928.83829800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-pilc@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01FA_01C19928.83829800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One of the most interesting subjects of IPCN 2002 (IP-based Cellular = Networks) is the relationship between the licensed 2.5/3G services and = 802.11 hotspots. How can optimal use be made of both environments such = that a realistic business service is possible?=20 Carriers will bring answers next April 23-26 during the third edition of = IPCN (Intersection of Mobile WAN and WLAN).=20 All details at: http://www.upperside.fr/ipcn02/baipcn02intro.htm =20 =20 ------=_NextPart_000_01FA_01C19928.83829800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
One of the = most=20 interesting subjects of IPCN 2002 (IP-based Cellular Networks) is the=20 relationship between the licensed 2.5/3G services and 802.11 hotspots. = How can=20 optimal use be made of both environments such that a realistic business = service=20 is possible?
Carriers will bring answers next = April 23-26=20 during the third edition of IPCN (Intersection of Mobile WAN and = WLAN).
All details=20 at:
http://www.uppe= rside.fr/ipcn02/baipcn02intro.htm
 
 
------=_NextPart_000_01FA_01C19928.83829800-- From owner-pilc@grc.nasa.gov Wed Jan 9 19:25:06 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21857 for ; Wed, 9 Jan 2002 19:25:05 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D2AD8C699F; Wed, 9 Jan 2002 19:22:32 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAU_ayVT; Wed, 9 Jan 02 19:22:32 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA29954 for pilc-outgoing; Wed, 9 Jan 2002 19:15:17 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA29943 for ; Wed, 9 Jan 2002 19:15:16 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id TAA26643 for ; Wed, 9 Jan 2002 19:15:10 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B431EC6934; Wed, 9 Jan 2002 19:13:46 -0500 (EST) Received: from patan.sun.com(192.18.98.43) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAnGa4mS; Wed, 9 Jan 02 19:13:46 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28609; Wed, 9 Jan 2002 17:13:27 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA00350; Wed, 9 Jan 2002 16:13:44 -0800 (PST) Date: Wed, 9 Jan 2002 16:13:04 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: large RTT variation caused by bandwidth oscillation To: Andrei Gurtov Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <006101c19901$95b3f360$6b24b183@etela.sonera.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@grc.nasa.gov Precedence: bulk > In my opinion, connections using SACK and Limited transmit can afford having > a conservative RTO since they suffer non-spurious timeouts infrequently. If I am not mistaken, rule 5.3 of RFC 2988 restarts the timer only if new data is ack'ed. Duplicate acks do not ack new data. So rule 5.3 does not help in the above cases. It does not even restart the timer for fast retransmit. > RFC2988 is a good starting point to provide a conservative enough timer > suitable for wireless environment. The next step could be to use > non-decreasing version of the timer, i.e. to use only RTT samples that > increase the RTO value. This way the RTO timer becomes the estimate of the > highest RTT value observed on this connection so far. The question is if RFC 2988 works because of coincidence or it has a solid foundation. I still do not understand the reason behind restarting the timer when an ack for new data arrives. It does delay a timeout, but for what reason? I do not think using the above suggested method is a good idea. we may as well use a fixed timeout of the max we know of for today's Internet (-: K. Poon. kcpoon@eng.sun.com From owner-pilc@grc.nasa.gov Wed Jan 9 21:25:08 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25070 for ; Wed, 9 Jan 2002 21:25:07 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id C93FEC699F; Wed, 9 Jan 2002 21:22:57 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA15aWKe; Wed, 9 Jan 02 21:22:57 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA13662 for pilc-outgoing; Wed, 9 Jan 2002 21:18:18 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id VAA13653; Wed, 9 Jan 2002 21:18:16 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id VAA10576; Wed, 9 Jan 2002 21:18:14 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 6066C640EB; Wed, 9 Jan 2002 21:16:00 -0500 (EST) Received: from adsl16503.estpak.ee(213.219.110.111) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAEvaqA2; Wed, 9 Jan 02 21:15:57 -0500 From: Z-editor Greetings Reply-To: greetings@z-editor.com Subject: Greeting Card form J. Date: Thu, 10 Jan 2002 04:20:22 +0200 X-Mailer: 007 Direct Email Easy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="6404f418-056f-11d6-9c69-00e02934281a" Message-Id: <20020110021600.6066C640EB@seraph3.grc.nasa.gov> To: undisclosed-recipients: ; Sender: owner-pilc@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format --6404f418-056f-11d6-9c69-00e02934281a Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You have just received a virtual greeting card from J. You can view your greeting card at : http://www.z-editor.com/cards/7acmynnyjjn.html Your greeting card will be available for the next 90 days We wish you all the best! _____________________________________________________________________________= __________ This card has been sent to you through the Virtual Greeting Card System at Z-editor.com Viewing and sending Z-editor cards is free. The greeting card is = virus-checked. Z-editor is an easy to use web-based web editor. Try it today for free at: = http://www.z-editor.com Z-editor enables you to modify and create web pages yourself. There is no reason to contact a busy IT specialist any more! Modify your web site from = anywhere in the world - no installations needed. Check out cool additional functions (e.g. virtual greeting card, mailing = list, etc), which can be easily added to your web site. We are looking forward to your visit to http://www.z-editor.com --6404f418-056f-11d6-9c69-00e02934281a-- From owner-pilc@grc.nasa.gov Thu Jan 10 07:24:53 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13559 for ; Thu, 10 Jan 2002 07:24:52 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 54AF0640E2; Thu, 10 Jan 2002 07:24:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAU6a4jt; Thu, 10 Jan 02 07:24:52 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA06192 for pilc-outgoing; Thu, 10 Jan 2002 07:18:53 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id HAA06184 for ; Thu, 10 Jan 2002 07:18:51 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id HAA16502 for ; Thu, 10 Jan 2002 07:18:49 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 3D366640EB; Thu, 10 Jan 2002 07:17:56 -0500 (EST) Received: from porsta.cs.helsinki.fi(128.214.48.124) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAA1oaGPr; Thu, 10 Jan 02 07:17:55 -0500 Received: from melkki.cs.Helsinki.FI (sslwrap@localhost [127.0.0.1]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id g0ACHm722362; Thu, 10 Jan 2002 14:17:48 +0200 Received: from localhost (gurtov@localhost) by melkki.cs.Helsinki.FI (8.11.6/8.11.2) with ESMTP id g0ACHih07406; Thu, 10 Jan 2002 14:17:44 +0200 X-Authentication-Warning: melkki.cs.Helsinki.FI: gurtov owned process doing -bs Date: Thu, 10 Jan 2002 14:17:43 +0200 (EET) From: Andrei Gurtov To: Gorry Fairhurst Cc: Subject: Re: large RTT variation caused by bandwidth oscillation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pilc@grc.nasa.gov Precedence: bulk On Wed, 9 Jan 2002, Gorry Fairhurst wrote: > on 9/1/02 11:34 am, Andrei Gurtov at gurtov@cs.Helsinki.FI wrote: > > > In my opinion, connections using SACK and Limited transmit can afford having > > a conservative RTO since they suffer non-spurious timeouts infrequently. > > > > RFC2988 is a good starting point to provide a conservative enough timer > > suitable for wireless environment. The next step could be to use > > non-decreasing version of the timer, i.e. to use only RTT samples that > > increase the RTO value. This way the RTO timer becomes the estimate of the > > highest RTT value observed on this connection so far. > > But, what about path changes, from a slow/long path to a short delay path? > --- surely there must be some grounds for reducing the RTO. Even if, the > tendency is to fix the RTO much larger than the RTT measurements, MAX seems > excessive... I know it sounds overly conservative, but nothing better comes to mind while thinking of a suitable rxmt timer for GPRS with fairly stable 1 s RTT with eventual 10 sec delay spikes. A possible option is to reset the timer to estimate based on actual RTT when a non-spurious timeout is encountered. Still, this may be a better approach than hard-coding some (arbitrary) fixed minimum RTO. Andrei From owner-pilc@grc.nasa.gov Thu Jan 10 20:20:16 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27175 for ; Thu, 10 Jan 2002 20:20:16 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E61C1C69B5; Thu, 10 Jan 2002 20:17:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAYfaaXl; Thu, 10 Jan 02 20:17:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA01019 for pilc-outgoing; Thu, 10 Jan 2002 20:10:46 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAA01008 for ; Thu, 10 Jan 2002 20:10:45 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id UAA08496 for ; Thu, 10 Jan 2002 20:10:42 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A1188C693F; Thu, 10 Jan 2002 20:09:59 -0500 (EST) Received: from patan.sun.com(192.18.98.43) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAjVaWhk; Thu, 10 Jan 02 20:09:59 -0500 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11870; Thu, 10 Jan 2002 18:09:58 -0700 (MST) Received: from shield (shield.EBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id RAA11198; Thu, 10 Jan 2002 17:09:57 -0800 (PST) Date: Thu, 10 Jan 2002 17:09:16 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: large RTT variation caused by bandwidth oscillation To: Andrei Gurtov Cc: Gorry Fairhurst , pilc@grc.nasa.gov In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@grc.nasa.gov Precedence: bulk > I know it sounds overly conservative, but nothing better comes to mind > while thinking of a suitable rxmt timer for GPRS with fairly stable 1 > s RTT with eventual 10 sec delay spikes. A possible option is to reset the > timer to estimate based on actual RTT when a non-spurious timeout is > encountered. Still, this may be a better approach than hard-coding some > (arbitrary) fixed minimum RTO. Some questions about GPRS. What is the approximate bandwidth delay product in such network? What kind of network apps are supposed to run on it? It seems that interactive apps are out of questions. How often will those delay spikes happen? Thanks. K. Poon. kcpoon@eng.sun.com From owner-pilc@grc.nasa.gov Fri Jan 11 19:39:58 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03803 for ; Fri, 11 Jan 2002 19:39:58 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id F112B64161; Fri, 11 Jan 2002 19:38:04 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAeeaW15; Fri, 11 Jan 02 19:38:04 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA11309 for pilc-outgoing; Fri, 11 Jan 2002 19:31:52 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id TAA11305 for ; Fri, 11 Jan 2002 19:31:51 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id TAA03554 for ; Fri, 11 Jan 2002 19:31:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 897F2C68CD; Fri, 11 Jan 2002 19:31:50 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAATNayvs; Fri, 11 Jan 02 19:31:50 -0500 Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0C0VnN25500; Fri, 11 Jan 2002 16:31:49 -0800 (PST) Date: Fri, 11 Jan 2002 16:31:49 -0800 From: Aaron Falk To: pilc , minutes@ietf.org Subject: pilc minutes (better late than never....) Message-ID: <12830000.1010795509@nit> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========609346650==========" Sender: owner-pilc@grc.nasa.gov Precedence: bulk --==========609346650========== Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline --==========609346650========== Content-Type: text/plain; charset=us-ascii; name="PILC_Meeting_Notes_121101.txt" Content-Disposition: attachment; filename="PILC_Meeting_Notes_121101.txt"; size=5313 Content-Transfer-Encoding: 7bit Performance Implications of Link Characteristics WG (pilc) The PILC working group meeting was held on Tuesday, December 11 at 1300-1400. The meeting was chaired by Aaron Falk and the following agenda was followed completely. AGENDA: Agenda Bashing chairs 2min Working Group Status chairs 3min CDMA2000 issues F. Kahafizov 10min draft-khafizov-pilc-cdma2000-00.txt Q: integrate into 2.5g3g or new doc? 2.5g/3g Update H. Inamura 10min draft-ietf-pilc-2.5g3g-05.txt Q: ready for wg last call? LINK last call comments P. Karn 10min draft-ietf-pilc-link-design-08.txt M. Allman PILC-related issues in ROHC C. Borman 10min IP-DVB announcement G. Fairhurst 2min Adjourn The meeting started promptly at 13:00 and Blue Sheets were circulated. Aaron Falk went over the Working Group Status ARQ is in IESG review. ASYM is going to IESG any day. LINK design is in last call. Mark Allman will be taking over editing for Phil Karns 2.5/3G document is near last call but needs to incorporate CDMA2000 information. ========================= CDMA2000 F. Kahafizoz presented slides on TCP performance over CDMA 2000 networks. Issues to be addressed include bandwidth oscillation, high BER, and bandwidth asymmetry. Bandwidth oscillation degrades throughput through spurious timeouts. True of any system with widely varying bandwidth. * Bandwidth Oscillations (BO) - Significant throughput degradation - Not cdma2000 specific - Related to resource contention - Fixes include 1) fix TCP, 2) Fix network or 3) leave as is. - Possible fixes o Adjust RTO value o enable Time Stamp option o increase window size o minimize ACK delay - Other recommendations o Aggressive link level error recovery o disable VJ header compression o use SACK - Options o Incorporate BO in 2.5g/3g and/or LINK ID o make a separate ID for BO o have a section in 2.5G/#g ID addressing specifics of CMDA2000 Suggestions from chair and floor moved toward including in existing documents rather than stand-alone document. F. Kahafizov volunteer to generate text for the documents. ============ Hiroshi Inamura presented slides on 2.5G/3G * Reviewed open issues - header compressions - active queue mgt. - Others * RTO typically 2s is to small? - Yes * New Sections - VJ header compression not recommended Comments from the floor: ECN section needs expansion as ECN may be quite beneficial. Question as to whether or not the effects of cell changes being incorporated into draft. ============= Phil Karn commented that the LINK document appears to be very near completion. Bandwidth on Demand and bandwidth oscillations may need some additional attention. Floor Comments: Asymmetry may need a bit of revision as it was written early on. ============ Carsten Bormann presented slides on issues in Robust Header Compression related to PILC The following is a summary of Carsten's slides: Robust Header Compression (ROHC) - Header Compression is prerequisite for all IP wireless - Wireless = lossy, long latency Work items Robust Header Compression of IP/UDP/RTP - need for e2e VoIP/video - RFC3095 july 2001 used by 3GPP and 3GPP2 - ROHC over PPP; 0-byte LLA submitted to IESG ROHC for TCP is starting to gel New: signaling compression (reduce latency) - universal decompressor ROHC is working on MIBs Next work will probably be related to SCTP RFC 2507 is not good enough as it does not handle options like SACK, timestamps - need to compress ECN bits well - cope with TCP's extensibility - (state of the ar ha advanced) Requirements drafts presented: 2 drafts - please read and comment on 01/03 versions once available! Solutions : two drafts in the process of merging Need wider input wrt next generation TCP ROHC TCP Requirements - Links with few residual erros but may have packet loss - Robustness o Should not disable TCOP mechanisms o Must NOT generate damaged headers o Must deal with current and future TCPs o TCP sequence numbers and IP ID less predictable TCP Sample Issues - TCP checksum and.or additional CRC for checking - Unidirectional vs bi-directional compression - Can ROHC ignore IP options? - Compress in tunnel encapsulations, too? o Reordering (prohibited, detected, allowed)? - Integrate with ASYM mechanisms - What are the assumptions about ECN behavior? - What loss amplifications behaviours are actually acceptable? - IPR Comments from floor - even if residual error is low, what is error distribution (burst errors vs uniform distribution errors). However, residual bit errors as defined by ROHC are packet with errors passed from layer 2 too layer 3. =================== IP-DVB announcement G. Fairhurst 2min G. Fairhurst extended an invitation to an informal meeting on 12/12 at 15:30 - 17:30. The meeting will be on IP over DVB. It is not an BoF, but a maillist will be created for those interested in this subject. More information can be found at http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/. --==========609346650==========-- From owner-pilc@grc.nasa.gov Sun Jan 13 01:51:58 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29980 for ; Sun, 13 Jan 2002 01:51:57 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 5F58BC68DB; Sun, 13 Jan 2002 01:51:59 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA49aOnn; Sun, 13 Jan 02 01:51:59 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA08858 for pilc-outgoing; Sun, 13 Jan 2002 01:40:46 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA08854 for ; Sun, 13 Jan 2002 01:40:45 -0500 (EST) From: BudgetLife@eudoramail.com Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA02110 for ; Sun, 13 Jan 2002 01:40:44 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 2DB0EC68DB; Sun, 13 Jan 2002 01:40:44 -0500 (EST) Received: from unknown(217.6.137.2) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAANbaaCl; Sun, 13 Jan 02 01:40:43 -0500 Received: from mx1.eudoramail.com ([207.93.225.208]) by LOS-WEB1; So, 13 Jan 2002 07:38:48 +0300 Message-ID: <000028c9007d$00003f02$00001ad0@mx1.eudoramail.com> To: Subject: Are You Paying too Much for Life Insurance? NCFSJ Date: Sun, 13 Jan 2002 00:36:04 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: BudgetLife3@eudoramail.com Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable

M= ost likely, YES !

Here's why.&= nbsp; Fierce ... take no prisoner ... insurance industry PRICE WARS have driven premiums DOWN, and = down, and down --30 -- 40 -- 50 -- even 70% from where they were just a short time ago!

YOUR INSURANCE COMPANY DOESN'T WANT YOU TO READ THIS= ...=

They will continue to take your money, while o= ffering lower rates (up to 50%, even 70% lower) to new buyers.

BUT DON'T TAKE OUR WORD FOR IT<= span style=3D"font-size:16.0pt;mso-bidi-font-size: 12.0pt">... Visit

http://www.lifeinsurance.net.cn/email/

and request an online quote today.&nbs= p; Be prepared to be surprised by how cheaply you can buy large amounts of term life insurance!

 

If you think, that you will not benefit from t= his correspondence, please reply with =FFFFFF93remove key=FFFFFF94 as the = subject matter.

 

From owner-pilc@grc.nasa.gov Sun Jan 13 11:24:28 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12046 for ; Sun, 13 Jan 2002 11:24:26 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 7BC4F64156; Sun, 13 Jan 2002 11:22:35 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAeza4P5; Sun, 13 Jan 02 11:22:35 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA12867 for pilc-outgoing; Sun, 13 Jan 2002 11:16:55 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA12852 for ; Sun, 13 Jan 2002 11:16:53 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA22494 for ; Sun, 13 Jan 2002 11:16:50 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 5DB09C68F3; Sun, 13 Jan 2002 11:15:44 -0500 (EST) Received: from smtp.dave.sonera.fi(131.177.130.21) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAu_aGIx; Sun, 13 Jan 02 11:15:44 -0500 Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:3848 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Sun, 13 Jan 2002 18:15:26 +0200 Message-ID: <020901c19c4d$15d3c720$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "Kacheong Poon" Cc: "Gorry Fairhurst" , References: Subject: Re: large RTT variation caused by bandwidth oscillation Date: Sun, 13 Jan 2002 18:12:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Some questions about GPRS. What is the approximate bandwidth > delay product in such network? What kind of network apps are > supposed to run on it? It seems that interactive apps are out > of questions. How often will those delay spikes happen? Thanks. Bandwidth is 10-50 kbps, RTT about 800 ms. People use it for normal Internet access. Frequency of delay spikes depends on many things. E.g. voice calls to your mobile terminal suspend the data connection. Driving in Helsinki seems to generate handovers (delay spikes) roughly every minute. For more details please check http://www.cs.helsinki.fi/u/gurtov/papers/icc01.html http://www.cs.helsinki.fi/u/gurtov/papers/pwc01.html Andrei From owner-pilc@grc.nasa.gov Mon Jan 14 14:16:44 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13801 for ; Mon, 14 Jan 2002 14:16:44 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 61602640EA; Mon, 14 Jan 2002 14:16:45 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAyyaO_g; Mon, 14 Jan 02 14:16:45 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA26082 for pilc-outgoing; Mon, 14 Jan 2002 14:07:33 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id OAA26065 for ; Mon, 14 Jan 2002 14:07:32 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id OAA11128 for ; Mon, 14 Jan 2002 14:07:31 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 21941C68CF; Mon, 14 Jan 2002 14:03:51 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAyuayzH; Mon, 14 Jan 02 14:03:50 -0500 Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0EJ3nN02460; Mon, 14 Jan 2002 11:03:49 -0800 (PST) Date: Mon, 14 Jan 2002 11:03:49 -0800 From: Aaron Falk To: pilc , minutes@ietf.org Subject: pilc minutes (corrected) Message-ID: <5360000.1011035029@nit> In-Reply-To: <12830000.1010795509@nit> References: <12830000.1010795509@nit> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit All- Please substitute the following modified version of the wg minutes. I have corrected name spelling for Khafizov. --aaron ====================================================== Performance Implications of Link Characteristics WG (pilc) The PILC working group meeting was held on Tuesday, December 11 at 1300-1400. The meeting was chaired by Aaron Falk and the following agenda was followed completely. AGENDA: Agenda Bashing chairs 2min Working Group Status chairs 3min CDMA2000 issues F. Khafizov 10min draft-khafizov-pilc-cdma2000-00.txt Q: integrate into 2.5g3g or new doc? 2.5g/3g Update H. Inamura 10min draft-ietf-pilc-2.5g3g-05.txt Q: ready for wg last call? LINK last call comments P. Karn 10min draft-ietf-pilc-link-design-08.txt M. Allman PILC-related issues in ROHC C. Borman 10min IP-DVB announcement G. Fairhurst 2min Adjourn The meeting started promptly at 13:00 and Blue Sheets were circulated. Aaron Falk went over the Working Group Status ARQ is in IESG review. ASYM is going to IESG any day. LINK design is in last call. Mark Allman will be taking over editing for Phil Karn's 2.5/3G document is near last call but needs to incorporate CDMA2000 information. ========================= CDMA2000 F. Khafizov presented slides on TCP performance over CDMA 2000 networks. Issues to be addressed include bandwidth oscillation, high BER, and bandwidth asymmetry. Bandwidth oscillation degrades throughput through spurious timeouts. True of any system with widely varying bandwidth. * Bandwidth Oscillations (BO) - Significant throughput degradation - Not cdma2000 specific - Related to resource contention - Fixes include 1) fix TCP, 2) Fix network or 3) leave as is. - Possible fixes o Adjust RTO value o enable Time Stamp option o increase window size o minimize ACK delay - Other recommendations o Aggressive link level error recovery o disable VJ header compression o use SACK - Options o Incorporate BO in 2.5g/3g and/or LINK ID o make a separate ID for BO o have a section in 2.5G/#g ID addressing specifics of CMDA2000 Suggestions from chair and floor moved toward including in existing documents rather than stand-alone document. F. Khafizov volunteer to generate text for the documents. ============ Hiroshi Inamura presented slides on 2.5G/3G * Reviewed open issues - header compressions - active queue mgt. - Others * RTO typically 2s is to small? - Yes * New Sections - VJ header compression not recommended Comments from the floor: ECN section needs expansion as ECN may be quite beneficial. Question as to whether or not the effects of cell changes being incorporated into draft. ============= Phil Karn commented that the LINK document appears to be very near completion. Bandwidth on Demand and bandwidth oscillations may need some additional attention. Floor Comments: Asymmetry may need a bit of revision as it was written early on. ============ Carsten Bormann presented slides on issues in Robust Header Compression related to PILC The following is a summary of Carsten's slides: Robust Header Compression (ROHC) - Header Compression is prerequisite for all IP wireless - Wireless = lossy, long latency Work items Robust Header Compression of IP/UDP/RTP - need for e2e VoIP/video - RFC3095 july 2001 used by 3GPP and 3GPP2 - ROHC over PPP; 0-byte LLA submitted to IESG ROHC for TCP is starting to gel New: signaling compression (reduce latency) - universal decompressor ROHC is working on MIBs Next work will probably be related to SCTP RFC 2507 is not good enough as it does not handle options like SACK, timestamps - need to compress ECN bits well - cope with TCP's extensibility - (state of the ar ha advanced) Requirements drafts presented: 2 drafts - please read and comment on 01/03 versions once available! Solutions : two drafts in the process of merging Need wider input wrt next generation TCP ROHC TCP Requirements - Links with few residual erros but may have packet loss - Robustness o Should not disable TCOP mechanisms o Must NOT generate damaged headers o Must deal with current and future TCPs o TCP sequence numbers and IP ID less predictable TCP Sample Issues - TCP checksum and.or additional CRC for checking - Unidirectional vs bi-directional compression - Can ROHC ignore IP options? - Compress in tunnel encapsulations, too? o Reordering (prohibited, detected, allowed)? - Integrate with ASYM mechanisms - What are the assumptions about ECN behavior? - What loss amplifications behaviours are actually acceptable? - IPR Comments from floor - even if residual error is low, what is error distribution (burst errors vs uniform distribution errors). However, residual bit errors as defined by ROHC are packet with errors passed from layer 2 too layer 3. =================== IP-DVB announcement G. Fairhurst 2min G. Fairhurst extended an invitation to an informal meeting on 12/12 at 15:30 - 17:30. The meeting will be on IP over DVB. It is not an BoF, but a maillist will be created for those interested in this subject. More information can be found at http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/. From owner-pilc@grc.nasa.gov Wed Jan 16 05:02:39 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03490 for ; Wed, 16 Jan 2002 05:02:39 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D5DE8C6943; Wed, 16 Jan 2002 04:59:44 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAxKaaFj; Wed, 16 Jan 02 04:59:44 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA01942 for pilc-outgoing; Wed, 16 Jan 2002 04:52:05 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id EAA01938 for ; Wed, 16 Jan 2002 04:52:00 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id EAA05243 for ; Wed, 16 Jan 2002 04:51:59 -0500 (EST) Received: by seraph3.grc.nasa.gov (Postfix, from userid 5) id 5932F640A8; Wed, 16 Jan 2002 04:51:56 -0500 (EST) Received: from gtdei-natgw.dei.uc.pt(193.137.203.232) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAABdaqeD; Wed, 16 Jan 02 04:51:55 -0500 Received: from pan.eden.dei.uc.pt (pan.dei.uc.pt [10.2.0.27]) by eden.dei.uc.pt (8.11.6/8.11.6) with ESMTP id g0G9nst373651; Wed, 16 Jan 2002 09:49:54 GMT Message-Id: <5.1.0.14.0.20020116095356.00a34010@eden.dei.uc.pt> X-Sender: boavida@eden.dei.uc.pt X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jan 2002 09:54:23 +0000 To: tcgn@ieee.org, itc@ieee.org, news-announce-conferences@uunet.uu.net, int-serv@ISI.EDU, cost264@lip6.fr, conf@colmar.uha.fr, cfp@mmlab.snu.ac.kr, rm@openmash.org, enternet@bbn.com, giga@tele.pitt.edu;, spects02@comp.leeds.ac.uk, sigmob@acm.org, kuvs-elg@fokus.gmd.de, news-announce-conferences@uunet.uu.net, pilc@grc.nasa.gov From: Fernando Boavida Subject: IDMS-PROMS'2002 Call for Papers Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3452246==_.ALT" Sender: owner-pilc@grc.nasa.gov Precedence: bulk --=====================_3452246==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable We apologize if you receive multiple copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IDMS/PROMS'2002 Joint International Workshop on Interactive Distributed Multimedia Systems / Protocols for Multimedia Systems http:// ip2002.dei.uc.pt/ November 26-29, 2002 University of Coimbra, Coimbra, Portugal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Interactive Distributed Multimedia Systems (IDMS) and Protocols for Multimedia Systems (PROMS) have been two successful series of international events bringing together researchers, developers and practitioners from academia and industry in all areas of multimedia systems. In 2002, for the first time, these two workshops will be held jointly, in what is expected to be the first of a new series of challenging and topical international workshops. IDMS/PROMS'2002 is intended to contribute to scientific, strategic and practical advances in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. Along with tutorials, invited papers and technical demonstrations, IDMS/PROMS'2002 is seeking first quality original work. Relevant topics to IDMS/PROMS'2002 include, but are not limited to: Mobile multimedia systems Multimedia middleware Multimedia communication protocols Quality of service issues Resource management Next generation Internet Active and programmable networking for multimedia applications Multimedia-specific mobile agents Multimedia distribution and transport Multimedia traffic engineering Multimedia encoding and compression Ubiquitous computing Development tools for distributed multimedia applications Multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, multimedia conferencing, virtual reality simulations Performance of protocols and applications: modelling, simulation and optimisation in different networks Multimedia content management Service access - security, authentication, privacy, watermarking Accounting and tariff policing for multimedia teleservices Standards (e.g., MPEG) and related issues IDMS/PROMS'2002 will consist of a two and a half day technical program, plus a full day of tutorials, and demonstrations during the workshop. Contributions in the form of full papers and position papers are encouraged. Full papers should describe innovative and significant work. Position papers are meant to enable researchers to present exciting ongoing work in early stages, opinions about current developments, and suggestions for future directions. The purpose of position papers is to provide a seed for debate and discussion. Both types of papers will be reviewed by the program committee and included in the workshop proceedings, which will be published by Springer-Verlag as part of the Lecture Notes in Computer Science series. Information for authors ----------------------- Authors are invited to submit full papers and position papers in PDF or Postscript formats through the workshop website http://ip2002.dei.uc.pt/. Submitted papers must describe original work not submitted elsewhere. Full papers must not be longer than 12 single-spaced pages, and position papers must not be longer than 6 single-spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. Final versions of accepted papers must be structured according to the instructions of Springer-Verlag (http://www.springer.de/comp/lncs/authors.html) Best paper award ---------------- A jury will select the best paper, based on the quality of the written paper. The winner will be awarded a prize donated by one of the workshop sponsors. General information ------------------- For more information visit http://ip2002.dei.uc.pt/ or mail to ip2002@dei.uc.pt (Fax.: +351 239 701266). See also the webpages of previous IDMS and PROMS events: IDMS'2001 - http://www.idms2001.org/ PROMS'2001 - http://www.ctit.utwente.nl/news/proms_2001/ Important dates --------------- Paper submissions due: May 15th, 2002 Notification of acceptance: June 30th, 2002 Camera ready version due: September 10th, 2002 Program Chair ------------- Fernando Boavida, University of Coimbra, Portugal Tutorial Chair -------------- Edmundo Monteiro, University of Coimbra, Portugal Steering Committee ------------------ Thomas Plagemann, University of Oslo, UniK, Norway Patrick Senac, ENSICA, France Hans Scholten, Twente University, The Netherlands Marten van Sinderen, Twente University, The Netherlands Joe Finney, Lancaster University, United Kingdom Laurent Mathy, Lancaster University, United Kingdom Zdzislaw Papir, AGH University of Technology, Poland Arturo Azcorra, Carlos III University, Madrid, Spain Program Committee ----------------- Alexandre Santos, University of Minho, Portugal Andrew Campbell, Columbia University, USA Arnaldo Martins, University of Aveiro, Portugal Arturo Azcorra, Carlos III University, Madrid, Spain Augusto Casaca, INESC, Portugal Burkhard Stiller, ETH Zurich, Switzerland David Hutchison, Lancaster University, United Kingdom Edmundo Madeira, University of Campinas, Brazil Edmundo Monteiro, University of Coimbra, Portugal Fernando Boavida, University of Coimbra, Portugal Fernando Pereira, Instituto Superior T=E9cnico, Portugal Francisco Fontes, Portugal Telecom Inova=E7=E3o, SA, Portugal Frank Eliassen, University of Oslo, Norway Fred Stentiford, BTexaCT Research, United Kingdom Giorgio Ventre, University Frederico II, Napoli, Italy Greg O'Shea, Microsoft Research Cambridge, United Kingdom Gregor v. Bochmann, University of Otawa, Canada Guy Leduc, University of Liege, Belgium Hans Scholten, Twente University, The Netherlands Henk Eertink, Telematica Instituut, The Netherlands Jan Bormans, IMEC, Belgium Jason Nieh, Columbia University, USA Jean-Luc Raffy, Institut National des Telecommunications, France Joao Orvalho, ESEC/CISUC, Portugal Joe Finney, Lancaster University, United Kingdom Jordi Domingo-Pascual, Universitat Polit=E8cnica de Catalunya, Spain Ketan Mayer-Patel, University of North Carolina, USA Lars Wolf, University of Karlsruhe, Germany Laurent Mathy, Lancaster University, United Kingdom Marten van Sinderen, University of Twente, The Netherlands Martin Mauve, University of Mannheim, Germany Michel Diaz, LAAS-CNRS, France Nick Race, Lancaster University, United Kingdom Patrick Senac, ENSICA, France Paul D. Amer, University of Delaware, USA Philippe Owezarski, LAAS-CNRS, France Radu Popescu-Zeletin, GMD-FOKUS, Germany Ralf Steinmetz, TU Darmstadt, Germany Roberto Canonico, University Frederico II, Napoli, Italy Serge Fdida, LiP6, France Sergio Palazzo, University of Catania, Italy Thomas Plagemann, University of Oslo, Unik, Norway Tim Chown, University of Southampton, United Kingdom Timothy Roscoe, Sprint Labs, USA Tobias Helbig, Philips Research Laboratories, Germany Ulrich Hofmann, University of Salzburg, Austria Vera Goebel, University of Oslo, Norway Winfried Kalfa, TU Chemnitz, Germany Wolfgang Effelsberg, University of Mannheim, Germany Zdzislaw Papir, AGH University of Technology, Poland Local Organising Committee -------------------------- Jo=E3o Orvalho (Chair), ESEC/CISUC, Portugal Jorge S=E1 Silva, University of Coimbra, Portugal Mar=EDlia Oliveira, University of Coimbra, Portugal Paulo Sim=F5es, University of Coimbra, Portugal --------------------------------------------------------------------------- Fernando Boavida (Associate Professor) Dept. Engenharia Informatica Tel.: + 351 239 790012 Universidade de Coimbra Fax.: + 351 239 701266 POLO II . Pinhal de Marrocos e-mail: boavida@dei.uc.pt P-3030 COIMBRA = http://www.dei.uc.pt/~boavida --------------------------------------------------------------------------- --=====================_3452246==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We apologize if you receive multiple copies.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

            &nbs= p;         IDMS/PROMS'2002
            &nbs= p; Joint International Workshop on
         Interactive Distributed Multimedia Systems /
             Protocols for Multimedia Systems
            &nbs= p;   http:// ip2002.dei.uc.pt/

            &nbs= p;     November 26-29, 2002
           University of= Coimbra, Coimbra, Portugal

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Interactive Distributed Multimedia Systems (IDMS) and Protocols for
Multimedia Systems (PROMS) have been two successful series of international=
events bringing together researchers, developers and practitioners from
academia and industry in all areas of multimedia systems. In 2002, for
the first time, these two workshops will be held jointly, in what is
expected to be the first of a new series of challenging and topical
international workshops.

IDMS/PROMS'2002 is intended to contribute to scientific, strategic and
practical advances in the area of distributed multimedia applications,
protocols, and intelligent management tools, with emphasis on their
provision over broadband networks. Along with tutorials, invited papers
and technical demonstrations, IDMS/PROMS'2002 is seeking first quality
original work.

Relevant topics to IDMS/PROMS'2002 include, but are not limited to:
 
        Mobile= multimedia systems
        Multimedia= middleware
        Multimedia= communication protocols
        Quality of= service issues
        Resource= management
        Next= generation Internet
        Active and= programmable networking for multimedia applications
        Multimedia-sp= ecific mobile agents
        Multimedia= distribution and transport
        Multimedia= traffic engineering
        Multimedia= encoding and compression
        Ubiquitous= computing
        Development= tools for distributed multimedia applications
        Multimedia= applications: video-on-demand, digital video libraries,
          = video games, virtual community, teleworking, teleteaching,
          = e-commerce, telemeeting, multimedia conferencing, virtual
          = reality simulations
        Performance= of protocols and applications: modelling, simulation
          = and optimisation in different networks
        Multimedia= content management
        Service= access - security, authentication, privacy, watermarking
        Accounting= and tariff policing for multimedia teleservices
        Standards= (e.g., MPEG) and related issues

IDMS/PROMS'2002 will consist of a two and a half day technical program,
plus a full day of tutorials, and demonstrations during the workshop.
Contributions in the form of full papers and position papers are encouraged.=
Full papers should describe innovative and significant work. Position
papers are meant to enable researchers to present exciting ongoing work
in early stages, opinions about current developments, and suggestions for=
future directions. The purpose of position papers is to provide a seed
for debate and discussion. Both types of papers will be reviewed by the
program committee and included in the workshop proceedings, which will
be published by Springer-Verlag as part of the Lecture Notes in Computer=
Science series.

Information for authors
-----------------------

Authors are invited to submit full papers and position papers in PDF
or Postscript formats through the workshop website http://ip2002.dei.uc.pt/.
Submitted papers must describe original work not submitted elsewhere. Full=
papers must not be longer than 12 single-spaced pages, and position
papers must not be longer than 6 single-spaced pages. Both types of
papers should contain an abstract of approximately 300 words, and include=
title, authors and affiliations. Final versions of accepted papers must
be structured according to the instructions of Springer-Verlag
(http://www.springer.de/comp/lncs/authors.html)
Best paper award
----------------

A jury will select the best paper, based on the quality of the written
paper. The winner will be awarded a prize donated by one of the workshop=
sponsors.

General information
-------------------

For more information visit http://ip2002.dei.uc.pt/ or mail to
ip2002@dei.uc.pt
(Fax.: +351 239 701266).
See also the webpages of previous IDMS and PROMS events:
IDMS'2001 - http://www.idms2001.org/
PROMS'2001 - http://www.ctit.utwente.nl/news/proms_2001/

Important dates
---------------

Paper submissions= due:        &= nbsp; May 15th,= 2002        &= nbsp; 
Notification of acceptance:     June= 30th, 2002 
Camera ready version= due:       September= 10th,= 2002        &= nbsp;   


Program Chair
-------------

Fernando Boavida, University of Coimbra, Portugal


Tutorial Chair
--------------
Edmundo Monteiro, University of Coimbra, Portugal


Steering Committee
------------------

Thomas Plagemann, University of Oslo, UniK,= Norway        = ;      
Patrick Senac, ENSICA, France
Hans Scholten, Twente University, The Netherlands
Marten van Sinderen, Twente University, The Netherlands
Joe Finney, Lancaster University, United Kingdom
Laurent Mathy, Lancaster University, United Kingdom
Zdzislaw Papir, AGH University of Technology, Poland
Arturo Azcorra, Carlos III University, Madrid, Spain

Program Committee
-----------------

Alexandre Santos, University of Minho, Portugal
Andrew Campbell, Columbia University, USA
Arnaldo Martins, University of Aveiro, Portugal
Arturo Azcorra, Carlos III University, Madrid, Spain
Augusto Casaca, INESC, Portugal
Burkhard Stiller, ETH Zurich, Switzerland
David Hutchison, Lancaster University, United Kingdom
Edmundo Madeira, University of Campinas, Brazil
Edmundo Monteiro, University of Coimbra, Portugal
Fernando Boavida, University of Coimbra, Portugal
Fernando Pereira, Instituto Superior T=E9cnico, Portugal
Francisco Fontes, Portugal Telecom Inova=E7=E3o, SA, Portugal
Frank Eliassen, University of Oslo, Norway
Fred Stentiford, BTexaCT Research, United Kingdom
Giorgio Ventre, University Frederico II, Napoli, Italy
Greg O'Shea, Microsoft Research Cambridge, United Kingdom
Gregor v. Bochmann, University of Otawa, Canada
Guy Leduc, University of Liege, Belgium
Hans Scholten, Twente University, The Netherlands
Henk Eertink, Telematica Instituut, The Netherlands
Jan Bormans, IMEC, Belgium
Jason Nieh, Columbia University, USA
Jean-Luc Raffy, Institut National des Telecommunications, France 
Joao Orvalho, ESEC/CISUC, Portugal
Joe Finney, Lancaster University, United Kingdom
Jordi Domingo-Pascual, Universitat Polit=E8cnica de Catalunya, Spain
Ketan Mayer-Patel, University of North Carolina, USA
Lars Wolf, University of Karlsruhe, Germany
Laurent Mathy, Lancaster University, United Kingdom
Marten van Sinderen, University of Twente, The Netherlands
Martin Mauve, University of Mannheim, Germany
Michel Diaz, LAAS-CNRS, France
Nick Race, Lancaster University, United Kingdom
Patrick Senac, ENSICA, France
Paul D. Amer, University of Delaware, USA
Philippe Owezarski, LAAS-CNRS, France
Radu Popescu-Zeletin, GMD-FOKUS, Germany
Ralf Steinmetz, TU Darmstadt, Germany
Roberto Canonico, University Frederico II, Napoli, Italy
Serge Fdida, LiP6, France
Sergio Palazzo, University of Catania, Italy
Thomas Plagemann, University of Oslo, Unik, Norway
Tim Chown, University of Southampton, United Kingdom
Timothy Roscoe, Sprint Labs, USA
Tobias Helbig, Philips Research Laboratories, Germany
Ulrich Hofmann, University of Salzburg, Austria
Vera Goebel, University of Oslo, Norway
Winfried Kalfa, TU Chemnitz, Germany
Wolfgang Effelsberg, University of Mannheim, Germany  
Zdzislaw Papir, AGH University of Technology, Poland

Local Organising Committee
--------------------------
Jo=E3o Orvalho (Chair), ESEC/CISUC, Portugal
Jorge S=E1 Silva, University of Coimbra, Portugal
Mar=EDlia Oliveira, University of Coimbra, Portugal
Paulo Sim=F5es, University of Coimbra, Portugal

------------------------------------------------------------------= ---------
Fernando Boavida (Associate= Professor)           = ;           
Dept. Engenharia= Informatica          &nbs= p;      Tel.: + 351 239 790012
Universidade de= Coimbra           &n= bsp;          Fax.: + 351 239= 701266
POLO II . Pinhal de= Marrocos           &= nbsp;     e-mail: boavida@dei.uc.pt
P-3030= COIMBRA       &nbs= p;          = ;        &nbs= p;         http://www.dei.uc.pt/~boavida
---------------------------------------------------------------------------<= br>
 --=====================_3452246==_.ALT-- From owner-pilc@grc.nasa.gov Thu Jan 17 18:27:55 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15455 for ; Thu, 17 Jan 2002 18:27:49 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0HNRqn23580 for ; Thu, 17 Jan 2002 18:27:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAARfaydU; Thu, 17 Jan 02 18:27:52 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA26403 for pilc-outgoing; Thu, 17 Jan 2002 18:18:05 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA26394; Thu, 17 Jan 2002 18:18:04 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA28699; Thu, 17 Jan 2002 18:18:03 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0HNI2w14664; Thu, 17 Jan 2002 18:18:02 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAjia4OC; Thu, 17 Jan 02 18:18:02 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HNHxT14870; Thu, 17 Jan 2002 17:17:59 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 17:17:59 -0600 Message-ID: From: "Farid Khafizov" To: "'mallman@grc.nasa.gov'" , "'Phil Karn'" , "'Aaron Falk'" , pilc Cc: "Mehmet Yavuz", "Farid Khafizov" Subject: RE: pilc minutes (corrected) Date: Thu, 17 Jan 2002 17:17:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19FAD.32DBF8C0" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19FAD.32DBF8C0 Content-Type: text/plain; charset="iso-8859-1" Enclosed please find suggested text on Bandwidth Oscillation for LINK-ID and comments on the latest version of the draft. --Farid //------------------------------------------------------------------------- // Suggested addition to LINK-ID (draft-ietf-pilc-link-design-08.txt) // To follow directly "BoD Subnets" section //------------------------------------------------------------------------- Bandwidth Oscillation When shared resources are periodically assigned to users for a limited time, BoD systems may experience Bandwidth Oscillation. One example is a CDMA based wireless data network such as UMTS or CDMA2000. Limited pool of orthogonal codes and RF transmit power necessitates time-sharing of those resources. If a number of users require, for example, large data files transfer at the same time, the system (e.g., the scheduler) may have to repeatedly allocate and de-allocate resources for each user. Such mode of operation causes Bandwidth Oscillation, which can result in spurious timeouts, and, hence, throughput degradation. Although effects of spurious retransmission have been extensively studied in the literature (e.g., [LK00]), it is important to note that in some cases Bandwidth Oscillation can be the single most important factor in throughput reduction. It has been shown that for some configurations of CDMA2000 networks, throughput degradation can be in excess of 50% [n1]. Experiments have also shown that effects of Bandwidth Oscillation can amplify throughput degradation caused by TCP segment loss or reordering. At the time of writing of this document IETF was working on recommendations for TCP options [n2] that could reduce adverse effects of BOS. Consensus of this forum, however, is that a better solution can be found by properly designing sub-networks. For a fixed TCP configuration, throughput reduction depends on the high bandwidth (HB), the duration of HB (B), the low bandwidth (LB) and the duration of LB (D). By choosing appropriate combination of throughput degradation can be reduced or even avoided. However, in cases when multiple users share same resources, B and D are related and reducing D becomes impossible without reduction of B. In addition, attempts to reduce B and/or D may increase signaling overhead, and, therefore, limit designers' flexibility in choosing the optimal configuration. [n1] F.Khafizov, M.Yavuz, "Running TCP over IS-2000", to appear in Proc. of IEEE ICC 2002 [n2] H. Inamura, G. Montenegro, M. Hata, M. Hara, J. James, W. Gilliam, A. Hameed, R. Ludwig, R. Garces, P. Ford, F. Wills, "TCP over 2.5G and 3G Wireless Networks", work in progress as internet-draft, draft-ietf-pilc-2.5g3g-05, November 2001 //------------------------------------------------------------------------- // Comments on existing text available at http://people.qualcomm.com/karn/pilc.txt //------------------------------------------------------------------------- Section: Choosing the MTU in Slow Networks > "However, the link resources used to > send the aborted packet are lost, and overall throughput will > decrease." It is probably me not being a native speaker, but I felt the above sentence wasn't very clear: I had trouble with present and future tense verbs in one sentence. Perhaps it should be written as "However, when the link resources used to send the aborted packet are lost, the overall throughput decreases." or "However, in this case, the link resources used to send the aborted packet are lost, and overall throughput decreases." //------------------------------------------------------------------------- Section: How TCP Works > "Since the most common cause of packet loss is congestion" Although this is true considering overall Internet traffic, in (at least some) wireless networks this assumption is not true. Experiments suggest that packet loss due to high BER is comparable or higher than that due to congestion. Perhaps that fact should be mentioned with the reference to rfc3155. //------------------------------------------------------------------------- Section: How TCP Works > "Recent proposals have been made to lower the > dupack threshold to 2." Would be nice to have a reference to "proposals" //------------------------------------------------------------------------- Section: TCP Performance Characteristics -> Analysis of Link-Layer Effects on TCP Performance > "If this link layer were used in the Internet, on a path that > otherwise had a round trip of of 80 msec, " "of of" //------------------------------------------------------------------------- Section: Bandwidth Asymmetries > "acknowledgments is too large, the slow return of of the ACKs directly" "of of" //------------------------------------------------------------------------- Section: Buffering, flow & congestion control > "Available Bit rate (ABR" should have "Rate" //------------------------------------------------------------------------- Section: Compression > "We make a stronger recommendation that subnetworks operating at low > speed or with small MTUs compress IP and transport-level headers" should be "We make a stronger recommendation that subnetworks operating at low BER conditions and low speed or with small MTUs compress IP and transport-level headers " It is mentioned later in the text that in the presence of errors header compression is not a good idea. Here one might add that in such circumstances there is no benefit of Fast Retransmit/Fast Recovery mechanism. //------------------------------------------------------------------------- Section: Mobility > "the most appropriate and efficient. Mobility is already an feature of" article change "an" -> "a" //------------------------------------------------------------------------- Section: Security Considerations > "2. Use of 'security by obscurity' [Schneier4] [Crypto9912]. One" and > "3. Inclusion of trapdoors [Schneier4] [Crypto9912]. Trapdoors are" Reference [Schneier4] is not defined //------------------------------------------------------------------------- > -----Original Message----- > From: Aaron Falk [SMTP:falk@ISI.EDU] > Sent: Monday, January 14, 2002 1:04 PM > To: pilc; minutes@ietf.org > Subject: pilc minutes (corrected) > ========================= > > CDMA2000 > > F. Khafizov presented slides on TCP performance over CDMA 2000 > networks. Issues to be addressed include bandwidth oscillation, high > BER, and bandwidth asymmetry. Bandwidth oscillation degrades > throughput through spurious timeouts. True of any system with widely > varying bandwidth. > > * Bandwidth Oscillations (BO) > - Significant throughput degradation > - Not cdma2000 specific > - Related to resource contention > - Fixes include 1) fix TCP, 2) Fix network or 3) leave as is. > - Possible fixes > o Adjust RTO value > o enable Time Stamp option > o increase window size > o minimize ACK delay > - Other recommendations > o Aggressive link level error recovery > o disable VJ header compression > o use SACK > - Options > o Incorporate BO in 2.5g/3g and/or LINK ID > o make a separate ID for BO > o have a section in 2.5G/#g ID addressing specifics of CMDA2000 > > Suggestions from chair and floor moved toward including in existing > documents rather than stand-alone document. > > F. Khafizov volunteer to generate text for the documents. > > > ------_=_NextPart_001_01C19FAD.32DBF8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: pilc minutes (corrected)

Enclosed = please find suggested text on Bandwidth Oscillation for LINK-ID
and = comments on the latest version of the draft.
--Farid

//-------------------------------------------------------= ------------------
// Suggested addition to LINK-ID = (draft-ietf-pilc-link-design-08.txt)
// To follow directly "BoD = Subnets" section
//-------------------------------------------------------= ------------------


Bandwidth Oscillation

When shared resources are periodically = assigned to users for a limited time, BoD systems may experience = Bandwidth Oscillation. One example is a CDMA based wireless data = network such as UMTS or CDMA2000. Limited pool of orthogonal codes and = RF transmit power necessitates time-sharing of those resources. If a = number of users require, for example, large data files transfer at the = same time, the system (e.g., the scheduler) may have to repeatedly = allocate and de-allocate resources for each user. Such mode of = operation causes Bandwidth Oscillation, which can result in spurious = timeouts, and, hence, throughput degradation. Although effects of = spurious retransmission have been extensively studied in the literature = (e.g., [LK00]), it is important to note that in some cases Bandwidth = Oscillation can be the single most important factor in throughput = reduction. It has been shown that for some configurations of CDMA2000 = networks, throughput degradation can be in excess of 50% [n1]. = Experiments have also shown that effects of Bandwidth Oscillation can = amplify throughput degradation caused by TCP segment loss or = reordering.

At the time of writing of this = document IETF was working on recommendations for TCP options [n2] that = could reduce adverse effects of BOS. Consensus of this forum, however, = is that a better solution can be found by properly designing = sub-networks. For a fixed TCP configuration, throughput reduction = depends on the high bandwidth (HB), the duration of HB (B), the low = bandwidth (LB) and the duration of LB (D). By choosing appropriate = combination of <HB,B,LB,D> throughput degradation can be reduced = or even avoided. However, in cases when multiple users share same = resources, B and D are related and reducing D becomes impossible = without reduction of B. In addition, attempts to reduce B and/or D may = increase signaling overhead, and, therefore, limit designers' = flexibility in choosing the optimal configuration.

[n1] F.Khafizov, M.Yavuz, = "Running TCP over IS-2000", to appear in Proc. of IEEE ICC = 2002
[n2] H. Inamura, G. Montenegro, M. = Hata, M. Hara, J. James, W. Gilliam, A. Hameed, R. Ludwig, R. Garces, = P. Ford, F. Wills, "TCP over 2.5G and 3G Wireless Networks", = work in progress as internet-draft, draft-ietf-pilc-2.5g3g-05, November = 2001



//-------------------------------------------------------= ------------------
// Comments on existing text = available at http://people.qualcomm.com/karn/pilc.txt
//-------------------------------------------------------= ------------------
Section: Choosing the MTU in Slow = Networks

>       =          =            "However, = the link resources used to
>   send the aborted = packet are lost, and overall throughput will
>   = decrease."

It is probably me not being a native = speaker, but I felt the above
sentence wasn't very clear: I had = trouble with present and future tense
verbs in one sentence. Perhaps it = should be written as

        =                     = "However, when the link resources used to
   send the aborted packet = are lost, the overall throughput
   decreases."

or
        =                     = "However, in this case, the link resources used to
   send the aborted packet = are lost, and overall throughput
   decreases."


//-------------------------------------------------------= ------------------
Section: How TCP Works

>   "Since the most = common cause of packet loss is congestion"

Although this is true considering = overall Internet traffic,
in (at least some) wireless networks = this assumption is not true.
Experiments suggest that packet loss = due to
high BER is comparable or higher than = that due to congestion.
Perhaps that fact should be mentioned = with the reference to rfc3155.

//-------------------------------------------------------= ------------------
Section: How TCP Works

>       =         "Recent proposals have = been made to lower the
>       =            dupack = threshold to 2."

Would be nice to have a reference to = "proposals"


//-------------------------------------------------------= ------------------
Section: TCP Performance = Characteristics -> Analysis of Link-Layer Effects on TCP = Performance

>       "If this = link layer were used in the Internet, on a path that
>          = otherwise had a round trip of of 80 msec, "

"of of"


//-------------------------------------------------------= ------------------
Section: Bandwidth Asymmetries

>       = "acknowledgments is too large, the slow return of of the ACKs = directly"

"of of"


//-------------------------------------------------------= ------------------
Section: Buffering, flow & = congestion control

>       "Available = Bit rate (ABR"

should have "Rate"


//-------------------------------------------------------= ------------------
Section: Compression

>       "We make a = stronger recommendation that subnetworks operating at low
>          = speed or with small MTUs compress IP and transport-level = headers"

should be

        "We make a stronger recommendation that subnetworks = operating at low BER conditions and low
           speed or with small MTUs compress IP and = transport-level headers "

It is mentioned later in the text that = in the presence of errors header compression
is not a good idea. Here one might = add that in such circumstances there is no benefit
of Fast Retransmit/Fast Recovery = mechanism.


//-------------------------------------------------------= ------------------
Section: Mobility

>   "the most = appropriate and efficient. Mobility is already an feature = of"

article change "an" -> = "a"


//-------------------------------------------------------= ------------------
Section: Security = Considerations

>       = "2. Use of 'security by obscurity' [Schneier4] [Crypto9912].  = One"
and
>       "3. = Inclusion of trapdoors [Schneier4] [Crypto9912].  Trapdoors = are"

Reference [Schneier4] is not defined =
//-------------------------------------------------------= ------------------








-----Original Message-----
From:   Aaron Falk [SMTP:falk@ISI.EDU]
Sent:   Monday, January 14, 2002 1:04 PM
To:     pilc; minutes@ietf.org
Subject:       = pilc minutes (corrected)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

CDMA2000

F. Khafizov presented slides on TCP = performance over CDMA 2000
networks.  Issues to be = addressed include bandwidth oscillation, high
BER, and bandwidth asymmetry.  = Bandwidth oscillation degrades
throughput through spurious = timeouts.  True of any system with widely
varying bandwidth.

* Bandwidth Oscillations (BO)
  -     = Significant throughput degradation
  -     Not = cdma2000 specific
  -     = Related to resource contention
  -     = Fixes include 1) fix TCP, 2) Fix network or 3) leave as is.
  -     = Possible fixes
   = o     Adjust RTO value
   = o     enable Time Stamp option
   = o     increase window size
   = o     minimize ACK delay
  -     = Other recommendations
   = o     Aggressive link level error recovery
   = o     disable VJ header compression
   = o     use SACK
  -     = Options
   = o     Incorporate  BO in 2.5g/3g and/or LINK = ID
   = o     make a separate ID for BO
   = o     have a section in 2.5G/#g ID addressing = specifics of CMDA2000

Suggestions from chair and floor moved = toward including in existing
documents rather than stand-alone = document.

F. Khafizov   volunteer to = generate text for the documents.



------_=_NextPart_001_01C19FAD.32DBF8C0-- From owner-pilc@grc.nasa.gov Thu Jan 17 18:35:45 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15588 for ; Thu, 17 Jan 2002 18:35:45 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0HNZlA17483 for ; Thu, 17 Jan 2002 18:35:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAApjaqjI; Thu, 17 Jan 02 18:35:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA28558 for pilc-outgoing; Thu, 17 Jan 2002 18:30:05 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA28549 for ; Thu, 17 Jan 2002 18:30:03 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA00310 for ; Thu, 17 Jan 2002 18:30:03 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0HNU1324188 for ; Thu, 17 Jan 2002 18:30:01 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAApPaqpV; Thu, 17 Jan 02 18:30:01 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0HNTwT16604; Thu, 17 Jan 2002 17:29:58 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 17:29:58 -0600 Message-ID: From: "Farid Khafizov" To: "'pilc@grc.nasa.gov'" , "'Hiroshi INAMURA'" , "'Aaron Falk'" Cc: "Mehmet Yavuz", "Farid Khafizov" Subject: 2.5g/3g ID additions (RE: pilc minutes (corrected)) Date: Thu, 17 Jan 2002 17:29:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19FAE.E02BB050" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19FAE.E02BB050 Content-Type: text/plain; charset="iso-8859-1" Enclosed please find revised version of earlier submitted text on VJC and Bandwidth Oscillation for 2.5g/3g ID. Thanks, --Farid ----------------------------------------------------------------------- 1. Disabling Van Jacobson TCP/IP Header Compression Van Jacobson TCP/IP header compression (VJC) algorithm [35] is negotiated between peer PPP layers. In CDMA2000 networks it could be implemented between the Mobile Terminal Equipment, such as laptop computer, and the Packet Data Serving Node. The algorithm was designed to increase application layer throughput by reducing packetization overhead [11]. For TCP segment size of 1000 Bytes, enabling VJC increases throughput by about 4%, if there is no packet loss. However, experiments have shown that in the presence of wireless link errors, VJC is not desirable [n4]. If a wireless link error is not recovered, it will cause TCP segment loss between peer PPP layers, and then VJC does not allow TCP to take advantage of Fast Retransmit Fast Recovery mechanism. VJC algorithm transmits not the TCP/IP headers but only the changes in the headers of consecutive segments. Therefore, loss of a TCP segment on the VJC link causes the transmitting and receiving TCP sequence numbers to go out of synch. When a TCP segment is lost, none of the following segment will be forwarded by the link until RTO expires [11]. It is recommended to disable VJC algorithm unless packet loss between peer PPP layers is very low. Robust Header Compression [34] was designed to address deficiencies of VJC. At the time of writing of this document, IETF was working on a proposal for negotiating Robust Header Compression over PPP [n5]. 2. Bandwidth Oscillation Limited RF spectrum along with high data rate requirement for 2.5G/3G wireless systems necessitate dynamic resource sharing among concurrent data users. Various scheduling mechanisms can be deployed in order to maximize resource utilization. Some of the limited resources in CDMA based systems (e.g., UMTS, CDMA2000) are orthogonal codes and RF transmit power. Shared channels in UMTS [N1] and supplemental channels in CDMA2000 [N2], designed for high speed traffic, utilize relatively high RF power and require higher portion of orthogonal code resources. Time division sharing of these resources may result in TCP throughput degradation. Usually these resources are allocated on per needed bases (bandwidth on demand) and released when there is no data to send. There could, however, be situations when resources are de-allocated while significant amount of data is still waiting in the queue. If a number of users require large data file transfer at the same time, the system (e.g., the scheduler) may have to repeatedly to allocate and de-allocate resources from each user. In this section we refer to periodic allocation and de-allocation of high-speed channel as Bandwidth Oscillation. Bandwidth Oscillation effects such as spurious retransmission were identified elsewhere (e.g., [17]) as throughput degradation factors. However, it is important to note that in case of some 3G wireless network configurations Bandwidth Oscillation can be the single most important factor in reducing throughput by as much as 30%-50%. In the next paragraph we give an example of Bandwidth Oscillation and define notation needed for further discussion. Although, the example is based on CDMA2000 system, the same considerations are applicable to many (wireless) systems with time scheduling of high-speed data traffic. CDMA2000 1x standard, IS-2000.2 [n2], provides means of transmitting data over two type of traffic channels: Fundamental (FCH) and Supplemental (SCH). Fundamental channel has a fixed low bandwidth (e.g., 9.6 kbps). Bandwidth of SCH is a multiple of that and could be as high as 32 times of FCH bandwidth. To simplify notation, we assume that FCH rate is fixed at 9.6 kbps, we denote (SCH+FCH)/FCH bandwidth ratio by O. Hence, O is proportional to the SCH rate. FCH is always assigned before data transmission begins. SCH is assigned on per needed basis. When SCH is being used we say that the call is in burst. There are two types of SCH assignments: finite and infinite [n3], which will be referred to as finite burst and infinite burst, respectively. Infinite burst means that SCH can be used for transmitting data until a release command is issued. Finite burst mode of operation limits the SCH usage to one of fourteen finite time intervals [n3] before it must be released. We denote the duration of SCH allocation by B. After SCH is released, it can be acquired again after certain delay (D). One of the ways of detecting congestion in TCP is RTO expiration. RTO computation algorithm [32] was designed to follow closely round trip time (RTT), but is known to work poorly when delay variance is high [11]. During high bandwidth (FCH+SCH) RTT is low and, if B is relatively long (e.g., 5.12 seconds), RTO converges to RTT. When SCH is released, suddenly RTT increases (proportionally to O) and low RTO expires forcing TCP into the Slow Start state, while actually none of the TCP segments were lost. B |<--------------->| |-----------------| | | | | | | | SCH+FCH | D | | | ---| |<---->| |------| FCH ------------------------------------------------------ Figure 1. Bandwidth oscillation. Full cycle time is B+D. SCH and FCH are used for transmitting data for time B, then SCH is released and only FCH carries data for time D. The best approach to avoiding adverse effects of Bandwidth Oscillation, is, perhaps, proper wireless sub-network design [11]. Simulation results as well as lab measurements suggest [N4] that when TCP parameters (and FCH rate) are fixed the level of throughput degradation (and achievable throughput) is a function of . For some combinations degradation of throughput could reach 55%. When B and/or D are low, the throughput degradation is less severe. However, deploying some 2.5/3G wireless systems with low B and/or D values could be impractical. Higher throughput is achieved when B is high, while signaling delays impose limits on reducing D. Avoiding finite burst mode of operation is also not practical because limited RF resources require time-sharing of SCH resources (e.g., scheduling users). Therefore, one has to consider other techniques that could reduce spurious retransmissions due to bandwidth oscillation. One obvious method was to adjust computed RTO value (or configure appropriately the minimum RTO value) at sending TCP. This technique, however, can not be recommended as a practical solution. Experiments have shown that RTO algorithm implementation compliant with RFC2988 [32] (e.g., minimum RTO=1 sec and initial RTO=3 sec) reduce number of spurious re-transmissions. Although RTO timer management specified in RFC2988 is not mandatory, implementation of retransmission timer restart when an ACK is received (section 5.3 of RFC2988) will further reduce (or even eliminate) spurious retransmissions. Secondary effects, such as TCP segment loss, in combination with Bandwidth Oscillation may not allow avoiding all spurious re-transmissions. Analysis of RTO algorithm along with an alternative (Eifel) algorithm are presented in [17]. Eifel algorithm requires timestamp option and at least one RTO expiration before TCP "learns" that retransmission was not necessary. Enabling timestamp option enables increased RTT sampling which can reduce spurious re-transmissions due to Bandwidth Oscillation. Other options that could reduce spurious re-transmissions due to Bandwidth Oscillation are increase CWND and reduce delay ACK timer at Receiving TCP to < 100 ms (however, this technique may have side effects in case bandwidth is limited in the opposite direction). [n1] "WCDMA for UMTS", edited by Harri Holma and Antti Toskala, John Wiley & Sons, Ltd., 2000 [n2] TIA/EIA/IS-2000.2-A, March, 2000, "Physical Layer Standard for cdma2000 Spread Spectrum Systems", [n3] TIA/EIA/IS-2000.5-A, "Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems", March, 2000 [n4] F.Khafizov, M.Yavuz, "Running TCP over IS-2000", to appear in Proc. of IEEE ICC 2002 [n5] C.Borman, "ROHC over PPP", Internet Draft, November 2001, http://www.normos.org/ietf/draft/draft-ietf-rohc-over-ppp-04.txt ------_=_NextPart_001_01C19FAE.E02BB050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 2.5g/3g ID additions (RE: pilc minutes (corrected))

Enclosed please find revised version of = earlier submitted text
on VJC and Bandwidth Oscillation for = 2.5g/3g ID.
Thanks,
--Farid





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

1. Disabling Van Jacobson TCP/IP Header = Compression

    Van Jacobson TCP/IP header compression = (VJC) algorithm [35] is negotiated between peer PPP layers. In CDMA2000 = networks it could be implemented between the Mobile Terminal Equipment, = such as laptop computer, and the Packet Data Serving Node. The = algorithm was designed to increase application layer throughput by = reducing packetization overhead [11]. For TCP segment size of 1000 = Bytes, enabling VJC increases throughput by about 4%, if there is no = packet loss.

    However, experiments have shown that in = the presence of wireless link errors, VJC is not desirable [n4]. If a = wireless link error is not recovered, it will cause TCP segment loss = between peer PPP layers, and then VJC does not allow TCP to take = advantage of Fast Retransmit Fast Recovery mechanism. VJC algorithm = transmits not the TCP/IP headers but only the changes in the headers of = consecutive segments. Therefore, loss of a TCP segment on the VJC link = causes the transmitting and receiving TCP sequence numbers to go out of = synch. When a TCP segment is lost, none of the following segment will = be forwarded by the link until RTO expires [11].

    It is recommended to disable VJC = algorithm unless packet loss between peer PPP layers is very low. = Robust Header Compression [34] was designed to address deficiencies of = VJC. At the time of writing of this document, IETF was working on a = proposal for negotiating Robust Header Compression over PPP = [n5].


2. Bandwidth Oscillation

    Limited RF spectrum along with high data = rate requirement for 2.5G/3G wireless systems necessitate dynamic = resource sharing among concurrent data users. Various scheduling = mechanisms can be deployed in order to maximize resource utilization. = Some of the limited resources in CDMA based systems (e.g., UMTS, = CDMA2000) are orthogonal codes and RF transmit power. Shared channels = in UMTS [N1] and supplemental channels in CDMA2000 [N2], designed for = high speed traffic, utilize relatively high RF power and require higher = portion of orthogonal code resources. Time division sharing of these = resources may result in TCP throughput degradation. Usually these = resources are allocated on per needed bases (bandwidth on demand) and = released when there is no data to send. There could, however, be = situations when resources are de-allocated while significant amount of = data is still waiting in the queue. If a number of users require large = data file transfer at the same time, the system (e.g., the scheduler) = may have to repeatedly to allocate and de-allocate resources from each = user.

    In this section we refer to periodic = allocation and de-allocation of high-speed channel as Bandwidth = Oscillation. Bandwidth Oscillation effects such as spurious = retransmission were identified elsewhere (e.g., [17]) as throughput = degradation factors. However, it is important to note that in case of = some 3G wireless network configurations Bandwidth Oscillation can be = the single most important factor in reducing throughput by as much as = 30%-50%. In the next paragraph we give an example of Bandwidth = Oscillation and define notation needed for further discussion. = Although, the example is based on CDMA2000 system, the same = considerations are applicable to many (wireless) systems with time = scheduling of high-speed data traffic.

    CDMA2000 1x standard, IS-2000.2 [n2], = provides means of transmitting data over two type of traffic channels: = Fundamental (FCH) and Supplemental (SCH). Fundamental channel has a = fixed low bandwidth (e.g., 9.6 kbps). Bandwidth of SCH is a multiple of = that and could be as high as 32 times of FCH bandwidth. To simplify = notation, we assume that FCH rate is fixed at 9.6 kbps, we denote = (SCH+FCH)/FCH bandwidth ratio by O. Hence, O is proportional to the SCH = rate. FCH is always assigned before data transmission begins. SCH is = assigned on per needed basis. When SCH is being used we say that the = call is in burst. There are two types of SCH assignments: finite and = infinite [n3], which will be referred to as finite burst and infinite = burst, respectively. Infinite burst means that SCH can be used for = transmitting data until a release command is issued. Finite burst mode = of operation limits the SCH usage to one of fourteen finite time = intervals [n3] before it must be released. We denote the duration of = SCH allocation by B. After SCH is released, it can be acquired again = after certain delay (D).

    One of the ways of detecting congestion = in TCP is RTO expiration. RTO computation algorithm [32] was designed = to follow closely round trip time (RTT), but is known to work poorly = when delay variance is high [11]. During high bandwidth (FCH+SCH) RTT = is low and, if B is relatively long (e.g., 5.12 seconds), RTO converges = to RTT. When SCH is released, suddenly RTT increases (proportionally to = O) and low RTO expires forcing TCP into the Slow Start state, while = actually none of the TCP segments were lost.

                = B            =
       = |<--------------->|      = |-----------------|      |
       = |            = ;     |      = |            = ;     |      |
       |   = SCH+FCH       |   D  = |            = ;     |      |
    ---|          &nb= sp;      = |<---->|         &nbs= p;       |------|  
               &= nbsp;           = FCH
    ------------------------------------------------------
    Figure 1. Bandwidth oscillation. Full = cycle time is B+D. SCH and FCH are used for transmitting data for time = B, then SCH is released and only FCH carries data for time = D.

    The best approach to avoiding adverse = effects of Bandwidth Oscillation, is, perhaps, proper wireless = sub-network design [11]. Simulation results as well as lab measurements = suggest [N4] that when TCP parameters (and FCH rate) are fixed the = level of throughput degradation (and achievable throughput) is a = function of <O, B, D>. For some combinations degradation of = throughput could reach 55%. When B and/or D are low, the throughput = degradation is less severe. However, deploying some 2.5/3G wireless = systems with low B and/or D values could be impractical. Higher = throughput is achieved when B is high, while signaling delays impose = limits on reducing D. Avoiding finite burst mode of operation is also = not practical because limited RF resources require time-sharing of SCH = resources (e.g., scheduling users).

    Therefore, one has to consider other = techniques that could reduce spurious retransmissions due to bandwidth = oscillation. One obvious method was to adjust computed RTO value (or = configure appropriately the minimum RTO value) at sending TCP. This = technique, however, can not be recommended as a practical solution. =

    Experiments have shown that RTO algorithm = implementation compliant with RFC2988 [32] (e.g., minimum RTO=3D1 sec = and initial RTO=3D3 sec) reduce number of spurious re-transmissions. = Although RTO timer management specified in RFC2988 is not mandatory, = implementation of retransmission timer restart when an ACK is received = (section 5.3 of RFC2988) will further reduce (or even eliminate) = spurious retransmissions. Secondary effects, such as TCP segment loss, = in combination with Bandwidth Oscillation may not allow avoiding all = spurious re-transmissions.

    Analysis of RTO algorithm along with an = alternative (Eifel) algorithm are presented in [17]. Eifel algorithm = requires timestamp option and at least one RTO expiration before TCP = "learns" that retransmission was not necessary. Enabling = timestamp option enables increased RTT sampling which can reduce = spurious re-transmissions due to Bandwidth Oscillation. Other options = that could reduce spurious re-transmissions due to Bandwidth = Oscillation are increase CWND and reduce delay ACK timer at Receiving = TCP to < 100 ms (however, this technique may have side effects in = case bandwidth is limited in the opposite direction).




    [n1] "WCDMA for UMTS", edited = by Harri Holma and Antti Toskala, John Wiley & Sons, Ltd., = 2000
    [n2] TIA/EIA/IS-2000.2-A, March, 2000, = "Physical Layer Standard for cdma2000 Spread Spectrum = Systems",
    [n3] TIA/EIA/IS-2000.5-A, "Upper = Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum = Systems", March, 2000
    [n4] F.Khafizov, M.Yavuz, "Running = TCP over IS-2000", to appear in Proc. of IEEE ICC 2002
    [n5] C.Borman, "ROHC over = PPP", Internet Draft, November 2001, http://www.normos.org/ietf/draft/draft-ietf-rohc-over-= ppp-04.txt

------_=_NextPart_001_01C19FAE.E02BB050-- From owner-pilc@grc.nasa.gov Thu Jan 17 19:03:46 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15951 for ; Thu, 17 Jan 2002 19:03:46 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0I03lx28463 for ; Thu, 17 Jan 2002 19:03:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAOoaWL3; Thu, 17 Jan 02 19:03:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA03051 for pilc-outgoing; Thu, 17 Jan 2002 18:57:45 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA03047 for ; Thu, 17 Jan 2002 18:57:44 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA04196 for ; Thu, 17 Jan 2002 18:57:43 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0HNvhW27573 for ; Thu, 17 Jan 2002 18:57:43 -0500 (EST) Received: from boreas.isi.edu(128.9.160.161) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAoxaG21; Thu, 17 Jan 02 18:57:43 -0500 Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0HNuAN27738; Thu, 17 Jan 2002 15:56:10 -0800 (PST) Date: Thu, 17 Jan 2002 15:56:10 -0800 From: Aaron Falk To: Farid Khafizov cc: "'pilc@grc.nasa.gov'" , "'Hiroshi INAMURA'" , Mehmet Yavuz Subject: Re: 2.5g/3g ID additions (RE: pilc minutes (corrected)) Message-ID: <1910000.1011311770@nit> In-Reply-To: References: X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > 1. Disabling Van Jacobson TCP/IP Header Compression > > Van Jacobson TCP/IP header compression (VJC) algorithm [35] is negotiated > between peer PPP layers. In CDMA2000 networks it could be implemented > between the Mobile Terminal Equipment, such as laptop computer, and the > Packet Data Serving Node. What is a Packet Data Serving Node? > The algorithm was designed to increase > application layer throughput by reducing packetization overhead [11]. For > TCP segment size of 1000 Bytes, enabling VJC increases throughput by > about 4%, if there is no packet loss. > > > 2. Bandwidth Oscillation > > > Analysis of RTO algorithm along with an alternative (Eifel) algorithm are > presented in [17]. per Mark: DSACK helps here too, no? > Eifel algorithm requires timestamp option and at least > one RTO expiration before TCP "learns" that retransmission was not > necessary. Enabling timestamp option enables increased RTT sampling which > can reduce spurious re-transmissions due to Bandwidth Oscillation. Other > options that could reduce spurious re-transmissions due to Bandwidth > Oscillation are increase CWND and reduce delay ACK timer at Receiving TCP > to < 100 ms (however, this technique may have side effects in case > bandwidth is limited in the opposite direction). > > --aaron From owner-pilc@grc.nasa.gov Fri Jan 18 05:22:07 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05497 for ; Fri, 18 Jan 2002 05:22:07 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IAM9P17647 for ; Fri, 18 Jan 2002 05:22:09 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAGEaWDI; Fri, 18 Jan 02 05:22:09 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA06271 for pilc-outgoing; Fri, 18 Jan 2002 05:16:27 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA06267 for ; Fri, 18 Jan 2002 05:16:26 -0500 (EST) From: BMIInews19@eudoramail.com Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id FAA20080 for ; Fri, 18 Jan 2002 05:16:25 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IAGPn16979 for ; Fri, 18 Jan 2002 05:16:25 -0500 (EST) Received: from unknown(216.116.192.197) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAitaqkH; Fri, 18 Jan 02 05:16:25 -0500 Received: from mx2.eudoramail.com ([204.32.146.133]) by ccbatch.infotechsys.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Fri, 18 Jan 2002 05:14:37 -0500 Message-ID: <0000092c344e$000022a9$00004a9c@mx2.eudoramail.com> To: Subject: BMII: A Marketing Giant in the Making FKXKMW Date: Fri, 18 Jan 2002 04:16:31 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reply-To: BMIInews19@eudoramail.com Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable = Investors
 <= /caption>
=

Emergin= g Growth Stock Alert
Blagman Media International: A Marketing Giant in the Making<= /td>


=       = Key Points about BMII:
  • BMII projects a total = run rate of between $80-100 million in 2002.

  • BMII currently manages an advertising and= promotional campaign for MET-Rx, the nation's leader in sports supplement= s.

  • Century Media= , BMII's pending acquisition target, is one of the nation's largest di= rect marketing firms, with a dozen Fortune 1000 companies as clients. <= br>
  • BMII has= the exclusive rights to market and advertise the national video release of a four video collec= tor's set of the best of "The Red Skelton Show."

    =
    Company Name  Blagman Media International (OTCBB: BMII)
    Current Pri= ce$0.0012 (12 hundredths of one cent)=
    52-Week High$0.56
    52-Week Low$0.0011=
<= td width=3D100% bgcolor=3D#2E524A>

Company Background

=

Today we have a look at= a classic merge and conquer scenario in the $200 billion dollar Di= rect Response sector.  The conqueror-to-be is called BMII (Bla= gman Media International, Inc.) The new company will combine the talents a= nd clients of some of the biggest names in the infomercial world un= der the Blagman name.  With its announced plans to acquire major comp= anies such as Century Media Inc. and Wellworld Group Ltd., BMII has quickl= y established a gateway for major immediate revenue stream coupled = with rapid internal growth.

A-List clients have inc= luded the likes of Proctor & Gamble, Kodak, Dainler-Chrysler, Black= and Decker, Home Shopping Network, and TriStar.  Total combined = billings for BMII upon the completion of its acquisitions are expected to = run from $80 to $100 million dollars in 2002.  This will give = BMII the financial leverage and the know-how to change the face of the Dir= ect Response industry.

Industry Stats

<= /table>

According to the= Direct Marketing Association (DMA), U.S. direct marketing expendit= ures , currently at $191.6 billion, are expected to continue to grow an= nually at 7.1% from 2002 until 2005.  Moreover, U.S. sales revenu= e due to direct marketing is estimated to reach more than $1.8 trillion fo= r 2001. Through 2005, such sales are estimated to grow by 9.6% annu= ally to reach $2.7 trillion. 

Again- Direct Respon= se will cause $2.7 trillion (estimated) in sales by 2005.  This f= igure goes to show the effectiveness of direct marketing as well as the li= kelihood that demand for Direct Response will continue to grow over the ye= ars.

BMII's Growth Strateg= y

Recognizing the opportunity for strategic consolidation in t= he Direct Response industry, the management of Century Media and Blagman d= ecided to utilize BMII to facilitate the acquisition strategy. = ; Through its public position, BMII assumed the lead role in the fi= nancing and negotiated the acquisition for a combination of stock and cash=

The company's senior management and board will consist of a com= bination of senior managers from both companies.  Currently, no other= direct independent competitor to BMII is in the field of Direct Response = having the breadth and depth of its combined enterprises.

At pres= ent, 99% of the pure play infomercial business is privately held.&n= bsp; And for good reason.  The margins offered by Direct Respo= nse sales are three and four times greater than traditional bricks-= and-mortar retail. Profit potential that makes BMII a stock with tremendou= s upside.  

BMII CEO Robert Blagman understands the Inf= omercial sector.  Says Blagman,

"The primary purpose of these reverse mergers was to make= BMII public and create a new BMII, a vehicle with which to build a media-= buying infrastructure.  BMII will streamline operations, combine misc= ellaneous expenses, and create synergies within this larger structure to i= ncrease economies of scale and lower costs-per-eyeball for their clients.&= quot;

In Conclusion

Given its accomplishments and current pl= ans, BMII appears to have great upside potential in the exciting in= fomercial market.  Blagman Media International has demonstrated is ab= ility to capture substantial clients, as evidenced by its impres= sive client base.  The acquisitions of Century Media and Wellworl= d will provide BMII with an even larger client base with plenty of = experience under its wing.   

With an expected = $80-100 million in billings for 2002 and the prospect of additional= mergers, acquisitions, and new ventures, BMII gives investors plenty = to look at given its price of just fractions of a penny per share.<= /font>


To be removed from future mailings, please respond to= this email with "Remove" in the subject line.

DISCLAIMER: <= br> Information within this email contains "forward looking statement= s" within the meaning of Section 27A of the Securities Act of 1933 an= d Section 21B of the Securities Exchange Act of 1934. Any statements that = express or involve discussions with respect to predictions, expectations, = beliefs, plans, projections, objectives, goals, assumptions or future even= ts or performance are not statements of historical fact and may be "f= orward looking statements."

Forward looking statements are b= ased on expectations, estimates and projections at the time the statements= are made that involve a number of risks and uncertainties which coul= d cause actual results or events to differ materially from those presently= anticipated. Forward looking statements in this action may be identified = through the use of words such as "projects", "foresee"= , "expects", "will,"  "anticipates," "estimates,= " "believes," "understands" or that by statements= indicating certain actions "may," "could," or "m= ight" occur.  All information provided within this email pertain= ing to investing, stocks, securities must be understood as information pro= vided and not investment advice. Emerging Growth Stock Alert advises all r= eaders and subscribers to seek advice from a registered professional = securities representative before deciding to trade in stocks featured with= in this email.  None of the material within this report shall be cons= trued as any kind of investment advice.

In compliance with the Se= curities Act of 1933, Section17(b), Emerging Growth Stock Alert discloses = the receipt of eighty million unrestricted shares of BMII from a third par= ty for the publication of this report and additional services related to B= MII. Be aware of an inherent conflict of interest resulting from such comp= ensation as we intend profit from the liquidation of these shares.  P= art or all of these shares may be sold at any given time. All factual= information in this report was gathered from public sources, including bu= t not limited to SEC filings, Company Press Releases, and the company's we= bsite. Emerging Growth Stock= Alert believes this information to be reliable but can make no guarantee = as to its accuracy or completeness. Use of the material within this email = constitutes your acceptance of these terms.



To be removed from future mailings, please= respond to this email with "Remove" in the subject line.

From owner-pilc@grc.nasa.gov Fri Jan 18 10:12:26 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14037 for ; Fri, 18 Jan 2002 10:12:26 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IFCQ811799 for ; Fri, 18 Jan 2002 10:12:26 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA2BaOcx; Fri, 18 Jan 02 10:12:25 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA23110 for pilc-outgoing; Fri, 18 Jan 2002 10:05:18 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA23102 for ; Fri, 18 Jan 2002 10:05:17 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA23455 for ; Fri, 18 Jan 2002 10:05:15 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IF5EL09890 for ; Fri, 18 Jan 2002 10:05:14 -0500 (EST) Message-Id: <200201181505.g0IF5EL09890@seraph2.grc.nasa.gov> Received: from unknown(211.116.140.157) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAR3aGtt; Fri, 18 Jan 02 10:05:13 -0500 Received: (qmail 18924 invoked from network); 18 Jan 2002 14:04:12 -0000 Received: from unknown (HELO pjs) (211.116.140.231) by 211.116.140.157 with SMTP; 18 Jan 2002 14:04:12 -0000 From: DC90 To: pilc@grc.nasa.gov Subject: [광고]BMW 7980원,노트북 2250원, 프라다 숄더백 6500원에 장만하실 수 있습니다 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Reply-To: pjs7353@lycos.co.kr Date: Fri, 18 Jan 2002 23:03:39 +0900 Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id KAA23110 Content-Transfer-Encoding: quoted-printable =C1=A6=B8=F1=BE=F8=C0=BD

DC90.COM !! =BD=C5=B0= =B3=B3=E4=C0=C7 =C0=D4=C2=FB=BD=C4 =BC=EE=C7=CE=B8=F4


BMW 5=BD=C3=B8=AE=C1=EE 530= i

=BD=C3=C1=DF=B0=A1: 79,800,000=BF=F8
=C0=D4=C2=FB=B0=A1: 7,980=BF=F8

=C0=D4= =C2=FB =C2=FC=BF=A9<= /p>

<= /td>

 

=BD=C5=B0=B3=B3=E4=C0=C7 =C0=D4=C2=FB=BD=C4 =BC=EE=C7=CE=B8=F4=C0= =CE dc90.com=C0=CC =BB=F5=B7=D3=B0=D4 =BF=C0=C7=C2=C7=DF=BD=C0=B4=CF=B4=D9.

dc90.com=C0=C7 =C0=D4= =C2=FB=BD=C4 =BC=EE=C7=CE=B8=F4=C0=BA =C8=A5=C0=DA =B1=B8=B8=C5=C7=CF=B1=E2=BF=A3 =BA=CE=B4=E3=BD=BA= =B7=B4=B0=ED =B1=D7=B7=AF=B3=AA =B2=C0 =B0=AE=B0=ED =BD=CD=BE=FA=B4=F8 =BB= =F3=C7=B0=C0=BB =BF=A9=B7=AF= =B8=ED=C0=CC =BA=F1=BF=EB=C0=BB =B3=AA=B4=A9=BE=EE =BA=CE=B4=E3= =C7=D1 =C8=C4, =C7=D1 =BB=E7=B6= =F7=C0=C7 =B3=AB=C2=FB=C0=DA=BF=A1=B0=D4 =B8=F4=BE=C6=C1=D6=B4=C2 =B9=E6=BD=C4=C0=C7 =BD=C5=B0=B3=B3=E4 =BC=EE=C4=AA=B8=F4=C0=D4= =B4=CF=B4=D9.

=C0=D4=C2=FB=BF=A1 =C2= =FC=BF=A9=C7=D1 =C8=C4, =B3=AB=C2=FB=B5=C7=C1=F6 =BE=CA=BE=D2=C0=BB =B0=E6=BF=EC=B4=C2 =BE=EE=B6=BB=C7=CF=B3=C4= =B0=ED=BF=E4?
=B0=C6=C1=A4=B8=B6=BD=CA=BD=C3=BF=E4. dc90.com=C0=BA =BF=A9= =B7=AF=BA=D0=C0=CC =C0=D4=C2=FB=BF=A1 =BB=E7=BF=EB=C7=D1 =BC=D2=C1=DF=C7=D1= =C0=D4=C2=FB=B1=DD=C0=BB =BB=E7=C0=CC=B9=F6=B8=D3=B4=CF=B7=CE =B5=B9=B7=C1=B5=E5=B7=C1=BC=AD dc90.com=BF=A1=BC=AD =BF=EE=BF=B5=C7=CF=B4=C2 =C0=CF=B9=DD=BC=EE=C7=CE=B8=F4=C0=C7 =BB=F3=C7=B0=C0=BB =C0=DA=C0=AF=B7=CE=C0=CC =B1=B8=B8=C5<= /font>=C7=D2 =BC=F6 =C0=D6=B5=B5=B7=CF =C7=CF=BF=B4=BD=C0=B4=CF=B4=D9.

 
 
  <= font color=3D"#C43535">=C0=D4=C2=FB=BF=A1 =C2=FC=BF=A9=C7=CF=B8=E9 =C2=FC=BF=A9=B1=DD=BE=D7=C0=C7 5%=B8=A6 =C0=D4=C2=FB=BF=B9= =C4=A1=B1=DD=C0=B8=B7=CE =BF=B9=C4=A1=C7=D8 =C1=D8=B4=D9=B0=ED!!!
2002=B3=E2 1=BF=F9 31=C0=CF=B1=EE=C1=F6 =C0=D4=C2=FB=BF=A1 =C2= =FC=BF=A9=C7=CF=BD=C3=B4=C2 =BA=D0 =C1=DF =BC=B1= =C2=F8=BC=F8
1,000=BA=D0=B1=EE=C1=F6 =C0=D4=C2=FB=BF=A1 =C2=FC=BF= =A9=C7=D1 =C2=FC=BF=A9=B1=DD=BE=D7=C0=C7 5%=B8=A6 =C0=D4=C2=FB=BF=B9=C4=A1= =B1=DD=C0=B8=B7=CE =BF=B9=C4=A1=C7=D8 =B5=E5=B8=B3=B4=CF=B4=D9.
(=B4=DC, =C0=D4=C2=FB=C0=CC =C3=EB=BC=D2=B5=C7=BE=EE =C0=D4=C2= =FB=BF=B9=C4=A1=B1=DD=C0=B8=B7=CE =C8=AF=BA=D2=C7=D1 =B0=E6=BF=EC=B4=C2 =C1= =A6=BF=DC =C7=D5=B4=CF=B4=D9.)
 
 
 

=C0=D4=C2=FB=BF=A1 =C2=FC=BF=A9= =C7=CF=B8=E9 =B0=E6=C7=B0=C0=CC =BD=F1=BE=C6=C1=F8=B4=D9!!! 2002=B3=E2 1=BF=F9 31=C0=CF=B1=EE=C1=F6 =C0=D4=C2=FB=BF=A1 = =C7=D1=B9=F8=C0=CC=BB=F3 =C2=FC=BF=A9=C7=CF=BD=C5= =C8=B8=BF=F8=BA=D0 =C1=DF =B3=AB=C2=FB=B9=DE=C1=F6
=B8=F8=C7=CF=BD=C5 =C8=B8=BF=F8=B4=D4=B5=E9=B2=B2=B4= =C2 =C3=DF=C3=B7=C0=BB =C5=EB=C7=D8 =C7=AA=C1=FC=C7=D1 =B0=E6=C7=B0=C0=BB= =B5=E5=B8=B3=B4=CF=B4=D9.
(=B4=DC, =C7=D8=B4=E7 =BB=F3=C7=B0=C0=C7 =C0=D4=C2=FB=C0=CC= =C3=EB=BC=D2=B5=C8 =B0=E6=BF=EC=B4=C2 =C1=A6=BF=DC =C7=D5=B4=CF=B4=D9.)<= br>
1=B5=EE 1=B8=ED : =B3=EB=C6=AE=BA=CF[=C8=C4=C1=F6=C2= =EA][PIII 1GHz] C-7631DV
2=B5=EE 2=B8=ED : =BB=EF=BC=BA Syncmaster LCD 175MP =
3=B5=EE 3=B8=ED : OLYMPUS Mu Zoom 140 QD CG
4=B5=EE 4=B8=ED : =C0=D4=C2=FB=BF=B9=C4=A1=B1=DD 20=B8= =B8=BF=F8
5=B5=EE 5=B8=ED : =C0=D4=C2=FB=BF=B9=C4=A1=B1=DD 10=B8= =B8=BF=F8

 
 
  =BC=F6=BC=F6=B7=E1=B0=A1 =B8=E9=C1=A6=B5=CB=B4=CF=B4=D9!!!!
2002=B3=E2 1=BF=F9 31=C0=CF=B1=EE=C1=F6 =C0=D4=C2=FB=BF=A1 =C2= =FC=BF=A9=C7=CF=BD=C3=B4=C2 =BA=D0=B2=B2=B4=C2 =BC=F6=BC=F6=B7=E1=B8=A6 =B0= =F8=C1=A6=C7=CF=C1=F6 =BE=CA=C0=BA
=C0=D4=C2=FB=C2=FC=BF=A9=B1=DD =C0=FC=BE=D7=C0=BB =BB=E7=C0=CC= =B9=F6=C4=B3=BD=AC=B7=CE =C0=FB=B8=B3=C7=CF=BF=A9 =B5=E5=B8=B3=B4=CF=B4=D9.
Copyright =A8=CF= 1998-2001 by DC90. All rights reserved

 

=B4=D9=C0=BD=BA=CE=C5=CD =C8=AB=BA=B8=B8=DE=C0=CF=C0=BB =B9=DE=C1=F6 =BE= =CA=C0=B8=BD=C3=B7=C1=B8=E9 =BF=A9=B1=E2=B8=A6 =B4=AD=B7=AF=C1=D6=BC=BC=BF=E4.

From owner-pilc@grc.nasa.gov Fri Jan 18 10:58:12 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15811 for ; Fri, 18 Jan 2002 10:58:11 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IFwDN19354 for ; Fri, 18 Jan 2002 10:58:13 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA4oaiZL; Fri, 18 Jan 02 10:58:13 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA07250 for pilc-outgoing; Fri, 18 Jan 2002 10:52:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA07236; Fri, 18 Jan 2002 10:52:10 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA02326; Fri, 18 Jan 2002 10:52:09 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IFq9b25871; Fri, 18 Jan 2002 10:52:09 -0500 (EST) Date: Fri, 18 Jan 2002 10:52:09 -0500 (EST) Received: from 28.c210-85-16.ethome.net.tw(210.85.16.28) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAxkaWFY; Fri, 18 Jan 02 10:52:08 -0500 Received: from mail by tpts8.seed.net.tw with SMTP id i8EEr45sB7y5UbsR2TQ15q6QUg; Sat, 19 Jan 2002 00:00:20 +0800 Message-ID: From: wMuGIt9yeZev@tpts8.seed.net.tw To: dxHt5YpbO@pavo.seed.net.tw MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_t75bPXRkhRqbq3Hnf" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-pilc@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_t75bPXRkhRqbq3Hnf Content-Type: multipart/alternative; boundary="----=_NextPart_t75bPXRkhRqbq3HnfAA" ------=_NextPart_t75bPXRkhRqbq3HnfAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJZCIgY29udGVu dD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+t1GmXqj9u1CxoaRIquymuMHb sG2qurT+qP223DwvdGl0bGU+DQo8L2hlYWQ+DQoNCjxib2R5Pg0KDQq3UaZeqP27ULGhpEiq7Ka4 wduwbaq6tP6o/bbcPyCxeqq6qkKkzSC3UbnvsXq7oaFBIHcgDQqn1qjspUikVaq6uvSttqzdrN0g Xl9fX19fX19fX19eIKVWpNGsT63TvkGmWMXKt1Kquql1uGChQSEgDQqkXbdRqNOt0672uqnB27Bt ttyhSCBcKCotKikvIGlWaWRlb7tQp0GqurLEpECmuMHbsG08YnI+DQo8YSBocmVmPSJodHRwOi8v d3d3Lml2aWRlby5jb20udHciPmh0dHA6Ly93d3cuaXZpZGVvLmNvbS50dzwvYT48YnI+DQo8YSBo cmVmPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvcm9tYW5jZS5hc3AiPmh0dHA6Ly93 d3cuaXZpZGVvLmNvbXR3L2ZsYXNoL3JvbWFuY2UuYXNwPC9hPg0KPHA+oUA8L3A+DQo8cD6hQA0K PG9iamVjdCBjbGFzc2lkPSJjbHNpZDpEMjdDREI2RS1BRTZELTExY2YtOTZCOC00NDQ1NTM1NDAw MDAiIGNvZGVCYXNlPSJodHRwOi8vZG93bmxvYWQubWFjcm9tZWRpYS5jb20vcHViL3Nob2Nrd2F2 ZS9jYWJzL2ZsYXNoL3N3Zmxhc2guY2FiI3ZlcnNpb249NCwwLDIsMCIgaGVpZ2h0PSIzMjQiIHdp ZHRoPSI1NTAiPg0KICA8cGFyYW0gTkFNRT0iX2N4IiBWQUxVRT0iMTQ1NTIiPg0KICA8cGFyYW0g TkFNRT0iX2N5IiBWQUxVRT0iODU3MyI+DQogIDxwYXJhbSBOQU1FPSJNb3ZpZSIgVkFMVUU9Imh0 dHA6Ly93d3cuaXZpZGVvLmNvbS50dy9mbGFzaC91bmNsZS5zd2YiPg0KICA8cGFyYW0gTkFNRT0i U3JjIiBWQUxVRT0iaHR0cDovL3d3dy5pdmlkZW8uY29tLnR3L2ZsYXNoL3VuY2xlLnN3ZiI+DQog IDxwYXJhbSBOQU1FPSJXTW9kZSIgVkFMVUU9IldpbmRvdyI+DQogIDxwYXJhbSBOQU1FPSJQbGF5 IiBWQUxVRT0iLTEiPg0KICA8cGFyYW0gTkFNRT0iTG9vcCIgVkFMVUU9Ii0xIj4NCiAgPHBhcmFt IE5BTUU9IlF1YWxpdHkiIFZBTFVFPSJIaWdoIj4NCiAgPHBhcmFtIE5BTUU9IlNBbGlnbiIgVkFM VUU+DQogIDxwYXJhbSBOQU1FPSJNZW51IiBWQUxVRT0iLTEiPg0KICA8cGFyYW0gTkFNRT0iQmFz ZSIgVkFMVUU+DQogIDxwYXJhbSBOQU1FPSJTY2FsZSIgVkFMVUU9IlNob3dBbGwiPg0KICA8cGFy YW0gTkFNRT0iRGV2aWNlRm9udCIgVkFMVUU9IjAiPg0KICA8cGFyYW0gTkFNRT0iRW1iZWRNb3Zp ZSIgVkFMVUU9IjAiPg0KICA8cGFyYW0gTkFNRT0iQkdDb2xvciIgVkFMVUU+DQogIDxwYXJhbSBO QU1FPSJTV1JlbW90ZSIgVkFMVUU+DQogIDxwYXJhbSBOQU1FPSJTdGFja2luZyIgVkFMVUU9ImJl bG93Ij48ZW1iZWQgc3JjPSJodHRwOi8vd3d3Lml2aWRlby5jb20udHcvZmxhc2gvdW5jbGUuc3dm IiBxdWFsaXR5PSJoaWdoIiBwbHVnaW5zcGFnZT0iaHR0cDovL3d3dy5tYWNyb21lZGlhLmNvbS9z aG9ja3dhdmUvZG93bmxvYWQvaW5kZXguY2dpP1AxX1Byb2RfVmVyc2lvbj1TaG9ja3dhdmVGbGFz aCIgdHlwZT0iYXBwbGljYXRpb24veC1zaG9ja3dhdmUtZmxhc2giIHdpZHRoPSI1NTAiIGhlaWdo dD0iMzI0Ij4NCjwvb2JqZWN0Pg0KPC9wPg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4= ------=_NextPart_t75bPXRkhRqbq3HnfAA ------=_NextPart_t75bPXRkhRqbq3HnfAA-- ------=_NextPart_t75bPXRkhRqbq3HnfAA-- ------=_NextPart_t75bPXRkhRqbq3Hnf-- From owner-pilc@grc.nasa.gov Fri Jan 18 12:42:30 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20343 for ; Fri, 18 Jan 2002 12:42:30 -0500 (EST) Received: (from uucp@localhost) by seraph3.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IHgVC14048 for ; Fri, 18 Jan 2002 12:42:31 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph3.grc.nasa.gov via csmap (V6.0) id srcAAAB_a4BB; Fri, 18 Jan 02 12:42:31 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA06516 for pilc-outgoing; Fri, 18 Jan 2002 12:36:40 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA06506; Fri, 18 Jan 2002 12:36:38 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA19017; Fri, 18 Jan 2002 12:36:37 -0500 (EST) Received: (from uucp@localhost) by seraph2.grc.nasa.gov (8.10.2+Sun/8.10.2) id g0IHaa504654; Fri, 18 Jan 2002 12:36:36 -0500 (EST) Received: from customer-148-223-7-67.uninet.net.mx(148.223.7.67) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAhEaafj; Fri, 18 Jan 02 12:36:36 -0500 Received: from mail.cyberaccess.com.pk ([63.27.139.54]) by customers.nextmail.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 18 Jan 2002 09:57:51 -0600 Message-ID: <000038f72882$000008cf$00004c8e@mail8.burlee.Com> To: From: "szdn40a0mw_c@wol.net.pk" Subject: Bright Teeth- NOW9002 Date: Fri, 18 Jan 2002 09:53:55 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 18 Jan 2002 15:57:52.0375 (UTC) FILETIME=[E29EB870:01C1A038] Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable
 
Home

Get Your Teeth Bright White Now!

Have you considered professional teeth whitening? If so, you know it usually = costs between $300 and $500 from your local dentist!

Visit our site to learn how to professionally whiten your teeth, using the exact same whitening sys= tem your dentist uses, at a fraction of the cost!

Here's what you get:

  • We will show you what to look for in a whitening system!
  • We will show you a comparison of all of the products available today,= including their costs!
  • We know our product is the best on the market, and we back it with a = 30 day money back guarantee!

Click here to learn= more!

From owner-pilc@grc.nasa.gov Mon Jan 21 11:29:00 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15620 for ; Mon, 21 Jan 2002 11:28:59 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1B0EDC6935 for ; Mon, 21 Jan 2002 11:29:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA09644 for pilc-outgoing; Mon, 21 Jan 2002 11:17:57 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA09639 for ; Mon, 21 Jan 2002 11:17:56 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA22404 for ; Mon, 21 Jan 2002 11:17:57 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id BA30BC68D4 for ; Mon, 21 Jan 2002 11:17:56 -0500 (EST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0LGHVIB028082; Mon, 21 Jan 2002 17:17:31 +0100 (MET) Received: from res0010384da36.ericsson.com (dhcp5-66 [164.48.135.66]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id RAA12902; Mon, 21 Jan 2002 17:17:30 +0100 (MET) Message-Id: <5.1.0.14.0.20020121165922.02c3f6f0@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 21 Jan 2002 17:18:26 +0100 To: "Farid Khafizov" From: Reiner Ludwig Subject: Re: 2.5g/3g ID additions (RE: pilc minutes (corrected)) Cc: "'pilc@grc.nasa.gov'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@grc.nasa.gov Precedence: bulk Hi Farid, thanks for your text. In general, I think it looks pretty OK. However, there is one major comment I have ... At 00:29 18.01.2002, Farid Khafizov wrote: >2. Bandwidth Oscillation >Limited RF spectrum along with high data rate requirement for 2.5G/3G >wireless systems necessitate dynamic resource sharing among concurrent >data users. Various scheduling mechanisms can be deployed in order to >maximize resource utilization. Some of the limited resources in CDMA based >systems (e.g., UMTS, CDMA2000) are orthogonal codes and RF transmit power. >Shared channels in UMTS [N1] and supplemental channels in CDMA2000 [N2], [....] This text suggests that bandwidth oscillation is also a characteristic of WCDMA/UMTS. This is *not* the case! The reason for this problem in CDMA2000 seems to be the use of the finite burst mode which limits the access to the high speed supplemental channel to 14 time units. In WCDMA/UMTS we have no such mechanism. Yes, bandwidth can also oscillate in WCDMA/UMTS, *but* on the scale of some tens of milliseconds. This is certainly not a problem for TCP. The closest thing to bandwidth oscillation I can imagine in WCDMA/UMTS would be a periodic switch between a high speed dedicated and the common channel. However, I don't think any manufacturer or operator plans to do this (it will result in a very unstable system). So, please, remove the reference to WCDMA/UMTS from your text. ///Reiner From owner-pilc@grc.nasa.gov Mon Jan 21 17:51:06 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27337 for ; Mon, 21 Jan 2002 17:51:05 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 8E454C6939 for ; Mon, 21 Jan 2002 17:51:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA24933 for pilc-outgoing; Mon, 21 Jan 2002 17:46:12 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA24929 for ; Mon, 21 Jan 2002 17:46:11 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id RAA07751 for ; Mon, 21 Jan 2002 17:46:12 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 09DB8C68F3 for ; Mon, 21 Jan 2002 17:46:12 -0500 (EST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LMkAw01074; Mon, 21 Jan 2002 23:46:10 +0100 (MET) Received: from res0010384da36.ericsson.com (rac184pc.edd.ericsson.se [164.48.123.184]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id XAA29941; Mon, 21 Jan 2002 23:46:07 +0100 (MET) Message-Id: <5.1.0.14.0.20020121213641.01a83af8@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 21 Jan 2002 22:33:33 +0100 To: Kacheong Poon From: Reiner Ludwig Subject: TCP's RTO & RTT-Spikes [was Re: large RTT variation caused by bandwidth oscillation] Cc: pilc@grc.nasa.gov In-Reply-To: References: <"Your message with ID" <00ea01c183f7$f8834dc0$24c9830c@ietfslc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@grc.nasa.gov Precedence: bulk Hi Kacheong, I'm slowly working through my e-mail backlog ... At 04:16 09.01.2002, Kacheong Poon wrote: >There is one comment specifically saying that Solaris does not >comply with Section 5, rule 5.3. It is correct, Solaris does >not implement the part of restarting timer in rule 5.3. The timer >is restarted when a fast retransmit happens or during the fast >recovery phase when missing segments are retransmitted. > >Rule 5.3 simply says that the RTO calculation is not good enough so >that implementations should add a little fudge factor to it. For >example, if 2 segments are sent and the receiver does not delay >ack'ing. The second segment is dropped. After the ACK for the >first segment arrives, rule 5.3 suggests that the timer should >be restarted. This means that the actual timeout value for the >second segment is RTO+RTT. The arrival of first data segment >correlates weakly, if there is any correlation, to the fate of the >next segment. This point has been mentioned by a lot of other people. I thought the same for quite a while but our recent research showed that rule 5.3 in RFC2988 is often an important (although fairly imprecise) safeguard. Imagine the case of a bandwidth dominated link where, e.g., the packet transmission delay across the bottleneck link dominates the RTT. This is typical for paths across wide-area wireless access. When the queue starts to build up at the bottleneck link, the RTT will increase significantly. Thus, when the RTT for packet N has increased significantly compared to SRTT, chances are that the RTT for packet N+1 will also be increased. Rule 5.3 implicitly factors this in. We found that this often saves you from a spurious timeout, because the SRTT and RTTVAR are often not sensitive enough to account for such RTT spikes (due to the gains 1/4 and 1/8). [Side note: This example also argues in favor of timing every segment across bandwidth dominated paths. This is because an inreasing RTT is sooner reflected in an increased RTO. Problem: How does the sender know that it is running across a bandwidth dominated path?] See also section 3.3 in our paper in CCR Vol. 30 No. 3, July 2000. At that time, we thought it would be better to change rule 5.3 as follows: (1) REXMT = RTO - 'age of oldest outstanding segment'; When timing every packet, we also changed the gains (1/4 for SRTT, and 1/8 for RTTVAR) to the single factor 1/(4 x flightsize). This is to avoid that the estimators (SRTT and RTTVAR) lose their memory too quick. With that change in place, we made the estimators even less sensitive to RTT spikes. The effect was that when an RTT spike occured, 'age of oldest outstanding segment' became very large, and REXMT became very low (often too low) to due rule (1). To solve that our current RTO looks like this: (2) RTO = MAX(SRTT, RTT) + MAX((K x RTTVAR), (2 x G)); with RTTVAR defined as given in the mentioned CCR paper. When timing every packet, we chose K = 2, and find pretty good timer performance. >[...] The current TCP RTO algorithm is not designed to >handle this kind of wireless environment. And we all know that the >current assumption of the RTO calculation is that the round trip route >does not change much. So it seems to me that we may need a better way >to deal with this in the RTO calculation. I doubt that we will find an RTO that will work fine under all conditions. Instead, I agree with Mark Allman that an RTO should be "reset" to be more conservative "for a while" after a spurious timeout has been detected. This is the link to the Eifel algorithm (which at this point is a pure detection scheme) and a corresponding response algorithm (revert CC state & adapt RTO). >I have another minor comment about what actually happens after a timeout. >I believe all modern TCP implementations will not have the false fast >retransmit after timeout problem mentioned in this thread. I'm not quite sure what you mean. Please explain this. ///Reiner From owner-pilc@grc.nasa.gov Tue Jan 22 03:46:39 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13902 for ; Tue, 22 Jan 2002 03:46:39 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 722FB640CA for ; Tue, 22 Jan 2002 03:46:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA22415 for pilc-outgoing; Tue, 22 Jan 2002 03:41:33 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA22411 for ; Tue, 22 Jan 2002 03:41:32 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id DAA18772 for ; Tue, 22 Jan 2002 03:41:33 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id BCBBBC6905 for ; Tue, 22 Jan 2002 03:41:32 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1346 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Tue, 22 Jan 2002 10:41:27 +0200 Message-ID: <004401c1a320$9322d8e0$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: Subject: text on use of timestamps for 2.5g3g draft Date: Tue, 22 Jan 2002 09:47:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Please find below our joint text with Reiner on use of timestamps in 2.5g3g draft. Andrei 3.1.7. TCP timestamp option. Traditionally, TCPs collect one RTT sample per window of data [38]. This can lead to an underestimation of the RTT, and spurious timeouts on bandwidth-dominated paths. This holds despite a conservative retransmit timer such as the one proposed in RFC2988 [32]. In general, TCP connections with a window larger than eight segments require more frequent RTT measurements [S95]. Timing every segment can be implemented with or without the TCP Timestamps option [5]. Using the TCP Timestamps option has the advantage that retransmitted segments can be used for RTT measurement, which is otherwise forbidden by Karn's algorithm [KP87]. Furthermore, the TCP Timestamps option is the basis for detecting spurious retransmits using the Eifel algorithm [17]. On paths where the packet transmission delay across the bottleneck link dominates the path's RTT, the queuing delay and hence the RTT can increase rapidly during the slow start phase. When RTT samples are collected once per window, the RTO value applied just before taking a new RTT sample can underestimate the current RTT. Experiments using NS2 show that in this case a spurious timeout during fast recovery can occur even without any delay spike [GU01]. Enabling timestamps significantly increases the maximum delay spike tolerated by TCP without experiencing a spurious timeout. In summary, timing every segment avoids the effect of an RTO lagging behind a rapidly increasing RTT. This decreases the likelihood of a spurious timeout. Additionally, timestamps reduce the likelihood of spurious timeouts due to bandwidth oscillation [cdma2000]. The only problematic issue about using timestamp seems to be the 12 bytes overhead introduced by carrying the TCP Timestamps option and padding in the TCP header. For a small MTU size, it can present a considerable overhead. For example, for an MTU of 296 bytes the added overhead is 4 %. For an MTU of 1500 bytes, the added overhead is only 0.8 %. TCP/IP header compression [RFC1144] does not support compressing headers with options. Thus, using the TCP Timestamps option effectively disables it. However, in many cases TCP/IP header compression is not used anyway due to poor performance in presence of packet losses [LU99]. The IETF is currently specifying a robust TCP/IP header compression scheme that supports TCP options [16,34]. The original specification of the timestamp option [5] may contain some flaws. An update specification [B93] provides the necessary fixes. Ideas in this expired draft appear in all current implementations of [5]. Recommendation: TCP SHOULD use the TCP Timestamps option. It allows better RTT estimation, reduces the risk of spurious timeouts, and enables the detection of spurious retransmits using the Eifel algorithm. References [cdma2000] F. Khafizov, M. Yavuz, TCP over CDMA2000 networks, draft-khafizov-pilc-cdma2000-00.txt [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates in Reliable Transport Protocols, In Proceedings of ACM SIGCOMM 87. [LU99] R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, and A. Joseph. Multi-layer tracing of TCP over a reliable wireless link. In Proceedings of the ACM SIGMETRICS, May 1999. [GU01] A. Gurtov, Making TCP Robust Against Delay Spikes, University of Helsinki, Department of Computer Science, Series of Publications C, No C-2001-53, November 2001. Available at http://www.cs.helsinki.fi/u/gurtov/papers/report01.html [RFC1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, RFC1144, February 1990. [S95] W. Stevens, TCP/IP Illustrated, Volume 1; The Protocols, Addison Wesley, 1995. [B93] R. T. Braden, TCP Extensions for High Performance: An Update, Internet Draft, June 1993. http://www.kohala.com/start/tcplw-extensions.txt From owner-pilc@grc.nasa.gov Tue Jan 22 15:54:24 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09963 for ; Tue, 22 Jan 2002 15:54:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 22870640D7 for ; Tue, 22 Jan 2002 15:54:21 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA16613 for pilc-outgoing; Tue, 22 Jan 2002 15:46:23 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA16576 for ; Tue, 22 Jan 2002 15:46:21 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA15610 for ; Tue, 22 Jan 2002 15:46:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C7994C693F for ; Tue, 22 Jan 2002 15:46:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02576; Tue, 22 Jan 2002 13:46:19 -0700 (MST) Received: from shield (shield.SFBay.Sun.COM [129.150.113.84]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA22054; Tue, 22 Jan 2002 12:46:18 -0800 (PST) Date: Tue, 22 Jan 2002 12:45:31 -0800 (PST) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: TCP's RTO & RTT-Spikes [was Re: large RTT variation caused by bandwidth oscillation] To: Reiner Ludwig Cc: pilc@grc.nasa.gov In-Reply-To: "Your message with ID" <5.1.0.14.0.20020121213641.01a83af8@mailhost.eed.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-pilc@grc.nasa.gov Precedence: bulk > Imagine the case of a bandwidth dominated link where, e.g., the packet > transmission delay across the bottleneck link dominates the RTT. This is > typical for paths across wide-area wireless access. When the queue starts > to build up at the bottleneck link, the RTT will increase significantly. > Thus, when the RTT for packet N has increased significantly compared to > SRTT, chances are that the RTT for packet N+1 will also be increased. Rule > 5.3 implicitly factors this in. We found that this often saves you from a > spurious timeout, because the SRTT and RTTVAR are often not sensitive > enough to account for such RTT spikes (due to the gains 1/4 and 1/8). > > [Side note: This example also argues in favor of timing every segment > across bandwidth dominated paths. This is because an inreasing RTT is > sooner reflected in an increased RTO. Problem: How does the sender know > that it is running across a bandwidth dominated path?] I can see your reason for timing every segment because of the queue building up. But it still seems to be a hack for restarting the timer. It just tells us that the timer is not good enough. What does an ACK for segment N tell TCP about the fate of segment N+1? If the timer is not good enough, there are other "hacks" to deal with it, I guess. Restarting the timer hack is not neccessarily the best one. > I doubt that we will find an RTO that will work fine under all conditions. > Instead, I agree with Mark Allman that an RTO should be "reset" to be more > conservative "for a while" after a spurious timeout has been detected. This > is the link to the Eifel algorithm (which at this point is a pure detection > scheme) and a corresponding response algorithm (revert CC state & adapt RTO). This is why I asked the question whether TCP should have more than one RTO algorithm. I believe everyone spoken so far agrees that it is probably not possible to have an RTO algorithm to work good in all situations. But there is only one right now specified in a standard RFC and everyone has to use it. We know that it does not work well in some network environments. If people know about this, they can switch to another one which is good for their situations. One question is how many such algorithms is enough? And should a TCP stack allow a user or sys admin to specify a user defined algorithm? There are many other issues. That's why I hope people can give their comments. > >I have another minor comment about what actually happens after a timeout. > >I believe all modern TCP implementations will not have the false fast > >retransmit after timeout problem mentioned in this thread. > > I'm not quite sure what you mean. Please explain this. It was suggested that the go-back-N behavior of TCP after a spurious timeout can trigger false fast retransmit due to those dup ACKS. I was saying that it was not true for all modern TCP impls. K. Poon. kacheong.poon@sun.com From owner-pilc@grc.nasa.gov Wed Jan 23 11:49:10 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15917 for ; Wed, 23 Jan 2002 11:49:09 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 5F654640EA for ; Wed, 23 Jan 2002 11:44:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA22400 for pilc-outgoing; Wed, 23 Jan 2002 11:38:56 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA22396 for ; Wed, 23 Jan 2002 11:38:55 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA25757 for ; Wed, 23 Jan 2002 11:38:54 -0500 (EST) Received: from linuxpow.com (linuxpow.com [12.149.2.10]) by seraph3.grc.nasa.gov (Postfix) with SMTP id 088F6640A2 for ; Wed, 23 Jan 2002 11:38:54 -0500 (EST) Received: (qmail 29818 invoked from network); 23 Jan 2002 16:21:28 -0000 Received: from buystainlessonline.com (HELO ) (nobody@12.149.2.55) by mail.buystainlessonline.com with SMTP; 23 Jan 2002 16:21:28 -0000 Subject: The Stainless Steel Network To: pilc@grc.nasa.gov From: "BuyStainlessOnline.com" Message-Id: <20020123163854.088F6640A2@seraph3.grc.nasa.gov> Date: Wed, 23 Jan 2002 11:38:54 -0500 (EST) Sender: owner-pilc@grc.nasa.gov Precedence: bulk The Stainless Steel Network is brought to you by www.buystainlessonline.com MARKET PULSE After attending an AWMI meeting last thursday evening, and gauging the current market conditions against last years poor performance, it is my professional opinion that markets are shifting. We have seen an increase of sales activity since Jan. 1st. Look for higher prices and thinning stocks for stainless. Mason Fine President BuyStainlessOnline, Inc. ------------------------------------------------- Stainless Deals (FOB Anywhere USA) PRIME with Mill Test Reports 375,000 pound Min. Order all items below 11ga 304 48 x 120 |price| $.55.lb 1/4 304 48 x 144 |price| $.58.lb ------------------------------------------------- www.BuyStainlessOnline.com Your Place for Stainless Today. P 215.604.5922 F 240.358.8483 Click Here to REGISTER! https://www.buystainlessonline.com/registration/registration.php Unsubscribe By clicking below: http://www.buystainlessonline.com/email/mail.php?action=delete&eval=51888&email=pilc@grc.nasa.gov From owner-pilc@grc.nasa.gov Wed Jan 23 22:46:28 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04655 for ; Wed, 23 Jan 2002 22:46:28 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 940F764104 for ; Wed, 23 Jan 2002 22:46:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA00405 for pilc-outgoing; Wed, 23 Jan 2002 22:37:34 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA00401 for ; Wed, 23 Jan 2002 22:37:33 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id WAA01099 for ; Wed, 23 Jan 2002 22:37:32 -0500 (EST) Received: from ns (unknown [61.73.80.220]) by seraph2.grc.nasa.gov (Postfix) with SMTP id 33289C68DA for ; Wed, 23 Jan 2002 22:37:27 -0500 (EST) x-esmtp: 0 0 1 Message-ID: <6334200214243162560@group.com> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 To: "1" From: "gro" Subject: 요청하신 목록입니다 Date: Thu, 24 Jan 2002 12:16:02 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC2B74.89D1CCC0" X-SMTPExp-Version: 1, 0, 2, 11 X-SMTPExp-Registration: 00B0320C107602006905 Sender: owner-pilc@grc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01BC2B74.89D1CCC0 Content-type: text/plain; charset="iso-2022-kr" Content-Transfer-Encoding: quoted-printable =C4=C4=C7=BB=C5=CD=B8=A6 =C0=CC=BF=EB=C7=CF=BD=C3=B4=C2=B5=A5 =C7=CA=BF=E4= =C7=D1 =C4=C4=C7=BB=C5=CD =B0=FC=B7=C3=C7=C1=B7=CE=B1=D7=B7=A5=C0=BB =BE=F6=C3=BB =C0=FA=B7=C5=C7=D1 =B0=A1=B0=DD=BF=A1 =C6=CB=B4=CF=B4=D9 =C3=D6=BD=C5=C7=AE=B9=F6=C0=FC=B0=D4=C0=D3=2E =C4=C4=C7=BB=C5=CD=C0=AF=C6=BF= =C7=C1=B7=CE=B1=D7=B7=A5=2E =BC=BA=C0=CE=BD=C3=B5=F0 =B5=EE=B5=EE =BE=F8=B4=C2=B0=D4 =BE=F8=BD=C0=B4=CF=B4=D9 =B9=B0=B7=D0 =BD=C5=BF=EB=C0=BA =B1=E2=BA=BB=C0=D4=B4=CF=B4=D9 =C0=CC =B8=DE=C0=CF=C0=BB =BA=B8=B3=BD =BE=C6=C0=CC=B5=F0=B7=CE=B4=C2 =BF=AC= =B6=F4=C0=CC =B5=C7=C1=F6 =BE=CA=BD=C0=B4=CF=B4=D9=2E =BE=D0=C3=E0=C8=AD=C0=CF=BC=D3=BF=A1 =BF=AC=B6=F4=C3=B3=B0=A1 =C0=D6=BD=C0= =B4=CF=B4=D9(=C0=FC=C8=AD=B9=F8=C8=A3)=20 =C7=DA=B5=E5=C6=F9=C0=B8=B7=CE =BF=AC=B6=F4=C1=D6=BD=CA=BD=C3=BF=E4 =B3=A1=C0=B8=B7=CE =C7=E3=B6=F4=BE=F8=C0=CC =B8=DE=C0=CF=C0=BB =B5=E5=B8=B0= =B0=CD=C0=BB =BB=E7=B0=FA=B5=E5=B8=B3=B4=CF=B4=D9=2E=B1=D7=B8=AE=B0=ED =BF= =A9=B7=AF=BA=D0=C0=C7 =B8=DE=C0=CF=C1=D6=BC=D2=B4=C2 =B9=AB=C0=DB=C0=A7=B7=CE =B8=F0=BE=C6=C1=F8=B0=CD=C0=CC=B4=CF =BA=B0=B4=D9= =B8=A5 =B0=C6=C1=A4=C0=BA =C7=CF=C1=F6 =BE=CA=C0=B8=BC=C5=B5=B5 =B5=CB=B4=CF= =B4=D9=2E =20 =B9=D8=C0=C7 =B1=DB=BF=A1=BC=AD =B8=F1=B7=CF=C0=BB =B4=D9=BF=EE=B9=DE=C0=B8= =BD=C7=BC=F6 =C0=D6=BD=C0=B4=CF=B4=D9 =B9=D8=BF=A1 =B1=DB=C0=CC =BA=B8=C0=CC=C1=F6 =BE=CA=C0=B8=BD=C3=B8=E9 =C3=B7= =BA=CE=B5=C8 =C8=AD=C0=CF cd=2Ehtm =C0=BB =BF=A9=BD=C3=B0=ED =B4=D9=BF=EE=B9= =DE=C0=B8=BD=C3=B8=E9 =B5=CB=B4=CF=B4=D9 =20 =BA=B8=B3=CA=BD=BA=BD=C3=B5=F0=B8=A6 =B5=E5=B8=AE=B0=ED =C0=D6=BD=C0=B4=CF= =B4=D9 =B0=ED=B8=BF=BD=C0=B4=CF=B4=D9 ------=_NextPart_000_01BC2B74.89D1CCC0 Content-Type: text/html; name="Cd.htm" Content-Description: Cd.htm Content-Disposition: attachment; filename="Cd.htm" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT7AzLD3wLogwaa48cDUtM+02TwvVElUTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBCR0NPTE9SPSNGRkY4REM+DQrExMe7xc24piDAzL/rx8+9w7TCtaUgssAgx8q/5MfR IMTEx7vFzSCw/LfDx8G3zrHXt6XAuzxCUj4NCr72w7sgwPq3xcfRILChsN2/oSDGy7TPtNk8QlI+ DQo8UD4NCjxGT05UIENPTE9SPUJMVUU+w9a9xceuufbA/LDUwNMuIMTEx7vFzbD8t8PHwbfOsde3 pS4gILy6wM69w7XwILXute48QlI+DQrExMe7xc2/oSCw/LfDtcgguPC1573DtfCwoSDA1r3AtM+0 2TwvRk9OVD48QlI+DQo8UD4NCsPWvcW48bfPwNS0z7TZPEJSPg0KubC30CC9xb/rwLogseK6u8DU tM+02TxCUj4NCr7Qw+DIrcDPvNPAxyCzu7/rwLsguri9xcjEIMD8yK2zqiC43sDPt84gv6y29MHW vcq9w7/kPEJSPg0KwMwguN7Az8C7ILq4s70gvsbAzLXwt860wiC/rLb0wMwgtcfB9iC+yr3AtM+0 2S48QlI+DQq+0MPgyK3Az7zTv6Egv6y29MOzsKEgwNa9wLTPtNkouN7Azy7A/MitufjIoyk8QlI+ IA0KPHA+DQoNCsjetOvG+cC4t84gv6y29MHWvcq9w7/kPEJSPg0KsKi758fVtM+02TxCUj4NCjxQ Pg0Ks6HAuLfOIMfjtvS++MDMILjewM/AuyC15biwsM3AuyC757D6teW4s7TPtNkusde4rrDtIL+p t6+60MDHILjewM/B1rzStMI8QlI+DQq5q8DbwKe3ziC48L7GwfiwzcDMtM8gtNm4pSCwxsGkwLog x8/B9iC+ysC4vMW1tSC1y7TPtNkuPEJSPiAgDQo8UD4NCjxGT05UIENPTE9SPUJMVUU+PFU+uPG3 z8C7ILTZv+653sC4vcO3wbjpPC9VPjwvRk9OVD4gPEEgSFJFRj1odHRwOi8vaG9tZXdpei50cmlw b2QubHljb3MuY28ua3IvYm9hcmQvZG93bmxvYWQucGhwMz9wX2lkPWtsa2xrbDk2Mz48Rk9OVCBT SVpFPTk+wMyw9zwvRk9OVD48L0E+wLsgxay4r8fPvcXIxDxCUj4NCjxmb250IGNvbG9yPTAwZmYw MCBzaXplPTU+Y2QuemlwPC9mb250PiC4piC02b/uud7AuL3DuOkgtcu0z7TZPGJyPg0KPHA+DQq4 uMDPIDxmb250IGNvbG9yPWdyZWVuPk91dGxvb2sgRXhwcmVzcyCzqiC02bilILjewM/HwbfOsde3 pcC7PC9mb250Prvnv+vHz73DtMIgutDB37+hILiuvbrGrrChIMGmtOu3ziC02b/uwMwgtcfB9iC+ yrTCtNm46Txicj4NCsO3us61yCDIrcDPIDx1PmNkLmh0bTwvdT4gwLsgv62w7SC02b/uud7AuL3D uOkgtcu0z7TZPGJyPg0KPHA+DQq9xcO7t66/oSC1+7bzIMPfsKG9w7XwuKYguau34bfOILXluK6w 7SDA1r3AtM+02Txicj4NCjwvQk9EWT4NCjwvSFRNTD4= ------=_NextPart_000_01BC2B74.89D1CCC0-- From owner-pilc@grc.nasa.gov Thu Jan 24 10:48:21 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24243 for ; Thu, 24 Jan 2002 10:48:21 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id E87C46411F for ; Thu, 24 Jan 2002 10:48:06 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA14822 for pilc-outgoing; Thu, 24 Jan 2002 10:41:31 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA14813 for ; Thu, 24 Jan 2002 10:41:29 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA07680 for ; Thu, 24 Jan 2002 10:41:29 -0500 (EST) Received: from excore1.hns.com (unknown [139.85.52.104]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id F004A640E3 for ; Thu, 24 Jan 2002 10:41:27 -0500 (EST) Received: from hns.com (SPERIPC-1.md.hns.com [139.85.102.238]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0OFfRZ27024 for ; Thu, 24 Jan 2002 10:41:27 -0500 (EST) Message-ID: <3C502B21.63029332@hns.com> Date: Thu, 24 Jan 2002 10:41:21 -0500 From: Surekha Peri Organization: Hughes Network Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pilc@grc.nasa.gov Subject: Header stripping vs Header Compression Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I want to know where I can find the information regarding why Header stripping was dropped in favour of ROHC in 3GPP. It would be great if anybody could point to any relevant links or give me some explanation. Thanks, Surekha. From owner-pilc@grc.nasa.gov Thu Jan 24 11:04:12 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24957 for ; Thu, 24 Jan 2002 11:04:12 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4B6B6640DE for ; Thu, 24 Jan 2002 11:04:15 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA20665 for pilc-outgoing; Thu, 24 Jan 2002 11:00:26 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA20657 for ; Thu, 24 Jan 2002 11:00:25 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA11095 for ; Thu, 24 Jan 2002 11:00:25 -0500 (EST) Received: from web11702.mail.yahoo.com (web11702.mail.yahoo.com [216.136.172.68]) by seraph2.grc.nasa.gov (Postfix) with SMTP id 76159C6954 for ; Thu, 24 Jan 2002 11:00:24 -0500 (EST) Message-ID: <20020124160020.37926.qmail@web11702.mail.yahoo.com> Received: from [143.209.230.141] by web11702.mail.yahoo.com via HTTP; Thu, 24 Jan 2002 08:00:20 PST Date: Thu, 24 Jan 2002 08:00:20 -0800 (PST) From: Behcet Sarikaya Subject: Fwd: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc minutes (corrected)) To: pilc@grc.nasa.gov Cc: francois.courau@alcatel.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pilc@grc.nasa.gov Precedence: bulk Dear all, I am forwarding the opinion of Francois Courau from Alcatel France (who is the head of 3GPP RAN WG) on this issue. I wish we could get another expert opinion of someone from Lucent or Qualcomm on the situation in CDMA2000. I am afraid if we include Farid's text only for CDMA2000 this will cause problems as to the inferiority of CDMA2000 vis-a-vis UMTS. Regards, --behcet --- Francois.Courau@alcatel.fr wrote: > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > minutes (corrected)) > To: Behcet Sarikaya > From: Francois.Courau@alcatel.fr > Date: Thu, 24 Jan 2002 11:18:44 +0100 > > > I fully share the analysis proposed by Ericsson. The > oscillation will be > linked with the reduction of throughpur decided > uponn by the radio access > network in the other cases we don't have a similar > problem to CDMA 2000. > > Francois > __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-pilc@grc.nasa.gov Thu Jan 24 11:25:35 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25920 for ; Thu, 24 Jan 2002 11:25:34 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id C0252C69E7 for ; Thu, 24 Jan 2002 11:24:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA29264 for pilc-outgoing; Thu, 24 Jan 2002 11:20:37 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA29256 for ; Thu, 24 Jan 2002 11:20:36 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA15392 for ; Thu, 24 Jan 2002 11:20:35 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 1F8C7C6952 for ; Thu, 24 Jan 2002 11:20:34 -0500 (EST) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0OGKS801915; Thu, 24 Jan 2002 11:20:29 -0500 (EST) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA09300; Thu, 24 Jan 2002 11:20:03 -0500 Message-ID: <3C50342D.282D1102@lucent.com> Date: Thu, 24 Jan 2002 11:19:57 -0500 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya Cc: pilc@grc.nasa.gov, francois.courau@alcatel.fr Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) References: <20020124160020.37926.qmail@web11702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure why the CDMA2000 ID was even considered seriously. It is standard problem that needs to be addressed carefully at the MAC layer. I am surprised folks actually went up to writing something like this and blaming it on CDMA2000 in a way! Standards define the basic MAC protocol. It is upto the Vendors to design "algorithms" for resource allocation. What happened to Phil Karn's and Gorry's comments which were raised very early after the initial draft was sent out? Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such problems to arise if someone used Downlink Shared Channel (DSCH) in UMTS in a random manner..ofcourse dedicated channels (DCH) help. I hope others in the mailing list raise their voice too! Thanks Behcet! Kamesh Behcet Sarikaya wrote: > > Dear all, > I am forwarding the opinion of Francois Courau from > Alcatel France (who is the head of 3GPP RAN WG) on > this issue. > I wish we could get another expert opinion of > someone from Lucent or Qualcomm on the situation in > CDMA2000. I am afraid if we include Farid's text only > for CDMA2000 this will cause problems as to the > inferiority of CDMA2000 vis-a-vis UMTS. > > Regards, > > --behcet > > --- Francois.Courau@alcatel.fr wrote: > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > > minutes (corrected)) > > To: Behcet Sarikaya > > From: Francois.Courau@alcatel.fr > > Date: Thu, 24 Jan 2002 11:18:44 +0100 > > > > > > I fully share the analysis proposed by Ericsson. The > > oscillation will be > > linked with the reduction of throughpur decided > > uponn by the radio access > > network in the other cases we don't have a similar > > problem to CDMA 2000. > > > > Francois > > > > __________________________________________________ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com From owner-pilc@grc.nasa.gov Fri Jan 25 00:27:41 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16829 for ; Fri, 25 Jan 2002 00:27:41 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BCF1264120 for ; Fri, 25 Jan 2002 00:25:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA26779 for pilc-outgoing; Fri, 25 Jan 2002 00:19:15 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA26771 for ; Fri, 25 Jan 2002 00:19:14 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id AAA08980 for ; Fri, 25 Jan 2002 00:19:13 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id EFB08640D6 for ; Fri, 25 Jan 2002 00:19:11 -0500 (EST) Received: from eed.ericsson.se (mailhost.eed.ericsson.se [164.48.133.33]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0P5J9w18771; Fri, 25 Jan 2002 06:19:10 +0100 (MET) Received: from res0010384da36.ericsson.com (rac166pc.edd.ericsson.se [164.48.123.166]) by eed.ericsson.se (8.8.8+Sun/1.1.mit) with ESMTP id GAA14899; Fri, 25 Jan 2002 06:19:06 +0100 (MET) Message-Id: <5.1.0.14.0.20020123181652.01a91e80@mailhost.eed.ericsson.se> X-Sender: eedrel@mailhost.eed.ericsson.se (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 25 Jan 2002 05:51:18 +0100 To: Kacheong Poon From: Reiner Ludwig Subject: Re: TCP's RTO & RTT-Spikes [was Re: large RTT variation caused by bandwidth oscillation] Cc: pilc@grc.nasa.gov In-Reply-To: References: <"Your message with ID" <5.1.0.14.0.20020121213641.01a83af8@mailhost.eed.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-pilc@grc.nasa.gov Precedence: bulk At 21:45 22.01.2002, Kacheong Poon wrote: >I can see your reason for timing every segment because of the queue >building up. But it still seems to be a hack for restarting the timer. >It just tells us that the timer is not good enough. What does an ACK >for segment N tell TCP about the fate of segment N+1? I agree with you that restarting REXMT with RTO when a new ACK arrives introduces this offset, and that that is sort of a hack. I.e., it typically makes the REXMT unnecessarily conservative. I hope you agree, though, that REXMT does need to be restarted when a new ACK arrives. But then to be precise this offset which is this mentioned 'age of oldest outstanding segment' needs to be taken account somehow. Do you agree with that? For example, one could do REXMT = RTO - 'age of oldest outstanding segment'; as suggested before. But that should only be done in "normal" phases, not during loss recovery. Still this is not sufficient, because it may be the case that the ACK for segment N does in fact indicate something about the fate of segment N+1: If the RTT for N has suddenly increased compared to SRTT, chances are quite high that the RTT for N+1 will also be increased. However, since SRTT and RTTVAR are smoothing averages, they might not react appropriately quick to compensate for such an RTT spike. Simply doing "REXMT = RTO - 'age of oldest outstanding segment';" will then become too aggressive. That's why we changed our RTO calc to RTO = MAX(SRTT, LastRTTSample) + 'some variation'; >This is why I asked the question whether TCP should have more than one >RTO algorithm. I still believe that we can find a single one that will be OK in general. Not that I believe that an REXMT/RTO can be found that catches each and every RTT spike. Such an REXMT/RTO would probably be far too conservative. Instead, TCP should be able to deal with spurious timeouts :-) > > >I have another minor comment about what actually happens after a timeout. > > >I believe all modern TCP implementations will not have the false fast > > >retransmit after timeout problem mentioned in this thread. > > > > I'm not quite sure what you mean. Please explain this. > >It was suggested that the go-back-N behavior of TCP after a spurious >timeout can trigger false fast retransmit due to those dup ACKS. I >was saying that it was not true for all modern TCP impls. Yes, TCP's that implement the careful version of bugfix from RFC2582 don't have that problem. ///Reiner From owner-pilc@grc.nasa.gov Fri Jan 25 01:52:46 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17827 for ; Fri, 25 Jan 2002 01:52:46 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8CEC464143 for ; Fri, 25 Jan 2002 01:50:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA05243 for pilc-outgoing; Fri, 25 Jan 2002 01:46:17 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id BAA05239 for ; Fri, 25 Jan 2002 01:46:16 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id BAA18744 for ; Fri, 25 Jan 2002 01:46:15 -0500 (EST) Received: from smtp.dave.sonera.fi (smtp.dave.sonera.fi [131.177.130.21]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id BFB16640D6 for ; Fri, 25 Jan 2002 01:45:37 -0500 (EST) Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:2740 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Fri, 25 Jan 2002 08:45:21 +0200 Message-ID: <01f501c1a56b$6e49d260$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: "Kamesh Medepalli" , "Behcet Sarikaya" Cc: , References: <20020124160020.37926.qmail@web11702.mail.yahoo.com> <3C50342D.282D1102@lucent.com> Subject: Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) Date: Fri, 25 Jan 2002 08:42:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I agree that the problem of 'bandwidth oscillation' itself is not new. While not saying anything on cdma2000 vs. umts, I think we should not be so negative about this draft. The authors have done a very good job for example by experimenting on how existing different TCP implementations react to this type of RTT changes, evaluating the effect of different TCP features like timestamps or restarting the retransmit timer on ACKs. After all, the final product is as good as its implementations and there was certainly something to learn for vendors and operators from this draft. Again, not saying that this is a good way to do the resource allocation... Andrei/ Sonera ----- Original Message ----- From: "Kamesh Medepalli" To: "Behcet Sarikaya" Cc: ; Sent: Thursday, January 24, 2002 6:19 PM Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > I am not sure why the CDMA2000 ID was even considered seriously. It is > standard problem that needs to be addressed carefully at the MAC layer. > I am surprised folks actually went up to writing something like this > and blaming it on CDMA2000 in a way! Standards define the basic MAC > protocol. It is upto the Vendors to design "algorithms" for resource > allocation. > > What happened to Phil Karn's and Gorry's comments which were raised very > early after the initial draft was sent out? > > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such > problems to arise if someone used Downlink Shared Channel (DSCH) in UMTS > in a random manner..ofcourse dedicated channels (DCH) help. > > I hope others in the mailing list raise their voice too! > > Thanks Behcet! > Kamesh > > Behcet Sarikaya wrote: > > > > Dear all, > > I am forwarding the opinion of Francois Courau from > > Alcatel France (who is the head of 3GPP RAN WG) on > > this issue. > > I wish we could get another expert opinion of > > someone from Lucent or Qualcomm on the situation in > > CDMA2000. I am afraid if we include Farid's text only > > for CDMA2000 this will cause problems as to the > > inferiority of CDMA2000 vis-a-vis UMTS. > > > > Regards, > > > > --behcet > > > > --- Francois.Courau@alcatel.fr wrote: > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > > > minutes (corrected)) > > > To: Behcet Sarikaya > > > From: Francois.Courau@alcatel.fr > > > Date: Thu, 24 Jan 2002 11:18:44 +0100 > > > > > > > > > I fully share the analysis proposed by Ericsson. The > > > oscillation will be > > > linked with the reduction of throughpur decided > > > uponn by the radio access > > > network in the other cases we don't have a similar > > > problem to CDMA 2000. > > > > > > Francois > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Great stuff seeking new owners in Yahoo! Auctions! > > http://auctions.yahoo.com > From owner-pilc@grc.nasa.gov Fri Jan 25 03:44:25 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27187 for ; Fri, 25 Jan 2002 03:44:25 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C2AB8640F2 for ; Fri, 25 Jan 2002 03:44:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA17337 for pilc-outgoing; Fri, 25 Jan 2002 03:39:59 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA17288 for ; Fri, 25 Jan 2002 03:39:57 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id DAA10530 for ; Fri, 25 Jan 2002 03:39:55 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id B5556C696A; Fri, 25 Jan 2002 03:39:40 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA_BaOjM; Fri, 25 Jan 02 03:39:40 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0P8dL315439; Fri, 25 Jan 2002 02:39:21 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 02:39:21 -0600 Message-ID: From: "Farid Khafizov" To: "'Andrei Gurtov'" , Kamesh Medepalli , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov Cc: "Mehmet Yavuz" , "Farid Khafizov" Subject: RE: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) Date: Fri, 25 Jan 2002 02:39:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A57B.CB7DE330" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A57B.CB7DE330 Content-Type: text/plain; charset="iso-8859-1" Dear all: We would like to clarify a few things about our previous correspondence. We believe this forum is not a place for deciding which 3G wireless technology is better and this definitely was not our intention. This forum should be objective and not biased towards any technology. We have no reason to think that CDMA2000 is inferior to UMTS. If the proposed text implies that, as some have suggested, we must make necessary changes to the text. Furthermore, it was not our intention to say or imply that Bandwidth Oscillation is *characteristic* of any particular network. This should be emphasized in the text. In the proposed text referring to UMTS and/or CDMA2000 we never say *will*. Specifically discussing bandwidth oscillation, we say "may" or "can". Like in UMTS, there are various ways to avoid bandwidth oscillation in CDMA2000. That is why it was decided to address this issue in LINK ID. We used CDMA2000 only as an example. UMTS could have been picked as an example too, if someone does "periodic switch between a high speed dedicated and the common channels. " 2.5g/3g ID is addressing issues of the networks that have not been widely deployed. Initial field reports from operators do not look very rosy. Doing a search on the web would show that expectations for 3g wireless data speed are much lower than originally thought. At this point it is reasonable to say that we do not know *all* TCP issues related to 3g wireless. Only time will show what they are and how to address them. In the absence of data from live networks with multiple users, one has to make certain assumptions on how those network might operate and draw conclusions based on those assumptions. IS-2000.5 specifies 14 options for finite Duration Supplemental Channel assignment. When we evaluated TCP performance for some of those options, we found that TCP didn't like them. It is true that vendors and/or operators may choose different configurations. However, it is important to realize that choosing a "better" SCH duration may come at the cost of additional signaling in the network which has implications to interference limited capacity. If you consider scheduling of users (especially with different QoS classes) , the problem becomes more complex. Even in "properly" designed sub-networks, admitting more users means more revenue, but also increases likelihood of bandwidth oscillation. So, an operator might still be interested in choosing non-optimal configuration options (allowed by the standards) as long as he can reduce throughput degradation by optimizing TCP. That is the main reason why we think bandwidth oscillation should be addressed in 2.5g/3g ID. At this point, we can either remove the Bandwidth Oscillation text from the draft and pretend that it may never happen , or we can specifically state that Bandwidth Oscillation is a potential problems which MIGHT show up and offer TCP optimization techniques. --Farid > -----Original Message----- > From: Andrei Gurtov [SMTP:gurtov@cs.Helsinki.FI] > Sent: Friday, January 25, 2002 12:42 AM > To: Kamesh Medepalli; Behcet Sarikaya > Cc: pilc@grc.nasa.gov; francois.courau@alcatel.fr > Subject: Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > > I agree that the problem of 'bandwidth oscillation' itself is not new. > While > not saying anything on cdma2000 vs. umts, I think we should not be so > negative about this draft. The authors have done a very good job for > example > by experimenting on how existing different TCP implementations react to > this > type of RTT changes, evaluating the effect of different TCP features like > timestamps or restarting the retransmit timer on ACKs. > > After all, the final product is as good as its implementations and there > was > certainly something to learn for vendors and operators from this draft. > Again, not saying that this is a good way to do the resource allocation... > > Andrei/ > Sonera > > ----- Original Message ----- > From: "Kamesh Medepalli" > To: "Behcet Sarikaya" > Cc: ; > Sent: Thursday, January 24, 2002 6:19 PM > Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > > > > I am not sure why the CDMA2000 ID was even considered seriously. It is > > standard problem that needs to be addressed carefully at the MAC layer. > > I am surprised folks actually went up to writing something like this > > and blaming it on CDMA2000 in a way! Standards define the basic MAC > > protocol. It is upto the Vendors to design "algorithms" for resource > > allocation. > > > > What happened to Phil Karn's and Gorry's comments which were raised very > > early after the initial draft was sent out? > > > > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such > > problems to arise if someone used Downlink Shared Channel (DSCH) in UMTS > > in a random manner..ofcourse dedicated channels (DCH) help. > > > > I hope others in the mailing list raise their voice too! > > > > Thanks Behcet! > > Kamesh > > > > Behcet Sarikaya wrote: > > > > > > Dear all, > > > I am forwarding the opinion of Francois Courau from > > > Alcatel France (who is the head of 3GPP RAN WG) on > > > this issue. > > > I wish we could get another expert opinion of > > > someone from Lucent or Qualcomm on the situation in > > > CDMA2000. I am afraid if we include Farid's text only > > > for CDMA2000 this will cause problems as to the > > > inferiority of CDMA2000 vis-a-vis UMTS. > > > > > > Regards, > > > > > > --behcet > > > > > > --- Francois.Courau@alcatel.fr wrote: > > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > > > > minutes (corrected)) > > > > To: Behcet Sarikaya > > > > From: Francois.Courau@alcatel.fr > > > > Date: Thu, 24 Jan 2002 11:18:44 +0100 > > > > > > > > > > > > I fully share the analysis proposed by Ericsson. The > > > > oscillation will be > > > > linked with the reduction of throughpur decided > > > > uponn by the radio access > > > > network in the other cases we don't have a similar > > > > problem to CDMA 2000. > > > > > > > > Francois > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Great stuff seeking new owners in Yahoo! Auctions! > > > http://auctions.yahoo.com > > > ------_=_NextPart_001_01C1A57B.CB7DE330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Re:2.5g/3g ID additions (RE: pilc minutes = (corrected))

Dear = all:

We = would  like to clarify a few things about our previous = correspondence.

We believe = this forum is not a place for deciding which 3G wireless technology =
is better = and this definitely was not our intention. This forum should be = objective and not biased
towards = any technology. We have no reason to think that CDMA2000 is inferior to = UMTS.
If the = proposed text implies that, as some have suggested, we must make = necessary changes to the text.

Furthermore, it was not our intention to say or imply that = Bandwidth Oscillation
is = *characteristic* of any particular network. This should be emphasized = in the text.
In the = proposed text referring to UMTS and/or CDMA2000 we never say = *will*.
Specifically discussing bandwidth oscillation, we say = "may" or "can".
Like in = UMTS, there are various ways to avoid bandwidth oscillation in = CDMA2000.
That is = why it was decided to address this issue in LINK ID.
We used = CDMA2000 only as an example. UMTS could have been picked as an example = too,
if someone = does "periodic switch between a high speed dedicated and the = common channels. "

2.5g/3g ID = is addressing issues of the networks that have not been widely = deployed.
Initial = field reports from operators do not look very rosy. Doing a search on = the web would show
that = expectations for 3g wireless data speed are much lower than originally = thought.
At this = point it is reasonable to say that we do not know *all* TCP issues = related to 3g wireless.
Only time = will show what they are and how to address them. In the absence of data = from
live = networks with multiple users, one has to make certain assumptions on = how those network
might = operate and draw conclusions based on those assumptions.

IS-2000.5 = specifies 14 options for finite Duration Supplemental Channel = assignment.
When we = evaluated TCP performance for some of those options, we found that TCP = didn't like them.
It is true = that vendors and/or operators may choose different = configurations.
However, = it is important to realize that choosing a "better" SCH = duration may come at the
cost of = additional signaling in the network which has implications to = interference limited capacity.
If you = consider scheduling of users (especially with different QoS classes) , = the problem becomes
more = complex. Even in "properly" designed sub-networks, admitting = more users means
more = revenue, but also increases likelihood of bandwidth oscillation. So, an =
operator = might still be interested in choosing non-optimal configuration options = (allowed by the standards)
as long as = he can reduce throughput degradation by optimizing TCP.
That is = the main reason why we think bandwidth oscillation should be addressed = in 2.5g/3g ID.

At this = point, we can either remove the Bandwidth Oscillation text from the = draft and
pretend = that it may never happen , or we can specifically state that
Bandwidth = Oscillation is a potential problems which MIGHT show up and
offer TCP = optimization techniques.

--Farid

-----Original Message-----
From:   Andrei Gurtov = [SMTP:gurtov@cs.Helsinki.FI]
Sent:   Friday, January 25, 2002 12:42 AM
To:     Kamesh Medepalli; Behcet Sarikaya
Cc:     pilc@grc.nasa.gov; francois.courau@alcatel.fr
Subject:       = Re: Re:2.5g/3g ID additions (RE: = pilc minutes (corrected))

I agree that the problem of 'bandwidth = oscillation' itself is not new. While
not saying anything on cdma2000 vs. = umts, I think we should not be so
negative about this draft. The = authors have done a very good job for example
by experimenting on how existing = different TCP implementations react to this
type of RTT changes, evaluating the = effect of different TCP features like
timestamps or restarting the = retransmit timer on ACKs.

After all, the final product is as = good as its implementations and there was
certainly something to learn for = vendors and operators from this draft.
Again, not saying that this is a good = way to do the resource allocation...

Andrei/
Sonera

----- Original Message -----
From: "Kamesh Medepalli" = <medepalli@lucent.com>
To: "Behcet Sarikaya" = <sarikayab@yahoo.com>
Cc: <pilc@grc.nasa.gov>; = <francois.courau@alcatel.fr>
Sent: Thursday, January 24, 2002 6:19 = PM
Subject: Re:2.5g/3g ID additions (RE: = pilc minutes (corrected))


> I am not sure why the CDMA2000 ID = was even considered seriously. It is
> standard problem that needs to = be addressed carefully at the MAC layer.
> I am surprised folks actually = went up to writing something like this
> and blaming it on CDMA2000 in a = way! Standards define the basic MAC
> protocol. It is upto the Vendors = to design "algorithms" for resource
> allocation.
>
> What happened to Phil Karn's and = Gorry's comments which were raised very
> early after the initial draft = was sent out?
>
> Clearly it is not a CDMA2000 vs = UMTS argument etc. It is easy for such
> problems to arise if someone = used Downlink Shared Channel (DSCH) in UMTS
> in a random manner..ofcourse = dedicated channels (DCH) help.
>
> I hope others in the mailing = list raise their voice too!
>
> Thanks Behcet!
> Kamesh
>
> Behcet Sarikaya wrote:
> >
> > Dear all,
> >   I am forwarding = the opinion of Francois Courau from
> > Alcatel France (who is the = head of 3GPP RAN WG) on
> > this issue.
> >   I wish we could = get another expert opinion of
> > someone from Lucent or = Qualcomm on  the situation in
> > CDMA2000. I am afraid if we = include Farid's text only
> > for CDMA2000 this will = cause problems as to the
> > inferiority of CDMA2000 = vis-a-vis UMTS.
> >
> > Regards,
> >
> > --behcet
> >
> > --- = Francois.Courau@alcatel.fr wrote:
> > > Subject: Re: Fwd: Re: = 2.5g/3g ID additions (RE: pilc
> > > minutes = (corrected))
> > > To: Behcet Sarikaya = <sarikayab@yahoo.com>
> > > From: = Francois.Courau@alcatel.fr
> > > Date: Thu, 24 Jan 2002 = 11:18:44 +0100
> > >
> > >
> > > I fully share the = analysis proposed by Ericsson. The
> > > oscillation will = be
> > > linked with the = reduction of throughpur decided
> > > uponn by the radio = access
> > > network in the other = cases we don't have a similar
> > > problem to CDMA = 2000.
> > >
> > > Francois
> > >
> >
> > = __________________________________________________
> > Do You Yahoo!?
> > Great stuff seeking new = owners in Yahoo! Auctions!
> > http://auctions.yahoo.com
>

------_=_NextPart_001_01C1A57B.CB7DE330-- From owner-pilc@grc.nasa.gov Fri Jan 25 10:28:13 2002 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04956 for ; Fri, 25 Jan 2002 10:28:10 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id F0D9664165 for ; Fri, 25 Jan 2002 10:26:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA21153 for pilc-outgoing; Fri, 25 Jan 2002 10:21:40 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id KAA21147 for ; Fri, 25 Jan 2002 10:21:39 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id KAA29724 for ; Fri, 25 Jan 2002 10:21:39 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 7ECF6C6904; Fri, 25 Jan 2002 10:21:37 -0500 (EST) Received: from unknown(211.117.232.146) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAWla4M1; Fri, 25 Jan 02 10:21:36 -0500 Reply-To: office7000@yahoo.co.kr From: 창업정보 To: pilc@grc.nasa.gov Subject: [광고] 돈 되는 사업정보입니다 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 26 Jan 2002 00:22:10 +0900 Message-Id: <20020125152137.7ECF6C6904@seraph2.grc.nasa.gov> Sender: owner-pilc@grc.nasa.gov Precedence: bulk 귀하의 창업을 돕겠습니다.

 

 귀하의 창업을 돕겠습니다.  

 저희 (주)나래정보에서는 전화정보 창업자를 모십니다.

 본  사업소에서 보유한 아이템을 드릴수도 있습니다.

귀하께서 계획하신 아이템을 수익성 있는 사업으로 만들어 드리겠습니다.

수년간의 기술과 노하우로 최선을 다하며, 고객의 이익과 사업의 발전을 위해 노력하는 기업으로

귀하의 곁에 끝까지 남겠습니다.

전화정보(700, 060, 800, 0600)특징

  1. 특별한 자격을 요하지 않습니다.(사업자 등록증 필요)

  2. 수금의 필요성이 없습니다.(각 통신사 수금대행)

  3. 타 사업보다 운영과 관리가 편리합니다.(전화로 관리가능)

  4. 귀하만의 노하우로 정보를 제공합니다.(아이템제공)

  5. 사업성 타당여부 조사.(시장성 조사 대행)

  6. 창업자금지원.(창업자금의 50%지원, 수익금 창출후에 수금)

  7. 사업의 지속성.(시스템 본사 관리. 사업자는 기획과 광고)

  8. 사업의 안전성.(한국통신, 하나로통신, 데이콤등과 연계하여 사업영위)

  9. 본사의 지원.((주)나래에서 사업자등록신청, 시스템제작, 운영, 관리)

 10. 장비임대.(금3,100,000원으로 장비일체와 프로그램을 제공합니다.)

 

"광고메일대행"  링크해주세요  

가장 빠른 광고효과입니다. 빠른 시간안에 확실한 효과를 보실수 있습니다. 이보다  뛰어난 광고효과를 기대할 수 없습니다. 저희 회원에 한하여 후불로 결재 받습니다.
 
                    

 귀하의 메일주소는 웹서핑중, http://www.xxxxxxxx.com/
에서 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면 ,수신거부를 눌러주세요

           

 

From owner-pilc@grc.nasa.gov Fri Jan 25 11:18:53 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06417 for ; Fri, 25 Jan 2002 11:18:52 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 1737E640F6 for ; Fri, 25 Jan 2002 11:17:31 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA08280 for pilc-outgoing; Fri, 25 Jan 2002 11:14:19 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA08231 for ; Fri, 25 Jan 2002 11:14:15 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id LAA08693 for ; Fri, 25 Jan 2002 11:14:12 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 91F5264144 for ; Fri, 25 Jan 2002 11:12:06 -0500 (EST) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0PG74h23452; Fri, 25 Jan 2002 11:07:08 -0500 (EST) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA10002; Fri, 25 Jan 2002 11:07:04 -0500 Message-ID: <3C5182A3.B828007F@lucent.com> Date: Fri, 25 Jan 2002 11:06:59 -0500 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Farid Khafizov Cc: "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz Subject: Re: 2.5g/3g ID additions (RE: pilc minutes (corrected)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Farid, Andrei: If the experiments are applicable to various technologies, my suggestion at this point is to create a subsection in either the 2.5g3g ID and/or LINK ID. It should first unambiguosly state that the problem is quite general and it exists in both wireless and wireline systems. Then as a specific example, describe why it is possible in GPRS, UMTS and CDMA-2000 2.5g3g Technologies. After the description, mention the experiments, results and recommendations (if any). Be sure that the results and recommendations apply across technologies. If they do not, there should be no additions made either of the drafts based on your material - at this time. If you do not have sufficient evidence to prove the general applicability of the solutions, we should wait for the study to be completed. Good results should always be published and I appreciate your willingness to do that. Recommendations should be general. Otherwise, it doesn't make sense to highlight the issue by considering "one of the possible systems" and then proposing the solution for "that particular system". This issue gets a lot more tricky when you start dealing with 3G technologies. I believe you agree with those thoughts. Thanks, Kamesh Farid Khafizov wrote: > > Part 1.1Type: Plain Text (text/plain) Dear all: We would like to clarify a few things about our previous correspondence. We believe this forum is not a place for deciding which 3G wireless technology is better and this definitely was not our intention. This forum should be objective and not biased towards any technology. We have no reason to think that CDMA2000 is inferior to UMTS. If the proposed text implies that, as some have suggested, we must make necessary changes to the text. Furthermore, it was not our intention to say or imply that Bandwidth Oscillation is *characteristic* of any particular network. This should be emphasized in the text. In the proposed text referring to UMTS and/or CDMA2000 we never say *will*. Specifically discussing bandwidth oscillation, we say "may" or "can". Like in UMTS, there are various ways to avoid bandwidth oscillation in CDMA2000. That is why it was decided to address this issue in LINK ID. We used CDMA2000 only as an example. UMTS could have been picked as an example too, if someone does "periodic switch between a high speed dedicated and the common channels. " 2.5g/3g ID is addressing issues of the networks that have not been widely deployed. Initial field reports from operators do not look very rosy. Doing a search on the web would show that expectations for 3g wireless data speed are much lower than originally thought. At this point it is reasonable to say that we do not know *all* TCP issues related to 3g wireless. Only time will show what they are and how to address them. In the absence of data from live networks with multiple users, one has to make certain assumptions on how those network might operate and draw conclusions based on those assumptions. IS-2000.5 specifies 14 options for finite Duration Supplemental Channel assignment. When we evaluated TCP performance for some of those options, we found that TCP didn't like them. It is true that vendors and/or operators may choose different configurations. However, it is important to realize that choosing a "better" SCH duration may come at the cost of additional signaling in the network which has implications to interference limited capacity. If you consider scheduling of users (especially with different QoS classes) , the problem becomes more complex. Even in "properly" designed sub-networks, admitting more users means more revenue, but also increases likelihood of bandwidth oscillation. So, an operator might still be interested in choosing non-optimal configuration options (allowed by the standards) as long as he can reduce throughput degradation by optimizing TCP. That is the main reason why we think bandwidth oscillation should be addressed in 2.5g/3g ID. At this point, we can either remove the Bandwidth Oscillation text from the draft and pretend that it may never happen , or we can specifically state that Bandwidth Oscillation is a potential problems which MIGHT show up and offer TCP optimization techniques. --Farid > -----Original Message----- > From: Andrei Gurtov [SMTP:gurtov@cs.Helsinki.FI] > Sent: Friday, January 25, 2002 12:42 AM > To: Kamesh Medepalli; Behcet Sarikaya > Cc: pilc@grc.nasa.gov; francois.courau@alcatel.fr > Subject: Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > > I agree that the problem of 'bandwidth oscillation' itself is not new. > While > not saying anything on cdma2000 vs. umts, I think we should not be so > negative about this draft. The authors have done a very good job for > example > by experimenting on how existing different TCP implementations react to > this > type of RTT changes, evaluating the effect of different TCP features like > timestamps or restarting the retransmit timer on ACKs. > > After all, the final product is as good as its implementations and there > was > certainly something to learn for vendors and operators from this draft. > Again, not saying that this is a good way to do the resource allocation... > > Andrei/ > Sonera > > ----- Original Message ----- > From: "Kamesh Medepalli" > To: "Behcet Sarikaya" > Cc: ; > Sent: Thursday, January 24, 2002 6:19 PM > Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > > > > I am not sure why the CDMA2000 ID was even considered seriously. It is > > standard problem that needs to be addressed carefully at the MAC layer. > > I am surprised folks actually went up to writing something like this > > and blaming it on CDMA2000 in a way! Standards define the basic MAC > > protocol. It is upto the Vendors to design "algorithms" for resource > > allocation. > > > > What happened to Phil Karn's and Gorry's comments which were raised very > > early after the initial draft was sent out? > > > > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such > > problems to arise if someone used Downlink Shared Channel (DSCH) in UMTS > > in a random manner..ofcourse dedicated channels (DCH) help. > > > > I hope others in the mailing list raise their voice too! > > > > Thanks Behcet! > > Kamesh > > > > Behcet Sarikaya wrote: > > > > > > Dear all, > > > I am forwarding the opinion of Francois Courau from > > > Alcatel France (who is the head of 3GPP RAN WG) on > > > this issue. > > > I wish we could get another expert opinion of > > > someone from Lucent or Qualcomm on the situation in > > > CDMA2000. I am afraid if we include Farid's text only > > > for CDMA2000 this will cause problems as to the > > > inferiority of CDMA2000 vis-a-vis UMTS. > > > > > > Regards, > > > > > > --behcet > > > > > > --- Francois.Courau@alcatel.fr wrote: > > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > > > > minutes (corrected)) > > > > To: Behcet Sarikaya > > > > From: Francois.Courau@alcatel.fr > > > > Date: Thu, 24 Jan 2002 11:18:44 +0100 > > > > > > > > > > > > I fully share the analysis proposed by Ericsson. The > > > > oscillation will be > > > > linked with the reduction of throughpur decided > > > > uponn by the radio access > > > > network in the other cases we don't have a similar > > > > problem to CDMA 2000. > > > > > > > > Francois > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Great stuff seeking new owners in Yahoo! Auctions! > > > http://auctions.yahoo.com > > > From owner-pilc@grc.nasa.gov Fri Jan 25 15:14:07 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12985 for ; Fri, 25 Jan 2002 15:14:06 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id AE91B64165 for ; Fri, 25 Jan 2002 15:11:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA07742 for pilc-outgoing; Fri, 25 Jan 2002 15:04:58 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA07722; Fri, 25 Jan 2002 15:04:56 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id PAA16295; Fri, 25 Jan 2002 15:04:55 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id A6816640FD; Fri, 25 Jan 2002 15:04:54 -0500 (EST) Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0PJrhN26451; Fri, 25 Jan 2002 11:53:43 -0800 (PST) Date: Fri, 25 Jan 2002 11:53:43 -0800 From: Aaron Falk To: Kamesh Medepalli , Farid Khafizov Cc: "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions Message-ID: <67700000.1011988423@nit> In-Reply-To: <3C5182A3.B828007F@lucent.com> References: <3C5182A3.B828007F@lucent.com> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Kamesh- I think I disagree. The results Farid has shown apply to CDMA2000 systems. The purpose of the 2.5g3g document is to explain how operators can configure TCP stacks to get good performance over these links. I think it is very appropriate to mention ameliorative techniques such as those described in draft-khafizov-pilc-cdma2000-00.txt and in the proposed 2.5g3g text. Naturally, it is important to clarify which systems and MAC configurations are addressed. It is probably also appropriate to state that this is an early research finding. However, if there are real systems deployed -- or planned to be deployed -- that have these problems, it is appropriate to include this text in the 2.5g3g draft. As we discussed in SLC, LINK also needs some text. This text, as you suggest below, should discuss the general problem of varying link bandwidth. The plans are to extend the section on 'Bandwidth on Demand' to include these effects. However, the purpose of LINK is to advise designers of future links on things they should do -- or avoid doing -- to support Internet. It would not be appropriate to discuss how to tweak a TCP stack to get good performance over a CDMA2000 link in this document. *References* to Farid's work are worth including in LINK as warnings to link designers of the negative consequences of link bandwidth oscillation on TCP performance. I hope this helps, --aaron --On Friday, January 25, 2002 11:06:59 AM -0500 Kamesh Medepalli wrote: > Farid, Andrei: > > If the experiments are applicable to various technologies, my suggestion > at this point is to create a subsection in either the 2.5g3g ID and/or > LINK ID. It should first unambiguosly state that the problem is quite > general and it exists in both wireless and wireline systems. Then as a > specific example, describe why it is possible in GPRS, UMTS and > CDMA-2000 2.5g3g Technologies. > > After the description, mention the experiments, results and > recommendations (if any). Be sure that the results and recommendations > apply across technologies. If they do not, there should be no additions > made either of the drafts based on your material - at this time. If you > do not have sufficient evidence to prove the general applicability of the > solutions, we should wait for the study to be completed. Good results > should always be published and I appreciate your willingness to do that. > > Recommendations should be general. Otherwise, it doesn't make sense to > highlight the issue by considering "one of the possible systems" and then > proposing the solution for "that particular system". This issue gets a > lot more tricky when you start dealing with 3G technologies. I believe > you agree with those thoughts. > > Thanks, > Kamesh > > Farid Khafizov wrote: >> >> Part 1.1Type: Plain Text (text/plain) > Dear all: > > We would like to clarify a few things about our previous correspondence. > > We believe this forum is not a place for deciding which 3G wireless > technology > is better and this definitely was not our intention. This forum should be > objective and not biased > towards any technology. We have no reason to think that CDMA2000 is > inferior to UMTS. > If the proposed text implies that, as some have suggested, we must make > necessary changes to the text. > > Furthermore, it was not our intention to say or imply that Bandwidth > Oscillation > is *characteristic* of any particular network. This should be emphasized > in the text. > In the proposed text referring to UMTS and/or CDMA2000 we never say > *will*. Specifically discussing bandwidth oscillation, we say "may" or > "can". Like in UMTS, there are various ways to avoid bandwidth > oscillation in CDMA2000. > That is why it was decided to address this issue in LINK ID. > We used CDMA2000 only as an example. UMTS could have been picked as an > example too, > if someone does "periodic switch between a high speed dedicated and the > common channels. " > > 2.5g/3g ID is addressing issues of the networks that have not been widely > deployed. > Initial field reports from operators do not look very rosy. Doing a search > on the web would show > that expectations for 3g wireless data speed are much lower than > originally thought. > At this point it is reasonable to say that we do not know *all* TCP issues > related to 3g wireless. > Only time will show what they are and how to address them. In the absence > of data from > live networks with multiple users, one has to make certain assumptions on > how those network > might operate and draw conclusions based on those assumptions. > > IS-2000.5 specifies 14 options for finite Duration Supplemental Channel > assignment. > When we evaluated TCP performance for some of those options, we found that > TCP didn't like them. > It is true that vendors and/or operators may choose different > configurations. > However, it is important to realize that choosing a "better" SCH duration > may come at the > cost of additional signaling in the network which has implications to > interference limited capacity. > If you consider scheduling of users (especially with different QoS > classes) , the problem becomes > more complex. Even in "properly" designed sub-networks, admitting more > users means > more revenue, but also increases likelihood of bandwidth oscillation. So, > an > > operator might still be interested in choosing non-optimal configuration > options (allowed by the standards) > as long as he can reduce throughput degradation by optimizing TCP. > That is the main reason why we think bandwidth oscillation should be > addressed in 2.5g/3g ID. > > At this point, we can either remove the Bandwidth Oscillation text from > the draft and > pretend that it may never happen , or we can specifically state that > Bandwidth Oscillation is a potential problems which MIGHT show up and > offer TCP optimization techniques. > > --Farid > >> -----Original Message----- >> From: Andrei Gurtov [SMTP:gurtov@cs.Helsinki.FI] >> Sent: Friday, January 25, 2002 12:42 AM >> To: Kamesh Medepalli; Behcet Sarikaya >> Cc: pilc@grc.nasa.gov; francois.courau@alcatel.fr >> Subject: Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) >> >> I agree that the problem of 'bandwidth oscillation' itself is not new. >> While >> not saying anything on cdma2000 vs. umts, I think we should not be so >> negative about this draft. The authors have done a very good job for >> example >> by experimenting on how existing different TCP implementations react to >> this >> type of RTT changes, evaluating the effect of different TCP features like >> timestamps or restarting the retransmit timer on ACKs. >> >> After all, the final product is as good as its implementations and there >> was >> certainly something to learn for vendors and operators from this draft. >> Again, not saying that this is a good way to do the resource >> allocation... >> >> Andrei/ >> Sonera >> >> ----- Original Message ----- >> From: "Kamesh Medepalli" >> To: "Behcet Sarikaya" >> Cc: ; >> Sent: Thursday, January 24, 2002 6:19 PM >> Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) >> >> >> > I am not sure why the CDMA2000 ID was even considered seriously. It is >> > standard problem that needs to be addressed carefully at the MAC layer. >> > I am surprised folks actually went up to writing something like this >> > and blaming it on CDMA2000 in a way! Standards define the basic MAC >> > protocol. It is upto the Vendors to design "algorithms" for resource >> > allocation. >> > >> > What happened to Phil Karn's and Gorry's comments which were raised >> > very early after the initial draft was sent out? >> > >> > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such >> > problems to arise if someone used Downlink Shared Channel (DSCH) in >> > UMTS in a random manner..ofcourse dedicated channels (DCH) help. >> > >> > I hope others in the mailing list raise their voice too! >> > >> > Thanks Behcet! >> > Kamesh >> > >> > Behcet Sarikaya wrote: >> > > >> > > Dear all, >> > > I am forwarding the opinion of Francois Courau from >> > > Alcatel France (who is the head of 3GPP RAN WG) on >> > > this issue. >> > > I wish we could get another expert opinion of >> > > someone from Lucent or Qualcomm on the situation in >> > > CDMA2000. I am afraid if we include Farid's text only >> > > for CDMA2000 this will cause problems as to the >> > > inferiority of CDMA2000 vis-a-vis UMTS. >> > > >> > > Regards, >> > > >> > > --behcet >> > > >> > > --- Francois.Courau@alcatel.fr wrote: >> > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc >> > > > minutes (corrected)) >> > > > To: Behcet Sarikaya >> > > > From: Francois.Courau@alcatel.fr >> > > > Date: Thu, 24 Jan 2002 11:18:44 +0100 >> > > > >> > > > >> > > > I fully share the analysis proposed by Ericsson. The >> > > > oscillation will be >> > > > linked with the reduction of throughpur decided >> > > > uponn by the radio access >> > > > network in the other cases we don't have a similar >> > > > problem to CDMA 2000. >> > > > >> > > > Francois >> > > > >> > > >> > > __________________________________________________ >> > > Do You Yahoo!? >> > > Great stuff seeking new owners in Yahoo! Auctions! >> > > http://auctions.yahoo.com >> > >> From owner-pilc@grc.nasa.gov Fri Jan 25 17:06:00 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15696 for ; Fri, 25 Jan 2002 17:05:59 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id D3E4DC69BB; Fri, 25 Jan 2002 17:03:44 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAMZai_N; Fri, 25 Jan 02 17:03:44 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA06294 for pilc-outgoing; Fri, 25 Jan 2002 16:59:16 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA06286; Fri, 25 Jan 2002 16:59:14 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id QAA04402; Fri, 25 Jan 2002 16:59:13 -0500 (EST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6E45164095; Fri, 25 Jan 2002 16:59:08 -0500 (EST) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0PLx5701894; Fri, 25 Jan 2002 16:59:05 -0500 (EST) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA20732; Fri, 25 Jan 2002 16:59:04 -0500 Message-ID: <3C51D521.BB3E7E1D@lucent.com> Date: Fri, 25 Jan 2002 16:58:57 -0500 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Falk Cc: Farid Khafizov , "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions References: <3C5182A3.B828007F@lucent.com> <67700000.1011988423@nit> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Aaron: Thanks for the mail. A couple of comments: 1. Wireless community is far different than Internet community. I don't have to tell you about all those Standards wars. Although CDMA-2000 ID has recommendations backed by some experimental studies, it is for some examples of rate allocation. It is not a generic statement. If we do not change the wording/content, it is very easy for someone in Wireless to say.."Oh, cdma2000 is not very TCP friendly, Where as UMTS, HDR (1X-EV-DO), GPRS are" --- That is WRONG. All these systems need TCP fixes if the resource allocation is not TCP friendly. The solution to the problem is to fix the allocation scheme and let TCP be transparent. Each Vendor has their own way of fixing this and operator ultimately chooses the one which works the best! 2. It is not always possible for bandwidth oscillation to exist in CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific examples". We have worked for the last 3 years on HTTP,FTP/TCP over CDMA-2000 and hence I can tell you that much! If anyone is interested, they can look at our VTC-2000 Spring paper (on just TCP) or MMT-2000 (with HTTP also) one. These for static rates. A more comprehensive paper is being published in Wireless Networks Journal [they haven't given us a date yet]. If the recommendations are generic for all Wireless Schemes, then they should be included in an RFC. Otherwise, we should hold on or explain the problem and fixes with a "generic" tone..without highlighting cdma2000 alone. Thanks, Kamesh Aaron Falk wrote: > > Kamesh- > > I think I disagree. The results Farid has shown apply to CDMA2000 systems. > The purpose of the 2.5g3g document is to explain how operators can > configure TCP stacks to get good performance over these links. I think it > is very appropriate to mention ameliorative techniques such as those > described in draft-khafizov-pilc-cdma2000-00.txt and in the proposed 2.5g3g > text. Naturally, it is important to clarify which systems and MAC > configurations are addressed. It is probably also appropriate to state > that this is an early research finding. However, if there are real systems > deployed -- or planned to be deployed -- that have these problems, it is > appropriate to include this text in the 2.5g3g draft. > > As we discussed in SLC, LINK also needs some text. This text, as you > suggest below, should discuss the general problem of varying link > bandwidth. The plans are to extend the section on 'Bandwidth on Demand' to > include these effects. However, the purpose of LINK is to advise designers > of future links on things they should do -- or avoid doing -- to support > Internet. It would not be appropriate to discuss how to tweak a TCP stack > to get good performance over a CDMA2000 link in this document. > *References* to Farid's work are worth including in LINK as warnings to > link designers of the negative consequences of link bandwidth oscillation > on TCP performance. > > I hope this helps, > > --aaron > > --On Friday, January 25, 2002 11:06:59 AM -0500 Kamesh Medepalli > wrote: > > > Farid, Andrei: > > > > If the experiments are applicable to various technologies, my suggestion > > at this point is to create a subsection in either the 2.5g3g ID and/or > > LINK ID. It should first unambiguosly state that the problem is quite > > general and it exists in both wireless and wireline systems. Then as a > > specific example, describe why it is possible in GPRS, UMTS and > > CDMA-2000 2.5g3g Technologies. > > > > After the description, mention the experiments, results and > > recommendations (if any). Be sure that the results and recommendations > > apply across technologies. If they do not, there should be no additions > > made either of the drafts based on your material - at this time. If you > > do not have sufficient evidence to prove the general applicability of the > > solutions, we should wait for the study to be completed. Good results > > should always be published and I appreciate your willingness to do that. > > > > Recommendations should be general. Otherwise, it doesn't make sense to > > highlight the issue by considering "one of the possible systems" and then > > proposing the solution for "that particular system". This issue gets a > > lot more tricky when you start dealing with 3G technologies. I believe > > you agree with those thoughts. > > > > Thanks, > > Kamesh > > > > Farid Khafizov wrote: > >> > >> Part 1.1Type: Plain Text (text/plain) > > Dear all: > > > > We would like to clarify a few things about our previous correspondence. > > > > We believe this forum is not a place for deciding which 3G wireless > > technology > > is better and this definitely was not our intention. This forum should be > > objective and not biased > > towards any technology. We have no reason to think that CDMA2000 is > > inferior to UMTS. > > If the proposed text implies that, as some have suggested, we must make > > necessary changes to the text. > > > > Furthermore, it was not our intention to say or imply that Bandwidth > > Oscillation > > is *characteristic* of any particular network. This should be emphasized > > in the text. > > In the proposed text referring to UMTS and/or CDMA2000 we never say > > *will*. Specifically discussing bandwidth oscillation, we say "may" or > > "can". Like in UMTS, there are various ways to avoid bandwidth > > oscillation in CDMA2000. > > That is why it was decided to address this issue in LINK ID. > > We used CDMA2000 only as an example. UMTS could have been picked as an > > example too, > > if someone does "periodic switch between a high speed dedicated and the > > common channels. " > > > > 2.5g/3g ID is addressing issues of the networks that have not been widely > > deployed. > > Initial field reports from operators do not look very rosy. Doing a search > > on the web would show > > that expectations for 3g wireless data speed are much lower than > > originally thought. > > At this point it is reasonable to say that we do not know *all* TCP issues > > related to 3g wireless. > > Only time will show what they are and how to address them. In the absence > > of data from > > live networks with multiple users, one has to make certain assumptions on > > how those network > > might operate and draw conclusions based on those assumptions. > > > > IS-2000.5 specifies 14 options for finite Duration Supplemental Channel > > assignment. > > When we evaluated TCP performance for some of those options, we found that > > TCP didn't like them. > > It is true that vendors and/or operators may choose different > > configurations. > > However, it is important to realize that choosing a "better" SCH duration > > may come at the > > cost of additional signaling in the network which has implications to > > interference limited capacity. > > If you consider scheduling of users (especially with different QoS > > classes) , the problem becomes > > more complex. Even in "properly" designed sub-networks, admitting more > > users means > > more revenue, but also increases likelihood of bandwidth oscillation. So, > > an > > > > operator might still be interested in choosing non-optimal configuration > > options (allowed by the standards) > > as long as he can reduce throughput degradation by optimizing TCP. > > That is the main reason why we think bandwidth oscillation should be > > addressed in 2.5g/3g ID. > > > > At this point, we can either remove the Bandwidth Oscillation text from > > the draft and > > pretend that it may never happen , or we can specifically state that > > Bandwidth Oscillation is a potential problems which MIGHT show up and > > offer TCP optimization techniques. > > > > --Farid > > > >> -----Original Message----- > >> From: Andrei Gurtov [SMTP:gurtov@cs.Helsinki.FI] > >> Sent: Friday, January 25, 2002 12:42 AM > >> To: Kamesh Medepalli; Behcet Sarikaya > >> Cc: pilc@grc.nasa.gov; francois.courau@alcatel.fr > >> Subject: Re: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > >> > >> I agree that the problem of 'bandwidth oscillation' itself is not new. > >> While > >> not saying anything on cdma2000 vs. umts, I think we should not be so > >> negative about this draft. The authors have done a very good job for > >> example > >> by experimenting on how existing different TCP implementations react to > >> this > >> type of RTT changes, evaluating the effect of different TCP features like > >> timestamps or restarting the retransmit timer on ACKs. > >> > >> After all, the final product is as good as its implementations and there > >> was > >> certainly something to learn for vendors and operators from this draft. > >> Again, not saying that this is a good way to do the resource > >> allocation... > >> > >> Andrei/ > >> Sonera > >> > >> ----- Original Message ----- > >> From: "Kamesh Medepalli" > >> To: "Behcet Sarikaya" > >> Cc: ; > >> Sent: Thursday, January 24, 2002 6:19 PM > >> Subject: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) > >> > >> > >> > I am not sure why the CDMA2000 ID was even considered seriously. It is > >> > standard problem that needs to be addressed carefully at the MAC layer. > >> > I am surprised folks actually went up to writing something like this > >> > and blaming it on CDMA2000 in a way! Standards define the basic MAC > >> > protocol. It is upto the Vendors to design "algorithms" for resource > >> > allocation. > >> > > >> > What happened to Phil Karn's and Gorry's comments which were raised > >> > very early after the initial draft was sent out? > >> > > >> > Clearly it is not a CDMA2000 vs UMTS argument etc. It is easy for such > >> > problems to arise if someone used Downlink Shared Channel (DSCH) in > >> > UMTS in a random manner..ofcourse dedicated channels (DCH) help. > >> > > >> > I hope others in the mailing list raise their voice too! > >> > > >> > Thanks Behcet! > >> > Kamesh > >> > > >> > Behcet Sarikaya wrote: > >> > > > >> > > Dear all, > >> > > I am forwarding the opinion of Francois Courau from > >> > > Alcatel France (who is the head of 3GPP RAN WG) on > >> > > this issue. > >> > > I wish we could get another expert opinion of > >> > > someone from Lucent or Qualcomm on the situation in > >> > > CDMA2000. I am afraid if we include Farid's text only > >> > > for CDMA2000 this will cause problems as to the > >> > > inferiority of CDMA2000 vis-a-vis UMTS. > >> > > > >> > > Regards, > >> > > > >> > > --behcet > >> > > > >> > > --- Francois.Courau@alcatel.fr wrote: > >> > > > Subject: Re: Fwd: Re: 2.5g/3g ID additions (RE: pilc > >> > > > minutes (corrected)) > >> > > > To: Behcet Sarikaya > >> > > > From: Francois.Courau@alcatel.fr > >> > > > Date: Thu, 24 Jan 2002 11:18:44 +0100 > >> > > > > >> > > > > >> > > > I fully share the analysis proposed by Ericsson. The > >> > > > oscillation will be > >> > > > linked with the reduction of throughpur decided > >> > > > uponn by the radio access > >> > > > network in the other cases we don't have a similar > >> > > > problem to CDMA 2000. > >> > > > > >> > > > Francois > >> > > > > >> > > > >> > > __________________________________________________ > >> > > Do You Yahoo!? > >> > > Great stuff seeking new owners in Yahoo! Auctions! > >> > > http://auctions.yahoo.com > >> > > >> From owner-pilc@grc.nasa.gov Fri Jan 25 17:54:02 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17317 for ; Fri, 25 Jan 2002 17:54:02 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 6244864179 for ; Fri, 25 Jan 2002 17:53:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA15217 for pilc-outgoing; Fri, 25 Jan 2002 17:49:15 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA15181; Fri, 25 Jan 2002 17:49:13 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id RAA11506; Fri, 25 Jan 2002 17:49:12 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 16E13640A5; Fri, 25 Jan 2002 17:49:12 -0500 (EST) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0PMn9304189; Fri, 25 Jan 2002 17:49:09 -0500 (EST) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA21860; Fri, 25 Jan 2002 17:49:09 -0500 Message-ID: <3C51E0DE.26ED6369@lucent.com> Date: Fri, 25 Jan 2002 17:49:02 -0500 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Falk Cc: Farid Khafizov , "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions References: <3C5182A3.B828007F@lucent.com> <67700000.1011988423@nit> <3C51D521.BB3E7E1D@lucent.com> <72970000.1011997817@nit> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi Aaron: Some comments inline.. Aaron Falk wrote: > > > If we do not change the wording/content, it is very easy for someone > > in Wireless to say.."Oh, cdma2000 is not very TCP friendly, Where as > > UMTS, HDR (1X-EV-DO), GPRS are" --- That is WRONG. All these systems > > need TCP fixes if the resource allocation is not TCP friendly. The > > solution to the problem is to fix the allocation scheme and let TCP > > be transparent. Each Vendor has their own way of fixing this and > > operator ultimately chooses the one which works the best! > > I think the doc should say (based on Farid's work) that this behavior is of > specific concern to CDMA2000 networks because there is an increased > liklihood of a MAC configuration which exhibits it. Do you disagree that > this is the case? Yes. > > > 2. It is not always possible for bandwidth oscillation to exist in > > CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific > > examples". > > Can you give specific counter examples? Sorry, I can't do it! (It may sound funny but such information is deemed proprietary) > > > We have worked for the last 3 years on HTTP,FTP/TCP over > > CDMA-2000 and hence I can tell you that much! If anyone is > > interested, they can look at our VTC-2000 Spring paper (on just TCP) > > or MMT-2000 (with HTTP also) one. > > URLs would be helpful here. > > > These for static rates. > > Um, bandwidth oscillation = dynamic rates != static rates, right? Do these > references address the issue we discussing or are you supporting your claim > to be knowledgeable in the field? No, these references do not show counter evidence. It is some proof that we have worked on TCP over cdma2000! > > > If the recommendations are generic for all Wireless Schemes, then they > > should be included in an RFC. Otherwise, we should hold on or explain > > the problem and fixes with a "generic" tone..without highlighting > > cdma2000 alone. > > So, as a non-expert in this area I'm still fuzzy about whether > > a) there are significant examples of CDMA2000 MACs which do not exhibit > bandwidth oscillation (i.e., can this be fixed with proper MAC tuning)? My answer is Yes. Even Farid has commented on this to some extent, I am pasting his comments from the previous mail... IS-2000.5 specifies 14 options for finite Duration Supplemental Channel assignment. When we evaluated TCP performance for some of those options, we found that TCP didn't like them. It is true that vendors and/or operators may choose different configurations. However, it is important to realize that choosing a "better" SCH duration may come at the cost of additional signaling in the network which has implications to interference limited capacity. If you consider scheduling of users (especially with different QoS classes) , the problem becomes more complex. Even in "properly" designed sub-networks, admitting more users means more revenue, but also increases likelihood of bandwidth oscillation. > > b) the type of bandwidth oscillation which affects TCP performance is also > present in other 2.5g/3g systems. > > I'd like to hear some more voices here. I would like to also! Thanks, Kamesh From owner-pilc@grc.nasa.gov Fri Jan 25 17:54:19 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17333 for ; Fri, 25 Jan 2002 17:54:19 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C254C6417E for ; Fri, 25 Jan 2002 17:53:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA15274 for pilc-outgoing; Fri, 25 Jan 2002 17:49:40 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA15256; Fri, 25 Jan 2002 17:49:39 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id RAA11536; Fri, 25 Jan 2002 17:49:38 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C36D964095; Fri, 25 Jan 2002 17:49:37 -0500 (EST) Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0PMUHN24884; Fri, 25 Jan 2002 14:30:17 -0800 (PST) Date: Fri, 25 Jan 2002 14:30:17 -0800 From: Aaron Falk To: Kamesh Medepalli Cc: Farid Khafizov , "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions Message-ID: <72970000.1011997817@nit> In-Reply-To: <3C51D521.BB3E7E1D@lucent.com> References: <3C5182A3.B828007F@lucent.com> <67700000.1011988423@nit> <3C51D521.BB3E7E1D@lucent.com> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > If we do not change the wording/content, it is very easy for someone > in Wireless to say.."Oh, cdma2000 is not very TCP friendly, Where as > UMTS, HDR (1X-EV-DO), GPRS are" --- That is WRONG. All these systems > need TCP fixes if the resource allocation is not TCP friendly. The > solution to the problem is to fix the allocation scheme and let TCP > be transparent. Each Vendor has their own way of fixing this and > operator ultimately chooses the one which works the best! I think the doc should say (based on Farid's work) that this behavior is of specific concern to CDMA2000 networks because there is an increased liklihood of a MAC configuration which exhibits it. Do you disagree that this is the case? > 2. It is not always possible for bandwidth oscillation to exist in > CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific > examples". Can you give specific counter examples? > We have worked for the last 3 years on HTTP,FTP/TCP over > CDMA-2000 and hence I can tell you that much! If anyone is > interested, they can look at our VTC-2000 Spring paper (on just TCP) > or MMT-2000 (with HTTP also) one. URLs would be helpful here. > These for static rates. Um, bandwidth oscillation = dynamic rates != static rates, right? Do these references address the issue we discussing or are you supporting your claim to be knowledgeable in the field? > If the recommendations are generic for all Wireless Schemes, then they > should be included in an RFC. Otherwise, we should hold on or explain > the problem and fixes with a "generic" tone..without highlighting > cdma2000 alone. So, as a non-expert in this area I'm still fuzzy about whether a) there are significant examples of CDMA2000 MACs which do not exhibit bandwidth oscillation (i.e., can this be fixed with proper MAC tuning)? b) the type of bandwidth oscillation which affects TCP performance is also present in other 2.5g/3g systems. I'd like to hear some more voices here. Thanks, --aaron From owner-pilc@grc.nasa.gov Fri Jan 25 18:32:22 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17943 for ; Fri, 25 Jan 2002 18:32:21 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id DC12B640FF for ; Fri, 25 Jan 2002 18:32:17 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA22262 for pilc-outgoing; Fri, 25 Jan 2002 18:27:31 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA22254; Fri, 25 Jan 2002 18:27:29 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA17008; Fri, 25 Jan 2002 18:27:29 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8045964095; Fri, 25 Jan 2002 18:27:28 -0500 (EST) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g0PNRQ312326; Fri, 25 Jan 2002 18:27:26 -0500 (EST) Received: from lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA22951; Fri, 25 Jan 2002 18:27:26 -0500 Message-ID: <3C51E9D6.43C1CF80@lucent.com> Date: Fri, 25 Jan 2002 18:27:18 -0500 From: Kamesh Medepalli Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Aaron Falk Cc: Farid Khafizov , "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions References: <3C5182A3.B828007F@lucent.com> <67700000.1011988423@nit> <3C51D521.BB3E7E1D@lucent.com> <72970000.1011997817@nit> <3C51E0DE.26ED6369@lucent.com> <74900000.1012000903@nit> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Aaron: I cannot make any more comments. I am for the last comment you made about crafting the text. I would be happy if the references to cdma2000 are kept to a minimum. Thanks, Kamesh Aaron Falk wrote: > > >> I think the doc should say (based on Farid's work) that this behavior is > >> of specific concern to CDMA2000 networks because there is an increased > >> liklihood of a MAC configuration which exhibits it. Do you disagree that > >> this is the case? > > > > Yes. > > If you want to convince me you'll have to support your answer with > something more than that. Farid has shown that there are modes in CDMA2000 > which exhibit bandwidth oscillation that can degrade TCP performance. > Reiner has stated that this isn't the case for WCDMA/UMTS because of a > different time scale used for the bandwidth allocation. Please provide > your reasoning why you feel that CDMA2000 isn't more likely to experience > these problems. I'm open minded about this but you have to back up your > claim. > > >> > 2. It is not always possible for bandwidth oscillation to exist in > >> > CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific > >> > examples". > >> > >> Can you give specific counter examples? > > > > Sorry, I can't do it! (It may sound funny but such information is deemed > > proprietary) > > So you are aware of a proprietary solution that doesn't exhibit these > problems. Thats fine. (Actually, it's good!) But because you (or your > employer) feels its proprietary, that's even more indication that there may > be/are people out there fielding systems which *do* exhibit these > oscillations. This text is for them. I think Farid's text that you pasted > below: > > > IS-2000.5 specifies 14 options for finite Duration Supplemental Channel > > assignment. When we evaluated TCP performance for some of those options, > > we found that TCP didn't like them. It is true that vendors and/or > > operators may choose different configurations. However, it is important > > to realize that choosing a "better" SCH duration may come at the cost of > > additional signaling in the network which has implications to > > interference limited capacity. If you consider scheduling of users > > (especially with different QoS classes) , the problem becomes more > > complex. Even in "properly" designed sub-networks, admitting more users > > means more revenue, but also increases likelihood of bandwidth > > oscillation. > > can be crafted into a suitable caveat that doesn't imply that all CDMA2000 > systems have worse performance than other technologies. > > --aaron From owner-pilc@grc.nasa.gov Fri Jan 25 18:43:24 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18231 for ; Fri, 25 Jan 2002 18:43:23 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id CDF5B64109 for ; Fri, 25 Jan 2002 18:43:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA24318 for pilc-outgoing; Fri, 25 Jan 2002 18:38:55 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA24308; Fri, 25 Jan 2002 18:38:53 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA18449; Fri, 25 Jan 2002 18:38:53 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C352764095; Fri, 25 Jan 2002 18:38:51 -0500 (EST) Received: from nit (nit.isi.edu [128.9.160.116]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g0PNLhN23224; Fri, 25 Jan 2002 15:21:43 -0800 (PST) Date: Fri, 25 Jan 2002 15:21:43 -0800 From: Aaron Falk To: Kamesh Medepalli Cc: Farid Khafizov , "'Andrei Gurtov'" , Behcet Sarikaya , "'Reiner Ludwig'" , pilc@grc.nasa.gov, Mehmet Yavuz , Mark Allman Subject: Re: 2.5g/3g ID additions Message-ID: <74900000.1012000903@nit> In-Reply-To: <3C51E0DE.26ED6369@lucent.com> References: <3C5182A3.B828007F@lucent.com> <67700000.1011988423@nit> <3C51D521.BB3E7E1D@lucent.com> <72970000.1011997817@nit> <3C51E0DE.26ED6369@lucent.com> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit >> I think the doc should say (based on Farid's work) that this behavior is >> of specific concern to CDMA2000 networks because there is an increased >> liklihood of a MAC configuration which exhibits it. Do you disagree that >> this is the case? > > Yes. If you want to convince me you'll have to support your answer with something more than that. Farid has shown that there are modes in CDMA2000 which exhibit bandwidth oscillation that can degrade TCP performance. Reiner has stated that this isn't the case for WCDMA/UMTS because of a different time scale used for the bandwidth allocation. Please provide your reasoning why you feel that CDMA2000 isn't more likely to experience these problems. I'm open minded about this but you have to back up your claim. >> > 2. It is not always possible for bandwidth oscillation to exist in >> > CDMA-2000. Hence, the study cases in Farid's ID are kind of "specific >> > examples". >> >> Can you give specific counter examples? > > Sorry, I can't do it! (It may sound funny but such information is deemed > proprietary) So you are aware of a proprietary solution that doesn't exhibit these problems. Thats fine. (Actually, it's good!) But because you (or your employer) feels its proprietary, that's even more indication that there may be/are people out there fielding systems which *do* exhibit these oscillations. This text is for them. I think Farid's text that you pasted below: > IS-2000.5 specifies 14 options for finite Duration Supplemental Channel > assignment. When we evaluated TCP performance for some of those options, > we found that TCP didn't like them. It is true that vendors and/or > operators may choose different configurations. However, it is important > to realize that choosing a "better" SCH duration may come at the cost of > additional signaling in the network which has implications to > interference limited capacity. If you consider scheduling of users > (especially with different QoS classes) , the problem becomes more > complex. Even in "properly" designed sub-networks, admitting more users > means more revenue, but also increases likelihood of bandwidth > oscillation. can be crafted into a suitable caveat that doesn't imply that all CDMA2000 systems have worse performance than other technologies. --aaron From owner-pilc@grc.nasa.gov Sat Jan 26 08:20:37 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06488 for ; Sat, 26 Jan 2002 08:20:37 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id BE7EFC698B; Sat, 26 Jan 2002 08:20:29 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAVTaWT1; Sat, 26 Jan 02 08:20:29 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA06835 for pilc-outgoing; Sat, 26 Jan 2002 08:13:59 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id IAA06831; Sat, 26 Jan 2002 08:13:58 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id IAA17294; Sat, 26 Jan 2002 08:13:57 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 76AFFC6908; Sat, 26 Jan 2002 08:13:55 -0500 (EST) Received: from smtp05.iddeo.es(62.81.186.15) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAZzaWz0; Sat, 26 Jan 02 08:13:55 -0500 Received: from czf02.el-consorci.com ([62.81.28.145]) by smtp05.retemail.es (InterMail vM.5.01.03.02 201-253-122-118-102-20010403) with ESMTP id <20020126131336.ZQBC1011.smtp05.retemail.es@czf02.el-consorci.com>; Sat, 26 Jan 2002 14:13:36 +0100 Received: from in.mail.bih.net.ba=0 (1Cust192.tnt1.bloomington.il.da.uu.net [63.27.139.192]) by czf02.el-consorci.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZGNQHQZ6; Sat, 26 Jan 2002 14:12:55 +0100 Message-ID: <000008950fcc$000072fc$00003f5f@radius.wol.net.pk> To: From: "nwe9osa_gw@wol.net.pk" Subject: Do Something You've Always Wanted1107 Date: Sat, 26 Jan 2002 07:09:02 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: quoted-printable
Get Your T= eeth Bright White Now!
 
If you've considered using professional teeth whitening from your local
Dentist, you already know it can cost as = much as $300-$500.....BUT NOW
you can do it at a fraction of the cost in the priv= acy of your home!
=

Please = take this opportunity to visit our site at http://208.31.60.32 
and learn more about this fantastic product!
 
Here's what you'll find:
=
  • Complete information on what this prod= uct will do and how it is= used.
  • Comparisons to the competition (including a cost analys= is)
  • Why we claim = to be the most powerful at-home whitening system available.
  • A full explanation of our 30 Day money back guarantee!
=
<= FONT face=3DArial size=3D2>
Clic= k here to learn more now! http://208.31.60.32

<= BR>
From owner-pilc@grc.nasa.gov Sat Jan 26 17:52:13 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11615 for ; Sat, 26 Jan 2002 17:52:12 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id AD9CCC6972; Sat, 26 Jan 2002 17:52:16 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAqCaOGm; Sat, 26 Jan 02 17:52:16 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA22161 for pilc-outgoing; Sat, 26 Jan 2002 17:48:02 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA22157 for ; Sat, 26 Jan 2002 17:48:01 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id RAA12681 for ; Sat, 26 Jan 2002 17:48:00 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 5CCA6C6965; Sat, 26 Jan 2002 17:48:00 -0500 (EST) Received: from viola.demizu.org(61.194.197.46) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA6VaWAl; Sat, 26 Jan 02 17:47:59 -0500 Received: from localhost (localhost [127.0.0.1]) by viola.demizu.org (8.11.0/8.11.0) with ESMTP id g0QMlDJ00505; Sun, 27 Jan 2002 07:47:14 +0900 (JST) From: Noritoshi Demizu To: pilc@grc.nasa.gov Subject: Re: text on use of timestamps for 2.5g3g draft In-Reply-To: Your message of "Tue, 22 Jan 2002 09:47:44 +0200" References: <004401c1a320$9322d8e0$6b24b183@etela.sonera.fi> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020127074712X.demizu@dd.iij4u.or.jp> Date: Sun, 27 Jan 2002 07:47:12 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 26 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Andrei, > The original specification of the timestamp option [5] may contain some > flaws. An update specification [B93] provides the necessary fixes. Ideas in > this expired draft appear in all current implementations of [5]. Is the last statement correct? In your mail on Jan 6, 2002, I thought you mentioned that Linux follows RFC1323 without the modification of [B93]. NetBSD still checks Last.ACK.sent < SEG.SEQ + SEG.LEN. FreeBSD does not check SEG.TSval >= TSrecent. OpenBSD follows the modification of [B93]. I do not know of other implementations and simulators. Since Linux is used widely, is it better to replace the word "all" to something like "many" or "some" ? > [B93] R. T. Braden, TCP Extensions for High Performance: An Update, Internet > Draft, June 1993. http://www.kohala.com/start/tcplw-extensions.txt > [5] Jacobson, V., Bdaden, R. and D. Borman, "TCP Extensions for > High Performance", RFC 1323, May 1992. Regards, Noritoshi Demizu From owner-pilc@grc.nasa.gov Sat Jan 26 22:48:40 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16083 for ; Sat, 26 Jan 2002 22:48:40 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 5492F6412A for ; Sat, 26 Jan 2002 22:48:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA16016 for pilc-outgoing; Sat, 26 Jan 2002 22:42:06 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA16006 for ; Sat, 26 Jan 2002 22:42:05 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id WAA09991 for ; Sat, 26 Jan 2002 22:42:05 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 0E1D6C68F7; Sat, 26 Jan 2002 22:42:05 -0500 (EST) Received: from web11706.mail.yahoo.com(216.136.172.72) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAoMaabX; Sat, 26 Jan 02 22:42:04 -0500 Message-ID: <20020127034203.67019.qmail@web11706.mail.yahoo.com> Received: from [66.137.224.11] by web11706.mail.yahoo.com via HTTP; Sat, 26 Jan 2002 19:42:03 PST Date: Sat, 26 Jan 2002 19:42:03 -0800 (PST) From: Behcet Sarikaya Subject: RE: Re:2.5g/3g ID additions (RE: pilc minutes (corrected)) To: pilc@grc.nasa.gov In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-pilc@grc.nasa.gov Precedence: bulk Dear all, --- Farid Khafizov wrote: > At this point, we can either remove the Bandwidth > Oscillation text from the > draft and > pretend that it may never happen , or we can > specifically state that > Bandwidth Oscillation is a potential problems which > MIGHT show up and > offer TCP optimization techniques. I vote for the former. Regards, --behcet __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com From owner-pilc@grc.nasa.gov Sun Jan 27 07:03:31 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28852 for ; Sun, 27 Jan 2002 07:03:31 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id C97B8C68DE; Sun, 27 Jan 2002 07:00:07 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAA7naWB4; Sun, 27 Jan 02 07:00:07 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA26584 for pilc-outgoing; Sun, 27 Jan 2002 06:53:19 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id GAA26580 for ; Sun, 27 Jan 2002 06:53:18 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id GAA03621 for ; Sun, 27 Jan 2002 06:53:17 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 571AFC68D4; Sun, 27 Jan 2002 06:53:17 -0500 (EST) Received: from smtp.dave.sonera.fi(131.177.130.21) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAZaa4k3; Sun, 27 Jan 02 06:53:17 -0500 Received: from gurtoan1-nb.etela.sonera.fi ([131.177.36.107]:1139 "HELO gurtoan1nb") by inside.dave.sonera.fi with SMTP id ; Sun, 27 Jan 2002 13:53:10 +0200 Message-ID: <001a01c1a729$307ed240$6b24b183@etela.sonera.fi> From: "Andrei Gurtov" To: References: <004401c1a320$9322d8e0$6b24b183@etela.sonera.fi> <20020127074712X.demizu@dd.iij4u.or.jp> Subject: Re: text on use of timestamps for 2.5g3g draft Date: Sun, 27 Jan 2002 13:51:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Noritoshi- > > The original specification of the timestamp option [5] may contain some > > flaws. An update specification [B93] provides the necessary fixes. Ideas in > > this expired draft appear in all current implementations of [5]. ...... > Since Linux is used widely, is it better to replace > the word "all" to something like "many" or "some" ? You are very right here. In fact, after discussing with Alexey Kuznetsov (Linux TCP/IP implementer) and Reiner the issue about this update became more controversial. According to Alexey, older Linux versions implemented the update, but the kernel was reverted back to rfc1323 in version 2.4. The reason is vulnerability to spoofing attacks since this update allows changing TCP state by out-of-window segments. Also, we concluded with Reiner that the 'failure case' for Eifel caused by echoing of old timestamps is in fact a good thing. Hence, I'm more thinking in favor of the original rfc1323 at the moment. Because of that I suggest some neutral text that replaces the quote above. --- The original definition of the timestamp option [5] specifies that duplicate segments below cumulative ACK do not update the cached timestamp value at the receiver. This may lead to overestimating of RTT for retransmitted segments. A possible solution [B93] allows the receiver to use a more recent timestamp from a duplicate segment. However, this suggestion allows for spoofing attacks at the TCP receiver. Therefore, careful consideration is needed in implementing this solution. --- rgds, Andrei From owner-pilc@grc.nasa.gov Mon Jan 28 04:05:01 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20848 for ; Mon, 28 Jan 2002 04:05:00 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 4B6196413F for ; Mon, 28 Jan 2002 04:04:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA09638 for pilc-outgoing; Mon, 28 Jan 2002 03:57:21 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id DAA09633 for ; Mon, 28 Jan 2002 03:57:20 -0500 (EST) From: zhuj@u.washington.edu Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id DAA11742 for ; Mon, 28 Jan 2002 03:57:19 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id 47073C68F8; Mon, 28 Jan 2002 03:57:19 -0500 (EST) Received: from mxout1.cac.washington.edu(140.142.32.5) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAUcaG0W; Mon, 28 Jan 02 03:57:18 -0500 Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0S8vHUC026700 for ; Mon, 28 Jan 2002 00:57:17 -0800 Received: from HOST (cs303-76.spmodem.washington.edu [140.142.171.77]) by mailhost1.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g0S8v39f008530 for ; Mon, 28 Jan 2002 00:57:03 -0800 Date: Mon, 28 Jan 2002 00:57:03 -0800 Message-Id: <200201280857.g0S8v39f008530@mailhost1.u.washington.edu> To: pilc@grc.nasa.gov Subject: new photos from my party! Sender: owner-pilc@grc.nasa.gov Precedence: bulk Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I``````````````````````````````````````````````````````"= end From owner-pilc@grc.nasa.gov Mon Jan 28 09:30:40 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27029 for ; Mon, 28 Jan 2002 09:30:39 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id CAB856418B for ; Mon, 28 Jan 2002 09:29:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA02875 for pilc-outgoing; Mon, 28 Jan 2002 09:22:46 -0500 (EST) Received: from guns.lerc.nasa.gov (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 JAA02869 for ; Mon, 28 Jan 2002 09:22:45 -0500 (EST) Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA92354; Mon, 28 Jan 2002 09:22:38 -0500 (EST) Message-Id: <200201281422.JAA92354@guns.lerc.nasa.gov> To: pilc@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: pilc: archive busted, but now fixed Organization: BBN Technologies/NASA GRC Song-of-the-Day: Paradise City Date: Mon, 28 Jan 2002 09:22:38 -0500 Sender: owner-pilc@grc.nasa.gov Precedence: bulk Folks- The pilc archive has been busted for a while. I believe that it is now fixed. I included all the messages that were initially skipped and all new messages should be archived automatically. This will be the test... Please let em know if you notice any further issues. allman --- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ From owner-pilc@grc.nasa.gov Mon Jan 28 18:27:51 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11092 for ; Mon, 28 Jan 2002 18:27:51 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id E1F2DC6991; Mon, 28 Jan 2002 18:27:47 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAFraiJp; Mon, 28 Jan 02 18:27:47 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02494 for pilc-outgoing; Mon, 28 Jan 2002 18:21:01 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02490 for ; Mon, 28 Jan 2002 18:21:00 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id SAA26874 for ; Mon, 28 Jan 2002 18:20:59 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 2B872640BA for ; Mon, 28 Jan 2002 18:20:59 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0SNKjr17299; Mon, 28 Jan 2002 17:20:45 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 17:20:45 -0600 Message-ID: From: "Farid Khafizov" To: "'Hiroshi INAMURA'" , "'Aaron Falk'" , pilc@grc.nasa.gov Cc: "Mehmet Yavuz" , "Farid Khafizov" Subject: RE: 2.5g/3g ID revised Bandwidth Oscillation text Date: Mon, 28 Jan 2002 17:20:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A852.7116F880" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A852.7116F880 Content-Type: text/plain; charset="iso-8859-1" Hiroshi et al: Enclosed please find our revised version of Bandwidth Oscillation text for 2.5g/3g ID. Mehmet and I feel strongly that the introduction of the draft should have a statement saying that 2.5g/3g ID is addressing issues of the networks that have not been widely deployed. Therefore, at the time of writing of the draft we can not know all TCP issues related to 3G wireless. Only time will show what they are and how to address them. Some of the recommendations of this text are based on exploratory research. --Farid ---------------------------------------------------------------------------- --------------------------------------------------------------------- 2.7. Bandwidth Oscillation Limited RF spectrum along with high data rate requirement of 2.5G/3G wireless systems necessitates dynamic resource sharing among concurrent data users. Various scheduling mechanisms can be deployed in order to maximize resource utilization. Time division sharing of these resources may result in TCP throughput degradation. Ideally resources are allocated on per needed bases (bandwidth on demand) and released when there is no data to send. However, there could be situations when resources are de-allocated while significant amount of data is still waiting in the queue to be transmitted. For example, if multiple users require large data file transfer at the same time, the system (e.g., the scheduler) may have to repeatedly allocate and de-allocate resources for each user. In this section we refer to periodic allocation and de-allocation of high-speed channel as Bandwidth Oscillation. Bandwidth Oscillation effects such as spurious retransmission were identified elsewhere (e.g., [17]) as throughput degradation factors. There are research studies [n3], which show that in some cases Bandwidth Oscillation can be the single most important factor in reducing throughput. One of the ways of detecting congestion in TCP is RTO expiration. RTO computation algorithm [32] was designed to follow closely round trip time (RTT), but is known to work poorly when delay variance is high [11]. When a user has high bandwidth (i.e., low RTT), if resources are allocated for a sufficiently long time, RTO converges to RTT. When resources are released, suddenly RTT increases and low RTO expires forcing TCP into the Slow Start state, while actually none of the TCP segments were lost. For fixed TCP parameters the achievable throughput depends on the pattern of resource allocation. When the frequency of resource allocation and de-allocation is sufficiently high, there is no throughput degradation. However, increasing frequency of resource allocation/de-allocation may come at the expense of increased signaling, and, therefore, may not be desirable in systems which have interference limited capacity. Standards for 3G wireless technologies [n1, n2] provide other mechanisms that can be used to combat adverse effects of Bandwidth Oscillation. It is the consensus of the PILC WG that the best approach for avoiding adverse effects of Bandwidth Oscillation is proper wireless sub-network design [11]. In systems that do experience bandwidth oscillation, one can control throughput degradation by optimizing TCP parameters [n3]. One obvious method is to adjust computed RTO value (or configure appropriately the minimum RTO value) at sending TCP. This technique, however, can not be recommended as a practical solution. Experiments have shown that RTO algorithm implementation compliant with RFC2988 [32] (e.g., minimum RTO=1 sec and initial RTO=3 sec) reduce number of spurious re-transmissions. Although RTO timer management specified in RFC2988 is not mandatory, implementation of retransmission timer restart when an ACK is received (section 5.3 of RFC2988) will further reduce (or even eliminate) spurious retransmissions. Secondary effects, such as TCP segment loss, in combination with Bandwidth Oscillation may not allow avoiding all spurious re-transmissions. Analysis of RTO algorithm along with an alternative (Eifel) algorithm are presented in [17]. Eifel algorithm requires timestamp option and at least one RTO expiration before TCP "learns" that retransmission was not necessary. D-SACK option [26] also allows TCP sender to detect spurious RTO expirations. Enabling timestamp option enables increased RTT sampling which can reduce spurious re-transmissions due to Bandwidth Oscillation. Other options that could reduce spurious RTO expirations due to Bandwidth Oscillation are increase CWND and reduced delay ACK timer at Receiving TCP to < 100 ms (however, this technique may have side effects in case bandwidth is limited in the opposite direction). [n1] 3GPP TS 25.3xx, UMTS MAC and RLC Protocol Specifications, 2001, ftp://ftp.3gpp.org/specs/latest/R1999/ [n2] TIA/EIA/IS-2000.5-A, "Upper Layer (Layer 3) Signaling Standard for cdma2000 Spread Spectrum Systems", March, 2000 [n3] F.Khafizov, M.Yavuz, "Running TCP over IS-2000", to appear in Proc. of IEEE ICC 2002 ------_=_NextPart_001_01C1A852.7116F880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 2.5g/3g ID revised Bandwidth Oscillation text

Hiroshi et = al:

Enclosed = please find our revised version of Bandwidth Oscillation text for = 2.5g/3g ID.
Mehmet and = I feel strongly that the introduction of the draft should have a = statement saying that
2.5g/3g ID = is addressing issues of the networks that have not been widely = deployed.
Therefore, = at the time of writing of the draft we can not know all TCP issues = related to 3G wireless.
Only time = will show what they are and how to address them. Some of the = recommendations
of this = text are based on exploratory research.

--Farid

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

2.7. = Bandwidth Oscillation

Limited RF = spectrum along with high data rate requirement of 2.5G/3G wireless = systems necessitates dynamic resource sharing among concurrent data = users. Various scheduling mechanisms can be deployed in order to = maximize resource utilization. Time division sharing of these resources = may result in TCP throughput degradation. Ideally resources are = allocated on per needed bases (bandwidth on demand) and released when = there is no data to send. However, there could be situations when = resources are de-allocated while significant amount of data is still = waiting in the queue to be transmitted. For example, if multiple users = require large data file transfer at the same time, the system (e.g., = the scheduler) may have to repeatedly allocate and de-allocate = resources for each user. In this section we refer to periodic = allocation and de-allocation of high-speed channel as Bandwidth = Oscillation. Bandwidth Oscillation effects such as spurious = retransmission were identified elsewhere (e.g., [17]) as throughput = degradation factors. There are research studies [n3], which show that = in some cases Bandwidth Oscillation can be the single most important = factor in reducing throughput.

One of the = ways of detecting congestion in TCP is RTO expiration. RTO computation = algorithm [32] was designed to follow closely round trip time (RTT), = but is known to work poorly when delay variance is high [11]. When a = user has high bandwidth (i.e., low RTT), if resources are allocated for = a sufficiently long time, RTO converges to RTT. When resources are = released, suddenly RTT increases and low RTO expires forcing TCP into = the Slow Start state, while actually none of the TCP segments were = lost.

For fixed = TCP parameters the achievable throughput depends on the pattern of = resource allocation. When the frequency of resource allocation and = de-allocation is sufficiently high, there is no throughput degradation. = However, increasing frequency of resource allocation/de-allocation may = come at the expense of increased signaling, and, therefore, may not be = desirable in systems which have interference limited capacity. = Standards for 3G wireless technologies [n1, n2] provide other = mechanisms that can be used to combat adverse effects of Bandwidth = Oscillation. It is the consensus of the PILC WG that the best approach = for avoiding adverse effects of Bandwidth Oscillation is proper = wireless sub-network design [11].

In systems = that do experience bandwidth oscillation, one can control throughput = degradation by optimizing TCP parameters [n3]. One obvious method is to = adjust computed RTO value (or configure appropriately the minimum RTO = value) at sending TCP. This technique, however, can not be recommended = as a practical solution. Experiments have shown that RTO algorithm = implementation compliant with RFC2988 [32] (e.g., minimum RTO=3D1 sec = and initial RTO=3D3 sec) reduce number of spurious re-transmissions. = Although RTO timer management specified in RFC2988 is not mandatory, = implementation of retransmission timer restart when an ACK is received = (section 5.3 of RFC2988) will further reduce (or even eliminate) = spurious retransmissions. Secondary effects, such as TCP segment loss, = in combination with Bandwidth Oscillation may not allow avoiding all = spurious re-transmissions.

Analysis of = RTO algorithm along with an alternative (Eifel) algorithm are presented = in [17]. Eifel algorithm requires timestamp option and at least one RTO = expiration before TCP "learns" that retransmission was not = necessary. D-SACK option [26] also allows TCP sender to detect spurious = RTO expirations. Enabling timestamp option enables increased RTT = sampling which can reduce spurious re-transmissions due to Bandwidth = Oscillation. Other options that could reduce spurious RTO expirations = due to Bandwidth Oscillation are increase CWND and reduced delay ACK = timer at Receiving TCP to < 100 ms (however, this technique may have = side effects in case bandwidth is limited in the opposite = direction).



[n1] 3GPP = TS 25.3xx, UMTS MAC and RLC Protocol Specifications, 2001, ftp://ftp.3gpp.org/specs/latest/R1999/
[n2] = TIA/EIA/IS-2000.5-A, "Upper Layer (Layer 3) Signaling Standard for = cdma2000 Spread Spectrum Systems", March, 2000
[n3] = F.Khafizov, M.Yavuz, "Running TCP over IS-2000", to appear in = Proc. of IEEE ICC 2002


------_=_NextPart_001_01C1A852.7116F880-- From owner-pilc@grc.nasa.gov Tue Jan 29 12:22:56 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10092 for ; Tue, 29 Jan 2002 12:22:55 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id A3D02C69D0; Tue, 29 Jan 2002 12:20:15 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov(139.88.112.33) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAAZkaiTO; Tue, 29 Jan 02 12:20:15 -0500 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA00729 for pilc-outgoing; Tue, 29 Jan 2002 12:13:28 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA00719 for ; Tue, 29 Jan 2002 12:13:27 -0500 (EST) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA00452 for ; Tue, 29 Jan 2002 12:13:26 -0500 (EST) Received: by seraph2.grc.nasa.gov (Postfix, from userid 5) id EDB6EC68F3; Tue, 29 Jan 2002 12:13:25 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com(47.103.122.112) by seraph2.grc.nasa.gov via csmap (V6.0) id srcAAANgaaOM; Tue, 29 Jan 02 12:13:25 -0500 Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0THDHr26083; Tue, 29 Jan 2002 11:13:17 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 11:13:17 -0600 Message-ID: From: "Farid Khafizov" To: "'Aaron Falk'" , "'pilc@grc.nasa.gov'" , "'Hiroshi INAMURA'" Cc: "Mehmet Yavuz" Subject: RE: 2.5g/3g ID additions (RE: pilc minutes (corrected)) Date: Tue, 29 Jan 2002 11:13:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A8E8.3D4E8680" Sender: owner-pilc@grc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A8E8.3D4E8680 Content-Type: text/plain Aaron: > What is a Packet Data Serving Node? Description of PDSN can be mentioned in the upcoming section "2.7.2 CDMA2000". Packet Data Service Node (PDSN) is a node connecting cdma2000 wireless sub-network to Packet Data Network (PDN). Similar to GGSN (Serving GPRS Support node) in UMTS, it can terminate PPP. Earlier versions of this draft had simplified protocol stack for UMTS. What was the reason for removing it? > per Mark: DSACK helps here too, no? you are right. We added a sentence in Bandwidth Oscillation text saying that DSACK helps. --Farid > -----Original Message----- > From: Aaron Falk [SMTP:falk@ISI.EDU] > Sent: Thursday, January 17, 2002 5:56 PM > To: Khafizov, Farid [RICH2:2N51:EXCH] > Cc: 'pilc@grc.nasa.gov'; 'Hiroshi INAMURA'; Yavuz, Mehmet > [RICH2:2N51:EXCH] > Subject: Re: 2.5g/3g ID additions (RE: pilc minutes (corrected)) > > > 1. Disabling Van Jacobson TCP/IP Header Compression > > > > Van Jacobson TCP/IP header compression (VJC) algorithm [35] is > negotiated > > between peer PPP layers. In CDMA2000 networks it could be implemented > > between the Mobile Terminal Equipment, such as laptop computer, and the > > Packet Data Serving Node. What is a Packet Data Serving Node? > > > The algorithm was designed to increase > > application layer throughput by reducing packetization overhead [11]. > For > > TCP segment size of 1000 Bytes, enabling VJC increases throughput by > > about 4%, if there is no packet loss. > > > > > > > > > 2. Bandwidth Oscillation > > > > > > > > > Analysis of RTO algorithm along with an alternative (Eifel) algorithm > are > > presented in [17]. > > per Mark: DSACK helps here too, no? > > > Eifel algorithm requires timestamp option and at least > > one RTO expiration before TCP "learns" that retransmission was not > > necessary. Enabling timestamp option enables increased RTT sampling > which > > can reduce spurious re-transmissions due to Bandwidth Oscillation. Other > > options that could reduce spurious re-transmissions due to Bandwidth > > Oscillation are increase CWND and reduce delay ACK timer at Receiving > TCP > > to < 100 ms (however, this technique may have side effects in case > > bandwidth is limited in the opposite direction). > > > > > > > --aaron ------_=_NextPart_001_01C1A8E8.3D4E8680 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: 2.5g/3g ID additions (RE: pilc minutes (corrected))

Aaron: =

> What is a Packet Data Serving = Node?

Description = of PDSN can be mentioned in the upcoming section "2.7.2 = CDMA2000".
Packet = Data Service Node (PDSN) is a node connecting cdma2000
wireless = sub-network to Packet Data Network (PDN).
Similar to = GGSN (Serving GPRS Support node) in UMTS, it can terminate PPP.

Earlier = versions of this draft had simplified protocol stack for UMTS.
What was = the reason for removing it?

> per Mark: DSACK helps here too, = no?

you are = right. We added a sentence in Bandwidth Oscillation text saying that = DSACK helps.

--Farid

-----Original Message-----
From:   Aaron Falk [SMTP:falk@ISI.EDU]
Sent:   Thursday, January 17, 2002 5:56 PM
To:     Khafizov, Farid [RICH2:2N51:EXCH]
Cc:     'pilc@grc.nasa.gov'; 'Hiroshi INAMURA'; Yavuz, Mehmet = [RICH2:2N51:EXCH]
Subject:       = Re: 2.5g/3g ID additions (RE: pilc = minutes (corrected))

> 1. Disabling Van Jacobson TCP/IP = Header Compression
>
> Van Jacobson TCP/IP header = compression (VJC) algorithm [35] is negotiated
> between peer PPP layers. In = CDMA2000 networks it could be implemented
> between the Mobile Terminal = Equipment, such as laptop computer, and the
> Packet Data Serving Node. =
 =20
  What is a = Packet Data Serving Node?
 
> The algorithm was designed to = increase
> application layer throughput by = reducing packetization overhead [11]. For
> TCP segment size of 1000 Bytes, = enabling VJC increases throughput by
> about 4%, if there is no packet = loss.
>

<snip>

>
> 2. Bandwidth Oscillation
>

<snip>

>
> Analysis of RTO algorithm along = with an alternative (Eifel) algorithm are
> presented in [17].

per Mark: DSACK helps here too, = no?

> Eifel algorithm requires = timestamp option and at least
> one RTO expiration before TCP = "learns" that retransmission was not
> necessary. Enabling timestamp = option enables increased RTT sampling which
> can reduce spurious = re-transmissions due to Bandwidth Oscillation. Other
> options that could reduce = spurious re-transmissions due to Bandwidth
> Oscillation are increase CWND = and reduce delay ACK timer at Receiving TCP
> to < 100 ms (however, this = technique may have side effects in case
> bandwidth is limited in the = opposite direction).
>
>


--aaron

------_=_NextPart_001_01C1A8E8.3D4E8680-- From owner-pilc@grc.nasa.gov Tue Jan 29 22:24:12 2002 Received: from seraph2.grc.nasa.gov (firewall-user@seraph2.lerc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28777 for ; Tue, 29 Jan 2002 22:24:12 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id B9B77C68D2 for ; Tue, 29 Jan 2002 22:24:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA06836 for pilc-outgoing; Tue, 29 Jan 2002 22:19:01 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA06826 for ; Tue, 29 Jan 2002 22:18:59 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id WAA02070 for ; Tue, 29 Jan 2002 22:18:58 -0500 (EST) Received: from hutmail.com (unknown [211.221.52.246]) by seraph3.grc.nasa.gov (Postfix) with SMTP id BA0F364090 for ; Tue, 29 Jan 2002 22:18:50 -0500 (EST) Reply-To: turbozet@hutmail.com From: Lee To: Subject: (광 고)획기적 홍보데이터입니다. Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 30 Jan 2002 12:16:49 +0900 X-User: 2.6-hkilfmmu-hojlnt-Ffkiq Message-Id: <20020130031850.BA0F364090@seraph3.grc.nasa.gov> Sender: owner-pilc@grc.nasa.gov Precedence: bulk


안녕하십니까? 메일데이터를 저렴한 가격에 드립니다. 관심없으시면 메일을 삭제해 주십시오.
본 메일은 정보통신부 권고사항에 의거하여 제목에 광고라 표시된 메일입니다.
본 내용은 스팸메일의 유형에 아무것도 속하지 않습니다.(피라미드, 행운의편지, 성인관련홍보 등)
또한 각 사이트의 공개게시판에서 임의추출한 것이므로 귀하의 신용정보와 아무런 연관이 없습니다.

프로그램으로 추출하여 작업한 메일데이터의 특징은 다음과 같습니다.
다음우표제? 안심하십시오. 철저한 작업으로 한메일이 없습니다. (한메일 포함된 것도 있음)
중복메일? 안심하십시오. 중복메일이 없습니다. 수신거부에 편리합니다.
통합? 편리하게 사용하시도록 똑같은 개수로 나누었습니다.
가격? 저렴합니다. 비싸지 않습니다.
호환? 한줄에 하나씩, 그리고 TXT로 저장되어 있습니다.
          어떤 프로그램과도 호환가능합니다.

...등등의 장점이 있습니다.
드라마틱한 홍보를 위한 필수데이터! 이런 기회는 다시오지 않습니다.
사이트를 참고해 주십시오. 건전한 용도로 쓰지 않는 분에게 판매하지 않으며,
각종 이용용도를 접수후, 엄선하여 몇분에게만 판매합니다.

come.to/adver  adver.ox.ro
adver.ce.ro      adver.pe.ky

접속이 느리면 adver2.(ce.ro / pe.ky / ox.ro)로 접속해 주십시오.
공지없이 중단되면 adver3, adver4, 5...이렇게 접속하시면 됩니다.
이유없이 사이트를 비방, 방해하는 사람에게 손해배상을 요구합니다.
본 사이트는 회사나 기업이 아닙니다. 오해마시길 바랍니다.
또한 본 메일은 사용자의 편의를 위해 절대 한번이상 발송하지 않습니다.
따라서 수신거부하실 필요가 없습니다.
문의사항 있으시면 메일주십시오.

From owner-pilc@grc.nasa.gov Thu Jan 31 12:41:50 2002 Received: from seraph3.grc.nasa.gov (firewall-user@seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04960 for ; Thu, 31 Jan 2002 12:41:50 -0500 (EST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 7DBA064129 for ; Thu, 31 Jan 2002 12:41:44 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA13903 for pilc-outgoing; Thu, 31 Jan 2002 12:32:32 -0500 (EST) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.lerc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA13898 for ; Thu, 31 Jan 2002 12:32:31 -0500 (EST) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA LeRC 8.9.1.1/8.11.x) with ESMTP id MAA24377 for ; Thu, 31 Jan 2002 12:32:30 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id F2490640CB for ; Thu, 31 Jan 2002 12:32:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04711; Thu, 31 Jan 2002 12:32:23 -0500 (EST) Message-Id: <200201311732.MAA04711@ietf.org> To: IETF-Announce: ; Cc: pilc@grc.nasa.gov From: The IESG SUBJECT: Last Call: TCP Performance Implications of Network Asymmetry to BCP Reply-To: iesg@ietf.org Date: Thu, 31 Jan 2002 12:32:23 -0500 Sender: owner-pilc@grc.nasa.gov Precedence: bulk The IESG has received a request from the Performance Implications of Link Characteristics Working Group to consider TCP Performance Implications of Network Asymmetry as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 14, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pilc-asym-07.txt