Subject: Re: [multipathtcp] Comments on draft-ietf-mptcp-congestion

From: Rolf Winter <[email-masked]>
Date: Mon, 2 Aug 2010 07:35:57 +0000

Hi,

> - The draft could probably motivate why congestion window coupling is
> actually needed as long as the number of subflows is smaller than the
> limit ("REC-3") given in draft-ietf-ledbat-practices-recommendations.

No. The draft should not do that. The value in that recommendation is arbitrary.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 2 Aug 2010 12:47:29 +0200

> > limit ("REC-3") given in 
> draft-ietf-ledbat-practices-recommendations.
> 

IMHO it is a valid question how that draft as a whole and its
recommendations relate to multipath transport. Both drafts somehow
discuss fairness issues of multiple connections. 

Note that I am not suggesting that the specific value mentioned in
draft-ietf-ledbat-practices-recommendations should have any impact on
the coupled congestion control algorithm.

Michael

---

From: Rolf Winter <[email-masked]>
Date: Mon, 2 Aug 2010 11:23:51 +0000

If anything, it should be the other way around. The LEDBAT draft should motivate why somebody might NOT use coupled congestion control. (There are of course reasons for this). 

> -----Original Message-----
> From: SCHARF, Michael [mailto:[email-masked]]
> Sent: Montag, 2. August 2010 12:47
> To: Rolf Winter; multipathtcp
> Subject: RE: Comments on draft-ietf-mptcp-congestion
>

---

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 2 Aug 2010 14:54:50 +0200

> If anything, it should be the other way around. The LEDBAT draft should motivate why somebody might NOT use coupled congestion control. (There are of course reasons for this). 

True, a reference in the reverse direction could make sense, too.

(Even though, unlike that draft, congestion control coupling is IMHO at a rather early stage of research so far, given that there are no highspeed algorithms etc.).

Michael