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

[<[e-mail]>]

John,

Thanks, very useful comments.

I agree that putting a lot more effort into word-smithing of the wiki is
not the best use of the ML's time - providing people can live with bob's
latest suggestion

>    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.

Agree. I think the important points are 
(1) the ISPs are doing these measures (DPI, volume capping etc). I think
discussing TCP's inadequacies is somewhat over-detailed; many of the
points being brought up are true, but even if that point was solved
(with TCP++) then it wouldn't end the reason why the ISPs deployed the
measures.
(2) the world would be much better with conex & the usages it enables.

> 
>    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.
> 

depending on what the revised problem statement is like, I think it
could be worth working up some succinct motivation text on the main
motivations. Whilst we don't want to cover all the possible usages of
conex, there seem 2 main things:
- capacity sharing for an ISP. This is solving a current issue in a way
that is "better" than the current mechanisms (which are DPI, volume
capping etc or putting in more bandwidth) - "better" could mean for ISPs
(simpler capacity sharing), regulators (transparency of mgt) etc
- enabling new user/application/transport behaviours by end-hosts (eg
the encouraging ledbat point)

if some nice text can be extracted / adapted from the problem statement
i-d (& Hannes one as well), then it might be worth adding this to the
wiki

Our agenda already covers the capacity sharing motivation; we'll think
about whether there's also time to cover the point about "new end-host
behaviours", or if this will dilute the focus.

>    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.

Leslie and I'll start on some Charter text. I will start with some
thoughts about the 'constraints' item on the agenda. 

I agree that the path to deployment is a very important question that
isn't clear enough. I guess this will be discussed under the
"Viability/Feasibility" agenda item. Another issue is how much the WG
(if formed) thinks about deployment, and how much it leaves this to
operators etc or until re-chartering. 

Thanks
phil