On 7/18/2017 4:05 PM, Olivier Bonaventure wrote:
>> Although I'm not averse to middleboxes as optional optimizations, I find
>> the proposed mechanisms aren't quite optional -- they inject option
>> information into the SYN data. That information would poison a
>> connection to a legacy receiver
Joe,
I've noted this before, but to share with other areas:
You noted this about previous documents. The document that I mentioned
describes a new design that answers several of the comments that you
raised on the mptcp mailing list.
Although I'm not averse to middleboxes as optional
On 7/18/2017 3:43 PM, Tom Herbert wrote:
>> TCP must be E2E and fall back to legacy endpoints without a reconnection
>> attempt, as required by RFC793.
>>
>> These aren't generic solutions; they're attacks on a TCP connection, IMO.
>>
> I agree. This seems be akin to stateful firewalls model
On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch wrote:
> Hi, all,
>
> I've noted this before, but to share with other areas:
>
> Although I'm not averse to middleboxes as optional optimizations, I find
> the proposed mechanisms aren't quite optional -- they inject option
> information
Hi, all,
I've noted this before, but to share with other areas:
Although I'm not averse to middleboxes as optional optimizations, I find
the proposed mechanisms aren't quite optional -- they inject option
information into the SYN data. That information would poison a
connection to a legacy
Some quick notes:
RFC1191 is for IPv4. The RFC for IPv6 PMTUD has just been revised
(8201), and includes clarified and corrected terms for the various types
of MTU that need to be considered.
It might also be useful to look at draft-ietf-intarea-tunnels and its
terminology for MTU values, esp.
Hello,
The design of Multipath TCP (RFC6824) has been heavily influenced by
various types of interferences caused by middleboxes. These problems
have been solved and the protocol is deployed at a large scale by
several smartphone vendors. One of the remaining items of the charter of
the