From nobody Mon Jan 5 02:25:18 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBBC1A1BDC for ; Mon, 5 Jan 2015 02:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 0-Z5iy4A_TKD for ; Mon, 5 Jan 2015 02:25:13 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B751A047A for ; Mon, 5 Jan 2015 02:25:12 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so9427772wgh.30 for ; Mon, 05 Jan 2015 02:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=kVi2N68vlXz4zMqDKyO5ndmyI1UaLWED3PT+IMkOVT0=; b=Gm3BfEWZw4XFXlVP4bVTJHv5RaoUxuPaEXrxthGrR8vIOYyTHWlVlqEr+cMNAQsYoA z4yznP5CF9qGtW1Wi/2KW2JnOzks7/1YrN9NXkx1J3kHqPUD9HaKYjkkzaeIx1e+AAAk PcfhsoWzjE2respQfhRPP+mg3AOZrMotrbtiqo2B6gBKEFAG2utnVA2fYNYM1CBv6R3a STljQ5ZhFXnXZ/LlqVxU/lgoizjghExOA4DjZPiF7Dezl7tioX90oOvcDYrLzLlp9E0A RhTygmhVZJaDL3gdcWMSJZPl1c+lg3ZmeWHbAlwT9aLAUv+YsGT2jTCRl1d9ZkEhl6IT W9JA== X-Received: by 10.180.100.98 with SMTP id ex2mr24294184wib.58.1420453510970; Mon, 05 Jan 2015 02:25:10 -0800 (PST) Received: from [192.168.0.2] (cpc5-acto4-2-0-cust918.4-2.cable.virginm.net. [86.13.119.151]) by mx.google.com with ESMTPSA id h2sm9349063wix.5.2015.01.05.02.25.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Jan 2015 02:25:10 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Alan Ford In-Reply-To: Date: Mon, 5 Jan 2015 10:25:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Anumita Biswas , multipathtcp@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/LGePYfoka_4Lo69tkaWlnaQl_ck Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 10:25:15 -0000 Hi Anumita, First, sorry for the slow reply! On 11 Dec 2014, at 21:50, Anumita Biswas wrote: > For all this to work, the current MPTCP implementers will have to add = the following support in their version 0 implementation:=20 >=20 > a. A server must accept a SYN with any version number. > b. The server must reply with the version number it supports or wishes = to use, provided it is equal to or lower than the client=92s version = number, and not fall back to a regular TCP handshake in SYN/ACK. > c. The client must echo the minimum of the versions advertised by the = client and server in the ACK of the 3-way handshake or fallback to = regular TCP if it does not support the server=92s version.=20 >=20 > Please let me know your thoughts on this, I agree with your proposal here, and will wrap it in in the next = revision. I had originally thought we wouldn't need to tackle this until = a newer MPTCP version number was proposed, but for fallback we do indeed = need to specify some of this. =46rom the perspective of a v0 MPTCP = implementation, the one thing we need to actively specify is that it is = still valid to respond to a SYN/MP_CAPABLE with one with a lower version = number. A pleasant side-effect of the stateless handshake mechanism we = have is that this means we don't need to worry about any contents in = that initial SYN/MP_CAPABLE with the higher version number - all = necessary data is echoed in the ACK/MP_CAPABLE. It's up to = implementations of later versions to determine whether they want to be = able to support fallback once the far end offers a lower version number. Best regards, Alan From nobody Mon Jan 5 11:57:23 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4781A88A8 for ; Mon, 5 Jan 2015 11:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 S5mJ_U4nhhzx for ; Mon, 5 Jan 2015 11:57:18 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A35C1A1BC6 for ; Mon, 5 Jan 2015 11:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1420486892; x=2284400492; h=From:Sender:Reply-To:Subject:Date:Message-Id:To:Cc:Mime-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x/0ajB8dCOat9wdoBcRja6Gr8RpTYhLQOiACQnr9eQQ=; b=ioVwBfNnlL+rXhVMco7JcNXUF7b7rVrQxdliXZsV6QY0DAdVQzkbsyQwZDDjxZII uuAFGNqCzMDZUGkH1AT4ZxVEGM4HLgdTC938XpKsNmvvkbvAvEKHCEqmIJg7Ab/F F1fikFDFx42oVCN6TK6smzSMRUGy6pk/q4Swq/BQ5JILiTDBq7FZxaol0hAq0RKW O4Pd3WSOL43ID46BIWiz53QoqSqSlJllIsjht5ZaueNuTk8WqnTmtyugpT3fNTN8 UscQ6ijH7VlMd3/saGd1wLcYmLa8YAd4jNNcURIAJa0s7iB0v/sBjqIYsDgzRyTs qEZ3eg61CSffAoLeJ7TMrw==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 3C.19.29682.CE8EAA45; Mon, 5 Jan 2015 11:41:32 -0800 (PST) X-AuditID: 11973e16-f79146d0000073f2-4c-54aae8ec0fb9 Received: from ba0301a-dhcp15.apple.com (ba0301a-dhcp15.apple.com [17.193.14.143]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 01.2C.22184.8C8EAA45; Mon, 5 Jan 2015 11:40:56 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Anumita Biswas In-Reply-To: Date: Mon, 5 Jan 2015 11:41:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alan Ford X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUi2FCYqvvmxaoQgxfNxhYrz61gtvi8+jqb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxfE8TS8E1/opF7d/ZGxj38nQxcnJICJhI TP52lQXCFpO4cG89WxcjF4eQwD5GiTlbnrPAFLXM/ssKkVjBJPHu0FF2kASzgJ7Ejuu/gBIc HLxA9tVOLZCwsICFxOMPDWAlbAL6Ekcf3WAGsTkFbCXOPpwPNpNFQEVi1acjLBBjJCVW/P3E CmFrSyxb+BqsnlfARqL/ykI2EFtIIFfi6qpuNpBVIgLKEstnsUKcJivx7+IZdpDTJAQ+skqs /vmEdQKj0Cwk181CuG4Wkg0LGJlXMQrlJmbm6GbmmeslFhTkpOol5+duYgSF73Q7sR2MD1dZ HWIU4GBU4uH9cWZliBBrYllxZe4hRmkOFiVxXo51K0KEBNITS1KzU1MLUovii0pzUosPMTJx cEo1MO7mrfAK8l055d3czS0m10NnGHyxnbH5Px/njr5XhnKaUSz+3RIevSpZbxtWT33LL847 t5p76RZt83ml/vuzfrIomAaItT/dKWEUvmTp2hNSn64EKnDf3/tS2//alPMvlukm7s+yEj84 qZhhRkjQUhumEzsvXf5l1DG75vCnTBXHibY9byPqcpVYijMSDbWYi4oTASCFSyNAAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUieJCvX/fEi1UhBlcmCFqsPLeC2eLz6uts DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG8z1NLAXX+CsWtX9nb2Dcy9PFyMkhIWAi 0TL7LyuELSZx4d56ti5GLg4hgRVMEu8OHWUHSTAL6EnsuP4LqIiDgxfIvtqpBRIWFrCQePyh AayETUBf4uijG8wgNqeArcTZh/NZQGwWARWJVZ+OsECMkZRY8fcTK4StLbFs4Wuwel4BG4n+ KwvZQGwhgVyJq6u62UBWiQgoSyyfBXWarMS/i2fYJzDyz0Jy0CyEg2YhGbqAkXkVo0BRak5i pbleYkFBTqpecn7uJkZQuDUUpu5gbFxudYhRgINRiYc34PzKECHWxLLiytxDjBIczEoivPLP V4UI8aYkVlalFuXHF5XmpBYfYpTmYFES51XePTNESCA9sSQ1OzW1ILUIJsvEwSnVwFh90fje MQnPfSItrfp7FaPkfdQj85SuW+yJ4cvZoSnLO9NDyPju+UKXFctK/XYvrF2Yaqf0U2hB7mbD vI/3fklGFhXv/q15r1dTV46J73jqSjauZxEF26sNr955smzekeU7bx6KXN+i8/terRVb6tTJ T3JcJStTrN3zEya+mFnc8aLaT015lRJLcUaioRZzUXEiAO7RxqwzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/multipathtcp/kajx7GfrPFeWOzEoWRMadoeblYk Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 19:57:20 -0000 > On Jan 5, 2015, at 2:25 AM, Alan Ford wrote: >=20 > Hi Anumita, >=20 > First, sorry for the slow reply! >=20 > On 11 Dec 2014, at 21:50, Anumita Biswas wrote: >> For all this to work, the current MPTCP implementers will have to add = the following support in their version 0 implementation:=20 >>=20 >> a. A server must accept a SYN with any version number. >> b. The server must reply with the version number it supports or = wishes to use, provided it is equal to or lower than the client=92s = version number, and not fall back to a regular TCP handshake in SYN/ACK. >> c. The client must echo the minimum of the versions advertised by the = client and server in the ACK of the 3-way handshake or fallback to = regular TCP if it does not support the server=92s version.=20 >>=20 >> Please let me know your thoughts on this, >=20 > I agree with your proposal here, and will wrap it in in the next = revision. I had originally thought we wouldn't need to tackle this until = a newer MPTCP version number was proposed, but for fallback we do indeed = need to specify some of this. =46rom the perspective of a v0 MPTCP = implementation, the one thing we need to actively specify is that it is = still valid to respond to a SYN/MP_CAPABLE with one with a lower version = number. A pleasant side-effect of the stateless handshake mechanism we = have is that this means we don't need to worry about any contents in = that initial SYN/MP_CAPABLE with the higher version number - all = necessary data is echoed in the ACK/MP_CAPABLE. It's up to = implementations of later versions to determine whether they want to be = able to support fallback once the far end offers a lower version number. >=20 My belief is that implementations will prefer to fallback to the minimum = MPTCP version if its possible to easily maintain/implement multiple = MPTCP versions, than fallback to regular TCP.=20 Thank you! Anumita > Best regards, > Alan >=20