Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 23 June 2020 08:45 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6AB3A17F1; Tue, 23 Jun 2020 01:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 HyZxHs386gv5; Tue, 23 Jun 2020 01:45:27 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00053.outbound.protection.outlook.com [40.107.0.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FFD3A17EE; Tue, 23 Jun 2020 01:45:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N0Q8fouauqr20IqucL4G10aVV85wnatx3vgtZYmZ//p5EPZU0HzhIXODUbLjyob5WQkeayst/hjYQYnONh2oBVst2HJsy0HmFkynICiZnX85nbYMJQHZtyJWrM957GREzYClTd9JYK2nz3pd1oJH32E35yYJkkydztjwfPZSkZPhsOpHSyI2aMbFkNFRFNaUYMDyOAveEyX51zPLSoPtGjAjryz6fInawswXHMJDuEWGLZM9hqFVDatW0pw5YxjhV+teuGfZYrAg8i0w+PCtWKla4UZ7eSiWx01K7qVJEWSWkFTFutxhnCc5j9GYCsnzOS0mFbseGiI0ygIlNb6Gzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BipvO2UvNpWYH/caYjfFX0oeBmZqRg36UGuGykT2g3c=; b=I16bNVwknmPk73t1f+XxTmGQ5QL8MWNJgxHvYFoPNFrn8XwCrBsSUi86Hm7GAgvbH1AxpZmw8RLHSRBeTsZ0QbPNWNxVRE1NRJOOmjF6aMdu5Fbs535XKlEObn9nd9Vs+F/Ts6VqtynbJi8kySiThN9L01MIRUDFvN3SUdK1PmFf+yPFXTTrbnF2Zy2eQBHEB2HWlWr1yMk07BzGnijCZzyhtXiFcyd1BG+rCIAqJm1R2m+Zb+u99h/OUz2QtdxvcsEDn25LYFdc5hcsbx4UAqUC8Jlpth358fT9fRxvsCk1dHSMHGkP1U+3xjgC6d7wzknFOFCaaucFX78vr5GXpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BipvO2UvNpWYH/caYjfFX0oeBmZqRg36UGuGykT2g3c=; b=luWuxEL6TruuLVJlrR153WBaVOo9oksvgYm9kAFpNDKEL2r6iRF3Pe205la48DRDHD7qx4xkC5j7pIkCoyHVHh+nYsN5w1IzndOkY/F+8KewdB/gIrzROcrdVDVeGDGnqDMsOdxJPllEVRUbDj7KFh8+w8LRcT+Nd/i41XAs0TE=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2682.eurprd07.prod.outlook.com (2603:10a6:3:90::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.13; Tue, 23 Jun 2020 08:45:23 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3131.018; Tue, 23 Jun 2020 08:45:23 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "BSipos@rkf-eng.com" <BSipos@rkf-eng.com>, "ietf@kuehlewind.net" <ietf@kuehlewind.net>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-dtn-tcpclv4@ietf.org" <draft-ietf-dtn-tcpclv4@ietf.org>, "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "edward.birrane@jhuapl.edu" <edward.birrane@jhuapl.edu>
Thread-Topic: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
Thread-Index: AQHV5+6WGby3OQoJeUGE8iR16tXBQqg90i+AgHI3IwCAFj7MAIAgWiHQ
Date: Tue, 23 Jun 2020 08:45:23 +0000
Message-ID: <HE1PR0702MB37729B37249E6BEDB706996B95940@HE1PR0702MB3772.eurprd07.prod.outlook.com>
References: <158220398711.12456.13531582672796496258.idtracker@ietfa.amsl.com> <745bfd811b9d3fb03f3e280b15fe9feb41241ba8.camel@rkf-eng.com> <HE1PR0702MB37721BC4C889B6AF96793B8395B10@HE1PR0702MB3772.eurprd07.prod.outlook.com> <5f1189de85d83aa3bc651e4f295c344a09e9928a.camel@rkf-eng.com>
In-Reply-To: <5f1189de85d83aa3bc651e4f295c344a09e9928a.camel@rkf-eng.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: rkf-eng.com; dkim=none (message not signed) header.d=none;rkf-eng.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [176.10.164.117]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8193814a-2ef0-4f39-e2cd-08d81751c4f4
x-ms-traffictypediagnostic: HE1PR0701MB2682:
x-microsoft-antispam-prvs: <HE1PR0701MB268299FF7C5978987C13580895940@HE1PR0701MB2682.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zEAB1dpE7E1+HYkQLaCqrW/9rrh9I1C2fJu5zDA81jFU8JUyuADnkyF2odLQcC+rR1yt1/PZ6Mb/QdGu6P/2FI1EuZhFmhdThdZORuMEDaWnr8Be7TpvE0sksq93P55QVxbFZboHNr1lM336Km387VPNcQ6ZOPprJ61DriiNqvOM7SMwCt7U4hHwNS2TfD1ljrVo6EmAjCsTES6Qe3j/cDYkGOv54sT2snvXro1RfBVuQlBzHfyyR9op6EfnKbGaQO1dbqiDk9KWmFI1kH/v96+W9zje335/TDg5UIVK+GPGqLyvIWe65F9ZxYHplWjTOAa8wrCIUh7IsqbelXTWlg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(346002)(366004)(44832011)(2906002)(33656002)(8936002)(64756008)(66446008)(66476007)(66556008)(66616009)(66946007)(316002)(76116006)(54906003)(52536014)(4326008)(110136005)(55016002)(478600001)(9686003)(5660300002)(26005)(86362001)(186003)(224303003)(83380400001)(71200400001)(99936003)(7696005)(6506007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +oU345MOkHRApqwsU1LvzZpcywjUxBgCjZaMLybYG5w5BjlQi4F0ESPtdBgGDEDL4X1YwPHgJTDCA44CP4onqyVvNeRni0gQTt5QgZvpCl0wEGVSZfydmZcLmIgs0vY7DSKYhQggcKiCRTE1LpV96NG5P9gGVJAbjuj4H6iOSuFpizHwlsnJ1PTRhV0RJhtieJFw30O6ywLLkhrKjvHxXxOMXyDIdvgMia/vk6yYWn8Ifxs0HzGCvbZCwRmrGOtBFcHt0J1Q9DT8QjQf3r4jcaiKxmKyCZzTPMD4I3jT19SgrY0uHFCkfZp9DQfo+L6iudeu0vB+ouPTrY+U15nICucY4Or7iwoJX/isyOhCtwLUrL79JbVeuSBXQv/8VqwoEWL3CMjPw7kLkjqKZ2n7meQRg8fl6mJ0fXm5Me7B4q+0hvv9t3QS9AwwlxuIqYE3Gm/FOWvw5iOi0Ax6Ihcy9BJ5ONESWGNtjbliD7Gew0N0jugEa/Wg0xwTj7dBHQZe
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00DF_01D6494B.64F2FFF0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8193814a-2ef0-4f39-e2cd-08d81751c4f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 08:45:23.5988 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iqGVF8i5wqGRqIlCO3Ca5dx+NVCqmzXgE6YnF7SDpmb7CaV1OP+HpVLROQqO+8QNO782R0cd6N7A9dIAb9HSI8A9t0lNERplOT4f22MZmVY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2682
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/juZRrGOXhmRxqfwax0L8PGfAx2U>
Subject: Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 08:45:30 -0000
Hi, Sorry for the delay in responding to the new version. I think the new version resolves everything except the Session keeping policies discussion below. Sorry for not making it clear that I think such a section would be good. I see the goal is to provide guidance to BP agent implementors using this CL. Cheers Magnus Westerlund > > > > > Sec 5.1.1: > > > > > Some discussion of the above issue appears motivated to determine if there > should be some more discussion of what reestablishment behavior TCPCL should > have and provide guidance to the higher layer that uses the TCPCL. > BS: You are correct that each CL has it's own notion of connectivity and session state. Your interpretation of the idle session termination also looks correct. Unfortunately, I have less perspective of how the BP Agent implementations to-date may require or expect CL interfaces to behave at an API level. My expectation of TCPCL use falls into two extreme use cases, which agree with your understanding: 1) A permanent physical link with reliable flows between nodes, which is expected to have steady load of transfers occupying the link. In this case the TCPCL would establish a session and keep it up as long as possible. The goal here is total throughput and not wasting any link throughput on TCP handshaking, TLS establishment, etc. 2) An ephemeral link between nodes which may not even have reliable long-term connectivity. In this case the TCPCL only attempts a session when both connectivity is expected and when a bundle transfer is queued (to send) or some polling interval is reached (to receive). These types of session keeping explanations could be added to the spec, similar to the existing "Transfer Segmentation Policies" examples. Maybe a section "Session Keeping Policies"? [MW] Yes, I think that would resolve my perspective on this issue and allow us to continue. > > > On Section 6.1: > A session termination MAY occur immediately after transmission of a > Contact Header (and prior to any further message transmit). This > can, for example, be used to notify that the entity is currently not > able or willing to communicate. However, an entity MUST always send > the Contact Header to its peer before sending a SESS_TERM message. > > I do see Mirja's issue. The text is a bit contradictory and unclear on which > session is referenced. So if the passive part receives a CONTACT header and > then sends a SESS_TERM I interpret this as you consider a TCPCL session is > crated through only Contact exchange. Secondly, as Mirja states it is > allowable to terminate the TCP session per Section 4.1 prior to this. > > > > If the passive entity does not receive a Contact Header > > after some implementation-defined time duration after TCP connection > > is established, the entity SHALL close the TCP connection. > > > > Thus, maybe a clarification that context of the normative text statement is in > relation to the TCPCL session. And note that TCP connection termination may > occur prior to the CONTACT exchange. > > > > Maybe: > > > > A TCPCL session termination MAY occur immediately after transmission of a > > ^^^^^ > > Contact Header (and prior to any further message transmit). This > > can, for example, be used to notify that the entity is currently not > > able or willing to communicate. However, an entity MUST always send > > the Contact Header to its peer before sending a SESS_TERM message. > > Termination of the TCP connection can occur prior to receiving the Contact > > header as discussed in Section 4.1. > > > > Feedback on this? > > BS: The key distinction here is between a "TCP connection being closed" vs. a "TCPCL session being terminated". TCPCL messaging isn't possible until after contact header exchange and contact negotiation "[PCH]" in Section 3.3, and TCPCL session isn't actually established until SESS_INIT exchange and parameter negotiation "[PSI]", so until that occurs there is not actually a TCPCL session to terminate. I used your suggested text to update the text in Section 6.1 to refer back to Section 4.1. [MW] The text changes -21 lloks fine to me and this issue is resovled.
- [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn… Mirja Kühlewind via Datatracker
- Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf… Brian Sipos
- Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf… Magnus Westerlund
- Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf… Brian Sipos
- Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf… Magnus Westerlund
- Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf… Magnus Westerlund