IETF Logo Mail Archive

Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00

Olivier Bonaventure <olivier.bonaventure@uclouvain.be> Mon, 15 July 2019 15:53 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8E9120088 for <multipathtcp@ietfa.amsl.com>; Mon, 15 Jul 2019 08:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 NOFy95oBeJLy for <multipathtcp@ietfa.amsl.com>; Mon, 15 Jul 2019 08:53:05 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50103.outbound.protection.outlook.com [40.107.5.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE6E120045 for <multipathtcp@ietf.org>; Mon, 15 Jul 2019 08:53:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbko5S40t1PFsIsjcDY+fNfGXlKIPXHFVkYv58DFxid8QUKq88i/NKWjn2X3ZJJcCEPfRJ+QyQiDn3TwTKDKtHoLycV7LHDGjHLE8npM0cqIUriWaTIR9lZYGsR02q4vXobPsrHgQmQcfW8qOn9RNtrQQBi8IeWAA1qilSK7FWx3DjTeKjN1IZ/rckUiPcxImsaHsleTfCEiTK5aDLVu6v+AS638QnIboe32qM+bXYOtiyNcSJI8LhmwI1BFcE9SjOj6t7IOAiQ/9IKxSCdkModa18hQgVJ6IfVqlHcMsF3bAB9ns3U9bupKRueD2vL3hBcCAQvXL+NJplLhJmBKyg==
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=ppCEFGITG9gYbGWYPXM6QttkaJx/Ze9hLn/e3eP1Jig=; b=SI3mi6wfUc/XGdEg3co8nr1tUlmgSRwOVLpgiIKQAWuTAOdZ/OAdZyIFL+sB6aClkASVel/V/qAi7VLeZ8sNuKc9LqknZm5dB0QIeyWnG8ONJbjs9R6EC43WwYDUY7PXa7YD+l9M9kPu33casUprFT/nswIGcnjjOWPgtasGO/sIYIEybaQ/MfbXoTMPG3F+HMFudhA0XLsc6jzD3Vms20fMI4a4QwbSj0Tb1A01FLBd4CKCjkkVsWx4g9RuBjpdOoZh/PJ0bC9sa0o8YuVCoENKi2qIIQ+8dmDz3Z/P2HWC/WrUVgAMU7yVi35uMljPCEH2P+Fm1YgZ61bVH1ixBw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=uclouvain.be;dmarc=pass action=none header.from=uclouvain.be;dkim=pass header.d=uclouvain.be;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ppCEFGITG9gYbGWYPXM6QttkaJx/Ze9hLn/e3eP1Jig=; b=aGaMCDN2ltboPYWJAEcqQ35GF877NMJVAbLx6AueAdNxAbQ9rbCLhsTjrisXxJTzMCoUkmoHbl2GWygEFtyz/QhAW5Gik8CcfY6I0vMmKWYAx4LCqsbtvBm2QlXTxgyoaFOQmMBxzWClo1bAzklLpUAx7Xk33lBmDLxZihXLdBI=
Received: from DB7PR03MB3548.eurprd03.prod.outlook.com (52.134.98.29) by DB7PR03MB3723.eurprd03.prod.outlook.com (52.134.99.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 15:53:01 +0000
Received: from DB7PR03MB3548.eurprd03.prod.outlook.com ([fe80::bd11:ef06:753f:2fd8]) by DB7PR03MB3548.eurprd03.prod.outlook.com ([fe80::bd11:ef06:753f:2fd8%4]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 15:53:00 +0000
From: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>, multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00
Thread-Index: AQHVOukUFVdTMmQex0qfaFNq0weJIKbL1OwA
Date: Mon, 15 Jul 2019 15:53:00 +0000
Message-ID: <d5d0ca74-befd-0552-8a4d-670fc86b3648@uclouvain.be>
References: <CAAK044SMCwZbxTpvAxCmJiK6Di6BMpUSXVW2p0uwipwc2KyMxw@mail.gmail.com>
In-Reply-To: <CAAK044SMCwZbxTpvAxCmJiK6Di6BMpUSXVW2p0uwipwc2KyMxw@mail.gmail.com>
Reply-To: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0099.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::15) To DB7PR03MB3548.eurprd03.prod.outlook.com (2603:10a6:5:4::29)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=olivier.bonaventure@uclouvain.be;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:6a8:308f:2:4ce4:b7b8:e368:f058]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0433f513-239a-4c84-0e5f-08d7093c837c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DB7PR03MB3723;
x-ms-traffictypediagnostic: DB7PR03MB3723:
x-microsoft-antispam-prvs: <DB7PR03MB37230B8307E2B3A8233E93F086CF0@DB7PR03MB3723.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(39860400002)(366004)(376002)(346002)(25584004)(199004)(189003)(81166006)(81156014)(6116002)(25786009)(256004)(14444005)(31696002)(36756003)(8936002)(86362001)(53936002)(305945005)(7736002)(478600001)(229853002)(8676002)(5660300002)(6512007)(446003)(11346002)(2616005)(476003)(486006)(66946007)(316002)(786003)(110136005)(71190400001)(71200400001)(43066004)(66446008)(64756008)(66556008)(66476007)(99286004)(68736007)(6436002)(3450700001)(76176011)(52116002)(14454004)(2906002)(46003)(6486002)(102836004)(386003)(6506007)(186003)(31686004)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR03MB3723; H:DB7PR03MB3548.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: uclouvain.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Y27DHaGEUWFps6JFmM6I3wqylmrsMzuGwhqAMETKyvu4+RfGxUGiZDd9Hg7OrZCIEGzaxxLbV2M2aJ84qSXYqDH3ZIfwr4Pmjg3wX9cLbEhXcsNBZf12LKNL1ARuq0IpY7nQsioZ2JPOxje2yFNKP5eMRXqW0gJlVr6kkxGzj7Jq8Ug5jaoijGzDtVqQ+AEYTkwPiuX8INMn3S+mnCHQG9ayF4HB64OwF02CzFLhhK6HQZ4ZZb/1pPBrcxSF5X+7Z5dbGGm8sLeWWUKgvqtywfmRC84zHHVMMuyB3B4Lj1pUhJe4ccFHJ2b/hTFrXyCiI7Y5gmSIfJ1pLPgxOthGlkG/i62KBhV2OO3AT07vkQulQ9zYfHwZiQQIRaeBdlN06jB296Zv9wcnSB5+9DJ8al++N3qE0K98C/glIkbOLYM=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4F25AC53F06A4A4EB86FE04E075F58AE@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 0433f513-239a-4c84-0e5f-08d7093c837c
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 15:53:00.6986 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: olivier.bonaventure@uclouvain.be
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR03MB3723
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/8bzYclRwNJ1yvy2n_h6leC_jcvQ>
Subject: Re: [multipathtcp] comments on draft-hoang-mptcp-sub-rate-limit-00
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 15:53:08 -0000

Yoshi,

> I've read this draft and have some questions and comments.

Thanks for your comments.

> 1: I am wondering how to calculate and limit the sending rate of subflow.
>      I think adjusting window size wouldn't be very accurate. But, we 
> don't want to perform expensive processing for this purpose.

The pragmatic approach is that it is possible to use window clamping and 
update the clamp value every time the rtt is updated. This is not as 
precise as a token bucket for example, but I don't think that the use 
cases that we have require this type of precision

> 2: I think this is one way information and servers don't need to send 
> SRL option to clients. But, the draft says "a host MUST NOT send more 
> than three SRL options on connection where it has not received any SRL 
> option" Does this mean senders need to send SRL options?

We'd like to limit the amount of SRL options that are sent, but another 
comment suggested to indicate a duration for the SRL value. This would 
require regular transmissions of the SRL option. This part of the text 
will need to be updated.

> 3: I am still not very sure the usage of SRL options for graceful 
> subflow closing. I might want to see some texts in the draft to 
> understand how this can be better than FIN exchange on subflows.

When a client sends a FIN, it indicates that it will not send data 
anymore on this subflow. When it sends a SRL option with 0, it indicates 
to the server that it does not want to receive anymore data on this 
subflow. We can provide some text if we agree on this use case.


Olivier

v2.23.0 | Report a Bug | By Email