Subject: [multipathtcp] Fallback mechanism

From: Mahesh M <[email-masked]>
Date: Thu, 13 Dec 2012 12:05:40 -0800

Hi,

Is the infinite mapping signaling is per direction of the flow or it applies to both the direction? In the draft  it is not clear if one end sends infinite mapping  the other end needs to send it or not. Thinking about it, looks like it is  per direction and if one end sends the infinite mapping other end can still continue to using regular(finite) DSS mapping. But, theoretically after the fallback it's a single flow, both ends needs to fallback to infinite mapping.

Regards,

Mahesh

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 15 Dec 2012 17:12:04 -0800

Hello Mahesh,

I think it's an interesting discussion point.
According to the draft, it doesn't necessarily require to close all
subflows except one.
If other subflows are still active, it might be possible for the other side
to continue using MPTCP as long as data acks come back. If we think about
this kind of situations, I think infinite mapping will be one direction.
Do you have any concern about using infinite mappings in one direction?

   When a connection has fallen back, only one subflow can send data,
   otherwise the receiver would not know how to reorder the data.  In
   practice, this means that all MPTCP subflows will have to be
   terminated except one.

Thanks,
--
Yoshifumi

On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M <[email-masked]> wrote:
>
> Hi,
>
>
>
> Is the infinite mapping signaling is per direction of the flow or it
applies to both the direction? In the draft  it is not clear if one end
sends infinite mapping  the other end needs to send it or not. Thinking
about it, looks like it is  per direction and if one end sends the infinite
mapping other end can still continue to using regular(finite) DSS mapping.
But, theoretically after the fallback it’s a single flow, both ends needs
to fallback to infinite mapping.
>
>
>
> Regards,
>
> Mahesh
>
>
>
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Mahesh M <[email-masked]>
Date: Sun, 16 Dec 2012 13:04:22 -0800

Hi,

I understand the reason for having a single subflow at the time of fallback. This is exactly why both ends should fallback to infinite mapping and after that they should not send any more DSS options. In the draft there two different types of fallback one at the time of first ACK and second when there is a checksum issue. For the first one there is no explicit signaling from the receiver but for the later one we have explicit MP_FAIL signal from the receiver. In the explicit MP_FAIL signaling case, it contains the sequence number from where it wants to receive the data from the MPTCP sequence space. If we consider a case where in both the directions data in flowing simultaneously, if one side fallback to infinite mapping other side has to fallback too, but for this MP_FAIL signal has to be generated in both the directions so that both ends can sync up and learn the sequence from which they need to start infinite mapping.
Since there is no explicit signaling for the fallback mechanism at the first ACK case, there needs some clarification in the draft on how/when both the ends will sync up on sending infinite mapping.

Regards,
Mahesh

From: Yoshifumi Nishida [mailto:[email-masked]]
Sent: Saturday, December 15, 2012 5:12 PM
To: Mahesh M
Cc: [email-masked]
Subject: Re: [multipathtcp] Fallback mechanism

Hello Mahesh,

I think it's an interesting discussion point.
According to the draft, it doesn't necessarily require to close all subflows except one.
If other subflows are still active, it might be possible for the other side to continue using MPTCP as long as data acks come back. If we think about this kind of situations, I think infinite mapping will be one direction.
Do you have any concern about using infinite mappings in one direction?

Thanks,
--
Yoshifumi

On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>