Subject: [tcpm] TCP sendbuffer advertising

From: Costin Raiciu <[email-masked]>
Date: Tue, 14 Jul 2015 08:04:06 +0300

Dear all,

We have been working on a simple extension to TCP that encode the amount of backlogged bytes in each TCP segment. This information can be used by the network or the receiver for various optimizations.

I will be present our work during the TCPM working group in Prague. This email is a heads-up for those interested in hearing more about the work before it is presented.

We have written a draft on the encoding, but unfortunately we have missed the Prague cutoff. You can download the draft from my webpage at http://nets.cs.pub.ro/~costin/files/draft-agache-tcpm-sndbufadv.txt
We will submit it properly as soon as the I-D submission tool reopens on saturday.

We also have a workshop paper in HotClout 2015 on the various use-cases of send buffer advertising, and our prototype implementation, that you can find at: http://nets.cs.pub.ro/~costin/files/sndbuf.pdf

We are looking forward to your comments.

Best.
Costin
----------------------------------------------
Costin Raiciu
Associate Professor
Homepage: http://nets.cs.pub.ro/~costin/
CS Department
University Politehnica of Bucharest

---

From: Costin Raiciu <[email-masked]>
Date: Thu, 16 Jul 2015 08:25:57 +0300

Yuchung, 

Thanks for your comments. Below are answers to your questions.

> 1) what happens when the backlog / sendbuf > 65536B?

Probably simply advertise the maximum you can encode, or use some sort of scaling. 

However, we have 4 bytes available for the encoding in packs (or in options, if you can spare the space), so you should be able to advertise a 4GB backlog, which is plenty.

> 2) announcing the backlog may help larger incast when the response >
> cwnd (i.e., taking multiple round trips to deliver). but many incast
> patterns I know of fit entirely in the first cwnd. For example 1000
> senders write 2 packets each to a single receiver. ECN/dctcp has the
> same limitation on such type of incast.

Sendbuffer advertising does not help here, agreed - all the advertised values will be zero.

> 3) some application prefer late-binding and delays writing data into
> the socket with features like TCP_NOTSENT_LOWAT
> (https://lwn.net/Articles/560082/). Thus the sendbuf remains low while
> app backlog may be very large. The react function that uses the
> sendbuf info should not assume sendbuf == app backlog.

The backlog will still be non-zero most often even in this case, otherwise the applications are underutilizing their network. This should still indicate to the network that the app is backlogged. The amount of backlogged data is not as important as the fact that there is a persistent backlog.

> 4) for HTTP/2 often the conversation is bi-directional: the server may
> be responding to a HTTP/2 request while actively acking other new
> client requests.
> The receiver window of the packets will alternate between sendbuf or
> receiver window. hence the sendbuf info may be missing intermittently.

Agreed. We just need to apply our patch and measure this. Will come back with answers when we have them.

> but I think this is an interesting feature worth exploring!

Glad you like it. We beilieve it’s quite useful too; that’s why we’re bringing it to TCPM.

Best.
Costin

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