Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

[Christoph Paasch <[e-mail]>]

Hello,

> On Dec 15, 2019, at 12:05 PM, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi,
> One concern I have here is this may mean we end up want all implementations to support late mapping feature.
> Because if an implementation that supports the feature uses it to send data, the receiver who doesn't support it will discard the packets. To avoid it, we need to mandate receivers to support it.

that is indeed the problem. Once we allow the sender to do late/early mappings, a receiver has to implement it to be interoperable with all implementations.

More inline:

> On Sat, Dec 14, 2019 at 5:40 AM V Anil Kumar <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Christoph,
> 
> On 12/13/19 11:54 PM, Christoph Paasch <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
[...]
>> > Well it could just be due to the lack of option space insegment-1. For
>> > example, the sender ofsegment-1 at that instant wants to transmit multiple
>> > TCP options (e.g.timestamp, SACK, DSS and ADD_ADDR). Obviously, they all
>> > cannot fit into optionfield of one segment, and eventually the DSS
>> > transmission got slightly delayedby a segment or two.
>> 
>> The implementation needs to enforce a strict priority of DSS over SACK and ADD_ADDR.
> TCP options have evolved over a period of time, and I do not think as such any document/guidelines exist on  enforcing priority for one over the other, though it turns out be an interesting topic.  Also, more TCP options could come up in future for implementing  new features.  So, it is likely that implementations would follow different strategy when it come to option priority. 

This is purely an implementation choice. I don't think it is necessary to document this.
For example, when TCP-MD5 is used, Linux disables the TCP Timestamp option, thus enforcing priority of TCP-MD5 over Timestamps.


To re-iterate my earlier point: Unless there is real data about the performance benefits,... of enabling early/late mapping, my vote is to not allow these kind of mappings as they complexify implementations.


Christoph


>> 
>> 
>> If the ADD_ADDR does not fit in the TCP-option space, it can send the
>> ADD_ADDR on a pure ACK. The echo-bit in the ADD_ADDR guarantee the reliable
>> delivery of it.
> I noticed this new feature in RFC 6824-bis to deliver ADD_ADDR in pure ACK and still achieve the reliability. The ability to deliver MPTCP options in pure ACK will be useful, especially for options like ADD_ADDR.   
>> 
>> 
>> Sure, one could argue that favoring SACK over DSS is more important. But I
>> think we would need data to justify that. Only very specific traffic
>> patterns will fall in this use-case.
> The bottomline is that in the event of a map being slightly delayed, i.e., delivered late with respect to the corresponding data, should  it result in resetting the subflow? 
> 
> As far as the specification is concerned, it could be liberal on accepting such maps, rather than being restrictive. Even if a current implementation cannot support this, future implementations may like to, provided the specification permits this and the implementation is willing to cop up with the associated complexity. 
> 
> Best regards,
> 
> Anil
>> 
>> 
>> Christoph
>> 
>> > 
>> >  
>> > 
>> > With regards,
>> > 
>> >  
>> > 
>> > Anil
>> > 
>> >  
>> > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > 
>> > > Christoph
>> > > 
>> > > 
>> > > > 
>> > > > 
>> > > > 
>> > > > Further, segment-3 cannot combine/cover the data in segment-1 and segment-3 in a "single map", as the data sequence space is not continuous, i.e., some in between data (segment-2) is mapped and transmitted through subflow-2. Here, the map in segment-3 does not even partially cover the data it carries. 
>> > > > 
>> > > > 
>> > > >  
>> > > > 
>> > > > Both RFC 6824 and the 6824-bis do not restrict the above scenario, and I guess the change proposed now does not permit this to happen. 
>> > > > 
>> > > > 
>> > > >  
>> > > > 
>> > > > Best regards, 
>> > > > 
>> > > > 
>> > > >  
>> > > > 
>> > > > Anil 
>> > > > 
>> > > > 
>> > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > That's the reason why we (the MPTCP-upstreaming community) vouch to have this case restricted.
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > Cheers,
>> > > > > Christoph
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > > Anil 
>> > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > 
>> > > > > > > Best regards,
>> > > > > > > 
>> > > > > > > Alan
>> > > > > > > 
>> > > > > > > 
>> > > > > > >  
>> > > > > > > 
>> > > > > > 
>> > > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > >  
>> > > > > 
>> > > > 
>> > > > 
>> > > 
>> > > 
>> > > 
>> > >  
>> > >
> _______________________________________________
> multipathtcp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>