From owner-tcpsat@lerc.nasa.gov Mon Jan 8 05:59:55 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29262; Mon, 8 Jan 2001 05:59:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA28947 for tcpsat-outgoing; Mon, 8 Jan 2001 05:12:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA28924; Mon, 8 Jan 2001 05:12:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id FAA15339; Mon, 8 Jan 2001 05:12:35 -0500 Received: from ada.cs.ucy.ac.cy(194.42.7.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015312; Mon, 8 Jan 01 05:12:21 -0500 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id MAA503182; Mon, 8 Jan 2001 12:08:49 +0200 Message-ID: <00ee01c0795d$dd406c00$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , "comm-theory" , , , , , "Conferencesa" , , , , , , , , , "Globecom" , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , , Cc: "Andreas Pitsillides" Subject: INFOCOM 2001 CALL FOR PARTICIPATION Date: Mon, 8 Jan 2001 12:28:45 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E4_01C0796E.8B4F5710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E4_01C0796E.8B4F5710 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit !!! OUR APOLOGIES FOR MULTIPLE COPIES !!! C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska You are invited to join IEEE INFOCOM 2001, the major conference on computer communications and networking. IEEE INFOCOM is celebrating its 20th anniversary in the splendid setting of Anchorage, Alaska, during the week of April 22-26, 2001. This unique event will feature a top quality technical program as well as an equally remarkable social program. Check the conference web site (http://www.ieee-infocom.org/2001) to get details on the technical and social program, travel grants and registration. Here are some of the highlights: TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications Quality of Service (QoS) Support for Broadband Wireless Networks Traffic Engineering in IP/MPLS Networks TCP Congestion Controls: Algorithms and Models Video Over IP Bluetooth and Pervasive Wireless Networking Control and Management for Optical Networks: An IP-Centric Approach Principles of Multicast Protocols and Services PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model TRAVEL GRANTS: Travel assistance to students, post-docs and junior faculty presenting a paper in the conference is available. Application deadline is Jan 15, 2001 CONFERENCE REGISTRATION: The deadline for advance registration is April 2, 2001. On-line registration is possible. Your dinner code is 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. TOURS: Several tours of Alaska's natural treasures are planned. HOTEL REGISTRATION: On-line registration is possible. Please book early to get a room at the Hilton. ------=_NextPart_000_00E4_01C0796E.8B4F5710 Content-Type: text/plain; name="cfpart.txt" Content-Disposition: attachment; filename="cfpart.txt" Content-Transfer-Encoding: quoted-printable C A L L F O R P A R T I C I P A T I O N I E E E I N F O C O M 2 0 0 1 http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska You are invited to join IEEE INFOCOM 2001, the major conference on computer communications and networking. IEEE INFOCOM is celebrating its 20th anniversary in the splendid setting of Anchorage, Alaska, during the week of April 22-26, 2001. This unique event will feature a top quality technical program as well as an equally remarkable social = program. Check the conference web site (http://www.ieee-infocom.org/2001) to get details on the technical and social program, travel grants and registration. Here are some of the highlights: TECHNICAL SESSIONS: 48 technical sessions featuring the latest research and trends in the field of computer communications and netwroking. TUTORIALS: Wireless Home Networks: Technologies and Applications=20 Quality of Service (QoS) Support for Broadband Wireless Networks=20 Traffic Engineering in IP/MPLS Networks=20 TCP Congestion Controls: Algorithms and Models=20 Video Over IP=20 Bluetooth and Pervasive Wireless Networking=20 Control and Management for Optical Networks: An IP-Centric Approach=20 Principles of Multicast Protocols and Services=20 PANELS: All-Optical Networks: Fact or Fiction Next Generation Wireless Networks: Radio, Networking and Applications Modeling of the Shrew: the Quest for a "Model" Network Model TRAVEL GRANTS: Travel assistance to students, post-docs and junior faculty presenting a paper in the conference is available. Application deadline is Jan 15, 2001 CONFERENCE REGISTRATION: The deadline for advance registration=20 is April 2, 2001. On-line registration is possible. Your dinner code is = 530T. Enter this code while registering and you may be a lucky winner of a $100 dinner at INFOCOM 2001. TOURS: Several tours of Alaska's natural treasures are planned. HOTEL REGISTRATION: On-line registration is possible. Please book early to get a room at the Hilton. ------=_NextPart_000_00E4_01C0796E.8B4F5710-- From owner-tcpsat@lerc.nasa.gov Mon Jan 8 10:38:48 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07900; Mon, 8 Jan 2001 10:38:47 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA23015 for tcpsat-outgoing; Mon, 8 Jan 2001 09:54:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA22984 for ; Mon, 8 Jan 2001 09:54:40 -0500 (EST) From: eric.verlind@philips.com Received: by seraph3.lerc.nasa.gov; id JAA16495; Mon, 8 Jan 2001 09:54:38 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016455; Mon, 8 Jan 01 09:54:28 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA07367 for ; Mon, 8 Jan 2001 15:54:21 +0100 (MET) (envelope-from eric.verlind@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma007357; Mon, 8 Jan 01 15:54:21 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA14793 for ; Mon, 8 Jan 2001 15:54:20 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA20829 for ; Mon, 8 Jan 2001 15:54:19 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900014977107; Mon, 8 Jan 2001 16:04:29 +0100 To: Subject: TCP end-to-end Semantics Message-ID: <0056900014977107000002L072*@MHS> Date: Mon, 8 Jan 2001 16:04:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 01/08/01 15:53:43" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id JAA22999 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Can somebody shed some light on a few things pleas please? 1. People claim that TCP semantics is not violated if TCP acks are "spoofed", as long as the initial 3-way handshake and the FIN are respected. Seems strange to me. Namely, the sending TCP will have lost the data because of spoofing and falsely assumes it has arrived if the link breaks down, i.e. there is a "false positive". Who says the sender wants to do a FIN, it could just stop and will notice nothing about the break down. 2. What if I used large windows, but spoofed the initial SYN/ACK, i.e. the opposite. This will speed up small transfers, because there is no wait for the handshake to complete. The other side can not open the socket, the first data transfer will simply fail, so no false positives here? Good idea or not? 3. What guarantee does an application have anyway. If I do a send in TCP, the data goes into TCP's buffer without error and is handled asynchronously, which could fail. How rock-solid is end-to-end reliability? Thank you, Eric Verlind SW Architect From owner-tcpsat@lerc.nasa.gov Mon Jan 8 11:07:29 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08942; Mon, 8 Jan 2001 11:07:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05604 for tcpsat-outgoing; Mon, 8 Jan 2001 10:28:50 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA05522 for ; Mon, 8 Jan 2001 10:28:46 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA22214; Mon, 8 Jan 2001 10:28:44 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022117; Mon, 8 Jan 01 10:28:03 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id KAA50616; Mon, 8 Jan 2001 10:27:58 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101081527.KAA50616@aland.bbn.com> To: eric.verlind@philips.com cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Mon, 08 Jan 2001 16:04:29 +0100." <0056900014977107000002L072*@MHS> Date: Mon, 08 Jan 2001 10:27:58 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <0056900014977107000002L072*@MHS>, eric.verlind@philips.com writes: >1. >People claim that TCP semantics is not violated if TCP acks are "spoofed", as >long as the initial 3-way handshake and the FIN are respected. >Seems strange to me. Namely, the sending TCP will have lost the data because o >f spoofing and falsely assumes it has arrived if the link breaks down, i.e. t >here is a "false positive". Who says the sender wants to do a FIN, it could j >ust stop and will >notice nothing about the break down. You're right, spoofing ACKs does violate TCP semantics. Some folks argue that if their intermediate node, that spoofs ACKs, also buffers data then you're safe, but they're wrong -- as the intermediate could fail. >2. >What if I used large windows, but spoofed the initial SYN/ACK, i.e. the opposi >te. This will speed up small transfers, because there is no wait for the hand >shake to complete. The other side can not open the socket, the first data tra >nsfer will simply >fail, so no false positives here? Good idea or not? Well it doesn't violate semantics in the same way -- if the other end does not open the connection then either (a) you'll get a RST and the connection will fail or (b) you'll retransmit several times and the connection will fail. It will never claim that data is delivered that was not. >3. >What guarantee does an application have anyway. If I do a send in TCP, the dat >a goes into TCP's buffer without error and is handled asynchronously, which c >ould fail. How rock-solid is end-to-end reliability? If you linger on the close (such that all data is acknowledged before your socket closes -- and assuming no ack spoofing) then you'll have a firm guarantee that your data reached the remote system. This guarantee, however, is only for the end system -- it does not say the end application received the data (it may never read it). Craig From owner-tcpsat@lerc.nasa.gov Mon Jan 8 17:53:47 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18168; Mon, 8 Jan 2001 17:53:40 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA05409 for tcpsat-outgoing; Mon, 8 Jan 2001 17:07:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA05357 for ; Mon, 8 Jan 2001 17:07:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA22851; Mon, 8 Jan 2001 17:07:31 -0500 Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022739; Mon, 8 Jan 01 17:07:03 -0500 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id XAA74699; Mon, 8 Jan 2001 23:07:32 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200101082207.XAA74699@info.iet.unipi.it> Subject: Re: TCP end-to-end Semantics In-Reply-To: <200101081527.KAA50616@aland.bbn.com> from Craig Partridge at "Jan 8, 2001 10:27:58 am" To: Craig Partridge Date: Mon, 8 Jan 2001 23:07:32 +0100 (CET) CC: eric.verlind@philips.com, tcpsat@grc.nasa.gov X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit >>1. >>People claim that TCP semantics is not violated if TCP acks are "spoofed", as ... > You're right, spoofing ACKs does violate TCP semantics. Some folks argue > that if their intermediate node, that spoofs ACKs, also buffers data then > you're safe, but they're wrong -- as the intermediate could fail. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ how is this different from what you say next > guarantee that your data reached the remote system. This guarantee, however, > is only for the end system -- it does not say the end application received > the data (it may never read it). i.e. how is your "remote system" different from any intermediate in the way -- you may have a better chance of detecting its failure, but no guarantees, anyways. The receiving end could well be an on-board CPU+memory on the network card (for however a bad idea this can be) and go equally unnoticed. Maybe we could say some intermediate device violates semantics iff there is a procedure that deterministically (or with very high probability) makes it behave differently from an implementation on the end-system ? cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- From owner-tcpsat@lerc.nasa.gov Mon Jan 8 19:09:40 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18921; Mon, 8 Jan 2001 19:09:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA18107 for tcpsat-outgoing; Mon, 8 Jan 2001 18:33:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA18054 for ; Mon, 8 Jan 2001 18:32:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA05323; Mon, 8 Jan 2001 18:32:55 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005242; Mon, 8 Jan 01 18:31:56 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id SAA52978; Mon, 8 Jan 2001 18:31:51 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101082331.SAA52978@aland.bbn.com> To: Luigi Rizzo cc: Craig Partridge , eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Mon, 08 Jan 2001 23:07:32 +0100." <200101082207.XAA74699@info.iet.unipi.it> Date: Mon, 08 Jan 2001 18:31:51 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes: >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue >> that if their intermediate node, that spoofs ACKs, also buffers data then >> you're safe, but they're wrong -- as the intermediate could fail. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >how is this different from what you say next > >> guarantee that your data reached the remote system. This guarantee, however >, >> is only for the end system -- it does not say the end application received >> the data (it may never read it). > >i.e. how is your "remote system" different from any intermediate in the >way -- you may have a better chance of detecting its failure, but no >guarantees, anyways. The receiving end could well be an on-board CPU+memory >on the network card (for however a bad idea this can be) and go >equally unnoticed. > >Maybe we could say some intermediate device violates semantics iff >there is a procedure that deterministically (or with very high >probability) makes it behave differently from an implementation on >the end-system ? Hi Luigi: That's an astute point, thanks! The answer is that I view the probability of failure as part of the TCP semantics. That is, TCP says it provides connectivity between two end points ("reliable inter-process communications between pairs of processes in host computers..."). My view is that means that TCP's host-to-host behavior is a function solely of the two end points. (One could also say this view is a logical consequence of the simple dumb network approach, of which IP is an example). So my second example, where the receiver could fail to deliver the data after ACKing it, in a normal TCP is solely a function of the receiver suffering one of a (fairly short) list of errors. Adding an intermediary doesn't change the receiver probability, but adds the probability of the failure of the intermediary. So the probability of failure is now different from what it was if just the two hosts were involved. Thanks for an insightful question and I'll be interested to know what you think of my reply :-) Craig From owner-tcpsat@lerc.nasa.gov Mon Jan 8 23:52:22 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23391; Mon, 8 Jan 2001 23:52:21 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA11210 for tcpsat-outgoing; Mon, 8 Jan 2001 23:14:48 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA11181 for ; Mon, 8 Jan 2001 23:14:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA03728; Mon, 8 Jan 2001 23:14:43 -0500 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003716; Mon, 8 Jan 01 23:14:40 -0500 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id UAA14456; Mon, 8 Jan 2001 20:14:28 -0800 (PST) Date: Mon, 8 Jan 2001 20:14:28 -0800 (PST) From: Alhussein Abouzeid To: Craig Partridge cc: Luigi Rizzo , eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <200101082331.SAA52978@aland.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk What is a system? and what are "TCP end-to-end semantics"? Where are they defined? I think saying remote and intermediate "system" does more harm than good in clarifying the issue. I do not think that the failure of the receiver to deliver data to the application after ACKing it is a problem of the transport layer anyway. If we accept layering, and we accept the end-to-end philosophy, then the guarantee that a transport protocol provides is between the two _transport_ end points not the two _application_ end points. Right? Now, there can be two ways to treat the end-to-end argument. If you (or your application) are a hardliner and require that the transport protocol ACK packets only if they are received at the destination, then spoofing is a violation. If, on the other hand, you apply the end-to-end on a "session" basis, i.e. a transport protocol will only terminate the session when all packets of the session are received, then, in principle, one can argue that there exists an intermediary spoofer (e.g. that doesn't complete the handshake except after the reception of all packets at the receiver) that will not be violating the semantics, even if it plays with the data packets/ACKs to its convenience during the course of the session. In other words, it depends on whether you define a "per packet" or a "per session" semantics. I've looked, and I failed to find any substantial study on how this affects the application layer. I think that it will generally depend on the application. My 6 piastres (= 2 cents) -Hussein. On Mon, 8 Jan 2001, Craig Partridge wrote: > > In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes: > > >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue > >> that if their intermediate node, that spoofs ACKs, also buffers data then > >> you're safe, but they're wrong -- as the intermediate could fail. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >how is this different from what you say next > > > >> guarantee that your data reached the remote system. This guarantee, however > >, > >> is only for the end system -- it does not say the end application received > >> the data (it may never read it). > > > >i.e. how is your "remote system" different from any intermediate in the > >way -- you may have a better chance of detecting its failure, but no > >guarantees, anyways. The receiving end could well be an on-board CPU+memory > >on the network card (for however a bad idea this can be) and go > >equally unnoticed. > > > >Maybe we could say some intermediate device violates semantics iff > >there is a procedure that deterministically (or with very high > >probability) makes it behave differently from an implementation on > >the end-system ? > > Hi Luigi: > > That's an astute point, thanks! > > The answer is that I view the probability of failure as part of the TCP > semantics. That is, TCP says it provides connectivity between two end > points ("reliable inter-process communications between pairs of > processes in host computers..."). > > My view is that means that TCP's host-to-host behavior is a function solely > of the two end points. (One could also say this view is a logical consequence > of the simple dumb network approach, of which IP is an example). > > So my second example, where the receiver could fail to deliver the data after > ACKing it, in a normal TCP is solely a function of the receiver suffering > one of a (fairly short) list of errors. Adding an intermediary doesn't > change the receiver probability, but adds the probability of the failure > of the intermediary. So the probability of failure is now different from > what it was if just the two hosts were involved. > > Thanks for an insightful question and I'll be interested to know what > you think of my reply :-) > > Craig > From owner-tcpsat@lerc.nasa.gov Tue Jan 9 05:19:40 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08299; Tue, 9 Jan 2001 05:19:40 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA11434 for tcpsat-outgoing; Tue, 9 Jan 2001 04:37:25 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA11310 for ; Tue, 9 Jan 2001 04:37:20 -0500 (EST) From: eric.verlind@philips.com Received: by seraph3.lerc.nasa.gov; id EAA06349; Tue, 9 Jan 2001 04:37:15 -0500 Received: from gw-nl4.philips.com(212.153.190.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006252; Tue, 9 Jan 01 04:36:28 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id KAA07973; Tue, 9 Jan 2001 10:36:20 +0100 (MET) (envelope-from eric.verlind@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma007969; Tue, 9 Jan 01 10:36:20 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA19788; Tue, 9 Jan 2001 10:36:19 +0100 (MET) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA19314; Tue, 9 Jan 2001 10:36:18 +0100 (MET) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900014999241; Tue, 9 Jan 2001 10:46:30 +0100 To: Cc: , , , Subject: Re: TCP end-to-end Semantics Message-ID: <0056900014999241000002L012*@MHS> Date: Tue, 9 Jan 2001 10:46:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 01/09/01 10:35:47" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id EAA11393 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi, What you say is probably true. However I am puzzled about the consequences of the remark on "session". So the spoofer TCP I am talking to happily sends me ACKs and I think: fine, let's free those buffers and get rid of the old application data. A few MByte ahead then the spoofer finds out that something is wrong. How do I know where things went wrong? Well yes, I know that something is wrong with the session and that's all. Some people argue that without spoofing things can go wrong anyway from the application point of view. They are right. However, two remarks on that: 1. Principal: Applications should in some way "surround" their transfers with means to guarantee that a transfer as a whole succeeds, i.e. end-to-end communication at the appl. level. For instance, after a file transfer, the correspondent should respond with "Thanx buddy, I've correctly received 4711 bytes from you". 2. Practical: How often do things go wrong normally? I am afraid that many application builders have the perception that TCP is 100% rock-hard reliable and for that they do not make their applications reliable "'cos TCP does that already". My fear: * normally, things can indeed go wrong but this is principal/theoretical rather than practical. The chances of failure are so low that -although it happens from time to time-, nobody is bothered by it: if I give it to TCP, it will just arrive. If it goes wrong, I might perceive this as a BIG exception, i.e. a system failure or strange quirk that I can live with because it happens so rarely. * the question is whether spoofing changes things in this respect. If "failure" becomes more than an exception but is perceived as a system weakness, that undermines my feeling that the system is trustworthy and rightly so. Can somebody come up with some examples of practical, relevant applications that will fail under spoofing? Any practical experiences? - I guess FTP does acking at the application level, but I'd have to check its rfc. - Web browsing is cached and proxied anyway, as somebody state rightfully. - What about http file downloads/uploads (other than web pages): any practical problem? Who can give me a feeling? Thanks, Eric Verlind Software Architect hussein@ee.washington.edu on 01/09/2001 05:17:40 AM To: craig@aland.bbn.com@SMTP cc: tcpsat@grc.nasa.gov@SMTP Eric Verlind/HAS/BE/PHILIPS@EMEA1 luigi@info.iet.unipi.it@SMTP Subject: Re: TCP end-to-end Semantics Classification: Restricted What is a system? and what are "TCP end-to-end semantics"? Where are they defined? I think saying remote and intermediate "system" does more harm than good in clarifying the issue. I do not think that the failure of the receiver to deliver data to the application after ACKing it is a problem of the transport layer anyway. If we accept layering, and we accept the end-to-end philosophy, then the guarantee that a transport protocol provides is between the two _transport_ end points not the two _application_ end points. Right? Now, there can be two ways to treat the end-to-end argument. If you (or your application) are a hardliner and require that the transport protocol ACK packets only if they are received at the destination, then spoofing is a violation. If, on the other hand, you apply the end-to-end on a "session" basis, i.e. a transport protocol will only terminate the session when all packets of the session are received, then, in principle, one can argue that there exists an intermediary spoofer (e.g. that doesn't complete the handshake except after the reception of all packets at the receiver) that will not be violating the semantics, even if it plays with the data packets/ACKs to its convenience during the course of the session. In other words, it depends on whether you define a "per packet" or a "per session" semantics. I've looked, and I failed to find any substantial study on how this affects the application layer. I think that it will generally depend on the application. My 6 piastres (= 2 cents) -Hussein. On Mon, 8 Jan 2001, Craig Partridge wrote: > > In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes: > > >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue > >> that if their intermediate node, that spoofs ACKs, also buffers data then > >> you're safe, but they're wrong -- as the intermediate could fail. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >how is this different from what you say next > > > >> guarantee that your data reached the remote system. This guarantee, however > >, > >> is only for the end system -- it does not say the end application received > >> the data (it may never read it). > > > >i.e. how is your "remote system" different from any intermediate in the > >way -- you may have a better chance of detecting its failure, but no > >guarantees, anyways. The receiving end could well be an on-board CPU+memory > >on the network card (for however a bad idea this can be) and go > >equally unnoticed. > > > >Maybe we could say some intermediate device violates semantics iff > >there is a procedure that deterministically (or with very high > >probability) makes it behave differently from an implementation on > >the end-system ? > > Hi Luigi: > > That's an astute point, thanks! > > The answer is that I view the probability of failure as part of the TCP > semantics. That is, TCP says it provides connectivity between two end > points ("reliable inter-process communications between pairs of > processes in host computers..."). > > My view is that means that TCP's host-to-host behavior is a function solely > of the two end points. (One could also say this view is a logical consequence > of the simple dumb network approach, of which IP is an example). > > So my second example, where the receiver could fail to deliver the data after > ACKing it, in a normal TCP is solely a function of the receiver suffering > one of a (fairly short) list of errors. Adding an intermediary doesn't > change the receiver probability, but adds the probability of the failure > of the intermediary. So the probability of failure is now different from > what it was if just the two hosts were involved. > > Thanks for an insightful question and I'll be interested to know what > you think of my reply :-) > > Craig > From owner-tcpsat@lerc.nasa.gov Tue Jan 9 05:26:03 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08350; Tue, 9 Jan 2001 05:26:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA12458 for tcpsat-outgoing; Tue, 9 Jan 2001 04:54:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA12437 for ; Tue, 9 Jan 2001 04:54:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA07897; Tue, 9 Jan 2001 04:54:32 -0500 Received: from mail.zrz.tu-berlin.de(130.149.4.15) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007846; Tue, 9 Jan 01 04:53:46 -0500 Received: from mimas.ee.tu-berlin.de ([130.149.49.68]) by mail.zrz.tu-berlin.de with esmtp (exim-3.20) id 14FvTM-0007ZT-00; Tue, 09 Jan 2001 10:53:44 +0100 Received: from ee.tu-berlin.de (morten@localhost [127.0.0.1]) by mimas.ee.TU-Berlin.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id KAA09668; Tue, 9 Jan 2001 10:53:39 +0100 Message-ID: <3A5ADFA3.3BAF25EC@ee.tu-berlin.de> Date: Tue, 09 Jan 2001 10:53:39 +0100 From: Morten Schlaeger Organization: TKN - TU Berlin X-Mailer: Mozilla 4.75 [de] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Alhussein Abouzeid CC: Craig Partridge , Luigi Rizzo , eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id EAA12458 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08350 Some quotation from RFC793: [page 2] "Some computer systems will be connected to networks via front-end computers which house the TCP and internet protocol layers, as well as network specific software. The TCP specification describes an interface to the higher level protocols which appears to be implementable even for the front-end case, as long as a suitable host-to-front end protocol is implemented." [page 8] "The mechanisms of TCP do not preclude implementation of the TCP in a front-end processor. However, in such an implementation, a host-to-front-end protocol must provide the functionality to support the type of TCP-user interface described in this document." I think, we should differentiate between protocol semantic and interface semantic. From an application point of view not the TCP semantic alone is important but also the semantic of the interface the application uses to communicate with the protocol stack. Of course, when the acknowledgments are sent by some intermediate host the meaning of the acknowledgment has changed to some extent. If we would use an application-network interface in which a "write-call" would return only when the data are acknowledged by the peer TCP, then this semantic might have some impact on the application design (although this gives the sender no guarantee that the data was consumed by the destination application). Using the Berkeley socket interface the socket calls to send data return when TCP has accepted the data for delivery (fits into the send-buffer, assuming blocking mode). The application is not informed about the success or failure of delivery. It is even allowed to close the socket after passing some data to the socket. Although I agree, that the crash probability is increased when an intermediate host is used, there is no difference for the application whether the acknowledgments are sent by the destination host or an intermediate host. If it wants to implement a reliable data transfer it must implement its own mechanisms. The only possibility for the application to know about the status of the data delivery is to use the linger option. This option moves the important role to the fin packet, which should not be acknowledged by the intermediate host until all data are received by the final destination host (which still is no guarantee that the data was consumed by the application). I think, Hussein, this goes somehow in the same direction as your per packet and per session semantic definition? Best regards, Morten Alhussein Abouzeid wrote: > > What is a system? and what are "TCP end-to-end semantics"? Where are they > defined? > > I think saying remote and intermediate "system" does more harm > than good in clarifying the issue. > > I do not think that the failure of the receiver to deliver data > to the application after ACKing it is a problem of the transport layer > anyway. If we accept layering, and we accept the end-to-end philosophy, > then the guarantee that a transport protocol provides is between the two > _transport_ end points not the two _application_ end points. Right? > > Now, there can be two ways to treat the end-to-end argument. If you (or > your application) are a hardliner and require that the transport > protocol ACK packets only if they are received at the destination, then > spoofing is a violation. If, on the other hand, you apply the end-to-end > on a "session" basis, i.e. a transport protocol will only terminate the > session when all packets of the session are received, then, in principle, > one can argue that there exists an intermediary spoofer (e.g. that > doesn't complete the handshake except after the reception of all packets > at the receiver) that will not be violating the semantics, even if it > plays with the data packets/ACKs to its convenience during the course of > the session. > > In other words, it depends on whether you define a "per packet" or a "per > session" semantics. I've looked, and I failed to find any substantial > study on how this affects the application layer. I think that it will generally > depend on the application. > > My 6 piastres (= 2 cents) > > -Hussein. > > On Mon, 8 Jan 2001, Craig Partridge wrote: > > > > > In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes: > > > > >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue > > >> that if their intermediate node, that spoofs ACKs, also buffers data then > > >> you're safe, but they're wrong -- as the intermediate could fail. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >how is this different from what you say next > > > > > >> guarantee that your data reached the remote system. This guarantee, however > > >, > > >> is only for the end system -- it does not say the end application received > > >> the data (it may never read it). > > > > > >i.e. how is your "remote system" different from any intermediate in the > > >way -- you may have a better chance of detecting its failure, but no > > >guarantees, anyways. The receiving end could well be an on-board CPU+memory > > >on the network card (for however a bad idea this can be) and go > > >equally unnoticed. > > > > > >Maybe we could say some intermediate device violates semantics iff > > >there is a procedure that deterministically (or with very high > > >probability) makes it behave differently from an implementation on > > >the end-system ? > > > > Hi Luigi: > > > > That's an astute point, thanks! > > > > The answer is that I view the probability of failure as part of the TCP > > semantics. That is, TCP says it provides connectivity between two end > > points ("reliable inter-process communications between pairs of > > processes in host computers..."). > > > > My view is that means that TCP's host-to-host behavior is a function solely > > of the two end points. (One could also say this view is a logical consequence > > of the simple dumb network approach, of which IP is an example). > > > > So my second example, where the receiver could fail to deliver the data after > > ACKing it, in a normal TCP is solely a function of the receiver suffering > > one of a (fairly short) list of errors. Adding an intermediary doesn't > > change the receiver probability, but adds the probability of the failure > > of the intermediary. So the probability of failure is now different from > > what it was if just the two hosts were involved. > > > > Thanks for an insightful question and I'll be interested to know what > > you think of my reply :-) > > > > Craig > > -- ------------------------------------------------------------------------ Morten Schläger Tel.: ++49 (030) 314-23834 Technical University Berlin Fax.: ++49 (030) 314-23818 Telecommunication Networks Group (TKN) morten@ee.TU-Berlin.DE Sekr. FT 5-2/Einsteinufer 25 10587 Berlin, Germany From owner-tcpsat@lerc.nasa.gov Tue Jan 9 11:32:54 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15600; Tue, 9 Jan 2001 11:32:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA26794 for tcpsat-outgoing; Tue, 9 Jan 2001 10:52:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA26696 for ; Tue, 9 Jan 2001 10:52:41 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA23866; Tue, 9 Jan 2001 10:52:36 -0500 Received: from labsun1.iss.comsat.com(134.133.12.61) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023789; Tue, 9 Jan 01 10:52:19 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun1.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f09FpmC27068; Tue, 9 Jan 2001 10:51:49 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f09FplA12716; Tue, 9 Jan 2001 10:51:47 -0500 (EST) Date: Tue, 9 Jan 2001 10:51:47 -0500 (EST) From: Anil Agarwal Message-Id: <200101091551.f09FplA12716@pleiades.ntd.comsat.com> To: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics Cc: craig@aland.bbn.com, eric.verlind@philips.com, hussein@ee.washington.edu, luigi@info.iet.unipi.it Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk All, Here is another way to look at whether "TCP-spoofing" causes violation of end-to-end TCP semantics. This is similar to Hussein's analysis. 1. In a purely, theoretical sense, the answer is YES, as stated by many authors. The spoofer acks packets to the sender that have not been delivered to the destination host. 2. On a more practical plane, things are a little different. Most well-written TCP applications do not assume that if the sender TCP has accepted user data, then the data will get delivered to the receiver with absolute guarantee. To verify end-to-end data delivery, such applications use one of several methods - 1. Close the socket, with the LINGER option enabled, and wait for TCP to finish its FIN echange and to return success/failure indication to the user. 2. Do an application-to-application message exchange to verify whether that all data has been received. This may also be done at intermediate points in the session. 3. Inquire of TCP as to how much of its data has been acknowledged by the peer and use that info. to verify whether data has been delivered to the receiver. It is theoretically possible for applications to inquire of TCP as to how much of its data has been acknowledged by the peer. The TCP RFC does NOT mention this as one of the interface primitives and I don't think there are any standard socket libraries that allow this. 4. Simply close the connection, with the assumption that the data will be successfully delivered with a fairly high probability. Let us assume that the TCP spoofer uses a reliable protocol to deliver packets to the final destination. Let us also assume that the TCP spoofer does not spoof the FIN exchange, i.e., the the spoofer ensures that the FIN exchange finishes successfully only if all sent data is successfully delivered to and acknowledged by both ends. With such a spoofer, one can say that applications that use methods 1 and 2 mentioned above, will not see any difference in "semantics" or end-results, when operating with an intermediate spoofer. Applications that use method 3 will of course be negatively affected. One can presume that there are not many such applications. Applications that use method 4 will not experience any significant change in probability of success or failure, assuming that the spoofer itself has a low probability of failure. Network or destination host failures will affect the probability of failure by the same amount, whether spoofing is used or not. In my humble opinion, TCP spoofing is not as bad as it sometimes sounds! As an aside, there are many other things that a good TCP-spoofer has to do, such as faithfully transfer the values of the some of the TCP header fields such as PUSH, URGENT, checksum and TCP options. We have developed and sell a TCP-spoofer product for use over satellite links. Regards, Anil Agarwal LMGT 22300 Comsat Dr Clarksburg, MD 20871 (301)428-4655 agarwal@ntd.comsat.com From owner-tcpsat@lerc.nasa.gov Tue Jan 9 11:39:12 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15602; Tue, 9 Jan 2001 11:32:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA25445 for tcpsat-outgoing; Tue, 9 Jan 2001 10:48:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA25385 for ; Tue, 9 Jan 2001 10:48:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA23193; Tue, 9 Jan 2001 10:48:24 -0500 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023129; Tue, 9 Jan 01 10:47:47 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA07092 for ; Tue, 9 Jan 2001 07:39:26 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Jan 2001 15:47:44 UT Received: from jheitz-dsl-77.ascend.com (jheitz-dsl-77.ascend.com [134.112.160.77]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA16124 for ; Tue, 9 Jan 2001 07:47:42 -0800 (PST) Received: from eng.ascend.com (localhost [127.0.0.1]) by jheitz-dsl-77.ascend.com (8.8.8+Sun/8.8.8) with ESMTP id HAA02307 for ; Tue, 9 Jan 2001 07:45:37 -0800 (PST) Message-ID: <3A5B3220.FE37CD69@eng.ascend.com> Date: Tue, 09 Jan 2001 07:45:36 -0800 From: Jacob Heitz Reply-To: Jacob Heitz Organization: Lucent Technologies, Internetworking Systems, Software Engineering, Alameda X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I, the application, expect from you, TCP, the following: When my peer application has received all the data I sent in order and uncorrupted AND I have received all the data the peer application has sent to me in order and uncorrupted, I expect a successful Close-Indication from you. If an unrecoverable error occurs, I expect an Error-Indication. It's that simple. The application indicates to TCP that it has no more data to send with a Close-Request. If you, TCP, cannot make that promise, then your usefulness to me is greatly diminished and I need to do my own error detection and correction and may as well use UDP. Alhussein Abouzeid wrote: > > What is a system? and what are "TCP end-to-end semantics"? Where are they > defined? > > I think saying remote and intermediate "system" does more harm > than good in clarifying the issue. > > I do not think that the failure of the receiver to deliver data > to the application after ACKing it is a problem of the transport layer > anyway. If we accept layering, and we accept the end-to-end philosophy, > then the guarantee that a transport protocol provides is between the two > _transport_ end points not the two _application_ end points. Right? > > Now, there can be two ways to treat the end-to-end argument. If you (or > your application) are a hardliner and require that the transport > protocol ACK packets only if they are received at the destination, then > spoofing is a violation. If, on the other hand, you apply the end-to-end > on a "session" basis, i.e. a transport protocol will only terminate the > session when all packets of the session are received, then, in principle, > one can argue that there exists an intermediary spoofer (e.g. that > doesn't complete the handshake except after the reception of all packets > at the receiver) that will not be violating the semantics, even if it > plays with the data packets/ACKs to its convenience during the course of > the session. > > In other words, it depends on whether you define a "per packet" or a "per > session" semantics. I've looked, and I failed to find any substantial > study on how this affects the application layer. I think that it will generally > depend on the application. > > My 6 piastres (= 2 cents) > > -Hussein. > > On Mon, 8 Jan 2001, Craig Partridge wrote: > > > > > In message <200101082207.XAA74699@info.iet.unipi.it>, Luigi Rizzo writes: > > > > >> You're right, spoofing ACKs does violate TCP semantics. Some folks argue > > >> that if their intermediate node, that spoofs ACKs, also buffers data then > > >> you're safe, but they're wrong -- as the intermediate could fail. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > >how is this different from what you say next > > > > > >> guarantee that your data reached the remote system. This guarantee, however > > >, > > >> is only for the end system -- it does not say the end application received > > >> the data (it may never read it). > > > > > >i.e. how is your "remote system" different from any intermediate in the > > >way -- you may have a better chance of detecting its failure, but no > > >guarantees, anyways. The receiving end could well be an on-board CPU+memory > > >on the network card (for however a bad idea this can be) and go > > >equally unnoticed. > > > > > >Maybe we could say some intermediate device violates semantics iff > > >there is a procedure that deterministically (or with very high > > >probability) makes it behave differently from an implementation on > > >the end-system ? > > > > Hi Luigi: > > > > That's an astute point, thanks! > > > > The answer is that I view the probability of failure as part of the TCP > > semantics. That is, TCP says it provides connectivity between two end > > points ("reliable inter-process communications between pairs of > > processes in host computers..."). > > > > My view is that means that TCP's host-to-host behavior is a function solely > > of the two end points. (One could also say this view is a logical consequence > > of the simple dumb network approach, of which IP is an example). > > > > So my second example, where the receiver could fail to deliver the data after > > ACKing it, in a normal TCP is solely a function of the receiver suffering > > one of a (fairly short) list of errors. Adding an intermediary doesn't > > change the receiver probability, but adds the probability of the failure > > of the intermediary. So the probability of failure is now different from > > what it was if just the two hosts were involved. > > > > Thanks for an insightful question and I'll be interested to know what > > you think of my reply :-) > > > > Craig > > From owner-tcpsat@lerc.nasa.gov Tue Jan 9 13:09:12 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18758; Tue, 9 Jan 2001 13:09:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA25772 for tcpsat-outgoing; Tue, 9 Jan 2001 12:29:02 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA25686 for ; Tue, 9 Jan 2001 12:28:58 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA08667; Tue, 9 Jan 2001 12:28:53 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008596; Tue, 9 Jan 01 12:28:19 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id MAA55198; Tue, 9 Jan 2001 12:28:12 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101091728.MAA55198@aland.bbn.com> To: Anil Agarwal cc: tcpsat@grc.nasa.gov, craig@aland.bbn.com, eric.verlind@philips.com, hussein@ee.washington.edu, luigi@info.iet.unipi.it Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Tue, 09 Jan 2001 10:51:47 EST." <200101091551.f09FplA12716@pleiades.ntd.comsat.com> Date: Tue, 09 Jan 2001 12:28:12 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <200101091551.f09FplA12716@pleiades.ntd.comsat.com>, Anil Agarwal wr ites: >2. On a more practical plane, things are a little different. > > Most well-written TCP applications do not assume that if the sender > TCP has accepted user data, then the data will get delivered to the > receiver with absolute guarantee. To verify end-to-end data delivery, > such applications use one of several methods - > > 1. Close the socket, with the LINGER option enabled, and wait for TCP > to finish its FIN echange and to return success/failure indication > to the user. Which may fail when spoofing is done. If the RTT between the sender and the spoofing node is sharply less (and less variable) than the RTT between the sender and the receiver, it is conceivable (esp. if the real RTT includes a satellite delay) that the sender will multiply retransmit and finally time out the FIN. The end result is a transfer that has occurred, but due to spoofing the sender deems to have failed and may retry (many times!). > 2. Do an application-to-application message exchange to verify whether > that all data has been received. This may also be done at intermediate > points in the session. This works, but is also subject to the timeout problem above. > ... > > With such a spoofer, one can say that applications that use methods 1 and 2 > mentioned above, will not see any difference in "semantics" or end-results, > when operating with an intermediate spoofer. I think I just illustrated a case where this is not true. > Applications that use method 4 will not experience any significant change > in probability of success or failure, assuming that the spoofer itself > has a low probability of failure. Network or destination host failures > will affect the probability of failure by the same amount, whether spoofing > is used or not. By this logic if my chance of failure is originally .001 and I add a spoofer with a chance of failure of 0.001, I should not be distressed that my chance of failure has roughly doubled to (0.002)? Craig From owner-tcpsat@lerc.nasa.gov Tue Jan 9 13:26:35 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18995; Tue, 9 Jan 2001 13:26:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA01718 for tcpsat-outgoing; Tue, 9 Jan 2001 12:49:23 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA01686 for ; Tue, 9 Jan 2001 12:49:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA11693; Tue, 9 Jan 2001 12:49:18 -0500 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011554; Tue, 9 Jan 01 12:48:50 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA15571; Tue, 9 Jan 2001 09:48:42 -0800 (PST) Message-ID: <3A5B4E7D.234AFA1A@isi.edu> Date: Tue, 09 Jan 2001 09:46:37 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: eric.verlind@philips.com CC: hussein@ee.washington.edu, dc@mentat.com, luigi@info.iet.unipi.it, tcpsat@grc.nasa.gov, craig@aland.bbn.com Subject: Re: TCP end-to-end Semantics References: <0056900014999241000002L012*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit eric.verlind@philips.com wrote: > > Can somebody come up with some examples of practical, relevant applications > that will fail under spoofing? What about any connection whose spoofed ACKs cause the sender's window to reuse offsets (i.e., roll-around), and then has a change in the path that causes the spoofer (with its state) to be outside the path? The result will _look_ like a successful transfer, but result in corruption. Joe From owner-tcpsat@lerc.nasa.gov Tue Jan 9 13:31:02 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19094; Tue, 9 Jan 2001 13:31:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA02899 for tcpsat-outgoing; Tue, 9 Jan 2001 12:53:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA02818 for ; Tue, 9 Jan 2001 12:53:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA12374; Tue, 9 Jan 2001 12:53:32 -0500 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012295; Tue, 9 Jan 01 12:52:59 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA16201; Tue, 9 Jan 2001 09:52:51 -0800 (PST) Message-ID: <3A5B4F76.E58B3095@isi.edu> Date: Tue, 09 Jan 2001 09:50:46 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alhussein Abouzeid CC: Craig Partridge , Luigi Rizzo , eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Alhussein Abouzeid wrote: > > What is a system? and what are "TCP end-to-end semantics"? Where are they > defined? > > I think saying remote and intermediate "system" does more harm > than good in clarifying the issue. > > I do not think that the failure of the receiver to deliver data > to the application after ACKing it is a problem of the transport layer > anyway. If we accept layering, and we accept the end-to-end philosophy, > then the guarantee that a transport protocol provides is between the two > _transport_ end points not the two _application_ end points. Right? The E2E argument makes assertions about the differences between composing services (e.g., ACKs here) or not. The ultimate effect of that would be applications that write IP packets. We tend to accept some slack inside the endhost as a tradeoff. > Now, there can be two ways to treat the end-to-end argument. If you (or > your application) are a hardliner and require that the transport > protocol ACK packets only if they are received at the destination, then > spoofing is a violation. If, on the other hand, you apply the end-to-end > on a "session" basis, i.e. a transport protocol will only terminate the > session when all packets of the session are received, then, in principle, > one can argue that there exists an intermediary spoofer (e.g. that > doesn't complete the handshake except after the reception of all packets > at the receiver) that will not be violating the semantics, even if it > plays with the data packets/ACKs to its convenience during the course of > the session. The problem is that the end system can THINK all the packets have been received, and have a different set of packets than were sent. (see the earlier example I posted - where the spoofer ACKs, the source window rolls-around, and then the path changes). Joe From owner-tcpsat@lerc.nasa.gov Tue Jan 9 13:38:00 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19220; Tue, 9 Jan 2001 13:38:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA06093 for tcpsat-outgoing; Tue, 9 Jan 2001 13:02:02 -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 NAA06030; Tue, 9 Jan 2001 13:01:46 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id NAA22555; Tue, 9 Jan 2001 13:01:46 -0500 (EST) Message-Id: <200101091801.NAA22555@guns.lerc.nasa.gov> To: Craig Partridge From: Mark Allman Reply-To: mallman@grc.nasa.gov cc: eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics Organization: NASA GRC/BBN Technologies Song-of-the-Day: Honky Tonk Woman Date: Tue, 09 Jan 2001 13:01:46 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > If you linger on the close (such that all data is acknowledged > before your socket closes -- and assuming no ack spoofing) then > you'll have a firm guarantee that your data reached the remote > system. Modulo LINGER working correctly (which my experience suggests is an iffy proposition). > This guarantee, however, is only for the end system -- it does not > say the end application received the data (it may never read it). I believe the strict application of the end-to-end principle is the only true answer. That is, the applications have to ACK the arrival of the data to its peer application. Trusting anything (transport protocols, routers, spoofing boxes, proxies, NATs, etc.) in between the application processes for "guarantees" is always going to be dicey (where the defintion of "dicey" sort of depends on what is involved in between the apps). allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Tue Jan 9 14:37:01 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20228; Tue, 9 Jan 2001 14:37:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21662 for tcpsat-outgoing; Tue, 9 Jan 2001 13:49:12 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA21573 for ; Tue, 9 Jan 2001 13:49:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA21130; Tue, 9 Jan 2001 13:49:05 -0500 Received: from labsun2.iss.comsat.com(134.133.12.62) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021001; Tue, 9 Jan 01 13:48:03 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun2.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f09Ilmc01322; Tue, 9 Jan 2001 13:47:48 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f09Ill720655; Tue, 9 Jan 2001 13:47:47 -0500 (EST) Date: Tue, 9 Jan 2001 13:47:47 -0500 (EST) From: Anil Agarwal Message-Id: <200101091847.f09Ill720655@pleiades.ntd.comsat.com> To: craig@aland.bbn.com Subject: Re: TCP end-to-end Semantics Cc: eric.verlind@philips.com, hussein@ee.washington.edu, luigi@info.iet.unipi.it, tcpsat@grc.nasa.gov Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <200101091728.MAA55198@aland.bbn.com> Craig Partridge wrote: >>2. On a more practical plane, things are a little different. >> >> Most well-written TCP applications do not assume that if the sender >> TCP has accepted user data, then the data will get delivered to the >> receiver with absolute guarantee. To verify end-to-end data delivery, >> such applications use one of several methods - >> >> 1. Close the socket, with the LINGER option enabled, and wait for TCP >> to finish its FIN echange and to return success/failure indication >> to the user. > >Which may fail when spoofing is done. If the RTT between the sender and >the spoofing node is sharply less (and less variable) than the RTT between >the sender and the receiver, it is conceivable (esp. if the real RTT >includes a satellite delay) that the sender will multiply retransmit >and finally time out the FIN. > >The end result is a transfer that has occurred, but due to spoofing the >sender deems to have failed and may retry (many times!). > Practically speaking, a FIN timeout takes 3.5 minutes, on most systems, with 11 retransmissions with backoff timeout values and a minimum timer value of 0.5 seconds. So the above scenario is one where the spoofer successfully completes the FIN exchange with the distant peer after 3.5 minutes and not earlier. I am sure everyone will agree that this is a very low probability (not zero) event for most networks, including satellite networks (except perhaps for deep-space links). This scenario is similar to a non-spoofed TCP connection that sends a FIN, gets a FIN,ACK from the peer and sends a final ACK. If the final ACK is not delivered to the peer, even after retransmissions of the FIN,ACK by the peer, then the sender perceives a successful transfer, while the receiver does not. Yet another scenario is a non-spoofed TCP connection that sends a FIN, but the FIN,ACK from the peer is lost and is never received even after retransmissions of the FIN by the sender. Then both the sender and receiver detect a failed connection, even though the receiver can tell that it received all the sender's data. The receiver cannot tell the difference between this scenario and the previous one; so it must discard the received data. Note: this is related to the "General's Problem". Hence, TCP does not provide 100% guarantee that both the sender and the receiver can detect a failed connection, although the probability of an undetected failure is very small. The probability of spoofing causing an undetected failure, as shown in Craig's scenario, is of the same order - I state this of course without proof :(. >> 2. Do an application-to-application message exchange to verify whether >> that all data has been received. This may also be done at intermediate >> points in the session. > >This works, but is also subject to the timeout problem above. > I am not sure why that is so. If the applications successfully exchange a data msg. saying that all data has been received, than they presumably will not care whether the FIN succeeds or not. On the other hand, this is also subject to the "General's Problem" dilemma, where both sides cannot detect with 100% probability a failed connection. >> ... >> >> With such a spoofer, one can say that applications that use methods 1 and 2 >> mentioned above, will not see any difference in "semantics" or end-results, >> when operating with an intermediate spoofer. > >I think I just illustrated a case where this is not true. > See explanations above. >> Applications that use method 4 will not experience any significant change >> in probability of success or failure, assuming that the spoofer itself >> has a low probability of failure. Network or destination host failures >> will affect the probability of failure by the same amount, whether spoofing >> is used or not. > >By this logic if my chance of failure is originally .001 and I add a spoofer >with a chance of failure of 0.001, I should not be distressed that my chance >of failure has roughly doubled to (0.002)? > There really isn't much cause for distress here. Firstly, equipment failures (of the router and spoofer kind) are not measured in .001 probabilities - they have MTBFs of several years - the equivalent failure probabilities are much, much lower. Secondly, the spoofer is generally NOT an additonal piece of equipment in the network - it takes the place of a router - hence the overall failure probability is no different than an equivalent network that does not use the spoofer. Regards, Anil Agarwal LMGT From owner-tcpsat@lerc.nasa.gov Tue Jan 9 16:19:56 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21523; Tue, 9 Jan 2001 16:19:55 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA21816 for tcpsat-outgoing; Tue, 9 Jan 2001 15:35:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA21761 for ; Tue, 9 Jan 2001 15:35:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA07413; Tue, 9 Jan 2001 15:35:46 -0500 Received: from sj-msg-core-1.cisco.com(171.71.163.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007332; Tue, 9 Jan 01 15:35:31 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.10]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08015; Tue, 9 Jan 2001 12:34:48 -0800 (PST) Message-Id: <5.0.2.1.2.20010109210640.00af3dc0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 21:28:42 +0800 To: Alhussein Abouzeid From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: tcpsat@grc.nasa.gov In-Reply-To: References: <200101082331.SAA52978@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 08:14 PM 1/8/01 -0800, Alhussein Abouzeid wrote: >What is a system? and what are "TCP end-to-end semantics"? Where are they >defined? TCP's e2e semantics are described in RFC 793. With respect to the relationship to applications above TCP, it says: Much of this document is written in the context of TCP implementations which are co-resident with higher level protocols in the host computer. Some computer systems will be connected to networks via front-end computers which house the TCP and internet protocol layers, as well as network specific software. The TCP specification describes an interface to the higher level protocols which appears to be implementable even for the front-end case, as long as a suitable host-to-front end protocol is implemented. Translation: the communication between TCP and its client applications is "reliable" in the same sense that communication between TCPs is "reliable". Between TCPs, "reliable" means that either the packets will be delivered and acknowledged, or after some number of retransmission attempts TCP will take the connection down and advise its client application of the failure. Between TCP and its client, that communication is provided by the operating system, and will either deliver the data or will inform both TCP and the application that the OS link has failed. It is technically possible that TCP could acknowledge the delivery of the data to a hung application and exchange FIN/FIN-ACK, and then have the application die an untimely death without fully processing the data, but the presumption is that OS failure or application failure at that specific point is so unlikely that it is acceptable to leave that to the application or the user to detect and correct. If TCP is terminated somewhere else - the above text mentions front-end processors - the clear expectation is that the communication link between the TCP and the client remains "reliable". I think the problem that Craig is mentioning is that when TCP Acks are spoofed, the probability of that end case is greater - the link between the guy spoofing the Ack and the ultimate destination is not necessarily as well guaranteed. It seems to me that this concern can be obviated only by having the spoofer cache the data exchanged on the connection and itself assure the delivery of the data - retransmit. >I do not think that the failure of the receiver to deliver data >to the application after ACKing it is a problem of the transport layer >anyway. If we accept layering, and we accept the end-to-end philosophy, >then the guarantee that a transport protocol provides is between the two >_transport_ end points not the two _application_ end points. Right? Of course, the ultimate judge of whether the right thing happened has to be the user of the application. But using that argument to justify failing to deliver the data to the application does indeed significantly weaken the legitimate expectations of the user. Per the text I quoted above, the user can legitimately expect that if TCP says the data was delivered, the data was indeed delivered to the application - only an OS failure or an application failure will cause the application to not receive and consume it. If you go on to argue that this is not a legitimate expectation, then all applications have to have some form of reliability guarantee in them as well. From owner-tcpsat@lerc.nasa.gov Tue Jan 9 16:20:10 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21547; Tue, 9 Jan 2001 16:20:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA21772 for tcpsat-outgoing; Tue, 9 Jan 2001 15:35:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA21723 for ; Tue, 9 Jan 2001 15:35:44 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA07358; Tue, 9 Jan 2001 15:35:43 -0500 Received: from sj-msg-core-1.cisco.com(171.71.163.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007295; Tue, 9 Jan 01 15:35:00 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.10]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08143; Tue, 9 Jan 2001 12:35:03 -0800 (PST) Message-Id: <5.0.2.1.2.20010109213020.00abc9b0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 21:32:54 +0800 To: eric.verlind@philips.com From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: In-Reply-To: <0056900014999241000002L012*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 10:46 AM 1/9/01 +0100, eric.verlind@philips.com wrote: >Can somebody come up with some examples of practical, relevant >applications that will fail under spoofing? Any practical experiences? yes. Financial applications, wherein the transmission of information results in money being removed from an account. When your bank tells your ATM to spit out money, if the communication is spoofed you can lose the money from your account and not get the bills spit out. More generally, transactions lost in flight can have other than a shared fate. From owner-tcpsat@lerc.nasa.gov Tue Jan 9 17:41:47 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22470; Tue, 9 Jan 2001 17:41:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA18521 for tcpsat-outgoing; Tue, 9 Jan 2001 17:07:36 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA18396 for ; Tue, 9 Jan 2001 17:07:32 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA22612; Tue, 9 Jan 2001 17:07:26 -0500 Received: from drawbridge.ascend.com(198.4.92.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022475; Tue, 9 Jan 01 17:06:30 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id NAA10887; Tue, 9 Jan 2001 13:58:09 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 9 Jan 2001 22:06:27 UT Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id OAA28017; Tue, 9 Jan 2001 14:06:26 -0800 (PST) Received: from lucent.com (briard.eng.ascend.com [135.140.26.37]) by wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id OAA07693; Tue, 9 Jan 2001 14:06:23 -0800 (PST) Message-ID: <3A5B8B5F.6FD52B4B@lucent.com> Date: Tue, 09 Jan 2001 14:06:23 -0800 From: Jacob Heitz Organization: Lucent Technologies, Internetworking Systems, Software Engineering, Alameda X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: Anil Agarwal CC: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics References: <200101091847.f09Ill720655@pleiades.ntd.comsat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Anil Agarwal wrote: > > In message <200101091728.MAA55198@aland.bbn.com> Craig Partridge wrote: > > >>2. On a more practical plane, things are a little different. > >> > >> Most well-written TCP applications do not assume that if the sender > >> TCP has accepted user data, then the data will get delivered to the > >> receiver with absolute guarantee. To verify end-to-end data delivery, > >> such applications use one of several methods - > >> > >> 1. Close the socket, with the LINGER option enabled, and wait for TCP > >> to finish its FIN echange and to return success/failure indication > >> to the user. > > > >Which may fail when spoofing is done. If the RTT between the sender and > >the spoofing node is sharply less (and less variable) than the RTT between > >the sender and the receiver, it is conceivable (esp. if the real RTT > >includes a satellite delay) that the sender will multiply retransmit > >and finally time out the FIN. > > > >The end result is a transfer that has occurred, but due to spoofing the > >sender deems to have failed and may retry (many times!). > > > > Practically speaking, a FIN timeout takes 3.5 minutes, on most > systems, with 11 retransmissions with backoff timeout values and a minimum > timer value of 0.5 seconds. So the above scenario is one where the spoofer > successfully completes the FIN exchange with the distant peer after 3.5 > minutes and not earlier. I am sure everyone will agree that this is > a very low probability (not zero) event for most networks, including > satellite networks (except perhaps for deep-space links). > > This scenario is similar to a non-spoofed TCP connection that > sends a FIN, gets a FIN,ACK from the peer and sends a final ACK. If the final > ACK is not delivered to the peer, even after retransmissions of the FIN,ACK > by the peer, then the sender perceives a successful transfer, while the > receiver does not. > > Yet another scenario is a non-spoofed TCP connection that > sends a FIN, but the FIN,ACK from the peer is lost and is never > received even after retransmissions of the FIN by the sender. > Then both the sender and receiver detect a failed connection, even though > the receiver can tell that it received all the sender's data. The receiver > cannot tell the difference between this scenario and the previous one; > so it must discard the received data. > > Note: this is related to the "General's Problem". > > Hence, TCP does not provide 100% guarantee that both the sender and the > receiver can detect a failed connection, although the probability of > an undetected failure is very small. The probability of spoofing causing > an undetected failure, as shown in Craig's scenario, is of the same > order - I state this of course without proof :(. Nonsense. TCP can and should provide 100% guarantee of detecting a failed connection. What it cannot do is provide a 100% guarantee of a successful connection. If the last ack does not arrive, there is doubt over success or failure. If the last ack arrives, the receiver of the last ack can be certain that all data was sent and received. The thing that the receiver of the last ack cannot be sure of is whether the peer is also sure. That is the General's Problem. TCP does not solve the General's Problem, but we don't normally care. You can spoof anything you like... except the last ack. > > >> 2. Do an application-to-application message exchange to verify whether > >> that all data has been received. This may also be done at intermediate > >> points in the session. > > > >This works, but is also subject to the timeout problem above. > > > > I am not sure why that is so. If the applications successfully exchange > a data msg. saying that all data has been received, than they presumably will > not care whether the FIN succeeds or not. > > On the other hand, this is also subject to the "General's Problem" dilemma, > where both sides cannot detect with 100% probability a failed connection. > > >> ... > >> > >> With such a spoofer, one can say that applications that use methods 1 and 2 > >> mentioned above, will not see any difference in "semantics" or end-results, > >> when operating with an intermediate spoofer. > > > >I think I just illustrated a case where this is not true. > > > > See explanations above. > > >> Applications that use method 4 will not experience any significant change > >> in probability of success or failure, assuming that the spoofer itself > >> has a low probability of failure. Network or destination host failures > >> will affect the probability of failure by the same amount, whether spoofing > >> is used or not. > > > >By this logic if my chance of failure is originally .001 and I add a spoofer > >with a chance of failure of 0.001, I should not be distressed that my chance > >of failure has roughly doubled to (0.002)? > > > > There really isn't much cause for distress here. > > Firstly, equipment failures (of the router and spoofer kind) are not measured > in .001 probabilities - they have MTBFs of several years - the equivalent > failure probabilities are much, much lower. > > Secondly, the spoofer is generally NOT an additonal piece of equipment in > the network - it takes the place of a router - hence the overall failure > probability is no different than an equivalent network that does not use > the spoofer. Nonsense. If a router fails, the endpoints find out and retransmit. A spoofer can fail such that the endpoints will never find out. > > Regards, > Anil Agarwal > LMGT From owner-tcpsat@lerc.nasa.gov Tue Jan 9 17:41:53 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22483; Tue, 9 Jan 2001 17:41:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA17827 for tcpsat-outgoing; Tue, 9 Jan 2001 17:04:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA17714 for ; Tue, 9 Jan 2001 17:04:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA22178; Tue, 9 Jan 2001 17:04:19 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022090; Tue, 9 Jan 01 17:03:51 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.10] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA06319 for ; Tue, 9 Jan 2001 17:03:37 -0500 (EST) Message-Id: <5.0.2.1.2.20010110055202.00a99d90@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 05:53:19 +0800 To: tcpsat@grc.nasa.gov From: Fred Baker Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010109210640.00af3dc0@flipper.cisco.com> References: <200101082331.SAA52978@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk By the way, I missed the initial message in this thread. What is proposed? Is it suggested that we move the acknowledge pointer (the sequence number of the next octet that the receiver expects to receive), or increase the window amount? From owner-tcpsat@lerc.nasa.gov Tue Jan 9 18:26:04 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23088; Tue, 9 Jan 2001 18:26:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA27594 for tcpsat-outgoing; Tue, 9 Jan 2001 17:50:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA27576 for ; Tue, 9 Jan 2001 17:50:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA29404; Tue, 9 Jan 2001 17:50:17 -0500 Received: from piglet.dstc.edu.au(130.102.176.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029314; Tue, 9 Jan 01 17:50:01 -0500 Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id f09MnMH19819; Wed, 10 Jan 2001 08:49:22 +1000 (EST) To: Fred Baker cc: eric.verlind@philips.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Tue, 09 Jan 2001 21:32:54 +0800." <5.0.2.1.2.20010109213020.00abc9b0@flipper.cisco.com> Date: Wed, 10 Jan 2001 08:49:46 +1000 Message-ID: <7504.979080586@dstc.edu.au> From: George Michaelson Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 10:46 AM 1/9/01 +0100, eric.verlind@philips.com wrote: >Can somebody come up with some examples of practical, relevant >applications that will fail under spoofing? Any practical experiences? yes. Financial applications, wherein the transmission of information results in money being removed from an account. When your bank tells your ATM to spit out money, if the communication is spoofed you can lose the money from your account and not get the bills spit out. More generally, transactions lost in flight can have other than a shared fate. But this presupposes transactional completeness maps 1:1 into tcp ack flow. Surely no application of this nature depends on an underlying protocol to give closure inside its application-specific logic? Assuming a reliable bytestream doesn't mean the application says yes or no. For instance, one can imagine a nightmare world of mainframes where TCP terminates in a front-end-processor and backend bisync is required to get to the cash services engine inside some monster iron. You can't use a spoofed or non-spoofed TCP ack there to get completion on a transaction. -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From owner-tcpsat@lerc.nasa.gov Tue Jan 9 18:27:04 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23117; Tue, 9 Jan 2001 18:27:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA27876 for tcpsat-outgoing; Tue, 9 Jan 2001 17:52:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA27826 for ; Tue, 9 Jan 2001 17:52:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id RAA29680; Tue, 9 Jan 2001 17:52:21 -0500 Received: from smtp.eecs.umich.edu(141.213.4.44) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029554; Tue, 9 Jan 01 17:51:58 -0500 Received: from wildwood.eecs.umich.edu (wildwood.eecs.umich.edu [141.213.4.68]) by smtp.eecs.umich.edu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA17602; Tue, 9 Jan 2001 17:51:45 -0500 Date: Tue, 9 Jan 2001 17:51:44 -0500 (EST) From: Mingyan Liu To: Craig Partridge cc: Anil Agarwal , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <200101091728.MAA55198@aland.bbn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Tue, 9 Jan 2001, Craig Partridge wrote: > > By this logic if my chance of failure is originally .001 and I add a spoofer > with a chance of failure of 0.001, I should not be distressed that my chance > of failure has roughly doubled to (0.002)? > I have a question: if by using the spoofer (or other type of PEPs that basically violate the e-t-e semantics) the performance is improved under certain conditions (e.g., increased link utilization etc. in the case of satellite), then should it be left to the application/user to decide whether they would rather use the spoofer and be exposed to higher failure probability, or just play safe and bypass the spoofer (assume that the use of a spoofer is not mandatory)? or is it that the e-t-e semantics should always supersede performance gain? -mingyan From owner-tcpsat@lerc.nasa.gov Tue Jan 9 18:55:11 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23353; Tue, 9 Jan 2001 18:55:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA01905 for tcpsat-outgoing; Tue, 9 Jan 2001 18:19:38 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA01722 for ; Tue, 9 Jan 2001 18:19:26 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA03390; Tue, 9 Jan 2001 18:19:25 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003328; Tue, 9 Jan 01 18:18:52 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.10] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA05085; Tue, 9 Jan 2001 18:18:19 -0500 (EST) Message-Id: <5.0.2.1.2.20010110065337.00a7d220@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 07:18:10 +0800 To: Anil Agarwal From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: tcpsat@grc.nasa.gov, craig@aland.bbn.com, eric.verlind@philips.com, hussein@ee.washington.edu, luigi@info.iet.unipi.it In-Reply-To: <200101091551.f09FplA12716@pleiades.ntd.comsat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 10:51 AM 1/9/01 -0500, Anil Agarwal wrote: >1. In a purely, theoretical sense, the answer is YES, as stated by many > authors. The spoofer acks packets to the sender that have not been > delivered to the destination host. this is what makes me wonder "what is the objective here"? If what we're trying to do is make the sender put additional data in flight, we don't have to acknowledge the data that is outstanding. We only need to increase the window, and do so in a manner that triggers additional transmissions. For example, Receiver <-> Spoofer <-> Sender if Receiver says that it will accept a window of N octets starting with octet n, Spoofer can increment the window to tell Sender that Destination is willing to receive N+M octets starting at octet n. Doing this will go through standard slow-start, and so will not actually increase Sender's transmission rate until several RTTs have gone by. If Spoofer is trying to get Sender to send more quickly NOW, he must increment the window in several successive messages: he can send a message every 10 milliseconds (say) which says Receiver will accept a window of N+m*MSS octets starting at octet n, for m = 1, 2, ..., M/MSS. That way, Sender will be provoked to send the next segment every 10 ms, achieving a high rate quickly, and Receiver will be none the wiser. We don't actually acknowledge anything until Receiver acknowledges it, so there is not a question of things being lost in flight. As long as there is no loss, this works just fine. If window size is an issue (if we are trying to move more than 64K bytes per RTT), someone who can add to the offered window can insert a window scaling option as well. And selective ack while he's at it. The problem, of course, is when a loss or massive reordering event occurs. Receiver receives messages (and acks them) up until the loss point, and then receives as much as its window allows after that, but discards all the stuff that Sender has sent over that. Sender will use the fast retransmission algorithm to get moving again, but will be in the fast retransmit phase (essentially sending one segment per RTT) for a really long period. The only way around that is for Spoofer to take responsibility for his actions and retransmit on Sender's behalf. Spoofer has to buffer Sender's data and retransmit it in a manner that appears normal to Destination. The shared-fate issue is still there - if Spoofer dies an untimely death, Destination and Sender have no chance of figuring out what he did, and will do better to tear down the connection and try again. In all, the best approach from my humble vantage point is to actually terminate and reopen the TCP connection, and (at least conceptually) copy data between them. We break the end to end semantic in the sense that an untimely loss of Spoofer leaves Reciever and Sender unable to recover, but everything else still works without having to wrap ourselves around an axle. What is the objective in this case? Is it to increase transfer rate? If so, why is pre-acknowledging data on the table? Joe mentioned the problem of having > 2 billion bytes outstanding so that the window wraps. While this is a theoretical problem, until we have terabit links with RTTs on the order of seconds, this is not a practical issue. From owner-tcpsat@lerc.nasa.gov Tue Jan 9 21:39:50 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25607; Tue, 9 Jan 2001 21:39:49 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA21151 for tcpsat-outgoing; Tue, 9 Jan 2001 20:54:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA21110 for ; Tue, 9 Jan 2001 20:54:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA22011; Tue, 9 Jan 2001 20:54:07 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021952; Tue, 9 Jan 01 20:53:29 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.10] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA18298; Tue, 9 Jan 2001 20:52:25 -0500 (EST) Message-Id: <5.0.2.1.2.20010110090515.00a9e4b0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Jan 2001 09:09:22 +0800 To: Mingyan Liu From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: Craig Partridge , Anil Agarwal , tcpsat@grc.nasa.gov In-Reply-To: References: <200101091728.MAA55198@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote: >it be left to the application/user to decide >whether they would rather use the spoofer and be exposed to higher failure >probability, or just play safe and bypass the spoofer (assume that the use >of a spoofer is not mandatory)? In general, I would agree with that. Now tell me this: do you know that the spoofer is there? How do you evade it? The cases that come quickly to mind are transparent and non-transparent web caches, Packeteer-style QoS control boxes which fiddle with TCP headers, Arrowpoint-etc devices which front-end sets of web servers, and so on. I can get around the non-transparent caches (SQuID etc) readily enough, but I may not be able to get around the others, and may not even know they are there. In such cases, the statement above is a great sentiment, one I would wholeheartedly support, but doesn't seem very practical. From owner-tcpsat@lerc.nasa.gov Tue Jan 9 23:42:51 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27669; Tue, 9 Jan 2001 23:42:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA01320 for tcpsat-outgoing; Tue, 9 Jan 2001 22:55:07 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA01314 for ; Tue, 9 Jan 2001 22:55:06 -0500 (EST) From: asaha@hss.hns.com Received: by seraph3.lerc.nasa.gov; id WAA04563; Tue, 9 Jan 2001 22:55:01 -0500 Received: from unknown(202.54.26.202) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004502; Tue, 9 Jan 01 22:54:10 -0500 Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f0A3tSa03332 for ; Wed, 10 Jan 2001 09:25:29 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 652569D0.00144DA8 ; Wed, 10 Jan 2001 09:11:46 +0530 X-Lotus-FromDomain: HSS To: tcpsat@grc.nasa.gov Message-ID: <652569D0.00144C44.00@sandesh.hss.hns.com> Date: Wed, 10 Jan 2001 09:18:06 +0530 Subject: Re: TCP end-to-end Semantics Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Hi, The requirement is that a TCP session, once it starts in spoofed mode continues thenceforth in spoofing mode unless there is a graceful closure. A route change that causes one of the spoofers to be removed from the path, will not be tolerated by most spoofers that I know of. However, this isn't as severe a restriction as it sounds.....most spoofers that I know operate on access networks where there is only one point of attachment. It would be interesting if there has been any study on spoofers that do tolerate these route changes. What about snoopers, or soft-state spoofers? Do they suffer from the same problem? -very best regards, Abheek eric.verlind@philips.com wrote: > > Can somebody come up with some examples of practical, relevant applications > that will fail under spoofing? What about any connection whose spoofed ACKs cause the sender's window to reuse offsets (i.e., roll-around), and then has a change in the path that causes the spoofer (with its state) to be outside the path? The result will _look_ like a successful transfer, but result in corruption. Joe From owner-tcpsat@lerc.nasa.gov Wed Jan 10 09:34:58 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17855; Wed, 10 Jan 2001 09:34:57 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA26667 for tcpsat-outgoing; Wed, 10 Jan 2001 08:43:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA26626 for ; Wed, 10 Jan 2001 08:43:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA29967; Wed, 10 Jan 2001 08:43:33 -0500 Received: from labsun2.iss.comsat.com(134.133.12.62) by seraph3.lerc.nasa.gov via smap (V5.5) id xma029889; Wed, 10 Jan 01 08:42:50 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun2.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f0ADgQc26517 for ; Wed, 10 Jan 2001 08:42:26 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f0ADgPX05362 for tcpsat@grc.nasa.gov; Wed, 10 Jan 2001 08:42:25 -0500 (EST) Date: Wed, 10 Jan 2001 08:42:25 -0500 (EST) From: Anil Agarwal Message-Id: <200101101342.f0ADgPX05362@pleiades.ntd.comsat.com> To: tcpsat@grc.nasa.gov Subject: Re: Re: TCP end-to-end Semantics Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <5.0.2.1.2.20010110090515.00a9e4b0@flipper.cisco.com>, Fred Baker wrote: > > >At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote: >>it be left to the application/user to decide >>whether they would rather use the spoofer and be exposed to higher failure >>probability, or just play safe and bypass the spoofer (assume that the use >>of a spoofer is not mandatory)? > >In general, I would agree with that. Now tell me this: do you know that the >spoofer is there? How do you evade it? > >The cases that come quickly to mind are transparent and non-transparent web >caches, Packeteer-style QoS control boxes which fiddle with TCP headers, >Arrowpoint-etc devices which front-end sets of web servers, and so on. I >can get around the non-transparent caches (SQuID etc) readily enough, but I >may not be able to get around the others, and may not even know they are there. > >In such cases, the statement above is a great sentiment, one I would >wholeheartedly support, but doesn't seem very practical. I am curious how we got into this discussion. Does someone have any firsthand knowledge that spoofers have a higher failure rate than other networking equipment? I don't think so - and hence the premise for this discussion is moot. The more relevant discussion, to which many authors have contributed valuable insights, is whether spoofing violates end-to-end TCP semantics, and at a more practical level, whether spoofing breaks applications or increases the probability of such breakage, such as reporting successful transfers when the transfer is in fact unsuccessful and vice-versa. Regards, Anil LMGT From owner-tcpsat@lerc.nasa.gov Wed Jan 10 09:38:48 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17988; Wed, 10 Jan 2001 09:38:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA01304 for tcpsat-outgoing; Wed, 10 Jan 2001 09:00:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA01260 for ; Wed, 10 Jan 2001 09:00:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA02498; Wed, 10 Jan 2001 09:00:38 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002394; Wed, 10 Jan 01 08:59:38 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id IAA59226; Wed, 10 Jan 2001 08:59:34 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101101359.IAA59226@aland.bbn.com> To: Mingyan Liu cc: Craig Partridge , Anil Agarwal , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Tue, 09 Jan 2001 17:51:44 EST." Date: Wed, 10 Jan 2001 08:59:34 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk How would you suppose the application discovers the spoofing? The whole idea of spoofing is that it is invisible. Craig In message , M ingyan Liu writes: > >On Tue, 9 Jan 2001, Craig Partridge wrote: > >> >> By this logic if my chance of failure is originally .001 and I add a spoofer >> with a chance of failure of 0.001, I should not be distressed that my chance >> of failure has roughly doubled to (0.002)? >> > >I have a question: if by using the spoofer (or other type of PEPs that >basically violate the e-t-e semantics) the performance is improved under >certain conditions (e.g., increased link utilization etc. in the case of >satellite), then should it be left to the application/user to decide >whether they would rather use the spoofer and be exposed to higher failure >probability, or just play safe and bypass the spoofer (assume that the use >of a spoofer is not mandatory)? or is it that the e-t-e semantics should >always supersede performance gain? > >-mingyan > > From owner-tcpsat@lerc.nasa.gov Wed Jan 10 10:33:04 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19291; Wed, 10 Jan 2001 10:33:03 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA16816 for tcpsat-outgoing; Wed, 10 Jan 2001 09:51:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA16737 for ; Wed, 10 Jan 2001 09:51:48 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA10114; Wed, 10 Jan 2001 09:51:48 -0500 Received: from po3.wam.umd.edu(128.8.10.165) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010029; Wed, 10 Jan 01 09:50:58 -0500 Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA13872; Wed, 10 Jan 2001 09:50:50 -0500 (EST) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA24892; Wed, 10 Jan 2001 09:50:50 -0500 (EST) Received: from localhost (karir@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA24888; Wed, 10 Jan 2001 09:50:50 -0500 (EST) X-Authentication-Warning: rac2.wam.umd.edu: karir owned process doing -bs Date: Wed, 10 Jan 2001 09:50:50 -0500 (EST) From: Manish Karir To: Fred Baker cc: Mingyan Liu , Craig Partridge , Anil Agarwal , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010110090515.00a9e4b0@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Wed, 10 Jan 2001, Fred Baker wrote: > At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote: > >it be left to the application/user to decide > >whether they would rather use the spoofer and be exposed to higher failure > >probability, or just play safe and bypass the spoofer (assume that the use > >of a spoofer is not mandatory)? > > In general, I would agree with that. Now tell me this: do you know that the > spoofer is there? How do you evade it? > well I believe the question is more along the lines of: if ISP X uses spoofer or caches or whatever to give you better performance(thruput or security or whatever you are measuring performance as) then you will continue to use them. If their service to you is unacceptable then you as the user can choose to switch to ISP Y. The bottom line is will the free market support for intelligence in the middle applications be sufficient for them to survive... if ISP X notices 10 big customers switching to someone else believe me he will quickly drop spoofing. if spoofing is invisible to end users and the users dont get any data losses or problems to complain about...then does it matter whether spoofing is used or not....is'nt the whole point of spoofing to get more customers by offering a network with (hopefully) superior performance than an competitor.... if customers do notice data losses degraded throughput hung connections.. whatever....then they are free to switch to another ISP. so it is correct to say that the end-users..(okay not applications) do in a way get to decided whether spoofing is good or not...whether they do this actively("..I need to call my ISP and find out what they do...") or passivly("aa...I dont know why my netscape browser hangs every 4th click.....I hate it...next month I'm switching") manish karir > The cases that come quickly to mind are transparent and > non-transparent web > caches, Packeteer-style QoS control boxes which fiddle with TCP > headers, Arrowpoint-etc devices which front-end sets of web servers, > and so on. I can get around the non-transparent caches (SQuID etc) > readily enough, but I may not be able to get around the others, and > may not even know they are there. > > In such cases, the statement above is a great sentiment, one I would > wholeheartedly support, but doesn't seem very practical. > > From owner-tcpsat@lerc.nasa.gov Wed Jan 10 10:33:51 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19343; Wed, 10 Jan 2001 10:33:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA19470 for tcpsat-outgoing; Wed, 10 Jan 2001 09:59:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA19379 for ; Wed, 10 Jan 2001 09:59:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA11315; Wed, 10 Jan 2001 09:59:14 -0500 Received: from aland.bbn.com(204.162.9.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011231; Wed, 10 Jan 01 09:58:58 -0500 Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.3/8.9.3) with ESMTP id JAA59699; Wed, 10 Jan 2001 09:58:56 -0500 (EST) (envelope-from craig@aland.bbn.com) Message-Id: <200101101458.JAA59699@aland.bbn.com> To: Manish Karir cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-reply-to: Your message of "Wed, 10 Jan 2001 09:50:50 EST." Date: Wed, 10 Jan 2001 09:58:56 -0500 From: Craig Partridge Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message , Manish Karir writes: >well I believe the question is more along the lines of: if ISP X uses >spoofer or caches or whatever to give you better performance(thruput or >security or whatever you are measuring performance as) then you will >continue to use them. If their service to you is unacceptable then >you as the user can choose to switch to ISP Y. The bottom line is >will the free market support for intelligence in the middle applications >be sufficient for them to survive... >if ISP X notices 10 big customers switching to someone else believe me he >will quickly drop spoofing. This assumes that the customer understand the source of error. One of the issues that has cropped up is that customers have expectations of their ISP. The introduction of hidden services like spoofers that may not conform with customer expectations but are not made visible to the customer means the customer may not get the service he/she expects but not know the cause. (E.g., the customer may switch and get another ISP that does the same hidden thing, and see the same problems, and blame the technology not the ISPs). Craig From owner-tcpsat@lerc.nasa.gov Wed Jan 10 10:36:45 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19427; Wed, 10 Jan 2001 10:36:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA20483 for tcpsat-outgoing; Wed, 10 Jan 2001 10:02:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA20415 for ; Wed, 10 Jan 2001 10:02:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA11865; Wed, 10 Jan 2001 10:02:31 -0500 Received: from po3.wam.umd.edu(128.8.10.165) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011706; Wed, 10 Jan 01 10:01:35 -0500 Received: from rac3.wam.umd.edu (IDENT:root@rac3.wam.umd.edu [128.8.10.143]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA14759; Wed, 10 Jan 2001 10:01:34 -0500 (EST) Received: from rac3.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac3.wam.umd.edu (8.9.3/8.9.3) with SMTP id KAA23444; Wed, 10 Jan 2001 10:01:34 -0500 (EST) Received: from localhost (karir@localhost) by rac3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id KAA23440; Wed, 10 Jan 2001 10:01:33 -0500 (EST) X-Authentication-Warning: rac3.wam.umd.edu: karir owned process doing -bs Date: Wed, 10 Jan 2001 10:01:33 -0500 (EST) From: Manish Karir To: asaha@hss.hns.com cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <652569D0.00144C44.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk You can check out: http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-11/CSHCN_TR_99-11.pdf I believe this implementation had a way of maintaining seq numbers such that they would work even if some traffic was routed around the spoofer. but I'm not sure.... Maybe if the original authors are still on this list they can comment... manish On Wed, 10 Jan 2001 asaha@hss.hns.com wrote: > Hi, > > The requirement is that a TCP session, once it starts in spoofed mode > continues thenceforth in spoofing mode unless there is a graceful > closure. A route change that causes one of the spoofers to be removed > from the path, will not be tolerated by most spoofers that I know of. > However, this isn't as severe a restriction as it sounds.....most > spoofers that I know operate on access networks where there is only > one point of attachment. > > It would be interesting if there has been any study on spoofers that > do tolerate these route changes. What about snoopers, or soft-state > spoofers? Do they suffer from the same problem? > > -very best regards, > Abheek From owner-tcpsat@lerc.nasa.gov Wed Jan 10 10:56:29 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19814; Wed, 10 Jan 2001 10:56:28 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA26410 for tcpsat-outgoing; Wed, 10 Jan 2001 10:20:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA26359 for ; Wed, 10 Jan 2001 10:20:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA15243; Wed, 10 Jan 2001 10:20:52 -0500 Received: from pot.cnuce.cnr.it(146.48.83.182) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015139; Wed, 10 Jan 01 10:19:56 -0500 Received: from pot by pot.cnuce.cnr.it with local (Exim 3.16 #1 (Debian)) id 14GN2V-0008Gm-00; Wed, 10 Jan 2001 16:19:51 +0100 From: Francesco Potorti` To: Fred Baker CC: tcpsat@grc.nasa.gov, eric.verlind@philips.com In-reply-to: <5.0.2.1.2.20010109213020.00abc9b0@flipper.cisco.com> (fred@cisco.com) Subject: Re: TCP end-to-end Semantics X-Fingerprint: 4B02 6187 5C03 D6B1 2E31 7666 09DF 2DC9 BE21 6115 References: <5.0.2.1.2.20010109213020.00abc9b0@flipper.cisco.com> Organization: CNR-CNUCE, via Alfieri 1, I-56010 Ghezzano Pisa, +39-0503153058 MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Message-Id: Date: Wed, 10 Jan 2001 16:19:51 +0100 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id KAA26410 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19814 At 10:46 AM 1/9/01 +0100, eric.verlind@philips.com wrote: >Can somebody come up with some examples of practical, relevant >applications that will fail under spoofing? Any practical experiences? Fred Baker: yes. Financial applications, wherein the transmission of information results in money being removed from an account. When your bank tells your ATM to spit out money, if the communication is spoofed you can lose the money from your account and not get the bills spit out. More generally, transactions lost in flight can have other than a shared fate. I do hope that no transaction-based application relies on TCP acks to verify that the receiving application has indeed got the data. Or, for that matter, no application at all. Am I missing anything? -- Francesco Potortì (researcher) Voice: +39 050 315 3058 (op.2111) Area della ricerca CNR - CNUCE Fax: +39 050 3138091 via Alfieri 1, I-56010 Ghezzano, Pisa Email: F.Potorti@cnuce.cnr.it Web: http://fly.cnuce.cnr.it/ Key: fly.cnuce.cnr.it/public.key From owner-tcpsat@lerc.nasa.gov Wed Jan 10 11:09:38 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20172; Wed, 10 Jan 2001 11:09:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA01263 for tcpsat-outgoing; Wed, 10 Jan 2001 10:35:09 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA01228 for ; Wed, 10 Jan 2001 10:35:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA17925; Wed, 10 Jan 2001 10:35:05 -0500 Received: from mailgw3a.lmco.com(192.35.35.24) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017811; Wed, 10 Jan 01 10:34:26 -0500 Received: from emss01g01.ems.lmco.com ([129.197.181.54]) by mailgw3a.lmco.com (8.8.8/8.8.8) with ESMTP id KAA22199 for ; Wed, 10 Jan 2001 10:34:26 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38886) id <0G6Y00801DXCOX@lmco.com> for tcpsat@grc.nasa.gov; Wed, 10 Jan 2001 07:34:25 -0800 (PST) Received: from emss01i00.ems.lmc.com ([129.197.181.70]) by lmco.com (PMDF V5.2-32 #38886) with ESMTP id <0G6Y0028EDX975@lmco.com> for tcpsat@grc.nasa.gov; Wed, 10 Jan 2001 07:34:22 -0800 (PST) Received: by emss01i00.ems.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 07:35:26 -0800 Content-return: allowed Date: Wed, 10 Jan 2001 07:35:25 -0800 From: "Smith JR, Harry E" Subject: TCP SACK Performance To: tcpsat@grc.nasa.gov Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Content-transfer-encoding: 7BIT Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT I am looking for information on TCP SACK. In particular, how the goodput and delay performance of TCP sack changes with BER. I have an idea how it does it with non-sack operations. Can anyone point me to some literature? I am not finding a lot on explanation on TCP sack implementation to the detail of the Stevens books. Harry Smith LMCO. ---------------------------------------------------------------------------- - Harry Smith 408 473 6491 From owner-tcpsat@lerc.nasa.gov Wed Jan 10 11:26:30 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20549; Wed, 10 Jan 2001 11:26:30 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA06311 for tcpsat-outgoing; Wed, 10 Jan 2001 10:50:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA06302 for ; Wed, 10 Jan 2001 10:50:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA20434; Wed, 10 Jan 2001 10:50:04 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020347; Wed, 10 Jan 01 10:49:13 -0500 Received: from hns.com (nmgsun3.hns.com [139.85.90.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id KAA07798 for ; Wed, 10 Jan 2001 10:49:11 -0500 (EST) Message-ID: <3A5C8476.17877389@hns.com> Date: Wed, 10 Jan 2001 10:49:10 -0500 From: Bhavesh Doshi X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: REMOVE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit REMOVE From owner-tcpsat@lerc.nasa.gov Wed Jan 10 11:26:47 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20562; Wed, 10 Jan 2001 11:26:46 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05130 for tcpsat-outgoing; Wed, 10 Jan 2001 10:45:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA05035 for ; Wed, 10 Jan 2001 10:45:49 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA19698; Wed, 10 Jan 2001 10:45:43 -0500 Received: from labsun1.iss.comsat.com(134.133.12.61) by seraph3.lerc.nasa.gov via smap (V5.5) id xma019582; Wed, 10 Jan 01 10:45:10 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun1.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f0AFiWC16517 for ; Wed, 10 Jan 2001 10:44:32 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f0AFiVE06961 for tcpsat@grc.nasa.gov; Wed, 10 Jan 2001 10:44:32 -0500 (EST) Date: Wed, 10 Jan 2001 10:44:32 -0500 (EST) From: Anil Agarwal Message-Id: <200101101544.f0AFiVE06961@pleiades.ntd.comsat.com> To: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <3A5B8B5F.6FD52B4B@lucent.com>, Jacob Heitz wrote: >Anil Agarwal wrote: >> >> In message <200101091728.MAA55198@aland.bbn.com> Craig Partridge wrote: >> >> >>2. On a more practical plane, things are a little different. >> >> >> >> Most well-written TCP applications do not assume that if the sender >> >> TCP has accepted user data, then the data will get delivered to the >> >> receiver with absolute guarantee. To verify end-to-end data delivery, >> >> such applications use one of several methods - >> >> >> >> 1. Close the socket, with the LINGER option enabled, and wait for TCP >> >> to finish its FIN echange and to return success/failure indication >> >> to the user. >> > >> >Which may fail when spoofing is done. If the RTT between the sender and >> >the spoofing node is sharply less (and less variable) than the RTT between >> >the sender and the receiver, it is conceivable (esp. if the real RTT >> >includes a satellite delay) that the sender will multiply retransmit >> >and finally time out the FIN. >> > >> >The end result is a transfer that has occurred, but due to spoofing the >> >sender deems to have failed and may retry (many times!). >> > >> >> Practically speaking, a FIN timeout takes 3.5 minutes, on most >> systems, with 11 retransmissions with backoff timeout values and a minimum >> timer value of 0.5 seconds. So the above scenario is one where the spoofer >> successfully completes the FIN exchange with the distant peer after 3.5 >> minutes and not earlier. I am sure everyone will agree that this is >> a very low probability (not zero) event for most networks, including >> satellite networks (except perhaps for deep-space links). >> >> This scenario is similar to a non-spoofed TCP connection that >> sends a FIN, gets a FIN,ACK from the peer and sends a final ACK. If the final >> ACK is not delivered to the peer, even after retransmissions of the FIN,ACK >> by the peer, then the sender perceives a successful transfer, while the >> receiver does not. >> >> Yet another scenario is a non-spoofed TCP connection that >> sends a FIN, but the FIN,ACK from the peer is lost and is never >> received even after retransmissions of the FIN by the sender. >> Then both the sender and receiver detect a failed connection, even though >> the receiver can tell that it received all the sender's data. The receiver >> cannot tell the difference between this scenario and the previous one; >> so it must discard the received data. >> >> Note: this is related to the "General's Problem". >> >> Hence, TCP does not provide 100% guarantee that both the sender and the >> receiver can detect a failed connection, although the probability of >> an undetected failure is very small. The probability of spoofing causing >> an undetected failure, as shown in Craig's scenario, is of the same >> order - I state this of course without proof :(. > >Nonsense. TCP can and should provide 100% guarantee of detecting a >failed connection. What it cannot do is provide a 100% guarantee of >a successful connection. If the last ack does not arrive, there is >doubt over success or failure. If the last ack arrives, the receiver >of the last ack can be certain that all data was sent and received. > >The thing that the receiver of the last ack cannot be sure of is >whether the peer is also sure. That is the General's Problem. >TCP does not solve the General's Problem, but we don't normally >care. > >You can spoof anything you like... except the last ack. I thank Jacob for his insightful comments. I stand corrected. Let us define a successful transfer as one where all data and the FIN is delivered to both ends. With that definition, one can state, that 1. For an unsuccessful transfer, TCP at both ends will detect the failure. 2. For a successful transfer, there is a non-zero probability P that TCP at one end (or both ends on a "simultaneous" close) may perceive the transfer as unsucessful. The probability P is related to the probability of a network or host outage during the FIN exchange time. This is an inherent poperty of TCP and has nothing to do with spoofing. I think we do care about the General's Problem; Fred Baker's example of the banking application is one reason why. No banking application designer would naively use TCP's "reliable transfer" mechanism as a means to solve the distributed transaction atomicity problem. I also stand corrected on the response to Craig's example. In that example both ends will notice a failure; the receiver will notice a failure since it will not get the "last ack". The probability of this event is related to the probability of the spoofer-to-destination network becoming "broken" around the time the first FIN is sent and getting "repaired" around 3.5+ minutes thereafter. One can see that the probability of this event is smaller than P mentioned above. Incidentally, the same result would occur if there was no spoofer. With the above background, and the material I wrote in my first response, I don't think anyone has come up with a legitimate example where spoofing causes an application to "break", when the application would work correctly in the absence of spoofing. It is important when designing such examples, to study carefully how the results would be different in a non-spoofed scenario. Also keep in mind, that the good spoofer will not spoof the FIN ack (or the last ack, as Jacob correctly points out). > >> >> >> Applications that use method 4 will not experience any significant change >> >> in probability of success or failure, assuming that the spoofer itself >> >> has a low probability of failure. Network or destination host failures >> >> will affect the probability of failure by the same amount, whether spoofing >> >> is used or not. >> > >> >By this logic if my chance of failure is originally .001 and I add a spoofer >> >with a chance of failure of 0.001, I should not be distressed that my chance >> >of failure has roughly doubled to (0.002)? >> > >> >> There really isn't much cause for distress here. >> >> Firstly, equipment failures (of the router and spoofer kind) are not measured >> in .001 probabilities - they have MTBFs of several years - the equivalent >> failure probabilities are much, much lower. >> >> Secondly, the spoofer is generally NOT an additonal piece of equipment in >> the network - it takes the place of a router - hence the overall failure >> probability is no different than an equivalent network that does not use >> the spoofer. > >Nonsense. If a router fails, the endpoints find out and retransmit. >A spoofer can fail such that the endpoints will never find out. > If we assume that the spoofer is working in an environment where there a spoofer failure causes loss of connectivity between the two hosts, then TCP will not be able to complete a FIN exchange and hence discover the spoofer failure. This is the most likely environment in which spoofers get used.. If we discard the above assumption, and assume that after the failure, the two ends will start communicating via an alternate path, then 1. If the TCP connections were "quiet" for a while before the failure, and the sequence number have not changed, then the TCP connections will actually continue, with no harm done (with a properly designed spoofer, of course, that retains sequence numbers across the spoofed connections. Our implementation does). 2. If not, then both ends will eventually retransmit and time out, since the receiver may be missing some data which the sender has already freed, and declare a failure (with a properly designed spoofer). (With a spoofer that does not retain seq numbers across spoofed connections, bad things can happen, probably with relatively small probability). The probability of a sequence number "match" while the sequence number at the sender has rolled over is extremely small and practically not very likely (the spoofer would have to buffer around 2^32 bytes on behalf of the sender!). This is no different than the TCP sequence wrap-around problem, for which PAWS was added; PAWS would solve the problem here as well. Anil Agarwal LMGT 22300 COMSAT Drive CLarksburg, MD 20871 301-428-4655 From owner-tcpsat@lerc.nasa.gov Wed Jan 10 11:55:30 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21223; Wed, 10 Jan 2001 11:55:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA14662 for tcpsat-outgoing; Wed, 10 Jan 2001 11:16:31 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA14608 for ; Wed, 10 Jan 2001 11:16:28 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA24872; Wed, 10 Jan 2001 11:16:26 -0500 Received: from smtp.eecs.umich.edu(141.213.4.44) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024733; Wed, 10 Jan 01 11:15:51 -0500 Received: from wildwood.eecs.umich.edu (wildwood.eecs.umich.edu [141.213.4.68]) by smtp.eecs.umich.edu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA09355; Wed, 10 Jan 2001 11:15:49 -0500 Date: Wed, 10 Jan 2001 11:15:49 -0500 (EST) From: Mingyan Liu To: Fred Baker cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010110090515.00a9e4b0@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk How about we use an IP option indicating "spoofing (not) allowed", similar to "no fragmentation", and require that the spoofer conform to it, will that make sense? (This then will not require user's knowledge but the application writers'...) Mingyan On Wed, 10 Jan 2001, Fred Baker wrote: > At 05:51 PM 1/9/01 -0500, Mingyan Liu wrote: > >it be left to the application/user to decide > >whether they would rather use the spoofer and be exposed to higher failure > >probability, or just play safe and bypass the spoofer (assume that the use > >of a spoofer is not mandatory)? > > In general, I would agree with that. Now tell me this: do you know that the > spoofer is there? How do you evade it? > > The cases that come quickly to mind are transparent and non-transparent web > caches, Packeteer-style QoS control boxes which fiddle with TCP headers, > Arrowpoint-etc devices which front-end sets of web servers, and so on. I > can get around the non-transparent caches (SQuID etc) readily enough, but I > may not be able to get around the others, and may not even know they are there. > > In such cases, the statement above is a great sentiment, one I would > wholeheartedly support, but doesn't seem very practical. > From owner-tcpsat@lerc.nasa.gov Wed Jan 10 12:07:02 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21473; Wed, 10 Jan 2001 12:07:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA23002 for tcpsat-outgoing; Wed, 10 Jan 2001 11:33:01 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA22936 for ; Wed, 10 Jan 2001 11:32:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA28321; Wed, 10 Jan 2001 11:32:55 -0500 Received: from green.its.bldrdoc.gov(132.163.64.205) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028209; Wed, 10 Jan 01 11:32:33 -0500 Received: from silver (silver.its.bldrdoc.gov [132.163.64.134]) by green.its.bldrdoc.gov (8.9.2/8.9.2) with ESMTP id JAA07148 for ; Wed, 10 Jan 2001 09:32:28 -0700 (MST) Message-Id: <4.2.0.58.20010110093152.00aa15c0@mail.its.bldrdoc.gov> X-Sender: billk@mail.its.bldrdoc.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 10 Jan 2001 09:32:37 -0700 To: tcpsat@grc.nasa.gov From: "William A. Kissick" Subject: REMOVE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk REMOVE ___________________________________________________________ Dr. William A. Kissick, Acting Chief Spectrum and Propagation Measurements Division (ITS.M) Institute for Telecommunication Sciences National Telecommunications and Information Administration 325 Broadway Boulder, Colorado 80305 http://www.its.bldrdoc.gov/Home.html Voice 303-497-7410 FAX 303-497-5323 ___________________________________________________________ From owner-tcpsat@lerc.nasa.gov Wed Jan 10 12:07:53 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21491; Wed, 10 Jan 2001 12:07:48 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA24015 for tcpsat-outgoing; Wed, 10 Jan 2001 11:36:20 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA23913 for ; Wed, 10 Jan 2001 11:36:15 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA28939; Wed, 10 Jan 2001 11:36:10 -0500 Received: from info.iet.unipi.it(131.114.9.184) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028825; Wed, 10 Jan 01 11:35:45 -0500 Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA11358; Wed, 10 Jan 2001 17:38:46 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200101101638.RAA11358@info.iet.unipi.it> Subject: Re: TCP end-to-end Semantics In-Reply-To: <200101091728.MAA55198@aland.bbn.com> from Craig Partridge at "Jan 9, 2001 12:28:12 pm" To: Craig Partridge Date: Wed, 10 Jan 2001 17:38:46 +0100 (CET) CC: Anil Agarwal , tcpsat@grc.nasa.gov, eric.verlind@philips.com, hussein@ee.washington.edu X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > By this logic if my chance of failure is originally .001 and I add a spoofer > with a chance of failure of 0.001, I should not be distressed that my chance > of failure has roughly doubled to (0.002)? The problem is that it might increase by several orders of magnitude. I would say that "failure" here is a false positive, i.e. data not being delivered to a well-behaved receiver (i.e. one which does all the read()s it is supposed to do) but the sender does not realize -- basically the sender even sees the last ack, but the receiving endpoint crashes before passing all data to the application. If the receiving protocol endpoint and the application are on the same physical hw, then P(failure) can easily be several orders of magnitude below 1. When you split the receiving endpoint from the application (by means of a proxy somewhere), depending on what you have in the middle and how you implement the proxy, the P(failure) of the connection between the proxy and the receiving application can be much higher (or more vulnerable to attacks). E.g. in the config below, if the proxy buffers everything and even generates the last ack, the sender will be able to terminate and it is easy to think that the connection on path <2> might be teared down with a significantly higher probability than the P(failure) above. Much better if the proxy retains the last ack until it gets one from the remote end (this way you can accommodate chains of proxies) -- modulo the timeout issues that someone mentioned. [sender]----<1>-----[proxy]-----<2>-----[receiver] cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone (510) 666 2927 . ----------------------------------+----------------------------------------- From owner-tcpsat@lerc.nasa.gov Wed Jan 10 12:22:26 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21811; Wed, 10 Jan 2001 12:22:23 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA26972 for tcpsat-outgoing; Wed, 10 Jan 2001 11:46:06 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA26923 for ; Wed, 10 Jan 2001 11:46:02 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA00887; Wed, 10 Jan 2001 11:46:01 -0500 Received: from unknown(4.36.44.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000755; Wed, 10 Jan 01 11:45:28 -0500 Received: (from smap@localhost) by smtp2.adero.com (8.10.1/8.10.1) id f0AGic218082 for ; Wed, 10 Jan 2001 16:44:38 GMT Received: from mail.adero.com(10.1.2.22) by smtp2.adero.com via smap (V2.1+anti-relay+anti-spam) id xma018073; Wed, 10 Jan 01 16:44:06 GMT Received: by mail.adero.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 11:44:55 -0500 Message-ID: <605143DC5922D411A27B0008C78694DC01C03086@mail.adero.com> From: Tom Andresen To: tcpsat@grc.nasa.gov Subject: REMOVE Date: Wed, 10 Jan 2001 11:44:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk REMOVE PLEASE From owner-tcpsat@lerc.nasa.gov Wed Jan 10 12:33:09 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22046; Wed, 10 Jan 2001 12:33:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA00280 for tcpsat-outgoing; Wed, 10 Jan 2001 11:57:52 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA00199 for ; Wed, 10 Jan 2001 11:57:47 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA03113; Wed, 10 Jan 2001 11:57:46 -0500 Received: from gw.sp.op.dlr.de(129.247.188.16) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003028; Wed, 10 Jan 01 11:56:55 -0500 Received: from dlr.de ([129.247.173.176]) by n13.sp.op.dlr.de (8.10.1/8.10.1) with ESMTP id f0AGuk4247870; Wed, 10 Jan 2001 17:56:47 +0100 Message-ID: <3A5C9453.DDED442B@dlr.de> Date: Wed, 10 Jan 2001 17:56:51 +0100 From: Carlo Matarasso Organization: DLR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: "Smith JR, Harry E" CC: tcpsat@grc.nasa.gov Subject: Re: TCP SACK Performance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Harry, I should definitely read some of the work by Dr. Floyd (http://www.aciri.org/floyd/). carlo "Smith JR, Harry E" wrote: > I am looking for information on TCP SACK. In particular, how the goodput > and delay performance of TCP sack changes with BER. I have an idea how it > does it with non-sack operations. > > Can anyone point me to some literature? I am not finding a lot on > explanation on TCP sack implementation to the detail of the Stevens books. > > Harry Smith > LMCO. > > ---------------------------------------------------------------------------- > - > Harry Smith > 408 473 6491 -- ------------------------------------------------------------------------------------------- DOTT. ING. CARLO MATARASSO carlo.matarasso@dlr.de TEL. +49 8153 28 2848 FAX +49 8153 28 2844 DLR - DEUTSCHES ZENTRUM FUER LUFT UND RAUMFAHRT GERMAN AEROSPACE CENTER http://www.dlr.de/kn/kn-dn POSTFACH 1116 D - 82230 WESSLING - GERMANY ------------------------------------------------------------------------------------------- From owner-tcpsat@lerc.nasa.gov Wed Jan 10 13:42:30 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23928; Wed, 10 Jan 2001 13:42:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21222 for tcpsat-outgoing; Wed, 10 Jan 2001 13:07:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA21098 for ; Wed, 10 Jan 2001 13:06:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA15625; Wed, 10 Jan 2001 13:06:55 -0500 Received: from generic.isetec.net.py(208.52.50.91) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015442; Wed, 10 Jan 01 13:06:06 -0500 Received: from infocenter.com.py (10.1.0.103 [10.1.0.103]) by hawk.horse with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CJQDHL3H; Wed, 10 Jan 2001 15:02:09 -0300 Message-ID: <3A5CA3C4.F1C275A6@infocenter.com.py> Date: Wed, 10 Jan 2001 15:02:44 -0300 From: Roberto Merens Organization: Infocenter X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: REMOVE Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id NAA21173 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id NAA21222 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA23928 REMOVE -- Roberto Merens Gerencia de NetWorking Infocenter www.infocenter.com.py Phone: 595-21-226016 Asunción - Paraguay From owner-tcpsat@lerc.nasa.gov Wed Jan 10 13:48:02 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24046; Wed, 10 Jan 2001 13:48:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA22071 for tcpsat-outgoing; Wed, 10 Jan 2001 13:09:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA22005 for ; Wed, 10 Jan 2001 13:09:05 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA16013; Wed, 10 Jan 2001 13:09:04 -0500 Received: from po4.wam.umd.edu(128.8.10.166) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015918; Wed, 10 Jan 01 13:08:12 -0500 Received: from rac1.wam.umd.edu (IDENT:root@rac1.wam.umd.edu [128.8.10.141]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA00042; Wed, 10 Jan 2001 13:08:07 -0500 (EST) Received: from rac1.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac1.wam.umd.edu (8.9.3/8.9.3) with SMTP id NAA03240; Wed, 10 Jan 2001 13:08:07 -0500 (EST) Received: from localhost (karir@localhost) by rac1.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA03236; Wed, 10 Jan 2001 13:08:07 -0500 (EST) X-Authentication-Warning: rac1.wam.umd.edu: karir owned process doing -bs Date: Wed, 10 Jan 2001 13:08:06 -0500 (EST) From: Manish Karir To: Anil Agarwal cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <200101101544.f0AFiVE06961@pleiades.ntd.comsat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Well one application that I did come across in my work what does'nt work seamlessless with spoofing is spoofing for IPSEC secure flows. IPSEC flows dont really break spoofing...you just cant spoof them cauz transport layer header is encrypted. This topic was brought up on the list earlier but never really resolved. Our own approach was to propose a layering mechanism to IPSEC to allow spoofing to happen. I believe there was a similar approach being proposed by HRL. if anybody is interested in learning more about this you can check out: http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_MS_99-9/CSHCN_MS_99-9.phtml and the HRL proposal is at: http://206.17.46.2/people/ygz/ml-ipsec/ manish On Wed, 10 Jan 2001, Anil Agarwal wrote: > > With the above background, and the material I wrote in my first response, > I don't think anyone has come up with a legitimate example where spoofing > causes an application to "break", when the application would work > correctly in the absence of spoofing. It is important when designing > such examples, to study carefully how the results would be different > in a non-spoofed scenario. Also keep in mind, that the good spoofer will > not spoof the FIN ack (or the last ack, as Jacob correctly points out). > From owner-tcpsat@lerc.nasa.gov Wed Jan 10 14:36:56 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25303; Wed, 10 Jan 2001 14:36:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA08341 for tcpsat-outgoing; Wed, 10 Jan 2001 13:58:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA08280 for ; Wed, 10 Jan 2001 13:58:07 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA23689; Wed, 10 Jan 2001 13:58:07 -0500 Received: from wirex.com(208.161.110.91) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023616; Wed, 10 Jan 01 13:57:20 -0500 Received: from joonees (cerebus.wirex.com [216.161.55.93]) by mail.wirex.com (Postfix) with SMTP id 9299B3EC13; Wed, 10 Jan 2001 10:57:19 -0800 (PST) From: "Joonees K. Chay" To: "Bhavesh Doshi" , Subject: REMOVE Date: Wed, 10 Jan 2001 10:52:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A5C8476.17877389@hns.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit REMOVE > -----Original Message----- > From: owner-tcpsat@lerc.nasa.gov [mailto:owner-tcpsat@lerc.nasa.gov]On > Behalf Of Bhavesh Doshi > Sent: Wednesday, January 10, 2001 7:49 AM > To: tcpsat@grc.nasa.gov > Subject: REMOVE > > > REMOVE > From owner-tcpsat@lerc.nasa.gov Wed Jan 10 14:37:05 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25316; Wed, 10 Jan 2001 14:37:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA09109 for tcpsat-outgoing; Wed, 10 Jan 2001 14:00:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA09047 for ; Wed, 10 Jan 2001 14:00:19 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA24155; Wed, 10 Jan 2001 14:00:17 -0500 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024038; Wed, 10 Jan 01 14:00:10 -0500 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA02466; Wed, 10 Jan 2001 11:00:06 -0800 (PST) Message-ID: <3A5CB0AD.7D250995@isi.edu> Date: Wed, 10 Jan 2001 10:57:49 -0800 From: Joe Touch X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Manish Karir CC: asaha@hss.hns.com, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Manish Karir wrote: > > You can check out: > http://www.isr.umd.edu/TechReports/CSHCN/1999/CSHCN_TR_99-11/CSHCN_TR_99-11.pdf > > I believe this implementation had a way of maintaining seq numbers > such that they would work even if some traffic was > routed around the spoofer. but I'm not sure.... It appears to assert that it preserves E2E semantics by preserving the sequence numbers. However the source TCP has no way of knowing that this intermediate has correctly or consistently provided that guarantee (or the one about delaying the SYN-ACK until it comes from the source, e.g.). > > Hi, > > > > The requirement is that a TCP session, once it starts in spoofed mode > > continues thenceforth in spoofing mode unless there is a graceful > > closure. A route change that causes one of the spoofers to be removed > > from the path, will not be tolerated by most spoofers that I know of. > > However, this isn't as severe a restriction as it sounds.....most > > spoofers that I know operate on access networks where there is only > > one point of attachment. The reason this is of further concern is that the spoofer code can die, in which case the TCP connection should show an error. As I pointed out before, this would result in erroneous data being transferred instead. The key point of the E2E argument is that it does not allow adding intermediate components except for performance, exactly because the E2E communication depends critically on their correct operation. Unless there is a provably uncrashable spoofer, it clearly violates TCP's E2E semantics as a result. Joe From owner-tcpsat@lerc.nasa.gov Wed Jan 10 15:19:10 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26071; Wed, 10 Jan 2001 15:19:09 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA20931 for tcpsat-outgoing; Wed, 10 Jan 2001 14:37:42 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA20853 for ; Wed, 10 Jan 2001 14:37:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA00124; Wed, 10 Jan 2001 14:37:32 -0500 Received: from mail2.newskies.nl(212.153.26.66) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000032; Wed, 10 Jan 01 14:36:52 -0500 Received: from grantlap (NSS [63.69.122.194]) by nss02.newskies.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CR47YCLM; Wed, 10 Jan 2001 20:36:45 +0100 From: "Grant Hundertmark" To: Subject: REMOVE Date: Wed, 10 Jan 2001 14:36:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3A5C8476.17877389@hns.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit REMOVE From owner-tcpsat@lerc.nasa.gov Wed Jan 10 17:02:24 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28561; Wed, 10 Jan 2001 17:02:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA22968 for tcpsat-outgoing; Wed, 10 Jan 2001 16:22:04 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA22918 for ; Wed, 10 Jan 2001 16:22:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA17093; Wed, 10 Jan 2001 16:21:59 -0500 Received: from fir.itsd.gov.bc.ca(142.32.11.82) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017010; Wed, 10 Jan 01 16:21:12 -0500 Received: from GEMINI.GOV.BC.CA (gemini.GOV.BC.CA [142.32.4.25]) by fir.itsd.gov.bc.ca (8.9.3/8.9.3) with ESMTP id NAA10770 for ; Wed, 10 Jan 2001 13:20:59 -0800 Received: from pipe.gov.bc.ca (pipe.bcsc.GOV.BC.CA) by venus.gov.bc.ca (PMDF V5.2-31 #35267) with ESMTP id <01JYQS5LJN5CR4J55X@venus.gov.bc.ca> for tcpsat@grc.nasa.gov; Wed, 10 Jan 2001 13:20:57 PST Received: by pipe.bcsc.GOV.BC.CA with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 13:20:59 -0800 Content-return: allowed Date: Wed, 10 Jan 2001 13:20:49 -0800 From: "Duggan, Bob R ISTA:EX" Subject: REMOVE To: tcpsat@grc.nasa.gov Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7BIT REMOVE From owner-tcpsat@lerc.nasa.gov Wed Jan 10 18:03:27 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02693; Wed, 10 Jan 2001 18:03:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA09056 for tcpsat-outgoing; Wed, 10 Jan 2001 17:27:39 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id RAA09050; Wed, 10 Jan 2001 17:27:36 -0500 (EST) Received: from katrinaljoy (ras113.lerc.nasa.gov [139.88.123.113]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id RAA14005; Wed, 10 Jan 2001 17:27:33 -0500 (EST) Message-Id: <4.1.20010110172217.00a4ab60@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Jan 2001 17:29:18 -0500 To: Anil Agarwal From: William D Ivancic Subject: Re: TCP end-to-end Semantics VPN question Cc: tcpsat@grc.nasa.gov In-Reply-To: <200101101544.f0AFiVE06961@pleiades.ntd.comsat.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2532476==_.ALT" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk --=====================_2532476==_.ALT Content-Type: text/plain; charset="us-ascii" Regarding spoofing: These questions regarding spoofing surfaced today in a meeting. I think I understand what will happen, but I would like your opinion. 1. If I am running an application that use TCP and using a Virtual Private Network, will spoofing improve my performance? 2. Can a spoofer be utilized in a mobile IP environment were to mobile host or mobile network switches to another network such as in a aeronautical internet? Will Ivancic ********************************************* William D. Ivancic NASA Glenn Research Center 21000 Brookpark Rd. MS 54-8 Cleveland, Ohio 44135 USA Phone: 1 216 433 3494 FAX: 1 216 433 8705 Email: William.D.Ivancic@grc.nasa.gov wivancic@grc.nasa.gov http://ctd.grc.nasa.gov/5610/5610.html ********************************************* --=====================_2532476==_.ALT Content-Type: text/html; charset="us-ascii" Regarding spoofing:

These questions regarding spoofing surfaced today in  a meeting.  I think I understand what will happen, but I would like your opinion.

1.  If I am running an application  that use TCP and using a Virtual Private Network, will spoofing improve my performance?

2.  Can a spoofer be utilized in a mobile IP environment were to mobile host  or mobile network switches to another network such as in a aeronautical internet?

Will Ivancic
*********************************************
William D. Ivancic
NASA Glenn Research Center
21000 Brookpark Rd.   MS 54-8
Cleveland, Ohio  44135
USA
Phone:   1 216 433 3494
FAX:     1 216 433 8705
Email:   William.D.Ivancic@grc.nasa.gov
             wivancic@grc.nasa.gov      
http://ctd.grc.nasa.gov/5610/5610.html  
*********************************************
 --=====================_2532476==_.ALT-- From owner-tcpsat@lerc.nasa.gov Wed Jan 10 20:17:28 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08175; Wed, 10 Jan 2001 20:17:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA25262 for tcpsat-outgoing; Wed, 10 Jan 2001 19:32:58 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA25221 for ; Wed, 10 Jan 2001 19:32:53 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA12102; Wed, 10 Jan 2001 19:32:51 -0500 Received: from labsun2.iss.comsat.com(134.133.12.62) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012056; Wed, 10 Jan 01 19:32:44 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun2.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f0B0WVc21087; Wed, 10 Jan 2001 19:32:31 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f0B0WVP08670; Wed, 10 Jan 2001 19:32:31 -0500 (EST) Date: Wed, 10 Jan 2001 19:32:31 -0500 (EST) From: Anil Agarwal Message-Id: <200101110032.f0B0WVP08670@pleiades.ntd.comsat.com> To: William.D.Ivancic@lerc.nasa.gov Subject: Re: TCP end-to-end Semantics Cc: tcpsat@grc.nasa.gov Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk In message <4.1.20010110172217.00a4ab60@popserve.lerc.nasa.gov>, William Ivancic wrote: >Regarding spoofing: > >These questions regarding spoofing surfaced today in a meeting. I think I >understand what will happen, but I would like your opinion. > >1. If I am running an application that use TCP and using a Virtual Private >Network, will spoofing improve my performance? I think the answer is NO. The spoofer will not recognize such packets as TCP packets and simply route them. One could come up with some clever way to spoof such connections, but if the VPN services include IPSec, then I think there is no hope. >2. Can a spoofer be utilized in a mobile IP environment were to mobile host >or mobile network switches to another network such as in a aeronautical >internet? > I do not know enough about mobile IP to answer that question; but here is my best guess. If the spoofer is located somewhere near the current base station, which changes as the mobile changes cell locations, and IP packets are routed from the destination via the current base station, then spoofing will probably not work. If the spoofer is located somewhere near the "home" base station, and if all packets get routed via the "home" base station, then spoofing can be made to work. Regards, Anil Agarwal LMGT From owner-tcpsat@lerc.nasa.gov Wed Jan 10 20:35:08 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08503; Wed, 10 Jan 2001 20:35:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA28113 for tcpsat-outgoing; Wed, 10 Jan 2001 20:02:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA28075 for ; Wed, 10 Jan 2001 20:02:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA15432; Wed, 10 Jan 2001 20:02:42 -0500 Received: from inet-exchange.tp.edu.sg(152.226.64.156) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015353; Wed, 10 Jan 01 20:01:46 -0500 Received: by INET-EXCHANGE with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 09:04:05 +0800 Message-ID: From: "Leong Kit Hoong, John" To: tcpsat@grc.nasa.gov Subject: REMOVE Date: Thu, 11 Jan 2001 09:03:39 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk REMOVE From owner-tcpsat@lerc.nasa.gov Thu Jan 11 02:26:39 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27164; Thu, 11 Jan 2001 02:26:37 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA26315 for tcpsat-outgoing; Thu, 11 Jan 2001 01:47:36 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA26279 for ; Thu, 11 Jan 2001 01:47:33 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA18980; Thu, 11 Jan 2001 01:47:31 -0500 Received: from sirius-giga.rz.uni-ulm.de(134.60.241.36) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018923; Thu, 11 Jan 01 01:46:55 -0500 Received: from rektoramt.uni-ulm.de (birgit.rektoramt.uni-ulm.de [134.60.45.15]) by mail.rz.uni-ulm.de (8.9.3/8.9.3) with ESMTP id HAA07957 for ; Thu, 11 Jan 2001 07:46:53 +0100 (MET) Message-ID: <3A5D57BB.218E81A1@rektoramt.uni-ulm.de> Date: Thu, 11 Jan 2001 07:50:35 +0100 From: Dr Karl-Heinz =?iso-8859-1?Q?M=FCller?= Organization: Universitaet Ulm X-Mailer: Mozilla 4.73 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: REMOVE Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.rz.uni-ulm.de id HAA07957 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id BAA26299 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id BAA26315 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA27164 -- REMOVE ---------------------------------------------------------------- University of Ulm, Dez I, Dept 1 Dr. Karl-Heinz Müller E.C./R&D Management in the President's Office D-89069 Ulm phone: +49-731-50-22010/2011 fax: +49-731-50-22016 e-mail: karl-heinz.mueller@rektoramt.uni-ulm.de http://www.uni-ulm.de From owner-tcpsat@lerc.nasa.gov Thu Jan 11 03:35:51 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27525; Thu, 11 Jan 2001 03:35:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA00835 for tcpsat-outgoing; Thu, 11 Jan 2001 03:02:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA00819 for ; Thu, 11 Jan 2001 03:02:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA25746; Thu, 11 Jan 2001 03:02:37 -0500 Received: from rmd250b.roma.alespazio.it(194.20.199.66) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025646; Thu, 11 Jan 01 03:01:36 -0500 Received: from eskycarducci1 ([172.21.5.57] (may be forged)) by rmd250b.roma.alespazio.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA09015 for ; Thu, 11 Jan 2001 09:00:20 +0100 (MET) Message-ID: <001301c07ba4$e3ee6b80$390515ac@eskyway> From: "Franco Carducci" To: References: Subject: REMOVE Date: Thu, 11 Jan 2001 09:02:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit From owner-tcpsat@lerc.nasa.gov Thu Jan 11 05:15:13 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28198; Thu, 11 Jan 2001 05:15:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA10258 for tcpsat-outgoing; Thu, 11 Jan 2001 04:25:05 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA10241 for ; Thu, 11 Jan 2001 04:25:03 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA04042; Thu, 11 Jan 2001 04:25:02 -0500 Received: from mta01.btfusion.com(62.172.195.11) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003982; Thu, 11 Jan 01 04:24:28 -0500 Received: from COMSYS01 ([213.121.90.12]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id G6ZRGQ00.G51 for ; Thu, 11 Jan 2001 09:24:26 +0000 From: "Steve O'Rourke" To: tcpsat@grc.nasa.gov Subject: Remove Date: Thu, 11 Jan 2001 09:25:18 +0000 Organization: Communication Systems Limited Reply-To: steve@comsys.co.uk Message-ID: <7uuq5tkepdmsse7h717o6mjft7i6ngu6a1@4ax.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id EAA10243 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Please remove the address niall@comsys.co.uk from this list as the employee no longer works here. From owner-tcpsat@lerc.nasa.gov Thu Jan 11 08:05:06 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29817; Thu, 11 Jan 2001 08:05:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA24470 for tcpsat-outgoing; Thu, 11 Jan 2001 07:17:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA24423 for ; Thu, 11 Jan 2001 07:16:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA20245; Thu, 11 Jan 2001 07:16:53 -0500 Received: from kryten.ee.ucl.ac.uk(128.40.38.7) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020205; Thu, 11 Jan 01 07:16:38 -0500 Received: from hannibal (hannibal [128.40.40.21]) by kryten.ee.ucl.ac.uk (8.9.3+Sun/8.9.1) with SMTP id MAA01813 for ; Thu, 11 Jan 2001 12:16:32 GMT Message-ID: <000a01c07bc8$1fe9b720$15282880@ee.ucl.ac.uk> From: "Ioannis Liabotis" To: References: <7uuq5tkepdmsse7h717o6mjft7i6ngu6a1@4ax.com> Subject: REMOVE Date: Thu, 11 Jan 2001 12:15:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit REMOVE From owner-tcpsat@lerc.nasa.gov Thu Jan 11 08:21:25 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00119; Thu, 11 Jan 2001 08:21:19 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA28229 for tcpsat-outgoing; Thu, 11 Jan 2001 07:44:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA28207 for ; Thu, 11 Jan 2001 07:44:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA23013; Thu, 11 Jan 2001 07:44:26 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022960; Thu, 11 Jan 01 07:44:18 -0500 Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14Gh5U-0000Ja-00 for tcpsat@grc.nasa.gov; Thu, 11 Jan 2001 12:44:16 +0000 Date: Thu, 11 Jan 2001 12:44:16 +0000 (GMT) From: Merkourios Karaliopoulos To: tcpsat@grc.nasa.gov Subject: Is there an archive of the list mails? In-Reply-To: <4.1.20010110172217.00a4ab60@popserve.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Sorry for intervening but is there any archive of the mailing list?Sometimes it becomes difficult to follow the debate... Thanks in advance Merkouris From owner-tcpsat@lerc.nasa.gov Thu Jan 11 08:59:38 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01073; Thu, 11 Jan 2001 08:59:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA07121 for tcpsat-outgoing; Thu, 11 Jan 2001 08:25:55 -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 IAA07105 for ; Thu, 11 Jan 2001 08:25:53 -0500 (EST) Received: from guns (mallman@localhost) by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id IAA01543; Thu, 11 Jan 2001 08:25:53 -0500 (EST) Message-Id: <200101111325.IAA01543@guns.lerc.nasa.gov> To: tcpsat@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: tcpsat administravia Organization: NASA GRC/BBN Technologies Song-of-the-Day: Sweet Home Alabama Date: Thu, 11 Jan 2001 08:25:53 -0500 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Folks- I'm repeating this because of the level of administrative spam that has been sent to the list recently. If you want off the tcpsat mailing list the way to go about it is to follow the instructions you were sent when you subscribed or are available on the tcpsat web page: http://tcpsat.grc.nasa.gov/tcpsat/ The basic method is to send "unsubscribe tcpsat" in the body of a message to majordomo@grc.nasa.gov. If you continue to have problems after attempting to use majorodomo feel free to drop me a note and I'll see what is wrong (but, only **after** you try majordomo -- my inbox is a priority queue and all). Thanks to the few folks who tried to send unsubscribe instructions to the mailing list yesterday. As Mr. Murphy is a constant companion of mine, those messages were caught in the "spam filter", but the remove requests flew right through. Grr... allman --- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ From owner-tcpsat@lerc.nasa.gov Thu Jan 11 12:10:15 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08734; Thu, 11 Jan 2001 12:10:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA28822 for tcpsat-outgoing; Thu, 11 Jan 2001 11:15:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA28767 for ; Thu, 11 Jan 2001 11:15:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id LAA23086; Thu, 11 Jan 2001 11:15:09 -0500 Received: from btbntsys2.yucom.be(212.8.180.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022898; Thu, 11 Jan 01 11:14:06 -0500 Received: from mail pickup service by btbntsys2 with Microsoft SMTPSVC; Thu, 11 Jan 2001 16:57:50 +0100 Received: (apparently) from btbntsys1 ([212.8.180.1]) by 212.8.180.2 with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 11 Jan 2001 15:07:26 +0100 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by btbntsys1 with Microsoft SMTPSVC(5.5.1877.197.19); Thu, 11 Jan 2001 15:05:53 +0100 Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA24470 for tcpsat-outgoing; Thu, 11 Jan 2001 07:17:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA24423 for ; Thu, 11 Jan 2001 07:16:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA20245; Thu, 11 Jan 2001 07:16:53 -0500 Received: from kryten.ee.ucl.ac.uk(128.40.38.7) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020205; Thu, 11 Jan 01 07:16:38 -0500 Received: from hannibal (hannibal [128.40.40.21]) by kryten.ee.ucl.ac.uk (8.9.3+Sun/8.9.1) with SMTP id MAA01813 for ; Thu, 11 Jan 2001 12:16:32 GMT Message-ID: <000a01c07bc8$1fe9b720$15282880@ee.ucl.ac.uk> From: "Ioannis Liabotis" To: References: <7uuq5tkepdmsse7h717o6mjft7i6ngu6a1@4ax.com> Subject: REMOVE Date: Thu, 11 Jan 2001 12:15:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit REMOVE From owner-tcpsat@lerc.nasa.gov Fri Jan 12 10:21:47 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10452; Fri, 12 Jan 2001 10:21:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA29408 for tcpsat-outgoing; Fri, 12 Jan 2001 09:29:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA29376 for ; Fri, 12 Jan 2001 09:29:14 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id JAA25255; Fri, 12 Jan 2001 09:29:13 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025176; Fri, 12 Jan 01 09:28:48 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14H5C3-000492-00; Fri, 12 Jan 2001 14:28:39 +0000 Date: Fri, 12 Jan 2001 14:28:40 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Mingyan Liu cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Wed, 10 Jan 2001, Mingyan Liu wrote: > How about we use an IP option indicating "spoofing (not) allowed", > similar to "no fragmentation", and require that the spoofer conform to > it, will that make sense? (This then will not require user's knowledge > but the application writers'...) You can always spoof such an option, making it worthless. L. PGP From owner-tcpsat@lerc.nasa.gov Sat Jan 13 00:29:59 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02047; Sat, 13 Jan 2001 00:29:58 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA11760 for tcpsat-outgoing; Fri, 12 Jan 2001 23:54:57 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA11738 for ; Fri, 12 Jan 2001 23:54:55 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA07287; Fri, 12 Jan 2001 23:54:54 -0500 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007249; Fri, 12 Jan 01 23:54:19 -0500 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id UAA17445; Fri, 12 Jan 2001 20:54:16 -0800 (PST) Date: Fri, 12 Jan 2001 20:54:16 -0800 (PST) From: Alhussein Abouzeid To: Mingyan Liu cc: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I think it is a good idea assuming the spoofer will respect it (which would be expected from a 'good' spoofer). -Hussein. > On Wed, 10 Jan 2001, Mingyan Liu wrote: > How about we use an IP option indicating "spoofing (not) allowed", > similar to "no fragmentation", and require that the spoofer conform to > it, will that make sense? (This then will not require user's knowledge > but the application writers'...) From owner-tcpsat@lerc.nasa.gov Sat Jan 13 03:07:18 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15729; Sat, 13 Jan 2001 03:07:18 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA18916 for tcpsat-outgoing; Sat, 13 Jan 2001 02:28:14 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id CAA18909 for ; Sat, 13 Jan 2001 02:28:12 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id CAA20126; Sat, 13 Jan 2001 02:28:11 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020081; Sat, 13 Jan 01 02:27:29 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.100] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA23057; Sat, 13 Jan 2001 02:26:29 -0500 (EST) Message-Id: <5.0.2.1.2.20010113152427.032ab200@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 13 Jan 2001 15:25:17 +0800 To: Alhussein Abouzeid From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: Mingyan Liu , tcpsat@grc.nasa.gov In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 08:54 PM 1/12/01 -0800, Alhussein Abouzeid wrote: >I think it is a good idea assuming the spoofer will respect it (which >would be expected from a 'good' spoofer). practically speaking, it would be a terrible idea. Options don't work well with a largeish number of the routers out there. The presence of an option kicks the message out of the fast path. From owner-tcpsat@lerc.nasa.gov Sat Jan 13 03:45:08 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15817; Sat, 13 Jan 2001 03:45:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA22225 for tcpsat-outgoing; Sat, 13 Jan 2001 03:16:43 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA22204 for ; Sat, 13 Jan 2001 03:16:41 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA24182; Sat, 13 Jan 2001 03:16:39 -0500 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024142; Sat, 13 Jan 01 03:16:18 -0500 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id AAA23819; Sat, 13 Jan 2001 00:16:15 -0800 (PST) Date: Sat, 13 Jan 2001 00:16:14 -0800 (PST) From: Alhussein Abouzeid To: Fred Baker cc: Mingyan Liu , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010113152427.032ab200@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Sat, 13 Jan 2001, Fred Baker wrote: > At 08:54 PM 1/12/01 -0800, Alhussein Abouzeid wrote: > >I think it is a good idea assuming the spoofer will respect it (which > >would be expected from a 'good' spoofer). > > practically speaking, it would be a terrible idea. Options don't work well > with a largeish number of the routers out there. The presence of an option > kicks the message out of the fast path. > I don't see that point coming up with a lot of option proposals, like, say, ECN? From owner-tcpsat@lerc.nasa.gov Sat Jan 13 04:01:43 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15872; Sat, 13 Jan 2001 04:01:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA23366 for tcpsat-outgoing; Sat, 13 Jan 2001 03:33:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA23357 for ; Sat, 13 Jan 2001 03:33:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA25691; Sat, 13 Jan 2001 03:33:56 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma025653; Sat, 13 Jan 01 03:33:02 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.100] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id DAA25834; Sat, 13 Jan 2001 03:32:08 -0500 (EST) Message-Id: <5.0.2.1.2.20010113162927.0327e140@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 13 Jan 2001 16:30:44 +0800 To: Alhussein Abouzeid From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: Mingyan Liu , tcpsat@grc.nasa.gov In-Reply-To: References: <5.0.2.1.2.20010113152427.032ab200@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 12:16 AM 1/13/01 -0800, Alhussein Abouzeid wrote: >I don't see that point coming up with a lot of option proposals, like, >say, ECN? ECN has no options. It has two bits in the IP header and two bits in the TCP header, which are already there and are not used. And yes, it comes up about every time someone decides they want an option. You can define them all you want, but plan on messages containing options getting dropped by popular ISPs. From owner-tcpsat@lerc.nasa.gov Sat Jan 13 05:04:54 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16093; Sat, 13 Jan 2001 05:04:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA27146 for tcpsat-outgoing; Sat, 13 Jan 2001 04:35:27 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA27137 for ; Sat, 13 Jan 2001 04:35:25 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA01166; Sat, 13 Jan 2001 04:35:25 -0500 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001114; Sat, 13 Jan 01 04:34:59 -0500 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id BAA25860; Sat, 13 Jan 2001 01:34:56 -0800 (PST) Date: Sat, 13 Jan 2001 01:34:54 -0800 (PST) From: Alhussein Abouzeid To: Fred Baker cc: Mingyan Liu , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010113162927.0327e140@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Sat, 13 Jan 2001, Fred Baker wrote: > At 12:16 AM 1/13/01 -0800, Alhussein Abouzeid wrote: > >I don't see that point coming up with a lot of option proposals, like, > >say, ECN? > > ECN has no options. It has two bits in the IP header and two bits in the > TCP header, which are already there and are not used. Why not use one of them for the spoofing/no-spoofing signal:) Is ECN more important? You bet it is. ECN *is* an option. TCP may or may not use it. It requires support from the routers. ENS (Explicitly No Spoofing) can also be a similar option? > > And yes, it comes up about every time someone decides they want an option. True. > You can define them all you want, but plan on messages containing options > getting dropped by popular ISPs. > I don't think this is the issue. A lot of popular ISP's have not implemented ECN anyway, but there is no doubt ECN will soon enough become a standard. The issue is whether there are considerable gains that call for defining and using such a bit within the IETF standards. And to drive this point home, I really don't think that the reluctance of such "ISP's" to improve their "IS" should ever be a factor in the evolution of protocols. -Hussein. From owner-tcpsat@lerc.nasa.gov Sat Jan 13 05:27:00 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16149; Sat, 13 Jan 2001 05:26:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA28036 for tcpsat-outgoing; Sat, 13 Jan 2001 04:57:56 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA28019 for ; Sat, 13 Jan 2001 04:57:54 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA03255; Sat, 13 Jan 2001 04:57:51 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003194; Sat, 13 Jan 01 04:57:41 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.100] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA28683; Sat, 13 Jan 2001 04:56:40 -0500 (EST) Message-Id: <5.0.2.1.2.20010113175353.032a9210@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 13 Jan 2001 17:56:05 +0800 To: Alhussein Abouzeid From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: Mingyan Liu , tcpsat@grc.nasa.gov In-Reply-To: References: <5.0.2.1.2.20010113162927.0327e140@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 01:34 AM 1/13/01 -0800, Alhussein Abouzeid wrote: >ECN *is* an option. TCP may or may not use it. we are somehow using entirely different definitions of the word "option". I am using it in the sense the word is used in RFC 791 and 793; you are using it, I think, in the sense "something that is optional". I'm not convinced I know what bits you're going to find in the IP or TCP headers that are left for doing "something that is optional", but if you can, be my guest. That said, IP Options are a problem. Really. From owner-tcpsat@lerc.nasa.gov Mon Jan 15 16:38:26 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16150; Mon, 15 Jan 2001 16:38:25 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA05282 for tcpsat-outgoing; Mon, 15 Jan 2001 16:01:24 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA05274 for ; Mon, 15 Jan 2001 16:01:23 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA02292; Mon, 15 Jan 2001 13:51:55 -0500 Received: from po3.wam.umd.edu(128.8.10.165) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002261; Mon, 15 Jan 01 13:51:10 -0500 Received: from rac5.wam.umd.edu (IDENT:root@rac5.wam.umd.edu [128.8.10.145]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA15061; Mon, 15 Jan 2001 13:51:05 -0500 (EST) Received: from rac5.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac5.wam.umd.edu (8.9.3/8.9.3) with SMTP id NAA18524; Mon, 15 Jan 2001 13:51:04 -0500 (EST) Received: from localhost (karir@localhost) by rac5.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA18520; Mon, 15 Jan 2001 13:51:04 -0500 (EST) X-Authentication-Warning: rac5.wam.umd.edu: karir owned process doing -bs Date: Mon, 15 Jan 2001 13:51:04 -0500 (EST) From: Manish Karir To: Fred Baker cc: Alhussein Abouzeid , Mingyan Liu , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics In-Reply-To: <5.0.2.1.2.20010113175353.032a9210@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Sat, 13 Jan 2001, Fred Baker wrote: > At 01:34 AM 1/13/01 -0800, Alhussein Abouzeid wrote: > >ECN *is* an option. TCP may or may not use it. > > we are somehow using entirely different definitions of the word "option". I > am using it in the sense the word is used in RFC 791 and 793; you are using > it, I think, in the sense "something that is optional". > > I'm not convinced I know what bits you're going to find in the IP or TCP > headers that are left for doing "something that is optional", but if you > can, be my guest. actually there can be any number of ways of doing this as long as the consensus and approval of the ietf is there... for example: -the protocol field could be used to identify the packets to be spoofed. so we would have TCP, or TCP-SPOOF to distinguish between the two. (I personally think this is a good idea...if what spoofing does is break traditional TCP then why call it TCP..just call it something else...) -a particular combination of the flags: say for example DF combined with SYN combined with FIN but no ACK will mean -dont spoof (bad idea I know..but once again....feasible..) -or how about a certain combination of bits in the TOS field... (after all is'nt the purpose of the ToS field to be able to identify flows of different types for processing different....so we can specify that say ToS value of x shall mean the flow should not be spoofed or should be spoofed) anyways.....just some random thoughts... manish From owner-tcpsat@lerc.nasa.gov Mon Jan 15 16:39:39 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16166; Mon, 15 Jan 2001 16:39:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA02033 for tcpsat-outgoing; Mon, 15 Jan 2001 15:52:33 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA02008 for ; Mon, 15 Jan 2001 15:52:30 -0500 (EST) From: carfred@embratel.com.br Received: by seraph3.lerc.nasa.gov; id PAA07956; Mon, 15 Jan 2001 15:07:01 -0500 Received: from gatekeeper1.embratel.com.br(200.255.122.6) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007919; Mon, 15 Jan 01 15:06:12 -0500 Received: by gatekeeper1.embratel.com.br; (8.8.8/1.3/10May95) id SAA26359; Mon, 15 Jan 2001 18:03:23 -0200 (EDT) Received: from ntrjo008a.nt.embratel.com.br by mailgate.embratel.com.br (8.8.8/1.1.22.3/11Jun99-0127PM) id SAA0000021763; Mon, 15 Jan 2001 18:06:32 -0200 (EDT) Received: by ntrjo008a.nt.embratel.com.br(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 032569D5.0073ECA8 ; Mon, 15 Jan 2001 18:06:12 -0300 X-Lotus-FromDomain: EMBRATEL To: tcpsat@grc.nasa.gov Message-ID: <032569D5.0073E6FB.00@ntrjo008a.nt.embratel.com.br> Date: Mon, 15 Jan 2001 18:07:02 -0300 Subject: REMOVE Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk From owner-tcpsat@lerc.nasa.gov Mon Jan 15 16:40:15 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16198; Mon, 15 Jan 2001 16:40:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA05907 for tcpsat-outgoing; Mon, 15 Jan 2001 16:03:37 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA05890 for ; Mon, 15 Jan 2001 16:03:36 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA01370; Mon, 15 Jan 2001 13:38:10 -0500 Received: from po3.wam.umd.edu(128.8.10.165) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001206; Mon, 15 Jan 01 13:37:40 -0500 Received: from rac5.wam.umd.edu (IDENT:root@rac5.wam.umd.edu [128.8.10.145]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA14670 for ; Mon, 15 Jan 2001 13:37:39 -0500 (EST) Received: from rac5.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac5.wam.umd.edu (8.9.3/8.9.3) with SMTP id NAA16425 for ; Mon, 15 Jan 2001 13:37:38 -0500 (EST) Received: from localhost (karir@localhost) by rac5.wam.umd.edu (8.9.3/8.9.3) with ESMTP id NAA16421 for ; Mon, 15 Jan 2001 13:37:38 -0500 (EST) X-Authentication-Warning: rac5.wam.umd.edu: karir owned process doing -bs Date: Mon, 15 Jan 2001 13:37:38 -0500 (EST) From: Manish Karir To: tcpsat@grc.nasa.gov Subject: spoofing standard?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk I think there is probably enough support on this list and real implementation experience to generate some sort of a spoofing standard? if nothing else an informational document which summarizes the most "correct" way of implementing this. I know there have been papers and descriptions of this before, but something which has the blessings of more than just the authors would be quite useful...that way we would atleast have a common base to argue about :) does anyone else agree on the need for such a document?? manish karir From owner-tcpsat@lerc.nasa.gov Mon Jan 15 19:09:17 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17857; Mon, 15 Jan 2001 19:09:16 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA16391 for tcpsat-outgoing; Mon, 15 Jan 2001 18:32:41 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA16367 for ; Mon, 15 Jan 2001 18:32:39 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA23037; Mon, 15 Jan 2001 18:32:37 -0500 Received: from labsun2.iss.comsat.com(134.133.12.62) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022959; Mon, 15 Jan 01 18:31:41 -0500 Received: from pleiades.ntd.comsat.com (pleiades.ntd.comsat.com [134.133.80.40]) by labsun2.iss.comsat.com (8.10.2/8.10.2) with ESMTP id f0FNVGc24946; Mon, 15 Jan 2001 18:31:17 -0500 (EST) Received: (from agarwal@localhost) by pleiades.ntd.comsat.com (8.10.2/8.10.2) id f0FNVGd12881; Mon, 15 Jan 2001 18:31:16 -0500 (EST) Date: Mon, 15 Jan 2001 18:31:16 -0500 (EST) From: Anil Agarwal Message-Id: <200101152331.f0FNVGd12881@pleiades.ntd.comsat.com> To: karir@wam.umd.edu Subject: Re: spoofing standard?? Cc: tcpsat@grc.nasa.gov Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Jan 15, 2001, Manish Karir wrote: >I think there is probably enough support on this list and real >implementation experience to generate some sort of a spoofing >standard? > >if nothing else an informational document which summarizes the >most "correct" way of implementing this. I know there have been >papers and descriptions of this before, but something which has the >blessings of more than just the authors would be quite useful...that way >we would atleast have a common base to argue about :) > >does anyone else agree on the need for such a document?? > >manish karir I agree wholeheartedly. It would certainly provide value to the Internet to have "robust" spoofing implementations, even though their use may not be encouraged, except for special environments, such as satellite or wireless networks. Anil Agarwal LMGT 22300 COMSAT Drive Clarksburg, MD 20871 301-428-4655 From owner-tcpsat@lerc.nasa.gov Mon Jan 15 19:30:42 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18071; Mon, 15 Jan 2001 19:30:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA17879 for tcpsat-outgoing; Mon, 15 Jan 2001 19:00:10 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA17856 for ; Mon, 15 Jan 2001 19:00:08 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA24858; Mon, 15 Jan 2001 19:00:07 -0500 Received: from web1305.mail.yahoo.com(128.11.23.155) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024790; Mon, 15 Jan 01 18:59:40 -0500 Received: (qmail 5380 invoked by uid 60001); 15 Jan 2001 23:59:36 -0000 Message-ID: <20010115235936.5379.qmail@web1305.mail.yahoo.com> Received: from [208.7.230.60] by web1305.mail.yahoo.com; Mon, 15 Jan 2001 15:59:36 PST Date: Mon, 15 Jan 2001 15:59:36 -0800 (PST) From: Pradeep Agrawal Subject: REMOVE To: tcpsat@grc.nasa.gov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-tcpsat@lerc.nasa.gov Mon Jan 15 20:59:27 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18763; Mon, 15 Jan 2001 20:59:27 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA23110 for tcpsat-outgoing; Mon, 15 Jan 2001 20:20:35 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA23097 for ; Mon, 15 Jan 2001 20:20:34 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id UAA00754; Mon, 15 Jan 2001 20:20:32 -0500 Received: from dogwood.cisco.com(161.44.11.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000712; Mon, 15 Jan 01 20:20:19 -0500 Received: from p7020-img-nt.cisco.com ([64.104.42.113] (may be forged)) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA05603; Mon, 15 Jan 2001 20:18:34 -0500 (EST) Message-Id: <5.0.2.1.2.20010116082546.03eed150@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 16 Jan 2001 08:26:00 +0800 To: Manish Karir From: Fred Baker Subject: Re: TCP end-to-end Semantics Cc: Alhussein Abouzeid , Mingyan Liu , tcpsat@grc.nasa.gov In-Reply-To: References: <5.0.2.1.2.20010113175353.032a9210@flipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk At 01:51 PM 1/15/01 -0500, Manish Karir wrote: >-or how about a certain combination of bits in the TOS field... that would be the diff-serv code point, no? From owner-tcpsat@lerc.nasa.gov Mon Jan 15 22:39:00 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21406; Mon, 15 Jan 2001 22:38:59 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA00680 for tcpsat-outgoing; Mon, 15 Jan 2001 21:59:18 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA00672 for ; Mon, 15 Jan 2001 21:59:16 -0500 (EST) From: aaron@panamsat.com Received: by seraph3.lerc.nasa.gov; id VAA07007; Mon, 15 Jan 2001 21:59:15 -0500 Received: from unknown(208.217.183.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006979; Mon, 15 Jan 01 21:59:01 -0500 Received: by atlconn1.panamsat.com with Internet Mail Service (5.5.2650.10) id ; Mon, 15 Jan 2001 21:59:00 -0500 Message-ID: <0703A3E1D430D411866100508BDFCF3328B5B8@CTOEXCH1> To: karir@wam.umd.edu Cc: tcpsat@grc.nasa.gov Subject: RE: spoofing standard?? Date: Mon, 15 Jan 2001 21:56:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="windows-1252" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Manish- At the time we discussed this issue during the formation of TCPSAT and PILC there was no support in the IETF to standardize ways of spoofing TCP. Our compromise, and I thought it was a good one, was to write a document desribing the ways that people spoofed TCP, why they felt they needed to do it, and to document the risks associated with different mechanisms. This document has been developed in the PILC working group, has finished working group last call, and is in review by the IESG for publication as an Informational RFC -- not an IETF standard. You can find a copy at http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-05.txt. --aaron > -----Original Message----- > From: Manish Karir [mailto:karir@wam.umd.edu] > Sent: Monday, January 15, 2001 1:38 PM > To: tcpsat@grc.nasa.gov > Subject: spoofing standard?? > > > > I think there is probably enough support on this list and real > implementation experience to generate some sort of a spoofing > standard? > > if nothing else an informational document which summarizes the > most "correct" way of implementing this. I know there have been > papers and descriptions of this before, but something which has the > blessings of more than just the authors would be quite > useful...that way > we would atleast have a common base to argue about :) > > does anyone else agree on the need for such a document?? > > manish karir > > > From owner-tcpsat@lerc.nasa.gov Tue Jan 16 00:06:01 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22599; Tue, 16 Jan 2001 00:06:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA06555 for tcpsat-outgoing; Mon, 15 Jan 2001 23:35:46 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA06518 for ; Mon, 15 Jan 2001 23:35:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id XAA13473; Mon, 15 Jan 2001 23:35:39 -0500 Received: from maxwell.ee.washington.edu(128.95.42.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013458; Mon, 15 Jan 01 23:35:38 -0500 Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.3]) by maxwell.ee.washington.edu (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id UAA16354; Mon, 15 Jan 2001 20:35:33 -0800 (PST) Date: Mon, 15 Jan 2001 20:35:33 -0800 (PST) From: Alhussein Abouzeid To: Anil Agarwal cc: karir@wam.umd.edu, tcpsat@grc.nasa.gov Subject: Re: spoofing standard?? In-Reply-To: <200101152331.f0FNVGd12881@pleiades.ntd.comsat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk On Mon, 15 Jan 2001, Anil Agarwal wrote: > On Jan 15, 2001, Manish Karir wrote: > > >I think there is probably enough support on this list and real > >implementation experience to generate some sort of a spoofing > >standard? > > > >if nothing else an informational document which summarizes the > >most "correct" way of implementing this. I know there have been > >papers and descriptions of this before, but something which has the > >blessings of more than just the authors would be quite useful...that way > >we would atleast have a common base to argue about :) > > > >does anyone else agree on the need for such a document?? > > > >manish karir > > I agree wholeheartedly. Same Here. -Hussein. > > It would certainly provide value to the Internet to have > "robust" spoofing implementations, even though their use may not be > encouraged, except for special environments, such as satellite or wireless > networks. > > Anil Agarwal > LMGT > 22300 COMSAT Drive > Clarksburg, MD 20871 > 301-428-4655 > From owner-tcpsat@lerc.nasa.gov Tue Jan 16 02:43:55 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06908; Tue, 16 Jan 2001 02:43:54 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id CAA05178 for tcpsat-outgoing; Tue, 16 Jan 2001 02:03:47 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA27468; Tue, 16 Jan 2001 01:50:40 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA22184; Tue, 16 Jan 2001 01:50:39 -0500 Received: from unknown(140.192.32.72) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022172; Tue, 16 Jan 01 01:50:30 -0500 Received: from EHAB2K ([140.192.34.122]) by CHOPIN.cti.depaul.edu with Microsoft SMTPSVC(5.0.2195.1600); Tue, 16 Jan 2001 00:50:19 -0600 Message-ID: <059c01c07f88$97885cf0$7a22c08c@cti.depaul.edu> From: "Ehab Al-Shaer" To: Subject: MMNS 2001 Call For Papers Date: Tue, 16 Jan 2001 00:50:19 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0599_01C07F56.4CD3FC50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 16 Jan 2001 06:50:19.0776 (UTC) FILETIME=[9757B000:01C07F88] Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0599_01C07F56.4CD3FC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable << OUR APOLOGIES FOR MULTIPLE COPIES >> CALL FOR PAPERS Fourth IFIP/IEEE International Conference on=20 Management of Multimedia Networks and Services (MMNS'2001) October 29- November 1, 2001 Chicago, Illinois, USA (http://www.mnlab.cs.depaul.edu/mmns2001) The IFIP/IEEE International Conference on Management of Multimedia = Networks and Services=20 will hold its fourth annual meeting Oct. 29 through Nov 1, 2001 in = Chicago. The IFIP/IEEE=20 MMNS is the premier IEEE/IFIP conferences focusing on management of = multimedia networks=20 and services. The conference will bring together researchers and = practitioners working in=20 the network and service management and present the latest development in = the field.=20 IFIP/IEEE MMNS uses single-track presentations, which provide an = intimate setting for=20 discussion and debate. The conference is known for its high-quality = papers from various=20 research communities. Selected papers will also be considered for = publication as a special=20 issue of the Journal of High Speed Networking and Journal of Networks = and Information=20 Systems. Of specific interest to MMNS2001 is the management of = multimedia in the Internet.=20 The program committee is soliciting original papers describing research = in the area of=20 management of multimedia networks and services. MMNS 2001 will provide = Travel and=20 Conference Scholarships for students. Topics of interest include, but = are not limited to,=20 the following: Distributed multimedia service management Integration of network control and management Network management models and architectures Distributed event correlation Monitoring QoS management Multimedia traffic management Resource, performance and fault management for broadband networks Configuration management of edge and core services for enabling multimedia traffic management Multi-point and multicast services management Resource management in wireless multimedia Wireless and mobile network management Mobility management Management of ad-hoc networks Multimedia content protection Deployment of multimedia services Active network management Network programmability for multimedia services Middleware support for management=20 Multimedia session management Packet scheduling and dropping techniques Multimedia service Engineering Billing and security for broadband networks Policy-based management for multimedia service PAPER SUBMISSION Papers must be submitted electronically (postscript or PDF format only). = Detailed instructions are provided at = .=20 Paper length is limited to 20 double-spaced pages. The paper cover page = must included:=20 title of paper, authors' names and affiliations, contact author's name = and address (both=20 postal and electronic), a short abstract, keywords, and submission area = (from the list of=20 relevant topics of interest). For any further information, you can = direct your questions=20 to mmns2001@cs.depaul.edu IMPORTANT DATES Submission deadline: April 20, 2001 Notification of acceptance: July 1, 2001 Final version due: July 21, 2001 Conference: October 29 to Nov 1, 2001 Conference CO-CHAIRS=20 Ehab Al-Shaer, DePaul University,=20 USA Giovanni Pacifici, IBM Research, USA=20 TUTORIAL CHAIR=20 Mohammed Atiquzzaman, U of Oklahoma, USA LOCAL PUBLICITY CHAIR Curt White, DePaul University=20 ORGANIZATION COMMITTEE CHAIR Greg Brewster, DePaul University=20 ADVISORY COMMITTEE=20 Raouf Boutaba, Univ. of Waterloo, Canada=20 Guy Pujolle, U. Pierre & Marie Curie, France=20 Wolfgang Zimmer, GMD FIRST, Germany=20 PROGRAM COMMITTEE=20 Ahmed Abutaleb, Lucent Technology, USA Nazim Agoulmine, Univ of Evry, France Salah Aidarous, NEC America, USA Kevin Almeroth, UC Santa Barbara, USA Nikos Anerousis, VoiceMate.com, USA Mohammed Atiquzzaman, U. of Oklahoma, USA Michael Borella, 3Com, USA Mohamed Bettaz, Philadelphia U., Jordan Andrew Campbell, Columbia University, USA Jean Pierre Claud=E9, U. of Versailles, France Metin Feridun, IBM Research, Switzerland Dominique Gaiti, U. of Troyes, France Leon A. Garcia, U. of Toronto, Canada German Goldszmidt, IBM Research, USA Mohsen Guizani, U. of West Florida, USA Abdelhakim Hafid, Telcordia, NJ, USA Masum Hasan, Cisco Systems, USA Go Hasegawa, Osaka University, Japan Ahmed Helmy, USC, USA Jean-Pierre Hubaux, EPFL, Switzerland=20 Joaquim Celestino J=FAnior, UECE, Brazil Ahmed Karmouch, U. of Ottawa, Canada Derong Liu, Univ of Illinois at Chicago, USA Manu Malek, Lucent technology, USA Allen Marshall, Queen's Univeersity, UK Subrata Mazumdar, Bell Laboratories, USA Ahmed Mehaoua, U. of Versailles, France Jose M. Nogueira, U. Minas Gerais, Brazil Jan Roos, U. of Pretoria, South Africa Jong-Tae Park, Kyungpook National U., Korea Punnet Sharma, HP Labs, USA Yuval Shavitt, Tel Aviv U. and Bell Labs, USA Chien-Chung Shen, Univ of Delaware, USA=20 Rolf Stadler, CTR/Columbia U., USA Burkhard Stiller, ETH Zurich, Switzerland Ralf Steinmetz, GMD., Germany Jose Neuman de Souza, U. Fed. do Ceara, Brazil Yechiam Yemini, Columbia U., USA Alaa Youssef, IBM Research, USA Douglas N. Zuckerman, Telcordia, USA ORGANIZATION COMMITTEE=20 Aftab Ahmad, DePaul University=20 Mouayad Albaghdad, Motorola Anthony Chung, DePaul University=20 Ramy Khasawneh, DePaul University Hazem Hamed, DePaul University Ye Guanhua, DePaul University Yonnning Tang, DePaul University Bin Zhang, DePaul University Qiao Zhang, DePaul University=20 MBONE Broadcast Specialist John Kristoff, DePaul University ------=_NextPart_000_0599_01C07F56.4CD3FC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<< OUR=20 APOLOGIES FOR MULTIPLE COPIES  >>
CALL FOR PAPERS
 
Fourth IFIP/IEEE International = Conference on=20
Management of Multimedia Networks and Services = (MMNS'2001)
 
October 29- November 1, = 2001
Chicago, Illinois,=20 USA
(http://www.mnlab.cs.depa= ul.edu/mmns2001)
 
The IFIP/IEEE International Conference = on=20 Management of Multimedia Networks and Services
will hold its fourth = annual=20 meeting Oct. 29 through Nov 1, 2001 in Chicago. The IFIP/IEEE
MMNS = is the=20 premier IEEE/IFIP conferences focusing on management of multimedia = networks=20
and services. The conference will bring together researchers and=20 practitioners working in
the network and service management and = present the=20 latest development in the field.
IFIP/IEEE MMNS uses single-track=20 presentations, which provide an intimate setting for
discussion and = debate.=20 The conference is known for its high-quality papers from various =
research=20 communities. Selected papers will also be considered for publication as = a=20 special
issue of the Journal of High Speed Networking and Journal of = Networks and Information
Systems. Of specific interest to MMNS2001 = is the=20 management of multimedia in the Internet.
The program committee is=20 soliciting original papers describing research in the area of =
management of=20 multimedia networks and services. MMNS 2001 will provide Travel and=20
Conference Scholarships for students. Topics of interest include, = but are=20 not limited to,
the following:
 
Distributed multimedia service=20 management
Integration of network control and management
Network=20 management models and architectures
Distributed event=20 correlation
Monitoring
QoS management
Multimedia traffic=20 management
Resource, performance and fault management for broadband=20 networks
Configuration management of edge and core services for=20 enabling
multimedia traffic management
Multi-point and multicast = services=20 management
Resource management in wireless multimedia
Wireless and = mobile=20 network management
Mobility management
Management of ad-hoc=20 networks
Multimedia content protection
Deployment of multimedia=20 services
Active network management
Network programmability for = multimedia=20 services
Middleware support for management
Multimedia session=20 management
Packet scheduling and dropping techniques
Multimedia = service=20 Engineering
Billing and security for broadband = networks
Policy-based=20 management for multimedia service
 
PAPER SUBMISSION
 
Papers must be submitted electronically = (postscript=20 or PDF format only).
Detailed instructions are provided at <http://www.mnlab.cs.depa= ul.edu/mmns2001>.=20
Paper length is limited to 20 double-spaced pages. The paper cover = page must=20 included:
title of paper, authors' names and affiliations, contact = author's=20 name and address (both
postal and electronic), a short abstract, = keywords,=20 and submission area (from the list of
relevant topics of interest). = For any=20 further information, you can direct your questions
to mmns2001@cs.depaul.edu<= /DIV>
 
IMPORTANT DATES
Submission = deadline:  April=20 20, 2001
Notification of acceptance: July 1, 2001
Final version = due: =20 July 21, 2001
Conference:   October 29 to Nov 1, = 2001
 
Conference CO-CHAIRS
Ehab Al-Shaer, = DePaul=20 University,
USA Giovanni Pacifici, IBM Research, USA
 
TUTORIAL CHAIR
Mohammed = Atiquzzaman, U of=20 Oklahoma, USA
 
LOCAL PUBLICITY CHAIR
Curt White, = DePaul=20 University
 
ORGANIZATION COMMITTEE CHAIR
Greg = Brewster,=20 DePaul University
 
ADVISORY COMMITTEE
Raouf Boutaba, = Univ. of=20 Waterloo, Canada
Guy Pujolle, U. Pierre & Marie Curie, France=20
Wolfgang Zimmer, GMD FIRST, Germany
 
PROGRAM COMMITTEE
Ahmed Abutaleb, = Lucent=20 Technology, USA
Nazim Agoulmine, Univ of Evry, France
Salah = Aidarous, NEC=20 America, USA
Kevin Almeroth, UC Santa Barbara, USA
Nikos = Anerousis,=20 VoiceMate.com, USA
Mohammed Atiquzzaman, U. of Oklahoma, = USA
Michael=20 Borella, 3Com, USA
Mohamed Bettaz, Philadelphia U., Jordan
Andrew=20 Campbell, Columbia University, USA
Jean Pierre Claud=E9, U. of = Versailles,=20 France
Metin Feridun, IBM Research, Switzerland
Dominique Gaiti, = U. of=20 Troyes, France
Leon A. Garcia, U. of Toronto, Canada
German = Goldszmidt,=20 IBM Research, USA
Mohsen Guizani, U. of West Florida, = USA
Abdelhakim=20 Hafid, Telcordia, NJ, USA
Masum Hasan, Cisco Systems,  USA
Go = Hasegawa, Osaka University, Japan
Ahmed Helmy, USC, = USA
Jean-Pierre=20 Hubaux, EPFL, Switzerland
Joaquim Celestino J=FAnior, UECE, = Brazil
Ahmed=20 Karmouch, U. of Ottawa, Canada
Derong Liu, Univ of Illinois at = Chicago,=20 USA
Manu Malek, Lucent technology, USA
Allen Marshall, Queen's=20 Univeersity, UK
Subrata Mazumdar, Bell Laboratories, USA
Ahmed = Mehaoua, U.=20 of Versailles, France
Jose M. Nogueira, U. Minas Gerais, = Brazil
Jan Roos,=20 U. of Pretoria, South Africa
Jong-Tae Park, Kyungpook National U.,=20 Korea
Punnet Sharma, HP Labs, USA
Yuval Shavitt, Tel Aviv U. and = Bell=20 Labs, USA
Chien-Chung Shen, Univ of Delaware, USA
Rolf Stadler,=20 CTR/Columbia U., USA
Burkhard Stiller, ETH Zurich, = Switzerland
Ralf=20 Steinmetz, GMD., Germany
Jose Neuman de Souza, U. Fed. do Ceara,=20 Brazil
Yechiam Yemini, Columbia U., USA
Alaa Youssef, IBM = Research,=20 USA
Douglas N. Zuckerman, Telcordia, USA
 
ORGANIZATION COMMITTEE
Aftab Ahmad, = DePaul=20 University
Mouayad Albaghdad, Motorola
Anthony Chung, DePaul = University=20
Ramy Khasawneh, DePaul University
Hazem Hamed, DePaul = University
Ye=20 Guanhua, DePaul University
Yonnning Tang, DePaul University
Bin = Zhang,=20 DePaul University
Qiao Zhang, DePaul University
 
MBONE Broadcast Specialist
John = Kristoff, DePaul=20 University
 
 
------=_NextPart_000_0599_01C07F56.4CD3FC50-- From owner-tcpsat@lerc.nasa.gov Tue Jan 16 05:05:35 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07593; Tue, 16 Jan 2001 05:05:35 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id EAA04227 for tcpsat-outgoing; Tue, 16 Jan 2001 04:31:44 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id EAA04194 for ; Tue, 16 Jan 2001 04:31:42 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id EAA01949; Tue, 16 Jan 2001 04:31:41 -0500 Received: from qhars002.nortelnetworks.com(192.100.101.19) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001929; Tue, 16 Jan 01 04:31:28 -0500 Received: from nwcwi1a.europe.nortel.com by qhars002.nortel.com; Tue, 16 Jan 2001 09:31:11 +0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 09:31:09 -0000 Message-ID: <0979C0AA41FED111BCFB00204804FC1302FDE17A@zhard000.europe.nortel.com> From: "Rahul Nandi" To: tcpsat@grc.nasa.gov Subject: RE: REMOVE Date: Tue, 16 Jan 2001 09:31:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07F9F.09DB2BA0" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07F9F.09DB2BA0 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_001_01C07F9F.09DB2BA0 Content-Type: text/html; charset="iso-8859-1" RE: REMOVE



------_=_NextPart_001_01C07F9F.09DB2BA0-- From owner-tcpsat@lerc.nasa.gov Tue Jan 16 11:01:40 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14818; Tue, 16 Jan 2001 11:01:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA27595 for tcpsat-outgoing; Tue, 16 Jan 2001 10:22:13 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA27537 for ; Tue, 16 Jan 2001 10:22:10 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA00160; Tue, 16 Jan 2001 10:22:05 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000010; Tue, 16 Jan 01 10:21:53 -0500 Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id KAA25933; Tue, 16 Jan 2001 10:20:22 -0500 (EST) Message-ID: <3A6466B5.987E0520@hns.com> Date: Tue, 16 Jan 2001 10:20:21 -0500 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: aaron@panamsat.com, karir@wam.umd.edu CC: tcpsat@grc.nasa.gov Subject: Re: spoofing standard?? References: <0703A3E1D430D411866100508BDFCF3328B5B8@CTOEXCH1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The PILC PEP document, with a few minor exceptions, does not talk about the right way to implement a PEP. This was very intentional because the IETF does not want to encourage the development of PEPs, in general (or perhaps at all). While I can see some possibility in the dim future of standardizing PEPs as potentially being meaningful work within the IETF (assuming things go a certain way with the work (which is not even in a working group yet) re discovering middle boxes and we can figure out a way to authenticate PEPs as a service), we are definitely not there yet. On the other hand, a case could be made that an informational document describing the "right" way to implement a PEP is of interest to the Internet community. (Not a standard but a set of guidelines.) Such a document does not belong in any IETF working group (in my opinion) but it might be appropriate as an independent submission. However, despite the preceeding sentences (and the fact that I sometimes work on PEPs myself), I, personally, am not convinced yet that such a document is appropriate. But, if such a document does get produced, I will very much care that it is written "correctly". (And, this includes having some big pointers to the implications discussion in the PILC PEP document.) John aaron@panamsat.com wrote: > > Manish- > > At the time we discussed this issue during the formation of TCPSAT and PILC > there was no support in the IETF to standardize ways of spoofing TCP. Our > compromise, and I thought it was a good one, was to write a document > desribing the ways that people spoofed TCP, why they felt they needed to do > it, and to document the risks associated with different mechanisms. This > document has been developed in the PILC working group, has finished working > group last call, and is in review by the IESG for publication as an > Informational RFC -- not an IETF standard. You can find a copy at > http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-05.txt. > > --aaron > > > -----Original Message----- > > From: Manish Karir [mailto:karir@wam.umd.edu] > > Sent: Monday, January 15, 2001 1:38 PM > > To: tcpsat@grc.nasa.gov > > Subject: spoofing standard?? > > > > > > > > I think there is probably enough support on this list and real > > implementation experience to generate some sort of a spoofing > > standard? > > > > if nothing else an informational document which summarizes the > > most "correct" way of implementing this. I know there have been > > papers and descriptions of this before, but something which has the > > blessings of more than just the authors would be quite > > useful...that way > > we would atleast have a common base to argue about :) > > > > does anyone else agree on the need for such a document?? > > > > manish karir > > > > > > From owner-tcpsat@lerc.nasa.gov Tue Jan 16 11:46:32 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16030; Tue, 16 Jan 2001 11:46:14 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA05530 for tcpsat-outgoing; Tue, 16 Jan 2001 10:56:03 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA05449 for ; Tue, 16 Jan 2001 10:55:56 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id KAA05024; Tue, 16 Jan 2001 10:55:50 -0500 Received: from smtp.eecs.umich.edu(141.213.4.44) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004944; Tue, 16 Jan 01 10:55:29 -0500 Received: from clueless.eecs.umich.edu (clueless.eecs.umich.edu [141.213.18.225]) by smtp.eecs.umich.edu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA20859; Tue, 16 Jan 2001 10:55:17 -0500 Date: Tue, 16 Jan 2001 10:55:17 -0500 (EST) From: Mingyan Liu To: Anil Agarwal cc: karir@wam.umd.edu, tcpsat@grc.nasa.gov Subject: Re: spoofing standard?? In-Reply-To: <200101152331.f0FNVGd12881@pleiades.ntd.comsat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk As a matter of fact spoofing is not only widely used in satellite systems but also frequently proposed to improve TCP performance over wireless mobile links. I think some form of standard on spoofing (or similar operation that violates the end-to-end semantics) would be very helpful. -mingyan P.S. I got an email from a friend asking "Can anyone on that list name an ISP that does not implement caching? Although caches are not necessarily spoofers I would bet that the TCP connection from the cache to the origin server does not resemble the connection from the client to the cache. So, unless I am missing something, it is nearly impossible to have true end to end TCP with HTTP transactions. " I post it here for your comments. On Mon, 15 Jan 2001, Anil Agarwal wrote: > On Jan 15, 2001, Manish Karir wrote: > > >I think there is probably enough support on this list and real > >implementation experience to generate some sort of a spoofing > >standard? > > > >if nothing else an informational document which summarizes the > >most "correct" way of implementing this. I know there have been > >papers and descriptions of this before, but something which has the > >blessings of more than just the authors would be quite useful...that way > >we would atleast have a common base to argue about :) > > > >does anyone else agree on the need for such a document?? > > > >manish karir > > I agree wholeheartedly. > > It would certainly provide value to the Internet to have > "robust" spoofing implementations, even though their use may not be > encouraged, except for special environments, such as satellite or wireless > networks. > > Anil Agarwal > LMGT > 22300 COMSAT Drive > Clarksburg, MD 20871 > 301-428-4655 > ======================== Mingyan Liu Assistant Professor EECS Department, Rm 4211 EECS University of Michigan Ann Arbor, MI 48109-2122 Tel:(734)764-9546 From owner-tcpsat@lerc.nasa.gov Tue Jan 16 12:45:29 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17325; Tue, 16 Jan 2001 12:45:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA24114 for tcpsat-outgoing; Tue, 16 Jan 2001 12:02:07 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA24050 for ; Tue, 16 Jan 2001 12:02:01 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA14547; Tue, 16 Jan 2001 12:02:00 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014338; Tue, 16 Jan 01 12:01:00 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.2/8.11.2) with ESMTP id f0GH0fo11884; Tue, 16 Jan 2001 17:00:41 GMT Message-ID: <3A647E3B.2D163300@erg.abdn.ac.uk> Date: Tue, 16 Jan 2001 17:00:43 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Manish Karir , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics - OPTIONS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Manish Karir wrote: > > On Sat, 13 Jan 2001, Fred Baker wrote: > > > At 01:34 AM 1/13/01 -0800, Alhussein Abouzeid wrote: > > >ECN *is* an option. TCP may or may not use it. > > > > we are somehow using entirely different definitions of the word "option". I > > am using it in the sense the word is used in RFC 791 and 793; you are using > > it, I think, in the sense "something that is optional". > > > > I'm not convinced I know what bits you're going to find in the IP or TCP > > headers that are left for doing "something that is optional", but if you > > can, be my guest. > > actually there can be any number of ways of doing this as long as the > consensus and approval of the ietf is there... IP Options are the most awkward (and probably less suited) of these. > for example: > > -the protocol field could be used to identify the packets to be spoofed. > so we would have TCP, or TCP-SPOOF to distinguish between the two. > (I personally think this is a good idea...if what spoofing does is > break traditional TCP then why call it TCP..just call it something > else...) That's not very good for inter-working with other user stacks... > > -a particular combination of the flags: say for example DF combined with > SYN combined with FIN but no ACK will mean -dont spoof > (bad idea I know..but once again....feasible..) > - bad and especially so using a combination of bits across different protocol layers. > -or how about a certain combination of bits in the TOS field... > (after all is'nt the purpose of the ToS field to be able to identify > flows of different types for processing different....so we can specify > that say ToS value of x shall mean the flow should not be spoofed or > should be spoofed) I believe these are already allocated to possible ECN and to DSCPs. DSCP values are not preserved unmodified end-to-end either, so these are not really candidates for this use. > > anyways.....just some random thoughts... TCP OPTION? If you can find out why you want to do it, and what benefit you get, why not consider a TCP option? I haven't heard of anyone (yet?) trying these spoofing ideas for UDP (???). If your target is TCP, and your spoofer **must** demultiplex individual flows and interpret TCP header semantics, why not negotiate "willingness to spoof" on TCP connection setup? Failure to see this option, could indicate unwillingness (including encryption? old protocol stack? lazy application?) - I wonder whether this has more potential? > > manish It seems to me that it is not just a matter of whether hosts mark packets with the correct identifier if they do (or do not) know they need spoofing - but also how TCP stacks find out that their parent application needs this facility - will the API do this (???), I would guess applications must explicity do this by understanding (???) how they plan to use a connection. Can this reasonably be expected to be implemented network wide? Another issue is whether there could be some consensus on **what** sort of spoofing a connection tolerate. I'm skeptical, on trying to standardise if there are a diverse set of techniques that are only used in some types of network... ) see the PILC WG PEP document. Best wisjhes, Gorry -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-tcpsat@lerc.nasa.gov Tue Jan 16 13:44:47 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19139; Tue, 16 Jan 2001 13:44:42 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA08853 for tcpsat-outgoing; Tue, 16 Jan 2001 12:52:08 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA08808 for ; Tue, 16 Jan 2001 12:52:04 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA21244; Tue, 16 Jan 2001 12:52:02 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021153; Tue, 16 Jan 01 12:51:40 -0500 Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id MAA27032; Tue, 16 Jan 2001 12:51:25 -0500 (EST) Message-ID: <3A648A1C.32F3B5E7@hns.com> Date: Tue, 16 Jan 2001 12:51:24 -0500 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics - OPTIONS References: <3A647E3B.2D163300@erg.abdn.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > TCP OPTION? > > If you can find out why you want to do it, and what benefit you get, why > not consider a TCP option? I haven't heard of anyone (yet?) trying > these spoofing ideas for UDP (???). If your target is TCP, and your spoofer > **must** demultiplex individual flows and interpret TCP header semantics, > why not negotiate "willingness to spoof" on TCP connection setup? Failure > to see this option, could indicate unwillingness (including encryption? old > protocol stack? lazy application?) - I wonder whether this has more > potential? This is an interesting idea. Something like the following... The initiator adds a "PEP" option to the SYN. If there is no PEP in the path, the receiver sends no option in the SYN ACK, letting the initiator know the connection is end to end. If there is a PEP in the path, the PEP adds a "PEP" option when it sends a SYN ACK to initiator and when it forwards or sends a SYN to the receiver. (The receiver could even, in theory, tell the PEP to get out of the way by not including the "PEP" option in its own SYN ACK response.) I see a problem with getting people to put support for such an option in their TCP stacks, though. They would have to be convinced of the value of doing so... John From owner-tcpsat@lerc.nasa.gov Tue Jan 16 13:49:10 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19243; Tue, 16 Jan 2001 13:49:10 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA12225 for tcpsat-outgoing; Tue, 16 Jan 2001 13:07:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA12210 for ; Tue, 16 Jan 2001 13:07:50 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA22989; Tue, 16 Jan 2001 13:07:49 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma022949; Tue, 16 Jan 01 13:07:00 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.2/8.11.2) with ESMTP id f0GI6vo12498 for ; Tue, 16 Jan 2001 18:06:57 GMT Message-ID: <3A648DC3.B034D1DB@erg.abdn.ac.uk> Date: Tue, 16 Jan 2001 18:06:58 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics - OPTIONS References: <3A647E3B.2D163300@erg.abdn.ac.uk> <3A648A1C.32F3B5E7@hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit John Border wrote: > > > TCP OPTION? > > > > If you can find out why you want to do it, and what benefit you get, why > > not consider a TCP option? I haven't heard of anyone (yet?) trying > > these spoofing ideas for UDP (???). If your target is TCP, and your spoofer > > **must** demultiplex individual flows and interpret TCP header semantics, > > why not negotiate "willingness to spoof" on TCP connection setup? Failure > > to see this option, could indicate unwillingness (including encryption? old > > protocol stack? lazy application?) - I wonder whether this has more > > potential? > > This is an interesting idea. Something like the following... > > The initiator adds a "PEP" option to the SYN. If there is no PEP in the path, > the receiver sends no option in the SYN ACK, letting the initiator know the > connection is end to end. If there is a PEP in the path, the PEP adds a "PEP" > option when it sends a SYN ACK to initiator and when it forwards or sends a > SYN to the receiver. (The receiver could even, in theory, tell the PEP to get > out of the way by not including the "PEP" option in its own SYN ACK response.) > > I see a problem with getting people to put support for such an option in their > TCP stacks, though. They would have to be convinced of the value of doing > so... > > John Yes, that sounds encouraging (to me). I think I still need to be convinced that we **should** do it, but at least something at the TCP level seems only to interact with TCP transport entities... and also give reasonable functionality, rather than trying to "overload" extra semantics to existing mechanisms... Gorry -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-tcpsat@lerc.nasa.gov Tue Jan 16 15:48:23 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21361; Tue, 16 Jan 2001 15:48:21 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA26045 for tcpsat-outgoing; Tue, 16 Jan 2001 15:07:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA25920 for ; Tue, 16 Jan 2001 15:07:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA08730; Tue, 16 Jan 2001 15:07:22 -0500 Received: from prue.eim.surrey.ac.uk(131.227.76.5) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008649; Tue, 16 Jan 01 15:06:46 -0500 Received: from regan.ee.surrey.ac.uk ([131.227.89.11]) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 14IcNM-00037c-00; Tue, 16 Jan 2001 20:06:40 +0000 Date: Tue, 16 Jan 2001 20:06:40 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Dr G Fairhurst cc: Manish Karir , tcpsat@grc.nasa.gov, tsvwg@ietf.org Subject: Re: TCP end-to-end Semantics - OPTIONS In-Reply-To: <3A647E3B.2D163300@erg.abdn.ac.uk> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk [most of this thread has little to do with satellites, so I've cc'd tsvwg, and suggest discussion moves there.] On Tue, 16 Jan 2001, Dr G Fairhurst wrote: > If you can find out why you want to do it, and what benefit you get, why > not consider a TCP option? Because there's no space left. The problem with TCP options is that there's limited space for them, and what with SACK and timestamps, the 40 available bytes for options soon fill up. Has anyone given any thought to negotiating accepted size of the TCP options field when a connection is initiated, or, slightly more crufty but perhaps better from a legacy viewpoint, negotiating use/acceptance of an option field indicating that further option information can be carried elsewhere in the TCP segment, either following the options field directly (ease of processing) or after any data in the segment? (The latter is possibly more backwards-compatible for old code that might assume a limit on option size, but since checksums have to be adjusted anyway that's probably a moot point. Possibly better for spoofing/NAT implementations en-route, though.) This would allow more SACK information to be provided - useful in itself. So you might have either: a) optional option at TCP connection setup indicating maximum number of TCP options sender is willing to process. Default (no given options limit advertised) is four as present; both ends can set their max tolerance. Weeny wireless receivers that know they're on header-compressed links might demand a limit of one or two, etc. Defining an explicit option size acceptance limit in initial negotiation and using the null terminator - that's what it's for! - strikes me as slightly more in the spirit of RFC1263 than the more baroque alternative below; all a spoofer has to do is not pass the option on during the initial exchange, so it's backwards-compatible. b) negotiated use of willingness to accept options 'extension header' at startup, then in a packet with a lot of options, you'd have: option field: timestamp window size optional option indicating use of optional options optional options: sack sack sack [..] sack. Loads and loads of sack. everything else we can think of. data. Yes, MSS payload computation has to be adjusted, but this strikes me as an easy win for cases where most of your data transfer is one-way and you're just sending acks where you can piggyback a lot of useful option information. Nothing wrong with a hundreds-byte ack packet if it contains useful information that the other end can process. And then we can worry less about sender heuristics guessing SACK state from the miserly three records available, too. Suggestion b) strikes me as vaguely analogous to use of GRE; it's a generic get-out-of-closed-space be-it-protocol-bits-or-option-bytes extension-header fix. L. hey, if T/TCP with SACK ever takes off, we'll need all the option space we can get. PGP From owner-tcpsat@lerc.nasa.gov Tue Jan 16 21:41:27 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26569; Tue, 16 Jan 2001 21:41:26 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA12864 for tcpsat-outgoing; Tue, 16 Jan 2001 21:00:29 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA12837 for ; Tue, 16 Jan 2001 21:00:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id VAA14129; Tue, 16 Jan 2001 21:00:25 -0500 Received: from smtp.eecs.umich.edu(141.213.4.44) by seraph3.lerc.nasa.gov via smap (V5.5) id xma014022; Tue, 16 Jan 01 20:59:52 -0500 Received: from clueless.eecs.umich.edu (clueless.eecs.umich.edu [141.213.18.225]) by smtp.eecs.umich.edu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA29217; Tue, 16 Jan 2001 20:59:34 -0500 Date: Tue, 16 Jan 2001 20:59:34 -0500 (EST) From: Mingyan Liu To: John Border cc: gorry@erg.abdn.ac.uk, tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics - OPTIONS In-Reply-To: <3A648A1C.32F3B5E7@hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk > > > TCP OPTION? > > > > If you can find out why you want to do it, and what benefit you get, why > > not consider a TCP option? I haven't heard of anyone (yet?) trying > > these spoofing ideas for UDP (???). If your target is TCP, and your spoofer > > **must** demultiplex individual flows and interpret TCP header semantics, > > why not negotiate "willingness to spoof" on TCP connection setup? Failure > > to see this option, could indicate unwillingness (including encryption? old > > protocol stack? lazy application?) - I wonder whether this has more > > potential? > > This is an interesting idea. Something like the following... > > The initiator adds a "PEP" option to the SYN. If there is no PEP in the path, > the receiver sends no option in the SYN ACK, letting the initiator know the > connection is end to end. If there is a PEP in the path, the PEP adds a "PEP" > option when it sends a SYN ACK to initiator and when it forwards or sends a > SYN to the receiver. (The receiver could even, in theory, tell the PEP to get > out of the way by not including the "PEP" option in its own SYN ACK response.) > I can see why it makes sense to do so, but this would mean the spoofer will need to check the TCP header of all passing (TCP) packets, even those belonging to a connection that did not choose to use the PEP? I guess this probably still beats using an IP "option", which gets the packet kicked out of the fast lane...? -mingyan From owner-tcpsat@lerc.nasa.gov Wed Jan 17 14:30:45 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24716; Wed, 17 Jan 2001 14:30:40 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA02391 for tcpsat-outgoing; Wed, 17 Jan 2001 13:43:21 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA02344 for ; Wed, 17 Jan 2001 13:43:18 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id NAA06381; Wed, 17 Jan 2001 13:43:17 -0500 Received: from mclean-mail.usae.bah.com(156.80.5.109) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006351; Wed, 17 Jan 01 13:42:56 -0500 Received: from jf ([156.80.71.126]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.61) with SMTP id AAAF61; Wed, 17 Jan 2001 13:42:49 -0500 Message-ID: <001b01c080b5$c7682120$7e47509c@jf.BAH.COM> From: "JTEOIETF" To: Subject: RFC1323 Window scale behavior Date: Wed, 17 Jan 2001 13:46:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C0808B.DE921920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C0808B.DE921920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I have been performing simulations in preparation of an upcoming = on-orbit test of TCP applications over satellite. The problem is the = RFC 1323 window scaling option does not always operate as expected. For = example, capturing the packets for an FTP session reveals the scaling = option is on during the initial session setup (I.e. login, cd-ing, etc) = but when a file transfer is requested and another session opens, the = window scale options are not present, therefore limiting to a 64k = window. I have a roundtrip delay upwards of 2500 ms and bandwidth of = 1.544 Mbps. Any input to this behavior is appreciated. Equipment: -IBM ThinkPad 600 w/ Windows 2000 sp1 -Cisco 2611 routers, using high speed serial ports on WAN side -KIV-19 crypto (capable of 13 Mbps) -Adtech SX12 link simulator Thank you, Jim ------=_NextPart_000_0018_01C0808B.DE921920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have been performing simulations in = preparation=20 of an upcoming on-orbit test of TCP applications over = satellite.  The=20 problem is the RFC 1323 window scaling option does not always operate as = expected.  For example, capturing the packets for an FTP session = reveals=20 the scaling option is on during the initial session setup (I.e. = login,=20 cd-ing, etc) but when a file transfer is requested and another session = opens,=20 the window scale options are not present, therefore limiting to a 64k=20 window.  I have a roundtrip delay upwards of 2500 ms and bandwidth = of 1.544=20 Mbps.  Any input to this behavior is appreciated.
 
Equipment:
 
-IBM ThinkPad 600 w/ Windows 2000 sp1
-Cisco 2611 routers, using high speed serial ports = on WAN=20 side
-KIV-19 crypto (capable of 13 = Mbps)
-Adtech SX12 link simulator
 
Thank you,
 
Jim
 
------=_NextPart_000_0018_01C0808B.DE921920-- From owner-tcpsat@lerc.nasa.gov Wed Jan 17 15:26:57 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25642; Wed, 17 Jan 2001 15:26:56 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA13772 for tcpsat-outgoing; Wed, 17 Jan 2001 14:40:59 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA13738 for ; Wed, 17 Jan 2001 14:40:57 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id OAA13955; Wed, 17 Jan 2001 14:40:56 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013911; Wed, 17 Jan 01 14:40:44 -0500 Received: from golariupc (GOLARIUPC.hns.com [139.85.148.130]) by hnssysa.hns.com (8.9.0/8.8.7) with SMTP id OAA12670; Wed, 17 Jan 2001 14:40:07 -0500 (EST) Message-ID: <031901c080bd$51a73220$8294558b@golariupc> From: "gabriel olariu" To: "JTEOIETF" , References: <001b01c080b5$c7682120$7e47509c@jf.BAH.COM> Subject: Re: RFC1323 Window scale behavior Date: Wed, 17 Jan 2001 14:40:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0316_01C08093.68AB0480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0316_01C08093.68AB0480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You need to verify that both server and client have the stack configured = with Tcp1323Opts=3D1. Also, the window sizes need to exceed 64K for large windows to kick in. Look at the TCP options exchanged in the SYN sequence and you'll see = who's doing=20 large windows and who's not. For the registry parameters that need to be set, consult "Microsoft = Windows 2000 Server" white paper. Only Win98/98SE/ME/2000 support large windows. Win98 has a documented = bug. gabriel ----- Original Message -----=20 From: JTEOIETF=20 To: tcpsat@grc.nasa.gov=20 Sent: Wednesday, January 17, 2001 1:46 PM Subject: RFC1323 Window scale behavior Hello, =20 I have been performing simulations in preparation of an upcoming = on-orbit test of TCP applications over satellite. The problem is the = RFC 1323 window scaling option does not always operate as expected. For = example, capturing the packets for an FTP session reveals the scaling = option is on during the initial session setup (I.e. login, cd-ing, etc) = but when a file transfer is requested and another session opens, the = window scale options are not present, therefore limiting to a 64k = window. I have a roundtrip delay upwards of 2500 ms and bandwidth of = 1.544 Mbps. Any input to this behavior is appreciated. =20 Equipment: =20 -IBM ThinkPad 600 w/ Windows 2000 sp1 -Cisco 2611 routers, using high speed serial ports on WAN side -KIV-19 crypto (capable of 13 Mbps) -Adtech SX12 link simulator =20 Thank you, =20 Jim =20 ------=_NextPart_000_0316_01C08093.68AB0480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You need to verify that both server and = client have=20 the stack configured with Tcp1323Opts=3D1.
Also, the window sizes need to exceed = 64K for large=20 windows to kick in.
Look at the TCP options exchanged in = the SYN=20 sequence and you'll see who's doing
large windows and who's = not.
For the registry parameters that need = to be set,=20 consult "Microsoft Windows 2000 Server" white paper.
Only Win98/98SE/ME/2000 support large = windows.=20 Win98 has a documented bug.
gabriel
----- Original Message -----
From:=20 JTEOIETF
Sent: Wednesday, January 17, = 2001 1:46=20 PM
Subject: RFC1323 Window scale=20 behavior

Hello,
 
I have been performing simulations in = preparation=20 of an upcoming on-orbit test of TCP applications over = satellite. =20 The problem is the RFC 1323 window scaling option does not always = operate as=20 expected.  For example, capturing the packets for an FTP session = reveals=20 the scaling option is on during the initial session setup (I.e. = login,=20 cd-ing, etc) but when a file transfer is requested and another session = opens,=20 the window scale options are not present, therefore limiting to a 64k=20 window.  I have a roundtrip delay upwards of 2500 ms and = bandwidth of=20 1.544 Mbps.  Any input to this behavior is = appreciated.
 
Equipment:
 
-IBM ThinkPad 600 w/ Windows 2000 sp1
-Cisco 2611 routers, using high speed serial ports = on WAN=20 side
-KIV-19 crypto (capable of 13 = Mbps)
-Adtech SX12 link simulator
 
Thank you,
 
Jim
 
------=_NextPart_000_0316_01C08093.68AB0480-- From owner-tcpsat@lerc.nasa.gov Wed Jan 17 16:34:40 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26509; Wed, 17 Jan 2001 16:34:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA26104 for tcpsat-outgoing; Wed, 17 Jan 2001 15:31:11 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA26023 for ; Wed, 17 Jan 2001 15:31:00 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id PAA20880; Wed, 17 Jan 2001 15:30:56 -0500 Received: from mclean-mail.usae.bah.com(156.80.5.109) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020716; Wed, 17 Jan 01 15:30:47 -0500 Received: from jf ([156.80.71.126]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.61) with SMTP id AAAEA4; Wed, 17 Jan 2001 15:26:07 -0500 Message-ID: <001401c080c4$3516b5c0$7e47509c@jf.BAH.COM> From: "JTEOIETF" To: "gabriel olariu" , Subject: Re: RFC1323 Window scale behavior Date: Wed, 17 Jan 2001 15:29:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C0809A.3F94A900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C0809A.3F94A900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Both client and server are configured to operate with window = scaling...Tcp1323opts =3D 1, tcpwindowsize =3D 524 k, etc. During some = SYN, ACK/SYN handshaking sequences, the scaling option is on and at the = correct scale factor. Other times it is not...especially when I need = it, such as file transfer. Any other thoughts... thanks Jim -----Original Message----- From: gabriel olariu To: JTEOIETF ; tcpsat@grc.nasa.gov = Date: Wednesday, January 17, 2001 2:40 PM Subject: Re: RFC1323 Window scale behavior You need to verify that both server and client have the stack = configured with Tcp1323Opts=3D1. Also, the window sizes need to exceed 64K for large windows to kick = in. Look at the TCP options exchanged in the SYN sequence and you'll see = who's doing=20 large windows and who's not. For the registry parameters that need to be set, consult "Microsoft = Windows 2000 Server" white paper. Only Win98/98SE/ME/2000 support large windows. Win98 has a documented = bug. gabriel ----- Original Message -----=20 From: JTEOIETF=20 To: tcpsat@grc.nasa.gov=20 Sent: Wednesday, January 17, 2001 1:46 PM Subject: RFC1323 Window scale behavior Hello, I have been performing simulations in preparation of an upcoming = on-orbit test of TCP applications over satellite. The problem is the = RFC 1323 window scaling option does not always operate as expected. For = example, capturing the packets for an FTP session reveals the scaling = option is on during the initial session setup (I.e. login, cd-ing, etc) = but when a file transfer is requested and another session opens, the = window scale options are not present, therefore limiting to a 64k = window. I have a roundtrip delay upwards of 2500 ms and bandwidth of = 1.544 Mbps. Any input to this behavior is appreciated. Equipment: -IBM ThinkPad 600 w/ Windows 2000 sp1 -Cisco 2611 routers, using high speed serial ports on WAN side -KIV-19 crypto (capable of 13 Mbps) -Adtech SX12 link simulator Thank you, Jim ------=_NextPart_000_000F_01C0809A.3F94A900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Both client and server are configured to operate = with window=20 scaling...Tcp1323opts =3D 1, tcpwindowsize =3D 524 k, etc. During = some SYN,=20 ACK/SYN handshaking sequences, the scaling option is on and at the = correct=20 scale factor.  Other times it is not...especially when I need it, = such as=20 file transfer.  Any other thoughts...
thanks
Jim
-----Original = Message-----
From:=20 gabriel olariu <golariu@hns.com>
To: = JTEOIETF=20 <jteoietf@bah.com>; tcpsat@grc.nasa.gov <tcpsat@grc.nasa.gov>
Dat= e:=20 Wednesday, January 17, 2001 2:40 PM
Subject: Re: RFC1323 = Window=20 scale behavior

You need to verify that both server = and client=20 have the stack configured with Tcp1323Opts=3D1.
Also, the window sizes need to exceed = 64K for=20 large windows to kick in.
Look at the TCP options exchanged in = the SYN=20 sequence and you'll see who's doing
large windows and who's = not.
For the registry parameters that need = to be set,=20 consult "Microsoft Windows 2000 Server" white paper.
Only Win98/98SE/ME/2000 support large = windows.=20 Win98 has a documented bug.
gabriel
----- Original Message -----
From:=20 JTEOIETF
Sent: Wednesday, January 17, = 2001 1:46=20 PM
Subject: RFC1323 Window scale = behavior

Hello,
 
I have been performing simulations in = preparation=20 of an upcoming on-orbit test of TCP applications over = satellite. =20 The problem is the RFC 1323 window scaling option does not always = operate as=20 expected.  For example, capturing the packets for an FTP = session=20 reveals the scaling option is on during the initial session = setup (I.e.=20 login, cd-ing, etc) but when a file transfer is requested and = another=20 session opens, the window scale options are not present, therefore = limiting=20 to a 64k window.  I have a roundtrip delay upwards of 2500 ms = and=20 bandwidth of 1.544 Mbps.  Any input to this behavior is=20 appreciated.
 
Equipment:
 
-IBM ThinkPad 600 w/ Windows 2000 = sp1
-Cisco 2611 routers, using high speed serial = ports on WAN=20 side
-KIV-19 crypto (capable of 13 = Mbps)
-Adtech SX12 link simulator
 
Thank you,
 
Jim
 
------=_NextPart_000_000F_01C0809A.3F94A900-- From owner-tcpsat@lerc.nasa.gov Wed Jan 17 17:05:42 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26805; Wed, 17 Jan 2001 17:05:41 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA04880 for tcpsat-outgoing; Wed, 17 Jan 2001 16:14:01 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA04864; Wed, 17 Jan 2001 16:13:53 -0500 (EST) Received: from katrinaljoy (vtcp10.lerc.nasa.gov [139.88.245.20]) by apataki-fi.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id QAA27737; Wed, 17 Jan 2001 16:13:49 -0500 (EST) Message-Id: <4.1.20010117154322.00a69230@popserve.lerc.nasa.gov> X-Sender: caivanc@popserve.lerc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Jan 2001 15:51:23 -0500 To: "JTEOIETF" From: William D Ivancic Subject: Re: RFC1323 Window scale behavior Cc: "gabriel olariu" , In-Reply-To: <001401c080c4$3516b5c0$7e47509c@jf.BAH.COM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_96971463==_.ALT" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk --=====================_96971463==_.ALT Content-Type: text/plain; charset="us-ascii" I seem to remember hearing that some FTP applications do not call the large windows options in TCP. I suggest checking you FTP application to ensure it utilizes large windows. If not, even though large windows is setup on your machine, the FTP application does not utilize it. I hope I'm not giving you false information. Good Luck. Will Ivancic At 03:29 PM 1/17/01 -0500, JTEOIETF wrote: > > Both client and server are configured to operate with window > scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, etc. During some SYN, > ACK/SYN handshaking sequences, the scaling option is on and at the correct > scale factor. Other times it is not...especially when I need it, such as > file transfer. Any other thoughts... > thanks > Jim --=====================_96971463==_.ALT Content-Type: text/html; charset="us-ascii" I seem to remember hearing that some FTP applications do not call the large windows options in TCP.  I suggest checking you FTP application to ensure it utilizes large windows.  If not, even though large windows is setup on your machine, the FTP application does not utilize it.  I hope I'm not giving you false information.  Good Luck.

Will Ivancic

At 03:29 PM 1/17/01 -0500, JTEOIETF wrote:
Both client and server are configured to operate with window scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, etc. During some SYN, ACK/SYN handshaking sequences, the scaling option is on and at the correct scale factor.  Other times it is not...especially when I need it, such as file transfer.  Any other thoughts...
thanks
Jim
--=====================_96971463==_.ALT-- From owner-tcpsat@lerc.nasa.gov Wed Jan 17 17:07:07 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26840; Wed, 17 Jan 2001 17:07:05 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA06686 for tcpsat-outgoing; Wed, 17 Jan 2001 16:23:28 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA06648 for ; Wed, 17 Jan 2001 16:23:27 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA27516; Wed, 17 Jan 2001 16:23:24 -0500 Received: from dfw-smtpout2.email.verio.net(129.250.36.42) by seraph3.lerc.nasa.gov via smap (V5.5) id xma027454; Wed, 17 Jan 01 16:23:02 -0500 Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 14J02n-00052F-00; Wed, 17 Jan 2001 21:23:01 +0000 Received: from [161.58.1.76] (helo=shell1) by dfw-mmp1.email.verio.net with esmtp id 14J02n-0002vg-00; Wed, 17 Jan 2001 21:23:01 +0000 Date: Wed, 17 Jan 2001 16:23:00 -0500 (EST) From: Eric Travis To: JTEOIETF cc: Subject: Re: RFC1323 Window scale behavior In-Reply-To: <001401c080c4$3516b5c0$7e47509c@jf.BAH.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Most likely your FTP client (and or server) is explicitly setting the send/receive buffers thus overriding the default values you tweaked. Do you have access to an alternative FTP client and/or server? Eric On Wed, 17 Jan 2001, JTEOIETF wrote: > Both client and server are configured to operate with > window scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, > etc. During some SYN, ACK/SYN handshaking sequences, > the scaling option is on and at the correct scale factor. > Other times it is not...especially when I need it, such > as file transfer. Any other thoughts... From owner-tcpsat@lerc.nasa.gov Wed Jan 17 17:39:39 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27497; Wed, 17 Jan 2001 17:39:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA12192 for tcpsat-outgoing; Wed, 17 Jan 2001 16:54:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA12149 for ; Wed, 17 Jan 2001 16:54:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id QAA01599; Wed, 17 Jan 2001 16:54:42 -0500 Received: from hnssysa.hns.com(139.85.76.100) by seraph3.lerc.nasa.gov via smap (V5.5) id xma001552; Wed, 17 Jan 01 16:53:59 -0500 Received: from golariupc (GOLARIUPC.hns.com [139.85.148.130]) by hnssysa.hns.com (8.9.0/8.8.7) with SMTP id QAA10513; Wed, 17 Jan 2001 16:53:27 -0500 (EST) Message-ID: <036001c080cf$f198c340$8294558b@golariupc> From: "gabriel olariu" To: "JTEOIETF" , References: <001b01c080b5$c7682120$7e47509c@jf.BAH.COM> Subject: Re: RFC1323 Window scale behavior Date: Wed, 17 Jan 2001 16:53:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_035D_01C080A6.08A74400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_035D_01C080A6.08A74400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could you please post the name of the ftp client/server you're using (if = possible). I was wrong saying that the app does not interfere. It can definitely = override the=20 registry settings, as noted by other persons earlier. This looks to be your case. Thanks, gabriel ----- Original Message -----=20 From: JTEOIETF=20 To: tcpsat@grc.nasa.gov=20 Sent: Wednesday, January 17, 2001 1:46 PM Subject: RFC1323 Window scale behavior Hello, =20 I have been performing simulations in preparation of an upcoming = on-orbit test of TCP applications over satellite. The problem is the = RFC 1323 window scaling option does not always operate as expected. For = example, capturing the packets for an FTP session reveals the scaling = option is on during the initial session setup (I.e. login, cd-ing, etc) = but when a file transfer is requested and another session opens, the = window scale options are not present, therefore limiting to a 64k = window. I have a roundtrip delay upwards of 2500 ms and bandwidth of = 1.544 Mbps. Any input to this behavior is appreciated. =20 Equipment: =20 -IBM ThinkPad 600 w/ Windows 2000 sp1 -Cisco 2611 routers, using high speed serial ports on WAN side -KIV-19 crypto (capable of 13 Mbps) -Adtech SX12 link simulator =20 Thank you, =20 Jim =20 ------=_NextPart_000_035D_01C080A6.08A74400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Could you please post the name of the = ftp=20 client/server you're using (if possible).
I was wrong saying that the app does = not interfere.=20 It can definitely override the
registry settings, as noted by other = persons=20 earlier.
This looks to be your = case.
Thanks,
gabriel
----- Original Message -----
From:=20 JTEOIETF
Sent: Wednesday, January 17, = 2001 1:46=20 PM
Subject: RFC1323 Window scale=20 behavior

Hello,
 
I have been performing simulations in = preparation=20 of an upcoming on-orbit test of TCP applications over = satellite. =20 The problem is the RFC 1323 window scaling option does not always = operate as=20 expected.  For example, capturing the packets for an FTP session = reveals=20 the scaling option is on during the initial session setup (I.e. = login,=20 cd-ing, etc) but when a file transfer is requested and another session = opens,=20 the window scale options are not present, therefore limiting to a 64k=20 window.  I have a roundtrip delay upwards of 2500 ms and = bandwidth of=20 1.544 Mbps.  Any input to this behavior is = appreciated.
 
Equipment:
 
-IBM ThinkPad 600 w/ Windows 2000 sp1
-Cisco 2611 routers, using high speed serial ports = on WAN=20 side
-KIV-19 crypto (capable of 13 = Mbps)
-Adtech SX12 link simulator
 
Thank you,
 
Jim
 
------=_NextPart_000_035D_01C080A6.08A74400-- From owner-tcpsat@lerc.nasa.gov Wed Jan 17 19:48:06 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29963; Wed, 17 Jan 2001 19:48:04 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA28647 for tcpsat-outgoing; Wed, 17 Jan 2001 19:09:17 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA28623 for ; Wed, 17 Jan 2001 19:09:15 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id TAA16231; Wed, 17 Jan 2001 19:09:15 -0500 Received: from acsys.anu.edu.au(150.203.20.41) by seraph3.lerc.nasa.gov via smap (V5.5) id xma016176; Wed, 17 Jan 01 19:08:17 -0500 Received: from accordion ([150.203.56.12]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id LAA17545; Thu, 18 Jan 2001 11:07:50 +1100 (EST) Message-Id: <3.0.32.20010118110800.01153210@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 18 Jan 2001 11:08:05 +1100 To: Eric Travis , JTEOIETF From: Markus Buchhorn Subject: Re: RFC1323 Window scale behavior Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk The Windows (NT4) ftp client has an option (-w) to set the buffer size for transfers. This seems to work (it significantly increased performance on our ATM network) (although on NT4 we can't go past 64k, of course). C:\>ftp -? [...] -w:buffersize Overrides the default transfer buffer size of 4096. Why, oh why, do they do this.... You haven't said anywhere how you are doing file transfers? ftp, smb, http, ... ? Cheers, Markus At 16:23 17/01/01 -0500, Eric Travis wrote: > >Most likely your FTP client (and or server) is >explicitly setting the send/receive buffers >thus overriding the default values you tweaked. >Do you have access to an alternative FTP client >and/or server? > >Eric > > > >On Wed, 17 Jan 2001, JTEOIETF wrote: > >> Both client and server are configured to operate with >> window scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, >> etc. During some SYN, ACK/SYN handshaking sequences, >> the scaling option is on and at the correct scale factor. >> Other times it is not...especially when I need it, such >> as file transfer. Any other thoughts... > > > Markus Buchhorn, Faculty of Engineering and IT, | Ph: +61 2 61258810 email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108 |Fax: +61 2 61250010 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 ** Note new address and phone numbers ** From owner-tcpsat@lerc.nasa.gov Wed Jan 17 23:31:07 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05186; Wed, 17 Jan 2001 23:31:07 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA12425 for tcpsat-outgoing; Wed, 17 Jan 2001 22:55:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA12409 for ; Wed, 17 Jan 2001 22:55:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id WAA02826; Wed, 17 Jan 2001 22:55:42 -0500 Message-Id: <200101180355.WAA02826@seraph3.lerc.nasa.gov> Received: from qmail4.vsto.net(209.185.20.134) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002793; Wed, 17 Jan 01 22:54:48 -0500 Received: (qmail 9945 invoked by alias); Received: from unknown (HELO mps4) (206.79.140.148) by qmail.visto.com with SMTP; 17 Jan 2001 19:54:46 -0800 Reply-To: joesat@visto.com From: "joe black" Subject: Re: RFC1323 Window scale behavior Date: Wed, 17 Jan 2001 19:51:07 -0800 X-Mailer: Visto To: travis@clark.net, jteoietf@bah.com, Markus.Buchhorn@anu.edu.au cc: tcpsat@grc.nasa.gov MIME-Version: 1.0 X-Mailer: Visto Server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id WAA12414 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit Hi Marcus, I'm from Uni Science M'sia. I have a few questions: 1) I would like to know if there is any tool to determine the TCP window size in Linux Redhat 6.2. (kernel 2.2.16)? Or can I know the default window size? Also, is there any tool that can be used to control the window size?? 2) If I enable TCP_WINDOW_SCALING, how can I know how big is the window size? If any of you can help, I would be very grateful. Rgds, joe -----Original Message----- From: Markus Buchhorn Markus.Buchhorn@anu.edu.au Sent: Thu, 18 Jan 2001 11:08:05 +1100 To: travis@clark.net, jteoietf@bah.com CC: tcpsat@grc.nasa.gov Subject: Re: RFC1323 Window scale behavior The Windows (NT4) ftp client has an option (-w) to set the buffer size for transfers. This seems to work (it significantly increased performance on our ATM network) (although on NT4 we can't go past 64k, of course). C:\>ftp -? [...] -w:buffersize Overrides the default transfer buffer size of 4096. Why, oh why, do they do this.... You haven't said anywhere how you are doing file transfers? ftp, smb, http, ... ? Cheers, Markus At 16:23 17/01/01 -0500, Eric Travis wrote: > >Most likely your FTP client (and or server) is >explicitly setting the send/receive buffers >thus overriding the default values you tweaked. >Do you have access to an alternative FTP client >and/or server? > >Eric > > > >On Wed, 17 Jan 2001, JTEOIETF wrote: > >> Both client and server are configured to operate with >> window scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, >> etc. During some SYN, ACK/SYN handshaking sequences, >> the scaling option is on and at the correct scale factor. >> Other times it is not...especially when I need it, such >> as file transfer. Any other thoughts... > > > Markus Buchhorn, Faculty of Engineering and IT, | Ph: +61 2 61258810 email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108 |Fax: +61 2 61250010 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 ** Note new address and phone numbers ** ___________________________________________________________________________ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot. From owner-tcpsat@lerc.nasa.gov Thu Jan 18 04:27:53 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21295; Thu, 18 Jan 2001 04:27:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id DAA29405 for tcpsat-outgoing; Thu, 18 Jan 2001 03:34:45 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id DAA29386 for ; Thu, 18 Jan 2001 03:34:43 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id DAA20434; Thu, 18 Jan 2001 03:34:42 -0500 Received: from alakhawayn.ma(193.194.63.82) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020385; Thu, 18 Jan 01 03:33:43 -0500 Received: from dr-biaz (fwinternet.alakhawayn.ma [193.194.63.129]) by mail.AlAkhawayn.ma (8.9.0/8.9.0) with SMTP id IAA13227; Thu, 18 Jan 2001 08:39:53 GMT Received: by localhost with Microsoft MAPI; Thu, 18 Jan 2001 08:32:24 -0000 Message-ID: <01C08129.2EBACC10.S.Biaz@alakhawayn.ma> From: =?us-ascii?Q?Saad_Biaz?= Reply-To: "S.Biaz@alakhawayn.ma" To: "'joesat@visto.com'" , "travis@clark.net" , "jteoietf@bah.com" , "Markus.Buchhorn@anu.edu.au" Cc: "tcpsat@grc.nasa.gov" Subject: RE: RFC1323 Window scale behavior Date: Thu, 18 Jan 2001 08:32:23 -0000 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I wonder if Linux has a tool similar to trpt that we find under Free BSD. With trpt, you would be able to monitor the window size. Another way would be to do a very simple hack on the tcp code. Hope this helps. -----Original Message----- From: joe black [SMTP:joesat@visto.com] Sent: jeudi 18 janvier 2001 03:51 To: travis@clark.net; jteoietf@bah.com; Markus.Buchhorn@anu.edu.au Cc: tcpsat@grc.nasa.gov Subject: Re: RFC1323 Window scale behavior Hi Marcus, I'm from Uni Science M'sia. I have a few questions: 1) I would like to know if there is any tool to determine the TCP window size in Linux Redhat 6.2. (kernel 2.2.16)? Or can I know the default window size? Also, is there any tool that can be used to control the window size?? 2) If I enable TCP_WINDOW_SCALING, how can I know how big is the window size? If any of you can help, I would be very grateful. Rgds, joe -----Original Message----- From: Markus Buchhorn Markus.Buchhorn@anu.edu.au Sent: Thu, 18 Jan 2001 11:08:05 +1100 To: travis@clark.net, jteoietf@bah.com CC: tcpsat@grc.nasa.gov Subject: Re: RFC1323 Window scale behavior The Windows (NT4) ftp client has an option (-w) to set the buffer size for transfers. This seems to work (it significantly increased performance on our ATM network) (although on NT4 we can't go past 64k, of course). C:\>ftp -? [...] -w:buffersize Overrides the default transfer buffer size of 4096. Why, oh why, do they do this.... You haven't said anywhere how you are doing file transfers? ftp, smb, http, ... ? Cheers, Markus At 16:23 17/01/01 -0500, Eric Travis wrote: > >Most likely your FTP client (and or server) is >explicitly setting the send/receive buffers >thus overriding the default values you tweaked. >Do you have access to an alternative FTP client >and/or server? > >Eric > > > >On Wed, 17 Jan 2001, JTEOIETF wrote: > >> Both client and server are configured to operate with >> window scaling...Tcp1323opts = 1, tcpwindowsize = 524 k, >> etc. During some SYN, ACK/SYN handshaking sequences, >> the scaling option is on and at the correct scale factor. >> Other times it is not...especially when I need it, such >> as file transfer. Any other thoughts... > > > Markus Buchhorn, Faculty of Engineering and IT, | Ph: +61 2 61258810 email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108 |Fax: +61 2 61250010 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 ** Note new address and phone numbers ** ___________________________________________________________________________ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot. From owner-tcpsat@lerc.nasa.gov Thu Jan 18 06:56:14 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22201; Thu, 18 Jan 2001 06:56:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id GAA08849 for tcpsat-outgoing; Thu, 18 Jan 2001 06:21:40 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id GAA08833 for ; Thu, 18 Jan 2001 06:21:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id GAA00613; Thu, 18 Jan 2001 06:21:38 -0500 Received: from cordelia.mail.kokuacom.net(212.116.96.13) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000599; Thu, 18 Jan 01 06:21:11 -0500 Received: from mike (unknown [212.116.96.126]) by cordelia.mail.kokuacom.net (Postfix) with SMTP id C4CFCAE493 for ; Thu, 18 Jan 2001 11:15:10 +0000 (GMT) From: "Mike Jagdis" To: Subject: FW: RFC1323 Window scale behavior Date: Thu, 18 Jan 2001 11:18:33 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > 1) I would like to know if there is any tool to determine the TCP > window size in Linux Redhat 6.2. (kernel 2.2.16)? > Or can I know the default window size? Also, is there any tool > that can be used to control the window size?? You can get/set the default and maximum (that an application can set via setsockopt() syscalls) through the proc files: /proc/sys/net/core/[rw]mem_{default,max}. You can turn window scaling on and off through, um..., /proc/sys/net/ipv4/tcp_window_scaling. If you want to know what is happening on the wire you need to watch packets - good old tcpdump (or iptraf for those who need something more graphical). Mike From owner-tcpsat@lerc.nasa.gov Thu Jan 18 08:35:53 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23286; Thu, 18 Jan 2001 08:35:53 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA18489 for tcpsat-outgoing; Thu, 18 Jan 2001 08:03:19 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA18468 for ; Thu, 18 Jan 2001 08:03:16 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA08115; Thu, 18 Jan 2001 08:03:14 -0500 Received: from aeon.tvd.be(195.162.196.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008078; Thu, 18 Jan 01 08:03:07 -0500 Received: from bardolino (cable-195-162-215-112.upc.chello.be [195.162.215.112]) by aeon.tvd.be (8.9.3/8.9.3/RELAY-1.1) with SMTP id OAA17930 for ; Thu, 18 Jan 2001 14:03:04 +0100 (MET) From: "Megabert" To: Subject: Re: RFC1323 Window scale behavior Date: Thu, 18 Jan 2001 14:02:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The two FTP clients that are installed on my PC, namely CuteFTP and WS_FTP both have settable options for the receive and xmit network buffer size. The default sizes in Cute are 4096, in WS_FTP the xmit size only is 512 bytes. Eric From owner-tcpsat@lerc.nasa.gov Thu Jan 18 08:36:34 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23304; Thu, 18 Jan 2001 08:36:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA18248 for tcpsat-outgoing; Thu, 18 Jan 2001 08:02:15 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA18215 for ; Thu, 18 Jan 2001 08:02:12 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id IAA08009; Thu, 18 Jan 2001 08:02:11 -0500 Received: from diesel.erg.abdn.ac.uk(139.133.204.76) by seraph3.lerc.nasa.gov via smap (V5.5) id xma007962; Thu, 18 Jan 01 08:01:22 -0500 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.11.2/8.11.2) with ESMTP id f0ID1Go23940; Thu, 18 Jan 2001 13:01:16 GMT Message-ID: <3A66E91D.8BB9202F@erg.abdn.ac.uk> Date: Thu, 18 Jan 2001 13:01:15 +0000 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: erg.abdn.ac.uk X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Mingyan Liu , tcpsat@grc.nasa.gov Subject: Re: TCP end-to-end Semantics - OPTIONS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Mingyan Liu wrote: > > > > > > TCP OPTION? > > > > > > If you can find out why you want to do it, and what benefit you get, why > > > not consider a TCP option? I haven't heard of anyone (yet?) trying > > > these spoofing ideas for UDP (???). If your target is TCP, and your spoofer > > > **must** demultiplex individual flows and interpret TCP header semantics, > > > why not negotiate "willingness to spoof" on TCP connection setup? Failure > > > to see this option, could indicate unwillingness (including encryption? old > > > protocol stack? lazy application?) - I wonder whether this has more > > > potential? > > > > This is an interesting idea. Something like the following... > > > > The initiator adds a "PEP" option to the SYN. If there is no PEP in the path, > > the receiver sends no option in the SYN ACK, letting the initiator know the > > connection is end to end. If there is a PEP in the path, the PEP adds a "PEP" > > option when it sends a SYN ACK to initiator and when it forwards or sends a > > SYN to the receiver. (The receiver could even, in theory, tell the PEP to get > > out of the way by not including the "PEP" option in its own SYN ACK response.) > > > > I can see why it makes sense to do so, but this would mean the spoofer > will need to check the TCP header of all passing (TCP) packets, even > those belonging to a connection that did not choose to use the PEP? > I guess this probably still beats using an IP "option", which gets the > packet kicked out of the fast lane...? > Sure it does. The TCP option allows fast path forwarding by all routers along path from the source to the destination, except the PEP itself. The IP option, means the spoofer has to look at all IP packets (slow path), THEN look at any TCP packet which it MAY spoof. Furthermore each router along the TCP PATH also looks at the IP OPTIONS. The PEP can choose to do as much work as it likes. It can look at all TCP packets - or it can implement a TCP flow cache, based on a list of established connections. and there known use of PEP or not. > -mingyan -- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry From owner-tcpsat@lerc.nasa.gov Tue Jan 23 08:02:52 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10190; Tue, 23 Jan 2001 08:02:51 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA08405 for tcpsat-outgoing; Tue, 23 Jan 2001 07:18:49 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA08390; Tue, 23 Jan 2001 07:18:38 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id HAA26291; Tue, 23 Jan 2001 07:18:37 -0500 Received: from ada.cs.ucy.ac.cy(194.42.7.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma026230; Tue, 23 Jan 01 07:18:03 -0500 Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id NAA47704; Tue, 23 Jan 2001 13:50:43 +0200 Message-ID: <01c901c08532$8dd269d0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , , "comm-theory" , , , , "Conferencesa" , , , , , , , , , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , Cc: "Andreas Pitsillides" Subject: INFOCOM 2002 CALL FOR PAPERS Date: Tue, 23 Jan 2001 13:48:49 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01B4_01C08543.36C53210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit Please accept our sincere apologies for multiple copies INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002. For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =========================== David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; name="cfp2002.txt" Content-Disposition: attachment; filename="cfp2002.txt" Content-Transfer-Encoding: quoted-printable INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE =3D=3D=3D=3D=3D The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002.=20 For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =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 David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology = (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: application/pdf; name="cfp2002.pdf" Content-Disposition: attachment; filename="cfp2002.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAtMTAwIG51bGxd Cj4+CmVuZG9iagozIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjEyIG51bGxdCj4+CmVu ZG9iago0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgLTcwIG51bGxdCj4+CmVuZG9iago1 IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvSW0xCi9XaWR0 aCAzMDkKL0hlaWdodCAyNTcKL0JpdHNQZXJDb21wb25lbnQgMQovQ29sb3JTcGFjZSAvRGV2aWNl R3JheQovTGVuZ3RoIDU4NgovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwK L0sgLTEgL0NvbHVtbnMgMzA5Pj4KPj4Kc3RyZWFtDQr///5kDCEfmSAapl4bUycCSCIFe0oEDgg4 IgeCbUwg4QOCDhBwiGuOYuUOHBAiKA0UQ1CoOEQ0jBB+DhEM0cobQMOEEKg3QQUMHCBKD0CTDdJQ YdBbDhAgoboJQ3CCVuglDcJKG6CVh0goN0EFbpBW6CUN0gt0lbpAkG6RFwVW6QV6CI0BOGHSCb0k m9bdJO6VN6t6W3p26u+g90iShtt0gd6Tt6fq7eqelbdVvSb1TukQMDwd+SYHg13SCIHgyDfgiB4F CR6CB9IINvhBvSCB/Tb4QfpN6p3pP6IKVA3qgTINnv6VBt6SBNBu+lgw/oKn6SW3frbfpbf0Fh/r 3eq36pbb9Le9e39Lute7fS/9bfX7+u/69/9/97/9Vr+/99f///2//////X////1+//uv+n/bpJf3 9v6/b/71Xvr++vv1V29f+l7bX+3pV4eq3d0vbel9vX2w9Je2qXdg8JV4eFXbBhMJVdgwmEvhiK7b CS218NVdpdhhdwwl2GElwYXcGvYMgeCmrVsigHg21yq5cDwXW2TIFZdhgqu0lbpd9X1t9bTW+lb0 tp9tUt2sOmltVsNOrYTCXTSsNBpWwmtsJoK2EGtsEGgrDCIHg6tW00rdpQ2qVh2lYeErettsIKGH QSsORML8pznpWGd+jYdAiOrBndeCjDYhKwztOCiwYShsIKwwlDBglDIZq0FDBlSBohhksBqhkGsb ChkNccqsKGIhQwUMKDCgwUGQPW1kGFMoA3mUwVZloGlMi+R2RwsRH////+ACACAKZW5kc3RyZWFt CmVuZG9iago2IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTcwIG51bGxdCj4+CmVuZG9i ago3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTkwIG51bGxdCj4+CmVuZG9iago4IDAg b2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjIyIG51bGxdCj4+CmVuZG9iago5IDAgb2JqCjw8 Ci9EIFsxIDAgUiAvWFlaIG51bGwgMTg4IG51bGxdCj4+CmVuZG9iagoxMCAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIDI1MiBudWxsXQo+PgplbmRvYmoKMTEgMCBvYmoKPDwKL0QgWzEgMCBS IC9YWVogbnVsbCAzNTEgbnVsbF0KPj4KZW5kb2JqCjEyIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFla IG51bGwgMzY3IG51bGxdCj4+CmVuZG9iagoxMyAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxs IDM4MSBudWxsXQo+PgplbmRvYmoKMTQgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAzOTQg bnVsbF0KPj4KZW5kb2JqCjE1IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDQxIG51bGxd Cj4+CmVuZG9iagoxNiAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1OCBudWxsXQo+Pgpl bmRvYmoKMTcgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NzIgbnVsbF0KPj4KZW5kb2Jq CjE4IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDg2IG51bGxdCj4+CmVuZG9iagoxOSAw IG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDE4MSBudWxsXQo+PgplbmRvYmoKMjAgMCBvYmoK PDwKL0QgWzEgMCBSIC9YWVogbnVsbCAyMDkgbnVsbF0KPj4KZW5kb2JqCjIxIDAgb2JqCjw8Ci9E IFsxIDAgUiAvWFlaIG51bGwgMzM0IG51bGxdCj4+CmVuZG9iagoyMiAwIG9iago8PAovRCBbMSAw IFIgL1hZWiBudWxsIDM3NSBudWxsXQo+PgplbmRvYmoKMjMgMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCAzODggbnVsbF0KPj4KZW5kb2JqCjI0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51 bGwgNDAxIG51bGxdCj4+CmVuZG9iagoyNSAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQx MyBudWxsXQo+PgplbmRvYmoKMjYgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0MjYgbnVs bF0KPj4KZW5kb2JqCjI3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDM5IG51bGxdCj4+ CmVuZG9iagoyOCAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1MSBudWxsXQo+PgplbmRv YmoKMjkgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NjQgbnVsbF0KPj4KZW5kb2JqCjMw IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDc3IG51bGxdCj4+CmVuZG9iagozMSAwIG9i ago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ5MCBudWxsXQo+PgplbmRvYmoKMzIgMCBvYmoKPDwK L0QgWzEgMCBSIC9YWVogbnVsbCA1MDIgbnVsbF0KPj4KZW5kb2JqCjMzIDAgb2JqCjw8Ci9EIFsx IDAgUiAvWFlaIG51bGwgNTE1IG51bGxdCj4+CmVuZG9iagozNCAwIG9iago8PAovRCBbMSAwIFIg L1hZWiBudWxsIDUyOCBudWxsXQo+PgplbmRvYmoKMzUgMCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAo RDoxOTEwMDExMDYxMjA3MDMpCi9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgQ29tbWFuZCAz LjAxIGZvciBTb2xhcmlzIDIuMyBhbmQgbGF0ZXIgXChTUEFSQ1wpKQovVGl0bGUgKGNzLmVwcykK L0NyZWF0b3IgKEZyYW1lTWFrZXIgeG01LjVQNGYpCj4+CmVuZG9iagozNiAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIG51bGwgbnVsbF0KPj4KZW5kb2JqCjM3IDAgb2JqCjw8Ci9EIFsxIDAg UiAvWFlaIG51bGwgbnVsbCBudWxsXQo+PgplbmRvYmoKMzggMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCBudWxsIG51bGxdCj4+CmVuZG9iagozOSAwIG9iago8PAovTGVuZ3RoIDQ4MTUKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiYxX23LbOBJ911fgaYtKWTSuBJm3xHG8zubi iVWzteXMg0zDMhOJ9FJSXNmv39MAQYn0ZTKpGuq4ge6D7kZ3Q7Dl5PjsUrDlZiJYxSaccZYJyWwh WesmtxNhmbWSGZuxmTWZ/+Oric45/sxTDalOuWazTBAI0v9O8EfBDQvaSOA38IKV68nx+Vqwd83k j8nb+eT4vWSCzW8nOvOr8REmxUKrbMpzNl+D0nIy4ynP2LwEmD9MrpKTNx8/Mvb+y1fGLqZWJ28u Tr9eTv+af4BCHRTiEKQQH4XjiCKogork8r6pN03rbtj1r+n8O7ZkYYtJjcwVNs3fwcZrxtj8zrHz erOttrutY80tO125cttW5WLFFvVNB6c6S5q6Ktlpvaxq59qp4MnmCDvLlH1Lzk9PT79Njzw9kXJj 2EykIsss2fFSdtKs72GhZZdNWbntL/YPFv++3kHzYluBc5QS6dM5TnM2kewD+H5nkoLwwFSaZ+wT u/qLs5uJNgW50CoJa2wNrNMs857NcjZCukiFRjCxlpUTrVWawW06S41gzyBLn4O1eYpEGaOg1ij6 lD0FY1O4YYwC3Uyl3NJa/NBIhCxPTcHGSNOnQ7TWpHYvPATIUiEOtCI1jeptDlGONDMHbHNkhO3P 8jSKXog4+GiEgt7o3M5o5/kRCnRDzPqDySzNNBsBOC+CvbeicIAGiVBOrl/hstO/dtn9+HqGbPrA BC17YFAmQmBEKq3PnJwSyxpOf9bkLXBEbBXlUZ4q5d0SGMMYftDRC8VIUxEQVNMBhImISGNvj7UV IQfDTqDCHui1Ms17oxBq0xOCmkg3qg1QFV5IoQAyASgPMtMpVV5NUfhISL03ocI5bJrrbikPIVVe jyRg6EOhIP8CqaJzQV54TGmNHPDbKGuMIUt0KOUXmlSHQ+W59ysJibftPQeUh0wQIQaeOiGbe6QD 2sfLB5gKA/YUVBdshvxTFEe6NtZfBsNGAHkXFwZiGTkmCzdziKQPIj4hiDhM1t0Eqg4D1K3V/f0P mpRfNEKBgkKKhCsd6CkcVLAxCufq1yJWlJHK58EYZcHl/aVG28p6gkPUre2P1mnqDj5EA9+Wk42/ goUK5cN4b6vgKP9Z+RORa3BhitzjLJXqUG5CUo+w8mmx8vryYo/Raak3GmQvpYLkpF1BJ5tpStXQ jHsxaofuxJ7nUKw4peDzYtxQ+bxYU0N7QUx35lkp5fALzMjdLzCji/ACM/g4f45Z5kcbyJBEj4QI DCYRnR3IdScX5PVChLQStHQ9MTlVrdy3Ha4lwmOQLjmnS4UsLwQzCD/VDGp6KFMRBgXlJGKJUqto 4Op2CwuiBev1EylByXkboo9OI4OLTeZ5GF8mAqZd2uyRpVztEExGrGhRjzjV5IiQbNL4tZkv8wGT FeryEek0D4mqtF8rKcPpAmKLyVG4rNcrjEdFN2iIbi0dU2tqkSZXqZS+clrrrXC950uhyVCwM+9E TKhS063FcFjEwTTKUVGtOZCbsVyTl56XUwV/SY5gFeYF+wr2XxLDvHhBLgtK3hfkXvI8PTGin/WZ 27V9Y4vQlyX1Okvl4nAdR0tY+gETRcVPBIgI93M0+V3R75ngaXglvH0VZk3ts1WHUbP7vep+G4rr ar9ujBX1PMKK6tBjLOgSHqwfYR4AJ7cOARhnQVPuTxzxNb1ihJ/LImlU/+7Ged4RRqpx9RhHqtYM qUccqcb1IxzY0nQjR6CnnvNH1C0fUEeNOaQeYaQaV49xpIp0HlCPOFKN60c4sKXBRIxATz0rxtT9 qy8PLy4ZHmmSrjKKB86cE4Pu1XeVnNe3U2mSpl37FxBr6u6RJ3hQgMrAUTX9ky15HV5zQoxfgCIM 15ivvO5k1y3slFCnsKZTwi531+tqsyFzFZ5+7a70j6+RblwZHt+KY33wkpAmviMv2mbZLtb+vdi6 qTDJsoJaf6B4mk7rTCBHSS0eiAr//Z3y5GPjX6Jtu6iXbu3q7Zgm5v9c/RbNy+3uBgo8TbCbSp78 JLJuxUCfNAeuXeQwS3nnagRP0DxE8wU59yq5227vXx8fPzw8TC1P0so5N6u6QJbNOm3aqeDJ8lhy Lr1SjA5eF3ot8oQebbjV6Hle22V55252K8e+JfBaVW5Xv5gjbTohRXlSuptRUiBNlda6O/W3KR17 nwwKjYhsoAWgVHob73erFbtf3LuW3ezcdJZj1Es+7GBJiSMGnsJb4BQXkSGRvcc+N9vqm1JZ2eXm LVuUpbvfLuoSOoSUOZaQC4Mf19dQL/SBvvkrsl3VCCGW6MS1Pus8BZ3bPHnnyrBN8oNt+xiM/aYK 0/vtpKlvnXeQAx8W3Th21dgtCrUmumU+1TrZbZu2Wqw201khcg2v1I5JNZPhIHJ/kGDQ+cPnQstu qZlJe7D0dI4mdDZR1FQUsgdVlklL3UT55nM5OT65FOzkknF6THGaEsAwRXU5vhDs8uTzM9u8VsPh CoWUNGxm5e/qe2rXYZU68DOGUSiQhaXJxjvprFourqst++y2D5TXTfujqpfs31NLdevH5q65f97n 6MKYmCQqJpWl85qVTf19V/uKwx6q7R1DBaRLExyIPMaYlIUCERMxhuSoXyOofXsT9EP5sifRhce3 MzNJCt2bpvR30uJObstlfVz2kTxeXtePQodKKvFukfAHAv27Tn5q19NO1pKqH06T0VvPk/5y7+o3 4bbf7XPpSZcWkkYfUXAabH7XqxiAOUX/kVfzmSz2joXcSGuGZWDk0AZUF215l4bqtBxe2ZnC467I KB7gZ7ylM1e7FjXg5G5Rtb6HqaGFC8qrxZQnvnD+rP7H/kXF1KEr1lWnX8d+mIvYHI7Y+dtPoeRH 64UXD5T/OVU2qUo38+Y3r72+EYH3oY7csLeLHWpKIZOjoVkchuORFux+bn5Ui6HdTv7EqaikVwv2 qWmDjcXKjXTnqeg7LbUpF8ppvUEUN9uU6u6cKDk4qJwKkdzVzapZ/ho5nmYXno8OFjaWd3VFffQC FIokdOuT5iWHvFtQAH5WN+yjG/PF6KSiL66Stw6t5ePiesO+uo1DYtCp7xBrlP0Rw27jwNCbtnKr 6Yx6yZf2ZvHI7aLv3ziKij6AhZqmC79vFj7nm3YRVXnHhZ/Nbfj+jgvzdJg8CAamBap2J816XW23 zj2fxP9chOyl/7lf7L0vOM4hhYdnwotS9AlcfVpsfiCP63KQT3h86ZjlaTfUqK4SGHoNoaBTIQLA HRMYKlFxjBapVmG25OEVdJV8mEqRxJZ22KcOZigVNGKPooes4hhOzIG6hF39LQclPdhvukrQMaYi Sx7Yf+ASQb2CnVTb/7NeNc1t40j0rl+BU0pKjRUCIEBybxOvM5WpymR2rKo9ZPcgU7TDXUl0UVRS /vf7XoOSaAramrFTPliP3Wh0N/rzaVzZxrfbeQY56PdJfpqTF18rJEGeTL9jhHu64lTS7jr183a7 R1z/2tQY7E79mSnT4cTHm5sbPt3jvsOMwcGP77hnMsjIq26bsq66ugqzH2beop/6MoSq0lhgMpWy 4OYjtw5roj+NgIfxzzwb/9BXZFVLOPrLTvnHLxPsGT4v2EFclqorkzj+PnZ6jQZRZGygaNnF/M+2 +vix0e2wwKWGC4PPRIPNxKGHoj8ITtUYFQeEwaScOKxAxgs2oI6Qmess8FrhtbxAJBk1Rimf3nMl 8sLruRX6jO18BAquYx4LK1YocGa4k9pDgFVjZOYF77BzJ9riM7qsx2e03jHy85SXJAe5OdX2Pp+n uPUMYXZCuvMy8hY85KGnvOEY0WMwNzM9L70CV1mnxigXLwAlea+D3JPQ/nOUC0hsz4qM8S64foSC Ck7uCip4E7BWEQSXORjqet6MkjJJxecoR3/nyZSGgjf39I53yRyXjgGlpgXTJ3Ai+IhpdhzBhGLI m/N9zpHXgoIXcokKn2Zzb9UYOYon0sKacmjyqZ+jD52j5IjIK4XoSI0iKX0DXseAGaP+lnRusl6H ghgjmVZj5CSSkZxZkOvmLhPMqDpHAJqPE1gZyqH+jlF/idSBoIKzgnUw/DmiurZgVAZeTLXEmVHn CFlEpIuely60+RxNcYyQj15QkvUuQ23xNpunwaFDZCT3rWeZI6/h5uYtHlNdAokeckqWj1F/B8zV vQZpoNpAjSBLAQNemb3PEV6WKB0aptlMxsgww4h8UEEzgIgNzX6GUPlYK23SPwRKFgMb2Bs1RmDS gnSopIUoaIq+eA4AXgO/UXPkFVDNWA6BUSzOEQu78f2L9RUZjb5Qz8DTiIZsszoAr75NsFEw7rxJ mbARVBx4S+Et/EFQDDiE9JCz7yUjJLVBkOQysNahKzk1Qs86YTm5fzvhXCR9nh1K6jgCCNvd3Ml0 iFRCVwUfPURBzjO0DTPuOTml56RKpJHTzolw3A8PxMnh2ZCdEbJhmWfGIPjip1OpxEXsbpbdTJyZ iHB/RmYdgmFZVLWcCc9+UVzQHNnoOQroEzkbnk6lBcftNkJG1A41zwaqMZrhehfV3EuGORkYInaH XHWo0DGn4rTUX8esOgrPBqe1FEqr41ebUF+iXullczy58J5hFioOeov7DoeTuTt2wKhZDEQEXO5j ZGgcilAecwquZtdGouv0eDdM6ckMMbE6ieWADTlgpI9HyMgBH+pflNx3dsdHjZBlE5EU0XGzkzC+ JUUkVKh4IWSdXyCLz3wszOAyK1OktjGyDSOx45Rx0eFhYj5/TbQV9uOQfY61ZexSGd0w5/gYORXh nN0MyRmFu4HLkDd91Q7UyGEozkYbIzMUYHYae2xW2VzCkEPbQbOjV9g4iqC4iSjO0/awGwSyYS8+ 3K3F5dTcRNKLnSKXgmcvkCmc+a+PLj8JJzmTsdXTMAymZ3eH0Soahpq7BEf0Io9czcNhM/CxKOVp HaaQg09TmjKwKw1xGMvd3uxh2Ug5HQZyZLMzWvord6Vcyb51ZTkF9vJ0EVpjHmzxIzLaMk1FAGSR w5Cdecko/IuQU2nmmDGMvnCaVcqxBkdPk4wXtBfIXFlQaOAuy5XxCo11dDWWFJ3GrJaIZc5wRWKL GGtGJyM6EL/hdM4ifzjt6HEKN1GX5uE0hNg4uV8dkNURu4zstlZGlqjTfJg1s4NPZcMZCMfdiBId vdscXiTqU54OHc1f8BrttjLaRIWz1CDSnKiWj8gupHvCf5HTLsS9Y9Zc1Jxei92dFDIrc46Jap5I Z3DpyWvj0yEHYpolPnjFXjjsJQkw3mRFnJyH9Ps/D2IkEKNO4dXYZ1zMrCST5MVrc8hhW3tOtmGB kIn2+CBmQM6Cz0wse6Ea90AEIkJJYmxIfr+YvPsAglaL+wkaAIpVgr9M6qpxMukacdxiM5l+vLm5 mS3+M0llhTsxalRYJiI4fc9JNid9nmw6SZgmup9fT3zbqLhCU5EB24fP15+jEq2RQBuwbmISbeHm OhuymSQx5ESFQVUjJ/YR5BzKOoZgVxScucD4Zbr4WqnrZns/K6ZVW23LSjVbfNg87ruq5Y/NTPvp fluXy65utrvZvxe/Tm4Wp31Dq18muNyi8lhYf2WM1Pn3byfvrm+1ur5lqYe2HCWgCF/w3e9a3V7/ Fjt2279ZEt4Mw4K4w/C10OSttlwaoXmiHqD957Z+qLfLtXpcPlbtTi3bStXbWaqn3+quWtGWtiqr baeWq28z46ZLWLgDiyp7E8WehO1Loxmqxd8hFbTNwGLoZnBwFX5sq+77TCfTpv1vvX2Yh4+LWY4v j3XZczf34X+9xRXVriOyQOV6v6p+CrS7mUmm+1ky7USHxVvcTP23TafW9Ub075qfVIcXum/W62Zm /PQ77vyb8MNJuncSOlsfNfOsd5RB78V7MxZaBsLApcjGLAW3mPq+bZarOxin3qifZ1rTlGT6aXwD B5+sCIdiAv1R4G8n96jHti6h70jYlcZ04LUMcTpHn7gg86DkFOH5AB/iLaDkcrWpdzv+Lptt1zbr /uBrNW26pmzWu1fq+mX6oX+no3o/xJO7p11XbdSuuQ/fECev1vQjYzNEs+6jGf79+PvLNf782CFp 1mqQIq936Kfmrl5X0Ox73VbrardTA53H4v+0stN/7JfruntSzb3aVe23uqyeB9JfjtJP+zWtR66/ LCCnfzT7jtnyA9TYVKt6+VI9bsuv1Wq/frUqhwiWh1LLx8f1oaLiMXufv/j9vkxvq3Lf8gXfsM6w tocCj/JVzrSbPr068p6p35ZfUZHLbt++SumuaZcPFfvU8semyVDZVbWrH1gsH9fL7fa8Av+FWPhe dwgHeTH5+YOjYrPcwh0bNug3L6mYaHguLw6S1WJm3bRd3jMQ/mWtL1W1xXxQVW28Dbk81S9TXG2q 5Q6xQNXpnQ4N6q5avSI0/skRorpT5TJ4+UcGxKZZVetXxMFJO0xZ90274Rh1mAT/J8AAHQJaSQpl bmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIg XQovRm9udCA8PAovRjIgNDEgMCBSCi9GNCA0MiAwIFIKL0Y2IDQzIDAgUgovRjggNDQgMCBSCi9G MTAgNDUgMCBSCi9GMTEgNDYgMCBSCi9GMTMgNDcgMCBSCj4+Ci9YT2JqZWN0IDw8Ci9JbTEgNSAw IFIKPj4KL1BhdHRlcm4gPDwKL1AxIDQ4IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNDkgMCBS Cj4+Ci9Db2xvclNwYWNlIDw8Ci9DUzEgNTAgMCBSCj4+Cj4+CmVuZG9iago1MCAwIG9iagpbL1Bh dHRlcm4gL0RldmljZUNNWUsgXQplbmRvYmoKNTIgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+ PgplbmRvYmoKNDggMCBvYmoKPDwKL1R5cGUgL1BhdHRlcm4KL1BhdHRlcm5UeXBlIDEKL1Jlc291 cmNlcyA1MiAwIFIKL01hdHJpeCBbMC45IDAgMCAwLjkgMCAwXQovUGFpbnRUeXBlIDIKL1RpbGlu Z1R5cGUgMwovQkJveCBbMCAwIDggOF0KL1hTdGVwIDgKL1lTdGVwIDgKL0xlbmd0aCA4OQovRmls dGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJFMgxDkBAFIThfk7xX4Ds8iL2ChKFKBSioyBL QuP6nswU882tyI4CgdbzbJq4VNH5cVDzUpdtQ8+8BFYVEe+pRCLLKMwRK8zl+5fhzho16BNgAHLx ElcKZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago8PAovVHlwZSAvSGFsZnRvbmUKL0hhbGZ0b25l VHlwZSAxCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpCi9GcmVxdWVuY3kgNjAKL0FuZ2xlIDQ1Ci9T cG90RnVuY3Rpb24gL1JvdW5kCj4+CmVuZG9iago0OSAwIG9iago8PAovVHlwZSAvRXh0R1N0YXRl Ci9TQSBmYWxzZQovT1AgZmFsc2UKL0hUIC9EZWZhdWx0Cj4+CmVuZG9iago1NCAwIG9iago8PAov VHlwZSAvRm9udERlc2NyaXB0b3IKL0FzY2VudCA3MTIKL0NhcEhlaWdodCA3MTIKL0Rlc2NlbnQg LTIzMgovRmxhZ3MgMjYyMTc4Ci9Gb250QkJveCBbLTE1MiAtMjY2IDEwMDAgOTI0XQovRm9udE5h bWUgL1BhbGF0aW5vLUJvbGQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyMgovWEhlaWdodCA0NzIK Pj4KZW5kb2JqCjQxIDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAv RjIKL0ZpcnN0Q2hhciAzMgovTGFzdENoYXIgMjU1Ci9XaWR0aHMgWzI1MCAyNzggNDAyIDUwMCA1 MDAgODg5IDgzMyAyMjcgMzMzIDMzMyA0NDQgNjA2IDI1MCAzMzMgMjUwIDI5NiAKNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI1MCAyNTAgNjA2IDYwNiA2MDYgNDQ0IAo3 NDcgNzc4IDY2NyA3MjIgODMzIDYxMSA1NTYgODMzIDgzMyAzODkgMzg5IDc3OCA2MTEgMTAwMCA4 MzMgODMzIAo2MTEgODMzIDcyMiA2MTEgNjY3IDc3OCA3NzggMTAwMCA2NjcgNjY3IDY2NyAzMzMg NjA2IDMzMyA2MDYgNTAwIAozMzMgNTAwIDYxMSA0NDQgNjExIDUwMCAzODkgNTU2IDYxMSAzMzMg MzMzIDYxMSAzMzMgODg5IDYxMSA1NTYgCjYxMSA2MTEgMzg5IDQ0NCAzMzMgNjExIDU1NiA4MzMg NTAwIDU1NiA1MDAgMzEwIDYwNiAzMTAgNjA2IDI1MCAKNzc4IDc3OCA3MjIgNjExIDgzMyA4MzMg Nzc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDQ0NCA1MDAgNTAwIAo1MDAgNTAwIDMzMyAzMzMg MzMzIDMzMyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA2MTEgNjExIDYxMSA2MTEgCjUwMCAyNTAg NTAwIDUwMCA1MDAgNjA2IDY0MSA2MTEgNzQ3IDc0NyA5OTggMzMzIDMzMyAyNTAgMTAwMCA4MzMg CjI1MCAyNTAgMjUwIDI1MCA1MDAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgNDM4IDQ4OCAyNTAg Nzc4IDU1NiAKNDQ0IDI3OCA2MDYgMjUwIDUwMCAyNTAgMjUwIDUwMCA1MDAgMTAwMCAyNTAgNzc4 IDc3OCA4MzMgMTAwMCA4MzMgCjUwMCAxMDAwIDUwMCA1MDAgMjc4IDI3OCAyNTAgMjUwIDU1NiA2 NjcgMTY3IDUwMCAzODkgMzg5IDYxMSA2MTEgCjUwMCAyNTAgMzMzIDUwMCAxMDAwIDc3OCA2MTEg Nzc4IDYxMSA2MTEgMzg5IDM4OSAzODkgMzg5IDgzMyA4MzMgCjI1MCA4MzMgNzc4IDc3OCA3Nzgg MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAKXQovRW5jb2Rpbmcg NTUgMCBSCi9CYXNlRm9udCAvUGFsYXRpbm8tQm9sZAovRm9udERlc2NyaXB0b3IgNTQgMCBSCj4+ CmVuZG9iago0MiAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y0 Ci9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1Cb2xkSXRhbGljCj4+CmVuZG9iago0 MyAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y2Ci9FbmNvZGlu ZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1JdGFsaWMKPj4KZW5kb2JqCjQ0IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjgKL0VuY29kaW5nIDU1IDAgUgovQmFz ZUZvbnQgL1RpbWVzLUJvbGQKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMQovTmFtZSAvRjEwCi9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1S b21hbgo+PgplbmRvYmoKNDYgMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9O YW1lIC9GMTEKL0Jhc2VGb250IC9aYXBmRGluZ2JhdHMKPj4KZW5kb2JqCjQ3IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjEzCi9FbmNvZGluZyA1NSAwIFIKL0Jh c2VGb250IC9IZWx2ZXRpY2EtQm9sZAo+PgplbmRvYmoKNTUgMCBvYmoKPDwKL1R5cGUgL0VuY29k aW5nCi9EaWZmZXJlbmNlcyBbIDM5L3F1b3Rlc2luZ2xlIDk2L2dyYXZlIDEyOC9BZGllcmVzaXMv QXJpbmcvQ2NlZGlsbGEvRWFjdXRlL050aWxkZS9PZGllcmVzaXMKL1VkaWVyZXNpcy9hYWN1dGUv YWdyYXZlL2FjaXJjdW1mbGV4L2FkaWVyZXNpcy9hdGlsZGUvYXJpbmcvY2NlZGlsbGEKL2VhY3V0 ZS9lZ3JhdmUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lhY3V0ZS9pZ3JhdmUvaWNpcmN1bWZsZXgv aWRpZXJlc2lzCi9udGlsZGUvb2FjdXRlL29ncmF2ZS9vY2lyY3VtZmxleC9vZGllcmVzaXMvb3Rp bGRlL3VhY3V0ZS91Z3JhdmUKL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy9kYWdnZXIvLm5vdGRlZiAx NjQvc2VjdGlvbi9idWxsZXQvcGFyYWdyYXBoL2dlcm1hbmRibHMKL3JlZ2lzdGVyZWQvY29weXJp Z2h0L3RyYWRlbWFyay9hY3V0ZS9kaWVyZXNpcy8ubm90ZGVmL0FFL09zbGFzaAogMTc3Ly5ub3Rk ZWYvLm5vdGRlZi8ubm90ZGVmL3llbiAxODIvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRl ZgovLm5vdGRlZi9vcmRmZW1pbmluZS9vcmRtYXNjdWxpbmUvLm5vdGRlZi9hZS9vc2xhc2gvcXVl c3Rpb25kb3duL2V4Y2xhbWRvd24KL2xvZ2ljYWxub3QvLm5vdGRlZi9mbG9yaW4vLm5vdGRlZi8u bm90ZGVmL2d1aWxsZW1vdGxlZnQvZ3VpbGxlbW90cmlnaHQvZWxsaXBzaXMKLy5ub3RkZWYvQWdy YXZlL0F0aWxkZS9PdGlsZGUvT0Uvb2UvZW5kYXNoL2VtZGFzaAovcXVvdGVkYmxsZWZ0L3F1b3Rl ZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQgMjE2L3lkaWVyZXNpcy9ZZGllcmVzaXMvZnJh Y3Rpb24vY3VycmVuY3kKL2d1aWxzaW5nbGxlZnQvZ3VpbHNpbmdscmlnaHQvZmkvZmwvZGFnZ2Vy ZGJsL3BlcmlvZGNlbnRlcmVkL3F1b3Rlc2luZ2xiYXNlL3F1b3RlZGJsYmFzZQovcGVydGhvdXNh bmQvQWNpcmN1bWZsZXgvRWNpcmN1bWZsZXgvQWFjdXRlL0VkaWVyZXNpcy9FZ3JhdmUvSWFjdXRl L0ljaXJjdW1mbGV4Ci9JZGllcmVzaXMvSWdyYXZlL09hY3V0ZS9PY2lyY3VtZmxleCAyNDEvT2dy YXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZ3JhdmUKIDI0Ni9jaXJjdW1mbGV4L3RpbGRlL21hY3Jv bi9icmV2ZS9kb3RhY2NlbnQvcmluZy9jZWRpbGxhL2h1bmdhcnVtbGF1dAovb2dvbmVrL2Nhcm9u Cl0KPj4KZW5kb2JqCjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA1MSAwIFIKL1Jlc291 cmNlcyA0MCAwIFIKL0NvbnRlbnRzIDM5IDAgUgovQ3JvcEJveCBbMCAwIDYxMiA3OTJdCj4+CmVu ZG9iago1MSAwIG9iago8PAovVHlwZSAvUGFnZXMKL0tpZHMgWzEgMCBSXQovQ291bnQgMQovTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQo+PgplbmRvYmoKNTYgMCBvYmoKPDwKL05hbWVzIFsoRikgMzcg MCBSIChHOTk2NzM1KSAzIDAgUiAoRzk5NjczOCkgMiAwIFIgKEc5OTc4MDYpIDQgMCBSIChHOTk3 ODA5KSA4IDAgUiAoRzk5NzgxMikgOSAwIFIgKEc5OTc4MTQpIDEwIDAgUiAoRzk5NzgxNSkgMTEg MCBSCihHOTk3ODE2KSAxMiAwIFIgKEc5OTc4MTcpIDEzIDAgUiAoRzk5NzgxOCkgMTQgMCBSIChH OTk3ODE5KSAxNSAwIFIgKEc5OTc4MjApIDE2IDAgUiAoRzk5NzgyMSkgMTcgMCBSIChHOTk3ODIy KSAxOCAwIFIgKEc5OTc4MjMpIDE5IDAgUgooRzk5ODAzOCkgNiAwIFIgKEc5OTgwMzkpIDcgMCBS IChHOTk4NTM1KSAyMSAwIFIgKEc5OTg4MzgpIDI2IDAgUiAoRzk5ODgzOSkgMjcgMCBSIChHOTk5 MDg3KSAyMCAwIFIgKEc5OTkxNTMpIDMwIDAgUiAoRzk5OTE1NCkgMzIgMCBSCihHOTk5MTU1KSAz MyAwIFIgKEc5OTkxNTgpIDI5IDAgUiAoRzk5OTE2NCkgMjggMCBSIChHOTk5MTg1KSAyMiAwIFIg KEc5OTkzODQpIDI1IDAgUiAoRzk5OTM4OSkgMjQgMCBSIChHOTk5NDE0KSAzMSAwIFIgKEc5OTk0 NzgpIDM0IDAgUgooRzk5OTQ5NCkgMjMgMCBSIChMKSAzOCAwIFIgKFAuMSkgMzYgMCBSXQo+Pgpl bmRvYmoKNTcgMCBvYmoKPDwKL0Rlc3RzIDU2IDAgUgo+PgplbmRvYmoKNTggMCBvYmoKPDwKL1R5 cGUgL0NhdGFsb2cKL1BhZ2VzIDUxIDAgUgovTmFtZXMgNTcgMCBSCj4+CmVuZG9iagp4cmVmCjAg NTkKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDExNTg0IDAwMDAwIG4gCjAwMDAwMDAwMTYgMDAw MDAgbiAKMDAwMDAwMDA2OCAwMDAwMCBuIAowMDAwMDAwMTE5IDAwMDAwIG4gCjAwMDAwMDAxNzAg MDAwMDAgbiAKMDAwMDAwMDk3NyAwMDAwMCBuIAowMDAwMDAxMDI4IDAwMDAwIG4gCjAwMDAwMDEw NzkgMDAwMDAgbiAKMDAwMDAwMTEzMCAwMDAwMCBuIAowMDAwMDAxMTgxIDAwMDAwIG4gCjAwMDAw MDEyMzMgMDAwMDAgbiAKMDAwMDAwMTI4NSAwMDAwMCBuIAowMDAwMDAxMzM3IDAwMDAwIG4gCjAw MDAwMDEzODkgMDAwMDAgbiAKMDAwMDAwMTQ0MSAwMDAwMCBuIAowMDAwMDAxNDkzIDAwMDAwIG4g CjAwMDAwMDE1NDUgMDAwMDAgbiAKMDAwMDAwMTU5NyAwMDAwMCBuIAowMDAwMDAxNjQ5IDAwMDAw IG4gCjAwMDAwMDE3MDEgMDAwMDAgbiAKMDAwMDAwMTc1MyAwMDAwMCBuIAowMDAwMDAxODA1IDAw MDAwIG4gCjAwMDAwMDE4NTcgMDAwMDAgbiAKMDAwMDAwMTkwOSAwMDAwMCBuIAowMDAwMDAxOTYx IDAwMDAwIG4gCjAwMDAwMDIwMTMgMDAwMDAgbiAKMDAwMDAwMjA2NSAwMDAwMCBuIAowMDAwMDAy MTE3IDAwMDAwIG4gCjAwMDAwMDIxNjkgMDAwMDAgbiAKMDAwMDAwMjIyMSAwMDAwMCBuIAowMDAw MDAyMjczIDAwMDAwIG4gCjAwMDAwMDIzMjUgMDAwMDAgbiAKMDAwMDAwMjM3NyAwMDAwMCBuIAow MDAwMDAyNDI5IDAwMDAwIG4gCjAwMDAwMDI0ODEgMDAwMDAgbiAKMDAwMDAwMjY2MyAwMDAwMCBu IAowMDAwMDAyNzE2IDAwMDAwIG4gCjAwMDAwMDI3NjkgMDAwMDAgbiAKMDAwMDAwMjgyMiAwMDAw MCBuIAowMDAwMDA3NzExIDAwMDAwIG4gCjAwMDAwMDg3MzEgMDAwMDAgbiAKMDAwMDAwOTgxMiAw MDAwMCBuIAowMDAwMDA5OTE3IDAwMDAwIG4gCjAwMDAwMTAwMTggMDAwMDAgbiAKMDAwMDAxMDEx NyAwMDAwMCBuIAowMDAwMDEwMjE4IDAwMDAwIG4gCjAwMDAwMTAzMDMgMDAwMDAgbiAKMDAwMDAw ODA0NiAwMDAwMCBuIAowMDAwMDA4NDY1IDAwMDAwIG4gCjAwMDAwMDc5NjcgMDAwMDAgbiAKMDAw MDAxMTY5MCAwMDAwMCBuIAowMDAwMDA4MDA3IDAwMDAwIG4gCjAwMDAwMDgzNDIgMDAwMDAgbiAK MDAwMDAwODUzNyAwMDAwMCBuIAowMDAwMDEwNDA3IDAwMDAwIG4gCjAwMDAwMTE3NzIgMDAwMDAg biAKMDAwMDAxMjM3NSAwMDAwMCBuIAowMDAwMDEyNDExIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1Np emUgNTkKL1Jvb3QgNTggMCBSCi9JbmZvIDM1IDAgUgovSUQgWzw2ZjUxMTFhYmViNzkzMzIzNTE2 NGM0NzI2MmFhMTVjZj48NmY1MTExYWJlYjc5MzMyMzUxNjRjNDcyNjJhYTE1Y2Y+XQo+PgpzdGFy dHhyZWYKMTI0NzYKJSVFT0YK ------=_NextPart_000_01B4_01C08543.36C53210-- From owner-tcpsat@lerc.nasa.gov Tue Jan 23 11:24:13 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16556; Tue, 23 Jan 2001 11:24:12 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA13672 for tcpsat-outgoing; Tue, 23 Jan 2001 10:42:32 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA13553; Tue, 23 Jan 2001 10:42:19 -0500 (EST) From: theodor@computers.gr Received: by seraph3.lerc.nasa.gov; id KAA18400; Tue, 23 Jan 2001 10:42:17 -0500 Received: from mail2.x-treme.gr(212.120.196.24) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018173; Tue, 23 Jan 01 10:40:29 -0500 Received: from computers.gr (xtr660.x-treme.gr [212.120.195.155]) by mail2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id RAA03886; Tue, 23 Jan 2001 17:15:43 +0200 Message-ID: <3A6D9E84.AE3E0813@computers.gr> Date: Tue, 23 Jan 2001 17:08:52 +0200 X-Mailer: Mozilla 4.6 [en-gb] (Win98; I) X-Accept-Language: el,en,en-GB MIME-Version: 1.0 To: colloq@cs.stanford.edu CC: ee380@shasta.stanford.edu, alg , amlist@takilab.k.dendai.ac.jp, cfp@mmlab.snu.ac.kr, comm-theory , comswtc@comsoc.org, comswtc@ieee.org, conf@colmar.uha.fr, conferences@iao.fhg.de, Conferencesa , cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, Cost264@lip6.fr, ctc-members@tinac.com, enternet@BBN.COM, fokus-user@fokus.gmd.de, f-troup@CODEX.CIS.upenn.edu, giga@tele.pitt.edu, Globecom , ieee_rtc_list@cs.tamu.edu, ieeetcpc@listserv.utoronto.ca, info-confs@comsoc.org, ipgroup@sprintlabs.com, iscc2000@infres.enst.fr, iwqos@comsoc.org, lists-mbone-eu-op-out@lists.ripe.net, Mail-distributor@KOM.th-darmstadt.de, mbone-eu-op@ripe.net, news-announce-conferences@uunet.uu.net, owner-globecom@comsoc.org, performance@haven.epm.ornl.gov, request-datacom@comsoc.org, reres@laas.fr, RHDM@lip6.fr, rm@mash.cs.berkeley.edu, seminar@cse.cuhk.edu.hk, spects02@comp.leeds.ac.uk, tccc@ieee.org, tcp-impl@lerc.nasa.gov, tcpsat@lerc.nasa.gov, terena list , webrepl@cs.utk.edu, xtp-relay@cs.concordia.ca, tfiw-announce@akalice.research.att.com Subject: (no subject) References: <00ee01c0795d$dd406c00$38072ac2@cs.ucy.ac.cy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit PLEASE, PROMOTE THE FOLLOWING ANNOUNCEMENT TO PEOPLE THAT ARE INTERESTED IN ELECTRICAL POWER ENGINEERING: Electr.Machines, Power Transmission and Distribution, High Voltages, Renewable Energy Sources, Electromagnetic Compatibility, Electric Power Market, Reliability, etc.... ******************************************* WSES/IEEE International Conference on POWER ENGINEERING Rethymnon, CRETE (GREECE). JULY 8-15, 2001 INVITATION FROM THE CHAIRMEN PROF. PECORELLI PERES AND PROF. LAMBERT-TORRES We would like to invite you for a unique opportunity to gather the forefront of technology with a stay in Crete, this magic island, the birth of the first civilization in the west european sense. You willl participate with engineers, professors, scientists, researches, managers and decision makers from all over the world who will attend this comprehensive technical conference devoted to electric power generation, transmission and distribution systems. As organizers of this Conference, our intention is to have a vision into the 21st century with a high quality technical program where you can present and learn the latest topics and issues that affect the environment, the technology, the industry and their future. Our best congratulations and thanks to all professionals for attending this invitation. Your registration on this site is the first step to make this a memorable conference. We hope you enjoy not only the technical activities but also the beauty and hospitality of Greece, the land of the Olympic Idea and especially of Crete, this unique island!. All these elements assure a special scenario to develop fertile techinical interchanges and the friendship for information and more details contact K.Ioannou : ioannou@vip.gr or theodor@computers.gr ALL THE ACCEPTED PAPERS will be published: 1)in the CD-ROM Proceedings (with Search Facilities and Page Numbering) as well as 2)in the Electrical and Computer Engineering International Reference Book Series of WSES PRESS as Post-Conference Books (Hard cover, velvet paper, international circulation). These will be different International Editions (with different ISBN). This material will be ready at the opening of the Multiconference and will be distributed to the participants. More informations: Send a message to ioannou@vip.gr or theodor@computers.gr About Crete: CRETE is a Unique Place in the World: In this magic island, so richly endowed by Nature, everything is in abundance: blond beaches with palm-trees, cool gorgers, serene coves, palm-forests, mysterious caves, minoan palaces, paleochristian churches, byzantine churches, islamic mosques, and of course modern cosmopolitan life. Crete lies in the crossroads of the three ancient continents: Europe-Asia-Africa and the Cretan Civilization borrowed elements from european, asian and african world. Also, Crete, in the minoan era, gave birth to the first civilization in the west-european sense. Many famous Artists and Politicians of Greece, like El-Greco, Venizelos and Kornaros were born in Crete. TOPICS: 1. Power System Planning and Management --------------------------------------- Generation, transmission & distribution planning Reliability and security Dynamic transient stability and voltage stability Electromagnetic transient evaluations Insulation co-ordination Transmission & distribution equipment Protection Corporate planning and management Alternative energy systems Environmental issues Energy Management Systems 2.Deregulation and Electric Power Market --------------------------------------- Impacts of deregulation Electricity pricing and transactions Open access IPP and Co-generation Power market Reliability Optimization Techniques Electricity Demand Management Load Management FACTS and Custom Power Devices for Power Quality, Power Switching, Uninterrupted Power Supplies, Power Factor Compensation and Conditioning, Capacitor Switching Techniques 3. Electric machines -------------------- Applied Electromagnetics for Electric Machines Design Stability Problems Control Electronics for Electric Machinery Generalized Electric Machines Mathematical Problems, Simulation Computational Analysis of related problems Applications 4.Electric Vehicles ------------------- Modelling Design Generator Protection and Control Parallel Operation of Generators Energy Storage Batteries Portable Power Systems Energy Efficiency Energy and the Environment 5.High Voltage Engineering -------------------------- High-Voltage, Medium-Voltage and Low-Voltage Switchgear High Voltage Cables Power Line Communications Protection Systems, Grounding Systems Control Relays, Distance Protection in High Voltage Transmission High Voltage Measurement Problems of Applied Electromagnetics in HV Engineering Finite Elements and Modern Computational Techniques 6. Power System Operation and Control ------------------------------------ Load and energy forecast Economic operation Demand side management Reliability management Reactive power control Distribution automation SCADA/EMS and information systems Power quality Harmonics, Network Harmonics, Power Quality Measurement Inter-Harmonics, Power Flow Studies Plant and equipment operation, maintenance and condition monitoring Phase and Voltage Imbalances, Voltage Sag Analysis Voltage Disturbance Computations, Power Quality in Distribution, Power Quality Economics 7.Modern technology and computation techniques and applications --------------------------------------------------------------- Power electronics and drive FACTS Superconductivity Communication and Information Technology Artificial intelligence and Neural Networks Evolutionary computation Expert Systems Online Monitoring and Diagnosis, Case Studies in Power Quality Management, Power Quality Standards 8.Renewable Energy Sources and Technology ----------------------------------------- Power Generation Power Plants Distributed Generation, Co-generation Energy Conversion and Conservation Solar Power Photovoltaic Energy, Solar Panels Wind Energy, Ocean Energy Tidal Power Thermal Power Bio-energy Hydrogen Energy, Fuel Cells Hybrid Systems and Vehicles 9.Transmission and Distribution ------------------------------ Transmission Planning Transmission Protection High-Voltage Transmission HVDC Transmission Power Electronics Applications Transformers Motors and Drives Substation Distribution Automation Circuit Breakers SF6 Technology in Arc Quenching, CB Tripping Releases and Mechanisms 10.Electromagnetic Compatibility -------------------------------- Applied Electromagnetics Noise Analysis Experimentation Modern Computational Techniques 11. Modern Topics and Related Energy Problems --------------------------------------------- 12.Power Engineering Education ------------------------------ From owner-tcpsat@lerc.nasa.gov Tue Jan 23 13:10:14 2001 Received: from lombok-fi.lerc.nasa.gov ([139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19848; Tue, 23 Jan 2001 13:10:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA07838 for tcpsat-outgoing; Tue, 23 Jan 2001 12:34:00 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA06357; Tue, 23 Jan 2001 12:26:11 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id MAA02888; Tue, 23 Jan 2001 12:25:59 -0500 Received: from csunb0.leeds.ac.uk(129.11.144.2) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002851; Tue, 23 Jan 01 12:25:24 -0500 Received: from csun-gps.scs.leeds.ac.uk (csun-gps.leeds.ac.uk [129.11.144.4]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with ESMTP id RAA27098; Tue, 23 Jan 2001 17:05:22 GMT Received: from localhost by csun-gps.scs.leeds.ac.uk; Tue, 23 Jan 2001 17:05:20 GMT Date: Tue, 23 Jan 2001 17:05:20 +0000 (GMT) From: K Djemame X-Sender: karim@csun-gps To: Conference Announcement , amlist@takilab.k.dendai.ac.jp, announce@tcos.org, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, comswtc@comsoc.org, comswtc@ieee.org, conf@colmar.uha.fr, confs-conferencesa@comsoc.org, cost237-transport@comp.lancs.ac.uk, cost257@informatik.uni-wuerzburg.de, Cost264@lip6.fr, f-troup@CODEX.CIS.upenn.edu, fokus-user@fokus.gmd.de, giga@tele.pitt.edu, gu-net@gunet.gr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@listserv.utoronto.ca, info-confs@comsoc.org, ipgroup@sprintlabs.com, iscc2000@infres.enst.fr, itc@ieee.org, iwqos@comsoc.org, lists-mbone-eu-op-out@lists.ripe.net, Mail-distributor@KOM.th-darmstadt.de, mbone-eu-op@ripe.net, news-announce-conferences@uunet.uu.net, performance@haven.epm.ornl.gov, request-datacom@comsoc.org, reres@laas.fr, RHDM@lip6.fr, rm@mash.cs.berkeley.edu, seminar@cse.cuhk.edu.hk, tccc@ieee.org, tcgn@ieee.org, tci-announce@computer.org, tcp-impl@lerc.nasa.gov, tcpsat@lerc.nasa.gov, webrepl@cs.utk.edu, xtp-relay@cs.concordia.ca cc: karatza@csd.auth.gr, obaidat@monmouth.edu, franco@dist.unige.it Subject: Special Session in SPECTS'2001 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk *** We apologise in advance if you receive multiple copies *** Special Session on Modeling and Simulation-Based Multiprocessor Scheduling http://agent.csd.auth.gr/~karatza/msms01 2001 International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS 2001 http://www.scs.org/confernc/spects01/spects01cfp.html July 15-19, 2001 Orlando, Florida, USA Call for Papers --------------- Multiprocessor systems provide considerable computational power that can be used to solve problems with large memory and computational requirements. However, jobs are not always executed efficiently. Good scheduling policies can improve system performance, preserve individual application performance, and avoid unbounded delays. The availability of multiprocessor systems and wide diversity of hardware and software resources used in them makes the arbitration of requirements and management of resources difficult. Schedulers must determine where and when applications are to execute, i.e., on which processors and in what order. The most practical way to evaluate scheduling algorithms without constructing a full scale implementation is by using modeling and simulation. Simulation models can help determine performance bottlenecks inherent to the architecture and provide a basis for refining system configurations. Scope ----- This SPECTS 2001 Special Session is a forum to present the latest results of international researchers. The focus of this technical session is on Modeling and Simulation Methodologies applied to the Scheduling of Multiprocesssors. Topics of interest include, but are not limited to: . Scheduling of multiprogrammed parallel systems . Coshecduling of applications on multiple processors . Load-balancing and load-sharing . Scheduling of shared-memory/distributed shared-memory systems. . Scheduling of parallel applications within distributed systems (e.g. clusters) . Scheduling Methods for Networks of Workstations . Scheduling of heterogeneous processors Paper Submission ---------------- It is strongly recommended that papers be submitted by email to the session organizer Helen Karatza (karatza@csd.auth.gr) in postscript or PDF format. Do not submit papers that have been previously published or presented. All papers will be refereed for accuracy, technical content and relevance to multiprocessor scheduling. Submissions should not exceed 25 double-spaced, 8.5x11 inch pages (including figures, tables, and references) in 10-12 point font. Include five to ten keywords, complete postal and e-mail return addresses, as well as the fax and phone numbers of each author. Deadlines --------- Submission of Papers - February 28, 2001 Notification of Acceptance - April 22, 2000 Final Camera-Ready Submission - May 22, 2000 Session Organizer ----------------- Helen D. Karatza Department of Informatics Aristotle University of Thessaloniki 54006 Thessaloniki Greece E-mail: karatza@csd.auth.gr Fax: 30-31-996360 Phone: 30-31-997974 For additional information, please contact Dr. Helen Karatza (karatza@csd.auth.gr) at the Aristotle University of Thessaloniki, Thessaloniki, Greece. From owner-tcpsat@lerc.nasa.gov Mon Jan 29 19:37:36 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12639; Mon, 29 Jan 2001 19:37:36 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA14969 for tcpsat-outgoing; Mon, 29 Jan 2001 18:37:26 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA14950 for ; Mon, 29 Jan 2001 18:37:24 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id SAA12249; Mon, 29 Jan 2001 18:37:23 -0500 Received: from unknown(203.2.75.232) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012223; Mon, 29 Jan 01 18:37:12 -0500 Received: from telstra (ocmax10-231.dialup.optusnet.com.au [198.142.43.231]) by mail008.syd.optusnet.com.au (8.11.1/8.11.1) with SMTP id f0TNb4Y09785 for ; Tue, 30 Jan 2001 10:37:05 +1100 Received: by localhost with Microsoft MAPI; Tue, 30 Jan 2001 10:38:25 +1100 Message-ID: <01C08AA8.C6B28160.glentindall@dingoblue.net.au> From: Glen Tindall Reply-To: "glentindall@dingoblue.net.au" To: "tcpsat@grc.nasa.gov" Subject: Ka band equipment Date: Tue, 30 Jan 2001 10:38:18 +1100 Organization: Dark Sky Projects X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Sorry to drag everyone down to the physical layer for a moment, but I'm putting together a Ka-band earth station and I'm not finding much in the way of equipment. Does anyone have any ideas on where to find the following: 3.7m to 5.6m diameter antenna and feed for 20.2-21.2GHz Rx and 30.0-31.0GHz Tx. LNB for 20.2-21.2GHz. High Power Amplifier for 30.0-31.0GHz (between 40 and 100W). Frequency converters for L-band to Ka-band. Any help would be much appreciated. Glen Tindall Dark Sky Projects Melbourne, AUSTRALIA. g_tindall@southcom.com.au From owner-tcpsat@lerc.nasa.gov Tue Jan 30 02:32:12 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01757; Tue, 30 Jan 2001 02:32:11 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA07298 for tcpsat-outgoing; Tue, 30 Jan 2001 01:18:53 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA07012; Tue, 30 Jan 2001 01:12:29 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA08614; Tue, 30 Jan 2001 01:12:28 -0500 Received: from unknown(202.96.136.221) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008533; Tue, 30 Jan 01 01:11:29 -0500 Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm1e3a7662ac; Tue, 30 Jan 2001 06:11:01 -0000 Received: from cuse68.se.cuhk.edu.hk([137.189.59.68]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm193a7334be; Sat, 27 Jan 2001 16:04:03 -0000 Received: from cuse190.se.cuhk.edu.hk (localhost [127.0.0.1]) by cuse68.se.cuhk.edu.hk (8.11.2/8.11.2) with ESMTP id f0RAf1D15876; Sat, 27 Jan 2001 18:41:01 +0800 (HKT) Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190]) by cuse190.se.cuhk.edu.hk (8.10.1/8.10.1) with ESMTP id f0RAf0w20157; Sat, 27 Jan 2001 18:41:00 +0800 (HKT) Received: (from root@localhost) by cse.cuhk.edu.hk id f0R1tNC22002; Sat, 27 Jan 2001 09:55:23 +0800 (HKT) Received: from ada.cs.ucy.ac.cy (ada.cs.ucy.ac.cy [194.42.7.2]) by cse.cuhk.edu.hk with ESMTP id f0NCHZQ24016; Tue, 23 Jan 2001 20:17:38 +0800 (HKT) Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id NAA47704; Tue, 23 Jan 2001 13:50:43 +0200 Message-ID: <01c901c08532$8dd269d0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , , "comm-theory" , , , , "Conferencesa" , , , , , , , , , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , Cc: "Andreas Pitsillides" Subject: INFOCOM 2002 CALL FOR PAPERS Date: Tue, 23 Jan 2001 13:48:49 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01B4_01C08543.36C53210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Lines: 441 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit Please accept our sincere apologies for multiple copies INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002. For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =========================== David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; name="cfp2002.txt" Content-Disposition: attachment; filename="cfp2002.txt" Content-Transfer-Encoding: quoted-printable INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE =3D=3D=3D=3D=3D The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002.=20 For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =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 David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology = (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: application/pdf; name="cfp2002.pdf" Content-Disposition: attachment; filename="cfp2002.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAtMTAwIG51bGxd Cj4+CmVuZG9iagozIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjEyIG51bGxdCj4+CmVu ZG9iago0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgLTcwIG51bGxdCj4+CmVuZG9iago1 IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvSW0xCi9XaWR0 aCAzMDkKL0hlaWdodCAyNTcKL0JpdHNQZXJDb21wb25lbnQgMQovQ29sb3JTcGFjZSAvRGV2aWNl R3JheQovTGVuZ3RoIDU4NgovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwK L0sgLTEgL0NvbHVtbnMgMzA5Pj4KPj4Kc3RyZWFtDQr///5kDCEfmSAapl4bUycCSCIFe0oEDgg4 IgeCbUwg4QOCDhBwiGuOYuUOHBAiKA0UQ1CoOEQ0jBB+DhEM0cobQMOEEKg3QQUMHCBKD0CTDdJQ YdBbDhAgoboJQ3CCVuglDcJKG6CVh0goN0EFbpBW6CUN0gt0lbpAkG6RFwVW6QV6CI0BOGHSCb0k m9bdJO6VN6t6W3p26u+g90iShtt0gd6Tt6fq7eqelbdVvSb1TukQMDwd+SYHg13SCIHgyDfgiB4F CR6CB9IINvhBvSCB/Tb4QfpN6p3pP6IKVA3qgTINnv6VBt6SBNBu+lgw/oKn6SW3frbfpbf0Fh/r 3eq36pbb9Le9e39Lute7fS/9bfX7+u/69/9/97/9Vr+/99f///2//////X////1+//uv+n/bpJf3 9v6/b/71Xvr++vv1V29f+l7bX+3pV4eq3d0vbel9vX2w9Je2qXdg8JV4eFXbBhMJVdgwmEvhiK7b CS218NVdpdhhdwwl2GElwYXcGvYMgeCmrVsigHg21yq5cDwXW2TIFZdhgqu0lbpd9X1t9bTW+lb0 tp9tUt2sOmltVsNOrYTCXTSsNBpWwmtsJoK2EGtsEGgrDCIHg6tW00rdpQ2qVh2lYeErettsIKGH QSsORML8pznpWGd+jYdAiOrBndeCjDYhKwztOCiwYShsIKwwlDBglDIZq0FDBlSBohhksBqhkGsb ChkNccqsKGIhQwUMKDCgwUGQPW1kGFMoA3mUwVZloGlMi+R2RwsRH////+ACACAKZW5kc3RyZWFt CmVuZG9iago2IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTcwIG51bGxdCj4+CmVuZG9i ago3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTkwIG51bGxdCj4+CmVuZG9iago4IDAg b2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjIyIG51bGxdCj4+CmVuZG9iago5IDAgb2JqCjw8 Ci9EIFsxIDAgUiAvWFlaIG51bGwgMTg4IG51bGxdCj4+CmVuZG9iagoxMCAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIDI1MiBudWxsXQo+PgplbmRvYmoKMTEgMCBvYmoKPDwKL0QgWzEgMCBS IC9YWVogbnVsbCAzNTEgbnVsbF0KPj4KZW5kb2JqCjEyIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFla IG51bGwgMzY3IG51bGxdCj4+CmVuZG9iagoxMyAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxs IDM4MSBudWxsXQo+PgplbmRvYmoKMTQgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAzOTQg bnVsbF0KPj4KZW5kb2JqCjE1IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDQxIG51bGxd Cj4+CmVuZG9iagoxNiAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1OCBudWxsXQo+Pgpl bmRvYmoKMTcgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NzIgbnVsbF0KPj4KZW5kb2Jq CjE4IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDg2IG51bGxdCj4+CmVuZG9iagoxOSAw IG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDE4MSBudWxsXQo+PgplbmRvYmoKMjAgMCBvYmoK PDwKL0QgWzEgMCBSIC9YWVogbnVsbCAyMDkgbnVsbF0KPj4KZW5kb2JqCjIxIDAgb2JqCjw8Ci9E IFsxIDAgUiAvWFlaIG51bGwgMzM0IG51bGxdCj4+CmVuZG9iagoyMiAwIG9iago8PAovRCBbMSAw IFIgL1hZWiBudWxsIDM3NSBudWxsXQo+PgplbmRvYmoKMjMgMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCAzODggbnVsbF0KPj4KZW5kb2JqCjI0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51 bGwgNDAxIG51bGxdCj4+CmVuZG9iagoyNSAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQx MyBudWxsXQo+PgplbmRvYmoKMjYgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0MjYgbnVs bF0KPj4KZW5kb2JqCjI3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDM5IG51bGxdCj4+ CmVuZG9iagoyOCAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1MSBudWxsXQo+PgplbmRv YmoKMjkgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NjQgbnVsbF0KPj4KZW5kb2JqCjMw IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDc3IG51bGxdCj4+CmVuZG9iagozMSAwIG9i ago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ5MCBudWxsXQo+PgplbmRvYmoKMzIgMCBvYmoKPDwK L0QgWzEgMCBSIC9YWVogbnVsbCA1MDIgbnVsbF0KPj4KZW5kb2JqCjMzIDAgb2JqCjw8Ci9EIFsx IDAgUiAvWFlaIG51bGwgNTE1IG51bGxdCj4+CmVuZG9iagozNCAwIG9iago8PAovRCBbMSAwIFIg L1hZWiBudWxsIDUyOCBudWxsXQo+PgplbmRvYmoKMzUgMCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAo RDoxOTEwMDExMDYxMjA3MDMpCi9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgQ29tbWFuZCAz LjAxIGZvciBTb2xhcmlzIDIuMyBhbmQgbGF0ZXIgXChTUEFSQ1wpKQovVGl0bGUgKGNzLmVwcykK L0NyZWF0b3IgKEZyYW1lTWFrZXIgeG01LjVQNGYpCj4+CmVuZG9iagozNiAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIG51bGwgbnVsbF0KPj4KZW5kb2JqCjM3IDAgb2JqCjw8Ci9EIFsxIDAg UiAvWFlaIG51bGwgbnVsbCBudWxsXQo+PgplbmRvYmoKMzggMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCBudWxsIG51bGxdCj4+CmVuZG9iagozOSAwIG9iago8PAovTGVuZ3RoIDQ4MTUKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiYxX23LbOBJ911fgaYtKWTSuBJm3xHG8zubi iVWzteXMg0zDMhOJ9FJSXNmv39MAQYn0ZTKpGuq4ge6D7kZ3Q7Dl5PjsUrDlZiJYxSaccZYJyWwh WesmtxNhmbWSGZuxmTWZ/+Oric45/sxTDalOuWazTBAI0v9O8EfBDQvaSOA38IKV68nx+Vqwd83k j8nb+eT4vWSCzW8nOvOr8REmxUKrbMpzNl+D0nIy4ynP2LwEmD9MrpKTNx8/Mvb+y1fGLqZWJ28u Tr9eTv+af4BCHRTiEKQQH4XjiCKogork8r6pN03rbtj1r+n8O7ZkYYtJjcwVNs3fwcZrxtj8zrHz erOttrutY80tO125cttW5WLFFvVNB6c6S5q6Ktlpvaxq59qp4MnmCDvLlH1Lzk9PT79Njzw9kXJj 2EykIsss2fFSdtKs72GhZZdNWbntL/YPFv++3kHzYluBc5QS6dM5TnM2kewD+H5nkoLwwFSaZ+wT u/qLs5uJNgW50CoJa2wNrNMs857NcjZCukiFRjCxlpUTrVWawW06S41gzyBLn4O1eYpEGaOg1ij6 lD0FY1O4YYwC3Uyl3NJa/NBIhCxPTcHGSNOnQ7TWpHYvPATIUiEOtCI1jeptDlGONDMHbHNkhO3P 8jSKXog4+GiEgt7o3M5o5/kRCnRDzPqDySzNNBsBOC+CvbeicIAGiVBOrl/hstO/dtn9+HqGbPrA BC17YFAmQmBEKq3PnJwSyxpOf9bkLXBEbBXlUZ4q5d0SGMMYftDRC8VIUxEQVNMBhImISGNvj7UV IQfDTqDCHui1Ms17oxBq0xOCmkg3qg1QFV5IoQAyASgPMtMpVV5NUfhISL03ocI5bJrrbikPIVVe jyRg6EOhIP8CqaJzQV54TGmNHPDbKGuMIUt0KOUXmlSHQ+W59ysJibftPQeUh0wQIQaeOiGbe6QD 2sfLB5gKA/YUVBdshvxTFEe6NtZfBsNGAHkXFwZiGTkmCzdziKQPIj4hiDhM1t0Eqg4D1K3V/f0P mpRfNEKBgkKKhCsd6CkcVLAxCufq1yJWlJHK58EYZcHl/aVG28p6gkPUre2P1mnqDj5EA9+Wk42/ goUK5cN4b6vgKP9Z+RORa3BhitzjLJXqUG5CUo+w8mmx8vryYo/Raak3GmQvpYLkpF1BJ5tpStXQ jHsxaofuxJ7nUKw4peDzYtxQ+bxYU0N7QUx35lkp5fALzMjdLzCji/ACM/g4f45Z5kcbyJBEj4QI DCYRnR3IdScX5PVChLQStHQ9MTlVrdy3Ha4lwmOQLjmnS4UsLwQzCD/VDGp6KFMRBgXlJGKJUqto 4Op2CwuiBev1EylByXkboo9OI4OLTeZ5GF8mAqZd2uyRpVztEExGrGhRjzjV5IiQbNL4tZkv8wGT FeryEek0D4mqtF8rKcPpAmKLyVG4rNcrjEdFN2iIbi0dU2tqkSZXqZS+clrrrXC950uhyVCwM+9E TKhS063FcFjEwTTKUVGtOZCbsVyTl56XUwV/SY5gFeYF+wr2XxLDvHhBLgtK3hfkXvI8PTGin/WZ 27V9Y4vQlyX1Okvl4nAdR0tY+gETRcVPBIgI93M0+V3R75ngaXglvH0VZk3ts1WHUbP7vep+G4rr ar9ujBX1PMKK6tBjLOgSHqwfYR4AJ7cOARhnQVPuTxzxNb1ihJ/LImlU/+7Ged4RRqpx9RhHqtYM qUccqcb1IxzY0nQjR6CnnvNH1C0fUEeNOaQeYaQaV49xpIp0HlCPOFKN60c4sKXBRIxATz0rxtT9 qy8PLy4ZHmmSrjKKB86cE4Pu1XeVnNe3U2mSpl37FxBr6u6RJ3hQgMrAUTX9ky15HV5zQoxfgCIM 15ivvO5k1y3slFCnsKZTwi531+tqsyFzFZ5+7a70j6+RblwZHt+KY33wkpAmviMv2mbZLtb+vdi6 qTDJsoJaf6B4mk7rTCBHSS0eiAr//Z3y5GPjX6Jtu6iXbu3q7Zgm5v9c/RbNy+3uBgo8TbCbSp78 JLJuxUCfNAeuXeQwS3nnagRP0DxE8wU59yq5227vXx8fPzw8TC1P0so5N6u6QJbNOm3aqeDJ8lhy Lr1SjA5eF3ot8oQebbjV6Hle22V55252K8e+JfBaVW5Xv5gjbTohRXlSuptRUiBNlda6O/W3KR17 nwwKjYhsoAWgVHob73erFbtf3LuW3ezcdJZj1Es+7GBJiSMGnsJb4BQXkSGRvcc+N9vqm1JZ2eXm LVuUpbvfLuoSOoSUOZaQC4Mf19dQL/SBvvkrsl3VCCGW6MS1Pus8BZ3bPHnnyrBN8oNt+xiM/aYK 0/vtpKlvnXeQAx8W3Th21dgtCrUmumU+1TrZbZu2Wqw201khcg2v1I5JNZPhIHJ/kGDQ+cPnQstu qZlJe7D0dI4mdDZR1FQUsgdVlklL3UT55nM5OT65FOzkknF6THGaEsAwRXU5vhDs8uTzM9u8VsPh CoWUNGxm5e/qe2rXYZU68DOGUSiQhaXJxjvprFourqst++y2D5TXTfujqpfs31NLdevH5q65f97n 6MKYmCQqJpWl85qVTf19V/uKwx6q7R1DBaRLExyIPMaYlIUCERMxhuSoXyOofXsT9EP5sifRhce3 MzNJCt2bpvR30uJObstlfVz2kTxeXtePQodKKvFukfAHAv27Tn5q19NO1pKqH06T0VvPk/5y7+o3 4bbf7XPpSZcWkkYfUXAabH7XqxiAOUX/kVfzmSz2joXcSGuGZWDk0AZUF215l4bqtBxe2ZnC467I KB7gZ7ylM1e7FjXg5G5Rtb6HqaGFC8qrxZQnvnD+rP7H/kXF1KEr1lWnX8d+mIvYHI7Y+dtPoeRH 64UXD5T/OVU2qUo38+Y3r72+EYH3oY7csLeLHWpKIZOjoVkchuORFux+bn5Ui6HdTv7EqaikVwv2 qWmDjcXKjXTnqeg7LbUpF8ppvUEUN9uU6u6cKDk4qJwKkdzVzapZ/ho5nmYXno8OFjaWd3VFffQC FIokdOuT5iWHvFtQAH5WN+yjG/PF6KSiL66Stw6t5ePiesO+uo1DYtCp7xBrlP0Rw27jwNCbtnKr 6Yx6yZf2ZvHI7aLv3ziKij6AhZqmC79vFj7nm3YRVXnHhZ/Nbfj+jgvzdJg8CAamBap2J816XW23 zj2fxP9chOyl/7lf7L0vOM4hhYdnwotS9AlcfVpsfiCP63KQT3h86ZjlaTfUqK4SGHoNoaBTIQLA HRMYKlFxjBapVmG25OEVdJV8mEqRxJZ22KcOZigVNGKPooes4hhOzIG6hF39LQclPdhvukrQMaYi Sx7Yf+ASQb2CnVTb/7NeNc1t40j0rl+BU0pKjRUCIEBybxOvM5WpymR2rKo9ZPcgU7TDXUl0UVRS /vf7XoOSaAramrFTPliP3Wh0N/rzaVzZxrfbeQY56PdJfpqTF18rJEGeTL9jhHu64lTS7jr183a7 R1z/2tQY7E79mSnT4cTHm5sbPt3jvsOMwcGP77hnMsjIq26bsq66ugqzH2beop/6MoSq0lhgMpWy 4OYjtw5roj+NgIfxzzwb/9BXZFVLOPrLTvnHLxPsGT4v2EFclqorkzj+PnZ6jQZRZGygaNnF/M+2 +vix0e2wwKWGC4PPRIPNxKGHoj8ITtUYFQeEwaScOKxAxgs2oI6Qmess8FrhtbxAJBk1Rimf3nMl 8sLruRX6jO18BAquYx4LK1YocGa4k9pDgFVjZOYF77BzJ9riM7qsx2e03jHy85SXJAe5OdX2Pp+n uPUMYXZCuvMy8hY85KGnvOEY0WMwNzM9L70CV1mnxigXLwAlea+D3JPQ/nOUC0hsz4qM8S64foSC Ck7uCip4E7BWEQSXORjqet6MkjJJxecoR3/nyZSGgjf39I53yRyXjgGlpgXTJ3Ai+IhpdhzBhGLI m/N9zpHXgoIXcokKn2Zzb9UYOYon0sKacmjyqZ+jD52j5IjIK4XoSI0iKX0DXseAGaP+lnRusl6H ghgjmVZj5CSSkZxZkOvmLhPMqDpHAJqPE1gZyqH+jlF/idSBoIKzgnUw/DmiurZgVAZeTLXEmVHn CFlEpIuely60+RxNcYyQj15QkvUuQ23xNpunwaFDZCT3rWeZI6/h5uYtHlNdAokeckqWj1F/B8zV vQZpoNpAjSBLAQNemb3PEV6WKB0aptlMxsgww4h8UEEzgIgNzX6GUPlYK23SPwRKFgMb2Bs1RmDS gnSopIUoaIq+eA4AXgO/UXPkFVDNWA6BUSzOEQu78f2L9RUZjb5Qz8DTiIZsszoAr75NsFEw7rxJ mbARVBx4S+Et/EFQDDiE9JCz7yUjJLVBkOQysNahKzk1Qs86YTm5fzvhXCR9nh1K6jgCCNvd3Ml0 iFRCVwUfPURBzjO0DTPuOTml56RKpJHTzolw3A8PxMnh2ZCdEbJhmWfGIPjip1OpxEXsbpbdTJyZ iHB/RmYdgmFZVLWcCc9+UVzQHNnoOQroEzkbnk6lBcftNkJG1A41zwaqMZrhehfV3EuGORkYInaH XHWo0DGn4rTUX8esOgrPBqe1FEqr41ebUF+iXullczy58J5hFioOeov7DoeTuTt2wKhZDEQEXO5j ZGgcilAecwquZtdGouv0eDdM6ckMMbE6ieWADTlgpI9HyMgBH+pflNx3dsdHjZBlE5EU0XGzkzC+ JUUkVKh4IWSdXyCLz3wszOAyK1OktjGyDSOx45Rx0eFhYj5/TbQV9uOQfY61ZexSGd0w5/gYORXh nN0MyRmFu4HLkDd91Q7UyGEozkYbIzMUYHYae2xW2VzCkEPbQbOjV9g4iqC4iSjO0/awGwSyYS8+ 3K3F5dTcRNKLnSKXgmcvkCmc+a+PLj8JJzmTsdXTMAymZ3eH0Soahpq7BEf0Io9czcNhM/CxKOVp HaaQg09TmjKwKw1xGMvd3uxh2Ug5HQZyZLMzWvord6Vcyb51ZTkF9vJ0EVpjHmzxIzLaMk1FAGSR w5Cdecko/IuQU2nmmDGMvnCaVcqxBkdPk4wXtBfIXFlQaOAuy5XxCo11dDWWFJ3GrJaIZc5wRWKL GGtGJyM6EL/hdM4ifzjt6HEKN1GX5uE0hNg4uV8dkNURu4zstlZGlqjTfJg1s4NPZcMZCMfdiBId vdscXiTqU54OHc1f8BrttjLaRIWz1CDSnKiWj8gupHvCf5HTLsS9Y9Zc1Jxei92dFDIrc46Jap5I Z3DpyWvj0yEHYpolPnjFXjjsJQkw3mRFnJyH9Ps/D2IkEKNO4dXYZ1zMrCST5MVrc8hhW3tOtmGB kIn2+CBmQM6Cz0wse6Ea90AEIkJJYmxIfr+YvPsAglaL+wkaAIpVgr9M6qpxMukacdxiM5l+vLm5 mS3+M0llhTsxalRYJiI4fc9JNid9nmw6SZgmup9fT3zbqLhCU5EB24fP15+jEq2RQBuwbmISbeHm OhuymSQx5ESFQVUjJ/YR5BzKOoZgVxScucD4Zbr4WqnrZns/K6ZVW23LSjVbfNg87ruq5Y/NTPvp fluXy65utrvZvxe/Tm4Wp31Dq18muNyi8lhYf2WM1Pn3byfvrm+1ur5lqYe2HCWgCF/w3e9a3V7/ Fjt2279ZEt4Mw4K4w/C10OSttlwaoXmiHqD957Z+qLfLtXpcPlbtTi3bStXbWaqn3+quWtGWtiqr baeWq28z46ZLWLgDiyp7E8WehO1Loxmqxd8hFbTNwGLoZnBwFX5sq+77TCfTpv1vvX2Yh4+LWY4v j3XZczf34X+9xRXVriOyQOV6v6p+CrS7mUmm+1ky7USHxVvcTP23TafW9Ub075qfVIcXum/W62Zm /PQ77vyb8MNJuncSOlsfNfOsd5RB78V7MxZaBsLApcjGLAW3mPq+bZarOxin3qifZ1rTlGT6aXwD B5+sCIdiAv1R4G8n96jHti6h70jYlcZ04LUMcTpHn7gg86DkFOH5AB/iLaDkcrWpdzv+Lptt1zbr /uBrNW26pmzWu1fq+mX6oX+no3o/xJO7p11XbdSuuQ/fECev1vQjYzNEs+6jGf79+PvLNf782CFp 1mqQIq936Kfmrl5X0Ox73VbrardTA53H4v+0stN/7JfruntSzb3aVe23uqyeB9JfjtJP+zWtR66/ LCCnfzT7jtnyA9TYVKt6+VI9bsuv1Wq/frUqhwiWh1LLx8f1oaLiMXufv/j9vkxvq3Lf8gXfsM6w tocCj/JVzrSbPr068p6p35ZfUZHLbt++SumuaZcPFfvU8semyVDZVbWrH1gsH9fL7fa8Av+FWPhe dwgHeTH5+YOjYrPcwh0bNug3L6mYaHguLw6S1WJm3bRd3jMQ/mWtL1W1xXxQVW28Dbk81S9TXG2q 5Q6xQNXpnQ4N6q5avSI0/skRorpT5TJ4+UcGxKZZVetXxMFJO0xZ90274Rh1mAT/J8AAHQJaSQpl bmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIg XQovRm9udCA8PAovRjIgNDEgMCBSCi9GNCA0MiAwIFIKL0Y2IDQzIDAgUgovRjggNDQgMCBSCi9G MTAgNDUgMCBSCi9GMTEgNDYgMCBSCi9GMTMgNDcgMCBSCj4+Ci9YT2JqZWN0IDw8Ci9JbTEgNSAw IFIKPj4KL1BhdHRlcm4gPDwKL1AxIDQ4IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNDkgMCBS Cj4+Ci9Db2xvclNwYWNlIDw8Ci9DUzEgNTAgMCBSCj4+Cj4+CmVuZG9iago1MCAwIG9iagpbL1Bh dHRlcm4gL0RldmljZUNNWUsgXQplbmRvYmoKNTIgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+ PgplbmRvYmoKNDggMCBvYmoKPDwKL1R5cGUgL1BhdHRlcm4KL1BhdHRlcm5UeXBlIDEKL1Jlc291 cmNlcyA1MiAwIFIKL01hdHJpeCBbMC45IDAgMCAwLjkgMCAwXQovUGFpbnRUeXBlIDIKL1RpbGlu Z1R5cGUgMwovQkJveCBbMCAwIDggOF0KL1hTdGVwIDgKL1lTdGVwIDgKL0xlbmd0aCA4OQovRmls dGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJFMgxDkBAFIThfk7xX4Ds8iL2ChKFKBSioyBL QuP6nswU882tyI4CgdbzbJq4VNH5cVDzUpdtQ8+8BFYVEe+pRCLLKMwRK8zl+5fhzho16BNgAHLx ElcKZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago8PAovVHlwZSAvSGFsZnRvbmUKL0hhbGZ0b25l VHlwZSAxCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpCi9GcmVxdWVuY3kgNjAKL0FuZ2xlIDQ1Ci9T cG90RnVuY3Rpb24gL1JvdW5kCj4+CmVuZG9iago0OSAwIG9iago8PAovVHlwZSAvRXh0R1N0YXRl Ci9TQSBmYWxzZQovT1AgZmFsc2UKL0hUIC9EZWZhdWx0Cj4+CmVuZG9iago1NCAwIG9iago8PAov VHlwZSAvRm9udERlc2NyaXB0b3IKL0FzY2VudCA3MTIKL0NhcEhlaWdodCA3MTIKL0Rlc2NlbnQg LTIzMgovRmxhZ3MgMjYyMTc4Ci9Gb250QkJveCBbLTE1MiAtMjY2IDEwMDAgOTI0XQovRm9udE5h bWUgL1BhbGF0aW5vLUJvbGQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyMgovWEhlaWdodCA0NzIK Pj4KZW5kb2JqCjQxIDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAv RjIKL0ZpcnN0Q2hhciAzMgovTGFzdENoYXIgMjU1Ci9XaWR0aHMgWzI1MCAyNzggNDAyIDUwMCA1 MDAgODg5IDgzMyAyMjcgMzMzIDMzMyA0NDQgNjA2IDI1MCAzMzMgMjUwIDI5NiAKNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI1MCAyNTAgNjA2IDYwNiA2MDYgNDQ0IAo3 NDcgNzc4IDY2NyA3MjIgODMzIDYxMSA1NTYgODMzIDgzMyAzODkgMzg5IDc3OCA2MTEgMTAwMCA4 MzMgODMzIAo2MTEgODMzIDcyMiA2MTEgNjY3IDc3OCA3NzggMTAwMCA2NjcgNjY3IDY2NyAzMzMg NjA2IDMzMyA2MDYgNTAwIAozMzMgNTAwIDYxMSA0NDQgNjExIDUwMCAzODkgNTU2IDYxMSAzMzMg MzMzIDYxMSAzMzMgODg5IDYxMSA1NTYgCjYxMSA2MTEgMzg5IDQ0NCAzMzMgNjExIDU1NiA4MzMg NTAwIDU1NiA1MDAgMzEwIDYwNiAzMTAgNjA2IDI1MCAKNzc4IDc3OCA3MjIgNjExIDgzMyA4MzMg Nzc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDQ0NCA1MDAgNTAwIAo1MDAgNTAwIDMzMyAzMzMg MzMzIDMzMyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA2MTEgNjExIDYxMSA2MTEgCjUwMCAyNTAg NTAwIDUwMCA1MDAgNjA2IDY0MSA2MTEgNzQ3IDc0NyA5OTggMzMzIDMzMyAyNTAgMTAwMCA4MzMg CjI1MCAyNTAgMjUwIDI1MCA1MDAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgNDM4IDQ4OCAyNTAg Nzc4IDU1NiAKNDQ0IDI3OCA2MDYgMjUwIDUwMCAyNTAgMjUwIDUwMCA1MDAgMTAwMCAyNTAgNzc4 IDc3OCA4MzMgMTAwMCA4MzMgCjUwMCAxMDAwIDUwMCA1MDAgMjc4IDI3OCAyNTAgMjUwIDU1NiA2 NjcgMTY3IDUwMCAzODkgMzg5IDYxMSA2MTEgCjUwMCAyNTAgMzMzIDUwMCAxMDAwIDc3OCA2MTEg Nzc4IDYxMSA2MTEgMzg5IDM4OSAzODkgMzg5IDgzMyA4MzMgCjI1MCA4MzMgNzc4IDc3OCA3Nzgg MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAKXQovRW5jb2Rpbmcg NTUgMCBSCi9CYXNlRm9udCAvUGFsYXRpbm8tQm9sZAovRm9udERlc2NyaXB0b3IgNTQgMCBSCj4+ CmVuZG9iago0MiAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y0 Ci9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1Cb2xkSXRhbGljCj4+CmVuZG9iago0 MyAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y2Ci9FbmNvZGlu ZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1JdGFsaWMKPj4KZW5kb2JqCjQ0IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjgKL0VuY29kaW5nIDU1IDAgUgovQmFz ZUZvbnQgL1RpbWVzLUJvbGQKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMQovTmFtZSAvRjEwCi9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1S b21hbgo+PgplbmRvYmoKNDYgMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9O YW1lIC9GMTEKL0Jhc2VGb250IC9aYXBmRGluZ2JhdHMKPj4KZW5kb2JqCjQ3IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjEzCi9FbmNvZGluZyA1NSAwIFIKL0Jh c2VGb250IC9IZWx2ZXRpY2EtQm9sZAo+PgplbmRvYmoKNTUgMCBvYmoKPDwKL1R5cGUgL0VuY29k aW5nCi9EaWZmZXJlbmNlcyBbIDM5L3F1b3Rlc2luZ2xlIDk2L2dyYXZlIDEyOC9BZGllcmVzaXMv QXJpbmcvQ2NlZGlsbGEvRWFjdXRlL050aWxkZS9PZGllcmVzaXMKL1VkaWVyZXNpcy9hYWN1dGUv YWdyYXZlL2FjaXJjdW1mbGV4L2FkaWVyZXNpcy9hdGlsZGUvYXJpbmcvY2NlZGlsbGEKL2VhY3V0 ZS9lZ3JhdmUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lhY3V0ZS9pZ3JhdmUvaWNpcmN1bWZsZXgv aWRpZXJlc2lzCi9udGlsZGUvb2FjdXRlL29ncmF2ZS9vY2lyY3VtZmxleC9vZGllcmVzaXMvb3Rp bGRlL3VhY3V0ZS91Z3JhdmUKL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy9kYWdnZXIvLm5vdGRlZiAx NjQvc2VjdGlvbi9idWxsZXQvcGFyYWdyYXBoL2dlcm1hbmRibHMKL3JlZ2lzdGVyZWQvY29weXJp Z2h0L3RyYWRlbWFyay9hY3V0ZS9kaWVyZXNpcy8ubm90ZGVmL0FFL09zbGFzaAogMTc3Ly5ub3Rk ZWYvLm5vdGRlZi8ubm90ZGVmL3llbiAxODIvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRl ZgovLm5vdGRlZi9vcmRmZW1pbmluZS9vcmRtYXNjdWxpbmUvLm5vdGRlZi9hZS9vc2xhc2gvcXVl c3Rpb25kb3duL2V4Y2xhbWRvd24KL2xvZ2ljYWxub3QvLm5vdGRlZi9mbG9yaW4vLm5vdGRlZi8u bm90ZGVmL2d1aWxsZW1vdGxlZnQvZ3VpbGxlbW90cmlnaHQvZWxsaXBzaXMKLy5ub3RkZWYvQWdy YXZlL0F0aWxkZS9PdGlsZGUvT0Uvb2UvZW5kYXNoL2VtZGFzaAovcXVvdGVkYmxsZWZ0L3F1b3Rl ZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQgMjE2L3lkaWVyZXNpcy9ZZGllcmVzaXMvZnJh Y3Rpb24vY3VycmVuY3kKL2d1aWxzaW5nbGxlZnQvZ3VpbHNpbmdscmlnaHQvZmkvZmwvZGFnZ2Vy ZGJsL3BlcmlvZGNlbnRlcmVkL3F1b3Rlc2luZ2xiYXNlL3F1b3RlZGJsYmFzZQovcGVydGhvdXNh bmQvQWNpcmN1bWZsZXgvRWNpcmN1bWZsZXgvQWFjdXRlL0VkaWVyZXNpcy9FZ3JhdmUvSWFjdXRl L0ljaXJjdW1mbGV4Ci9JZGllcmVzaXMvSWdyYXZlL09hY3V0ZS9PY2lyY3VtZmxleCAyNDEvT2dy YXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZ3JhdmUKIDI0Ni9jaXJjdW1mbGV4L3RpbGRlL21hY3Jv bi9icmV2ZS9kb3RhY2NlbnQvcmluZy9jZWRpbGxhL2h1bmdhcnVtbGF1dAovb2dvbmVrL2Nhcm9u Cl0KPj4KZW5kb2JqCjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA1MSAwIFIKL1Jlc291 cmNlcyA0MCAwIFIKL0NvbnRlbnRzIDM5IDAgUgovQ3JvcEJveCBbMCAwIDYxMiA3OTJdCj4+CmVu ZG9iago1MSAwIG9iago8PAovVHlwZSAvUGFnZXMKL0tpZHMgWzEgMCBSXQovQ291bnQgMQovTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQo+PgplbmRvYmoKNTYgMCBvYmoKPDwKL05hbWVzIFsoRikgMzcg MCBSIChHOTk2NzM1KSAzIDAgUiAoRzk5NjczOCkgMiAwIFIgKEc5OTc4MDYpIDQgMCBSIChHOTk3 ODA5KSA4IDAgUiAoRzk5NzgxMikgOSAwIFIgKEc5OTc4MTQpIDEwIDAgUiAoRzk5NzgxNSkgMTEg MCBSCihHOTk3ODE2KSAxMiAwIFIgKEc5OTc4MTcpIDEzIDAgUiAoRzk5NzgxOCkgMTQgMCBSIChH OTk3ODE5KSAxNSAwIFIgKEc5OTc4MjApIDE2IDAgUiAoRzk5NzgyMSkgMTcgMCBSIChHOTk3ODIy KSAxOCAwIFIgKEc5OTc4MjMpIDE5IDAgUgooRzk5ODAzOCkgNiAwIFIgKEc5OTgwMzkpIDcgMCBS IChHOTk4NTM1KSAyMSAwIFIgKEc5OTg4MzgpIDI2IDAgUiAoRzk5ODgzOSkgMjcgMCBSIChHOTk5 MDg3KSAyMCAwIFIgKEc5OTkxNTMpIDMwIDAgUiAoRzk5OTE1NCkgMzIgMCBSCihHOTk5MTU1KSAz MyAwIFIgKEc5OTkxNTgpIDI5IDAgUiAoRzk5OTE2NCkgMjggMCBSIChHOTk5MTg1KSAyMiAwIFIg KEc5OTkzODQpIDI1IDAgUiAoRzk5OTM4OSkgMjQgMCBSIChHOTk5NDE0KSAzMSAwIFIgKEc5OTk0 NzgpIDM0IDAgUgooRzk5OTQ5NCkgMjMgMCBSIChMKSAzOCAwIFIgKFAuMSkgMzYgMCBSXQo+Pgpl bmRvYmoKNTcgMCBvYmoKPDwKL0Rlc3RzIDU2IDAgUgo+PgplbmRvYmoKNTggMCBvYmoKPDwKL1R5 cGUgL0NhdGFsb2cKL1BhZ2VzIDUxIDAgUgovTmFtZXMgNTcgMCBSCj4+CmVuZG9iagp4cmVmCjAg NTkKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDExNTg0IDAwMDAwIG4gCjAwMDAwMDAwMTYgMDAw MDAgbiAKMDAwMDAwMDA2OCAwMDAwMCBuIAowMDAwMDAwMTE5IDAwMDAwIG4gCjAwMDAwMDAxNzAg MDAwMDAgbiAKMDAwMDAwMDk3NyAwMDAwMCBuIAowMDAwMDAxMDI4IDAwMDAwIG4gCjAwMDAwMDEw NzkgMDAwMDAgbiAKMDAwMDAwMTEzMCAwMDAwMCBuIAowMDAwMDAxMTgxIDAwMDAwIG4gCjAwMDAw MDEyMzMgMDAwMDAgbiAKMDAwMDAwMTI4NSAwMDAwMCBuIAowMDAwMDAxMzM3IDAwMDAwIG4gCjAw MDAwMDEzODkgMDAwMDAgbiAKMDAwMDAwMTQ0MSAwMDAwMCBuIAowMDAwMDAxNDkzIDAwMDAwIG4g CjAwMDAwMDE1NDUgMDAwMDAgbiAKMDAwMDAwMTU5NyAwMDAwMCBuIAowMDAwMDAxNjQ5IDAwMDAw IG4gCjAwMDAwMDE3MDEgMDAwMDAgbiAKMDAwMDAwMTc1MyAwMDAwMCBuIAowMDAwMDAxODA1IDAw MDAwIG4gCjAwMDAwMDE4NTcgMDAwMDAgbiAKMDAwMDAwMTkwOSAwMDAwMCBuIAowMDAwMDAxOTYx IDAwMDAwIG4gCjAwMDAwMDIwMTMgMDAwMDAgbiAKMDAwMDAwMjA2NSAwMDAwMCBuIAowMDAwMDAy MTE3IDAwMDAwIG4gCjAwMDAwMDIxNjkgMDAwMDAgbiAKMDAwMDAwMjIyMSAwMDAwMCBuIAowMDAw MDAyMjczIDAwMDAwIG4gCjAwMDAwMDIzMjUgMDAwMDAgbiAKMDAwMDAwMjM3NyAwMDAwMCBuIAow MDAwMDAyNDI5IDAwMDAwIG4gCjAwMDAwMDI0ODEgMDAwMDAgbiAKMDAwMDAwMjY2MyAwMDAwMCBu IAowMDAwMDAyNzE2IDAwMDAwIG4gCjAwMDAwMDI3NjkgMDAwMDAgbiAKMDAwMDAwMjgyMiAwMDAw MCBuIAowMDAwMDA3NzExIDAwMDAwIG4gCjAwMDAwMDg3MzEgMDAwMDAgbiAKMDAwMDAwOTgxMiAw MDAwMCBuIAowMDAwMDA5OTE3IDAwMDAwIG4gCjAwMDAwMTAwMTggMDAwMDAgbiAKMDAwMDAxMDEx NyAwMDAwMCBuIAowMDAwMDEwMjE4IDAwMDAwIG4gCjAwMDAwMTAzMDMgMDAwMDAgbiAKMDAwMDAw ODA0NiAwMDAwMCBuIAowMDAwMDA4NDY1IDAwMDAwIG4gCjAwMDAwMDc5NjcgMDAwMDAgbiAKMDAw MDAxMTY5MCAwMDAwMCBuIAowMDAwMDA4MDA3IDAwMDAwIG4gCjAwMDAwMDgzNDIgMDAwMDAgbiAK MDAwMDAwODUzNyAwMDAwMCBuIAowMDAwMDEwNDA3IDAwMDAwIG4gCjAwMDAwMTE3NzIgMDAwMDAg biAKMDAwMDAxMjM3NSAwMDAwMCBuIAowMDAwMDEyNDExIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1Np emUgNTkKL1Jvb3QgNTggMCBSCi9JbmZvIDM1IDAgUgovSUQgWzw2ZjUxMTFhYmViNzkzMzIzNTE2 NGM0NzI2MmFhMTVjZj48NmY1MTExYWJlYjc5MzMyMzUxNjRjNDcyNjJhYTE1Y2Y+XQo+PgpzdGFy dHhyZWYKMTI0NzYKJSVFT0YK ------=_NextPart_000_01B4_01C08543.36C53210-- From owner-tcpsat@lerc.nasa.gov Tue Jan 30 02:34:46 2001 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01772; Tue, 30 Jan 2001 02:34:45 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id BAA07299 for tcpsat-outgoing; Tue, 30 Jan 2001 01:18:54 -0500 (EST) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id BAA06638; Tue, 30 Jan 2001 01:07:20 -0500 (EST) Received: by seraph3.lerc.nasa.gov; id BAA08177; Tue, 30 Jan 2001 01:07:19 -0500 Received: from unknown(202.96.136.221) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008139; Tue, 30 Jan 01 01:07:03 -0500 Received: from public.szptt.net.cn([202.96.136.221]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43a7661a4; Tue, 30 Jan 2001 06:06:37 -0000 Received: from cuse68.se.cuhk.edu.hk([137.189.59.68]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm193a7334be; Sat, 27 Jan 2001 16:04:03 -0000 Received: from cuse190.se.cuhk.edu.hk (localhost [127.0.0.1]) by cuse68.se.cuhk.edu.hk (8.11.2/8.11.2) with ESMTP id f0RAf1D15876; Sat, 27 Jan 2001 18:41:01 +0800 (HKT) Received: from cse.cuhk.edu.hk (cucs18.cse.cuhk.edu.hk [137.189.91.190]) by cuse190.se.cuhk.edu.hk (8.10.1/8.10.1) with ESMTP id f0RAf0w20157; Sat, 27 Jan 2001 18:41:00 +0800 (HKT) Received: (from root@localhost) by cse.cuhk.edu.hk id f0R1tNC22002; Sat, 27 Jan 2001 09:55:23 +0800 (HKT) Received: from ada.cs.ucy.ac.cy (ada.cs.ucy.ac.cy [194.42.7.2]) by cse.cuhk.edu.hk with ESMTP id f0NCHZQ24016; Tue, 23 Jan 2001 20:17:38 +0800 (HKT) Received: from cs144 (cs144.cs.ucy.ac.cy [194.42.7.56]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id NAA47704; Tue, 23 Jan 2001 13:50:43 +0200 Message-ID: <01c901c08532$8dd269d0$38072ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: "alg" , , , , "comm-theory" , , , , "Conferencesa" , , , , , , , , , "GU-NET" , , , , , , , , , , , , , , , , , , , , , , , , "terena list" , , Cc: "Andreas Pitsillides" Subject: INFOCOM 2002 CALL FOR PAPERS Date: Tue, 23 Jan 2001 13:48:49 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01B4_01C08543.36C53210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Lines: 441 Sender: owner-tcpsat@lerc.nasa.gov Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; charset="windows-1253" Content-Transfer-Encoding: 7bit Please accept our sincere apologies for multiple copies INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002. For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =========================== David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: text/plain; name="cfp2002.txt" Content-Disposition: attachment; filename="cfp2002.txt" Content-Transfer-Encoding: quoted-printable INFOCOM 2002 CALL FOR PAPERS ************************************************* * IEEE INFOCOM 2002 * * The Conference on Computer Communications * * * * June 23-27, 2002, New York City * * * * The 21st Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2002 * ************************************************* SCOPE =3D=3D=3D=3D=3D The major conference on computer communications and networking is celebrating its 21st anniversary at the Hilton Hotel in New York during the week of June 23-27, 2002. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Broadband & ATM * Congestion & admission control * Flow control * Internetworking & IP * Mobile & wireless networks * Multicast * Multimedia * Network applications & services * Network architectures * Network design & planning * Network management & control * Network measurements & testbeds * Network modeling * Network pricing * Network protocols * Network system software * Optical networks * Quality of service * Routing * Scheduling * Security & privacy * Storage area networks * Switches & switching * Traffic engineering * Web caching * Web performance SCHEDULE (STRICTLY ENFORCED) Full paper due July 31, 2001 Notification of acceptance November 14, 2001 Final version due December 20, 2001 CONFERENCE SCHEDULE Tutorials June 23-24, 2002 Conference June 25-27, 2002 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2002.=20 For general information please contact the Genaral Chair, Parviz Kermani PROGRAM COMMITTEE CO-CHAIRS =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 David Lee, Bell Labs Research China (lee@research.bell-labs.com) Ariel Orda, Technion - Israel Inst. of Technology = (ariel@ee.technion.ac.il) ------=_NextPart_000_01B4_01C08543.36C53210 Content-Type: application/pdf; name="cfp2002.pdf" Content-Disposition: attachment; filename="cfp2002.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAtMTAwIG51bGxd Cj4+CmVuZG9iagozIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjEyIG51bGxdCj4+CmVu ZG9iago0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgLTcwIG51bGxdCj4+CmVuZG9iago1 IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9JbWFnZQovTmFtZSAvSW0xCi9XaWR0 aCAzMDkKL0hlaWdodCAyNTcKL0JpdHNQZXJDb21wb25lbnQgMQovQ29sb3JTcGFjZSAvRGV2aWNl R3JheQovTGVuZ3RoIDU4NgovRmlsdGVyIC9DQ0lUVEZheERlY29kZQovRGVjb2RlUGFybXMgPDwK L0sgLTEgL0NvbHVtbnMgMzA5Pj4KPj4Kc3RyZWFtDQr///5kDCEfmSAapl4bUycCSCIFe0oEDgg4 IgeCbUwg4QOCDhBwiGuOYuUOHBAiKA0UQ1CoOEQ0jBB+DhEM0cobQMOEEKg3QQUMHCBKD0CTDdJQ YdBbDhAgoboJQ3CCVuglDcJKG6CVh0goN0EFbpBW6CUN0gt0lbpAkG6RFwVW6QV6CI0BOGHSCb0k m9bdJO6VN6t6W3p26u+g90iShtt0gd6Tt6fq7eqelbdVvSb1TukQMDwd+SYHg13SCIHgyDfgiB4F CR6CB9IINvhBvSCB/Tb4QfpN6p3pP6IKVA3qgTINnv6VBt6SBNBu+lgw/oKn6SW3frbfpbf0Fh/r 3eq36pbb9Le9e39Lute7fS/9bfX7+u/69/9/97/9Vr+/99f///2//////X////1+//uv+n/bpJf3 9v6/b/71Xvr++vv1V29f+l7bX+3pV4eq3d0vbel9vX2w9Je2qXdg8JV4eFXbBhMJVdgwmEvhiK7b CS218NVdpdhhdwwl2GElwYXcGvYMgeCmrVsigHg21yq5cDwXW2TIFZdhgqu0lbpd9X1t9bTW+lb0 tp9tUt2sOmltVsNOrYTCXTSsNBpWwmtsJoK2EGtsEGgrDCIHg6tW00rdpQ2qVh2lYeErettsIKGH QSsORML8pznpWGd+jYdAiOrBndeCjDYhKwztOCiwYShsIKwwlDBglDIZq0FDBlSBohhksBqhkGsb ChkNccqsKGIhQwUMKDCgwUGQPW1kGFMoA3mUwVZloGlMi+R2RwsRH////+ACACAKZW5kc3RyZWFt CmVuZG9iago2IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTcwIG51bGxdCj4+CmVuZG9i ago3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNTkwIG51bGxdCj4+CmVuZG9iago4IDAg b2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNjIyIG51bGxdCj4+CmVuZG9iago5IDAgb2JqCjw8 Ci9EIFsxIDAgUiAvWFlaIG51bGwgMTg4IG51bGxdCj4+CmVuZG9iagoxMCAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIDI1MiBudWxsXQo+PgplbmRvYmoKMTEgMCBvYmoKPDwKL0QgWzEgMCBS IC9YWVogbnVsbCAzNTEgbnVsbF0KPj4KZW5kb2JqCjEyIDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFla IG51bGwgMzY3IG51bGxdCj4+CmVuZG9iagoxMyAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxs IDM4MSBudWxsXQo+PgplbmRvYmoKMTQgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCAzOTQg bnVsbF0KPj4KZW5kb2JqCjE1IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDQxIG51bGxd Cj4+CmVuZG9iagoxNiAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1OCBudWxsXQo+Pgpl bmRvYmoKMTcgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NzIgbnVsbF0KPj4KZW5kb2Jq CjE4IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDg2IG51bGxdCj4+CmVuZG9iagoxOSAw IG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDE4MSBudWxsXQo+PgplbmRvYmoKMjAgMCBvYmoK PDwKL0QgWzEgMCBSIC9YWVogbnVsbCAyMDkgbnVsbF0KPj4KZW5kb2JqCjIxIDAgb2JqCjw8Ci9E IFsxIDAgUiAvWFlaIG51bGwgMzM0IG51bGxdCj4+CmVuZG9iagoyMiAwIG9iago8PAovRCBbMSAw IFIgL1hZWiBudWxsIDM3NSBudWxsXQo+PgplbmRvYmoKMjMgMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCAzODggbnVsbF0KPj4KZW5kb2JqCjI0IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51 bGwgNDAxIG51bGxdCj4+CmVuZG9iagoyNSAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQx MyBudWxsXQo+PgplbmRvYmoKMjYgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0MjYgbnVs bF0KPj4KZW5kb2JqCjI3IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDM5IG51bGxdCj4+ CmVuZG9iagoyOCAwIG9iago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ1MSBudWxsXQo+PgplbmRv YmoKMjkgMCBvYmoKPDwKL0QgWzEgMCBSIC9YWVogbnVsbCA0NjQgbnVsbF0KPj4KZW5kb2JqCjMw IDAgb2JqCjw8Ci9EIFsxIDAgUiAvWFlaIG51bGwgNDc3IG51bGxdCj4+CmVuZG9iagozMSAwIG9i ago8PAovRCBbMSAwIFIgL1hZWiBudWxsIDQ5MCBudWxsXQo+PgplbmRvYmoKMzIgMCBvYmoKPDwK L0QgWzEgMCBSIC9YWVogbnVsbCA1MDIgbnVsbF0KPj4KZW5kb2JqCjMzIDAgb2JqCjw8Ci9EIFsx IDAgUiAvWFlaIG51bGwgNTE1IG51bGxdCj4+CmVuZG9iagozNCAwIG9iago8PAovRCBbMSAwIFIg L1hZWiBudWxsIDUyOCBudWxsXQo+PgplbmRvYmoKMzUgMCBvYmoKPDwKL0NyZWF0aW9uRGF0ZSAo RDoxOTEwMDExMDYxMjA3MDMpCi9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgQ29tbWFuZCAz LjAxIGZvciBTb2xhcmlzIDIuMyBhbmQgbGF0ZXIgXChTUEFSQ1wpKQovVGl0bGUgKGNzLmVwcykK L0NyZWF0b3IgKEZyYW1lTWFrZXIgeG01LjVQNGYpCj4+CmVuZG9iagozNiAwIG9iago8PAovRCBb MSAwIFIgL1hZWiBudWxsIG51bGwgbnVsbF0KPj4KZW5kb2JqCjM3IDAgb2JqCjw8Ci9EIFsxIDAg UiAvWFlaIG51bGwgbnVsbCBudWxsXQo+PgplbmRvYmoKMzggMCBvYmoKPDwKL0QgWzEgMCBSIC9Y WVogbnVsbCBudWxsIG51bGxdCj4+CmVuZG9iagozOSAwIG9iago8PAovTGVuZ3RoIDQ4MTUKL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtDQpIiYxX23LbOBJ911fgaYtKWTSuBJm3xHG8zubi iVWzteXMg0zDMhOJ9FJSXNmv39MAQYn0ZTKpGuq4ge6D7kZ3Q7Dl5PjsUrDlZiJYxSaccZYJyWwh WesmtxNhmbWSGZuxmTWZ/+Oric45/sxTDalOuWazTBAI0v9O8EfBDQvaSOA38IKV68nx+Vqwd83k j8nb+eT4vWSCzW8nOvOr8REmxUKrbMpzNl+D0nIy4ynP2LwEmD9MrpKTNx8/Mvb+y1fGLqZWJ28u Tr9eTv+af4BCHRTiEKQQH4XjiCKogork8r6pN03rbtj1r+n8O7ZkYYtJjcwVNs3fwcZrxtj8zrHz erOttrutY80tO125cttW5WLFFvVNB6c6S5q6Ktlpvaxq59qp4MnmCDvLlH1Lzk9PT79Njzw9kXJj 2EykIsss2fFSdtKs72GhZZdNWbntL/YPFv++3kHzYluBc5QS6dM5TnM2kewD+H5nkoLwwFSaZ+wT u/qLs5uJNgW50CoJa2wNrNMs857NcjZCukiFRjCxlpUTrVWawW06S41gzyBLn4O1eYpEGaOg1ij6 lD0FY1O4YYwC3Uyl3NJa/NBIhCxPTcHGSNOnQ7TWpHYvPATIUiEOtCI1jeptDlGONDMHbHNkhO3P 8jSKXog4+GiEgt7o3M5o5/kRCnRDzPqDySzNNBsBOC+CvbeicIAGiVBOrl/hstO/dtn9+HqGbPrA BC17YFAmQmBEKq3PnJwSyxpOf9bkLXBEbBXlUZ4q5d0SGMMYftDRC8VIUxEQVNMBhImISGNvj7UV IQfDTqDCHui1Ms17oxBq0xOCmkg3qg1QFV5IoQAyASgPMtMpVV5NUfhISL03ocI5bJrrbikPIVVe jyRg6EOhIP8CqaJzQV54TGmNHPDbKGuMIUt0KOUXmlSHQ+W59ysJibftPQeUh0wQIQaeOiGbe6QD 2sfLB5gKA/YUVBdshvxTFEe6NtZfBsNGAHkXFwZiGTkmCzdziKQPIj4hiDhM1t0Eqg4D1K3V/f0P mpRfNEKBgkKKhCsd6CkcVLAxCufq1yJWlJHK58EYZcHl/aVG28p6gkPUre2P1mnqDj5EA9+Wk42/ goUK5cN4b6vgKP9Z+RORa3BhitzjLJXqUG5CUo+w8mmx8vryYo/Raak3GmQvpYLkpF1BJ5tpStXQ jHsxaofuxJ7nUKw4peDzYtxQ+bxYU0N7QUx35lkp5fALzMjdLzCji/ACM/g4f45Z5kcbyJBEj4QI DCYRnR3IdScX5PVChLQStHQ9MTlVrdy3Ha4lwmOQLjmnS4UsLwQzCD/VDGp6KFMRBgXlJGKJUqto 4Op2CwuiBev1EylByXkboo9OI4OLTeZ5GF8mAqZd2uyRpVztEExGrGhRjzjV5IiQbNL4tZkv8wGT FeryEek0D4mqtF8rKcPpAmKLyVG4rNcrjEdFN2iIbi0dU2tqkSZXqZS+clrrrXC950uhyVCwM+9E TKhS063FcFjEwTTKUVGtOZCbsVyTl56XUwV/SY5gFeYF+wr2XxLDvHhBLgtK3hfkXvI8PTGin/WZ 27V9Y4vQlyX1Okvl4nAdR0tY+gETRcVPBIgI93M0+V3R75ngaXglvH0VZk3ts1WHUbP7vep+G4rr ar9ujBX1PMKK6tBjLOgSHqwfYR4AJ7cOARhnQVPuTxzxNb1ihJ/LImlU/+7Ged4RRqpx9RhHqtYM qUccqcb1IxzY0nQjR6CnnvNH1C0fUEeNOaQeYaQaV49xpIp0HlCPOFKN60c4sKXBRIxATz0rxtT9 qy8PLy4ZHmmSrjKKB86cE4Pu1XeVnNe3U2mSpl37FxBr6u6RJ3hQgMrAUTX9ky15HV5zQoxfgCIM 15ivvO5k1y3slFCnsKZTwi531+tqsyFzFZ5+7a70j6+RblwZHt+KY33wkpAmviMv2mbZLtb+vdi6 qTDJsoJaf6B4mk7rTCBHSS0eiAr//Z3y5GPjX6Jtu6iXbu3q7Zgm5v9c/RbNy+3uBgo8TbCbSp78 JLJuxUCfNAeuXeQwS3nnagRP0DxE8wU59yq5227vXx8fPzw8TC1P0so5N6u6QJbNOm3aqeDJ8lhy Lr1SjA5eF3ot8oQebbjV6Hle22V55252K8e+JfBaVW5Xv5gjbTohRXlSuptRUiBNlda6O/W3KR17 nwwKjYhsoAWgVHob73erFbtf3LuW3ezcdJZj1Es+7GBJiSMGnsJb4BQXkSGRvcc+N9vqm1JZ2eXm LVuUpbvfLuoSOoSUOZaQC4Mf19dQL/SBvvkrsl3VCCGW6MS1Pus8BZ3bPHnnyrBN8oNt+xiM/aYK 0/vtpKlvnXeQAx8W3Th21dgtCrUmumU+1TrZbZu2Wqw201khcg2v1I5JNZPhIHJ/kGDQ+cPnQstu qZlJe7D0dI4mdDZR1FQUsgdVlklL3UT55nM5OT65FOzkknF6THGaEsAwRXU5vhDs8uTzM9u8VsPh CoWUNGxm5e/qe2rXYZU68DOGUSiQhaXJxjvprFourqst++y2D5TXTfujqpfs31NLdevH5q65f97n 6MKYmCQqJpWl85qVTf19V/uKwx6q7R1DBaRLExyIPMaYlIUCERMxhuSoXyOofXsT9EP5sifRhce3 MzNJCt2bpvR30uJObstlfVz2kTxeXtePQodKKvFukfAHAv27Tn5q19NO1pKqH06T0VvPk/5y7+o3 4bbf7XPpSZcWkkYfUXAabH7XqxiAOUX/kVfzmSz2joXcSGuGZWDk0AZUF215l4bqtBxe2ZnC467I KB7gZ7ylM1e7FjXg5G5Rtb6HqaGFC8qrxZQnvnD+rP7H/kXF1KEr1lWnX8d+mIvYHI7Y+dtPoeRH 64UXD5T/OVU2qUo38+Y3r72+EYH3oY7csLeLHWpKIZOjoVkchuORFux+bn5Ui6HdTv7EqaikVwv2 qWmDjcXKjXTnqeg7LbUpF8ppvUEUN9uU6u6cKDk4qJwKkdzVzapZ/ho5nmYXno8OFjaWd3VFffQC FIokdOuT5iWHvFtQAH5WN+yjG/PF6KSiL66Stw6t5ePiesO+uo1DYtCp7xBrlP0Rw27jwNCbtnKr 6Yx6yZf2ZvHI7aLv3ziKij6AhZqmC79vFj7nm3YRVXnHhZ/Nbfj+jgvzdJg8CAamBap2J816XW23 zj2fxP9chOyl/7lf7L0vOM4hhYdnwotS9AlcfVpsfiCP63KQT3h86ZjlaTfUqK4SGHoNoaBTIQLA HRMYKlFxjBapVmG25OEVdJV8mEqRxJZ22KcOZigVNGKPooes4hhOzIG6hF39LQclPdhvukrQMaYi Sx7Yf+ASQb2CnVTb/7NeNc1t40j0rl+BU0pKjRUCIEBybxOvM5WpymR2rKo9ZPcgU7TDXUl0UVRS /vf7XoOSaAramrFTPliP3Wh0N/rzaVzZxrfbeQY56PdJfpqTF18rJEGeTL9jhHu64lTS7jr183a7 R1z/2tQY7E79mSnT4cTHm5sbPt3jvsOMwcGP77hnMsjIq26bsq66ugqzH2beop/6MoSq0lhgMpWy 4OYjtw5roj+NgIfxzzwb/9BXZFVLOPrLTvnHLxPsGT4v2EFclqorkzj+PnZ6jQZRZGygaNnF/M+2 +vix0e2wwKWGC4PPRIPNxKGHoj8ITtUYFQeEwaScOKxAxgs2oI6Qmess8FrhtbxAJBk1Rimf3nMl 8sLruRX6jO18BAquYx4LK1YocGa4k9pDgFVjZOYF77BzJ9riM7qsx2e03jHy85SXJAe5OdX2Pp+n uPUMYXZCuvMy8hY85KGnvOEY0WMwNzM9L70CV1mnxigXLwAlea+D3JPQ/nOUC0hsz4qM8S64foSC Ck7uCip4E7BWEQSXORjqet6MkjJJxecoR3/nyZSGgjf39I53yRyXjgGlpgXTJ3Ai+IhpdhzBhGLI m/N9zpHXgoIXcokKn2Zzb9UYOYon0sKacmjyqZ+jD52j5IjIK4XoSI0iKX0DXseAGaP+lnRusl6H ghgjmVZj5CSSkZxZkOvmLhPMqDpHAJqPE1gZyqH+jlF/idSBoIKzgnUw/DmiurZgVAZeTLXEmVHn CFlEpIuely60+RxNcYyQj15QkvUuQ23xNpunwaFDZCT3rWeZI6/h5uYtHlNdAokeckqWj1F/B8zV vQZpoNpAjSBLAQNemb3PEV6WKB0aptlMxsgww4h8UEEzgIgNzX6GUPlYK23SPwRKFgMb2Bs1RmDS gnSopIUoaIq+eA4AXgO/UXPkFVDNWA6BUSzOEQu78f2L9RUZjb5Qz8DTiIZsszoAr75NsFEw7rxJ mbARVBx4S+Et/EFQDDiE9JCz7yUjJLVBkOQysNahKzk1Qs86YTm5fzvhXCR9nh1K6jgCCNvd3Ml0 iFRCVwUfPURBzjO0DTPuOTml56RKpJHTzolw3A8PxMnh2ZCdEbJhmWfGIPjip1OpxEXsbpbdTJyZ iHB/RmYdgmFZVLWcCc9+UVzQHNnoOQroEzkbnk6lBcftNkJG1A41zwaqMZrhehfV3EuGORkYInaH XHWo0DGn4rTUX8esOgrPBqe1FEqr41ebUF+iXullczy58J5hFioOeov7DoeTuTt2wKhZDEQEXO5j ZGgcilAecwquZtdGouv0eDdM6ckMMbE6ieWADTlgpI9HyMgBH+pflNx3dsdHjZBlE5EU0XGzkzC+ JUUkVKh4IWSdXyCLz3wszOAyK1OktjGyDSOx45Rx0eFhYj5/TbQV9uOQfY61ZexSGd0w5/gYORXh nN0MyRmFu4HLkDd91Q7UyGEozkYbIzMUYHYae2xW2VzCkEPbQbOjV9g4iqC4iSjO0/awGwSyYS8+ 3K3F5dTcRNKLnSKXgmcvkCmc+a+PLj8JJzmTsdXTMAymZ3eH0Soahpq7BEf0Io9czcNhM/CxKOVp HaaQg09TmjKwKw1xGMvd3uxh2Ug5HQZyZLMzWvord6Vcyb51ZTkF9vJ0EVpjHmzxIzLaMk1FAGSR w5Cdecko/IuQU2nmmDGMvnCaVcqxBkdPk4wXtBfIXFlQaOAuy5XxCo11dDWWFJ3GrJaIZc5wRWKL GGtGJyM6EL/hdM4ifzjt6HEKN1GX5uE0hNg4uV8dkNURu4zstlZGlqjTfJg1s4NPZcMZCMfdiBId vdscXiTqU54OHc1f8BrttjLaRIWz1CDSnKiWj8gupHvCf5HTLsS9Y9Zc1Jxei92dFDIrc46Jap5I Z3DpyWvj0yEHYpolPnjFXjjsJQkw3mRFnJyH9Ps/D2IkEKNO4dXYZ1zMrCST5MVrc8hhW3tOtmGB kIn2+CBmQM6Cz0wse6Ea90AEIkJJYmxIfr+YvPsAglaL+wkaAIpVgr9M6qpxMukacdxiM5l+vLm5 mS3+M0llhTsxalRYJiI4fc9JNid9nmw6SZgmup9fT3zbqLhCU5EB24fP15+jEq2RQBuwbmISbeHm OhuymSQx5ESFQVUjJ/YR5BzKOoZgVxScucD4Zbr4WqnrZns/K6ZVW23LSjVbfNg87ruq5Y/NTPvp fluXy65utrvZvxe/Tm4Wp31Dq18muNyi8lhYf2WM1Pn3byfvrm+1ur5lqYe2HCWgCF/w3e9a3V7/ Fjt2279ZEt4Mw4K4w/C10OSttlwaoXmiHqD957Z+qLfLtXpcPlbtTi3bStXbWaqn3+quWtGWtiqr baeWq28z46ZLWLgDiyp7E8WehO1Loxmqxd8hFbTNwGLoZnBwFX5sq+77TCfTpv1vvX2Yh4+LWY4v j3XZczf34X+9xRXVriOyQOV6v6p+CrS7mUmm+1ky7USHxVvcTP23TafW9Ub075qfVIcXum/W62Zm /PQ77vyb8MNJuncSOlsfNfOsd5RB78V7MxZaBsLApcjGLAW3mPq+bZarOxin3qifZ1rTlGT6aXwD B5+sCIdiAv1R4G8n96jHti6h70jYlcZ04LUMcTpHn7gg86DkFOH5AB/iLaDkcrWpdzv+Lptt1zbr /uBrNW26pmzWu1fq+mX6oX+no3o/xJO7p11XbdSuuQ/fECev1vQjYzNEs+6jGf79+PvLNf782CFp 1mqQIq936Kfmrl5X0Ox73VbrardTA53H4v+0stN/7JfruntSzb3aVe23uqyeB9JfjtJP+zWtR66/ LCCnfzT7jtnyA9TYVKt6+VI9bsuv1Wq/frUqhwiWh1LLx8f1oaLiMXufv/j9vkxvq3Lf8gXfsM6w tocCj/JVzrSbPr068p6p35ZfUZHLbt++SumuaZcPFfvU8semyVDZVbWrH1gsH9fL7fa8Av+FWPhe dwgHeTH5+YOjYrPcwh0bNug3L6mYaHguLw6S1WJm3bRd3jMQ/mWtL1W1xXxQVW28Dbk81S9TXG2q 5Q6xQNXpnQ4N6q5avSI0/skRorpT5TJ4+UcGxKZZVetXxMFJO0xZ90274Rh1mAT/J8AAHQJaSQpl bmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjw8Ci9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIg XQovRm9udCA8PAovRjIgNDEgMCBSCi9GNCA0MiAwIFIKL0Y2IDQzIDAgUgovRjggNDQgMCBSCi9G MTAgNDUgMCBSCi9GMTEgNDYgMCBSCi9GMTMgNDcgMCBSCj4+Ci9YT2JqZWN0IDw8Ci9JbTEgNSAw IFIKPj4KL1BhdHRlcm4gPDwKL1AxIDQ4IDAgUgo+PgovRXh0R1N0YXRlIDw8Ci9HUzEgNDkgMCBS Cj4+Ci9Db2xvclNwYWNlIDw8Ci9DUzEgNTAgMCBSCj4+Cj4+CmVuZG9iago1MCAwIG9iagpbL1Bh dHRlcm4gL0RldmljZUNNWUsgXQplbmRvYmoKNTIgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgXQo+ PgplbmRvYmoKNDggMCBvYmoKPDwKL1R5cGUgL1BhdHRlcm4KL1BhdHRlcm5UeXBlIDEKL1Jlc291 cmNlcyA1MiAwIFIKL01hdHJpeCBbMC45IDAgMCAwLjkgMCAwXQovUGFpbnRUeXBlIDIKL1RpbGlu Z1R5cGUgMwovQkJveCBbMCAwIDggOF0KL1hTdGVwIDgKL1lTdGVwIDgKL0xlbmd0aCA4OQovRmls dGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0NCkiJFMgxDkBAFIThfk7xX4Ds8iL2ChKFKBSioyBL QuP6nswU882tyI4CgdbzbJq4VNH5cVDzUpdtQ8+8BFYVEe+pRCLLKMwRK8zl+5fhzho16BNgAHLx ElcKZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago8PAovVHlwZSAvSGFsZnRvbmUKL0hhbGZ0b25l VHlwZSAxCi9IYWxmdG9uZU5hbWUgKERlZmF1bHQpCi9GcmVxdWVuY3kgNjAKL0FuZ2xlIDQ1Ci9T cG90RnVuY3Rpb24gL1JvdW5kCj4+CmVuZG9iago0OSAwIG9iago8PAovVHlwZSAvRXh0R1N0YXRl Ci9TQSBmYWxzZQovT1AgZmFsc2UKL0hUIC9EZWZhdWx0Cj4+CmVuZG9iago1NCAwIG9iago8PAov VHlwZSAvRm9udERlc2NyaXB0b3IKL0FzY2VudCA3MTIKL0NhcEhlaWdodCA3MTIKL0Rlc2NlbnQg LTIzMgovRmxhZ3MgMjYyMTc4Ci9Gb250QkJveCBbLTE1MiAtMjY2IDEwMDAgOTI0XQovRm9udE5h bWUgL1BhbGF0aW5vLUJvbGQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyMgovWEhlaWdodCA0NzIK Pj4KZW5kb2JqCjQxIDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAv RjIKL0ZpcnN0Q2hhciAzMgovTGFzdENoYXIgMjU1Ci9XaWR0aHMgWzI1MCAyNzggNDAyIDUwMCA1 MDAgODg5IDgzMyAyMjcgMzMzIDMzMyA0NDQgNjA2IDI1MCAzMzMgMjUwIDI5NiAKNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI1MCAyNTAgNjA2IDYwNiA2MDYgNDQ0IAo3 NDcgNzc4IDY2NyA3MjIgODMzIDYxMSA1NTYgODMzIDgzMyAzODkgMzg5IDc3OCA2MTEgMTAwMCA4 MzMgODMzIAo2MTEgODMzIDcyMiA2MTEgNjY3IDc3OCA3NzggMTAwMCA2NjcgNjY3IDY2NyAzMzMg NjA2IDMzMyA2MDYgNTAwIAozMzMgNTAwIDYxMSA0NDQgNjExIDUwMCAzODkgNTU2IDYxMSAzMzMg MzMzIDYxMSAzMzMgODg5IDYxMSA1NTYgCjYxMSA2MTEgMzg5IDQ0NCAzMzMgNjExIDU1NiA4MzMg NTAwIDU1NiA1MDAgMzEwIDYwNiAzMTAgNjA2IDI1MCAKNzc4IDc3OCA3MjIgNjExIDgzMyA4MzMg Nzc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDQ0NCA1MDAgNTAwIAo1MDAgNTAwIDMzMyAzMzMg MzMzIDMzMyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA2MTEgNjExIDYxMSA2MTEgCjUwMCAyNTAg NTAwIDUwMCA1MDAgNjA2IDY0MSA2MTEgNzQ3IDc0NyA5OTggMzMzIDMzMyAyNTAgMTAwMCA4MzMg CjI1MCAyNTAgMjUwIDI1MCA1MDAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgNDM4IDQ4OCAyNTAg Nzc4IDU1NiAKNDQ0IDI3OCA2MDYgMjUwIDUwMCAyNTAgMjUwIDUwMCA1MDAgMTAwMCAyNTAgNzc4 IDc3OCA4MzMgMTAwMCA4MzMgCjUwMCAxMDAwIDUwMCA1MDAgMjc4IDI3OCAyNTAgMjUwIDU1NiA2 NjcgMTY3IDUwMCAzODkgMzg5IDYxMSA2MTEgCjUwMCAyNTAgMzMzIDUwMCAxMDAwIDc3OCA2MTEg Nzc4IDYxMSA2MTEgMzg5IDM4OSAzODkgMzg5IDgzMyA4MzMgCjI1MCA4MzMgNzc4IDc3OCA3Nzgg MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAKXQovRW5jb2Rpbmcg NTUgMCBSCi9CYXNlRm9udCAvUGFsYXRpbm8tQm9sZAovRm9udERlc2NyaXB0b3IgNTQgMCBSCj4+ CmVuZG9iago0MiAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y0 Ci9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1Cb2xkSXRhbGljCj4+CmVuZG9iago0 MyAwIG9iago8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL05hbWUgL0Y2Ci9FbmNvZGlu ZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1JdGFsaWMKPj4KZW5kb2JqCjQ0IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjgKL0VuY29kaW5nIDU1IDAgUgovQmFz ZUZvbnQgL1RpbWVzLUJvbGQKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMQovTmFtZSAvRjEwCi9FbmNvZGluZyA1NSAwIFIKL0Jhc2VGb250IC9UaW1lcy1S b21hbgo+PgplbmRvYmoKNDYgMCBvYmoKPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9O YW1lIC9GMTEKL0Jhc2VGb250IC9aYXBmRGluZ2JhdHMKPj4KZW5kb2JqCjQ3IDAgb2JqCjw8Ci9U eXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjEzCi9FbmNvZGluZyA1NSAwIFIKL0Jh c2VGb250IC9IZWx2ZXRpY2EtQm9sZAo+PgplbmRvYmoKNTUgMCBvYmoKPDwKL1R5cGUgL0VuY29k aW5nCi9EaWZmZXJlbmNlcyBbIDM5L3F1b3Rlc2luZ2xlIDk2L2dyYXZlIDEyOC9BZGllcmVzaXMv QXJpbmcvQ2NlZGlsbGEvRWFjdXRlL050aWxkZS9PZGllcmVzaXMKL1VkaWVyZXNpcy9hYWN1dGUv YWdyYXZlL2FjaXJjdW1mbGV4L2FkaWVyZXNpcy9hdGlsZGUvYXJpbmcvY2NlZGlsbGEKL2VhY3V0 ZS9lZ3JhdmUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lhY3V0ZS9pZ3JhdmUvaWNpcmN1bWZsZXgv aWRpZXJlc2lzCi9udGlsZGUvb2FjdXRlL29ncmF2ZS9vY2lyY3VtZmxleC9vZGllcmVzaXMvb3Rp bGRlL3VhY3V0ZS91Z3JhdmUKL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy9kYWdnZXIvLm5vdGRlZiAx NjQvc2VjdGlvbi9idWxsZXQvcGFyYWdyYXBoL2dlcm1hbmRibHMKL3JlZ2lzdGVyZWQvY29weXJp Z2h0L3RyYWRlbWFyay9hY3V0ZS9kaWVyZXNpcy8ubm90ZGVmL0FFL09zbGFzaAogMTc3Ly5ub3Rk ZWYvLm5vdGRlZi8ubm90ZGVmL3llbiAxODIvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRl ZgovLm5vdGRlZi9vcmRmZW1pbmluZS9vcmRtYXNjdWxpbmUvLm5vdGRlZi9hZS9vc2xhc2gvcXVl c3Rpb25kb3duL2V4Y2xhbWRvd24KL2xvZ2ljYWxub3QvLm5vdGRlZi9mbG9yaW4vLm5vdGRlZi8u bm90ZGVmL2d1aWxsZW1vdGxlZnQvZ3VpbGxlbW90cmlnaHQvZWxsaXBzaXMKLy5ub3RkZWYvQWdy YXZlL0F0aWxkZS9PdGlsZGUvT0Uvb2UvZW5kYXNoL2VtZGFzaAovcXVvdGVkYmxsZWZ0L3F1b3Rl ZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQgMjE2L3lkaWVyZXNpcy9ZZGllcmVzaXMvZnJh Y3Rpb24vY3VycmVuY3kKL2d1aWxzaW5nbGxlZnQvZ3VpbHNpbmdscmlnaHQvZmkvZmwvZGFnZ2Vy ZGJsL3BlcmlvZGNlbnRlcmVkL3F1b3Rlc2luZ2xiYXNlL3F1b3RlZGJsYmFzZQovcGVydGhvdXNh bmQvQWNpcmN1bWZsZXgvRWNpcmN1bWZsZXgvQWFjdXRlL0VkaWVyZXNpcy9FZ3JhdmUvSWFjdXRl L0ljaXJjdW1mbGV4Ci9JZGllcmVzaXMvSWdyYXZlL09hY3V0ZS9PY2lyY3VtZmxleCAyNDEvT2dy YXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZ3JhdmUKIDI0Ni9jaXJjdW1mbGV4L3RpbGRlL21hY3Jv bi9icmV2ZS9kb3RhY2NlbnQvcmluZy9jZWRpbGxhL2h1bmdhcnVtbGF1dAovb2dvbmVrL2Nhcm9u Cl0KPj4KZW5kb2JqCjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCA1MSAwIFIKL1Jlc291 cmNlcyA0MCAwIFIKL0NvbnRlbnRzIDM5IDAgUgovQ3JvcEJveCBbMCAwIDYxMiA3OTJdCj4+CmVu ZG9iago1MSAwIG9iago8PAovVHlwZSAvUGFnZXMKL0tpZHMgWzEgMCBSXQovQ291bnQgMQovTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQo+PgplbmRvYmoKNTYgMCBvYmoKPDwKL05hbWVzIFsoRikgMzcg MCBSIChHOTk2NzM1KSAzIDAgUiAoRzk5NjczOCkgMiAwIFIgKEc5OTc4MDYpIDQgMCBSIChHOTk3 ODA5KSA4IDAgUiAoRzk5NzgxMikgOSAwIFIgKEc5OTc4MTQpIDEwIDAgUiAoRzk5NzgxNSkgMTEg MCBSCihHOTk3ODE2KSAxMiAwIFIgKEc5OTc4MTcpIDEzIDAgUiAoRzk5NzgxOCkgMTQgMCBSIChH OTk3ODE5KSAxNSAwIFIgKEc5OTc4MjApIDE2IDAgUiAoRzk5NzgyMSkgMTcgMCBSIChHOTk3ODIy KSAxOCAwIFIgKEc5OTc4MjMpIDE5IDAgUgooRzk5ODAzOCkgNiAwIFIgKEc5OTgwMzkpIDcgMCBS IChHOTk4NTM1KSAyMSAwIFIgKEc5OTg4MzgpIDI2IDAgUiAoRzk5ODgzOSkgMjcgMCBSIChHOTk5 MDg3KSAyMCAwIFIgKEc5OTkxNTMpIDMwIDAgUiAoRzk5OTE1NCkgMzIgMCBSCihHOTk5MTU1KSAz MyAwIFIgKEc5OTkxNTgpIDI5IDAgUiAoRzk5OTE2NCkgMjggMCBSIChHOTk5MTg1KSAyMiAwIFIg KEc5OTkzODQpIDI1IDAgUiAoRzk5OTM4OSkgMjQgMCBSIChHOTk5NDE0KSAzMSAwIFIgKEc5OTk0 NzgpIDM0IDAgUgooRzk5OTQ5NCkgMjMgMCBSIChMKSAzOCAwIFIgKFAuMSkgMzYgMCBSXQo+Pgpl bmRvYmoKNTcgMCBvYmoKPDwKL0Rlc3RzIDU2IDAgUgo+PgplbmRvYmoKNTggMCBvYmoKPDwKL1R5 cGUgL0NhdGFsb2cKL1BhZ2VzIDUxIDAgUgovTmFtZXMgNTcgMCBSCj4+CmVuZG9iagp4cmVmCjAg NTkKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDExNTg0IDAwMDAwIG4gCjAwMDAwMDAwMTYgMDAw MDAgbiAKMDAwMDAwMDA2OCAwMDAwMCBuIAowMDAwMDAwMTE5IDAwMDAwIG4gCjAwMDAwMDAxNzAg MDAwMDAgbiAKMDAwMDAwMDk3NyAwMDAwMCBuIAowMDAwMDAxMDI4IDAwMDAwIG4gCjAwMDAwMDEw NzkgMDAwMDAgbiAKMDAwMDAwMTEzMCAwMDAwMCBuIAowMDAwMDAxMTgxIDAwMDAwIG4gCjAwMDAw MDEyMzMgMDAwMDAgbiAKMDAwMDAwMTI4NSAwMDAwMCBuIAowMDAwMDAxMzM3IDAwMDAwIG4gCjAw MDAwMDEzODkgMDAwMDAgbiAKMDAwMDAwMTQ0MSAwMDAwMCBuIAowMDAwMDAxNDkzIDAwMDAwIG4g CjAwMDAwMDE1NDUgMDAwMDAgbiAKMDAwMDAwMTU5NyAwMDAwMCBuIAowMDAwMDAxNjQ5IDAwMDAw IG4gCjAwMDAwMDE3MDEgMDAwMDAgbiAKMDAwMDAwMTc1MyAwMDAwMCBuIAowMDAwMDAxODA1IDAw MDAwIG4gCjAwMDAwMDE4NTcgMDAwMDAgbiAKMDAwMDAwMTkwOSAwMDAwMCBuIAowMDAwMDAxOTYx IDAwMDAwIG4gCjAwMDAwMDIwMTMgMDAwMDAgbiAKMDAwMDAwMjA2NSAwMDAwMCBuIAowMDAwMDAy MTE3IDAwMDAwIG4gCjAwMDAwMDIxNjkgMDAwMDAgbiAKMDAwMDAwMjIyMSAwMDAwMCBuIAowMDAw MDAyMjczIDAwMDAwIG4gCjAwMDAwMDIzMjUgMDAwMDAgbiAKMDAwMDAwMjM3NyAwMDAwMCBuIAow MDAwMDAyNDI5IDAwMDAwIG4gCjAwMDAwMDI0ODEgMDAwMDAgbiAKMDAwMDAwMjY2MyAwMDAwMCBu IAowMDAwMDAyNzE2IDAwMDAwIG4gCjAwMDAwMDI3NjkgMDAwMDAgbiAKMDAwMDAwMjgyMiAwMDAw MCBuIAowMDAwMDA3NzExIDAwMDAwIG4gCjAwMDAwMDg3MzEgMDAwMDAgbiAKMDAwMDAwOTgxMiAw MDAwMCBuIAowMDAwMDA5OTE3IDAwMDAwIG4gCjAwMDAwMTAwMTggMDAwMDAgbiAKMDAwMDAxMDEx NyAwMDAwMCBuIAowMDAwMDEwMjE4IDAwMDAwIG4gCjAwMDAwMTAzMDMgMDAwMDAgbiAKMDAwMDAw ODA0NiAwMDAwMCBuIAowMDAwMDA4NDY1IDAwMDAwIG4gCjAwMDAwMDc5NjcgMDAwMDAgbiAKMDAw MDAxMTY5MCAwMDAwMCBuIAowMDAwMDA4MDA3IDAwMDAwIG4gCjAwMDAwMDgzNDIgMDAwMDAgbiAK MDAwMDAwODUzNyAwMDAwMCBuIAowMDAwMDEwNDA3IDAwMDAwIG4gCjAwMDAwMTE3NzIgMDAwMDAg biAKMDAwMDAxMjM3NSAwMDAwMCBuIAowMDAwMDEyNDExIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1Np emUgNTkKL1Jvb3QgNTggMCBSCi9JbmZvIDM1IDAgUgovSUQgWzw2ZjUxMTFhYmViNzkzMzIzNTE2 NGM0NzI2MmFhMTVjZj48NmY1MTExYWJlYjc5MzMyMzUxNjRjNDcyNjJhYTE1Y2Y+XQo+PgpzdGFy dHhyZWYKMTI0NzYKJSVFT0YK ------=_NextPart_000_01B4_01C08543.36C53210--