Re: Spin bit discussion - where we're at

[Roland Zink <[e-mail]>]

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
>