Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
From: "Bert Huijben" <bert@qqmail.nl>
To: <dev@httpd.apache.org>
References: <02f401d12912$fcba4130$f62ec390$@qqmail.nl>
 <030501d12916$cf7e1120$6e7a3360$@qqmail.nl> <56599792.3060402@greenbytes.de>
 <03a401d129dd$fafdbfe0$f0f93fa0$@qqmail.nl>
 <03aa01d129e1$2d49d990$87dd8cb0$@qqmail.nl>
In-Reply-To: <03aa01d129e1$2d49d990$87dd8cb0$@qqmail.nl>
Subject: RE: No H2 Window updates!
Date: Sat, 28 Nov 2015 22:29:03 +0100
Message-ID: <040101d12a23$ced65530$6c82ff90$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQJt5VCTIFs6KteEjCgZz0PozG8d2QIIvd2DAZcYZYkCyYw91gGJZW1znTjeQnA=
Content-Language: nl

> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: zaterdag 28 november 2015 14:32
> To: stefan.eissing@greenbytes.de; dev@httpd.apache.org
> Subject: RE: No H2 Window updates!


> In case of Subversion's real usage, I want to commit potentially hundreds
of
> MByte, so a connection level window of more than a few bytes would be
> very
> welcome.... With HTTP/1 we send out the data as fast as we can and the TCP
> windowing handles this from the httpd side... Now the http/2 level
> windowing
> should handle this.
> 
> 
> Mod_dav and mod_dav_svn are usually fast readers; just limited by trivial
> disk io or xml processing in the common operations, so I don't expect real
> problems there.

For my commits against the svn-master.apache.org repository my latency/ping
time is +- 142 ms.

With the current simple algorithm and a maximum window of 64
Kbyte/connection, I can send a theoretical maximum of 64 Kbyte/142 ms per
connection to that server... which would be about 450 Kbyte/s.
(=1/0.142*65536/1024)

That is < 1/30th of the bandwidth I have at my disposal (+- 150 Mbit).

But currently I don't even get anywhere near that as my window continues to
shrink because some data is missed in accounting even after my simple patch.


For httpd we have to think carefully which algorithm we want to implement
here. Preferably the algorithm should be better than TCP could, as we know
the specifics of the http algorithm better than plain TCP could for
HTTP/1,1. TCP does send a lot of window updates though... Almost every
packet does.


Solving the really hard problems, like this one, is the reason I didn't
think the nghttp2 library would really be the solution for serf. 
It is nice for such a library to provide a head start on the protocol level,
but there is no way a standard library can really solve this scheduling
problem in a generic way. (If it could do it, we had used that solution for
TCP... and never had to resort to designing a HTTP/2 in the first place).

See https://en.wikipedia.org/wiki/TCP_window_scale_option for some
introduction on how TCP was extended to work above the limit that currently
applies to H2.


Dynamic window sizing/scaling will have to be implemented at some point, at
both the stream and the connection level... This will involve timing,
measuring, etc. etc. Things nghttp2 can't do for us right now.
And if I'm right this might take continuous optimizing for years to come.


When I connect to sites like google I immediately receive a large connection
level window, to allow me to post huge blobs without a delay. (Haven't
tested their stream level windows behavior yet)
In serf I do something similar... and then apply a bit of throttling at the
stream level.


I would guess some clients have already implemented some of this, so we
might be able to learn from their implementations... Clients will see much
more incoming data than servers of course :).


	Bert