RE: Spin bit discussion - where we're at

[Ingemar Johansson S <[e-mail]>]

Hi

I really don't see that QUIC is able to solve this (congestion) issue. 
I pointed out ConEx (see eg. RFC6789) as one solution. And as Christian pointed out, operators already use rate shaping or policing or limit the amount of data.

Finally, even though there can be reasons to hack a congestion control algorithm that will help your QUIC connection to outcompete other flows, it also comes with the risk that said connection bloats its own last mile access link. So in the end you create most of the problems for yourself. For instance your LTE connection will only reward you with either high RTT or high loss or both if your congestion control is not enough responsive to congestion signals. 

/Ingemar

> -----Original Message-----
> From: Roland Zink [mailto:[e-mail]]
> Sent: den 27 november 2017 20:46
> To: Christian Huitema <[e-mail]>
> Cc: Ingemar Johansson S <[e-mail]>; Gorry (erg)
> <[e-mail]>; [e-mail]
> Subject: Re: Spin bit discussion - where we're at
> 
> I agree it is not only QUIC. I also don't think it is necessary to panic now. We
> have issue #740
> (https://github.com/quicwg/base-drafts/issues/740) about adding a security
> issues section were existing means could be added. When QUIC can help to
> address such issues it can become more reliable so I wouldn't say this is out
> of scope just because other protocols have similar issues. If it really turns out
> that the current mitigations are not sufficient then work on better queue
> management algorithm will probably come too late.
> 
> 
> Roland
> 
> 
> 
> Am 27.11.2017 um 19:02 schrieb Christian Huitema:
> > On 11/27/2017 9:36 AM, Roland Zink wrote:
> >
> >> If QUIC makes the problem crystal clear then now seems to be a good
> >> time to solve or mitigate it before risking it becomes a real world
> >> problem.
> > First, let's start by agreeing that this is not a problem specific QUIC.
> > You could say the same about Bit Torrent, any protocol that sends
> > video over UDP, or any application that opens multiple TCP connection.
> > So, yes, there may well be a problem, but since it is not specific to
> > QUIC the mitigation does not have to be specific to QUIC either.
> >
> > But let's not panic. Practical mitigation has started long ago, with
> > ISPs effectively controlling how much data can be sent through a
> > customer's up-link. Maybe these current mitigations are not
> > sufficient, but if that is the case I would expect more work on better
> > queue management algorithm.
> >
> > -- Christian Huitema
> >