Subject: [tcpm] Next steps for sednbuffer advertising

From: Costin Raiciu <[email-masked]>
Date: Tue, 28 Jul 2015 17:31:29 +0300

Dear all,

In Prague I presented a proposal for TCP to include sendbuffer information in every segment (the amount of backlogged bytes) to help networks and receivers with various optimizations. 

As sendbuffer advertising is a sender-only modification, we have argued it needs no negotiation in the three way handshake. Once it is turned on, the relevant information will be added to outgoing data segments, and the receiver or the network can use that information if they know about sendbuffer advertising. Otherwise, they should not be impacted at all.

We have proposed two ways of encoding sendbuffer information: 
- in a TCP option on data segments, opportunistically when there is space in the options field - this option is for Internet deployment.	
- by scavenging the ACK field and/or the receive window field, and by defining a new “Sendbuffer advertisting flag” - this option is targeted for datacenter deployment.

My slot was the next to last in TCPM and there was not enough time for discussions. That is I would like to ask TCPM-ers:

1) do you find sendbuffer advertising useful - should something like this be standardised?

2) do you agree/like/dislike the encoding(s) we have proposed, or do you have beter alternatives?

Thanks.
Costin

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 28 Jul 2015 17:02:38 +0100

> 1) do you find sendbuffer advertising useful - should something like this be standardised?

Yes, and maybe.

My use-case is different: diagnosis of performance issues.  I'd also
like to have observability of the congestion window and the ssthresh.
This would not be needed at all times, but could be enabled as needed.

> 2) do you agree/like/dislike the encoding(s) we have proposed, or do you have beter alternatives?

I do not like the repurposing of the ACK value, and feel that
using an option would be preferable.

Possibly having the option in the SYN defining the content
(a descriptive string, and a number of bytes; repeated for
each possible datum) would maintain future flexibility.
The option in data segments would carry just a packed sequence
of values.
-- 
Jeremy