Re: Spin bit discussion - where we're at

["Brian Trammell (IETF)" <[e-mail]>]

> On 22 Nov 2017, at 14:55, Eggert, Lars <[e-mail]> wrote:
> 
> Hi,
> 
> On 2017-11-22, at 14:31, Salvatore Loreto <[e-mail]> wrote:
>> Indeed in the original mail Mark is on one side proposing to discuss it in London (instead that into the next interim)
>> but at same time is leaving open the possibility to postpone the final decision until right before shipping the protocol to the IESG
> 
> I think the decision to not discuss it at the interim is based on the observation that the registered attendees at the interim are probably not representative of the overall WG constituency - we want to give all sides an ability to participate equally in the discussion.
> 
>> While I agree with Mark assessment that we can tip this into the short header relatively late in the game,
>> I am concerned for this huge potential delay for a proposal that I would argue is already clear to all people actively involved in the QUIC design.
>> 
>> Can you please which are the next steps you are going to follow here?
> 
> I think what Mark tried to express is that the discussion on the Spin Bit can be mostly decoupled from the (large amount of) work remaining on the base spec. That is, we don't have to conclude the Spin Bit discussion significantly prior to the conclusion of the overall work (although we can), since it should be easy to merge at the later stages before handing things to the IESG.

Quoting this for truth, and agreement. One of the nice properties of this particular proposal is that it can be implemented (almost) completely independently of the rest of the transport protocol, and as such can be developed independently as well.

However, this is probably not the case for the other proposals I'm aware of: a simple loss/ECN re-feedback mechanism as in conex impacts ack handling, for instance, and some of the debug bits signaling whether a flow is flow control or congestion control limited (see 279 / 418) also require slightly deeper integration with the transport mechanics. We already pretty much knew that discussion on these was a topic for v2, though, so the additional process doesn't actually change anything there.

Cheers,

Brian