> 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 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.
Server S is never confused as long as S receives unfragmented TCP
segments, surely including the SYN's. However, what does server S do
when it gets the second IP fragments? The fragments from the HTTP
clients as received at S have the same IP source and destination addresses
and IP ID's. At best they'll have differing IP offsets and lengths,
but at worst even those will be the same.
The only fix is for the proxy P to assign its own IP's, but that has
serious problems given the small size of the IP ID and relatively long
lifetimes (a few seconds) of client streams. 64K packets in a few
seconds is not impressive in a world of Tbit/sec routers. 64K 500 byte
packets in 3 seconds is only 10 MByte/sec, less than a single FDDI
interface. Consider that many popular web sites can't answer in less
than 10 seconds, and you're talking about less than a T3.
Vernon Schryver vjs@rhyolite.com
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:28 MST