From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 4 16:19:11 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09423 for ; Fri, 4 Sep 1998 16:19:11 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA01601 for <@deliverator.sgi.com:tcpimpl-archive@ietf.org>; Fri, 4 Sep 1998 13:17:43 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:tcpimpl-archive@ietf.org> id NAA07380; Fri, 4 Sep 1998 13:19:12 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA06755 for <@sgi.engr.sgi.com:tcpimpl-archive@ietf.org>; Fri, 4 Sep 1998 13:19:12 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA54003; Fri, 4 Sep 1998 13:19:11 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Date: Fri, 4 Sep 1998 13:19:11 -0700 (PDT) Message-Id: <199809042019.NAA54003@cthulhu.engr.sgi.com> To: tcpimpl-archive@ietf.org From: Majordomo@cthulhu.engr.sgi.com Subject: Welcome to tcp-impl Reply-To: Majordomo@cthulhu.engr.sgi.com -- Welcome to the tcp-impl mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe tcp-impl or from another account, besides tcpimpl-archive@ietf.org: unsubscribe tcp-impl tcpimpl-archive@ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: The owner of this list (tcp-impl) is fisher@engr.sgi.com. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 4 16:45:14 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09841 for ; Fri, 4 Sep 1998 16:45:14 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA06779 for <@deliverator.sgi.com:tcpimpl-archive@odin.ietf.org>; Fri, 4 Sep 1998 13:43:46 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:tcpimpl-archive@odin.ietf.org> id NAA14860; Fri, 4 Sep 1998 13:45:11 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA05903 for <@sgi.engr.sgi.com:tcpimpl-archive@lists.ietf.org>; Fri, 4 Sep 1998 13:45:10 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA46346; Fri, 4 Sep 1998 13:45:10 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Date: Fri, 4 Sep 1998 13:45:10 -0700 (PDT) Message-Id: <199809042045.NAA46346@cthulhu.engr.sgi.com> To: tcpimpl-archive@ietf.org From: Majordomo@cthulhu.engr.sgi.com Subject: Welcome to tcp-impl Reply-To: Majordomo@cthulhu.engr.sgi.com -- Welcome to the tcp-impl mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, you can send mail to with the following command in the body of your email message: unsubscribe tcp-impl or from another account, besides tcpimpl-archive@lists.ietf.org: unsubscribe tcp-impl tcpimpl-archive@lists.ietf.org If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: The owner of this list (tcp-impl) is fisher@engr.sgi.com. From owner-tcp-impl@cthulhu.engr.sgi.com Sun Sep 6 03:31:03 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA00816 for ; Sun, 6 Sep 1998 03:31:02 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA28176; Sun, 6 Sep 1998 00:29:13 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id AAA27887; Sun, 6 Sep 1998 00:30:36 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00362; Sat, 5 Sep 1998 12:26:40 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA47724 for tcp-impl-list; Sat, 5 Sep 1998 12:20:24 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA98370 for ; Sat, 5 Sep 1998 12:20:22 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00478 for ; Sat, 5 Sep 1998 12:20:21 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA17911; Sat, 5 Sep 1998 12:20:21 -0700 (PDT) Date: Sat, 5 Sep 1998 12:18:25 -0700 From: braden@ISI.EDU Posted-Date: Sat, 5 Sep 1998 12:18:25 -0700 Message-Id: <199809051918.AA03039@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Sat, 5 Sep 1998 12:18:25 -0700 To: perry@piermont.com, aron@cs.rice.edu, rstevens@kohala.com Subject: Re: status of T/TCP Cc: tcp-impl@cthulhu.engr.sgi.com Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk [This is the wrong list for this discussion, in my opinion. But I cannot resist saying...] The first time I read this document, and again upon re-reading it, I found its logic a little strange. It seems to be summarized in two points: (1) T/TCP is no more insecure than TCP is already, except (2) in those cases where T/TCP gives better performance than TCP (eg avoiding TW state), this performance improvement is undersirable because it allows makes denial-of-service attacks easier. Hey, I have a GREAT idea: let's set TCP's TW delay to 10 hours, to increase TCP security. Bob Braden From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 10:14:03 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA03269 for ; Tue, 8 Sep 1998 10:14:02 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id HAA29961; Tue, 8 Sep 1998 07:12:23 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id HAA17666; Tue, 8 Sep 1998 07:14:01 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA04540; Tue, 8 Sep 1998 07:13:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA93820 for tcp-impl-list; Tue, 8 Sep 1998 07:02:53 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA15171 for ; Tue, 8 Sep 1998 07:02:48 -0700 (PDT) mail_from (perry@jekyll.piermont.com) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA04526 for ; Tue, 8 Sep 1998 07:02:47 -0700 (PDT) mail_from (perry@jekyll.piermont.com) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id KAA17435; Tue, 8 Sep 1998 10:02:25 -0400 (EDT) Message-Id: <199809081402.KAA17435@jekyll.piermont.com> To: braden@ISI.EDU cc: perry@piermont.com, aron@cs.rice.edu, rstevens@kohala.com, tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP In-reply-to: Your message of "Sat, 05 Sep 1998 12:18:25 PDT." <199809051918.AA03039@gra.isi.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Sep 1998 10:02:25 -0400 From: "Perry E. Metzger" Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk braden@ISI.EDU writes: > > [This is the wrong list for this discussion, in my opinion. But I > cannot resist saying...] > > The first time I read this document, and again upon re-reading it, I > found its logic a little strange. It seems to be summarized in two > points: (1) T/TCP is no more insecure than TCP is already, No, it claims (correctly) that the lack of a three way handshake makes T/TCP substantially less secure than TCP is already. I believe that is the point. Perry From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 10:49:32 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA04198 for ; Tue, 8 Sep 1998 10:49:31 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id HAA06663; Tue, 8 Sep 1998 07:47:53 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id HAA24824; Tue, 8 Sep 1998 07:49:32 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA03569; Tue, 8 Sep 1998 07:49:23 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA67974 for tcp-impl-list; Tue, 8 Sep 1998 07:42:33 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA29061 for ; Tue, 8 Sep 1998 07:42:31 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: from lunacity.ne.mediaone.net (lunacity.ne.mediaone.net [24.128.118.236]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA05977 for ; Tue, 8 Sep 1998 07:42:30 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: (from mycroft@localhost) by lunacity.ne.mediaone.net (8.8.8/8.8.8) id KAA02756; Tue, 8 Sep 1998 10:43:20 -0400 (EDT) Date: Tue, 8 Sep 1998 10:43:20 -0400 (EDT) Message-Id: <199809081443.KAA02756@lunacity.ne.mediaone.net> From: "Charles M. Hannum" To: braden@ISI.EDU Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I think it's a shame that you have to get emotional about it, Bob. My draft was not an emotional piece of work; it simply (and quite dryly) presents a number of ways to abuse T/TCP that are not possible with a normal TCP implementation, and points out an interoperability issue. Whether or not these concerns are truly significant wasn't the issue I was presenting when I wrote it. I do, however, find it interesting that one of the holes was actually used to break into machines. I believe this suggests that people should not simply turn up their noses (as you did) when someone publishes a paper that puts their pet project in a bad light. Had you actually read the paper carefully and reviewed your implementation, that hole could have been fixed a long time before it was ever abused. Your response instead seemed childish and irresponsible. As for your particular points: 1) There *are* cases in which the r-utilities are secure with TCP, where they are not with T/TCP. This is basically any environment where only `internal' addresses are permitted to establish connections. With normal TCP, the responses would never be routed to the outside world, and so it would be impossible to do anything; with T/TCP, you only need one packet. So saying `T/TCP is no more insecure than TCP is already' is simply fallacious. 2) Denial of service attacks are a serious issue and cannot simply be ignored. If you really believe you can dismiss this out of hand, tell that to all the service operators who were completely screwed by SYN flood attacks a year or so ago, and imagine it 10x worse. (There are also some more subtle and much more devastating denial of service attacks that I didn't mention in the draft.) I never once said `this performance improvement is undesirable'; I did not in any way attack that (laudable) goal. However, your arrogant dismissal of the issues seems to me to cast doubt on your credibility. From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 11:50:06 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA06452 for ; Tue, 8 Sep 1998 11:50:05 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA20428; Tue, 8 Sep 1998 08:48:05 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id IAA12704; Tue, 8 Sep 1998 08:49:43 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA05847; Tue, 8 Sep 1998 08:49:33 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA55241 for tcp-impl-list; Tue, 8 Sep 1998 08:42:51 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA84070 for ; Tue, 8 Sep 1998 08:42:49 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: from lunacity.ne.mediaone.net (lunacity.ne.mediaone.net [24.128.118.236]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA00334 for ; Tue, 8 Sep 1998 08:42:48 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: (from mycroft@localhost) by lunacity.ne.mediaone.net (8.8.8/8.8.8) id LAA02918; Tue, 8 Sep 1998 11:43:39 -0400 (EDT) Date: Tue, 8 Sep 1998 11:43:39 -0400 (EDT) Message-Id: <199809081543.LAA02918@lunacity.ne.mediaone.net> From: "Charles M. Hannum" To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk BTW, on review, I believe the `sequence number attacks' section is actually irrelevant. The comment about TIME-WAIT state is incorrect, because TIME-WAIT can be assassinated even with normal TCP. This causes the entire logic of the argument to fall apart. It's also the case that this is only really relevant for applications using host-based authorization, which should be disabling T/TCP for the other reasons I mentioned. (I actually noticed this once before, but due to the distinct lack of feedback I never updated the draft.) So, let's assume for a moment that there are correct implementations resolving the concerns mentioned in sections 2 (`Host-Based Authorization') and 4 (`Pre-SYN Queueing'), and that section 5 (`Sequence Number Attacks') is simply discarded. That still leaves the concerns in section 3 (`SYN flooding') and 6 (`Conclusions'). I could easily give on the interoperability problem mentioned in section 6. It's specifically the client using T/TCP and connecting to an old server that causes the problem. It doesn't matter whether or not a server uses T/TCP. So this problem isn't particularly relevant to service operators. However, the potential for denial of service attacks is still real, and I don't see any way around it. Now, I expect at this point someone will simply fire up a stupid SYN flooding engine and claim that nothing happened. So I will explain a simple scenario that your SYN flooding tool didn't exercise, but which will completely hose your server: * Say you have a CGI script that takes 1 second of real time to load. Lots of sites -- especially ones with fancy shopping carts and whatnot -- have a plethora of these. * Now say I flood you at a pretty slow rate, perhaps 11 packets every 10 seconds, with requests that exercise this particular CGI script. Since we're using T/TCP, I only need 1 packet per probe to do this, and I never have to see the replies. * In not too much time at all, I'll have hundreds of httpd processes on your machine stuck waiting for this damned CGI script, and not processing any real requests. * Your customers get pissed off. Scale the numbers to suit your CGI scripts, of course. It doesn't matter; the point is still the same. From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 12:10:38 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA07297 for ; Tue, 8 Sep 1998 12:10:37 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id JAA25713; Tue, 8 Sep 1998 09:08:53 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA19999; Tue, 8 Sep 1998 09:10:27 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08192; Tue, 8 Sep 1998 09:10:18 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA34336 for tcp-impl-list; Tue, 8 Sep 1998 09:03:43 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA22459 for ; Tue, 8 Sep 1998 09:03:41 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: from lunacity.ne.mediaone.net (lunacity.ne.mediaone.net [24.128.118.236]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA05824 for ; Tue, 8 Sep 1998 09:03:40 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: (from mycroft@localhost) by lunacity.ne.mediaone.net (8.8.8/8.8.8) id MAA03009; Tue, 8 Sep 1998 12:04:33 -0400 (EDT) Date: Tue, 8 Sep 1998 12:04:33 -0400 (EDT) Message-Id: <199809081604.MAA03009@lunacity.ne.mediaone.net> From: "Charles M. Hannum" To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > * In not too much time at all, I'll have hundreds of httpd processes > on your machine stuck waiting for this damned CGI script, and not > processing any real requests. > > * Your customers get pissed off. In case it wasn't blindingly obvious to everyone, the punchline is: Because you're using T/TCP, I can submit these 1-packet probes with totally random (or very pointedly non-random) source IP addresses, so you can't filter them out by source. I can randomize the data in the query a bit and make it very difficult -- perhaps even impossible -- for you to filter out the requests based on data. In short, I can potentially make it impossible for you to prevent this attack from happening. And the reason I can do this is because you're using T/TCP. If you were using TCP, this wouldn't be possible. I *think* we could actually fix this, by using some sort of exchange in the first connection (which always does a full 3WHS to initialize the connection count) and a hashing mechanism similiar to RFC-1948 to ensure that future SYN-data-FIN packets came from the same source as the initial connection request (or at worst a snooper in between). This would effectively restore the `security' (in this case, really the *accountability*) of normal TCP. I haven't worked out the details, but it seems emminently doable. And I think that's enough mail for this morning. From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 12:34:06 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA08397 for ; Tue, 8 Sep 1998 12:34:05 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id JAA02278; Tue, 8 Sep 1998 09:31:48 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA28885; Tue, 8 Sep 1998 09:33:27 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04318; Tue, 8 Sep 1998 09:33:17 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA38474 for tcp-impl-list; Tue, 8 Sep 1998 09:27:25 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA69021 for ; Tue, 8 Sep 1998 09:27:23 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07774 for ; Tue, 8 Sep 1998 09:27:22 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA20893; Tue, 8 Sep 1998 09:27:21 -0700 (PDT) Date: Tue, 8 Sep 1998 09:25:27 -0700 From: braden@ISI.EDU Posted-Date: Tue, 8 Sep 1998 09:25:27 -0700 Message-Id: <199809081625.AA06024@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Tue, 8 Sep 1998 09:25:27 -0700 To: braden@ISI.EDU, mycroft@mit.edu Subject: Re: status of T/TCP Cc: tcp-impl@cthulhu.engr.sgi.com Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Charles, Gosh, thanks. It is not very often that I am honored by someone from MIT calling me "arrogant". Actually, the discussion I wanted to have concerns protocol architecture, something like: "is it necessary, reasonable, and desirable for the TCP 3 way handshake sequence number synchronization mechanism to be an essential security mechanism?" But as this is the wrong list, I will say no more on this subject here. Bob Braden From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 13:17:35 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA10222 for ; Tue, 8 Sep 1998 13:17:34 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA15525; Tue, 8 Sep 1998 10:15:07 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA17418; Tue, 8 Sep 1998 10:16:46 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA03273; Tue, 8 Sep 1998 10:16:34 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA33224 for tcp-impl-list; Tue, 8 Sep 1998 10:08:38 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA46839 for ; Tue, 8 Sep 1998 10:08:36 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06511 for ; Tue, 8 Sep 1998 10:08:34 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id LAA05457 for tcp-impl@cthulhu.engr.sgi.com env-from ; Tue, 8 Sep 1998 11:08:33 -0600 (MDT) Date: Tue, 8 Sep 1998 11:08:33 -0600 (MDT) From: Vernon Schryver Message-Id: <199809081708.LAA05457@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: "Charles M. Hannum" > ... > I *think* we could actually fix this, by using some sort of exchange > in the first connection (which always does a full 3WHS to initialize > the connection count) and a hashing mechanism similiar to RFC-1948 to > ensure that future SYN-data-FIN packets came from the same source as > the initial connection request (or at worst a snooper in between). > This would effectively restore the `security' (in this case, really > the *accountability*) of normal TCP. > > I haven't worked out the details, but it seems emminently doable. Yes, but why bother? Instead of inventing yet another mechanism to keep state above T/TCP, why not simply modify the application protocol to use TCP? Why not arrange to pay the price of the 3-way handshake/A&A once, and then re-use the TCP connection for several transactions? I've long liked the idea of reducing the number of packets in the TCP 3-way handshake. (It was one of the selling points of XTP). However, your point about the utility of delaying committing significant resources until at least one round-trip of packets has at least somewhat verified the identity of the peer is very interesting. Besides your notion of some kind of hashing/pre-reservation, you might do something in you HTTP server example such as start the HTTP query for requests that arrived by T/TCP, but perpare to abandon it early. Either: 1. respond to the initial T/TCP packet by both starting the query and sending a window-probe-style TCP segment to the client. If the client does not respond quickly (say <1 sec), abort the query. Yes, this sounds like it would require violations of various layering religions. 2. limit the total number of processes doing work for T/TCP requests that have not been ACK'd. If the system gets load, drop a random request, much like the random-drop defense to SYN attacks. This could not be distinguished by clients from ordinary packet losses, and so would be harmless, except for the work wasted before request is dropped. I think this should not offend the layering priests except in concept, since it would require no hacks in the stack. Still, why bother? Never mind newer versions of HTTP. What benefit does T/TCP give, other than a speed-up by one RTT of the initial response? Since all HTTP clients now use more than one TCP connection, delays for 3-way handshakes after the first are insignificant, aren't they? Given commerical HTTP servers that can server more hits/second than you can buy Internet bandwidth no matter what your budget, there doesn't seem much that T/TCP can do for servers. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 16:30:41 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA14546 for ; Tue, 8 Sep 1998 16:30:40 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA06669; Tue, 8 Sep 1998 13:27:30 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id NAA21380; Tue, 8 Sep 1998 13:29:09 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA08062; Tue, 8 Sep 1998 13:28:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA96870 for tcp-impl-list; Tue, 8 Sep 1998 13:22:48 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA20838 for ; Tue, 8 Sep 1998 13:22:46 -0700 (PDT) mail_from (rstevens@kohala.kohala.com) Received: from kalae.kohala.com (kalae.kohala.com [216.19.23.35]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA03550 for ; Tue, 8 Sep 1998 13:22:35 -0700 (PDT) mail_from (rstevens@kohala.kohala.com) Received: from kohala.kohala.com (kohala.kohala.com [216.19.23.33]) by kalae.kohala.com (8.9.0/8.9.0) with ESMTP id NAA21876; Tue, 8 Sep 1998 13:22:29 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id NAA21583; Tue, 8 Sep 1998 13:22:28 -0700 (MST) Message-Id: <199809082022.NAA21583@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 8 Sep 1998 13:22:28 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: "Charles M. Hannum" , tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk [In your message of Sep 8, 12:04pm you write:] > > In case it wasn't blindingly obvious to everyone, the punchline is: > Because you're using T/TCP, I can submit these 1-packet probes with > totally random (or very pointedly non-random) source IP addresses, so > you can't filter them out by source. But these 1-packet probes with random source addresses are not passed to the application *until* the 3WHS is completed, assuming that these random source addresses have not had previous connections with this server that have initialized the CC for this client. And if you use random source address, the 3WHS will never complete. So to launch these attacks you minimally have to come from a host that supports T/TCP and you must use your own source IP. Rich Stevens From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 8 19:39:37 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA17220 for ; Tue, 8 Sep 1998 19:39:37 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA21096; Tue, 8 Sep 1998 16:35:46 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id QAA21785; Tue, 8 Sep 1998 16:37:26 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02068; Tue, 8 Sep 1998 16:37:06 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA87456 for tcp-impl-list; Tue, 8 Sep 1998 16:30:35 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA53356 for ; Tue, 8 Sep 1998 16:30:33 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: from lunacity.ne.mediaone.net (lunacity.ne.mediaone.net [24.128.118.236]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02947 for ; Tue, 8 Sep 1998 16:30:32 -0700 (PDT) mail_from (mycroft@lunacity.ne.mediaone.net) Received: (from mycroft@localhost) by lunacity.ne.mediaone.net (8.8.8/8.8.8) id TAA04039; Tue, 8 Sep 1998 19:31:10 -0400 (EDT) Date: Tue, 8 Sep 1998 19:31:10 -0400 (EDT) Message-Id: <199809082331.TAA04039@lunacity.ne.mediaone.net> From: "Charles M. Hannum" To: rstevens@kohala.com (W. Richard Stevens) Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk >> In case it wasn't blindingly obvious to everyone, the punchline is: >> Because you're using T/TCP, I can submit these 1-packet probes with >> totally random (or very pointedly non-random) source IP addresses, so >> you can't filter them out by source. > > But these 1-packet probes with random source addresses are not passed > to the application *until* the 3WHS is completed, assuming that these > random source addresses have not had previous connections with this > server that have initialized the CC for this client. And if you use > random source address, the 3WHS will never complete. So to launch > these attacks you minimally have to come from a host that supports > T/TCP and you must use your own source IP. That turns out not to be the case, for two reasons: 1) The existing implementation creates the TAO cache before the first 3WHS has completed. 2) C.f. `very pointedly non-random'. Say I pick source addresses of known customers, or known data providers, instead. With T/TCP, I don't have to know the port numbers they used in previous connections, because the TAO cache applies to all connections from that particular machine; all I have to know is that they're likely to be in the TAO cache. There are some very subtle aspects to #2. For example, say you have something that automatically detects this sort of attack and filters out that client. Besides the potential for annoying real customers, this has other effects. One such attack would be to get you to automatically filter out known search engine robots, so your site never appears on them. It's likely that you wouldn't even notice this, and you'd just lose hits (read: potential revenue) without ever knowing why. (And, of course, in most cases I could just keep round-robining between a number of known addresses. You can't filter out everything; eventually you'd have to start doing aggregate filtering or timing out old entries...) The idea may be digusting to some people (and I confess that it churns my own stomach a bit), but the 3WHS really does provide a certain amount of accountability that is important for maintaining a clean neighborhood. I think a fix for this is as simple as: * Send a random cookie in the CC.NEW. * Return the cookie in the CC. * If the received cookie doesn't match the cached (sent) cookie, fall back to a 3WHS and reinitialize the TAO cache. This increases the size of the CC.NEW/CC options slightly, but should not have any significant impact on performance. It is incompatible with the old CC.NEW/CC options, but it's not as if they're widely deployed anyway. From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 9 11:08:18 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA02753 for ; Wed, 9 Sep 1998 11:08:17 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA05961; Wed, 9 Sep 1998 08:05:12 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id IAA14792; Wed, 9 Sep 1998 08:06:51 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA02295; Wed, 9 Sep 1998 08:06:36 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA19384 for tcp-impl-list; Wed, 9 Sep 1998 07:59:56 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA08464 for ; Wed, 9 Sep 1998 07:59:54 -0700 (PDT) mail_from (dab@frantic.bsdi.com) Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA05816 for ; Wed, 9 Sep 1998 07:59:52 -0700 (PDT) mail_from (dab@frantic.bsdi.com) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id JAA29280 for tcp-impl@cthulhu.engr.sgi.com; Wed, 9 Sep 1998 09:59:50 -0500 (CDT) Date: Wed, 9 Sep 1998 09:59:50 -0500 (CDT) From: David Borman Message-Id: <199809091459.JAA29280@frantic.bsdi.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I wasn't going to step into the T/TCP discussion, but it has gone on long enough that if people are thinking at all seriously about T/TCP, then I should. Several years ago I studied the T/TCP protocol, and decided that it was more complicated than it needed to be. I'm attaching the message that I sent out to the end2end-interest mailing list in 1996. And before people start jumping up and down, yes, I know that this doesn't address any of the spoofing issues. But if people are thinking about changing T/TCP to address security issues, I'd like to change T/TCP to simplify the CC processing at the same time. -David Borman, dab@bsdi.com > From dab Wed Mar 13 15:08:54 1996 > To: braden@ISI.EDU > Subject: T/TCP & CC processing > Cc: end2end-interest@ISI.EDU > > > Hello all. > > This message is a follow up to what I brought up at the T/TCP > BOF in LA about an alternate method for validating CC values. > > This proposal does several things: > 1) It eliminates the need for the CC.NEW option, the > client only sends the CC option. > 2) Allows the first SYN/CC that is received from > any host to be accepted without waiting for the > 3-way handshake to complete, which means that a > stream of in-sequence T/TCP requests can be processed > without forcing any of them to wait for the 3-way > handshake to complete. > 3) It simplifies the CC processing at both ends. > > Background > ---------- > > The goal of the cache of CC values is to be able to identify > incoming SYN packets that are valid, so that the data in them > can be processed immediately via the TCP Accelerated Open (TAO) > mechanism, which passes the data up to the application without > waiting for the three way handshake to complete. Or, more precisely, > we want to identify SYN packets that might be old SYN packets > and not process the data until we have verified the connection > by completing the 3-way handshake. > > There are two ways that a duplicate SYN can arrive. Either > somewhere along the path the packet was duplicated, or else > the source has retransmitted the SYN packet. In the first > case, the duplicate should be received within one MSL, of > the first SYN, since after one MSL it should be discarded. > As long as the connection created by the original MSL exists > at least one MSL, it will catch any duplicated SYNs. In the > second case, if the response comes in just after the SYN is > retransmitted, as long as the control block exists at least > one MSL before going away, the retransmitted SYN will be > caught by the control block. Since the control block has > to go through TIME-WAIT, it will be around at least 2 MSL. > It should also be noted that while the source is retransmitting > SYNs, it means that the connection at the receiver, once one > of the SYNs has gotten through, will persist until the source > has gotten back a response, meaning that the control block > at the receiver will take care of any duplicate SYNs. > > When the first SYN packet from host A arrives at host B, it will > always be a valid SYN. If it was not a valid SYN, then that means > that host A has destroyed the connection in less than the MSL > after sending out the SYN, which should not happen. > > Additionally, when there have been no SYN packets from a host for > more than an MSL, the next SYN will be a valid SYN, since all old > duplicate SYN will have exited the network. > > From this it can be implied that if the server remembers the time > that the last SYN/CC was received, then if when the next SYN/CC > arrives is more than an MSL, it should be a valid SYN/CC, whether > or not the CC passes the check. > > Proposal for processing the CC option > ------------------------------------- > > The server maintains a table of HOST, CC and CLOCK values. The CLOCK > is when CC was received from HOST. If a CC arrives for a HOST that is > not in the table and there are empty slots in the table, TAO can be > used, and HOST and CC are added to the table with CLOCK = CURRENT_CLOCK. > If there is an entry, but it is more than 2 MSL old, the entry can be > ignored and treated as if it wasn't in the table. > > There is a table for cached CC information. Each entry contains: > TABLE[n].HOST > TABLE[n].CC > TABLE[n].CLOCK > > In addition, there are two values: > OLD_CLOCK > CURRENT_CLOCK > > At start up: > OLD_CLOCK = CURRENT_CLOCK > > SYN/CC arrives from : > > > if there exists a table entry TABLE[n] such that TABLE[n].HOST == SEG.SRC > then > if SEG.CC > TABLE[n].CC or CURRENT_CLOCK - TABLE[n].CLOCK > 2 MSL > then > TABLE[n].CC = SEG.CC > TAO = OK > else > TAO = NOT_OK > endif > > TABLE[n].CLOCK = CURRENT_CLOCK. > > else SEG.SRC is not in the table > > if CURRENT_CLOCK - OLD_CLOCK > 2 MSL then > TAO = OK > else > TAO = NOT_OK > endif > > Find an empty entry in the table. > > if there is no empty entry, then > Find the oldest entry in the table. > OLD_CLOCK = TABLE[n].CLOCK > endif > > TABLE[n].CLOCK = CURRENT_CLOCK > TABLE[n].CC = SEG.CC > TABLE[n].HOST = SEG.SRC > endif > > > A few observations on the algorithm > ----------------------------------- > > 1) Setting OLD_CLOCK = CURRENT_CLOCK at startup time forces > all new connections to do a full 3-way handshake until the > host has been up long enough for any old SYNs that were > floating around in the network to trickle in. > > 2) You only need to maintain the CC cache for hosts from > which SYN/CCs have sent within the last MSL. > > 3) The timeout period must be between 1 MSL and 2 MSL. > 1 MSL is the lower bound, because that is how long > duplicates can be floating around. 2 MSL is the > upper bound, because CC values can wrap anytime > after 2 MSL. > > 4) Once a SYN arrives and a control block is created, that > control block will exist until any retransmitted or > duplicate SYNs have either arrived or timed out in the > network. > > 5) Because of #4, the CC cache code is only used when a SYN > arrives and there does not already exist a connection for > that SYN. > > 6) The current RFC is not at-most-one, and this proposal > neither strengthens or weakens that situation. > > -David Borman, dab@bsdi.com > From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 9 13:17:12 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA07420 for ; Wed, 9 Sep 1998 13:17:12 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA23512; Wed, 9 Sep 1998 10:14:41 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA09963; Wed, 9 Sep 1998 10:16:23 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA08336; Wed, 9 Sep 1998 10:16:06 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA26444 for tcp-impl-list; Wed, 9 Sep 1998 10:10:07 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA27776 for ; Wed, 9 Sep 1998 10:10:05 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06417 for ; Wed, 9 Sep 1998 10:10:04 -0700 (PDT) mail_from (vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.9.1/8.9.1) id KAA07546; Wed, 9 Sep 1998 10:10:04 -0700 (PDT) Message-Id: <199809091710.KAA07546@daffy.ee.lbl.gov> To: tcp-impl@cthulhu.engr.sgi.com Subject: moving the "status of T/TCP" discussion Date: Wed, 09 Sep 1998 10:10:04 PDT From: Vern Paxson Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Since this thread has mutated from implementation issues to protocol issues, I'd like to ask that further discussion occur on end2end-interest. For those not on that list, you can join via email to (I think) end2end-interest-request@isi.edu. Vern From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 9 13:39:28 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA07899 for ; Wed, 9 Sep 1998 13:39:28 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA01202; Wed, 9 Sep 1998 10:36:20 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA19655; Wed, 9 Sep 1998 10:38:02 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06309; Wed, 9 Sep 1998 10:37:45 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA49330 for tcp-impl-list; Wed, 9 Sep 1998 10:27:55 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA48080 for ; Wed, 9 Sep 1998 10:27:53 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA01488 for ; Wed, 9 Sep 1998 10:27:51 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA13334; Wed, 9 Sep 1998 10:27:49 -0700 (PDT) Date: Wed, 9 Sep 1998 10:25:51 -0700 From: braden@ISI.EDU Posted-Date: Wed, 9 Sep 1998 10:25:51 -0700 Message-Id: <199809091725.AA08524@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Wed, 9 Sep 1998 10:25:51 -0700 To: tcp-impl@cthulhu.engr.sgi.com, vern@ee.lbl.gov Subject: Re: moving the "status of T/TCP" discussion Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk *> From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 9 10:15:04 1998 *> To: tcp-impl@cthulhu.engr.sgi.com *> Subject: moving the "status of T/TCP" discussion *> Date: Wed, 09 Sep 1998 10:10:04 PDT *> From: Vern Paxson *> Sender: owner-tcp-impl@cthulhu.engr.sgi.com *> Precedence: bulk *> Content-Length: 250 *> X-Lines: 6 *> *> Since this thread has mutated from implementation issues to protocol *> issues, I'd like to ask that further discussion occur on end2end-interest. *> For those not on that list, you can join via email to (I think) *> end2end-interest-request@isi.edu. *> *> Vern *> Majordomo@isi.edu Bob Braden From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 11 09:19:52 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19571 for ; Fri, 11 Sep 1998 09:19:51 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id GAA15311; Fri, 11 Sep 1998 06:16:25 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id GAA09773; Fri, 11 Sep 1998 06:17:56 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA04656; Fri, 11 Sep 1998 06:17:43 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA14644 for tcp-impl-list; Fri, 11 Sep 1998 06:07:01 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA35473 for ; Fri, 11 Sep 1998 06:06:53 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA02236 for ; Fri, 11 Sep 1998 06:06:52 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id JAA22428; Fri, 11 Sep 1998 09:06:46 -0400 (EDT) Received: from guns by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id JAA06298; Fri, 11 Sep 1998 09:06:46 -0400 (EDT) Message-Id: <199809111306.JAA06298@guns.lerc.nasa.gov> To: tcp-impl@cthulhu.engr.sgi.com Cc: "Vern Paxson" From: Mark Allman Reply-To: mallman@lerc.nasa.gov Subject: NewReno and the 2001 Revision Organization: Late Night Hackers, NASA Lewis, Cleveland, Ohio Song-of-the-Day: For What It's Worth Date: Fri, 11 Sep 1998 09:06:45 -0400 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk We would like to hear some feedback on what sorts of loss recovery mechanisms the working group thinks are appropriate for inclusion in the revision of RFC 2001. As Sally outlined in Chicago, there are several improvements we can make to Reno style TCP (i.e., TCP without SACK). Our current opinion is that some form of the NewReno changes (as was obvious in the meeting, there are a number of permutations of NewReno) should be included in a seperate experimental document. However, as Sally outlined in the meeting and it her note to this list shortly after, there is also a seperate issue of fixing a fairly well known TCP bug (misfeature?). The bug occurs when multiple fast retransmits happen for multiple lost segments within a window of data and consequently cwnd is halved multiple times for one ``congestion event''. We would like to hear comments on whether or not such a bug fix should be included in the 2001 revision. Thanks, Mark and Vern From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 11 09:45:29 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19990 for ; Fri, 11 Sep 1998 09:45:28 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id GAA20743; Fri, 11 Sep 1998 06:42:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id GAA15447; Fri, 11 Sep 1998 06:44:22 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA04637; Fri, 11 Sep 1998 06:44:16 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA72033 for tcp-impl-list; Fri, 11 Sep 1998 06:38:40 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA00926 for ; Fri, 11 Sep 1998 06:38:39 -0700 (PDT) mail_from (Spencer.Dawkins.sdawkins@nt.com) Received: from smtprtp (smtprtp.nortel.com [192.122.117.66]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA07425 for ; Fri, 11 Sep 1998 06:38:38 -0700 (PDT) mail_from (Spencer.Dawkins.sdawkins@nt.com) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp; Fri, 11 Sep 1998 09:38:21 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.0.1460.8) id ; Fri, 11 Sep 1998 09:40:50 -0400 Message-ID: <11622C999F23D111BA620000F8662EB7027066D0@zrchb152.us.nortel.com> From: "Spencer Dawkins" To: tcp-impl@cthulhu.engr.sgi.com Subject: RE: NewReno and the 2001 Revision Date: Fri, 11 Sep 1998 09:35:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I would like to see this bug fix (multiple cwnd reductions in a single window) included. It seems to me that the TCPSAT guys are spending lots of time and effort trying to keep their pipes full, and backing off by half in a single window of data (when we built this up at one segment per window of data) is already aggressive congestion avoidance - agressive enough to avoid congestion oscillation. Spencer > -----Original Message----- > From: Mark Allman [SMTP:mallman@lerc.nasa.gov] > Sent: Friday, September 11, 1998 8:07 AM > To: tcp-impl@cthulhu.engr.sgi.com > Cc: Vern Paxson > Subject: NewReno and the 2001 Revision > > > We would like to hear some feedback on what sorts of loss recovery > mechanisms the working group thinks are appropriate for inclusion in > the revision of RFC 2001. As Sally outlined in Chicago, there are > several improvements we can make to Reno style TCP (i.e., TCP > without SACK). > > Our current opinion is that some form of the NewReno changes (as was > obvious in the meeting, there are a number of permutations of > NewReno) should be included in a seperate experimental document. > However, as Sally outlined in the meeting and it her note to this > list shortly after, there is also a seperate issue of fixing a > fairly well known TCP bug (misfeature?). The bug occurs when > multiple fast retransmits happen for multiple lost segments within a > window of data and consequently cwnd is halved multiple times for > one ``congestion event''. We would like to hear comments on whether > or not such a bug fix should be included in the 2001 revision. > > Thanks, > Mark and Vern From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 15 09:41:33 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20149 for ; Tue, 15 Sep 1998 09:41:32 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id GAA15951; Tue, 15 Sep 1998 06:37:43 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id GAA09980; Tue, 15 Sep 1998 06:39:15 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA03032; Tue, 15 Sep 1998 06:38:59 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id GAA41191 for tcp-impl-list; Tue, 15 Sep 1998 06:34:10 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id GAA33742 for ; Tue, 15 Sep 1998 06:34:08 -0700 (PDT) mail_from (genumae65@ee.cuhk.edu.hk) Received: from ub.cesnet.cz (ns.ub.cesnet.cz [194.212.185.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA07092 for ; Tue, 15 Sep 1998 06:34:05 -0700 (PDT) mail_from (genumae65@ee.cuhk.edu.hk) Received: from mail.jakub.hiedu.cz (mail.jakub.hiedu.cz [194.212.60.61]) by ub.cesnet.cz (8.8.7/CESNET) with ESMTP id PAA07491; Tue, 15 Sep 1998 15:26:11 +0200 Date: Tue, 15 Sep 1998 15:26:11 +0200 Received: from DAT/SpoolDir by mail.jakub.hiedu.cz (Mercury 1.21); 15 Sep 98 15:27:27 +0200 Received: from SpoolDir by DAT (Mercury 1.30); 15 Sep 98 13:16:14 +0200 Received: from Default by mail.jakub.hiedu.cz (Mercury 1.30); 15 Sep 98 13:16:05 +0200 To: genumae65@ee.cuhk.edu.hk From: genumae65@ee.cuhk.edu.hk (previdso) Comments: Authenticated sender is Subject: Sexual Harassment Video - Best Seller Message-Id: <199809152422PAA37480@eduksio.jakub.hiedu.cz> Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk This #1 best-selling, business training video can save you thousands of dollars in legal problems by preventing sexual harassment situations before they start. "Sexual Harassment: Situations for Discussions" - VHS Video 24 minutes ( 1998 ) (NTSC video format) Includes a 112-page self-study book "Stopping Sexual Harassment Before it Starts: A Business and Legal Perspective" ($12.95 value) US$110.90 includes $10.95 Federal Express 3-day (US) shipping - Absolute 100% satisfaction, money-back guarantee - Produced by the leading US producer of business training videos. ONLY US$110.90 includes US Federal Express 3-day shipping Unconditional, money-back guarantee - simply return the video. TO ORDER: click here =>http://DirecteMart.com 1-800-700-4439 ( US only ) OR mailto: DirecteMarketing.com@mailexcite.com OR Print and Mail this email and include credit card number, expiration date and signature. VISA Mastercard Amex Training Focus 2777 Yulupa Avenue, #133 Santa Rosa, CA 95405 Make US Checks payable to Training Focus (US funds US banks) No organization can afford to ignore sexual harassment prevention training. This new, quality, professionally-produced, video program delivers the facts on what managers and employees need to know for sexual harassment recognition and prevention. Two new, landmark, US Supreme Court rulings ( 6-26-98 ) make it easier to bring lawsuits over sexaul harassment at work. In a resounding 7-2 vote, the nation's high court ruled in two cases that employers may be held liable for misconduct by their supervisors. Sexual harassment lawsuits have soared nationwide during the 1990s. WASHINGTON (Reuters) Videos are shipped within 48 hours via 3-day Federal Express. Outside the continental US, please ask for shipping charges. Training Focus. Inc. Internet Distributor of Quality, Professionally-Produced, Affordable, Business Videos, Books, Audios, and CDs - since 1996 Please ask about our catalog of hundreds of new and best-selling, quality, affordable business training videos. By using the internet to eliminate high costs of printing, postage and phones, we are able to sell at prices around US$100. Similar quality products cost US$250 - US$800 elsewhere. We apologize if our phone lines are busy, please keep trying. It's a flat-rate, unlimited-volume 800# system using the latest telecom technology. But occasionally we do overwhelm it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This was filtered against the Global Remove Database at: http://142.176.13.105 To be added to the Global Remove Database, go to the above site. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Str5485-jio15 From owner-tcp-impl@cthulhu.engr.sgi.com Tue Sep 15 16:25:32 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04159 for ; Tue, 15 Sep 1998 16:25:32 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA26105; Tue, 15 Sep 1998 13:22:13 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id NAA21901; Tue, 15 Sep 1998 13:23:45 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA07348; Tue, 15 Sep 1998 13:23:38 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA87997 for tcp-impl-list; Tue, 15 Sep 1998 13:19:39 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA00032 for ; Tue, 15 Sep 1998 13:19:37 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from raptor.CS.Berkeley.EDU (raptor.CS.Berkeley.EDU [128.32.130.30]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA02500 for ; Tue, 15 Sep 1998 13:19:30 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from localhost (tomh@localhost) by raptor.CS.Berkeley.EDU (8.8.5/8.8.5) with SMTP id NAA07642 for ; Tue, 15 Sep 1998 13:19:27 -0700 (PDT) Date: Tue, 15 Sep 1998 13:19:27 -0700 (PDT) From: Tom Henderson Reply-To: tomh@CS.Berkeley.EDU To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: NewReno and the 2001 Revision In-Reply-To: <199809111306.JAA06298@guns.lerc.nasa.gov> Message-ID: Organization: UC Berkeley Computer Science X-Url: http://www.cs.berkeley.edu/~tomh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk I've recently been looking at this issue quite closely. This bug fix is very helpful in at least the following situation: large file transfers over GEO (600ms RTT) paths for which the initial value of ssthresh is not cached but is instead some large value. Without the fix, the slow start overshoot typically leads to multiple packet losses, which then leads to rebuilding snd_cwnd linearly from a small value. As an example of the type of performance difference I've seen, a 10 MB file transfer over our GEO network testbed consistently takes a 30% hit in throughput when SACK with Reno congestion avoidance is used instead of SACK with ``NewReno.'' In general, for long transfers over a satellite path, it is very costly to unnecessarily reduce the congestion window while in linear growth phase. I agree with the opinion that this is a bug fix and should not be considered experimental. It covers a case for which the previous version of RFC 2001 was ambiguous (what to do if the ACK is a partial ACK). However, I also believe that if the spec is to include this, it should fully specify the correct behavior upon receiving a partial new ACK. In our SACK + NewReno implementation, we also do the following: - upon receiving a partial ACK, partially deflate the current snd_cwnd by (the amount of new data acked minus one segment), resend the next highest segment that has not yet been ACKed, and call tcp_output() to see if a new segment can be sent. The reason to do window inflation in Reno TCP is to have the correct amount of outstanding data in the network when the recovery ends. If one does not deflate the window for partial ACKs, this amount will be incorrect (overestimated). - upon leaving fast recovery, set snd_cwnd to min(snd_ssthresh, current amount of outstanding data). Window inflation may not successfully generate enough new transmissions for a number of reasons (e.g., sender is receiver window limited, dup acks are lost), leading to a burst of packets when the recovery phase ends. Kevin Fall and Sally Floyd have previously proposed a "maxburst" parameter that limits the number of segments that can be sent in response to an ACK when leaving fast recovery phase. However, we found that a slow receiver can generate a lot of pure window updates right after recovery ends, the effect of which can circumvent this maxburst protection. Setting snd_cwnd to be no more than the current amount of outstanding data is effective in preventing this problem. - avoid "false fast retransmissions" after a timeout as decribed by Hoe in the 1996 Sigcomm paper. --Tom Henderson For those interested, more details on our TCP implementation and experimental results can be found in the following paper: http://www.cs.berkeley.edu/~tomh/papers/jsac99_abstract.html From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 03:17:03 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA17049 for ; Wed, 16 Sep 1998 03:17:03 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id AAA24164; Wed, 16 Sep 1998 00:15:31 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id AAA01400; Wed, 16 Sep 1998 00:17:03 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA04898; Wed, 16 Sep 1998 00:16:59 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id AAA57129 for tcp-impl-list; Wed, 16 Sep 1998 00:10:03 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA01925 for ; Wed, 16 Sep 1998 00:10:01 -0700 (PDT) mail_from (Sam.Michiels@cs.kuleuven.ac.be) Received: from styx.cs.kuleuven.ac.be (styx.cs.kuleuven.ac.be [134.58.40.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA04556 for ; Wed, 16 Sep 1998 00:09:58 -0700 (PDT) mail_from (Sam.Michiels@cs.kuleuven.ac.be) Received: from nix.cs.kuleuven.ac.be (samm@nix.cs.kuleuven.ac.be [134.58.42.36]) by styx.cs.kuleuven.ac.be (8.9.1a/8.9.1) with ESMTP id JAA09251 for ; Wed, 16 Sep 1998 09:09:56 +0200 (MET DST) Received: (from samm@localhost) by nix.cs.kuleuven.ac.be (8.9.1a/8.9.1) id JAA03925 for tcp-impl@cthulhu.engr.sgi.com; Wed, 16 Sep 1998 09:09:55 +0200 (MET DST) From: Sam Michiels Message-Id: <199809160709.JAA03925@nix.cs.kuleuven.ac.be> Subject: OO TCP implementations? To: tcp-impl@cthulhu.engr.sgi.com Date: Wed, 16 Sep 1998 09:09:54 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Hello, I was wondering if anybody of you knows about an Object-Oriented design/implementation of TCP? I'm interested... Regards, Sam. From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 12:01:31 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA23940 for ; Wed, 16 Sep 1998 12:01:29 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA10268; Wed, 16 Sep 1998 08:59:58 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA23201; Wed, 16 Sep 1998 09:01:30 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA04472; Wed, 16 Sep 1998 09:01:13 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA22930 for tcp-impl-list; Wed, 16 Sep 1998 08:52:57 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA06519 for ; Wed, 16 Sep 1998 08:52:55 -0700 (PDT) mail_from (nnarasimharao@novell.com) Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id IAA07270 for ; Wed, 16 Sep 1998 08:52:54 -0700 (PDT) mail_from (nnarasimharao@novell.com) Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Wed, 16 Sep 1998 09:38:53 -0600 Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Wed, 16 Sep 1998 01:34:10 -0600 From: "Nagampali Narasimharao" To: , Subject: Re: OO TCP implementations? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA23940 Hi, In case you find one, please do keep in me loop. I would like to have the code as well. Thanks for your help. Regards Narsi >>> Sam Michiels 09/16 12:39 PM >>> Hello, I was wondering if anybody of you knows about an Object-Oriented design/implementation of TCP? I'm interested... Regards, Sam. From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 13:36:11 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26937 for ; Wed, 16 Sep 1998 13:36:10 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA05974; Wed, 16 Sep 1998 10:34:38 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA25067; Wed, 16 Sep 1998 10:36:09 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07113; Wed, 16 Sep 1998 10:36:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA46546 for tcp-impl-list; Wed, 16 Sep 1998 10:29:44 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA99287 for ; Wed, 16 Sep 1998 10:29:41 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA09767 for ; Wed, 16 Sep 1998 10:29:40 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail1.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA15205; Wed, 16 Sep 1998 10:29:16 -0700 (PDT) Received: by pachyderm.pa.dec.com; id AA17399; Wed, 16 Sep 1998 10:29:14 -0700 Date: Wed, 16 Sep 1998 10:29:14 -0700 From: jg@pa.dec.com (Jim Gettys) Message-Id: <9809161729.AA17399@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: braden@ISI.EDU Cc: rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809041644.AA27622@gra.isi.edu> Subject: Re: status of T/TCP Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Sender: owner-tcp-impl@cthulhu.engr.sgi.com > From: braden@ISI.EDU > Date: Fri, 4 Sep 1998 09:44:58 -0700 > To: rstevens@kohala.com, mycroft@mit.edu > Cc: perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > ----- > *> > *> Furthermore, the case that T/TCP was originally designed for (HTTP) > *> has been more or less resolved by changing the application layer > > According to Jim Gettys, this is an hypothesis which has not been > proven and may be open some doubt. I have been looking for resources > (read "graduate student") to run a test, but perhaps someone else > will do it. Jim has a test scenario. > > Bob Braden > > I suppose I should watch this list more often, but life's been a bit busy. I've always been a fan of T/TCP (if the problems that have been raised can be resolved). There are several reasons why: 1) initial latency is too high. RTT's matter. Much of the work in HTTP/1.1 is to allow pipelining, to reduce the number of RTT's required for operation; but the TCP open is one I can't get around. 2) the distribution of traffic in the Web is not what you might think. Some of it is quite "trasaction oriented" in nature. 3) HTTP/1.1, when implemented well, can greatly reduce (in terms of # of packets) the length of a packet train of a TCP connection). 4) Style sheets will change the content over the next few years. Lets look at these separately: First: Initial connection latency. Some people blithly wave their hands at the savings in latency on connection open... I do not; the Web is an interactive application, which is currently most used over high latency paths (28.8 modems are the bulk of the world out there, so 170ms is optimistically the best you ever see, even for local documents). The RTT between MIT and the main AltaVista site, for example, is around 80 milliseconds as I measure it this instant; any/all of these times are multiples of human perceptible delay. Wireless networks (GSM, etc) look to be in the 800ms range. So right there, I immediately see lots of good reasons to save round trips at connection open. These are delays that immediately impact human percieved performance. Second: transactional behavior. The patterns of of access to a web server is a complex function. But a fair fraction of this traffic (due to extensive client caching) is a single HTTP request followed by a single response, even on pages which are graphically complex. I'll as our Web characterization group to try to get a better pointer to data showing what this distribution looks like. And commonly, in the cases that are not transactional in nature, you want behavior that devolves to normal TCP. You can't predict in advance what behavior is likely. Another common idiom I expect to see as HTTP/1.1 is deployed and implemented well (not clear current implementations typically do this, though) is an initial handshake request/response, followed by a second (the cache validation case) request/response piplines, which would be one or more back to back packets and similar behavior from the server. If everything is cached, you'll get just a few packets of payload in each direction before the connection goes idle (waiting for the next user click that may never come). Note that our SIGCOM paper does not model this often transactional behavior seen in the Web; please don't believe that our Microscape site bears much resemblance to reality (it is about a factor of 2 more complex than a number of fancy corporate home pages). Third: HTTP/1.1, implemented well, can greatly reduce (in terms of # of packets) the length of a packet train of a TCP connection). This will result in more of the traffic looking "transactional" in nature (while increasing, maybe doubling, the mean size of packets). See our SIGCOM paper of a year ago. Fourth: Roughly as HTTP/1.1 rolls out, stylesheets are also deploying. As our SIGCOM paper showes, it will have a possibly great impact on most Web surfing. This can significantly change the nature of the content. There are two possibilities: 1) people will exploit style sheets to improve interactive feel. This will shorten the length of a transaction to a server, in some cases, pretty dramatically, by getting rid of most "junk GIF's", replacing it with stylesheets (which are more compact to begin with, and can be further compressed greatly with deflate compression). 2) Web site designers will use the fact that more useful content can be sent in the same amount of time to put more junk on a web page. I have heard it asserted that web site designers design to human tolerance time, rather than speed. If 1) is true, we'll see very different traffic, more transactional in nature. If 2) is true, things won't change so much. I don't know which is going to happen; most likely a combination. See our SIGCOM paper (and other tidbits) for some of the background, which can be found at: http://www.w3.org/Protocols/HTTP/Performance/ So I was, and still am, a fan of T/TCP. I believe that HTTP/1.1 does NOT reduce the need for it, for the reasons given. I pose to this list: can it be fixed? If it can be fixed, I think it is good stuff. - Jim Gettys From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 13:55:23 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27296 for ; Wed, 16 Sep 1998 13:55:23 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA11785; Wed, 16 Sep 1998 10:53:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA00474; Wed, 16 Sep 1998 10:55:24 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA07634; Wed, 16 Sep 1998 10:53:59 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA11061 for tcp-impl-list; Wed, 16 Sep 1998 10:48:42 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA67644 for ; Wed, 16 Sep 1998 10:48:40 -0700 (PDT) mail_from (craig@aland.bbn.com) Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06830 for ; Wed, 16 Sep 1998 10:48:38 -0700 (PDT) mail_from (craig@aland.bbn.com) Received: from aland.bbn.com (localhost [127.0.0.1]) by aland.bbn.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id KAA18560; Wed, 16 Sep 1998 10:47:00 -0700 (PDT) Message-Id: <199809161747.KAA18560@aland.bbn.com> To: jg@pa.dec.com (Jim Gettys) cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP In-reply-to: Your message of "Wed, 16 Sep 1998 10:29:14 PDT." <9809161729.AA17399@pachyderm.pa.dec.com> Date: Wed, 16 Sep 1998 10:45:44 -0700 From: Craig Partridge Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk In message <9809161729.AA17399@pachyderm.pa.dec.com>, Jim Gettys writes: >Some people blithly wave their hands at the savings in latency on connection >open... > >I do not; the Web is an interactive application, which is currently >most used over high latency paths (28.8 modems are the bulk of the >world out there, so 170ms is optimistically the best you ever see, >even for local documents). The RTT between MIT and the main AltaVista >site, for example, is around 80 milliseconds as I measure it this instant; >any/all of these times are multiples of human perceptible delay. Jim: Do you have good human factors studies on this topic? Last time I went into the human factors literature (c. 1993) I discovered that the best work in the field indicated: * round-trip delays of 600ms were generally quite acceptable * that round-trip delays of 300ms were almost always acceptable Now these studies are from the 1960s and involve voice. Further, the authors of one of the studies (who was still doing work 30 years later) warned me that people appear to get trained to lower delays (as one improves one's network, one increases expectations). But has someone done the careful study for the Web? Craig PS: I'd characterize the study as the following -- try to simulate infinite bandwidth [i.e. load data from local memory or, if one must, a fast file system] and experiment with varying delays between mouse click and when a page actually displays. Allow users to click on a button to ask for faster response when they are dissatisfied. (This roughly matches the old experiments, and avoids problems of technology limitations -- which bedeviled a lot of the telephone delay studies -- lots of folks thought they were measuring human response to delay only to discover they were measuring human response to echo-canceller failures). From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 14:27:00 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA27818 for ; Wed, 16 Sep 1998 14:26:59 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA20242; Wed, 16 Sep 1998 11:25:28 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA10229; Wed, 16 Sep 1998 11:27:00 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06694; Wed, 16 Sep 1998 11:26:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA93747 for tcp-impl-list; Wed, 16 Sep 1998 11:22:20 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA90634 for ; Wed, 16 Sep 1998 11:22:18 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: from zygorthian-space-raiders.mit.edu (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03545 for ; Wed, 16 Sep 1998 11:22:17 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: (from mycroft@localhost) by zygorthian-space-raiders.mit.edu (8.8.8/8.8.8) id OAA08661; Wed, 16 Sep 1998 14:20:57 -0400 (EDT) Date: Wed, 16 Sep 1998 14:20:57 -0400 (EDT) Message-Id: <199809161820.OAA08661@zygorthian-space-raiders.mit.edu> From: "Charles M. Hannum" To: jg@pa.dec.com (Jim Gettys) Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > So I was, and still am, a fan of T/TCP. I believe that HTTP/1.1 does NOT > reduce the need for it, for the reasons given. I pose to this list: can it be > fixed? If it can be fixed, I think it is good stuff. I believe solutions have been proposed (mostly by me!) to all of the problems I've mentioned. One of them would require changing the protocol in an incompatible way -- but as I pointed out, T/TCP is not widely deployed, so this shouldn't be a large burden. From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 14:55:16 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28154 for ; Wed, 16 Sep 1998 14:55:15 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA27721; Wed, 16 Sep 1998 11:53:44 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA16200; Wed, 16 Sep 1998 11:45:45 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02273; Wed, 16 Sep 1998 11:45:28 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA36336 for tcp-impl-list; Wed, 16 Sep 1998 11:40:44 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA54077 for ; Wed, 16 Sep 1998 11:40:42 -0700 (PDT) mail_from (perry@jekyll.piermont.com) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA04482 for ; Wed, 16 Sep 1998 11:40:40 -0700 (PDT) mail_from (perry@jekyll.piermont.com) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA25978; Wed, 16 Sep 1998 14:38:07 -0400 (EDT) Message-Id: <199809161838.OAA25978@jekyll.piermont.com> To: jg@pa.dec.com (Jim Gettys) cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP In-reply-to: Your message of "Wed, 16 Sep 1998 10:29:14 PDT." <9809161729.AA17399@pachyderm.pa.dec.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 16 Sep 1998 14:38:06 -0400 From: "Perry E. Metzger" Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Jim Gettys writes: > I've always been a fan of T/TCP (if the problems that have been raised > can be resolved). I don't really see how they can. Although some people seem to have derided Charles' draft, I think the security issues are real. It is far harder to bring down a TCP based server than a T/TCP based one. The three way handshake is what saves a TCP based host -- you have to be in two-way communication to attack a host (you can't spoof sequence numbers provided you do something like RFC 1948 stuff). T/TCP, for all its charms, can't stop you from being attacked with forged packets precisely because it will never require a three way handshake. Is this such a big deal, though? I have a fast link, and rarely notice or care about the initial handshake issue on my web browsing. Certainly the DNS lookups that have to be done swamp any benefit I'll get from T/TCP. Is another 60 or 100ms such a big deal? The problem with HTTP used to be the floods of tiny connections it induced and what they did to the network. Now that we have that problem licked with HTTP 1.1, the rest seems to be cosmetic, and as I've noted, that cosmetic issue seems almost lost in the noise of other things. Perry From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 14:57:58 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28174 for ; Wed, 16 Sep 1998 14:57:55 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id LAA28586; Wed, 16 Sep 1998 11:56:22 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id LAA20231; Wed, 16 Sep 1998 11:57:49 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA06396; Wed, 16 Sep 1998 11:57:38 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA83407 for tcp-impl-list; Wed, 16 Sep 1998 11:53:04 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA30480 for ; Wed, 16 Sep 1998 11:53:02 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA03444 for ; Wed, 16 Sep 1998 11:53:01 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail1.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id LAA04423; Wed, 16 Sep 1998 11:52:42 -0700 (PDT) Received: by pachyderm.pa.dec.com; id AA04864; Wed, 16 Sep 1998 11:52:40 -0700 Date: Wed, 16 Sep 1998 11:52:40 -0700 From: jg@pa.dec.com (Jim Gettys) Message-Id: <9809161852.AA04864@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Craig Partridge Cc: jg@pa.dec.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809161747.KAA18560@aland.bbn.com> Subject: Re: status of T/TCP Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Sender: owner-tcp-impl@cthulhu.engr.sgi.com > From: Craig Partridge > Date: Wed, 16 Sep 1998 10:45:44 -0700 > To: jg@pa.dec.com (Jim Gettys) > Cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, > aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > ----- > In message <9809161729.AA17399@pachyderm.pa.dec.com>, Jim Gettys writes: > > >Some people blithly wave their hands at the savings in latency on connection > >open... > > > >I do not; the Web is an interactive application, which is currently > >most used over high latency paths (28.8 modems are the bulk of the > >world out there, so 170ms is optimistically the best you ever see, > >even for local documents). The RTT between MIT and the main AltaVista > >site, for example, is around 80 milliseconds as I measure it this instant; > >any/all of these times are multiples of human perceptible delay. > > Jim: > > Do you have good human factors studies on this topic? > > Last time I went into the human factors literature (c. 1993) I discovered > that the best work in the field indicated: > > * round-trip delays of 600ms were generally quite acceptable > > * that round-trip delays of 300ms were almost always acceptable > > Now these studies are from the 1960s and involve voice. Further, the > authors of one of the studies (who was still doing work 30 years later) > warned me that people appear to get trained to lower delays (as one > improves one's network, one increases expectations). > > But has someone done the careful study for the Web? > I don't have good research at my hands to point you to. Acceptable of course, depends on the applicatation; it may not be a human on the other end. I have a bit of "first hand" experience in the area due to my previous life: 30 milliseconds is roughly the limit of human perception; anything faster than this is "instantaneous". This is true for refresh on a TV screen, or rubberbanding a mouse (my own experimental experience is once X mouse tracking reached 30HZ, the rubber band "felt" attached to the mouse). I don't know about you, but I want things "instantly" on my screen after I click. My performance goal is always therefore in the 50-30 millisecond range. Note that speed of light (in glass) becomes an issue in the Internet, at the best of times; taking this number and multiplying by a factor of two easily gets up to the hundreds of milliseconds of even the very old data you quote above. 2X the 82 milliseconds between me and AltaVista becomes 160ms. More commonly, with 28.8 modems, the RTT is in the 170ms range, to the first hop; 2X is then 340ms, which even by your number is becoming an issue. Add these two, and you get something in the 500ms range. Another example: my machine at MIT to Inria's web server (in France): RTT is ~125 milliseconds. (And we have our own line to Inria) 2X this is 250 milliseconds. If I were at home on my dialup line, I bet I'd measure an RTT of around 300milliseconds (170 + 125). 2X this is 600 milliseconds. I hope this demonstrates that, even given the "acceptable" delays of 300-600 milliseconds you quote that it is pretty trivial to burn this time up in today's internet (and tomorrow's too). I personally believe that "fast enough" is considerably less than your numbers. So I'd like to take the 2X down to 1X of the RTT for the initial latency. And I don't want to use my ENTIRE latency budget for getting things "fast enough" on round trips that aren't necessary. How about time to do something useful at the server end? Or to transfer bytes over the wire for some real content so that something appears on my screen. Latency is additive; and you don't ever get it back. One alternative, of course, is to always have a web proxy up stream of you, with a connection open to your browser to get back the RTT over the slowest hop; but I'd like to get it back everywhere. - Jim From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 16:00:35 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29139 for ; Wed, 16 Sep 1998 16:00:34 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id MAA12882; Wed, 16 Sep 1998 12:59:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id NAA07802; Wed, 16 Sep 1998 13:00:33 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA01666; Wed, 16 Sep 1998 13:00:19 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA75129 for tcp-impl-list; Wed, 16 Sep 1998 12:55:58 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA34150 for ; Wed, 16 Sep 1998 12:55:54 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA08920 for ; Wed, 16 Sep 1998 12:55:53 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA27017; Wed, 16 Sep 1998 12:55:51 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id MAA03042; Wed, 16 Sep 1998 12:55:51 -0700 (PDT) Date: Wed, 16 Sep 1998 12:55:51 -0700 (PDT) Message-Id: <199809161955.MAA03042@rum.isi.edu> To: craig@aland.bbn.com, jg@pa.dec.com Subject: Re: status of T/TCP Cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 11:56:46 1998 > Date: Wed, 16 Sep 1998 11:52:40 -0700 > From: jg@pa.dec.com (Jim Gettys) > To: Craig Partridge > Cc: jg@pa.dec.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, > perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > > > > > From: Craig Partridge > > Date: Wed, 16 Sep 1998 10:45:44 -0700 > > To: jg@pa.dec.com (Jim Gettys) > > Cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, > > aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > > Subject: Re: status of T/TCP > > ----- ... > > Jim: > > > > Do you have good human factors studies on this topic? > > > > Last time I went into the human factors literature (c. 1993) I discovered > > that the best work in the field indicated: > > > > * round-trip delays of 600ms were generally quite acceptable > > > > * that round-trip delays of 300ms were almost always acceptable > > ... > > But has someone done the careful study for the Web? > > > > I don't have good research at my hands to point you to. > > Acceptable of course, depends on the applicatation; it may not be a human > on the other end. > > I have a bit of "first hand" experience in the area due to my previous life: > > 30 milliseconds is roughly the limit of human perception; anything > faster than this is "instantaneous". This is true for refresh > on a TV screen, or rubberbanding a mouse (my own experimental experience > is once X mouse tracking reached 30HZ, the rubber band "felt" attached > to the mouse). 30ms is related to motion video; anything more instant than that is lost in the frame refresh, which is lost in the persistence of vision. Tolerable delays depend on whether the brain is otherwise busy, which opens that loop up for other tasks. Clicking on a single light is around 100ms, multi-colored (click if it's red, where the light has to both go ON and go RED) takes ~300ms, and on up for more complicated tasks. If the response takes less time than the brain's processing, you're fine. > I don't know about you, but I want things "instantly" on my screen > after I click. My performance goal is always therefore in the 50-30 > millisecond range. This is from click to render; includes OS delays, request/response, and the rendering on the local end, BTW. > Note that speed of light (in glass) becomes an issue in the Internet, > at the best of times; taking this number and multiplying by a factor of > two easily gets up to the hundreds of milliseconds of even the very old > data you quote above. 2X the 82 milliseconds between me and AltaVista > becomes 160ms. More commonly, with 28.8 modems, the RTT is in the 170ms > range, to the first hop; 2X is then 340ms, which even by your number is > becoming an issue. Add these two, and you get something in the 500ms > range. BTW - some of this latency is the modem being too clever about buffering and compressing. Shutting it down might decrease the latency. Another part is the use of large packets - it might be better to have smaller packets with additional overhead. The overall transaction latency would increase, but the time to first portion of response would decrease. > Another example: my machine at MIT to Inria's web server (in France): > RTT is ~125 milliseconds. (And we have our own line to Inria) 2X this > is 250 milliseconds. BTW2 - why are you doubling the RTT? I have a chart of the BW required to send a web page in 100 ms, counting only transmission delay, at: http://www.isi.edu/lowlat/ > And I don't want to use my ENTIRE latency budget for getting things "fast > enough" on round trips that aren't necessary. How about time to do something > useful at the server end? Or to transfer bytes over the wire for some > real content so that something appears on my screen. Latency is additive; > and you don't ever get it back. > > One alternative, of course, is to always have a web proxy up stream > of you, with a connection open to your browser to get back the RTT over > the slowest hop; but I'd like to get it back everywhere. > - Jim Another is to send things ahead of time; we do this in 'background' to reduce the response latency. In the end, source anticipation is the only way to reduce the latency (and it does 'get it back', in a sense) Joe From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 16:35:28 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29752 for ; Wed, 16 Sep 1998 16:35:27 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA21067; Wed, 16 Sep 1998 13:33:56 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id NAA16677; Wed, 16 Sep 1998 13:35:27 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA00598; Wed, 16 Sep 1998 13:35:22 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA94878 for tcp-impl-list; Wed, 16 Sep 1998 13:30:52 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA72861 for ; Wed, 16 Sep 1998 13:30:50 -0700 (PDT) mail_from (mouse@Twig.Rodents.Montreal.QC.CA) Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA03738 for ; Wed, 16 Sep 1998 13:30:46 -0700 (PDT) mail_from (mouse@Twig.Rodents.Montreal.QC.CA) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.5/8.8.5) id QAA27219; Wed, 16 Sep 1998 16:30:40 -0400 (EDT) Date: Wed, 16 Sep 1998 16:30:40 -0400 (EDT) From: der Mouse Message-Id: <199809162030.QAA27219@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk >> More commonly, with 28.8 modems, the RTT is in the 170ms range, to >> the first hop; [...] > BTW - some of this latency is the modem being too clever about > buffering and compressing. Shutting it down might decrease the > latency. Might? Definitely does, in my experience. Turn off error correction and compression and I've always found latency goes down. The per-packet error rate goes up, of course; whether this is an acceptable tradeoff depends on the application. Of course, this particular side note is probably getting a little off-topic for tcp-impl.... der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 17:55:26 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00928 for ; Wed, 16 Sep 1998 17:55:25 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA11063; Wed, 16 Sep 1998 14:53:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA08015; Wed, 16 Sep 1998 14:41:12 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA00126; Wed, 16 Sep 1998 14:40:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA21503 for tcp-impl-list; Wed, 16 Sep 1998 14:39:15 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA32911 for ; Wed, 16 Sep 1998 14:39:14 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA02547 for ; Wed, 16 Sep 1998 14:39:13 -0700 (PDT) mail_from (touch@ISI.EDU) Received: from rum.isi.edu (rum-e.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA06969; Wed, 16 Sep 1998 14:39:12 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.8.7/8.8.6) id OAA05778; Wed, 16 Sep 1998 14:39:12 -0700 (PDT) Date: Wed, 16 Sep 1998 14:39:12 -0700 (PDT) Message-Id: <199809162139.OAA05778@rum.isi.edu> To: touch@ISI.EDU, jg@pa.dec.com Subject: Re: status of T/TCP Cc: craig@aland.bbn.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: jg@pa.dec.com (Jim Gettys) > To: Joe Touch > Cc: craig@aland.bbn.com, jg@pa.dec.com, braden@ISI.EDU, rstevens@kohala.com, > mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, > tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > ... > > > Another example: my machine at MIT to Inria's web server (in France): > > > RTT is ~125 milliseconds. (And we have our own line to Inria) 2X this > > > is 250 milliseconds. > > > > BTW2 - why are you doubling the RTT? ... > How do you anticipate a new user's first visit to a web site (without > burning infinite bandwidth? You don't - that's the one you have to just wait. However, T/TCP won't help this either - if it really is the first time you're there, you take a 3-way handshake to establish state. T/TCP helps only for subsequent connections. (just to round out the original discussion on T/TCP, which is where we started) Joe From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 18:22:48 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00930 for ; Wed, 16 Sep 1998 17:55:25 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id OAA11066; Wed, 16 Sep 1998 14:53:55 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA08022; Wed, 16 Sep 1998 14:41:13 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA03185; Wed, 16 Sep 1998 14:40:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA99622 for tcp-impl-list; Wed, 16 Sep 1998 14:35:47 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA70056 for ; Wed, 16 Sep 1998 14:35:45 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08055 for ; Wed, 16 Sep 1998 14:35:44 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail1.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA06204; Wed, 16 Sep 1998 14:34:23 -0700 (PDT) Received: by pachyderm.pa.dec.com; id AA11803; Wed, 16 Sep 1998 14:34:21 -0700 Date: Wed, 16 Sep 1998 14:34:21 -0700 From: jg@pa.dec.com (Jim Gettys) Message-Id: <9809162134.AA11803@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: Joe Touch Cc: craig@aland.bbn.com, jg@pa.dec.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809161955.MAA03042@rum.isi.edu> Subject: Re: status of T/TCP Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: Joe Touch > Date: Wed, 16 Sep 1998 12:55:51 -0700 (PDT) > To: craig@aland.bbn.com, jg@pa.dec.com > Cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, > aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > ----- > > From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 11:56:46 1998 > > Date: Wed, 16 Sep 1998 11:52:40 -0700 > > From: jg@pa.dec.com (Jim Gettys) > > To: Craig Partridge > > Cc: jg@pa.dec.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, > > perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > > Subject: Re: status of T/TCP > > > > > > > > > From: Craig Partridge > > > Date: Wed, 16 Sep 1998 10:45:44 -0700 > > > To: jg@pa.dec.com (Jim Gettys) > > > Cc: braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, > perry@piermont.com, > > > aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com > > > Subject: Re: status of T/TCP > > > ----- > ... > > > Jim: > > > > > > Do you have good human factors studies on this topic? > > > > > > Last time I went into the human factors literature (c. 1993) I discovered > > > that the best work in the field indicated: > > > > > > * round-trip delays of 600ms were generally quite acceptable > > > > > > * that round-trip delays of 300ms were almost always acceptable > > > > ... > > > But has someone done the careful study for the Web? > > > > > > > I don't have good research at my hands to point you to. > > > > Acceptable of course, depends on the applicatation; it may not be a human > > on the other end. > > > > I have a bit of "first hand" experience in the area due to my previous life: > > > > 30 milliseconds is roughly the limit of human perception; anything > > faster than this is "instantaneous". This is true for refresh > > on a TV screen, or rubberbanding a mouse (my own experimental experience > > is once X mouse tracking reached 30HZ, the rubber band "felt" attached > > to the mouse). > > 30ms is related to motion video; anything more instant than that > is lost in the frame refresh, which is lost in the persistence of vision. > > Tolerable delays depend on whether the brain is otherwise busy, > which opens that loop up for other tasks. Clicking on a single light > is around 100ms, multi-colored (click if it's red, where the light > has to both go ON and go RED) takes ~300ms, and on up for more > complicated tasks. > > If the response takes less time than the brain's processing, you're fine. > > > I don't know about you, but I want things "instantly" on my screen > > after I click. My performance goal is always therefore in the 50-30 > > millisecond range. > > This is from click to render; includes OS delays, request/response, > and the rendering on the local end, BTW. > > > Note that speed of light (in glass) becomes an issue in the Internet, > > at the best of times; taking this number and multiplying by a factor of > > two easily gets up to the hundreds of milliseconds of even the very old > > data you quote above. 2X the 82 milliseconds between me and AltaVista > > becomes 160ms. More commonly, with 28.8 modems, the RTT is in the 170ms > > range, to the first hop; 2X is then 340ms, which even by your number is > > becoming an issue. Add these two, and you get something in the 500ms > > range. > > BTW - some of this latency is the modem being too clever about > buffering and compressing. Shutting it down might decrease the latency. > Another part is the use of large packets - it might be better to have > smaller packets with additional overhead. The overall transaction latency > would increase, but the time to first portion of response would decrease. Sure. The right thing to do (if HTTP did not have such verbose request response headers) would be to turn off all modem compression, and send the HTML content compressed. Deflate compression does very much better than anything in modems. > > > Another example: my machine at MIT to Inria's web server (in France): > > RTT is ~125 milliseconds. (And we have our own line to Inria) 2X this > > is 250 milliseconds. > > BTW2 - why are you doubling the RTT? > The difference between the two round trip times to open a conventional TCP connection vs. T/TCP. Conventional TCP takes two... I want to get one of them back... > I have a chart of the BW required to send a web page in 100 ms, > counting only transmission delay, at: > > http://www.isi.edu/lowlat/ > Yup. This is why changing the content is important: stylesheets and good data compression to reduce the number of bits transferred is also essential to help interactivity of the Web. If I get more useful information / bit transferred, it can make a tremendous difference. Simple data compression can get you a factor of three or more on the HTML, XML, or text transferred; stylesheets can get rid of large numbers of unneeded GIF's, and can similarly be compressed. For many/most web pages, there is probably a factor of three or more to be had; for those currently guilty of "GIF abuse" due to HTML's deficiency without stylesheets, the improvement may be another factor of two or more (depending on how agressive people are at using style sheets rather than GIF's for common things. > > And I don't want to use my ENTIRE latency budget for getting things "fast > > enough" on round trips that aren't necessary. How about time to do > something > > useful at the server end? Or to transfer bytes over the wire for some > > real content so that something appears on my screen. Latency is additive; > > and you don't ever get it back. > > > > One alternative, of course, is to always have a web proxy up stream > > of you, with a connection open to your browser to get back the RTT over > > the slowest hop; but I'd like to get it back everywhere. > > - Jim > > Another is to send things ahead of time; we do this in 'background' > to reduce the response latency. In the end, source anticipation is > the only way to reduce the latency (and it does 'get it back', in > a sense) > > Joe How do you anticipate a new user's first visit to a web site (without burning infinite bandwidth? In any case, I think this discussion has shown that the latency is a real issue for interactive applications, given the Internet, whether the requirement is 30 or 300 milliseconds... I can fix some of the problems at the applications layer, and you can fix some of it in the network protocol (or do you want us to invent our own protocol? :-) ). Our fixes in the web currenly beginning deployment include pipelining, stylesheets, and transfer coding (deflate compression). Fully exploited, these can make a major difference for the interactive behavior of the applications (making your numbers at the URL above obsolete). I still want T/TCP for the additional round trip I'd get back, along with all the other reasons I stated originally. Wouldn't matter so much if we weren't working hard at the application level, but we are; I predict that what wasn't noticable in the past will start becoming a significant part of the latency budget. In any case, I don't think this conversation should continue here, as it has little bearing on general TCP implementation. - Jim From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 18:26:34 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01245 for ; Wed, 16 Sep 1998 18:26:33 -0400 (EDT) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA20287; Wed, 16 Sep 1998 15:25:02 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id PAA18764; Wed, 16 Sep 1998 15:14:34 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA01162; Wed, 16 Sep 1998 15:14:26 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA91188 for tcp-impl-list; Wed, 16 Sep 1998 15:10:30 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA35037 for ; Wed, 16 Sep 1998 15:10:29 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA00188 for ; Wed, 16 Sep 1998 15:10:27 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id QAA09931 for tcp-impl@cthulhu.engr.sgi.com env-from ; Wed, 16 Sep 1998 16:10:26 -0600 (MDT) Date: Wed, 16 Sep 1998 16:10:26 -0600 (MDT) From: Vernon Schryver Message-Id: <199809162210.QAA09931@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: jg@pa.dec.com (Jim Gettys) > ... > > BTW - some of this latency is the modem being too clever about > > buffering and compressing. Shutting it down might decrease the latency. > > Another part is the use of large packets - it might be better to have > > smaller packets with additional overhead. The overall transaction latency > > would increase, but the time to first portion of response would decrease. > > Sure. The right thing to do (if HTTP did not have such verbose request > response headers) would be to turn off all modem compression, and > send the HTML content compressed. Deflate compression does very > much better than anything in modems. Modems tend to use LZW, always (I trust) with at least 10-bit and at least sometimes more. Judging from what Paul Mackerras has told me of his comparisons between BSD Compress (RFC 1977) and Deflate (RFC 1979) in his widely used `pppd`, the difference between Deflate and your typical modem on the data that is compressed should be about the difference you see between `compress` and `gzip`, or around a 10% improvement in compression ratio but at a ~2X cost in CPU cycles, and mostly on the side that does not have cycles to waste, the HTTP server. Since most ISP's do not run hardware that supports VJ header compression, a modem using 12 or 14-bit LZW will be able to good things to those 45-byte TCP/IP/PPP headers, which will probably almost always excede what the modem loses by using LZW over the application-data. In other words, I bet that if you measure things, you'll find that turning off v.42+v.42bis improves latencies (and only when the link is mostly idle, as with `ping`) but always hurts throughput, even when moving pre-compressed application-data. > ... > TCP connection vs. T/TCP. Conventional TCP takes two... I want to > get one of them back... If you get it back, then how do you deal with the modified form of SYN attack? As has been said repeatedly recently, an extra intial RTT paid by someone before the server commits any significant resources to the request seems necessary to defend against that attack. I've claimed that random-drop in the application would help, but people tend to not like random ideas. Besides, even I admit it would help only when the ratio of good to bad connection attempts is small. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 21:50:54 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02579 for ; Wed, 16 Sep 1998 21:50:54 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA29766 for <@deliverator.sgi.com:tcpimpl-archive@odin.ietf.org>; Wed, 16 Sep 1998 18:49:23 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:tcpimpl-archive@odin.ietf.org> id SAA12707; Wed, 16 Sep 1998 18:50:55 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA09730; Wed, 16 Sep 1998 18:50:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id SAA84689 for tcp-impl-list; Wed, 16 Sep 1998 18:45:06 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA13070 for ; Wed, 16 Sep 1998 18:44:59 -0700 (PDT) mail_from (sparker@fstop.Eng.Sun.COM) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA05565 for ; Wed, 16 Sep 1998 18:44:59 -0700 (PDT) mail_from (sparker@fstop.Eng.Sun.COM) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA22024; Wed, 16 Sep 1998 18:40:21 -0700 Received: from fstop. (fstop.Eng.Sun.COM [192.9.204.16]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA24645; Wed, 16 Sep 1998 18:40:16 -0700 Received: from fstop.eng.sun.com by fstop. (SMI-8.6/SMI-SVR4) id SAA14320; Wed, 16 Sep 1998 18:40:04 -0700 Message-Id: <199809170140.SAA14320@fstop.> From: sparker@Eng.Sun.COM To: jg@pa.dec.com (Jim Gettys) cc: craig@aland.bbn.com, braden@ISI.EDU, rstevens@kohala.com, mycroft@mit.edu, perry@piermont.com, aron@cs.rice.edu, tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Date: Wed, 16 Sep 1998 18:40:04 -0700 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk - I still want T/TCP for the additional round trip I'd get back, along with - all the other reasons I stated originally. And I still remain convinced that security concerns, the added complexity to TCP (as hashed out quite well by the original researcher in a BOF, what?, two years back?) and the lack of serious deployment experience with T/TCP mean it's a long-term, if ever, affair. Look for latency reduction by reducing the size of content, and by making the content arrive in a sensible order. Let the document include tips about preloading the most common next choice(s). - In any case, I don't think this conversation should continue here, - as it has little bearing on general TCP implementation. Yup. Especially considering T/TCP is only experimental at best. Cheers, ~sparker From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 22:09:38 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02691 for ; Wed, 16 Sep 1998 22:09:37 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA04884 for <@deliverator.sgi.com:tcpimpl-archive@odin.ietf.org>; Wed, 16 Sep 1998 19:08:07 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:tcpimpl-archive@odin.ietf.org> id TAA17380; Wed, 16 Sep 1998 19:09:39 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA05871; Wed, 16 Sep 1998 19:09:34 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA56266 for tcp-impl-list; Wed, 16 Sep 1998 19:05:17 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA68985 for ; Wed, 16 Sep 1998 19:05:15 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: from zygorthian-space-raiders.mit.edu (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA00645 for ; Wed, 16 Sep 1998 19:05:14 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: (from mycroft@localhost) by zygorthian-space-raiders.mit.edu (8.8.8/8.8.8) id WAA08960; Wed, 16 Sep 1998 22:05:14 -0400 (EDT) Date: Wed, 16 Sep 1998 22:05:14 -0400 (EDT) Message-Id: <199809170205.WAA08960@zygorthian-space-raiders.mit.edu> From: "Charles M. Hannum" To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Since there seems to be some confusion about this, I'd like to state my position on the whole T/TCP thing explicitly: My concern is whether, by introducing T/TCP, we are creating new ways to lose that users are not expecting. The purpose of my original draft, and further comments here, is to bring light to these issues so that they are addressed. There's really nothing more to it than this. I don't have some vendetta against T/TCP, or Bob. Assuming that the problems are addressed, I think T/TCP is actually a good idea. There isn't really a way to lose here. With the changes I proposed, and the changes someone else (sorry, I forget who) proposed to simplify the setup, the changes to the TCP protocol are relatively simple. There is still an issue with servers that implement RFC793 to the letter, but I think this is probably an ignorable issue for the most part (especially considering my intent of not using T/TCP at all for some protocols). So, I think the thing to do at this point is review the T/TCP spec, incorporating relevant requirements and modifications proposed here, implement it, and see how it fares. This is, after all, what the RFC process is about. From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 16 22:16:55 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02743 for ; Wed, 16 Sep 1998 22:16:55 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA06232 for <@deliverator.sgi.com:tcpimpl-archive@odin.ietf.org>; Wed, 16 Sep 1998 19:15:24 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for <@relay.sgi.com:tcpimpl-archive@odin.ietf.org> id TAA19161; Wed, 16 Sep 1998 19:16:57 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA00545; Wed, 16 Sep 1998 19:16:53 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA14156 for tcp-impl-list; Wed, 16 Sep 1998 19:13:50 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA97030 for ; Wed, 16 Sep 1998 19:13:49 -0700 (PDT) mail_from (alan@lxorguk.ukuu.org.uk) Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA06318 for ; Wed, 16 Sep 1998 19:13:48 -0700 (PDT) mail_from (alan@lxorguk.ukuu.org.uk) Received: from the-village.bc.nu (the-village.bc.nu [163.164.160.21]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id DAA10937; Thu, 17 Sep 1998 03:13:34 +0100 Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zJUTN-000aQwC; Thu, 17 Sep 98 04:11 BST Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: status of T/TCP To: root@ihack.net (Charles M. Hannum) Date: Thu, 17 Sep 1998 04:11:08 +0100 (BST) Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809170205.WAA08960@zygorthian-space-raiders.mit.edu> from "Charles M. Hannum" at Sep 16, 98 10:05:14 pm Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > There is still an issue with servers that implement RFC793 to the > letter, but I think this is probably an ignorable issue for the most > part (especially considering my intent of not using T/TCP at all for > some protocols). An awful lot of low end "contraption in a box" devices are KA9Q derived and older KA9Q does not like T/TCP one bit. > So, I think the thing to do at this point is review the T/TCP spec, > incorporating relevant requirements and modifications proposed here, > implement it, and see how it fares. If this is to be done perhaps the first thing to issue is a small rfc note on making sure your stack doesnt break when .. so that things are ready for T/TCP. IPv6 is kindly going to kill a lot of the dinosaur stacks for everyone so it would be good that nobody commits t/tcp incompatibility across it From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 17 12:21:51 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA16302 for ; Thu, 17 Sep 1998 12:21:50 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id JAA21760; Thu, 17 Sep 1998 09:19:50 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA07128; Thu, 17 Sep 1998 09:21:19 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA06033; Thu, 17 Sep 1998 09:20:48 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA39345 for tcp-impl-list; Thu, 17 Sep 1998 09:12:37 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA18803 for ; Thu, 17 Sep 1998 09:12:34 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA06901 for ; Thu, 17 Sep 1998 09:12:34 -0700 (PDT) mail_from (braden@ISI.EDU) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA18565; Thu, 17 Sep 1998 09:12:03 -0700 (PDT) Date: Thu, 17 Sep 1998 09:09:44 -0700 From: braden@ISI.EDU Posted-Date: Thu, 17 Sep 1998 09:09:44 -0700 Message-Id: <199809171609.AA24245@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Thu, 17 Sep 1998 09:09:44 -0700 To: root@ihack.net, alan@lxorguk.ukuu.org.uk Subject: Re: status of T/TCP Cc: tcp-impl@cthulhu.engr.sgi.com Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk *> *> > There is still an issue with servers that implement RFC793 to the *> > letter, but I think this is probably an ignorable issue for the most *> > part (especially considering my intent of not using T/TCP at all for *> > some protocols). *> *> An awful lot of low end "contraption in a box" devices are KA9Q derived *> and older KA9Q does not like T/TCP one bit. *> Are you saying that a T/TCP client actually *breaks* a TCP that "implements RFC793 to the letter"? I thought T/TCP was fully backward compatible with strictly correct TCPs. Could you explain further? [This might actually be an sub-issue the is RELEVANT to this mailing list!] Bob Braden From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 17 12:59:04 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA16712 for ; Thu, 17 Sep 1998 12:59:04 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id JAA03280; Thu, 17 Sep 1998 09:57:25 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id JAA22696; Thu, 17 Sep 1998 09:58:56 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07607; Thu, 17 Sep 1998 09:58:45 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA48368 for tcp-impl-list; Thu, 17 Sep 1998 09:56:38 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA44586 for ; Thu, 17 Sep 1998 09:56:37 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: from zygorthian-space-raiders.mit.edu (ZYGORTHIAN-SPACE-RAIDERS.MIT.EDU [18.70.0.61]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA09359 for ; Thu, 17 Sep 1998 09:56:35 -0700 (PDT) mail_from (mycroft@zygorthian-space-raiders.mit.edu) Received: (from mycroft@localhost) by zygorthian-space-raiders.mit.edu (8.8.8/8.8.8) id MAA12414; Thu, 17 Sep 1998 12:56:32 -0400 (EDT) Date: Thu, 17 Sep 1998 12:56:32 -0400 (EDT) Message-Id: <199809171656.MAA12414@zygorthian-space-raiders.mit.edu> From: "Charles M. Hannum" To: braden@ISI.EDU Cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Are you saying that a T/TCP client actually *breaks* a TCP that > "implements RFC793 to the letter"? Yes, that's what I've been saying for years. The processing rules in RFC793 have at least one interesting condition that conflicts with T/TCP. On page 75, near the middle: eighth, check the FIN bit, Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT since the SEG.SEQ cannot be validated; drop the segment and return. This is very clear. It says `drop the segment', not `drop the FIN' or `send a RST'. So if your T/TCP client sends a SYN-data-FIN to my TCP server, and I implement exactly what the spec says, your packets will be blackholed and you won't be able to talk to me. In practice, most servers just drop the FIN, but I for one specifically chose that behaviour to be compatible with T/TCP clients. (I've been specifically asked at least twice to change the behaviour to what RFC793 specifies.) I believe this is also the issue with talking to KA9Q. (And while we *could* update RFC793, I don't think it's valid to say that a vast pile of systems which correctly implemented the spec are now incorrect. That effectively requires a flag day.) From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 17 13:13:43 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA16901 for ; Thu, 17 Sep 1998 13:13:43 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id KAA07525; Thu, 17 Sep 1998 10:12:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA28541; Thu, 17 Sep 1998 10:13:29 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA07264; Thu, 17 Sep 1998 09:57:31 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA10090 for tcp-impl-list; Thu, 17 Sep 1998 09:52:29 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA21558 for ; Thu, 17 Sep 1998 09:52:28 -0700 (PDT) mail_from (alan@lxorguk.ukuu.org.uk) Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08188 for ; Thu, 17 Sep 1998 09:52:26 -0700 (PDT) mail_from (alan@lxorguk.ukuu.org.uk) Received: from the-village.bc.nu (the-village.bc.nu [163.164.160.21]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id RAA27473; Thu, 17 Sep 1998 17:52:12 +0100 Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zJiBe-000aQwC; Thu, 17 Sep 98 18:49 BST Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: status of T/TCP To: braden@ISI.EDU Date: Thu, 17 Sep 1998 18:49:45 +0100 (BST) Cc: root@IHACK.NET, alan@lxorguk.ukuu.org.uk, tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809171609.AA24245@gra.isi.edu> from "braden@ISI.EDU" at Sep 17, 98 09:09:44 am Content-Type: text Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Are you saying that a T/TCP client actually *breaks* a TCP that > "implements RFC793 to the letter"? I thought T/TCP was fully backward > compatible with strictly correct TCPs. Could you explain further? > [This might actually be an sub-issue the is RELEVANT to this mailing > list!] Im not sure if its a bug or a feature. T/TCP isnt arguably compliant to RFC793 since it sends data into a window that has not been advertised and is closed. Thats pretty much pedantry. What I do know is if I make a T/TCP connection to boxes using older versions of KA9Q NOS the connection dies. It doesnt do a nice syn+data+fin syn|ack (ack no data) ack [normal tcp] it actually fails. From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 18 10:21:36 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA04229 for ; Fri, 18 Sep 1998 10:21:35 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id HAA08355; Fri, 18 Sep 1998 07:19:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id HAA18287; Fri, 18 Sep 1998 07:21:24 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA06459; Fri, 18 Sep 1998 07:21:19 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id HAA37951 for tcp-impl-list; Fri, 18 Sep 1998 07:13:56 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA72648 for ; Fri, 18 Sep 1998 07:13:55 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA01089 for ; Fri, 18 Sep 1998 07:13:54 -0700 (PDT) mail_from (jg@pa.dec.com) Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail2.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id HAA31132; Fri, 18 Sep 1998 07:13:48 -0700 (PDT) Received: by pachyderm.pa.dec.com; id AA19454; Fri, 18 Sep 1998 07:13:46 -0700 Date: Fri, 18 Sep 1998 07:13:46 -0700 From: jg@pa.dec.com (Jim Gettys) Message-Id: <9809181413.AA19454@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client lkgdhcp-24-224-199.lkg.dec.com, user jg) To: Vernon Schryver Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: <199809162210.QAA09931@calcite.rhyolite.com> Subject: Re: status of T/TCP Mime-Version: 1.0 Content-Type: text/plain Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > Sender: owner-tcp-impl@cthulhu.engr.sgi.com > From: Vernon Schryver > Date: Wed, 16 Sep 1998 16:10:26 -0600 (MDT) > To: tcp-impl@cthulhu.engr.sgi.com > Subject: Re: status of T/TCP > ----- > > From: jg@pa.dec.com (Jim Gettys) > > > ... > > > BTW - some of this latency is the modem being too clever about > > > buffering and compressing. Shutting it down might decrease the latency. > > > Another part is the use of large packets - it might be better to have > > > smaller packets with additional overhead. The overall transaction latency > > > would increase, but the time to first portion of response would decrease. > > > > Sure. The right thing to do (if HTTP did not have such verbose request > > response headers) would be to turn off all modem compression, and > > send the HTML content compressed. Deflate compression does very > > much better than anything in modems. > > Modems tend to use LZW, always (I trust) with at least 10-bit and at least > sometimes more. Judging from what Paul Mackerras has told me of his > comparisons between BSD Compress (RFC 1977) and Deflate (RFC 1979) in his > widely used `pppd`, the difference between Deflate and your typical modem > on the data that is compressed should be about the difference you see > between `compress` and `gzip`, or around a 10% improvement in compression > ratio but at a ~2X cost in CPU cycles, and mostly on the side that does > not have cycles to waste, the HTTP server. > The server can cache the compressed object, and only compress it once. Our measurements show a much greater effect of compression than 10%; see: http://www.w3.org/Protocols/HTTP/Performance/#Compression This are measurements over real modems. - Jim From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 18 11:29:37 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04832 for ; Fri, 18 Sep 1998 11:29:36 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA22813; Fri, 18 Sep 1998 08:27:57 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id IAA07036; Fri, 18 Sep 1998 08:29:30 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA01968; Fri, 18 Sep 1998 08:29:16 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA86637 for tcp-impl-list; Fri, 18 Sep 1998 08:25:37 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA05127 for ; Fri, 18 Sep 1998 08:25:35 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA06347 for ; Fri, 18 Sep 1998 08:25:34 -0700 (PDT) mail_from (vjs@calcite.rhyolite.com) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id JAA14637 for tcp-impl@cthulhu.engr.sgi.com env-from ; Fri, 18 Sep 1998 09:25:32 -0600 (MDT) Date: Fri, 18 Sep 1998 09:25:32 -0600 (MDT) From: Vernon Schryver Message-Id: <199809181525.JAA14637@calcite.rhyolite.com> To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: status of T/TCP Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > From: jg@pa.dec.com (Jim Gettys) > ... > > > Sure. The right thing to do (if HTTP did not have such verbose request > > > response headers) would be to turn off all modem compression, and > > > send the HTML content compressed. Deflate compression does very > > > much better than anything in modems. > > > > Modems tend to use LZW, always (I trust) with at least 10-bit and at least > > sometimes more. Judging from what Paul Mackerras has told me of his > > comparisons between BSD Compress (RFC 1977) and Deflate (RFC 1979) in his > > widely used `pppd`, the difference between Deflate and your typical modem > > on the data that is compressed should be about the difference you see > > between `compress` and `gzip`, or around a 10% improvement in compression > > ratio but at a ~2X cost in CPU cycles, and mostly on the side that does > > not have cycles to waste, the HTTP server. > > > > The server can cache the compressed object, and only compress it once. > > Our measurements show a much greater effect of compression than 10%; > see: http://www.w3.org/Protocols/HTTP/Performance/#Compression > > This are measurements over real modems. That difference is much larger than 10%, but you neglected to mention the brand or even variety (e.g. v.34 vs. v.32) of the modems. Your modems did about 20 kbit/sec, so they could not have been v.32, but they have been either v.32bis or v.34. You also omitted TCP window sizes and mention of the CTE-DTE speeds, both of which have large effects. With the high latencies of modem links, you really want a TCP window of more than 1 or 2 segments, despite the fact that some TCP/IP/PPP stacks for PCs think 2 segments is a lot. That your modems appeared to move data at the same speed regardless of whether data was compressable (i.e. precompressed or not) suggests that v.42bis was turned off. Please do the obvious sanity check. If modem compression were as absolutely useless as your numbers say, then why would anyone bother? That your compressed and uncompressed HTML differed 11K vs. 42K means that your HTML is over the line into embarassingly compressable territory. (I could easily believe that most image-free HTML is over that line.) Your test obviously, as you note, did not have involved any images, which makes it a less than especially interesting test. Over the years, I've made a bunch of measurements of precompressed, random, ordinary, and embarrassingly compressable data (e.g. `ttcp` or `ping` without -P) through SLIP/modems and PPP/modems. At my previous major UNIX vendor employer, I maintained the UUCP/PPP/cu/SLIP/etc modem configuration scripts in my spare time, along with doing PPP, and cajoled the loan of a pair of modems from everyone who wanted another modem supported so that I could tune the scripts and make some measurements. There is no such thing as a "standard modem" as mentioned in your report. All modems claim to support various standards, but their performance varies radically, whether you are concerned with analog issues (i.e. phone lines) or bit moving. I've seen variations up to a factor of 4 just by switching modems at a single modem-to-modem bit rate; never mind the modems that simply do not work on some phone lines. For example one ome major brand of v.32bis modem seemed to be unable to send at the same time it was receiving, or vice versa, and so its performance with ordinary data with TCP/IP/PPP/modem is other than impressive because of TCP ACKs. (v.32bis is the old, pre-"56K" standard.) You can compare for yourself the effects of modem compression by itself with Deflate compression by itself comparing `gzip` with `compress` on your HTML pages. (You might want `compress -b10` to make LZW as poor as the worst v.42bis modems.) I bet you will rarely see more than 10% and will never more than 25% difference between LZ78 (or is it LZ77?) used in gzip and Deflate compared to the LZW used in v.42bis (modems) and `compress`. (This obvious test is the standard counter to modem and PPP box salescritters that claim that their boxes get "8:1" or "9:1" on "typical" data.) Note that the v.42bis modem compression standard says that when a modem notices that the data did not compress, it should send it in the clear. That means that once you've paid latency that v.42 packetizing costs, v.42bis compression is free--well, only in good modems. There are of junk modems that can move data or compress but not both, and not very well. Lest you say that the junk modems prove your point, I've found the USR Couriers, among some others, to be other than junk. The last time I bought one, it cost me about $250. Never mind the effects of PPP compression. I have clocked my favorite flavor of CCP at 3-digit compression ratios over real links, with data patterns used in `ttcp` or `ping` without -P. (I added -P to the `ping` program seen in some systems precisesly to foil modem and PPP compression.) Vernon Schryver vjs@rhyolite.com From rgupta@ch1.vsnl.net.in Sat Sep 19 06:09:07 1998 Received: from ch1.vsnl.net.in (ch1.vsnl.net.in [202.54.25.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id GAA20145 for ; Sat, 19 Sep 1998 06:08:44 -0400 (EDT) Received: from ch122.pppch.vsnl.net.in by ch1.vsnl.net.in; (5.65v3.2/1.1.8.2/06Nov96-0858PM) id AA09746; Sat, 19 Sep 1998 15:41:27 +0500 Message-Id: <030101bde3b6$2767a9a0$921936ca@internet> Reply-To: "Trident" From: "Trident" To: , , , , , , , , Subject: Fw: Date: Sat, 19 Sep 1998 15:23:16 +0530 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01BDE3E1.6C9FCA40" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_013A_01BDE3E1.6C9FCA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable www.tridentindia.com Dear Friend, =20 =20 Trident group has made a humble beginning in 1985 in Core Sector = Fertilizer Industry. In just thirteen years, the Company has grown into = more than Ten Companies, Trident Group with diversification in field of = Paper & Pulp, Chemicals, Cotton & Acrylic Yarn, Bio-Tech, Terry Towels = and Yarn Processing and Information Technology. =20 The group is known for Quality Products and Efficient Services. Four = Companies of the Group have ISO- 9000 certification. =20 The Trident Group is now gearing up to enter a dynamic new era. There = are major expansion and consolidation programmes in all existing = Companies and several new projects, to be implemented in the near = future. =20 The Group=92s turnover has grown from a meagre Rs. 9.00 Crores in = 1985-86 to more than 200 Crores in 1998. =20 The group has vision of becoming "Rs. 1000 Crores of worth Trident Group = Assets by 2000 A.D." =20 Trident Infotech Corporation Ltd. (TICL) was incorporated in 1996 to = provide comprehensive IT Services. =20 During the first few years of its operations, TICL has developed = confidence among its business partners & clients. It offers services in = the following areas: =20 =20 a.. Software Exports=20 b.. Software development using data base, 4GLs and Graphical User = Interface=20 c.. Feasibility & System Study=20 d.. Selection of Hardware, Software etc.=20 e.. Networking Consultancy=20 f.. Business process re-engineering=20 g.. Computer Aided design and Graphics=20 h.. Computer Education & Training=20 i.. Corporate Training=20 j.. Key Entry TICL Strategic Alliances a.. Microsoft, USA, as Microsoft Certified Solution Provider and = Authorised Trainer.=20 b.. Oracle Inc., USA, as qualified "Value Added Alliance Partners"=20 c.. Autodesk Inc., USA, as Auuthorised Training Centre for AutoCAD & = Related products.=20 =20 Skillset =20 TICL has a team of Software engineers and consultants. Most ofd them = have good working knowledge of: a.. Windows NT/Windows 98=20 b.. MS SQL Server/Oracle 8/MS Access=20 c.. Visual Basic/Visual C++/PowerBuilder/Visual Foxpro=20 d.. Developer 2000/Designer 2000/Oracle DBA=20 e.. AutoCAD/3D Studio=20 f.. Digitization and GIS=20 g.. Network Management Trident ERP solution has been developed for Indian Business houses, = process and Manufacturing Industry. Efforts of 150 man years by = dedicated team of Software Professionals, Chartered Accountants, = Engineers & MBAs have gone into the development of the product, which = has been successfully implemented in Companies engaged in business of = Paper, Yarn, Terry Towel, Fertilizer and Chemicals. =20 To know more, Visit us at: www.tridentindia.com =20 =20 Trident Infotech Corporation Limited, S.C.O. 20-21, Madhya Marg, Sector-9D, Chandigarh - INDIA Phone : (0172) 743008, 743672 Fax : (0172) 742612 E-Mail : rgupta@ch1.vsnl.net.in ------=_NextPart_000_013A_01BDE3E1.6C9FCA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
www.tridentindia.com
Dear Friend,
 
 
Trident = group has made=20 a humble beginning in 1985 in Core Sector Fertilizer Industry. In just = thirteen=20 years, the Company has grown into more than Ten Companies, Trident Group = with=20 diversification in field of Paper & Pulp, Chemicals, Cotton & = Acrylic=20 Yarn, Bio-Tech, Terry Towels and Yarn Processing and Information=20 Technology.
 
The group is known = for Quality=20 Products and Efficient Services. Four Companies of the Group have ISO- = 9000=20 certification.
 
The Trident Group is = now gearing=20 up to enter a dynamic new era. There are major expansion and = consolidation=20 programmes in all existing Companies and several new projects, to be = implemented=20 in the near future.
 
The Group’s = turnover has=20 grown from a meagre Rs. 9.00 Crores in 1985-86 to more than 200 Crores = in=20 1998.
 
The group has vision = of becoming=20 "Rs. 1000 Crores of worth Trident Group Assets by 2000=20 A.D."
 
Trident Infotech = Corporation Ltd.=20 (TICL) was incorporated in 1996 to provide comprehensive IT=20 Services.
 
During the first few = years of its=20 operations, TICL has developed confidence among its business partners = &=20 clients. It offers services in the following areas:
 
     
  • Software Exports=20
  • Software development using data = base, 4GLs=20 and Graphical User Interface=20
  • Feasibility & System = Study=20
  • Selection of Hardware, Software = etc.=20
  • Networking Consultancy=20
  • Business process = re-engineering=20
  • Computer Aided design and = Graphics=20
  • Computer Education & = Training=20
  • Corporate Training=20
  • Key Entry
TICL Strategic=20 Alliances
  • Microsoft, USA, as Microsoft = Certified=20 Solution Provider and Authorised Trainer.=20
  • Oracle Inc., USA, as = qualified=20 "Value Added Alliance Partners"=20
  • Autodesk Inc., USA, as = Auuthorised=20 Training Centre for AutoCAD & Related products.=20
     
Skillset
 
TICL has a team of = Software=20 engineers and consultants. Most ofd them have good working knowledge=20 of:
  • Windows NT/Windows 98=20
  • MS SQL Server/Oracle 8/MS = Access=20
  • Visual Basic/Visual = C++/PowerBuilder/Visual=20 Foxpro=20
  • Developer 2000/Designer = 2000/Oracle=20 DBA=20
  • AutoCAD/3D Studio=20
  • Digitization and GIS=20
  • Network = Management
Trident ERP solution = has been=20 developed for Indian Business houses, process and Manufacturing = Industry.=20 Efforts of 150 man years by dedicated team of Software Professionals, = Chartered=20 Accountants, Engineers & MBAs have gone into the development of the = product,=20 which has been successfully implemented in Companies engaged in business = of=20 Paper, Yarn, Terry Towel, Fertilizer and Chemicals.
 
To know more, Visit = us=20 at:
www.tridentindia.com
 
 
Trident Infotech = Corporation=20 Limited,
S.C.O. 20-21, Madhya = Marg,=20 Sector-9D,
Chandigarh - = INDIA
Phone : (0172) = 743008,=20 743672
Fax : (0172) = 742612
E-Mail : rgupta@ch1.vsnl.net.in<= /DIV>
 
------=_NextPart_000_013A_01BDE3E1.6C9FCA40-- From owner-tcp-impl@cthulhu.engr.sgi.com Mon Sep 21 15:03:10 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23053 for ; Mon, 21 Sep 1998 15:03:09 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id MAA24427; Mon, 21 Sep 1998 12:01:06 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA00726; Mon, 21 Sep 1998 12:02:37 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03067; Mon, 21 Sep 1998 12:02:21 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA55871 for tcp-impl-list; Mon, 21 Sep 1998 11:52:48 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA37527 for ; Mon, 21 Sep 1998 11:52:46 -0700 (PDT) mail_from (ahobson@computer.eng.mindspring.net) Received: from computer.eng.mindspring.net (computer.eng.mindspring.net [207.69.192.185]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05702 for ; Mon, 21 Sep 1998 11:52:45 -0700 (PDT) mail_from (ahobson@computer.eng.mindspring.net) Received: (from ahobson@localhost) by computer.eng.mindspring.net (8.8.8/8.8.4) id OAA21346; Mon, 21 Sep 1998 14:52:38 -0400 (EDT) From: Andrew Hobson To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: OO TCP implementations? References: <199809160709.JAA03925@nix.cs.kuleuven.ac.be> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 21 Sep 1998 14:52:37 -0400 In-Reply-To: Sam Michiels's message of "Wed, 16 Sep 1998 09:09:54 +0200 (MET DST)" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.4/XEmacs 21.0(beta36) - "Philippine" X-Face: (e_H,)"'M4u!E!3"|XVHJ=[/_.:z73Z^oGf")[Payuf said: > Hello, > I was wondering if anybody of you knows about an Object-Oriented > design/implementation of TCP? Not exactly Object-Oriented, but has information on an implementation of an HTTP server and TCP stack in Standard ML. Drew -- There followed a period of embarrassment as the rumour went round London that Joey Mellen had trepanned himself, whereas in fact he had failed to do so. From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 24 00:28:00 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA26958 for ; Thu, 24 Sep 1998 00:27:59 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA12523; Wed, 23 Sep 1998 21:26:11 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id UAA04789; Wed, 23 Sep 1998 20:05:43 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA09321; Wed, 23 Sep 1998 19:34:07 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA55551 for tcp-impl-list; Wed, 23 Sep 1998 19:32:01 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA69963 for ; Wed, 23 Sep 1998 19:31:56 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA05377 for ; Wed, 23 Sep 1998 19:31:56 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA22037; Wed, 23 Sep 1998 19:31:24 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id TAA12769; Wed, 23 Sep 1998 19:31:22 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id TAA01350; Wed, 23 Sep 1998 19:31:23 -0700 (PDT) Date: Wed, 23 Sep 1998 19:31:22 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: NewReno and the 2001 Revision To: tomh@CS.Berkeley.EDU Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > testbed consistently takes a 30% hit in throughput when SACK with Reno > congestion avoidance is used instead of SACK with ``NewReno.'' In general, Can you describe what you meant by SACK with Reno and SACK with NewReno? With NewReno, upon receiving a partial ACK, the first unack'ed segment is retransmitted immediately. So how do you use SACK info here? Do you retransmit more than one segment using SACK info? Or do you check that the first unack'ed segment is indeed lost before retransmitting it? And if the first unack'ed segment is not lost, you use the SACK info to retransmit the next lost segment? K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 24 00:28:00 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA26960 for ; Thu, 24 Sep 1998 00:28:00 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA12593; Wed, 23 Sep 1998 21:26:20 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id UAA05030; Wed, 23 Sep 1998 20:06:06 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA00910; Wed, 23 Sep 1998 19:28:54 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA20329 for tcp-impl-list; Wed, 23 Sep 1998 19:25:20 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA06816 for ; Wed, 23 Sep 1998 19:25:17 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA06042 for ; Wed, 23 Sep 1998 19:25:17 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA21437; Wed, 23 Sep 1998 19:25:14 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id TAA00898; Wed, 23 Sep 1998 19:25:14 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id TAA01345; Wed, 23 Sep 1998 19:25:13 -0700 (PDT) Date: Wed, 23 Sep 1998 19:25:13 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: NewReno and the 2001 Revision To: mallman@lerc.nasa.gov Cc: tcp-impl@cthulhu.engr.sgi.com, Vern Paxson In-Reply-To: "Your message with ID" <199809111306.JAA06298@guns.lerc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > one ``congestion event''. We would like to hear comments on whether > or not such a bug fix should be included in the 2001 revision. I'd suggest putting the bug fix in the 2001 revision but leave out NewReno. IMHO, we should come up with a draft on the use of SACK in recovery instead of spending effort on experimental documents describing NewReno and other variants. As Sally pointed out in the IETF meeting, we can easily come up with scenarioes where NewReno and its variants work badly or too aggressively. But with SACK, we can do better. As of now, there is no internet draft on how to make good use of SACK. I think in 1 year's time, SACK should be widely deployed. So we should focus on how to make good use of SACK info, and also how to avoid abusing it. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 24 01:50:00 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA27551 for ; Thu, 24 Sep 1998 01:50:00 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA04569; Wed, 23 Sep 1998 22:48:14 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id WAA15734; Wed, 23 Sep 1998 22:49:46 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA05432; Wed, 23 Sep 1998 22:49:41 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA12081 for tcp-impl-list; Wed, 23 Sep 1998 22:45:28 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA60602 for ; Wed, 23 Sep 1998 22:45:26 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from raptor.CS.Berkeley.EDU (raptor.CS.Berkeley.EDU [128.32.130.30]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA01985 for ; Wed, 23 Sep 1998 22:45:26 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from localhost (tomh@localhost) by raptor.CS.Berkeley.EDU (8.8.5/8.8.5) with SMTP id WAA26140; Wed, 23 Sep 1998 22:45:25 -0700 (PDT) Date: Wed, 23 Sep 1998 22:45:24 -0700 (PDT) From: Tom Henderson Reply-To: tomh@CS.Berkeley.EDU To: Kacheong Poon cc: tcp-impl@cthulhu.engr.sgi.com Subject: Re: NewReno and the 2001 Revision In-Reply-To: Message-ID: Organization: UC Berkeley Computer Science X-Url: http://www.cs.berkeley.edu/~tomh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk On Wed, 23 Sep 1998, Kacheong Poon wrote: > Can you describe what you meant by SACK with Reno and SACK with NewReno? With First, let me define NewReno for the purpose of this discussion. NewReno is Reno with the following changes: i) define a variable (snd_recover) that is set to snd_max upon entering fast recovery. When snd_una reaches snd_recover, the fast recovery phase is considered to be over. ii) if a partial cumulative ack is received (ti_ack < snd_recover), retransmit the next segment beyond ti_ack, deflate snd_cwnd by the amount of new data acknowledged, add back one segment to snd_cwnd, and send a new segment if permitted. iii) if a new ack is received with (ti_ack >= snd_recover), set snd_cwnd to min(snd_ssthresh, amount of outstanding data in the network + 1 segment) and otherwise exit fast recovery as in Reno. iv) do not reset snd_recover upon a rtx timeout. If three dupacks are received and (ti_ack < snd_recover), do not perform fast retransmit/fast recovery but instead just advance snd_cwnd by one segment and send the next segment (snd_nxt). This is avoidance of false fast retransmission after a timeout. When combining SACK with NewReno, the SACK information may permit you to identify segments that need to be retransmitted before you receive the partial cumulative ack. In our implementation, if the SACK information indicates that the receiver is holding a segment sent at least 3 segments beyond a given segment that is not SACKed, the given segment is eligible for retransmission. If we send such a retransmission ``early'' (i.e., before partial cumulative ack), we decrement the inflated snd_cwnd by one segment to account for this (in essence, we trade sending a new segment off the top of the window for the early retransmission). If we later get a partial cumulative ack, but the next segment has already been retransmitted, snd_cwnd is inflated by one segment. In summary, in our implementation, SACK information permits the substitution of an early retransmission for inflating snd_cwnd by one segment, in a manner consistent with the allowable amount of outstanding data in the network under NewReno rules. This reordering of retransmissions and new transmissions allows recovery to occur in fewer RTTs. SACK with Reno also allows you to send retransmissions early (as defined above), but suffers from the multiple window reductions in one window of data and false fast retransmission problems. Tom p.s. I'd like to hear if my outline of what I called NewReno above is consistent with the ``bug fix'' people had in mind, as I know the term NewReno can mean different things to different people. From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 24 02:04:23 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA27654 for ; Thu, 24 Sep 1998 02:04:22 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA09070; Wed, 23 Sep 1998 23:02:40 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id XAA19663; Wed, 23 Sep 1998 23:04:12 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA01598; Wed, 23 Sep 1998 23:04:05 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id XAA05292 for tcp-impl-list; Wed, 23 Sep 1998 23:00:23 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id XAA00863 for ; Wed, 23 Sep 1998 23:00:21 -0700 (PDT) mail_from (davem@dm.cobaltmicro.com) Received: from dm.cobaltmicro.com (dm.cobaltmicro.com [209.133.34.35]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA07768 for ; Wed, 23 Sep 1998 23:00:20 -0700 (PDT) mail_from (davem@dm.cobaltmicro.com) Received: (from davem@localhost) by dm.cobaltmicro.com (8.8.7/8.8.7) id WAA10467; Wed, 23 Sep 1998 22:56:41 -0700 Date: Wed, 23 Sep 1998 22:56:41 -0700 Message-Id: <199809240556.WAA10467@dm.cobaltmicro.com> From: "David S. Miller" To: tomh@CS.Berkeley.EDU CC: Kacheong.Poon@Eng.Sun.COM, tcp-impl@cthulhu.engr.sgi.com In-reply-to: (message from Tom Henderson on Wed, 23 Sep 1998 22:45:24 -0700 (PDT)) Subject: Re: NewReno and the 2001 Revision References: Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Date: Wed, 23 Sep 1998 22:45:24 -0700 (PDT) From: Tom Henderson p.s. I'd like to hear if my outline of what I called NewReno above is consistent with the ``bug fix'' people had in mind, as I know the term NewReno can mean different things to different people. To remove confusion I usually refer to it as "Hoe style retransmits", to directly reference the retransmit strategy changes suggested by Janie Hoe's paper. I think this bug fix is useful in the case where SACK is not being used. There are going to be many non-SACK stacks still around even when SACK is moderately prevalent and deployed. (I still see a packet trace involving a KA9Q stack from time to time even today :-) SACK is in my experience of implementation more powerful with other techniques such as FACK, so much so that any benefits the newreno changes give you are lost in the noise. Later, David S. Miller davem@dm.cobaltmicro.com From owner-tcp-impl@cthulhu.engr.sgi.com Thu Sep 24 02:48:27 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA27824 for ; Thu, 24 Sep 1998 02:48:26 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA20043; Wed, 23 Sep 1998 23:46:44 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id TAA18362; Wed, 23 Sep 1998 19:20:32 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA07756; Wed, 23 Sep 1998 19:20:15 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA67109 for tcp-impl-list; Wed, 23 Sep 1998 19:13:25 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA29570 for ; Wed, 23 Sep 1998 19:13:23 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA05854 for ; Wed, 23 Sep 1998 19:13:22 -0700 (PDT) mail_from (Kacheong.Poon@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA20059; Wed, 23 Sep 1998 19:13:21 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id TAA00068; Wed, 23 Sep 1998 19:13:20 -0700 Received: from shield.eng.sun.com (shield.Eng.Sun.COM [129.146.85.114]) by shield.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id TAA01340; Wed, 23 Sep 1998 19:13:15 -0700 (PDT) Date: Wed, 23 Sep 1998 19:13:06 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: viewgraphs on revisions to RFC 2001 To: Sally Floyd Cc: tcp-impl@cthulhu.engr.sgi.com In-Reply-To: "Your message with ID" <199808300130.SAA19711@owl.ee.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > 5A. When a non-duplicate ACK arrives that covers "recover", > follow step 5 above. When a non-duplicate ACK arrives > that does not cover "recover" (i.e., a "partial ack"), > retransmit the first unacknowledged segment. (This is > "NewReno".) Do not change cwnd or ssthresh, but deflate > the congestion window by removing the additive term with > the count of duplicate acknowledgements. For the first > partial ACK that arrives, also reset the retransmit timer. A very late reply... Just to repeat what I mentioned in the IETF meeting. The reason to reset the retransmit timer only for the first partial ACK is to avoid a stop and go behaviour. But this also limits the number of segments NewReno can recover. An implementation with a coarse grain timer, like in BSD RTO is in the order of 500ms, can recover more segments than an implementation with a finer grain timer. The number of segments which can be recovered also depends on the RTT. For a satellite link, RTT is ~520ms. Say with BSD, RTO may be 1.5s for such link. That means NewReno can only recover 2 additional segments before a timeout happens. And for such LFN, TCP window is usually very large. It is likely that more than 3 segments can be dropped in a window. In [H96], the algorithm suggested is a little bit different from the above. During the fast retransmit phase, a slow start like mechanism is used. That means for one RTT, more than one segment can be recovered. NewReno can only recover one segment. This reduces the impact of stop and go behaviour. This is more aggressive and can potentially retransmit quite a few duplicate segments. But for LFN, this can be a big help. For relatively small window and short RTT, the gain is small compared to NewReno. K. Poon. kcpoon@eng.sun.com From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 25 01:14:55 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA29482 for ; Fri, 25 Sep 1998 01:14:54 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA18874; Thu, 24 Sep 1998 22:12:55 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id WAA15301; Thu, 24 Sep 1998 22:14:24 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA05341; Thu, 24 Sep 1998 09:59:51 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA94980 for tcp-impl-list; Thu, 24 Sep 1998 09:52:52 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA84098 for ; Thu, 24 Sep 1998 09:52:51 -0700 (PDT) mail_from (raj@cup.hp.com) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA02900 for ; Thu, 24 Sep 1998 09:52:50 -0700 (PDT) mail_from (raj@cup.hp.com) Received: from loiter.cup.hp.com (root@loiter.cup.hp.com [15.13.104.252]) by atlrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id MAA18184 for ; Thu, 24 Sep 1998 12:52:17 -0400 (EDT) Received: from cup.hp.com (raj@loiter [15.13.104.252]) by loiter.cup.hp.com with ESMTP (8.8.6/8.7.3 TIS Messaging 5.0) id JAA02373 for ; Thu, 24 Sep 1998 09:52:46 -0700 (PDT) Message-ID: <360A78DE.8235DE14@cup.hp.com> Date: Thu, 24 Sep 1998 09:52:46 -0700 From: Rick Jones Organization: HP 9000 Network Performance X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/735) MIME-Version: 1.0 To: tcp-impl@cthulhu.engr.sgi.com Subject: Re: NewReno and the 2001 Revision References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Tom Henderson wrote: > > On Wed, 23 Sep 1998, Kacheong Poon wrote: > > > Can you describe what you meant by SACK with Reno and SACK with NewReno? With > > First, let me define NewReno for the purpose of this discussion. NewReno is > Reno with the following changes: > i) define a variable (snd_recover) that is set to snd_max upon entering fast > recovery. When snd_una reaches snd_recover, the fast recovery phase is > considered to be over. > ii) if a partial cumulative ack is received (ti_ack < snd_recover), retransmit > the next segment beyond ti_ack, deflate snd_cwnd by the amount of new > data acknowledged, add back one segment to snd_cwnd, and send a new segment > if permitted. > iii) if a new ack is received with (ti_ack >= snd_recover), set snd_cwnd to > min(snd_ssthresh, amount of outstanding data in the network + 1 segment) > and otherwise exit fast recovery as in Reno. I'll have to ask the guys currently supporting MPE/iX, but I think that the behaviour described in i has been present in the MPE/XL (now iX) TCP stack since we implemented congestion control and avoidance. ii has been present in that the next segment after the ACK would be sent, but I do not recall new data being allowed. that stack would then start from a cwnd of 1 upon iii. At the time (89-90ish) it worked pretty well for aggregate file transfers over 9600 baud dial-ups. rick jones -- these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, or post, but please do not do both... my email address is raj in the cup.hp.com domain... From owner-tcp-impl@cthulhu.engr.sgi.com Fri Sep 25 15:45:49 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA13991 for ; Fri, 25 Sep 1998 15:45:48 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id MAA25339; Fri, 25 Sep 1998 12:43:02 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id MAA26241; Fri, 25 Sep 1998 12:44:34 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA06493; Fri, 25 Sep 1998 12:44:30 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA52780 for tcp-impl-list; Fri, 25 Sep 1998 12:37:00 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA24687 for ; Fri, 25 Sep 1998 12:36:59 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from assateague.lerc.nasa.gov (assateague-fi.lerc.nasa.gov [139.88.112.23]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA07286 for ; Fri, 25 Sep 1998 12:36:57 -0700 (PDT) mail_from (mallman@guns.lerc.nasa.gov) Received: from guns.lerc.nasa.gov (guns.lerc.nasa.gov [139.88.44.160]) by assateague.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id PAA13093; Fri, 25 Sep 1998 15:36:53 -0400 (EDT) Received: from guns by guns.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id PAA08985; Fri, 25 Sep 1998 15:36:53 -0400 (EDT) Message-Id: <199809251936.PAA08985@guns.lerc.nasa.gov> To: Kacheong Poon From: Mark Allman Reply-To: mallman@lerc.nasa.gov cc: tcp-impl@cthulhu.engr.sgi.com, Vern Paxson Subject: Re: NewReno and the 2001 Revision Organization: Late Night Hackers, NASA LeRC, Cleveland, Ohio Song-of-the-Day: Bad to the Bone Date: Fri, 25 Sep 1998 15:36:52 -0400 Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk > As Sally pointed out in the IETF meeting, we can easily come up > with scenarioes where NewReno and its variants work badly or too > aggressively. But with SACK, we can do better. I think no matter what TCP we have, we can always come up with scenarios where things don't work particularly well. I have seen presentations on situations in which SACK based algorithms are suboptimal, as well. > As of now, there is no internet draft on how to make good use of > SACK. I think in 1 year's time, SACK should be widely deployed. > So we should focus on how to make good use of SACK info, and also > how to avoid abusing it. OK, I am with you on the last statement. We don't want people to abuse SACK information and make an inappropriately agressive TCP. That is why we inserted the statement on SACK in 2001.bis. The paragraph essentially says that SACK algorithms must follow the spirit of the non-SACK congestion control algorithms (see the statement in the draft for a better (I hope!) description). But, at this point I am not sure that the research into a SACK-based algorithm is done, or near a point where it is time to determine which algorithm is ``the best'' and standardize it. So, it seems to me that the appropriate approach is to outline the general principles that should guide the development of SACK-based algorithms, in order to prevent such algorithms from hurting the network and contributing to congestion collapse. However, it seems less important to try to decide which SACK-based algorithm is the best and standardize it (at least at this time). But, I've been wrong before... allman From owner-tcp-impl@cthulhu.engr.sgi.com Wed Sep 30 02:23:31 1998 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA04404 for ; Wed, 30 Sep 1998 02:23:30 -0400 (EDT) Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id XAA19904; Tue, 29 Sep 1998 23:21:01 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id TAA20695; Tue, 29 Sep 1998 19:18:31 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA09038; Tue, 29 Sep 1998 19:18:14 -0700 (PDT) mail_from (owner-tcp-impl@cthulhu.engr.sgi.com) Received: (from majordomo-owner@localhost) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA24279 for tcp-impl-list; Tue, 29 Sep 1998 19:09:58 -0700 (PDT) mail_from (owner-tcp-impl@relay.engr.sgi.com) Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA20857 for ; Tue, 29 Sep 1998 19:09:56 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from raptor.CS.Berkeley.EDU (raptor.CS.Berkeley.EDU [128.32.130.30]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA03311 for ; Tue, 29 Sep 1998 19:09:45 -0700 (PDT) mail_from (tomh@raptor.CS.Berkeley.EDU) Received: from localhost (tomh@localhost) by raptor.CS.Berkeley.EDU (8.8.5/8.8.5) with SMTP id TAA03037; Tue, 29 Sep 1998 19:09:40 -0700 (PDT) Date: Tue, 29 Sep 1998 19:09:40 -0700 (PDT) From: Tom Henderson Reply-To: tomh@CS.Berkeley.EDU To: tcp-impl@cthulhu.engr.sgi.com, tcpsat@lerc.nasa.gov cc: semke@psc.edu Subject: BSD/OS 3.0 TCP SACK code available Message-ID: Organization: UC Berkeley Computer Science X-Url: http://www.cs.berkeley.edu/~tomh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tcp-impl@cthulhu.engr.sgi.com Precedence: bulk Apologies to multiple recipients... The UCB Daedalus research group announces the availability of revised TCP SACK source code and patches for BSD/OS 3.0. This revision to the BSD/OS 2.1 code, which has been available since 1996 and in use by our research group since that time, contains the following modifications: o Congestion avoidance is based on Reno with the following bug fixes, which we label ``NEWRENO'': - Avoidance of multiple window reductions during fast recovery when multiple losses occur in one window of data. - Avoidance of false fast retransmissions after a timeout. o The basic PSC FACK algorithm can be optionally compiled with SACK. Details of the specific policies implemented are available in the ``README.policy'' file with the code. tcpdump source code modifications for viewing SACK information are also in the ftp repository. See the following locations: ftp://daedalus.cs.berkeley.edu/pub/tcpsack/bsdi-3.0 or http://http.cs.berkeley.edu/~tomh/sack.html (html version of the README file) Hari Balakrishnan, Tom Henderson, and Venkat Padmanabhan UC Berkeley Daedalus Research Group (http://daedalus.cs.berkeley.edu)