Re: [re-ECN] FW: ConEx BoF announcement text

[John Leslie <[e-mail]>]

   Meta-comment: Bob _really_should_ break the habit of quoting the whole
of the message he's responding to!

   (It wouldn't hurt if the rest of us also broke that habit.)

Bob Briscoe <[e-mail]> wrote:
> 
> I realised what I didn't like. It was saying "TCP can't bash p2p" 
> which implied we want something that can.

   An important point. We're not trying to win over the folks that want
that.

> I've changed it round (& it's a few bytes shorter):

   (Another meta-comment: It's hard to get the context, or even exactly
what Bob wants the whole BoF announcement to look like.)

> <BB_proposed_para2>
> The Internet is, in essence, about pooling resources. The ability to 
> share capacity has been paramount to its success and has 
> traditionally been managed through the voluntary use of TCP 
> congestion control. However, TCP doesn't account for how much an 
> application occupies capacity over time. This has led ISPs to deploy 
> various ad-hoc mechanisms such as volume accounting, rate policing 
> and deep packet inspection. These try to protect the experience of 
> the majority of users by limiting persistent traffic such as 
> peer-to-peer file-sharing or video streaming. These ad-hoc practices 
> can stifle innovation at the transport and application layer (see for 
> example, the problem statement I-D referred to below and RFC5594). 
> This in turn has increasingly led to calls for government regulations.
> </BB_proposed_para2>

   It's really getting to be time to put this to bed: so I won't
respond to individual words and phrases...

   Generally, it's an improvement to talk about what TCP _doesn't_
take into account. At some point we'll have to explain why these
omissions are important, but it doesn't have to be here.

   It's clear enough that ISPs and other network managers _are_
deployinng the kinds of measures listed, whether or not it's clear
why they do it. There's really not much we can do in the line of
defending or attacking them here: the practices will have to be
discussed at the BoF, and the less we accept responsibility for
defending or attacking them, the better.

   Frankly, the "Problem Statement" isn't going to be in terribly
good shape at the time that folks will be reading the BoF announcement.
It's an important document; it does not deserve to be rushed. I
question whether mentioning it in the BoF announcement helps.

> The whole thing has a relentlessly negative tone I'm afraid.

   There's really not much we can do about that. Live with it!

> It's all about using ConEx to stop stuff. It's not getting across
> that we're giving ISPs a tool to encourage things like LEDBAT and
> potentially much better LEDBAT++s.

   This is true; but I'm not sure we've even gotten that across to
the active participants on this list. The sort of tweaking we've
been attempting for the last week _can't_ hope to get that across.
Perhaps someone would like to prepare an agenda item on that?

> And faster transports in the future. And apple pie. And not having
> to limit volume unnecessarily. And not having to limit bit-rate
> unnecessarily. And doves, and blossom and running mountain streams ...

   :^) !!!

   'Twould be a lovely agenda item...

> <2nd_Half_of_para3_on_wiki>
> Once ISPs can see rest-of-path congestion, they can discourage users 
> from causing large volumes of congestion, discourage other networks 
> from allowing their users to cause congestion, and more meaningfully 
> differentiate between the qualities of services offered from 
> potential connectivity partners. Meanwhile end-hosts may be freed 
> from rate restrictions where their traffic causes little congestion.
> </2nd_Half_of_para3_on_wiki>

   (Probably I should hunt down that wiki page and do a mental diff,
but I do have other things that need to get done today...)

   I really don't know if the wiki can be a good tool for expressing
this stuff: in general, a wiki will evolve to a point where enough
differing opinions are detailed; but that evolution proceeds on its
own timescale, whereas we're facing a hard deadline for the BoF to
start and finish.

   In any case, a wiki really doesn't try for brevity, and attempts
at brevity (at the expense of completeness) aren't helping here.
Might it be better for Bob to have his own section of the wiki to
explain _exactly_ how he sees re-ecn fitting in -- where he gets
his text complete and simply posts pointers to it?

   I don't believe that posting proposed changes to "the wiki", as if
it were a WG document with a Document Editor, is working.

   Nor do I even believe that trying to have text which is all things
to all participants is a good goal to pursue here.

   Clearly, the BoF needs to happen. Almost as clearly, the BoF is
not about whether re-ecn is the right solution. It's clear to me that
we're going to have to live with a mushy problem-statement at the BoF;
so picking "the" solution would be ill-advised, even if the Tao of
BoFs didn't forbid it.

   The BoF needs instead to give IESG folks a way to judge whether
there's sufficient interest and commitment to form a Working Group,
and whether a Charter can be written that appears to have a good shot
at success. IMHO, the IESG is generally friendly to this idea; but
there's a lot of history to look back on, and the path to deployment
is unclear.

   I don't honestly know how well IESG folks understand re-ecn, but
that may not matter. We've had plenty of opportunities to explain
the basic ideas of re-ecn: we shouldn't consider success or failure
to get those ideas across at the BoG as a critical-path.

   We should present the breadth of interest; we should try to get
across _some_ progress on a Problem Statement; and we should hope
for a goodly hum on willingness to work on the problem.

   I doubt that fine-tuning the BoF announcement is a good way to
ensure _any_ of those tasks...

--
John Leslie <[e-mail]>