Re: [tcpm] TCP Connection ID

[Olivier Bonaventure <[e-mail]>]

Dear Alexander,

> 
> As you all know L3 LB is a common element of today's cloud infrastructure. Its original design was based on the connection state that maps backend IPs (real IPs) to connection. Recently there were several papers that were suggesting the move to the stateless L3 LB, where the state (connection id) becomes the property of connection and it kept at the client, so the L3 LB can work without keeping state for every connection. As far as I understand, for QUIC it becomes native with destination connection ID in its header.
> 
> I've seen suggestions for getting this functionality in TCP by overloading the Timestamps option or even TCP SEQ - can't say that such design looks good for me. I wonder was there an attempt to add connection id in the TCP options, and if it was - why it wasn't successful?

Overloading TCP sequence numbers or TCP timestamps to support this feature could lead to problems that are difficult to troubleshoot as there are middleboxes that modify these fields.

The latest version of Multipath TCP (RFC8684) includes a feature to support load-balancers. The connection is established via the load balancer that forwards the SYN to a server and this server advertises its own address to the client. This enables the client to stick the new subflows of the Multipath TCP connection to this server and thus completely bypass the load balancer. This is described in https://inl.info.ucl.ac.be/publications/making-multipath-tcp-friendlier-load-balancers-and-anycast.html <https://inl.info.ucl.ac.be/publications/making-multipath-tcp-friendlier-load-balancers-and-anycast.html>

Olivier
-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>