Tom,
Only a few companies can control both client and server sides.
However, ISPs might be able to control the STB at the client side and the
middleboxes in their networks.
This may be a relatively easy way to deploy MPTCP technology rather than
updating clients or servers.
Yoshi,
I think
Hi Tom,
On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote:
> On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida
> wrote:
> > Hi Tom,
> >
> > Only a few companies can control both client and server sides.
> > However, ISPs might be able to control
If you have a TCP solution that endpoints don't want but ISPs do, you do
not have a good solution.
Again, this seems like an interim fix that only complicates the
landscape for everyone - it impedes deployment of security and could
complicate every other option.
Every attempt to address these
On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida
wrote:
> Hi Tom,
>
> Only a few companies can control both client and server sides.
> However, ISPs might be able to control the STB at the client side and the
> middleboxes in their networks.
> This may be a relatively
Hi Tom,
Only a few companies can control both client and server sides.
However, ISPs might be able to control the STB at the client side and the
middleboxes in their networks.
This may be a relatively easy way to deploy MPTCP technology rather than
updating clients or servers.
--
Yoshi
On Mon,
> From the viewpoint of the enduser, there is a benefit in using MPTCP on her
> smartphone because she can combine LTE and WiFi to achieve higher bandwidth
> or have seamless handovers. From the viewpoint of the network operator, this
> is an added value service that they provide to their
Tom,
I disagree, discussions about deployment and implementation are in
scope. The primary argument for necessity that this draft makes is
that MPTCP is being deployed too slowly.
The main argument of the draft is that deployment on client and servers does
not go at the same pace. This is
On Mon, Sep 18, 2017 at 2:18 AM, Olivier Bonaventure
wrote:
> Tom,
>>
>>
>> I disagree, discussions about deployment and implementation are in
>> scope. The primary argument for necessity that this draft makes is
>> that MPTCP is being deployed too slowly.
>
>
>
Tom,
I disagree, discussions about deployment and implementation are in
scope. The primary argument for necessity that this draft makes is
that MPTCP is being deployed too slowly.
The main argument of the draft is that deployment on client and servers
does not go at the same pace. This is
On 9/17/2017 7:05 PM, Tom Herbert wrote:
>> I agree, there is engineering effort to bring MPTCP in the mainline Linux
>> kernel, but this is outside the scope of IETF.
>>
> Oliver,
>
> I disagree, discussions about deployment and implementation are in
> scope. The primary argument for necessity
On Sun, Sep 17, 2017 at 1:24 PM, Olivier Bonaventure
wrote:
> Tom,
>
> Thanks for your comments.
>
>> For #1 the assumption, the key assertion in the draft is "There are
>> some situations where the transport stack used on clients (resp.
>> servers) can be
On Wed, Sep 13, 2017 at 8:01 AM, wrote:
> Hi,
>
> At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, “0-RTT
> TCP converters”
> https://tools.ietf.org/html/draft-bonaventure-mptcp-converters This seemed
> to get a good reception, and had taken on board
Hi,
At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, "0-RTT
TCP converters" https://tools.ietf.org/html/draft-bonaventure-mptcp-converters
This seemed to get a good reception, and had taken on board the feedback about
the "plain mode" draft.
We believe the next steps are:
13 matches
Mail list logo