Subject: [multipathtcp] Hosts not using MPTCP's congestion control

From: <[email-masked]>
Date: Thu, 26 Aug 2010 17:37:05 +0100

I can imagine that some hosts will want to use MPTCP protocol to allow multiple address pairs, but not use the congestion control algorithm. For instance, a host might choose to send packets on one of the paths, with the other kept as a standby. Perhaps also where the host simply duplicates pkts onto both paths.

Should the protocol draft include advice on cases like this? In the heuristics section?
What should it do with the Initial data sequence number? Should there be advice what to set it to, or even a special value (say 0) to indicate that the data sequence numbering stuff is not being used for this connection?

Thanks
phil

---

From: Mark Handley <[email-masked]>
Date: Thu, 26 Aug 2010 18:08:49 +0100

The intent is that the protocol spec and the congestion control spec
are decoupled.  While I've very happy with the current congestion
control behaviour, I'm also quite sure it isn't the last word on the
subject.  So I expect new congestion control specs will eventually
come along and obsolete anything we write now.

Equally, if we got it right, SCTP should be able to use the congestion
control spec (if it is so desired) without re-writing it for SCTP.

 - Mark

On 26 August 2010 17:37, philip.eardley <[email-masked]> wrote:
> I can imagine that some hosts will want to use MPTCP protocol to allow
> multiple address pairs, but not use the congestion control algorithm. For
> instance, a host might choose to send packets on one of the paths, with the
> other kept as a standby. Perhaps also where the host simply duplicates pkts
> onto both paths.
>
> What should it do with the Initial data sequence number? Should there be
> advice what to set it to, or even a special value (say 0) to indicate that
> the data sequence numbering stuff is not being used for this connection?
>
> Thanks
> phil
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>
>