Re: [tcpm] draft-ietf-tcpm-converters
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 17 June 2019 06:19 UTC
Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3412000E for <tcpm@ietfa.amsl.com>; Sun, 16 Jun 2019 23:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F0E3j5EQCPu for <tcpm@ietfa.amsl.com>; Sun, 16 Jun 2019 23:19:51 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F67120106 for <tcpm@ietf.org>; Sun, 16 Jun 2019 23:19:51 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 318D725A13; Mon, 17 Jun 2019 08:19:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1560752389; bh=nz30cA+2B8jgRmCaLTEZlhWDvkL5/ZAgMdSGyPauriI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=vFalSfyDZWh2K8XcGaLdeWyyQ1rl9CZJCSitil2rxKnIynK2vYYte5bMh0KHMLBfY XwCH/IDJv/6G+wBL4i2GoiCX0cri+YSz/vyr6pwQBsI0EC/oYZilijR55UAEoLHbLQ rgxqVP/ktKil+cY128Eygp1lIA+kZC/UaLEBqLi8=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oun4RJRV5AdX; Mon, 17 Jun 2019 08:19:48 +0200 (CEST)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 17 Jun 2019 08:19:48 +0200 (CEST)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.117]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 17 Jun 2019 08:19:47 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "draft-ietf-tcpm-converters@ietf.org" <draft-ietf-tcpm-converters@ietf.org>
CC: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Thread-Topic: draft-ietf-tcpm-converters
Thread-Index: AdUkHWlwWAVA12efRnCFBwL9n6nkWAArZURgAAJqz1Q=
Date: Mon, 17 Jun 2019 06:19:47 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D3378FF@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <6EC6417807D9754DA64F3087E2E2E03E2D336687@rznt8114.rznt.rzdir.fht-esslingen.de>, <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAA7AD7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D3378FFrznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/LJYpdVKt4Dtp8XL1Obu5W-pw-bg>
Subject: Re: [tcpm] draft-ietf-tcpm-converters
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2019 06:19:55 -0000
Hi Med, The proposed text would address my concern. Thanks Michael Von: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> Gesendet: Montag, 17. Juni 2019 08:11 An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; draft-ietf-tcpm-converters@ietf.org<mailto:draft-ietf-tcpm-converters@ietf.org> Cc: tcpm@ietf.org Extensions<mailto:tcpm@ietf.org> Betreff: RE: draft-ietf-tcpm-converters Hi Michael, Please see inline. Cheers, Med De : Scharf, Michael [mailto:Michael.Scharf@hs-esslingen.de] Envoyé : dimanche 16 juin 2019 10:28 À : draft-ietf-tcpm-converters@ietf.org Cc : tcpm@ietf.org Extensions Objet : draft-ietf-tcpm-converters Hi all, In preparation of a planned WGLC (heads-up to all) I have read draft-ietf-tcpm-converters-07 again. As a result, I have two further questions (as individual contributor, if that matters). Ideally I should have already noted when reading the document last time… 1/ The handling of the three-way handshake is well specified in the document, and this is what the convert protocol is about. Yet, I really wonder if some words are needed on what the endpoints can expect from the converter once the connection is established? In section 1, the document specifies that the converters „relay control messages and data between the client and the server“. While I believe most of us have an idea what this means, I wonder if it is formally clear what that implies for acknowledgements and connection management (e.g., FIN, RST, keepalives). For instance, if the client receives an ACK for a segment with FIN flag, can the client assume that the server has received a FIN from the converter and that the converter has received an ACK from the Server for that FIN? My understanding is that a converter is not required to guarantee these end-to-end semantics. If that is true, wouldn’t it be better to be explicit about that? This may also relate to what happens in case of failures inside the converter. [Med] We can add some details if you thnk this is useful. A first attempt to address your comment is available at: https://github.com/obonaventure/draft-tcp-converters/pull/60/files. We will further tweak the text and release a new revision soon. 2/ The document uses the term „TCP extended header“, e.g. on page 10 and 23. As far as I know, we typically don’t use this term for the standard TCP header, either with or without options. draft-ietf-tcpm-tcp-edo uses a similar term, but as far as I understand the converter protocol does not rely on EDO. Wouldn’t it be more reasonable to replace „TCP extended header“ by a more common term, e.g. by „TCP header“? [Med] Will be fixed. Thanks Michael
- [tcpm] draft-ietf-tcpm-converters Scharf, Michael
- Re: [tcpm] draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] draft-ietf-tcpm-converters Scharf, Michael
- Re: [tcpm] draft-ietf-tcpm-converters mohamed.boucadair