8 ms·

I read the paper briefly on this. I get that you can 'transfer' a socket to another host by sending where you are in the stream and its state. What I don't get

I read the paper briefly on this. I get that you can 'transfer' a socket to another host by sending where you are in the stream and its state. What I don't get is how exactly does the 'peer' change to the new socket? They will be sending packets to the old IP. Second machine has it's own IP. If the purpose of using tcpcp is for 'load balancing' or w/e, then why does it seem to need the connections behind a single machine for routing? I assume this is what redirects inbound traffic from the peer to the new machine. But if it still requires a single machine for routing then it will be just as congested and not load-balanced. What am I missing here?

lcampbell 5y ago
This might make more sense in the situation where multiple hosts share the same IP, as in a CARP[1] setup. There’s probably other useful use-cases but that’s the one that comes to my mind. [1] https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol https://en.wikipedia.org/wiki/Common_Address_Redundancy_Prot...
- vlovich123 5y ago
  Anycast?
0xCMP 5y ago
In their paper the example is servers sitting behind a switch which respond to ARP requests for the same IP (in addition to their own IP) which allows packets for that shared IP to reach both servers (2 in their example). The servers accept every 2nd connection + any established+related connection packets. All other packets are dropped.
kbouck 5y ago
IBM was doing something like this in their software load balancer ~1996. The technique was used in the large sporting events websites of the day (olympics, wimbledon, ...) went something like this: - a routing node (a kernel extension) would receive packets and forward them (verbatim, same src & dest IP) to a backend worker - backend worker was configured for same IP, which meant: a) arp had to be disabled to avoid conflict, or b) the loopback interface had to be aliased to same IP (using loopback avoids arp conflict and worker still happy to accept the packet and respond) - response then goes back directly from worker to original source, which was a good approach for scaling web traffic back then, small http requests going through routing node, large responses going back direct from worker to source. more details: https://patents.google.com/patent/EP0838931A2/en https://patents.google.com/patent/EP0838931A2/en

lcampbell 5y ago

This might make more sense in the situation where multiple hosts share the same IP, as in a CARP[1] setup. There’s probably other useful use-cases but that’s the one that comes to my mind. [1] https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol https://en.wikipedia.org/wiki/Common_Address_Redundancy_Prot...

vlovich123 5y ago
Anycast?

0xCMP 5y ago

In their paper the example is servers sitting behind a switch which respond to ARP requests for the same IP (in addition to their own IP) which allows packets for that shared IP to reach both servers (2 in their example). The servers accept every 2nd connection + any established+related connection packets. All other packets are dropped.

kbouck 5y ago

IBM was doing something like this in their software load balancer ~1996. The technique was used in the large sporting events websites of the day (olympics, wimbledon, ...) went something like this: - a routing node (a kernel extension) would receive packets and forward them (verbatim, same src & dest IP) to a backend worker - backend worker was configured for same IP, which meant: a) arp had to be disabled to avoid conflict, or b) the loopback interface had to be aliased to same IP (using loopback avoids arp conflict and worker still happy to accept the packet and respond) - response then goes back directly from worker to original source, which was a good approach for scaling web traffic back then, small http requests going through routing node, large responses going back direct from worker to source. more details: https://patents.google.com/patent/EP0838931A2/en https://patents.google.com/patent/EP0838931A2/en