From owner-freebsd-net@FreeBSD.ORG Fri Nov 5 21:46:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F87916A4CE; Fri, 5 Nov 2004 21:46:06 +0000 (GMT) Received: from mail.net (custpop.ca.mci.com [142.77.1.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FCE43D58; Fri, 5 Nov 2004 21:46:05 +0000 (GMT) (envelope-from kfl@xiphos.ca) Received: from [216.95.199.148] (account kfl@xiphos.ca HELO [192.168.1.7]) by mail.net (CommuniGate Pro SMTP 4.2.5) with ESMTP id 26469084; Fri, 05 Nov 2004 16:46:04 -0500 Message-ID: <418BF7EA.2020404@xiphos.ca> Date: Fri, 05 Nov 2004 17:00:10 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <418BB008.6040907@xiphos.ca> <418BAE54.72E4208F@freebsd.org> <418BB7BC.3010305@xiphos.ca> <418BB909.501CC9FD@freebsd.org> In-Reply-To: <418BB909.501CC9FD@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Matt Sealey cc: mallman@icir.org cc: Julian Elischer cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2004 21:46:06 -0000 Ok here is an example, just to make sure I understand: CLI1 : SERVER1 (first connection, option negociated, tuple hash created) CLI1 : SERVER1 (second connection, sending payload in first packet, using previously negotiated cookie) ... CLI1 : SERVER1 ( nth connection, sending payload in first packet, using previously negotiated cookie ) CLI1 : SERVER2 (first connection, option negociated, tuple created) CLI1 : SERVER2 (second connection, sending payload in first packet, using previously negotiated cookie) ... CLI1 : SERVER2 ( nth connection, sending payload in first packet, using previously negotiated cookie ) ... CLIX : SERVERY ( if first connection create cookie, store tuple. if tuple exists send payload in first packet) So, each time CL1 goes to a different server it pay the 3WSH tax only once. This is very alike how T/TCP works right now (beside the cookie thing). What I am wondering is how can we avoid as much as possible the "learning" of the different servers since I know that CLIs will have to go through two gateways running transparent proxies that support the option (T/TCP). But since they are transparent (using forward rules) the gateway don't talk to each other but to the SERVERs (from an IP standpoint). For example, if the cookie was per machine and not tuples, you could have something like this: step 1: CLI1 : SERVER1 (first connection, option negociated, cookie negotiated) CLI1 : SERVER1 (second connection, sending payload in first packet, using previously negotiated cookie) ... step2: CLI1 : SERVER2 (first connection, option negociated, get the same machine cookie from "SERVER1" (found a transparent proxy)) (From now on CL1 assumes its going through a transparent proxy that can do T/TCP) CLI1 : SERVER3 (first connection, sending payload in first packet, using previously negotiated machine cookie, validating transparent proxy) (If the cookie returned by SERVER3 does not match the"machine cookie it found in SERVER1" then go back to step 1) This way the protocol would use knowledge that there is a transparent proxy (found at step2) that is doing T/TCP on behalf of the SERVERs. What do you think? Regards, Andre Oppermann wrote: >Karim Fodil-Lemelin wrote: > > >> In the case where all connections go through the SATLINK and are >>splitted by proxies, it make sense to use this knowledge and not >>renegotiate cookies for every connections since we know there is only >>one path to the internet and that all SATLINK connections will support >>(T/TCP or whatever name it will have). Do you have any plan to include >>that knowledge in your design or is it too much of a special case to >>really care? >> >> > >It does not renegotiate cookies for every connection. Only the first >connection will do that. Re-seeding of the cookies will happen trans- >parently. You pay the 3WSH tax only once for the first connection, or >the first connection after a longer idle time when the cookie expired. > > > -- Karim Fodil-Lemelin Lead Programmer Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com -------------------------------------------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this communication and any copy immediately. Thank you.