Subject: [multipathtcp] subflow termination with FIN

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 17 May 2012 15:42:07 -0500

All,

I have a question on termination of individual MPTCP subflows:

Multiple subflows are up with tcp_state = ESTABLISHED, when host A sends TCP FIN on SFL1 and sets this subflow's tcp_state to FIN_WAIT1.

When receiving FIN on SFL1, host B could simply enter tcp_state = CLOSE_WAIT for this SFL and keep sitting there until the end of connection.

Obviously, this is not desirable. If host A sends FIN on a SFL, host B should grant this request, stop scheduling new data on this SFL and respond with FIN ASAP.

I think this behavior should be discussed in the design doc. Thanks.

Regards,

Georg

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 17 May 2012 21:57:22 -0700

Hi Georg,

In my understanding, host B still can use this connection to send data to
host A if it wants and it doesn't break TCP's semantics. I'm guessing some
implementations want to do this kind of things.

I also agree that some implementations want to release resources quickly as
you suggested.
So, I might prefer to leave this to implementers.

Thanks,
--
Yoshifumi Nishida

On Thu, May 17, 2012 at 1:42 PM, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

>  All,****
>
> ** **
>
> I have a question on termination of individual MPTCP subflows:****
>
> ** **
>
> Multiple subflows are up with tcp_state = ESTABLISHED, when host A sends
> TCP FIN on SFL1 and sets this subflow’s tcp_state to FIN_WAIT1. ****
>
> ** **
>
> When receiving FIN on SFL1, host B could simply enter tcp_state =
> CLOSE_WAIT for this SFL and keep sitting there until the end of connection.
> ****
>
> ** **
>
> Obviously, this is not desirable. If host A sends FIN on a SFL, host B
> should grant this request, stop scheduling new data on this SFL and respond
> with FIN ASAP. ****
>
> ** **
>
> I think this behavior should be discussed in the design doc. Thanks.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Georg****
>
> ** **
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>