Re: Constantly varying download rate with a complex xen networking setup, why?

[Bill Fink <billfink@mindspring.com>]

On Tue, 21 Jul 2009, Ilpo Järvinen wrote:

> On Wed, 17 Jun 2009, Raphael Hertzog wrote:
> 
> > Le mercredi 17 juin 2009, Ilpo Järvinen a écrit :
> >> On Wed, 17 Jun 2009, Raphael Hertzog wrote:
> >>
> >>> Le lundi 15 juin 2009, Ilpo Järvinen a écrit :
> >>>> Maybe the proxy interferes there somehow... I don't know enough about the
> >>>> details to say but I suppose the proxy at least breaks your tcp connection
> >>>> to two parts.
> >>>
> >>> Indeed. Is there some processing done in a simple linux bridge where the
> >>> reapperance of the same TCP packet that has been created and sent on another
> >>> local interface could create problem?
> >>
> >> I thought out had a http proxy in between? I suppose it is certainly doing
> >> more than bridging. Anyway, I'll be week away, so no quick responses are
> >> to be expected from my part after this mail.
> >
> > Well, I have the problem when I don't use the proxy... if I use it, the
> > download is split over two TCP connections and things are fine.
> >
> > Hence my question was if something could be confused by the fact that the
> > same packet is seen twice on the same machine once (in output) via 
> > eth2/xenbrD and once (in forward) via xenbrE (the routing between both 
> > bridges is done by the domU independently of the dom0 network config).
> 
> Did you ever get tcpdumps btw? Looking into your setup it would probably 
> be useful take it from all the interfaces where the packets are supposed 
> to pass.

I don't know if the following has any applicability to your specific
situation, but I thought I'd mention it.

It has to do with what I call the non-transitivity of TCP network
performance.  If you have something like the following scenario:

	A <----LAN----> B <----WAN----> C
	     low RTT        high RTT

Just because you have good TCP network performance from A to B, and
good TCP network performance from B to C, it does not necessarily
follow that you will also have good TCP network performance from A to C.

Consider the case where the B<->C path is clean, but there are problems
on the A<->B path (causing TCP retransmissions).  The low RTT on the
A<->B path can mask the problems (basically TCP performs well in spite
of the problems because of the low RTT), but a transfer directly from
A to C performs poorly because the high RTT results in a very slow
ramp up in performance after a loss event.

Again, I have no idea if this applies in any way to your case.

						-Bill