From owner-tcp-impl@lerc.nasa.gov Tue Nov 2 10:44:15 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06876 for ; Tue, 2 Nov 1999 10:44:13 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA02955 for tcp-impl-outgoing; Tue, 2 Nov 1999 07:31:24 -0500 (EST) Received: from maile.surrey.ac.uk (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA02946 for ; Tue, 2 Nov 1999 07:31:22 -0500 (EST) Received: from regan.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Tue, 2 Nov 1999 12:30:21 +0000 Date: Tue, 2 Nov 1999 12:31:03 +0000 (GMT) From: Lloyd Wood X-Sender: eep1lw@regan.ee.surrey.ac.uk Reply-To: Lloyd Wood To: tcp-impl@grc.nasa.gov cc: ballardie@dial.pipex.com Subject: a TCP slowstart question 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-tcp-impl@lerc.nasa.gov Precedence: bulk [prompted by a chat with Tony Ballardie.] Has anyone looked at implementing what works in fast recovery in slow start itself? http://search.ietf.org/internet-drafts/draft-floyd-cong-00.txt Section 9.1 'Issues that have not been addressed in the standards process, and are generally considered not to require standardization, include such issues as the use (or non-use) of rate-based pacing,and mechanisms for ending slow-start early, before the congestion window reaches ssthresh.' If you experience loss due to timeout in the actual slowstart process, then the value of ssthresh must be too high for the network conditions, and should be lower. It might make sense for the individual flow to immediately enter congestion avoidance from a lower functional window size that appeared to work, skipping the doubling process all the way from 1 - this should prevent TCPs starving because they never reach ssthresh, decreasing burstiness. This is presuming that a single loss due to timeout in slowstart is equivalent to three dupacks in congestion avoidance. This fits with proposals for increasing initial window size, I think, which address the same starting-from-1-segment going-back-to-1-segment with less flexibility in the case of loss during slowstart. Pointers/list of obvious pitfalls welcome. thanks, L. PGP From owner-tcp-impl@lerc.nasa.gov Wed Nov 3 01:10:25 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20790 for ; Wed, 3 Nov 1999 01:10:24 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA03323 for tcp-impl-outgoing; Tue, 2 Nov 1999 22:12:02 -0500 (EST) Received: from froggie.cs.washington.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id WAA03292 for ; Tue, 2 Nov 1999 22:12:00 -0500 (EST) Received: from localhost by froggie.cs.washington.edu (8.9.3/8.9.3/0.3) with SMTP id TAA11066; Tue, 2 Nov 1999 19:11:55 -0800 (PST) (envelope-from cardwell@froggie.cs.washington.edu) X-Authentication-Warning: froggie.cs.washington.edu: cardwell owned process doing -bs Date: Tue, 2 Nov 1999 19:11:55 -0800 (PST) From: Neal Cardwell To: Lloyd Wood cc: tcp-impl@grc.nasa.gov, ballardie@dial.pipex.com Subject: Re: a TCP slowstart question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, 2 Nov 1999, Lloyd Wood wrote: > If you experience loss due to timeout in the actual slowstart process, > then the value of ssthresh must be too high for the network > conditions, and should be lower. It might make sense for the > individual flow to immediately enter congestion avoidance from a lower > functional window size that appeared to work, skipping the doubling > process all the way from 1 - this should prevent TCPs starving because > they never reach ssthresh, decreasing burstiness. When the sender times out in slow start, what sort of cwnd do you think might be reasonable for the "lower functional window size"? I think traditional TCP reasoning would say that when you time out you've usually (hopefully) lost your ACK clock, so any cwnd bigger than a few packets will lead to a possibly dangerous burst of packets at line rate. > This is presuming that a single loss due to timeout in slowstart is > equivalent to three dupacks in congestion avoidance. What's the reasoning here? cheers, neal From owner-tcp-impl@lerc.nasa.gov Fri Nov 12 15:25:29 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13228 for ; Fri, 12 Nov 1999 15:25:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA11209 for tcp-impl-outgoing; Fri, 12 Nov 1999 12:16:46 -0500 (EST) Received: from lenst.lenst-int (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id MAA11205 for ; Fri, 12 Nov 1999 12:16:40 -0500 (EST) Received: from lenst.die.unifi.it (IDENT:fritta@afrodite.lenst-int [192.168.11.117]) by lenst.lenst-int (8.9.3/8.8.7) with ESMTP id RAA20324 for ; Fri, 12 Nov 1999 17:21:03 +0100 Message-ID: <382C4C3B.AE57CDFD@lenst.die.unifi.it> Date: Fri, 12 Nov 1999 18:19:55 +0100 From: Silvia Frittelli X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: a question about RED gateway Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I have a question about the computation of the average queue lenght avg calculated in "Random Early Detection Gateways for Congestion Avoidance" by Sally Floyd and Van Jacobson (IEEE/ACM TRANSACTIONS ON NETWORKING, vol 1,n. 4, August 1993). When the queue is not empty avg ->avg*(1-w_q)exp[(time -q_time)/s] where: avg is the average queue lenght; time is the actual time; q_time is the moment corresponding to the beginning of the idle of the queue; s is the typical trasmission time for a small packet; I don't understand what the expression (time-q_time)/s means. Infact if it could be the number of packets that might have been transmitted by the gateway during the time that the queue is idle, I don't understand why I have to consider the typical trasmission time for a SMALL packet instead of the typical trasmission time for a MEDIUM packet. Thank you. From owner-tcp-impl@lerc.nasa.gov Fri Nov 12 23:44:44 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04365 for ; Fri, 12 Nov 1999 23:44:43 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA16247 for tcp-impl-outgoing; Fri, 12 Nov 1999 20:56:01 -0500 (EST) Received: from netlab.snu.ac.kr (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id UAB16242 for ; Fri, 12 Nov 1999 20:55:59 -0500 (EST) Received: from netlab.snu.ac.kr (jchee.snu.ac.kr [147.46.116.88]) by netlab.snu.ac.kr (8.9.3/8.9.3) with ESMTP id LAA10542 for ; Sat, 13 Nov 1999 11:16:00 +0900 Message-ID: <382CC50E.A88F139F@netlab.snu.ac.kr> Date: Sat, 13 Nov 1999 10:55:27 +0900 From: Joo Change-hee X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: a question about delayed ACK policy Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit I have a question about delayed ACK policy that is widely used in current TCP implementation and makes the receiver send an ACK per two packets. my question is that if out-of-order packet is received but it is next expected one, then the receiver should delay corresponding ACK ? for example, if the sender experiences mulitple packet drops in a window, then timeout occurs in TCP Reno. the sender already send packets between "snd_una" and "snd_max". TCP starts its slow-start again. At the receiver's view, it receives some packets between "snd_una" and "snd_max" and it expects the next packet ("next_") will be the packet that has seq number of "snd_una". To make it easy, let's thinks the worst case. The receiver receves only one packet that has seq number of "snd_max". Then the sender in its slow-start send packets burstly from seq number of "snd_una". At this point, the receiver should use delayed ACK ? I think that the receiver should not delay ACKs because the packets are out-of-order. But it seems that some implementations delayed the correponding ACKs because they test only whether the received packet has "next_" seq number. Is that right? I am not convinced. Any helps are welcome. Thanks. From owner-tcp-impl@lerc.nasa.gov Sat Nov 13 01:30:23 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11221 for ; Sat, 13 Nov 1999 01:30:22 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA19283 for tcp-impl-outgoing; Fri, 12 Nov 1999 23:02:18 -0500 (EST) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id XAA19279 for ; Fri, 12 Nov 1999 23:02:17 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id UAA00633; Fri, 12 Nov 1999 20:02:11 -0800 (PST) Message-Id: <199911130402.UAA00633@daffy.ee.lbl.gov> To: Silvia Frittelli Cc: tcp-impl@grc.nasa.gov Subject: Re: a question about RED gateway In-reply-to: Your message of Fri, 12 Nov 1999 18:19:55 PST. Date: Fri, 12 Nov 1999 20:02:10 PST From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > I have a question about the computation of the average queue lenght avg > calculated in "Random Early Detection Gateways for Congestion > Avoidance" by Sally Floyd and Van Jacobson (IEEE/ACM TRANSACTIONS ON > NETWORKING, vol 1,n. 4, August 1993). This is not the right mailing list for this question - you might instead try end2end-interest@isi.edu. Vern From owner-tcp-impl@lerc.nasa.gov Sat Nov 13 02:42:03 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09029 for ; Sat, 13 Nov 1999 02:42:02 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA21998 for tcp-impl-outgoing; Sat, 13 Nov 1999 00:13:43 -0500 (EST) Received: from saba.cs.washington.edu (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA21994 for ; Sat, 13 Nov 1999 00:13:41 -0500 (EST) Received: from localhost (cardwell@localhost) by saba.cs.washington.edu (8.9.3/8.9.3/0.2) with ESMTP id VAA31012; Fri, 12 Nov 1999 21:13:26 -0800 (envelope-from cardwell@cs.washington.edu) X-Authentication-Warning: saba.cs.washington.edu: cardwell owned process doing -bs Date: Fri, 12 Nov 1999 21:13:26 -0800 (PST) From: Neal Cardwell To: Joo Change-hee cc: tcp-impl@grc.nasa.gov Subject: Re: a question about delayed ACK policy In-Reply-To: <382CC50E.A88F139F@netlab.snu.ac.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > my question is that if out-of-order packet is received but it is next > expected one, then the receiver should delay corresponding ACK ? I think your intuition is right. If the packet arrives at rcv_nxt but the receiver already has packets buffered above rcv_nxt, then the receiver should send an ACK immediately to expedite the loss recovery process, whether it's a timeout and slow start or Hoe-style fast recovery based on partial ACKs. This is noted in RFC 2581, as well as the New Reno RFC. If i remember correctly, BSD-derived stacks and recent Linux stacks do this correctly, but early Linux 2.0.x stacks unfortunately delay ACKs in this case. neal From owner-tcp-impl@lerc.nasa.gov Sat Nov 13 02:43:09 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09309 for ; Sat, 13 Nov 1999 02:43:08 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA22401 for tcp-impl-outgoing; Sat, 13 Nov 1999 00:26:01 -0500 (EST) Received: from daffy.ee.lbl.gov (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id AAA22397 for ; Sat, 13 Nov 1999 00:26:00 -0500 (EST) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.2/8.9.2) id VAA01069; Fri, 12 Nov 1999 21:25:46 -0800 (PST) Message-Id: <199911130525.VAA01069@daffy.ee.lbl.gov> To: Joo Change-hee Cc: tcp-impl@grc.nasa.gov Subject: Re: a question about delayed ACK policy In-reply-to: Your message of Sat, 13 Nov 1999 10:55:27 PST. Date: Fri, 12 Nov 1999 21:25:46 PST From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > my question is that if out-of-order packet is received but it is next > expected one, then the receiver should delay corresponding ACK ? Here's the relevant part of RFC 2581, which boils down to "no, don't delay the ack": Out-of-order data segments SHOULD be acknowledged immediately, in order to accelerate loss recovery. To trigger the fast retransmit algorithm, the receiver SHOULD send an immediate duplicate ACK when it receives a data segment above a gap in the sequence space. To provide feedback to senders recovering from losses, the receiver SHOULD send an immediate ACK when it receives a data segment that fills in all or part of a gap in the sequence space. - Vern From owner-tcp-impl@lerc.nasa.gov Tue Nov 16 19:10:03 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19613 for ; Tue, 16 Nov 1999 19:10:01 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA13374 for tcp-impl-outgoing; Tue, 16 Nov 1999 15:10:38 -0500 (EST) Received: from shell16.ba.best.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA13360 for ; Tue, 16 Nov 1999 15:10:35 -0500 (EST) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id MAA21729; Tue, 16 Nov 1999 12:10:30 -0800 (PST) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 16 Nov 1999 12:10:30 -0800 (PST) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: tcp-impl@grc.nasa.gov cc: Ron Bonica Subject: Usage of packet returned in ICMP error messages Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Greetings, The IETF MPLS (multi-protocol label switching) working group is currently discussing an internet draft which proposes some modifications to ICMP error messages that are not entirely backward compatible with RFC 1812 (the router requirements document) and RFC 1122 (the host requirements document). Specifically, the draft proposes that when label-switching routers send an ICMP error message they will put a data structure containing the MPLS shim header immediately after the first 8 bytes of user data from the original datagram. As most readers of this list are probably aware, RFC 1812 and RFC 1122 permit ICMP error message to contain more than 8 bytes of user data from the original datagram, but both documents specify that any user data which is returned will be copied from the original datagram without change. Thus, an application implemented in accordance with those RFCs that receives an ICMP error message formatted in accordance with the proposed draft could misinterpret the shim header structure as returned user data. The question arises whether there are, in fact, any applications which make use of extra user data (beyond the first 8 bytes) that is returned in ICMP error messages. If the readers of this list are aware of any such applications I would appreciate hearing about them. Many thanks, Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com From owner-tcp-impl@lerc.nasa.gov Tue Nov 16 21:15:39 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07545 for ; Tue, 16 Nov 1999 21:15:38 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA02096 for tcp-impl-outgoing; Tue, 16 Nov 1999 18:13:22 -0500 (EST) Received: from calcite.rhyolite.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id SAA02084 for ; Tue, 16 Nov 1999 18:13:18 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id QAA12936 for tcp-impl@grc.nasa.gov env-from ; Tue, 16 Nov 1999 16:13:13 -0700 (MST) Date: Tue, 16 Nov 1999 16:13:13 -0700 (MST) From: Vernon Schryver Message-Id: <199911162313.QAA12936@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Usage of packet returned in ICMP error messages Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "C. M. Heard/VVNET, Inc." > The IETF MPLS (multi-protocol label switching) working group is currently > discussing an internet draft which proposes > some modifications to ICMP error messages that are not entirely backward > compatible with RFC 1812 (the router requirements document) and RFC 1122 > (the host requirements document). Specifically, the draft proposes > that when label-switching routers send an ICMP error message they will > put a data structure containing the MPLS shim header immediately after > the first 8 bytes of user data from the original datagram. As most > readers of this list are probably aware, RFC 1812 and RFC 1122 permit > ICMP error message to contain more than 8 bytes of user data from the > original datagram, but both documents specify that any user data which > is returned will be copied from the original datagram without change. > Thus, an application implemented in accordance with those RFCs that > receives an ICMP error message formatted in accordance with the proposed > draft could misinterpret the shim header structure as returned user data. > > The question arises whether there are, in fact, any applications which > make use of extra user data (beyond the first 8 bytes) that is returned > in ICMP error messages. If the readers of this list are aware of any > such applications I would appreciate hearing about them. There are several such applications: 1. some versions of `ping` and `traceroute` decode the bad packet included in the message.. 2. doesn't any TCP host that handles Network or Port Unreachables, Quenches, MTU discovery, need to have the orignal IP header follow the ICMP gateway address, parameter problem byte MAX MTU, or other ICMP data? 3. how does a host understand a Port Unreachable if the original UDP or TCP header is not where it usually is? One might blow off #1 or even #3, but surely not #2. So I must not understand the proposal. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Nov 17 19:02:42 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14083 for ; Wed, 17 Nov 1999 19:02:39 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA01059 for tcp-impl-outgoing; Wed, 17 Nov 1999 15:40:49 -0500 (EST) Received: from stovokor.epilogue.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA01053 for ; Wed, 17 Nov 1999 15:40:47 -0500 (EST) Received: from localhost.epilogue.com ([127.0.0.1]:9489 "EHLO epilogue.com" ident: "IDENT-NOT-QUERIED [port 9489]") by stovokor.epilogue.com with ESMTP id <7786-195>; Wed, 17 Nov 1999 15:40:31 -0500 To: "C. M. Heard/VVNET, Inc." cc: tcp-impl@grc.nasa.gov, Ron Bonica Subject: Re: Usage of packet returned in ICMP error messages In-reply-to: Your message of "Tue, 16 Nov 1999 12:10:30 PST." Date: Wed, 17 Nov 1999 15:40:30 -0500 From: Bill Sommerfeld Message-Id: <19991117204045Z7786-195+3353@stovokor.epilogue.com> Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk A couple comments. It's not clear how this extends to v6; i belive v6 is spec'ed to return signficantly more of the packet than v4. By "first 8 bytes of user data", i assume you're referring to the first 8 bytes of the transport-layer header (the draft seems to be a bit vague). The most crucial thing here (in the first 8 bytes) is the transport-layer ports, which allows the receiver of the icmp datagram to figure out which application-layer entity sent the traffic. however, things are evolving such that the transport layer header isn't necessarily the first thing in the packet.. ip-in-ip tunnelling, ipsec, and v6's salami headers are all going to play havoc with this; i suspect that this is going to confuse host stacks which assume that the entire tail end of the icmp datagram is an excerpt from the packet which didn't make it.. I would go hunting for alternate encapsulation tricks here.. - Bill From owner-tcp-impl@lerc.nasa.gov Sun Nov 21 08:47:00 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09408 for ; Sun, 21 Nov 1999 08:47:00 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA12674 for tcp-impl-outgoing; Sun, 21 Nov 1999 05:47:57 -0500 (EST) Received: from imo-d03.mx.aol.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id FAA12670; Sun, 21 Nov 1999 05:47:55 -0500 (EST) From: Tootie079@aol.com Received: from Tootie079@aol.com by imo-d03.mx.aol.com (mail_out_v24.4.) id a.0.f30b1f80 (4329); Sun, 21 Nov 1999 05:37:48 -0500 (EST) Message-ID: <0.f30b1f80.2569257c@aol.com> Date: Sun, 21 Nov 1999 05:37:48 EST Subject: Hi - I have a good idea MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 27 To: undisclosed-recipients:; Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Sure, you've seen this make money surfing the web stuff, right? Things like alladvantage.com and things like that....well....they're really getting hard to run, because everybody who is, has already signed up for them, you know? Well, have I got the thing for you. This this is primarily like alladvantage.com, HOWEVER you can make a little more on it, and NOBODY has it yet. So now it's time for you to be a kingpin this time, and be at the top of the chain. If you're going to do this, the key is sending to your friends, and to people who are moativated with this, and SYKE them up, and you're bound to do at least decent with this. There are a lot of things you can do, and make a little money once...what I like about this is, you refer people once, and then you just keep making money from it....for good. You really can't go wrong...... So, please, check it out, and if you like it, sign up. Referring people shouldn't be that bad, because basically nobody has this yet. Thanks for your time :-) Click here!< /A> From owner-tcp-impl@lerc.nasa.gov Mon Nov 22 08:52:34 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26876 for ; Mon, 22 Nov 1999 08:52:29 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA08378 for tcp-impl-outgoing; Mon, 22 Nov 1999 05:43:11 -0500 (EST) Received: from post.netchina.com.cn (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA08374 for ; Mon, 22 Nov 1999 05:43:06 -0500 (EST) Received: (qmail 24068 invoked from network); 22 Nov 1999 10:44:27 -0000 Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227) by 202.94.1.48 with SMTP; 22 Nov 1999 10:44:27 -0000 Message-ID: <38391DB0.A8BBF838@netchina.com.cn> Date: Mon, 22 Nov 1999 18:40:50 +0800 From: Robert Tan Reply-To: tjsh@netchina.com.cn Organization: Tan Junsheng X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: The title: Flash Bandwidth 1KHz to 100MHz Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit The title: Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter Dear Sir: This is my discussion article. The details: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc Sincerely, Robert Tan 11.22 Flash Bandwidth 1KHz to 100MHz Digital Controlled Broadband Anti-alias & Reconstruction Filter The Next Era Web of Multimedia Data-stream Transmission Solution of the Internet! By Robert Tan Update: 1999. 11. 22 For the many more format and definite of standard of digital film and video, digital audio and the other multimedia data stream of tomorrow, the existing network technology including the modern internet webs will be fabulous and difficult to transmit it for us. The Endpoint Congestion almost resistant our viewer area full of the entire world, We would need the straightway link of the multi-media data-stream in real-time for us. Would you like to get a lower cost & more effective digital signal channel in a wide-bandwidth or broadband hybrid coax cable system? For the FTTX, HFC networks, especially in the HFC networks with the 256QAM or 64VSB digital modulation technology systems, the SSB-ASK or the VSB-ASK technology transmission systems would be used normally. The Flash Bandwidth 1KHZ to 100MHz digital control a variable frequency bandwidth, it is high-performance anti-alias & reconstruction (FBW) filter, it will be able to provide a variable multiplex sub-frequency band in any broadband HFC system. With the FDM assistant digital carry system and SSB or VSB signal channel, a group of FBW filters will provide separate multi-frequency bands in spectrum without any cross talking and distortion by a large frequency range in a high-speed high- effective transmission system. In a FTTX or HFC web, this digital controlled signal channel would have a very large frequency spectrum changed dynamic range. For a large client group, such as the Broadband Cable Internet Access or HFC users, one of them would like to get a variable data speed according to the applications of his needed. It will provide a lot of digital control frequency bandwidth which is separated one another in HFC transmission system, and it will more effective for the "hot clients", such as the VOD video clients or the other high-code rate users and high-speed data stream user's applications. The FBW will improve the speed of the data stream, diminish the amount of the spare resource seizing of "Cool Clients", reduce the calculations of the DSP processor of the center web main switching system and the branch switching system. Reduce the CPU utilities of the applications in all of client communication adapter and its cost of produce is very important. The "Cool Clients" mains the IP telephone users or the other lower speed code rate audio applications. Anyway, the speed of the up-stream data and down-stream data speed could be changed to any value you needed, and the changing degree will be very smoothly and very simply in writing one or two bytes in the command system of communication web switcher. By the high-speed frequency variable characteristic, if the FBW filter were used in your FTTX or HFC switching system, the upward and downward data stream speed could be managed and attempted by your command system. So that, the transmission bandwidth will be able to adjusted to your needed in any time within one millionth second. The real-time will be very more improved and more effective on the communication main roads such as FTTX and HFC system, transmission controlling system will completely control the data stream in real-time. Dear Technology Research and Development Administrator: I am an electronic engineer in the field of Analog and Digital filters researching and designing. I had been a DSP engineer for ten years. My development field is electronic circuits -- digital and analog hardware designing and researching in applications of Digital Signal Processing. My works contains the frequency spectrum analysis, digital audio and digital video systems, noise spectrum controlling and processing, and the other military applications. I have researched and designed several kind of analog and digital anti-alias & reconstruction filters. A few years before, in my R&D works, I find the special frequency of the filters is usually fixed, it could be very difficult to change the cutoff frequency of the low-pass anti-alias & reconstruction filter. But the fixed filter could not suit the target of my technical applications. If we want to get several special frequency of the filters, we must to use several different fixed filters or instead of fixed filter with switching capacity filter or digital filter, such as IIR or FIR filter, and their frequency must be variable in order to change the analysis frequency. It is very important for the spectrum analysis system and the digital random real time vibrated controlling system. But, in this way, we must pay for digital IIR or FIR filter, it is very expensive in the price, take a large space for the DSP chips and its outside memory banks to install it. So, we would get into much troubles and complex questions from a simple problem. However, we have the switching capacity technologies, and the product of up to 8th order filters is a very normally used. But the switching capacity filter will have a high noise and low frequency range, and it has a non-exactly special frequency, generally. The special frequency of most of the switching capacity filters is from 1/95 to 1/105 times of its main switching clock and it is difficult to improve its accuracy. Actually, the switching capacity filter circuit is very difficult to adjust and use in applications. Anywise, its order is normally below 8th order, and the special frequency and bandwidth of the switching capacity filters is below to 50KHz, and the amplitude response is not exactly yet, the dynamic range of the amplitude is very low, normally, it is below the 48dB. Except of frequency range from 0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not usefully, it is normally being used in the speech processing circuit and the other lower frequency band processing systems. Attention, all of this analysis is not including the phase noise of the main switching clock and the noise of clock feed through yet. The others, it is difficult to get much more analysis frequency bands or special frequency points for the switching capacity filters, it is especially for the higher frequency band which is approached to the top frequency point. All of these characteristics of the switching capacity filters will restrict its applications in the area of modern digital communications. The others method of the filters designing is the contact-time analog filter .I have found some method. It could make many transfer functions. Such as the elliptical function, Chebyshev function and Butterworth function, but there is some interesting things here, it is that the same circuit frame could be built into many transfer functions, and it would have programmable (digital controlled) special frequency. Changing special frequency on line is available. It could get the very wide frequency range, very quickly to change the used band, and the digital controlled circuit is very directly and simply, the special frequency step is very smoothly (because the Frequency is controlled by long bit Digital multiplier). In that points, integrate the FBW filter circuit technology is very useful for the digital controlling and processing systems. Because of the Digital Controlling Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8 or 12 bits long Digital Multiplier and a few chips of high-speed amplifiers. The other, this filter technology is used with a few exactitude resistors and exactitude capacitors also. For example, an 8th order elliptical filter need 8chips of dual Digital Multiplier and several chips high bandwidth amplifiers, 8chips exactitude capacitors and several chips exactitude resisters. If it is possible, integrating all the Digital Multiplier and amplifiers into one chip or one plastic package (mixed circuit), place all the exactitude resistors and capacitors out of the package. It will be finest filter and very easy to used and could be re-designed agilely by the customers and the OEMs. The parameter of the filters is depending on the value of the resistors and the capacitors. Its value could be designed by the customs freely and calculated by constant functions directly, and that is very simply. And then, the FBW filters would be very usefully in the FTTX or HFC networks. For working with the 256QAM or 64VSB modulation technology and any narrow-band transmission technology systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV and VOD systems, it would compress the used frequency bandwidth in mostly extent. Because of the WAN systems in any nations will be depending on the "Tree structures" as the main road in the webs in the future. The frequency source is very expensive in this web, It would be welcomed in the Internet web digital information transmission, exchanging and switching technology area, DSP area and digital communications area, such as MAN and WAN coax cable webs or the FTTX system applications. Any way, the most of modern networking transmission mode is TDM. It is very suitable for the text material or media, because of it is a fixed media in size, and it is the fixed continue time in length and generation procedure. But the most of multimedia is not to be suitable with that. The data stream of voice and video will have no constant size to be forecasted has no constant procedure time. It is only have a constant and fixed bandwidth of media data stream. Because of your interesting points is onto the generations and the procedures of the video or audio information of thus material or the news, such as the high quality digital cinema, digital musicale and so on. Certainly, you could take the any multimedia information and any moving picture on you desktop through the Internet Web. It will be appeared the true alive world with you in any site you can go! So that, the only one of best way of the media data streams transmission and exchanging is the FDM mode with the SSB-ASK or VSB-ASK technology, it should be working with the QAM or VSB- ASK digital modulation technology in the future Internet webs. FBW filter would be used in most of switchers and routers, which is depending on the FDM technologies. For the cable TV systems STB (set top box), video & audio servers in Broadband Cable Internet Access, cable modems or the client-end adapters in the most of family users and the most of business cable users in the world will need a very great deal of broadband web transmission bandwidth. Because of that, in any modern home-electronic equipment, such as the Internet officers, shopping's and the VOD or the other broadband information electronics, its using method would be depending on the FDM switching technologies. So that, the "Online Home-Electronics" or the other Internet accessing products which is used in people's homes would be simply to operate and easy to use. And it must be depend on the simply low-layer hardware equipment and protocols of the webs, such as the VOD systems and the STB terminals in the Broadband Cable Internet Access or HFC networks. The FBW technology would provide us more applicable and useable method in the physics layer of the public HFC networks, its FDM applications in a broadband web get us in a lower building price, more effective than the other technology. Such as the Broadband Cable Internet Access webs, HFC networks, FTTX networks, and the other and the other WAN public broadband networks would have a very great applications of the FBW filters. The others, using a Flash-Band-width filter will help you get in to a fully data stream bandwidth management of any expensive data-link channels and the very expensive communication data stream bandwidth, such as the communication data-link of the satellite communication systems, and the ocean bottom communication systems. FBW filter will control the any leased data-stream bandwidth in dynamic mode within a very large frequency range, a large range of signal frequency bandwidth and data-stream speed in any time for a communication administration and operation system. It will change the bandwidth with you leased data stream very imminently within several microsecond, improve your expensive bandwidth of data-stream transmission channel, save your leased payment and money cost for any customers of digital communications and any Tele-communication operating and service company. It will hold any important transmission of data-stream in smoothly and take it freely. So, in this system, any interrupt of your communication data stream will be never. The Digital Control Flash Bandwidth Filter specifications: (1) General details: Frequency range: 0.1Hz--100MHz Useable frequency range: 0.1Hz--100MHz(at least) Special frequency step: 0.001Hz-1000KHz Transfer functions: Elliptical, Butterworth, Chebyshev, and Bassel function. And the others contacted-time filters. Available filter type: Low-pass filter, High-pass filter, Notch filter, Band-pass filter and All-pass filter. Noise Level: -160dB(max) (Only depend on the number of the used amplifiers.) Order range: 2nd--12th(Depend on the sensitivity of the transfer functions.) Filter switching time: Less than 300nS (Filter Setting time is 200nS) Useful Range: Anti-alias filters, Reconstruction filters. (2) Pass Band Specifications: Frequency selectable range: 100Hz--100MHz (Depend on the performance of the selected amplifiers) Special Frequency steps: 1Hz-1000KHz Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of the filter.) Ripple: 0.01--1.0dB (Only depend on the filter function and the passband ripple designed.) (3) Pass to Stop Band: Drop speed of Interim-band Cut-off: 180db/oct (8th order elliptical function with 0.05dB pass-band ripple) (4) Stop Band: Amplitude min drop: 120db(8th elliptical filter for example) Frequency range: 0.1Hz--100MHz (Depend on the amplifiers and the Digital Multiplier specifications) (5) Digital Control specifications: Digital component is used (8 bit, 10bit, 12bit, and 16bit is available). The special frequency is (N1/N2) * Frequency (ref). (The N1, N2 is the Digital component input byte, from 8bit to 16 bit.) The Frequency (ref) is form 10Hz to 10MHz. (This parameter is depends on one RC time constant.) High speed and voltage feedback high-bandwidth operation amplifiers are required. (6) Requirement: (The filter section of 8th order) Digital component: 8 chips (Selections depend on the frequency range) High-performance Amplifiers: 12 to 24 chips (Selections depend on the frequency) Capacitors or inductors: 8 chips (exactitude degree value is 1% to 0.1%) Resistors: 16-36 chips (exactitude degree value is 1% to 0.1%) (7) Group delay: Depend on the function of the filter designed, filter phase response designed, and the filter order. (8) Filter switching time: Less than 300nS (Filter Setting time is 200nS) The Comparisons of the 4 kinds active Filters For example: 8th order filter Switching Capacity Filter Digital Filter (FIR or IIR Filter) Traditional Fixed Analog Frequency Filter Digital controlling FBW filter Noise Level or (THD+N) Value: Highest -48db Lower -70db Very Low -160db Very Low -120db Filter Dynamic Range The Value: Little 50db Middle 70db Very Large 160db Large 100db Real-time active frequency The range of the value: Narrow 200Hz to 300KHz Wide 0.001Hz to 50KHz Very Wide 0.1Hz to 1MHz Very wide 0.001Hz to 100MHz The Outside in advance Anti-alias & Reconstruction assistant filter requirement The degree of assistant filter Quality Required 2nd to 4th order anti-alias & reconstruction assistant outside filter Required 4th to 6th order anti-alias & reconstruction assistant outside filter Not required. ---------- Not required ---------- The Precision of the special frequency: The ability of on-line changing the filter special frequency &Method Low. +/-3% Very easy (Changing the switching clock) High +/-3% Very difficult (Change a new programs and parameters ) Very high 0.1% Very difficult. (Changing the system time constant) Very high 0.1% Easy(Writing digital word to the filter control port) The complex degree of the filter system designing &The used space Simple Small Very complex Very large Simple Middle Middle Middle The price for produce a filter &The difficult degree of the applications Very low $10~50 Easy Very high $300~600 Difficult Low $30~90 Easy Middle $50~100 Middle Anti-alias & Reconstruction filter Performance: (1)Pass Band Ripple &Dynamic Range: (2)Stop Band Rejection (3)Interim Band Dropping Slope: Low Quality & Low Price. +/-0.2db 50db 55db 50db/oct Normal or High Quality & High price +/-0.01db 70db 70db 130db/oct Normal Quality & Low Price +/-0.01db 120db 120db 180db/oct High Quality & & Middle Price. +/-0.01db 110db 120db 180db/oct Online/offline Changing of highest/lowest special frequency rate & Range: &changing time: All available 1000 times 300Hz to 300KHz 10mS(Time of PLL tracking & locked) Offline available Not available Not available Not available (Reboot DSP & A/D system) Offline available 1000 times Not available Not available All available 100000 times 1KHz to 100MHz 160nS (TTL 2 bytes writing time) Filter online reconstruction setting time (The total time of filter frequency switched) 10mS Not available Not available 300nS Group delay and the phase response: Producer design only. Linear or Producer design only. Producer design only. Producer & User design is available. Equality data stream speed or comported speed of its TxDAC : &Butterworth 8th filter (Broadband channel HFC usable signal dynamic range is about 50dB): 4.8Kbps to 4.8Mbps (600SPS to 600KSPS) 8bit TxDAC Constant 400Kbps (50KSPS) 8bit TxDAC Constant 800Mbps (100MSPS) 8bit TxDAC 16Kbps to 1600Mbps (2KSPS to 200MSPS) 8bit TxDAC Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in SSB/VSB mode of technology (Data speed of Base Band): Carrier signal RF full-band tie up: Difficult to be used with the 256QAM and 64VSB. (High Level Phase Noise) 4.8Kbps(Min) 4.8Mbps(Max) 384Hz to 384KHz Difficult to be used in variable data-speed transmission or receiving system Difficult to be used in variable data-speed transmission or receiving system With 256QAM: 8Kbps(Min) 800Mbps (Max) With 64VSB: 12Kbps(Min) 1200Mbps (Max). 1.28KHz to 128MHz For the HFC Specialty signal TV Channel: 40dB Eb/N 6MHz Full-band 64VSB model @1KHz-6MHz Data-rate: With 64VSB: 9.375Kbps (Min) 56.25Mbps (Max) Contact Address: No.2 Buliding Room1007, Mudanyuan Beili, Haidian District Beijing P. R. China, Post Code: 100083 Name: Tan Junsheng (Robert Tan) Tele: 8610-82076834, 86-13701070213(Mobile) E-mail: Tjsh@netchina.com.cn or tanjun@hotmail.com Homepage: http://www.cnindex.net/~tjsh Details Remind: http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html From owner-tcp-impl@lerc.nasa.gov Mon Nov 29 20:04:51 1999 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06836 for ; Mon, 29 Nov 1999 20:04:50 -0500 (EST) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA15432 for tcp-impl-outgoing; Mon, 29 Nov 1999 16:53:54 -0500 (EST) Received: from mailhost.iprg.nokia.com (fw01.lerc.nasa.gov [139.88.145.14]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id QAA15428 for ; Mon, 29 Nov 1999 16:53:52 -0500 (EST) Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id NAA25778 for ; Mon, 29 Nov 1999 13:53:47 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id NAA06916 for tcp-impl@lerc.nasa.gov; Mon, 29 Nov 1999 13:53:47 -0800 (PST) Date: Mon, 29 Nov 1999 13:53:47 -0800 (PST) Message-Id: <199911292153.NAA06916@vienna.iprg.nokia.com> To: tcp-impl@lerc.nasa.gov Subject: INFOCOM 2000 Call For Participation Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk CALL FOR PARTICIPATION ----------------------------------------------------------- | | | ### # # ####### ####### ##### ####### # # | | # ## # # # # # # # # ## ## | | # # # # # # # # # # # # # # | | # # # # ##### # # # # # # # # | | # # # # # # # # # # # # | | # # ## # # # # # # # # # | | ### # # # ####### ##### ####### # # | | | | | \ ##### ### ### ### / \ # # # # # # # # / \ # # # # # # # / \ ##### # # # # # # / \ # # # # # # # / \ # # # # # # # / \ ####### ### ### ### / \ / ------------------------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make hotel reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty for defraying some of the costs of presenting a paper in the conference will be available. Please refer to the conference web sites for further details later this year. http://www.comnet.technion.ac.il/infocom2000/grants.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il]