IETF Logo Mail Archive

Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 15 March 2019 06:35 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 EFCB0130E2F for <tcpm@ietfa.amsl.com>; Thu, 14 Mar 2019 23:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7RdZ58UGewhk for <tcpm@ietfa.amsl.com>; Thu, 14 Mar 2019 23:35:13 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD433127987 for <tcpm@ietf.org>; Thu, 14 Mar 2019 23:35:12 -0700 (PDT)
Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CA118279602 for <tcpm@ietf.org>; Fri, 15 Mar 2019 15:35:09 +0900 (JST)
Received: by mail-wr1-f53.google.com with SMTP id t5so8319670wri.7 for <tcpm@ietf.org>; Thu, 14 Mar 2019 23:35:09 -0700 (PDT)
X-Gm-Message-State: APjAAAWZ34LGRpgOVkhx++ghchNR2F3xIRV1LAm93uLoA1EPukpEn1oP CVUXssl9361pKaAI/vunhcQAaC/abd8YqHSllII=
X-Google-Smtp-Source: APXvYqx/2JPv5XMk7fvyG6ryHr9ZdyWVa5kTR3YYNobtembpNEjnlhgx6NgIrCJ8ae+Fi4507zZKZUz4J+o8TRmvaKI=
X-Received: by 2002:adf:f487:: with SMTP id l7mr1069741wro.86.1552631707519; Thu, 14 Mar 2019 23:35:07 -0700 (PDT)
MIME-Version: 1.0
References: <9DD59801-36CE-407E-98F0-0BB1AAD514A7@tessares.net> <CAO249yc-eHAnOR7XfemQyJB+UVjmdtt43oZs+xJa=inZBBgp2w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA2273F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249ycs3grfmcaVJem-swoAWMAU_boOc5csY-ZjWn5S8m0F5w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA23CC3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA24AC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yeALw7PJnKxkLVMr2q4-qeB_-fMwc7HW+3f-mX-s+RQag@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA25443@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249ydNzjkpxogU+1RNY-_aOa6XGMu7J-zmfv0NGcjFF3u9Ag@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA25F47@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAO249yd5KTOC8Y3xCpTHfqwWpg80nM_hV9ADkPNMKFxqeUvpFg@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA27F2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Thu, 14 Mar 2019 23:34:55 -0700
X-Gmail-Original-Message-ID: <CAO249yejJmSpzQM0UQzQq2FwOXxMQ3ynzQA_T1RUoSve7MebFA@mail.gmail.com>
Message-ID: <CAO249yejJmSpzQM0UQzQq2FwOXxMQ3ynzQA_T1RUoSve7MebFA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064d18705841c3d42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oVhieVGBMtpnurzEKwpdcJCAubE>
Subject: Re: [tcpm] Updated version of draft-ietf-tcpm-converters-05
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: Fri, 15 Mar 2019 06:35:15 -0000

Hi Med,

On Mon, Mar 4, 2019 at 7:21 AM <mohamed.boucadair@orange.com> wrote:

> Yoshi,
>
>
>
> “I don't think this is always true.
>
> If mptcp client uses multiple subflows for the mptcp connection, how does
> it looks to the server?
>
> I believe it should be a single connection on the serve side.”
>
>
>
> The server will always see the same source address/port.
>
>
>
> “But, this means when you convert mptcp into tcp, you'll need to merge
> multiple TCP connections into a single TCP connection.”
>
>
>
> The glue is done at the TCP level by the converter.
>
>
>
> “This merging process will not be very easy when TLS are used for
> subflows.”
>
>
>
> Why? I think the disconnect is that you seem to imply that data from
> various segments are multiplexed in the same segment upstream.
>

>

Sorry for my slow response. I did some small experiments to examine this
and took some time to setup.
After I've checked, I've found the concept of the converter can work
properly with TLS.
I'm sorry for the confusion. I am now fine with the current statement on
this point.
--
Yoshi

v2.23.0 | Report a Bug | By Email