W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013


From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 15 Apr 2013 16:04:48 +1000
Cc: Lars Eggert <lars@netapp.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Martin Stiemerling <martin.stiemerling@neclab.eu>
Message-Id: <BA43F8F6-8B7F-4B34-B620-2806A02A5AA1@mnot.net>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

On 13/04/2013, at 7:52 AM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> wrote:

> Iíve opened issue #65 to track what we should do about SETTINGS_CURRENT_CWND:
> https://github.com/http2/http2-spec/issues/65


>  As for my opinion about what to do: I think we should delete this TCP congestion window setting from HTTP/2.0.
> This is as out of scope as Iíve ever seen at the IETF. Modifying TCP (by modifying its contract to upper layers such as HTTP, and by modifying its state machine) is not something that can be done outside of the Transport Area. Iím cc-ing Lars Eggert and Martin Stiemerling (former and current Transport ADs), in case they have additional comments or clarifications.

I'd love to hear what Transport folks have to say on-list.

I've also been talking with the Martin about having more Transport cross-fertilisation; we're hoping to spend some time on discussing relevant issues in Berlin.

> Besides, as pointed out by Lars Eggert (cc-ed, along with Martin Stiemerling) in an offline exchange, there is a perfectly reasonable alternative progressing in the Transport Areaís TCPM working group, namely, the proposal to bump up the TCPís initial congestion window to 10. This has undergone the rigorous review required of such a fundamental change, and is currently in the RFC editorís queue (so itís basically done):
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
> That exchange also confirmed my opinion that there is very little chance the IESG would allow SETTINGS_CURRENT_CWND to remain in the HTTP/2.0 spec. In the interest of optimizing community time (HTTPbis, HTTP/2.0 implementors, IESG, etc) I think eliminating this now so it does not appear in the first implementable draft makes sense.

My understanding from discussion in Tokyo was that this is in the spec so that some interested parties can perform some experiments with it and figure out whether it offers any value. In as much as that will serve as input to the discussions with the transport area, it could be useful to leave it in for a bit longer.

So - are people still intending to do that? In particular, in the scope of the first few implementation drafts?

Regarding the overhead for implementers - this feature is completely optional, so it doesn't represent any waste of community time in those terms. 

That said, if we consider removing this, we may want to revisit our decision to only mark settings persistence 'at risk' for the implementation draft.


Mark Nottingham   http://www.mnot.net/
Received on Monday, 15 April 2013 06:05:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC