IETF Logo Mail Archive

Re: [Banana] Charter

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Wed, 20 September 2017 04:03 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3860A13219F for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 21:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 eEEBASUTBdxB for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 21:03:32 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9A412426E for <banana@ietf.org>; Tue, 19 Sep 2017 21:03:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6259; q=dns/txt; s=iport; t=1505880212; x=1507089812; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HJePgp46HvzNC6nSyqpbPNI1Hz9jnwxdD6/t3qU7SaM=; b=mwqzSsZ8UhHOJpG37L8X3AWlB6GiFfUTTh0VMam372BcYZ/cdMWQX6nZ Emd5Re6ktGrh4r5M9I41gBD+vjdtTrX4DG4+1WCIZAOM0iXTY/COsqPiY i1BUN9zaNaOkAZ1eJKQWLQ8gkFKIyQvrQ0rqWog8R5SaOeLITNFk481cj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DmAQBU58FZ/51dJa1bGQEBAQEBAQEBAQEBBwEBAQEBgm9rgVInB54DgXSIPIgrh1AKhTsChFtXAQIBAQEBAQJrKIUYAQEBBHkQAgEIEAEDAQIoByERFAkIAgQOBRuJNEwDFasPhzANg18BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyuCAoFRgWSDKIJZgkIWhT0FoFA8Ao9dhHeSeoxciC4CERkBgTgBV4ENdxWHZXaHa4EPAQEB
X-IronPort-AV: E=Sophos;i="5.42,420,1500940800"; d="scan'208,217";a="5965029"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 04:03:31 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v8K43VDk006296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Sep 2017 04:03:31 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 23:03:30 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 23:03:30 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Margaret Wasserman <margaretw42@gmail.com>
CC: Tommy Pauly <tpauly@apple.com>, Margaret Cullen <mrcullen42@gmail.com>, "Zhangmingui (Martin)" <zhangmingui@huawei.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "banana@ietf.org" <banana@ietf.org>
Thread-Topic: [Banana] Charter
Thread-Index: AQHS/w5lhWOFLy/yHEWQ/Po5rcE+YqJYdBGAgFsJ04CAADjYAIAArB+AgAGr8wCAALSfAIAEmiqAgABd/AD//5ILgIAAh5yA//+msICAAIHlAP//nMUAAA+4OwAAEgAvgAAdhd+A//+Ye4CAAK8wAP//jzgA
Date: Wed, 20 Sep 2017 04:03:30 +0000
Message-ID: <D5E73502.22DD40%sgundave@cisco.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch> <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com> <01e83ac6-0bd0-e7c7-01e4-0ffb7af73034@gmail.com> <4B6D7CF5-E6BC-4ECA-9299-7458A624320B@nokia.com> <B31BA5EB-7369-4B49-B240-AA6C3E653231@gmail.com> <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com> <4552F0907735844E9204A62BBDD325E7A65EC703@NKGEML515-MBX.china.huawei.com> <260086DD-D245-46EF-89E2-308D5A58AAFB@nokia.com> <5FECB6A6-41B7-41D1-A8B8-B7BCE8474F90@gmail.com> <2CD45C9D-41FB-425F-946E-D3AE47C9B000@nokia.com> <6A618A1C-92FB-467F-8F7D-6A9B40FC191E@gmail.com> <D5E56BEA.28AE8D%sgundave@cisco.com> <9CD725AF-B9FE-4E81-BFD6-21A812DF48CF@gmail.com> <D5E58ECD.22D723%sgundave@cisco.com> <355C07D1-032F-4E07-AEEB-6E1FD5024A68@gmail.com> <D5E5AA42.22D7AB%sgundave@cisco.com> <E16200ED-1BEF-48F3-A43E-E738AD6A2A12@gmail.com> <D5E68DEF.22D875%sgundave@cisco.com> <F8841D2A-A04A-448E-BC99-BD18BD178DD2@apple.com> <D5E6F82F.22DA6D%sgundave@cisco.com> <FF152404-DEA1-46D5-B44D-E755CBD1F896@gmail.com>
In-Reply-To: <FF152404-DEA1-46D5-B44D-E755CBD1F896@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.54]
Content-Type: multipart/alternative; boundary="_000_D5E7350222DD40sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/Bcrgj9ZsKOWi9nyMOHzrMssogxQ>
Subject: Re: [Banana] Charter
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2017 04:03:34 -0000

Hi Margaret,

There are two parts to this; the approach of #1) registering multiple paths / establishing multiple tunnels and #2) the approach of flow distribution with flow spec negotiation.

In MIP, #1 is not dependent on #2. When there is no negotiated flow spec, the peers can adopt a locally configured traffic distribution scheme, which can be per-packet, or link-weighted packet distribution scheme .. or what ever is supported and configured on those two peers. In our implementation we do support both the modes, flow based on packet based.



Sri

From: Margaret Wasserman <margaretw42@gmail.com<mailto:margaretw42@gmail.com>>
Date: Tuesday, September 19, 2017 at 8:47 PM
To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>
Cc: Tommy Pauly <tpauly@apple.com<mailto:tpauly@apple.com>>, Margaret Cullen <mrcullen42@gmail.com<mailto:mrcullen42@gmail.com>>, "Zhangmingui (Martin)" <zhangmingui@huawei.com<mailto:zhangmingui@huawei.com>>, Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com<mailto:wim.henderickx@nokia.com>>, "banana@ietf.org<mailto:banana@ietf.org>" <banana@ietf.org<mailto:banana@ietf.org>>
Subject: Re: [Banana] Charter

Hi Sri,

6. Multi path Support with QUIC/MPTCP Proxy (Proxy Initiated)


<1C40439B-02E1-47BC-BE0B-28B2BD41E2F1.png>

Given that the standard parts of this protocol (as you describe them) only includes flow-based distribution between the links, how would this solution allow a single flow to use the bandwidth of multiple links?  How do you control (or at least influence how reverse-path traffic is distributed?

I am at least somewhat familiar with MIP and PMIP (although I will grant that you are much more knowledgable about it), and this is the part I don't understand.  Are you performing packet-based distribution that using some sort of changes or extensions to PMIP?  Or is your solution purely flow based?

Margaret

v2.23.0 | Report a Bug | By Email