Re: Spin bit discussion - where we're at

[Christian Huitema <[e-mail]>]

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]> 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(struct sock *sk)
>> {
>>         const struct tcp_sock *tp = tcp_sk(sk);
>>         return max(tp->snd_cwnd >> 1U, 2U);
>> }
>> To something like
>> u32 tcp_bloat_ssthresh(struct sock *sk)
>> {
>>         const struct tcp_sock *tp = tcp_sk(sk);
>>         return tp->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]> 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]> 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]] 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]> wrote:
>> > >
>> > > Hi,
>> > >
>> > > On 2017-11-22, at 11:01, Stephen                             Farrell <[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
>> 
>>  
>>  
>