Subject: [multipathtcp] Bug in ns2 version of mptcp

From: Abhijit Sipani <[email-masked]>
Date: Fri, 19 Nov 2010 13:43:09 -0500

Hi all

There appears to be a bug in the ns2 implementation of mptcp. Adding a line
"$ns rtmodel-at 250 down $n0_1 $r2" at the end of the script
mptcp-sample.tcl causes the mptcp performance to go down significantly as
compared to normal tcp 1 and normal tcp 2. It appears as if the subflow even
after going down is sought to be accessed by the host. Issue has been
reported. However has the linux kernel version of mptcp been tested for
subflow failures like what happens in the case of a particular subflow going
down? Does the algorithm shift the traffic to another subflow as it should?
Would sure like to know everyone's comments and views....

Thanks and Regards
-- 

Abhijit Sipani
Graduate Student
Department of Computer Science and Engineering
North Carolina State University
919-534-5023

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 22 Nov 2010 00:42:29 -0800

Hi Abhijit,

Thanks for the bug report.
At least, this is an implementation specific bug and not a logic bug in
mptcp.
I will fix this within a week. Please wait for a bit.
I believe a mptcp implementation should have an intelligence to decide which
paths should be used for data transfer and should exclude a path with bad
quality.
In your scenario, when you turn down an interface on the mptcp node, proper
implementation will use only one interface for data transfer after it
detects failure (possibly from consecutive timeouts)
It might be an interesting question whether we should have path management
logic(e.g. how to decide link is inactive, etc) in the protocol spec (like
SCTP) or will be documented as implementers guideline.

Thanks,
--
Yoshifumi Nishida
[email-masked]

2010/11/19 Abhijit Sipani <[email-masked]>

> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>

---

From: Sébastien Barré <[email-masked]>
Date: Mon, 22 Nov 2010 12:09:00 +0100

Hi Abhijit, Yoshifumi,

To answer Abhijit's question about the Linux MPTCP behaviour in case of 
failure: it does switch the traffic to working links whenever there is a 
failure on one of them. The current exact behaviour is that by default 
the scheduler sends traffic on all paths. Then in the event of a timeout 
on one subflow, the corresponding congestion window is copied to another 
subflow to ensure that data keeps flowing (otherwise we would quickly 
get stuck with zero-window from the receiver).
The timed out subflow is not used anymore until at least one ack arrives 
on it. That means that in case of complete failure of one subflow, it is 
just disabled. And whenever it comes up again, it is used again.

Regarding where to write text about path management logic, my suggestion is:
*Put everything that requires modifications to the protocol in the 
protocol spec.
*Put everything else in the "implementation guidelines" draft. (I am 
writing one at the moment and will submit it soon).

Makes sense ?

regards,

Sébastien.

Op 22-11-10 09:42, Yoshifumi Nishida schreef:
> At least, this is an implementation specific bug and not a logic bug 
> in mptcp.
> I believe a mptcp implementation should have an intelligence to decide 
> which paths should be used for data transfer and should exclude a path 
> with bad quality.
> In your scenario, when you turn down an interface on the mptcp node, 
> proper implementation will use only one interface for data transfer 
> after it detects failure (possibly from consecutive timeouts)
> It might be an interesting question whether we should have path 
> management logic(e.g. how to decide link is inactive, etc) in the 
> protocol spec (like SCTP) or will be documented as implementers guideline.
>
> Thanks,
> --
> Yoshifumi Nishida
> [email-masked] <mailto:[email-masked]>
>
> 2010/11/19 Abhijit Sipani <[email-masked] 
> <mailto:[email-masked]>>
>
>
>     Hi all
>
>     There appears to be a bug in the ns2 implementation of mptcp.
>     Adding a line "$ns rtmodel-at 250 down $n0_1 $r2" at the end of
>     the script mptcp-sample.tcl causes the mptcp performance to go
>     down significantly as compared to normal tcp 1 and normal tcp 2.
>     It appears as if the subflow even after going down is sought to be
>     accessed by the host. Issue has been reported. However has the
>     linux kernel version of mptcp been tested for subflow failures
>     like what happens in the case of a particular subflow going down?
>     Does the algorithm shift the traffic to another subflow as it
>     should? Would sure like to know everyone's comments and views....
>
>     Thanks and Regards
>     -- 
>
>
>     Abhijit Sipani
>     Graduate Student
>     [email-masked] <mailto:[email-masked]>

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre