Re: [hybi] Clarify the role of closing handshake

Salvatore Loreto <salvatore.loreto@ericsson.com> Fri, 11 February 2011 17:32 UTC

Return-Path: <salvatore.loreto@ericsson.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 3343E3A67DA for <hybi@core3.amsl.com>; Fri, 11 Feb 2011 09:32:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 dWcJSyVPxKG6 for <hybi@core3.amsl.com>; Fri, 11 Feb 2011 09:32:41 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5AA563A6778 for <hybi@ietf.org>; Fri, 11 Feb 2011 09:32:41 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-78-4d5572c767f2
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.2F.13987.7C2755D4; Fri, 11 Feb 2011 18:32:55 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Fri, 11 Feb 2011 18:32:55 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 127672328 for <hybi@ietf.org>; Fri, 11 Feb 2011 19:32:55 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDEE6506C9 for <hybi@ietf.org>; Fri, 11 Feb 2011 19:32:54 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4F7B95057B for <hybi@ietf.org>; Fri, 11 Feb 2011 19:32:53 +0200 (EET)
Message-ID: <4D5572C5.2000703@ericsson.com>
Date: Fri, 11 Feb 2011 18:32:53 +0100
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: hybi@ietf.org
References: <OF1FBA64A7.FD3F6A29-ON88257833.0078A037-88257833.0081FBEE@playstation.sony.com>
In-Reply-To: <OF1FBA64A7.FD3F6A29-ON88257833.0078A037-88257833.0081FBEE@playstation.sony.com>
Content-Type: multipart/alternative; boundary="------------050903020402060609000509"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] Clarify the role of closing handshake
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: Fri, 11 Feb 2011 17:32:43 -0000

On 2/11/11 12:39 AM, Yutaka_Takeda@PlayStation.Sony.Com wrote:
>
> Hi,
>
> Joining this thread from another one in reply to Takeshi's message. 
> Let me try to through my
> thoughts...
>
> > > o Section 4.5.1 - Close handshake
> > >
> > > It is no clear to me what 0x43 and 0x53 are trying to achieve. In
> > > TCP, there is FIN with no
> > > details of why/who is closing for graceful shutdown.
> >
> > Actually, it's not intended to indicate who's closing, but to make
> > sure what the close frame really means, i.e. it's close initiation
> > or close acknowledgement. Using an analogy of TCP, close S from
> > server is FIN, and close S from client is ACK for server's FIN.
> >
> > Without this, each peer cannot know
> > - the other peer just initiated close
> > or
> > - the other peer received close frame and acknowledged it
> >
> > Imagine both peers send out close initiation at approximately same
> > time. They looks like acknowledgement but are not.
> >
> > Once we can perfectly distinguish initiation and acknowledgement as
> > described above, we can assume "If A received close acknowledgement
> > from B, B has received all the data sent from A before close 
> successfully".
> >
> > If you have any idea about the usefulness of this closing handshake
> > design, please come to the thread "Clarify the role of closing
> > handshake" and speak out. We're discussing it now.
>
> The current -05 as is seems good to me. Now I think it would be good 
> to have 1-byte body
> 0x43 and 0x53, if it is important to know whether all data sent 
> successfully reached the peer.
> I just do not know how import that is from application's perspective.

Hi Yutaka

People seems agree that this can be handled at application level,
(the fact that you also say that it is difficult to know how important 
that is
from an application's prospective seem that you agree on that, but then
the rest of your message confuse me, can you clarify what you would like?)

People seems agree, withing this thread, that at protocol level it is 
enough to go for the simplest scenario:

- Peer B assumes that no more data is coming from peer A when B receives 
closing
initiation from A.

please read the text suggested from Takeshi in
http://www.ietf.org/mail-archive/web/hybi/current/msg06285.html
and check if it works for you

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com