<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>Michael,<br><br>Did you get off (iccrg) list response to your point (2) below? I have similar concerns to yours...<br><br>Dirceu<br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Michael Tüxen <Michael.Tuexen@lurchi.franken.de><br><b><span style="font-weight: bold;">Cc:</span></b> multipathtcp@ietf.org; iccrg <iccrg@cs.ucl.ac.uk><br><b><span style="font-weight: bold;">Sent:</span></b> Wed, January 26, 2011 3:25:20 PM<br><b><span style="font-weight: bold;">Subject:</span></b> [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport
Protocols"<br></font><br>
Hi Philip,<br><br>I have some questions regarding section 3:<br><br>(1) It is stated:<br> "Since we require that the total throughput is no worse<br> than the throughput a single TCP would get on the best path..."<br> and later:<br> "The formula is derived by equalizing the rate of the multipath flow<br> with the rate of a TCP running on the best path, and solving for<br> alpha."<br> So what is considered here:<br> * throughput in bytes/sec<br> * rate in packets/sec<br> * rate in bytes/sec<br><br>(2) I don't understand the formula for alpha completely. I understand how<br> the corresponding formula in "Practical Congestion Control for Multipath<br> Transport Protocol" is derived. However, there the congestion windows<br> are measured in MTUs (or MSS or packets). So it is more packet
rate<br> based. I could understand the formula in the ID if cwnd_i / mss_i would<br> be used instead of cwnd_i * mss_i. So is it a typo or could someone provide<br> a hint why cwnd_i * mss_i is used.<br><br>Best regards<br>Michael<br><br>On Jan 19, 2011, at 3:25 PM, <<a ymailto="mailto:philip.eardley@bt.com" href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a>> <<a ymailto="mailto:philip.eardley@bt.com" href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a>> wrote:<br><br>> The Multipath TCP WG has developed a congestion control algorithm that enables a TCP connection to use multiple paths. <br><span>> <a target="_blank" href="http://tools.ietf.org/html/draft-ietf-mptcp-congestion">http://tools.ietf.org/html/draft-ietf-mptcp-congestion</a></span><br>> <br>> We’re hoping to WG Last Call this document in February, so it would be great if anyone from ICCRG could
review it<br>> <br>> Thanks,<br>> Phil & Yoshifumi<br>> MPTCP WG Chairs<br>> <br>> Abstract<br>> <br>> Often endpoints are connected by multiple paths, but communications<br>> are usually restricted to a single path per connection. Resource<br>> usage within the network would be more efficient were it possible for<br>> these multiple paths to be used concurrently. Multipath TCP is a<br>> proposal to achieve multipath transport in TCP.<br>> <br>> New congestion control algorithms are needed for multipath transport<br>> protocols such as Multipath TCP, as single path algorithms have a<br>> series of issues in the multipath context. One of the prominent<br>> problems is that running existing algorithms such as TCP New Reno<br>>
independently on each path would give the multipath flow more than<br>> its fair share at a bottleneck link traversed by more than one of its<br>> subflows. Further, it is desirable that a source with multiple paths<br>> available will transfer more traffic using the least congested of the<br>> paths, hence achieving resource pooling. This would increase the<br>> overall utilization of the network and also its robustness to<br>> failure.<br>> <br>> This document presents a congestion control algorithm which couples<br>> the congestion control algorithms running on different subflows by<br>> linking their increase functions, and dynamically controls the<br>> overall aggresiveness of the multipath flow. The result is a<br>> practical algorithm that is fair
to TCP at bottlenecks while moving<br>> traffic away from congested links.<br>> <br>> _______________________________________________<br>> multipathtcp mailing list<br>> <a ymailto="mailto:multipathtcp@ietf.org" href="mailto:multipathtcp@ietf.org">multipathtcp@ietf.org</a><br>> <a href="https://www.ietf.org/mailman/listinfo/multipathtcp" target="_blank">https://www.ietf.org/mailman/listinfo/multipathtcp</a><br><br><br>_______________________________________________<br>Iccrg mailing list<br><a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br><span><a target="_blank" href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a></span><br></div></div>
</div><br>
</body></html>