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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 21 Jul 2009 23:40:26 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	=?ISO-8859-1?Q? "Ilpo_J=E4rvinen" ?= <ilpo.jarvinen@...sinki.fi>
Cc:	Raphael Hertzog <raphael@...za.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: Constantly varying download rate with a complex xen networking
 setup, why?

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html