Re: HTTP/2 and TCP CWND

[Mark Nottingham <[e-mail]>]

On 13/04/2013, at 7:52 AM, Gabriel Montenegro <[e-mail]> wrote:

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

Thanks.

>  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.

Cheers,

--
Mark Nottingham   http://www.mnot.net/