Vernon Schryver wrote:
>
> > From: Joe Touch <touch@ISI.EDU>
>
> > ...
> > > > I suspect they ignore the issue because of how they demux to multiple
> > > > boxes;
> > > > if the demux is by a hash of source IP address, then there's no need for
> > > > coordination thereafter.
> > >
> > > That's ok for the redirected ISP customers and the box itself, but
> > > what about the distant server that is getting less than half of the
> > > (addr, port, addr, port) 4-tuple? I thought the point was that
> > > the distant SMTP or HTTP server would be getting second or later
> > > IP fragments with colliding IP ID's, identical source (proxy's)
> > > and destination (server's) IP addresses, and so with no clue which
> > > IP fragments belong to which stream.
> >
> > I was describing a (easy) case where the demux is by source IP only; in
> > that case, IP IDs can be reused by the different servers, because there
> > is no potential collision of the tuples.
> >
> > There are certainly cases where the demux is not by source IP, in which
> > case the different servers (or clients) sharing an IP address need to
> > coordinate IP IDs.
>
> Either I don't understand or we're not communicating.
> I don't see how a redirection proxy can ever be designed to demux packets
> from the Internet by IP source address. Those source addresses are in
> the great beyond and will be different or the same for local customers
> depending on chance and the popularity of the distant server.
I'm speaking of a redirection proxy sitting at the entry of a web farm.
In that case, the redirection proxy never really terminates a
connection; it forwards the SYN to one of the web farm boxes, and
changes the IP address in the process:
> I'm talking about
>
> client A, IP address 10.1
> client B, IP address 10.2
> redirection proxy P, IP address 192.0.2.1
> distant HTTP server S, IP address 172.16.0.1
>
> Clients A and B try to open HTTP/TCP/IP connections with S. They
> both have private Ethernets and so like MTU=1500 ad MSS=1460, and
> they have typically misconfigured PPP/modem links with MTU=512.
>
> Both clients send SYN's to get rolling. Since they're using common
> operating systems that don't try hard, they both use the same IP ID's
> their corresponding HTTP/TCP/IP packets.
> The first thing they do after the 3-way handshake is try to GET similar
> 600 byte URLs. Or perhaps they do 1000 byte PUT's. Thus, they both send
> IP fragments with the same IP ID's, the same IP destination address,
> and differing only in IP source address (10.1. vs.10.2) and fragmentary
> HTTP payload.
>
> The proxy P takes all of their IP packets and rewrites their sources
> addresses of 10.1 and 10.2 to its own 192.0.2.1. The proxy then sends
> the modified IP packets to server S.
Ahh - that would be 'bad.' (i.e., that's not the case I was thinking of
which wouldn't be a problem).
I was thinking of rewriting destination addresses, not sources. E.g:
client A @ 10.1
client B @ 10.2
redirection P @ 192.0.2.1
HTTP server S @ 172.16.0.1
local HTTP 'server' (cache) C at 192.0.2.2
local HTTP 'server' (cache) D at 192.0.2.3
A sends to S
P 'nat's' the dest S to the dest C
C responds to A
(alternately, P responds to A, and relays
by opening a new connection to C)
B sends to S
P 'nat's' the dest S to the dest D
D responds to B...
E.g., - P demuxes to each local cache based on the source address
in this case, C and D need not coordinate IP IDs; they're
necessarily distinct.
Joe
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST