Subject: [multipathtcp] Some comments on RFC 6824

From: Rao Shoaib <[email-masked]>
Date: Tue, 23 Jun 2015 22:35:48 -0700

Hi All,

I am implementing MPTCP in Solaris and have a few comments below based 
on my implementation experience so far.

1) Currently the RFC says that checksum in DSS option 'SHOULD' be 
present.  Requiring checksum is a performance killer because it has to 
be calculated in the software and needs to be calculated over the ENTIRE 
mapping. This also means that the receiver has to wait to receive the 
complete mapping worth of data before it can be processed. More 
importantly these days most  NIC's support HW checksum offload and that 
feature is commonly used, this requirement makes this important HW 
feature useless.

I am hoping that the requirement of requiring checksum in the DSS option 
be relaxed and may even not be required in a data center.

2) The RFC does not say what the initial subflow sequence number should 
be. Can this be made clear. Why not use the TCP sequence number of the 
subflow.

3) When calculating the HMAC, token, key's sequence number etc it is not 
at all clear which values have to be in network byte order and which 
not. Can this be explicitly specified in the RFC.

4) Can we not allow dropping a segment after it has been acked at the 
subflow level. It is very unlikely that a network element would drop a 
TCP segment after it has been processed and acked. Making this change 
would make buffer management much easier. If an element can drop a 
packet than it should not ack,  but other implementation should not be 
burdened by this requirement.

Thanks,

Shoaib

---

From: Mark Handley <[email-masked]>
Date: Wed, 24 Jun 2015 09:29:37 +0100

> be relaxed and may even not be required in a data center.

The DSS checksum is to catch MPTCP-unaware middleboxes that modify
content, and permit graceful fallback to regular TCP, so the content
stream does not end up corrupted.  If you know for sure there is no such
middlebox on the path (as in some datacenters) then disabling the
checksum should be fine.  That's why it's a SHOULD, not a MUST.

When MPTCP is eventually commonplace, NICs will no doubt do DSS checksum
offload too, and integrate it into TSO.

> burdened by this requirement.

The problem is that in the presence of middleboxes, you can't be sure
that a subflow ack means the data got there.  This usually isn't a huge
issue with TCP because you share fate with the middlebox.  For MPTCP
though, you don't share fate with the middlebox.  Consider the following
scenario:

You've a mobile host, downloading over 3G and WiFi.  There's a middlebox
on the 3G path that's proactively acking data - we do see such things in
the wild.  At some point the client moves into a place where 3G
reception is blocked but WiFi is provided - this scenario is common in
the London Underground system for example.  At the point the 3G drops,
some data had been acked by the middlebox, but not received by the
mobile host.   If the server had freed the data from its socket buffer,
the connection is now deadlocked.  The current MPTCP spec says the
sender can't free this data - it hasn't received a data ack yet - so
there's no problem; the data will be resent over WiFi and everything is
fine.

Hope that helps with the rationale. 

Cheers,
Mark

---

From: Rao Shoaib <[email-masked]>
Date: Wed, 24 Jun 2015 10:32:20 -0700

Hi Mark,

Please see inline

> offload too, and integrate it into TSO.
Can we make this clear in the RFC as convincing customers to turn off 
checksum is not easy even when they complain about performance.
> Hope that helps with the rationale.
The example helps out a lot and now I understand the issue. This 
requirement requires holding onto the TCP buffer after it has been acked 
and that requires some not so clean changes to existing TCP code.  Let 
me think a little more on how to implement this efficiently.

Thanks a lot for your prompt reply.

Shoaib.

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

---

From: Rao Shoaib <[email-masked]>
Date: Wed, 24 Jun 2015 22:47:59 -0700

> checksum is not easy even when they complain about performance.
I went back and looked at RFC 6824. I find that the text on page 16 is 
quite clear. So there is no need to take any action.

Shoaib
> requirement requires holding onto the TCP buffer after it has been 
> acked and that requires some not so clean changes to existing TCP 
> code.  Let me think a little more on how to implement this efficiently.
>