atom feed59 messages in org.freebsd.freebsd-archRemoving T/TCP and replacing it with ...
FromSent OnAttachments
Andre OppermannOct 21, 2004 7:33 am 
Poul-Henning KampOct 21, 2004 7:41 am 
Andre OppermannOct 21, 2004 7:46 am 
Richard WendlandOct 21, 2004 7:59 am 
Mike SilbersackOct 21, 2004 8:23 am 
Andre OppermannOct 21, 2004 8:37 am 
Bruce M SimpsonOct 21, 2004 8:40 am 
Andre OppermannOct 21, 2004 9:23 am 
Garrett WollmanOct 21, 2004 9:27 am 
Mark AllmanOct 21, 2004 10:31 am 
Andre OppermannOct 21, 2004 10:56 am 
Matt EmmertonOct 21, 2004 11:31 am 
Sean ChittendenOct 21, 2004 11:31 am 
Mark AllmanOct 21, 2004 11:32 am 
David O'BrienOct 21, 2004 11:51 am 
Andre OppermannOct 21, 2004 11:56 am 
Julian ElischerOct 21, 2004 11:59 am 
Garrett WollmanOct 21, 2004 12:02 pm 
Andre OppermannOct 21, 2004 12:02 pm 
Andre OppermannOct 21, 2004 12:04 pm 
Sean ChittendenOct 21, 2004 12:24 pm 
Marco MolteniOct 21, 2004 12:34 pm 
Igor SysoevOct 21, 2004 12:41 pm 
Craig RodriguesOct 21, 2004 6:46 pm 
Russell L. CarterOct 21, 2004 7:02 pm 
Julian ElischerOct 21, 2004 8:24 pm 
SUZUKI ShinsukeOct 22, 2004 12:47 am 
Dag-Erling SmørgravOct 22, 2004 5:06 am 
Dag-Erling SmørgravOct 22, 2004 5:47 am 
Andre OppermannOct 22, 2004 8:14 am 
Andre OppermannOct 22, 2004 8:17 am 
Brian Fundakowski FeldmanOct 22, 2004 8:44 am 
Andre OppermannOct 22, 2004 8:55 am 
Mark AllmanOct 22, 2004 11:24 am 
Peter LeiOct 22, 2004 5:59 pm 
Randall StewartOct 23, 2004 6:07 am 
Randall StewartOct 23, 2004 6:16 am 
Randall StewartOct 23, 2004 6:17 am 
Randall StewartOct 23, 2004 6:20 am 
Andre OppermannOct 23, 2004 7:16 am 
Randy BushOct 23, 2004 9:01 am 
SUZUKI ShinsukeOct 25, 2004 10:18 pm 
Randall StewartOct 26, 2004 3:41 am 
Peter LeiOct 26, 2004 7:44 am 
Karim Fodil-LemelinNov 4, 2004 9:52 am 
Andre OppermannNov 4, 2004 10:50 am 
Julian ElischerNov 4, 2004 12:52 pm 
Matt SealeyNov 4, 2004 12:58 pm 
Karim Fodil-LemelinNov 5, 2004 8:08 am 
Karim Fodil-LemelinNov 5, 2004 8:39 am 
Andre OppermannNov 5, 2004 8:45 am 
Karim Fodil-LemelinNov 5, 2004 9:12 am 
Andre OppermannNov 5, 2004 9:31 am 
Karim Fodil-LemelinNov 5, 2004 1:45 pm 
Andre OppermannNov 5, 2004 2:16 pm 
Mark AllmanNov 8, 2004 8:08 pm 
Andre OppermannJul 3, 2005 12:08 am 
Andre OppermannJul 3, 2005 11:43 am 
Randall StewartJul 3, 2005 11:44 am 
Subject:Removing T/TCP and replacing it with something simpler
From:Andre Oppermann (and@freebsd.org)
Date:Nov 5, 2004 2:16:45 pm
List:org.freebsd.freebsd-arch

Karim Fodil-Lemelin wrote:

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).

Yes, exactly. Actually the new T/TCP thing works the same as the old one from a functional point of view. What changes is the implementation. The original one was quite intrusive to the TCP code and generated many special cases which made it hard to maintain and to put new code in. In addition it CC* stuff is a rather weak and fragile mechanism. That's why we go with cookies this time and there are only a few places where the code has to be aware of it. Much less intrusive and more easy to maintain properly.

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?

I think that is nice. Sounds like homework for you. ;-)

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.

Xiphos Technologies Inc. (514) 848-9640 x223 (514) 848-9644 fax www.xiplink.com