Transaction TCP patch for Linux

Transaction TCP patch for Linux

[Laurence]

I'd like to be emailed comments or replies personally.

Transaction TCP is an extension for TCP. Its performance advantage is
indisputably better than standard TCP. But only FreeBSD integrates
TTCP into its kernel. So, I've started T/TCP for Linux at
http://ttcplinux.sourceforge.net or
http://sourceforge.net/projects/ttcplinux. I'm writing the kernel
patch for Linux kernel 2.4.2. Is anyone interested in it or have
anything to say about T/TCP's pros and cons??

Besides, I've finished some basic codes involving:
1. new structures
2. newly created or modified funtions mainly related to receiving

If anyone is interested, tell me and I'll send the codes. I don't want to upload the codes in CVS at this moment. At least, I want to have a basic but compile-able one.

Re: Transaction TCP patch for Linux

[Matti Aarnio]

On Mon, Feb 11, 2002 at 12:50:02AM +0800, Laurence wrote:
> I'd like to be emailed comments or replies personally.
> 
> Transaction TCP is an extension for TCP. Its performance advantage is
> indisputably better than standard TCP. But only FreeBSD integrates
> TTCP into its kernel. So, I've started T/TCP for Linux at
> http://ttcplinux.sourceforge.net or
> http://sourceforge.net/projects/ttcplinux. I'm writing the kernel
> patch for Linux kernel 2.4.2. Is anyone interested in it or have
> anything to say about T/TCP's pros and cons??

  http://theory.lcs.mit.edu/~mass/comm.html
  http://theory.lcs.mit.edu/~mass/forte96.html

  There Mark Smith shows that T/TCP does not (in all error cases)
  act the _same_ as TCP, although that does not necessarily mean
  it would be wrong.

  Reading  W.R.Stevens' book "TCP/IP Illustriated, Volume 3"
  gives a glimpse of how BSD did things in NET/3 code back
  in early 1994-1996, and there I see many odd bits like
  per-host route entires containing support data..


> Besides, I've finished some basic codes involving:
> 1. new structures
> 2. newly created or modified funtions mainly related to receiving
> 
> If anyone is interested, tell me and I'll send the codes. I don't want 
> to upload the codes in CVS at this moment. At least, I want to have a 
> basic but compile-able one.

/Matti Aarnio

Re: Transaction TCP patch for Linux

[bert hubert]

On Sun, Feb 10, 2002 at 04:49:55PM +0000, Laurence wrote:
> I'd like to be emailed comments or replies personally.
> 
> Transaction TCP is an extension for TCP. Its performance advantage is
> indisputably better than standard TCP. But only FreeBSD integrates
> TTCP into its kernel. So, I've started T/TCP for Linux at
> http://ttcplinux.sourceforge.net or
> http://sourceforge.net/projects/ttcplinux. I'm writing the kernel
> patch for Linux kernel 2.4.2. Is anyone interested in it or have
> anything to say about T/TCP's pros and cons??

I've seen people state that T/TCP is fundamentally broken:

http://groups.google.com/groups?q=alan+cox+%22t/tcp%22&hl=en&scoring=d&selm=linux.kernel.E14vGeS-0005Lu-00%40the-village.bc.nu&rnum=2

http://www.xent.com/FoRK-archive/feb99/0255.html

So I'm not sure if it is worth implementing.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

Re: Transaction TCP patch for Linux

[Alan Cox]

> > patch for Linux kernel 2.4.2. Is anyone interested in it or have
> > anything to say about T/TCP's pros and cons??
> 
> I've seen people state that T/TCP is fundamentally broken:
> http://groups.google.com/groups?q=alan+cox+%22t/tcp%22&hl=en&scoring=d&selm=linux.kernel.E14vGeS-0005Lu-00%40the-village.bc.nu&rnum=2
> http://www.xent.com/FoRK-archive/feb99/0255.html
> 
> So I'm not sure if it is worth implementing.

T/TCP in its current form is broken. Implementing it is still a fun exercise
for someone, and while nobody has pushed it forwards there is no reason to
believe it can't be fixed. You just have to write T/TCPv2 and draft the
rfc to fix it