From owner-freebsd-net@FreeBSD.ORG  Wed May 28 10:12:01 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 789D937B401
	for <net@FreeBSD.org>; Wed, 28 May 2003 10:12:01 -0700 (PDT)
Received: from mail12.uunet.ca (mail12.uunet.ca [142.77.1.49])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8676E43F75
	for <net@FreeBSD.org>; Wed, 28 May 2003 10:12:00 -0700 (PDT)
	(envelope-from kfl@xiphos.ca)
Received: from tick ([216.95.199.148]) by mail12.uunet.ca with SMTP id
	<96662-2471>; Wed, 28 May 2003 12:45:55 -0400
From: "kfl" <kfl@xiphos.ca>
To: "freebsd - net" <net@FreeBSD.org>
Date: Wed, 28 May 2003 12:55:47 -0400
Message-ID: <JCEDLMKGMLLELHAJNIHJKEGHEJAA.kfl@xiphos.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: FW: TCP for transaction
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2003 17:12:01 -0000



> -----Original Message-----
> From: kfl [mailto:kfl@xiphos.ca]
> Sent: Wednesday, May 28, 2003 12:53 PM
> To: freebsd - net
> Subject: TCP for transaction
>
>
>
> 	Here is a tcpdump output from one FreeBSD box with TCP for
> transaction enabled and a client supporting the NO_PUSH
> setsockopt with a windows box:
>
> 19:00:15.357281 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: SP
> 4208572194:420
> 8572331(137) win 65535 <mss 1460,nop,wscale 2,nop,nop,ccnew 2> (DF)
> 19:00:15.357514 192.168.2.7.microsoft-ds > 192.168.3.200.1247: S
> 2795532295:2795
> 532295(0) ack 4208572195 win 61680 <mss 1460,nop,wscale 2> (DF)
> 19:00:15.357911 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: .
> ack 1 win 52560
>  (DF)
> 19:00:18.356736 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P
> 1:138(137) ack
> 1 win 52560 (DF)
> 19:00:18.357465 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P
> 1:90(89) ack 13
> 8 win 61646 (DF)
> 19:00:18.456659 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: .
> ack 90 win 5256
> 0 (DF)
> 19:00:20.611227 192.168.3.200.1247 > 192.168.2.7.microsoft-ds: P
> 138:336(198) ac
> k 90 win 52560 (DF)
> 19:00:20.612037 192.168.2.7.microsoft-ds > 192.168.3.200.1247: P
> 90:359(269) ack
>  336 win 61597 (DF)
>
> I see two problems here (in fact its only one problem with a side effect):
>
> 	1) When sending the ccnew option T/TCP send data with it.
> 	2) As a results the sender times out and retransmit at
> 19:00:18.356736
> 	   adding 3 seconds to the connection data transfer.
>
> Now, in the rfc1644 it is stipulated that a host can send data
> with the cc.new option. I am a bit confused here since T/TCP
> should accelerate data transfer for small transaction (saving 1
> RTT) and not timing out if the destination host does not support it.
>
> 	I think we should avoid sending data with the cc.new option.
>
> Any thoughs?
>
> Karim Fodil-Lemelin
> Network Engineering.
> Xiphos Technologies
> www.xiphos.com
>