* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-13 5:52 V Anil Kumar
0 siblings, 0 replies; 12+ messages in thread
From: V Anil Kumar @ 2019-12-13 5:52 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 6153 bytes --]
Hi Christoph,
Thanks for your reply. Please see inline.
On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>
>
>
>
>
> Hello,
>
>
>
>
> >
> > On Dec 10, 2019, at 12:04 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> >
> >
> > Hi Alan,
> >
> >
> >
> > Please see inline.
> >
> > On 12/06/19 09:28 PM, Alan Ford <alan.ford(a)gmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Hi all,
> > >
> > >
> > >
> > >
> > > Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
> > >
> > >
> > >
> > >
> > > ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
> > >
> > >
> > >
> > >
> > > WG participants, please speak up if you have any concerns.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Edit 1, clarifying reliability of MP_CAPABLE
> > >
> > >
> > >
> > >
> > > Change the sentence reading:
> > >
> > >
> > >
> > >
> > > The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
> > >
> > >
> > >
> > >
> > > To:
> > >
> > >
> > >
> > >
> > > The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Change the sentence reading:
> > >
> > >
> > >
> > >
> > > If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
> > >
> > >
> > >
> > >
> > > To:
> > >
> > >
> > >
> > >
> > > If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Edit 2, mapping constraint
> > >
> > >
> > >
> > >
> > > Change the sentence reading:
> > >
> > >
> > >
> > >
> > > A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> > >
> > >
> > >
> > >
> > > To:
> > >
> > >
> > >
> > >
> > > A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > As far as I understand, the proposed change introduces a “MUST” to insist that the map in a segment must cover at least some data in the segment. But the document does not talk anything about the rational behind it. I guess it is purely an
> >
> > ease of implementation?
> >
> >
>
>
> For two reasons:
>
> 1. Ease of implementation
> 2. If an implementation tries to "remember" early mappings, it is not clear how many of these an implementation can hold. Thus, the sender does not know how many early mappings he can send. So, it is hard for a sender to do the right thing.
>
>
> >
> >
> >
> > I think the design/format of the Data Sequence Mapping permits the map to stand independent of the data being carried in a segment. So, as long as an implementation is willing to deal with the complexity of storing and processing late and early mappings (with respect to the data arrival), it could be permitted provided that the received map is for an in-window data.
> >
> >
>
>
> What is the concrete use-case for such early mappings? What are the benefits of it? I think that if we want to enable such implementation-complexity, we need a compelling use-case with a big benefit.
>
>
>
>
Consider a case where a MPTCP connection consists of two subflows, and the data segments are scheduled for transmission in the order shown below below.
Subflow-1: segment-1 segment-3 segment-5 segment-6
bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
no map map for 1-100 map for 401-600 no map
Subflow-2: segment-2 segment-4 segment-7 segment-8
bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
map for 101-200 map for 301-400 map for 601-800 no map
In the above case, the map for data in segment-1 is included in segment-3. 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
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 14314 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-20 8:42 Christoph Paasch
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Paasch @ 2019-12-20 8:42 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 6657 bytes --]
> On Dec 18, 2019, at 6:07 AM, V Anil Kumar <anil(a)csir4pi.in> wrote:
>
> Hi,
>
> On 12/15/19 10:35 PM, Christoph Paasch <cpaasch(a)apple.com <mailto:cpaasch(a)apple.com>> wrote:
>>
>> Hello,
>>
>>
>>> On Dec 15, 2019, at 12:05 PM, Yoshifumi Nishida <nsd.ietf(a)gmail.com <mailto:nsd.ietf(a)gmail.com>> 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 <anil(a)csir4pi.in <mailto:anil(a)csir4pi.in>> wrote:
>>> Hi Christoph,
>>>
>>> On 12/13/19 11:54 PM, Christoph Paasch <cpaasch(a)apple.com <mailto:cpaasch(a)apple.com>> 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.
>>
>
> When MPTCP is used for data transfer in both directions, the need to carry both timestamp and SACK options in a data segment may not be a rare case, as data loss or out-of-order reception can happen in both directions. On such a data segment, once timestamp and SACK options are included, packing DSS with map is not feasible. Should the data segment in such case include SACK or DSS? How does the Linux implementation of MPTCP deal with such a case?
>
It should include a DSS and fill up the remainder of the option-space with SACK-blocks. That is also what Linux does.
Christoph
>
>
> Anil
>
>>
>>
>>
>>
>> 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
>>> multipathtcp(a)ietf.org <mailto:multipathtcp(a)ietf.org>
>>> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 22057 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-18 5:07 V Anil Kumar
0 siblings, 0 replies; 12+ messages in thread
From: V Anil Kumar @ 2019-12-18 5:07 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 7167 bytes --]
Hi,
On 12/15/19 10:35 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>
>
>
>
>
> Hello,
>
>
>
>
> >
> > On Dec 15, 2019, at 12:05 PM, Yoshifumi Nishida <nsd.ietf(a)gmail.com> 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 <anil(a)csir4pi.in> wrote:
> >
> >
> > > Hi Christoph,
> > >
> > > On 12/13/19 11:54 PM, Christoph Paasch <cpaasch(a)apple.com> 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.
>
>
>
>
When MPTCP is used for data transfer in both directions, the need to carry both timestamp and SACK options in a data segment may not be a rare case, as data loss or out-of-order reception can happen in both directions. On such a data segment, once timestamp and SACK options are included, packing DSS with map is not feasible. Should the data segment in such case include SACK or DSS? How does the Linux implementation of MPTCP deal with such a case?
Anil
>
>
>
>
>
>
>
>
>
> 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
> > > multipathtcp(a)ietf.org
> > > https://www.ietf.org/mailman/listinfo/multipathtcp
> > >
> >
> >
> >
>
>
>
>
>
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 11986 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-15 17:05 Christoph Paasch
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Paasch @ 2019-12-15 17:05 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 5439 bytes --]
Hello,
> On Dec 15, 2019, at 12:05 PM, Yoshifumi Nishida <nsd.ietf(a)gmail.com> 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 <anil(a)csir4pi.in <mailto:anil(a)csir4pi.in>> wrote:
> Hi Christoph,
>
> On 12/13/19 11:54 PM, Christoph Paasch <cpaasch(a)apple.com <mailto:cpaasch(a)apple.com>> 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
> multipathtcp(a)ietf.org <mailto:multipathtcp(a)ietf.org>
> https://www.ietf.org/mailman/listinfo/multipathtcp <https://www.ietf.org/mailman/listinfo/multipathtcp>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 10380 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-15 14:20 V Anil Kumar
0 siblings, 0 replies; 12+ messages in thread
From: V Anil Kumar @ 2019-12-15 14:20 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
Hi Joe,
On 12/14/19 10:48 PM, Joe Touch <touch(a)strayalpha.com> wrote:
>
>
>
>
>
>
>
>
>
>
> >
> > On Dec 14, 2019, at 5:39 AM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> >
> >
> >
> >
> > >
> > > 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.
> >
> >
>
>
>
> FYI, this has come up as an issue before.
>
>
>
>
> TCP options are individual and accepted in isolation. They are easily confirmed only during SYN exchange; anything after that requires a stateful, reliable transmission mechanism for coordination.
>
>
>
>
> There is no way to retrofit any ordering constraints, or prioritization. If you need that sort of feature, it needs to be built inside a single option as “sub options”.
>
>
>
>
>
>
Thank you for sharing this information.
I agree with this.
Anil
>
>
>
>
>
> Joe
>
>
>
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3415 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-15 11:05 Yoshifumi Nishida
0 siblings, 0 replies; 12+ messages in thread
From: Yoshifumi Nishida @ 2019-12-15 11:05 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 12353 bytes --]
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.
--
Yoshi
On Sat, Dec 14, 2019 at 5:40 AM V Anil Kumar <anil(a)csir4pi.in> wrote:
> Hi Christoph,
>
> On 12/13/19 11:54 PM, *Christoph Paasch * <cpaasch(a)apple.com> wrote:
>
> On 13/12/19 - 23:41:25, V Anil Kumar wrote:
> > Hi Christoph,
> >
> > Thanks again for your reply. My response is given inline.
> >
> > On 12/13/19 09:59 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> > > >
> > > >
> > >
> > >
> > > >
> > > > Hi Christoph,
> > > >
> > > > Thanks for your reply. Please see inline.
> > > >
> > > > On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar
> > > > > > <anil(a)csir4pi.in(javascript:main.compose()> wrote:
> > > > > >
> > > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > On 12/06/19 09:28 PM,Alan
> > > > > > Ford<alan.ford(a)gmail.com(javascript:main.compose()> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Following on from the discussion of implementation feedback
> with
> > > > > > > Christoph, I propose the following edits to RFC6824bis - which
> > > > > > > is currently in AUTH48 - as clarifications.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ADs, please can you confirm you consider these edits
> > > > > > > sufficiently editorial to fit into AUTH48.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > WG participants, please speak up if you have any concerns.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Edit 1, clarifying reliability of MP_CAPABLE
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > > sequence space, although this does not need to be acknowledged
> > > > > > > at the connection level until the first data is sent (see
> > > > > > > Section 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > > sequence space, and this MUST be acknowledged at the
> connection
> > > > > > > level at or before the time the first data is sent or received
> > > > > > > (see Section 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > > ACK + MP_CAPABLE can be inferred by the receipt of this data
> > > > > > > with an MPTCP Data Sequence Signal (DSS) option (Section
> 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > > ACK + MP_CAPABLE is ensured by the receipt of this data with
> an
> > > > > > > MPTCP Data Sequence Signal (DSS) option (Section 3.3)
> > > > > > > containing a DATA_ACK for the MP_CAPABLE (which is the first
> > > > > > > octet of the data sequence space).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > In my personal opinion either one of these edits would be
> > > > > > > sufficient for making the point, however clearly this has
> caused
> > > > > > > some confusion amongst the implementor community so making both
> > > > > > > these changes should make it absolutely clear as to the
> expected
> > > > > > > behaviour here.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Edit 2, mapping constraint
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > A Data Sequence Mapping does not need to be included in every
> > > > > > > MPTCP packet, as long as the subflow sequence space in that
> > > > > > > packet is covered by a mapping known at the receiver.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > A Data Sequence Mapping MUST appear on a TCP segment which is
> > > > > > > covered by the mapping. It does not need to be included in
> > > > > > > every MPTCP packet, as long as the subflow sequence space in
> > > > > > > that packet is covered by a mapping known at the receiver.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > As far as I understand, the proposed change introduces a “MUST”
> to
> > > > > > insist that the map in a segment must cover at least some data in
> > > > > > the segment. But the document does not talk anything about the
> > > > > > rational behind it. I guess it is purely an
> > > > > >
> > > > > > ease of implementation?
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > For two reasons:
> > > > >
> > > > > 1. Ease of implementation 2. If an implementation tries to
> > > > > "remember" early mappings, it is not clear how many of these an
> > > > > implementation can hold. Thus, the sender does not know how many
> > > > > early mappings he can send. So, it is hard for a sender to do the
> > > > > right thing.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think the design/format of the Data Sequence Mapping permits
> the
> > > > > > map to stand independent of the data being carried in a segment.
> > > > > > So, as long as an implementation is willing to deal with the
> > > > > > complexity of storing and processing late and early mappings
> (with
> > > > > > respect to the data arrival), it could be permitted provided that
> > > > > > the received map is for an in-window data.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > What is the concrete use-case for such early mappings? What are the
> > > > > benefits of it? I think that if we want to enable such
> > > > > implementation-complexity, we need a compelling use-case with a big
> > > > > benefit.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > Consider a case where a MPTCP connection consists of two subflows,
> and
> > > > the data segments are scheduled for transmission in the order shown
> > > > below below.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-1: segment-1 segment-3 segment-5 segment-6
> > > >
> > > > bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> > > >
> > > > no map map for 1-100 map for 401-600 no map
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-2: segment-2 segment-4 segment-7 segment-8
> > > >
> > > > bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> > > >
> > > > map for 101-200 map for 301-400 map for 601-800 no map
> > > >
> > > >
> > > >
> > > > In the above case, the map for data in segment-1 is included in
> > > > segment-3.
> > > >
> > > >
> > > >
> > >
> > >
> > > The question here is why would the stack not put the mapping for
> segment
> > > 1 on segment 1 itself. And what is the benefit of doing so?
> > >
> > >
> > >
> > >
> > >
> >
> > 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.
>
>
>
> 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
> multipathtcp(a)ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 19098 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-14 17:18 Joe Touch
0 siblings, 0 replies; 12+ messages in thread
From: Joe Touch @ 2019-12-14 17:18 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
> On Dec 14, 2019, at 5:39 AM, V Anil Kumar <anil(a)csir4pi.in> wrote:
>
>> 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.
FYI, this has come up as an issue before.
TCP options are individual and accepted in isolation. They are easily confirmed only during SYN exchange; anything after that requires a stateful, reliable transmission mechanism for coordination.
There is no way to retrofit any ordering constraints, or prioritization. If you need that sort of feature, it needs to be built inside a single option as “sub options”.
Joe
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2573 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-14 13:39 V Anil Kumar
0 siblings, 0 replies; 12+ messages in thread
From: V Anil Kumar @ 2019-12-14 13:39 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 11962 bytes --]
Hi Christoph,
On 12/13/19 11:54 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>
> On 13/12/19 - 23:41:25, V Anil Kumar wrote:
> > Hi Christoph,
> >
> > Thanks again for your reply. My response is given inline.
> >
> > On 12/13/19 09:59 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > > > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> > > >
> > > >
> > >
> > >
> > > >
> > > > Hi Christoph,
> > > >
> > > > Thanks for your reply. Please see inline.
> > > >
> > > > On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar
> > > > > > <anil(a)csir4pi.in(javascript:main.compose()> wrote:
> > > > > >
> > > > > >
> > > > > > Hi Alan,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Please see inline.
> > > > > >
> > > > > > On 12/06/19 09:28 PM,Alan
> > > > > > Ford<alan.ford(a)gmail.com(javascript:main.compose()> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Following on from the discussion of implementation feedback with
> > > > > > > Christoph, I propose the following edits to RFC6824bis - which
> > > > > > > is currently in AUTH48 - as clarifications.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ADs, please can you confirm you consider these edits
> > > > > > > sufficiently editorial to fit into AUTH48.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > WG participants, please speak up if you have any concerns.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Edit 1, clarifying reliability of MP_CAPABLE
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > > sequence space, although this does not need to be acknowledged
> > > > > > > at the connection level until the first data is sent (see
> > > > > > > Section 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > > sequence space, and this MUST be acknowledged at the connection
> > > > > > > level at or before the time the first data is sent or received
> > > > > > > (see Section 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > > ACK + MP_CAPABLE can be inferred by the receipt of this data
> > > > > > > with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > > ACK + MP_CAPABLE is ensured by the receipt of this data with an
> > > > > > > MPTCP Data Sequence Signal (DSS) option (Section 3.3)
> > > > > > > containing a DATA_ACK for the MP_CAPABLE (which is the first
> > > > > > > octet of the data sequence space).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > In my personal opinion either one of these edits would be
> > > > > > > sufficient for making the point, however clearly this has caused
> > > > > > > some confusion amongst the implementor community so making both
> > > > > > > these changes should make it absolutely clear as to the expected
> > > > > > > behaviour here.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Edit 2, mapping constraint
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Change the sentence reading:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > A Data Sequence Mapping does not need to be included in every
> > > > > > > MPTCP packet, as long as the subflow sequence space in that
> > > > > > > packet is covered by a mapping known at the receiver.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > To:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > A Data Sequence Mapping MUST appear on a TCP segment which is
> > > > > > > covered by the mapping. It does not need to be included in
> > > > > > > every MPTCP packet, as long as the subflow sequence space in
> > > > > > > that packet is covered by a mapping known at the receiver.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > As far as I understand, the proposed change introduces a “MUST” to
> > > > > > insist that the map in a segment must cover at least some data in
> > > > > > the segment. But the document does not talk anything about the
> > > > > > rational behind it. I guess it is purely an
> > > > > >
> > > > > > ease of implementation?
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > For two reasons:
> > > > >
> > > > > 1. Ease of implementation 2. If an implementation tries to
> > > > > "remember" early mappings, it is not clear how many of these an
> > > > > implementation can hold. Thus, the sender does not know how many
> > > > > early mappings he can send. So, it is hard for a sender to do the
> > > > > right thing.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I think the design/format of the Data Sequence Mapping permits the
> > > > > > map to stand independent of the data being carried in a segment.
> > > > > > So, as long as an implementation is willing to deal with the
> > > > > > complexity of storing and processing late and early mappings (with
> > > > > > respect to the data arrival), it could be permitted provided that
> > > > > > the received map is for an in-window data.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > What is the concrete use-case for such early mappings? What are the
> > > > > benefits of it? I think that if we want to enable such
> > > > > implementation-complexity, we need a compelling use-case with a big
> > > > > benefit.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > Consider a case where a MPTCP connection consists of two subflows, and
> > > > the data segments are scheduled for transmission in the order shown
> > > > below below.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-1: segment-1 segment-3 segment-5 segment-6
> > > >
> > > > bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> > > >
> > > > no map map for 1-100 map for 401-600 no map
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Subflow-2: segment-2 segment-4 segment-7 segment-8
> > > >
> > > > bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> > > >
> > > > map for 101-200 map for 301-400 map for 601-800 no map
> > > >
> > > >
> > > >
> > > > In the above case, the map for data in segment-1 is included in
> > > > segment-3.
> > > >
> > > >
> > > >
> > >
> > >
> > > The question here is why would the stack not put the mapping for segment
> > > 1 on segment 1 itself. And what is the benefit of doing so?
> > >
> > >
> > >
> > >
> > >
> >
> > 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.
>
>
>
> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 18854 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-13 18:24 Christoph Paasch
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Paasch @ 2019-12-13 18:24 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 9954 bytes --]
On 13/12/19 - 23:41:25, V Anil Kumar wrote:
> Hi Christoph,
>
> Thanks again for your reply. My response is given inline.
>
> On 12/13/19 09:59 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> >
> >
> >
> >
> >
> >
> > Hello,
> >
> >
> >
> > > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> > >
> > >
> >
> >
> > >
> > > Hi Christoph,
> > >
> > > Thanks for your reply. Please see inline.
> > >
> > > On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar
> > > > > <anil(a)csir4pi.in(javascript:main.compose()> wrote:
> > > > >
> > > > >
> > > > > Hi Alan,
> > > > >
> > > > >
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > On 12/06/19 09:28 PM,Alan
> > > > > Ford<alan.ford(a)gmail.com(javascript:main.compose()> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Following on from the discussion of implementation feedback with
> > > > > > Christoph, I propose the following edits to RFC6824bis - which
> > > > > > is currently in AUTH48 - as clarifications.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ADs, please can you confirm you consider these edits
> > > > > > sufficiently editorial to fit into AUTH48.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > WG participants, please speak up if you have any concerns.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Edit 1, clarifying reliability of MP_CAPABLE
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Change the sentence reading:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > sequence space, although this does not need to be acknowledged
> > > > > > at the connection level until the first data is sent (see
> > > > > > Section 3.3).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > The SYN with MP_CAPABLE occupies the first octet of data
> > > > > > sequence space, and this MUST be acknowledged at the connection
> > > > > > level at or before the time the first data is sent or received
> > > > > > (see Section 3.3).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Change the sentence reading:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > ACK + MP_CAPABLE can be inferred by the receipt of this data
> > > > > > with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > If B has data to send first, then the reliable delivery of the
> > > > > > ACK + MP_CAPABLE is ensured by the receipt of this data with an
> > > > > > MPTCP Data Sequence Signal (DSS) option (Section 3.3)
> > > > > > containing a DATA_ACK for the MP_CAPABLE (which is the first
> > > > > > octet of the data sequence space).
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > In my personal opinion either one of these edits would be
> > > > > > sufficient for making the point, however clearly this has caused
> > > > > > some confusion amongst the implementor community so making both
> > > > > > these changes should make it absolutely clear as to the expected
> > > > > > behaviour here.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Edit 2, mapping constraint
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Change the sentence reading:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > A Data Sequence Mapping does not need to be included in every
> > > > > > MPTCP packet, as long as the subflow sequence space in that
> > > > > > packet is covered by a mapping known at the receiver.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > A Data Sequence Mapping MUST appear on a TCP segment which is
> > > > > > covered by the mapping. It does not need to be included in
> > > > > > every MPTCP packet, as long as the subflow sequence space in
> > > > > > that packet is covered by a mapping known at the receiver.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > As far as I understand, the proposed change introduces a “MUST” to
> > > > > insist that the map in a segment must cover at least some data in
> > > > > the segment. But the document does not talk anything about the
> > > > > rational behind it. I guess it is purely an
> > > > >
> > > > > ease of implementation?
> > > > >
> > > > >
> > > >
> > > >
> > > > For two reasons:
> > > >
> > > > 1. Ease of implementation 2. If an implementation tries to
> > > > "remember" early mappings, it is not clear how many of these an
> > > > implementation can hold. Thus, the sender does not know how many
> > > > early mappings he can send. So, it is hard for a sender to do the
> > > > right thing.
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > I think the design/format of the Data Sequence Mapping permits the
> > > > > map to stand independent of the data being carried in a segment.
> > > > > So, as long as an implementation is willing to deal with the
> > > > > complexity of storing and processing late and early mappings (with
> > > > > respect to the data arrival), it could be permitted provided that
> > > > > the received map is for an in-window data.
> > > > >
> > > > >
> > > >
> > > >
> > > > What is the concrete use-case for such early mappings? What are the
> > > > benefits of it? I think that if we want to enable such
> > > > implementation-complexity, we need a compelling use-case with a big
> > > > benefit.
> > > >
> > > >
> > > >
> > > >
> > >
> > > Consider a case where a MPTCP connection consists of two subflows, and
> > > the data segments are scheduled for transmission in the order shown
> > > below below.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Subflow-1: segment-1 segment-3 segment-5 segment-6
> > >
> > > bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> > >
> > > no map map for 1-100 map for 401-600 no map
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Subflow-2: segment-2 segment-4 segment-7 segment-8
> > >
> > > bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> > >
> > > map for 101-200 map for 301-400 map for 601-800 no map
> > >
> > >
> > >
> > > In the above case, the map for data in segment-1 is included in
> > > segment-3.
> > >
> > >
> > >
> >
> >
> > The question here is why would the stack not put the mapping for segment
> > 1 on segment 1 itself. And what is the benefit of doing so?
> >
> >
> >
> >
> >
>
> 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.
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.
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.
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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-13 18:11 V Anil Kumar
0 siblings, 0 replies; 12+ messages in thread
From: V Anil Kumar @ 2019-12-13 18:11 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 8251 bytes --]
Hi Christoph,
Thanks again for your reply. My response is given inline.
On 12/13/19 09:59 PM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>
>
>
>
>
>
> Hello,
>
>
>
> > On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
> >
> >
>
>
> >
> > Hi Christoph,
> >
> > Thanks for your reply. Please see inline.
> >
> > On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > >
> > >
> > >
> > > >
> > > > On Dec 10, 2019, at 12:04 PM, V Anil Kumar <anil(a)csir4pi.in(javascript:main.compose()> wrote:
> > > >
> > > >
> > > > Hi Alan,
> > > >
> > > >
> > > >
> > > > Please see inline.
> > > >
> > > > On 12/06/19 09:28 PM,Alan Ford<alan.ford(a)gmail.com(javascript:main.compose()> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > WG participants, please speak up if you have any concerns.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Edit 1, clarifying reliability of MP_CAPABLE
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Change the sentence reading:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Change the sentence reading:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Edit 2, mapping constraint
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Change the sentence reading:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > To:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > As far as I understand, the proposed change introduces a “MUST” to insist that the map in a segment must cover at least some data in the segment. But the document does not talk anything about the rational behind it. I guess it is purely an
> > > >
> > > > ease of implementation?
> > > >
> > > >
> > >
> > >
> > > For two reasons:
> > >
> > > 1. Ease of implementation
> > > 2. If an implementation tries to "remember" early mappings, it is not clear how many of these an implementation can hold. Thus, the sender does not know how many early mappings he can send. So, it is hard for a sender to do the right thing.
> > >
> > >
> > > >
> > > >
> > > >
> > > > I think the design/format of the Data Sequence Mapping permits the map to stand independent of the data being carried in a segment. So, as long as an implementation is willing to deal with the complexity of storing and processing late and early mappings (with respect to the data arrival), it could be permitted provided that the received map is for an in-window data.
> > > >
> > > >
> > >
> > >
> > > What is the concrete use-case for such early mappings? What are the benefits of it? I think that if we want to enable such implementation-complexity, we need a compelling use-case with a big benefit.
> > >
> > >
> > >
> > >
> >
> > Consider a case where a MPTCP connection consists of two subflows, and the data segments are scheduled for transmission in the order shown below below.
> >
> >
> >
> >
> >
> >
> > Subflow-1: segment-1 segment-3 segment-5 segment-6
> >
> > bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> >
> > no map map for 1-100 map for 401-600 no map
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Subflow-2: segment-2 segment-4 segment-7 segment-8
> >
> > bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> >
> > map for 101-200 map for 301-400 map for 601-800 no map
> >
> >
> >
> > In the above case, the map for data in segment-1 is included in segment-3.
> >
> >
> >
>
>
> The question here is why would the stack not put the mapping for segment 1 on segment 1 itself. And what is the benefit of doing so?
>
>
>
>
>
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.
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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>
>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 42942 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-13 16:29 Christoph Paasch
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Paasch @ 2019-12-13 16:29 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 5862 bytes --]
Hello,
> On Dec 12, 2019, at 9:53 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
>
> Hi Christoph,
>
> Thanks for your reply. Please see inline.
>
>> On 12/12/19 12:52 AM, Christoph Paasch <cpaasch(a)apple.com> wrote:
>>
>> Hello,
>>
>>
>>> On Dec 10, 2019, at 12:04 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
>>>
>>> Hi Alan,
>>>
>>> Please see inline.
>>>
>>>> On 12/06/19 09:28 PM,Alan Ford<alan.ford(a)gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>
>>>> Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
>>>>
>>>> ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
>>>>
>>>> WG participants, please speak up if you have any concerns.
>>>>
>>>>
>>>> Edit 1, clarifying reliability of MP_CAPABLE
>>>>
>>>> Change the sentence reading:
>>>>
>>>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
>>>>
>>>> To:
>>>>
>>>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
>>>>
>>>>
>>>> Change the sentence reading:
>>>>
>>>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
>>>>
>>>> To:
>>>>
>>>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
>>>>
>>>>
>>>> In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
>>>>
>>>>
>>>> Edit 2, mapping constraint
>>>>
>>>> Change the sentence reading:
>>>>
>>>> A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>>>
>>>> To:
>>>>
>>>> A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>>>
>>> As far as I understand, the proposed change introduces a “MUST” to insist that the map in a segment must cover at least some data in the segment. But the document does not talk anything about the rational behind it. I guess it is purely an
>>> ease of implementation?
>>
>> For two reasons:
>>
>> 1. Ease of implementation
>> 2. If an implementation tries to "remember" early mappings, it is not clear how many of these an implementation can hold. Thus, the sender does not know how many early mappings he can send. So, it is hard for a sender to do the right thing.
>>
>>> I think the design/format of the Data Sequence Mapping permits the map to stand independent of the data being carried in a segment. So, as long as an implementation is willing to deal with the complexity of storing and processing late and early mappings (with respect to the data arrival), it could be permitted provided that the received map is for an in-window data.
>>
>> What is the concrete use-case for such early mappings? What are the benefits of it? I think that if we want to enable such implementation-complexity, we need a compelling use-case with a big benefit.
>>
> Consider a case where a MPTCP connection consists of two subflows, and the data segments are scheduled for transmission in the order shown below below.
>
> Subflow-1: segment-1 segment-3 segment-5 segment-6
> bytes:1-100 bytes:201-300 bytes:401-500 bytes:501-600
> no map map for 1-100 map for 401-600 no map
>
>
> Subflow-2: segment-2 segment-4 segment-7 segment-8
> bytes: 101-200 bytes:301-400 bytes: 601-700 bytes:701-800
> map for 101-200 map for 301-400 map for 601-800 no map
>
> In the above case, the map for data in segment-1 is included in segment-3.
The question here is why would the stack not put the mapping for segment 1 on segment 1 itself. And what is the benefit of doing so?
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
>>>>
>>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 16294 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
@ 2019-12-11 19:22 Christoph Paasch
0 siblings, 0 replies; 12+ messages in thread
From: Christoph Paasch @ 2019-12-11 19:22 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]
Hello,
> On Dec 10, 2019, at 12:04 PM, V Anil Kumar <anil(a)csir4pi.in> wrote:
>
> Hi Alan,
>
> Please see inline.
>
> On 12/06/19 09:28 PM, Alan Ford <alan.ford(a)gmail.com <mailto:alan.ford(a)gmail.com>> wrote:
>>
>> Hi all,
>>
>>
>> Following on from the discussion of implementation feedback with Christoph, I propose the following edits to RFC6824bis - which is currently in AUTH48 - as clarifications.
>>
>> ADs, please can you confirm you consider these edits sufficiently editorial to fit into AUTH48.
>>
>> WG participants, please speak up if you have any concerns.
>>
>>
>> Edit 1, clarifying reliability of MP_CAPABLE
>>
>> Change the sentence reading:
>>
>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
>>
>> To:
>>
>> The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at or before the time the first data is sent or received (see Section 3.3).
>>
>>
>> Change the sentence reading:
>>
>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3).
>>
>> To:
>>
>> If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
>>
>>
>> In my personal opinion either one of these edits would be sufficient for making the point, however clearly this has caused some confusion amongst the implementor community so making both these changes should make it absolutely clear as to the expected behaviour here.
>>
>>
>> Edit 2, mapping constraint
>>
>> Change the sentence reading:
>>
>> A Data Sequence Mapping does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>
>> To:
>>
>> A Data Sequence Mapping MUST appear on a TCP segment which is covered by the mapping. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver.
>>
> As far as I understand, the proposed change introduces a “MUST” to insist that the map in a segment must cover at least some data in the segment. But the document does not talk anything about the rational behind it. I guess it is purely an
> ease of implementation?
For two reasons:
1. Ease of implementation
2. If an implementation tries to "remember" early mappings, it is not clear how many of these an implementation can hold. Thus, the sender does not know how many early mappings he can send. So, it is hard for a sender to do the right thing.
> I think the design/format of the Data Sequence Mapping permits the map to stand independent of the data being carried in a segment. So, as long as an implementation is willing to deal with the complexity of storing and processing late and early mappings (with respect to the data arrival), it could be permitted provided that the received map is for an in-window data.
What is the concrete use-case for such early mappings? What are the benefits of it? I think that if we want to enable such implementation-complexity, we need a compelling use-case with a big benefit.
That's the reason why we (the MPTCP-upstreaming community) vouch to have this case restricted.
Cheers,
Christoph
>
> Anil
>>
>>
>>
>> Best regards,
>> Alan
>>
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 8857 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-12-20 8:42 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-13 5:52 [MPTCP] Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis V Anil Kumar
-- strict thread matches above, loose matches on Subject: below --
2019-12-20 8:42 Christoph Paasch
2019-12-18 5:07 V Anil Kumar
2019-12-15 17:05 Christoph Paasch
2019-12-15 14:20 V Anil Kumar
2019-12-15 11:05 Yoshifumi Nishida
2019-12-14 17:18 Joe Touch
2019-12-14 13:39 V Anil Kumar
2019-12-13 18:24 Christoph Paasch
2019-12-13 18:11 V Anil Kumar
2019-12-13 16:29 Christoph Paasch
2019-12-11 19:22 Christoph Paasch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.