IETF Logo Mail Archive

Re: [hybi] TCP packet boundaries must not be assumed (was Re: With deflate-stream, Close frame doesn't work as an end of data marker)

Andy Green <andy@warmcat.com> Thu, 10 March 2011 12:20 UTC

Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B669C3A696F for <hybi@core3.amsl.com>; Thu, 10 Mar 2011 04:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.587
X-Spam-Level:
X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRBj4hxJJYgp for <hybi@core3.amsl.com>; Thu, 10 Mar 2011 04:20:39 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 50D5B3A691D for <hybi@ietf.org>; Thu, 10 Mar 2011 04:20:39 -0800 (PST)
Received: by wyb42 with SMTP id 42so1572041wyb.31 for <hybi@ietf.org>; Thu, 10 Mar 2011 04:21:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F/r7KEt9hj4/PMuEkVPgY1YwXISKRxQrx08rZN+94C8=; b=Vqszfu3VB9MwiU2KDYnlXzYcO89D9KUzL8uYGa0tS8Ge4MCR+pyA2DWwgNz/MLIrLs wDBF33h/M08MH8E07lQKotTERIyVbMUN8yHsdPiL55q4PQyR3L2DaW/GdiVsDSxOE3Ek lcVyhwQLW5tls3zvNvs8r9d3N7BK1lWH04n+A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W0Pcyo0CYlclMc++TkJk8Eq3TRlp9Wz/crvw9ii6MkZHuSi/7r9CbbiuVNdBYnY7Hr kKH5VoqGAURfnRcgNjbnr7A3IDmvBqniPwuaQ/F6tjBOhYbVBa8OxNElQ3jvgYyxXti+ yr6RLm/o4nfggZZUoXn6pjX/1Gzl7vHeDmbAM=
Received: by 10.227.7.87 with SMTP id c23mr1145455wbc.108.1299759716470; Thu, 10 Mar 2011 04:21:56 -0800 (PST)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id w25sm2377148wbd.23.2011.03.10.04.21.55 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 04:21:56 -0800 (PST)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4D78C262.2060808@warmcat.com>
Date: Thu, 10 Mar 2011 12:21:54 +0000
From: Andy Green <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8
MIME-Version: 1.0
To: Jamie Lokier <jamie@shareable.org>
References: <OF27A0495D.2C32912B-ON8825784E.00342DCE-8825784E.00367A85@playstation.sony.com> <4D775D69.8010808@warmcat.com> <AANLkTi=4_jp_=QffTsTbrUxjzGTRTv5F4Ao=5ZBpc2FB@mail.gmail.com> <4D777402.3010101@warmcat.com> <AANLkTinJPtZ6Y9oVZt3cMm3rjRMM_EPryS+pNwmcB8hP@mail.gmail.com> <4D778F5C.3020404@warmcat.com> <20110310115119.GI29234@shareable.org>
In-Reply-To: <20110310115119.GI29234@shareable.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org, Yutaka_Takeda@playstation.sony.com
Subject: Re: [hybi] TCP packet boundaries must not be assumed (was Re: With deflate-stream, Close frame doesn't work as an end of data marker)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2011 12:20:40 -0000

On 03/10/2011 11:51 AM, Somebody in the thread at some point said:

Hi -

> You also cannot depend on TCP_NODELAY preventing packet aggregation.
>
> There are many corner cases, but here is a few simple ones: When there
> is any bottleneck such as congestion, receiver too slow, receiver busy
> or not enough bandwidth somewhere, the sender will delay sending, or
> resend, and so may aggregate more data into previously queued packets.

Hum fair enough, that is a good point.

If I understood it, it looks like the new language from Yoshino will 
make this moot, because knowing the link is compressed, we know we have 
to specifically wait a while anyway for Z_FINISH bytes to come before close.

-Andy

v2.23.0 | Report a Bug | By Email