From owner-freebsd-net@FreeBSD.ORG  Wed May 28 10:28:55 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 B8A8E37B401
	for <freebsd-net@freebsd.org>; Wed, 28 May 2003 10:28:55 -0700 (PDT)
Received: from mail12.uunet.ca (mail12.uunet.ca [142.77.1.49])
	by mx1.FreeBSD.org (Postfix) with ESMTP id F1BC143FBF
	for <freebsd-net@freebsd.org>; Wed, 28 May 2003 10:28:52 -0700 (PDT)
	(envelope-from kfl@xiphos.ca)
Received: from tick ([216.95.199.148]) by mail12.uunet.ca with SMTP id
	<94157-12743>; Wed, 28 May 2003 13:22:21 -0400
From: "kfl" <kfl@xiphos.ca>
To: "freebsd - net" <freebsd-net@freebsd.org>
Date: Wed, 28 May 2003 13:32:14 -0400
Message-ID: <JCEDLMKGMLLELHAJNIHJMEGJEJAA.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: 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:28:56 -0000

Hi,
	Here is a tcpdump output from one FreeBSD box with TCP for transaction
enabled and a client supporting the NOPUSH 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.