On 3/29/23 5:41 PM, Wenjia Zhang wrote:
On 24.03.23 08:26, Kai wrote:
On 3/23/23 1:09 AM, Wenjia Zhang wrote:
On 21.03.23 08:19, Kai Shen wrote:
SMC-R performs not so well on fallback situations right now,
especially on short link server fallback occasions. We are planning
to make SMC-R widely used and handling this fallback performance
issue is really crucial to us. Here we introduce a shadow socket
method to try to relief this problem.
Could you please elaborate the problem?
Here is the background. We are using SMC-R to accelerate server-client
applications by using SMC-R on server side, but not all clients use
SMC-R. So in these occasions we hope that the clients using SMC-R get
acceleration while the clients that fallback to TCP will get the
performance no worse than TCP.
I'm wondering how the usecase works? How are the server-client
applications get accelerated by using SMC-R? If your case rely on the
fallback, why don't use TCP/IP directly?
Our goal is to replace TCP with SMC-R on Cloud as much as possible.
Many applications will use SMC-R by default but not all(like they are
not using then latest OS). So a SMC-R using server must be ready to
serve SMC-R clients and TCP clients in the mean time. As a result
fallback will happend.
In these cases we hope clients using SMC-R get accelerated and clients
using TCP get no performance loss. The server using SMC-R can't tell if
the next client use SMC-R or TCP util their TCP SYN comes and this lead
to fallback when a client use TCP. But the current SMC-R server fallback
path which handles incoming TCP connection requests will compromise the
performance of TCP clients. So we want to optimize SMC-R server fallback
path.
Thanks.
