Subject: Re: [multipathtcp] Fallback mechanism

From: Mahesh M <[email-masked]>
Date: Wed, 2 Jan 2013 11:27:46 -0800

Hi,

Can I get some feedback on below question about fallback mechanism? This important for compatibility between different implementations.

Regards,
Mahesh

From: Mahesh M
Sent: Sunday, December 16, 2012 1:04 PM
To: 'Yoshifumi Nishida'
Cc: [email-masked]
Subject: RE: [multipathtcp] Fallback mechanism

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]<mailto:[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?

   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]<mailto:[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]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: "Alan Ford (alanford)" <[email-masked]>
Date: Wed, 2 Jan 2013 19:34:49 +0000

Hi Mahesh,

Yes, both ends would have to send MP_FAIL in this case. The sending of a DSS with infinite mapping is the acknowledgement signal to say that this MP_FAIL has been received. If no DSS is received with an infinite mapping within a window's worth of data, the MP_FAIL should be re-sent. An endpoint would also be at liberty to close and restart this subflow (with infinite mapping) if it had reason to believe its MP_FAIL was not being acted on. This is ultimately local implementation policy and I don't see it would affect compatibility in a big way.

Regards,
Alan

From: Mahesh M <[email-masked]<mailto:[email-masked]>>
Date: Wed, 2 Jan 2013 11:27:46 -0800
To: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [multipathtcp] Fallback mechanism

Hi,

Regards,
Mahesh

From: Mahesh M

Hi,

Regards,
Mahesh

Hello Mahesh,

Thanks,
--
Yoshifumi

On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M <[email-masked]<mailto:[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]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Mahesh M <[email-masked]>
Date: Wed, 2 Jan 2013 11:44:37 -0800

Hi,

I did not find any mention in the draft that the end receiving MP_FAIL also needs to send MP_FAIL after sending infinite mapping. If it is there let me know. If draft does not make in mandatory then it can create incompatibility.

Regards,
Mahesh

From: Alan Ford (alanford) [mailto:[email-masked]]
Sent: Wednesday, January 02, 2013 11:35 AM
To: Mahesh M; Yoshifumi Nishida
Cc: [email-masked]
Subject: Re: [multipathtcp] Fallback mechanism

Hi Mahesh,

Regards,
Alan

Hi,

Regards,
Mahesh

From: Mahesh M

Hi,

Regards,
Mahesh

Hello Mahesh,

Thanks,
--
Yoshifumi

---

From: "Alan Ford (alanford)" <[email-masked]>
Date: Wed, 2 Jan 2013 19:49:33 +0000

No, you do not need to send an MP_FAIL on receipt of an MP_FAIL. I thought the case you described below referred to when both ends detected a failure at the same time.

Reading again, I see you mean that you need both ends to fall back if one has signalled it.

I don't see there any technical reason why you could not have asymmetric paths deployed, with only one direction fallen back, but in reality I would expect both ends to fallback. Whilst it could could increase complexity to cope with this, it does not seem necessary to prohibit it. A simple implementation that could not cope with asymmetry in the directions could choose to send MP_FAIL on receipt of MP_FAIL and thus would be safe.

Regards,
Alan

From: Mahesh M <[email-masked]<mailto:[email-masked]>>
Date: Wed, 2 Jan 2013 11:44:37 -0800
To: Alan Ford <[email-masked]<mailto:[email-masked]>>, Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [multipathtcp] Fallback mechanism

Hi,

Regards,
Mahesh

Hi Mahesh,

Regards,
Alan

Hi,

Regards,
Mahesh

From: Mahesh M

Hi,

Regards,
Mahesh

Hello Mahesh,

Thanks,
--
Yoshifumi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 2 Jan 2013 21:53:25 -0800

Hi Mahesh,

I can imagine most of implementations will fallback in both directions and
I think it is totally fine since it's not violating the spec at all.
But, I don't see a strong reason to update the spec to make this mandatory.
Are there potential risks for one way infinite mapping?

Thanks,
--
Yoshifumi

On Wed, Jan 2, 2013 at 11:44 AM, Mahesh M <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> I did not find any mention in the draft that the end receiving MP_FAIL
> also needs to send MP_FAIL after sending infinite mapping. If it is there
> let me know. If draft does not make in mandatory then it can create
> incompatibility.****
>
> ** **
>
> Regards,****
>
> Mahesh****
>
> ** **
>
> *From:* Alan Ford (alanford) [mailto:[email-masked]]
> *Sent:* Wednesday, January 02, 2013 11:35 AM
> *To:* Mahesh M; Yoshifumi Nishida
> *Cc:* [email-masked]
> *Subject:* Re: [multipathtcp] Fallback mechanism****
>
> ** **
>
> Hi Mahesh,****
>
> ** **
>
> Yes, both ends would have to send MP_FAIL in this case. The sending of a
> DSS with infinite mapping is the acknowledgement signal to say that this
> MP_FAIL has been received. If no DSS is received with an infinite mapping
> within a window's worth of data, the MP_FAIL should be re-sent. An endpoint
> would also be at liberty to close and restart this subflow (with infinite
> mapping) if it had reason to believe its MP_FAIL was not being acted on.
> This is ultimately local implementation policy and I don't see it would
> affect compatibility in a big way.****
>
> ** **
>
> Regards,****
>
> Alan****
>
> ** **
>
> *From: *Mahesh M <[email-masked]>
> *Date: *Wed, 2 Jan 2013 11:27:46 -0800
> *To: *Yoshifumi Nishida <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [multipathtcp] Fallback mechanism****
>
> ** **
>
> Hi,****
>
>  ****
>
> Can I get some feedback on below question about fallback mechanism? This
> important for compatibility between different implementations.****
>
>  ****
>
> Regards,****
>
> Mahesh****
>
>  ****
>
> *From:* Mahesh M
> *Sent:* Sunday, December 16, 2012 1:04 PM
> *To:* 'Yoshifumi Nishida'
> *Cc:* [email-masked]
> *Subject:* RE: [multipathtcp] Fallback mechanism****
>
>  ****
>
> 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]<[email-masked]>]
>
> *Sent:* Saturday, December 15, 2012 5:12 PM
> *To:* Mahesh M
> *Cc:* [email-masked]
> *Subject:* Re: [multipathtcp] Fallback mechanism****
>
>  ****
>
> Hello Mahesh,
>
> 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.
> 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
> >
> >
> >
> >
> > [email-masked]
> >****
> _______________________________________________ multipathtcp mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/multipathtcp *
> ***
>