Re: Spin bit discussion - where we're at

[Roland Zink <[e-mail]>]

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.

Roland


Am 27.11.2017 um 17:38 schrieb Christian Huitema:
> The network cannot control the congestion algorithm in the end points. 
> QUIC does not create the problem, just makes it crystal clear. But the 
> network can manage queues. So does the kernel.
>
> -- Christian Huitema
>
> On Nov 27, 2017, at 6:47 AM, Roland Zink <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> I guess the guys which really want to do it will somehow get the 
>> necessary rights (like to load a kernel module) and do it although 
>> this may be difficult if you want to do it on million of devices. I'm 
>> more thinking of a slow process, say app 1 increase the initial 
>> window then app 2 thinks it needs to do the same and back out less 
>> than the default. Then app 1 is doing something and at some point 
>> nobody follows what is (will be) in the RFC. They not necessarily 
>> want to break something but at the end it can result into the same. 
>> It is no longer a single policy which applies to all apps instead 
>> each app comes with its own and the apps often can control both sides.
>>
>>
>> Roland
>>
>>
>>
>> Am 27.11.2017 um 15:14 schrieb Ingemar Johansson S:
>>>
>>> Hi
>>>
>>> I would say that it is perfectly possible to trick e.g. the Linux 
>>> TCP stack to something like what is described below. Just clone 
>>> tcp_cong.c ,
>>>
>>> Change the following lines
>>>
>>> u32 *tcp_reno_ssthresh* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_reno_ssthresh>(struct*sock* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/sock> *sk)
>>>
>>> {
>>>
>>> conststruct*tcp_sock* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_sock> *tp 
>>> =*tcp_sk* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_sk>(sk);
>>>
>>> return*max* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/max>(tp->snd_cwnd 
>>> >>1U,2U);
>>>
>>> }
>>>
>>> To something like
>>>
>>> u32*tcp_**bloat**_ssthresh* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_reno_ssthresh>(struct*sock* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/sock> *sk)
>>> {
>>> conststruct*tcp_sock* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_sock> 
>>> *tp=*tcp_sk* 
>>> <https://elixir.free-electrons.com/linux/v3.12/ident/tcp_sk>(sk);
>>> returntp->snd_cwnd;
>>> }
>>>
>>> Build it and make it a loadable kernel module, you need to rename a 
>>> few other functions as well, and you can call it tcp_bloat.c 😊
>>>
>>> So.. my opinion is that you can perfectly well collapse the internet 
>>> also with TCP. ConEx was introduced as a medicine for this but it 
>>> never gained traction.
>>>
>>> /Ingemar
>>>
>>> *From:* Gorry (erg) [mailto:[e-mail]]
>>> *Sent:* den 27 november 2017 14:15
>>> *To:* Roland Zink <[e-mail]>
>>> *Cc:* [e-mail]
>>> *Subject:* Re: Spin bit discussion - where we're at
>>>
>>> See below:
>>>
>>>
>>> On 27 Nov 2017, at 12:32, Roland Zink <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     Am 27.11.2017 um 08:03 schrieb Jana Iyengar:
>>>
>>>         In addition to how the spin bit can be designed and used,
>>>         I'd like those taking on this effort to consider this
>>>         question: Whatever network management problem you're
>>>         considering solving with a bit, what does it take to solve
>>>         this problem without the bit exposed? I'm asking you to
>>>         consider "zero-bit" solutions, or at least for a
>>>         cost/benefit analysis of developing solutions with and
>>>         without the spin bit for specific network management
>>>         functions. Specifically,
>>>
>>>         (i) What's impossible or very difficult to do, from a
>>>         network management perspective, of not having the spin bit?
>>>         Note that I'm not asking for what is and is not measurable
>>>         -- not everything measurable is useful. I'm specifically
>>>         asking in terms of network management functions, in
>>>         practice, as used by operators. Some of this has been
>>>         addressed in the discussions/drafts I've seen, but I think
>>>         it's most useful when framed in terms of network management
>>>         functions.
>>>
>>>     I want to express the question about manageability from a
>>>     different angle. QUIC moves the congestion control from being a
>>>     common functionality in the kernel to application functionality.
>>>     It also hides the protocol handling of congestion from the
>>>     network. This gives incentives for application developers to
>>>     change congestion control to give their application an advantage
>>>     over others. No special rights are necessary. Now the question
>>>     is does QUIC provide enough manageability to avoid an Internet
>>>     (or some part of it) breakdown when it is misused? Can it be
>>>     shown that this can't happen?
>>>
>>> I think this may touch on some of the topics in:
>>>
>>> https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-04
>>>
>>> Although this is focussed on issues wider than Quic, I think the 
>>> points you raise are relevant. This was presented last IETF-100 in 
>>> TSVWG and INTAREA. We would appreciate insight, and comments on 
>>> this.  (I am just about to push new version to correct typos!)
>>>
>>>
>>>
>>>         (ii) What are the alternatives for building the same
>>>         functions without the spin bit? Let's consider for a moment
>>>         that the spin bit isn't actually available in practice. What
>>>         will operators do to continue managing their networks? This
>>>         might be expensive, but that's precisely what I'm looking
>>>         for -- the cost to operators of not having the spin bit. For
>>>         instance, active probes are a fine way to measure network
>>>         RTT within operator networks, and that is an alternative.
>>>         There are surely others too. Their costs and limitations are
>>>         important to know about in order to reason about their
>>>         viability, so I'd like to see alternatives considered.
>>>
>>>     Solutions that only work within an operators network are not
>>>     enough when more than one operator is involved.
>>>
>>> Yes, also true.
>>>
>>> Gorry
>>>
>>>         I don't mean to start the discussion on this thread, but I'd
>>>         like to urge those going off to do the writing to consider
>>>         these questions.
>>>
>>>         - jana
>>>
>>>         On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL)
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>             Hi Brian, Stephen, Lars, Mark and all,
>>>
>>>             one join, one suggestion, and one question below.
>>>             see [ACM]
>>>             > -----Original Message-----
>>>             > From: QUIC [mailto:[e-mail]
>>>             <mailto:[e-mail]>] On Behalf Of Brian Trammell
>>>             > (IETF)
>>>             > Sent: Wednesday, November 22, 2017 5:59 AM
>>>             > To: Eggert, Lars
>>>             > Cc: Mark Nottingham; QUIC WG; Stephen Farrell
>>>             > Subject: Re: Spin bit discussion - where we're at
>>>             >
>>>             > hi Lars,
>>>             >
>>>             > > On 22 Nov 2017, at 11:35, Eggert, Lars
>>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>>             > >
>>>             > > Hi,
>>>             > >
>>>             > > On 2017-11-22, at 11:01, Stephen Farrell
>>>             <[e-mail]
>>>             <mailto:[e-mail]>>
>>>             > wrote:
>>>             > >> What I thought was being requested and what I do
>>>             think is reasonable
>>>             > >> is to document a privacy analysis for any quic
>>>             protocol bits that are
>>>             > >> visible to the path. Whether or not some or all of
>>>             that text ends up
>>>             > >> in some RFC is another day's work.
>>>             > > Lars wrote:
>>>             > > for the Spin Bit specifically, the intent was to
>>>             permanently capture
>>>             > the analysis the DT has done, so that when others
>>>             review the proposed
>>>             > Spin Bit specification, they can take that as a given
>>>             and direct any
>>>             > further analysis to other aspects. It made sense to
>>>             the chairs that that
>>>             > specific analysis should become part of the Spin Bit
>>>             specification. I
>>>             > think we'd be open to a discussion on whether a
>>>             broader document
>>>             > analyzing the QUIC wire image would be a better home
>>>             for this. The main
>>>             > point is for the work that the DT has done to be
>>>             documented.
>>>
>>>             > Brian wrote:
>>>             > Okay. That's somewhat more reasonable than what I read
>>>             the ask to be
>>>             > ("we're going to gate this on the people who care
>>>             about this doing some
>>>             > non-trivial amount of work"). Those of us who
>>>             volunteer (help, please,
>>>             > anyone? :) ) can certainly pull together what we have
>>>             in a single I-D
>>>             > and ask the WG what more it thinks it needs. To me all
>>>             this seems pretty
>>>             > clear, but I've been working on this topic for a while.
>>>             [ACM]
>>>             Having reached the end of the "Thanksgiving thread",
>>>             I'm scrolling back a few pages to join the task of
>>>             permanently capturing the work of the DT in an I-D (at
>>>             least):
>>>             There should be lasting value in some of our findings
>>>             and IMO they are worthy of a persistent reference.
>>>
>>>             > Lars wrote:
>>>             > > For proposals other than the Spin Bit (I think I
>>>             have seen individual
>>>             > contributors at least mention "loss" and "congestion"
>>>             bits, but without
>>>             > much detail), we wanted to clarify that we'd like to
>>>             see an analysis and
>>>             > discussion of their privacy aspects to roughly the
>>>             same degree as the DT
>>>             > has performed for the Spin Bit proposal.
>>>             >
>>>             [ACM]
>>>             I suggest that this might be a different I-D, at least
>>>             to start.
>>>             Question: Is there a privacy analysis of present ECN
>>>             available?
>>>             (a search yielded many results with Missing: privacy)
>>>
>>>             regards,
>>>             Al
>>>
>>