RE: Robert Wilton's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Martin,

Thanks for your comments.  Please see inline ...

> -----Original Message-----
> From: Martin Thomson <[e-mail]>
> Sent: 07 January 2021 05:04
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; WG Chairs <[e-mail]>;
> [e-mail]; Lars Eggert <[e-mail]>
> Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-transport-33:
> (with DISCUSS and COMMENT)
> 
> Responding to the DISCUSS only.
> 
> On Thu, Jan 7, 2021, at 04:43, Robert Wilton via Datatracker wrote:
> > 1) It would be helpful to clarify what the expected behaviour is for an
> > implementation that chooses not to support the spin-bit.  Does it just
> leave
> > the bit set as 0, or is it meant to follow the same behaviour as if
> spin-bit is
> > supported but disabled?
> 
> The working group did not reach consensus on what an implementation should
> do, therefore the document does not say anything specific.  Indeed, I will
> go further and say that we have pretty firm consensus on what is
> documented.
[RW] 

Okay.  I think that the document would be better if this was explicitly expressed.  I dislike deliberate ambiguities in documents because they potentially lead to issues like the IPv6 extension header processing ambiguity.

In the IESG telechat today, it was suggested that one of the reasons for the specified behaviours when spin is supported, but disabled, was to ensure that the spin-bit is suitably greased.  However, if implementations don't support the spin-bit then they may just set this to 0, and this bit wouldn't be greased.  It was suggested in the IESG discussion that this might want to be considered further.

Completely as an aside, I tried to look back at the consensus decisions on this issue in github and on the mailing list. Although it is possible to see where it had been marked that consensus had been declared, I found it very hard to see what the input/discussion was for those consensus decisions.  Note, I'm no way doubting the integrity/result of those consensus decisions, I trust the authors/chairs/ads, just pointing out that it seems to be hard to verify/confirm.  Possibly having separate labels for "rough consensus" vs "full consensus" might also be helpful.


> 
> We did get good information, based on implementation and experimental
> experience, that filtering out bad values was easy, even trivial.
[RW] 

Thank you.  That is good to know and partially alleviates one of my concerns, although I still don't see the benefit of injecting random values, and still seems to add additional complexity for questionable benefit.


> 
> > 2) This may not be discuss worthy, but some of the spin bit behaviour is
> > inconsistently defined between the quic transport and quic manageability
> > drafts.
> 
> As you correctly observe, the transport draft is authoritative in this
> regard.  As the manageability draft is not yet finished, I would expect
> any inconsistencies to be addressed there.
[RW] 

Okay.  You can regard this point as being resolved.


> 
> > But my two main discuss questions/comments relate to whether the spin-
> bit, as
> > specified in quic transport, achieves its goal.  I appreciate that there
> are
> > individuals who don't think that it is required at all, conversely some
> network
> > operators believe that they will lose vital information needed to help
> manage
> > their networks, and presumably we are trying to find a pragmatic
> compromise
> > between these two positions.
> 
> I would not say compromise, but rather that this is a mechanism that we
> know is acceptable to (some) endpoint implementations and know to be
> valuable to (some) network operators.  It is also optional (for both),
> relatively low cost to specify, implement, and deploy.
> 
> > 1) I find it hard to understand why a server is allowed to independently
> decide
> > whether or not to support the spin bit on a connection?  Shouldn't the
> client
> > (or administrator of the client system) that opened the connection be
> able to
> > choose whether they want the RTT to be monitorable via the spin bit?
> What is
> > the reasoning for allowing the server (or server administrator) to be
> able to
> > independently be able to decide what is best for the client?
> 
> The consensus of the working group is that active spinning must be made
> independently by either endpoint and that having an endpoint dictate the
> actions of its peer for this feature was not desirable.  Hence the design
> as documented.
> 
> > 2) In the case that the spin-bit is disabled, I don't understand the
> benefit of
> > injecting a random spin bit value in each packet rather than always
> setting it
> > to a per connection random value.  It seems that whether or not the
> randomness
> > is injected, it is expected to be feasible to extract the RTT for those
> > connections that are genuinely spinning the bit (or otherwise the spin
> bit is
> > entirely pointless), but it just seems to make it computationally harder
> to
> > extract the signal from the noise.  Perhaps the goal here is reduce the
> ability
> > for pervasive monitoring to occur, but that feels a bit like security
> through
> > obscurity.
> 
> Randomness is an option, not a requirement.  Some implementations just
> send 0 or 1 always.
> 
> As previously noted, extracting signal from noise was proven to be
> relatively easy.  This was, I believe, what convinced those who wanted to
> read the spin bit to accept the consensus position (though I can't speak
> for those people).
[RW] 

I couldn't figure out what the benefit of injecting the random value is.  In the IESG meeting it was suggested that this is done to prevent ossification and is used as a form of greasing.  I'm not convinced that a per connection value isn't sufficient for greasing purposes but that is just my instinct.  Clearly it is impossible to prove either way.

It was also suggested that another benefit of using a random per packet value is to avoid extra per connection state, but I think that you could probably avoid that extra state even if the value was per connection (e.g., just copy one of the bits from the connection id - assuming that is available).


> 
> > Some enlightenment for these questions would be appreciated.
> 
> I hope that what enlightenment I was able to share suffices.

I don't really support how the spin-bit is specified in the quic transport draft.  My concern is that if many implementations decide not to support it then over time it will make managing networks harder.  However, I cannot see any benefit in reopening a long contentious debate now, which will probably not get anywhere useful and just delay the QUIC documents.  Instead, I will change my ballot to abstain.  However, I do appreciate the effort that you, the WG, and wider community have put into this protocol.

Regards,
Rob