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

[Leslie Daigle <[e-mail]>]

I think this is getting close...

John Leslie wrote:
> [e-mail] <[e-mail]> wrote:
>> I think I would rather say something slightly different about TCP.
>> How about making the whole:
>>
>> " The Internet is, in essence, about pooling resources. The ability to
>> share capacity has been paramount to its success and has traditionally
>> relied on the voluntary use of TCP congestion control. However, TCP
>> may not be the most suitable algorithm for applications such as
>> peer-to-peer or streaming video that break some of its fundamental
>> design assumptions.
> 
>    Yes!

It would be really nice to articulate something about those violated 
design assumptions.  Detail left to the problem draft, if anywhere. 
But, perhaps:

"The Internet is, in essence, about pooling resources. The ability to
share capacity has been paramount to its success and currently relies on 
the voluntary use of TCP congestion control. However, this assumes all 
application requirements are the same, and congestion can be avoided by 
ensuring orderly and fair (on average) access to bandwidth.  This is 
does not generally work for peer-to-peer or streaming video applications."

> 
>> Such applications are able to cause enough congestion over time to
>> severely impair the quality of experience of other users.
> 
>    True, but not quite right. Perhaps:
> " 
> " Such applications need to be a bit more aggressive than TCP under
> " some circumstances even if they are less aggressive on average. ISPs
> " are unable to tell whether such applications are, on average, more
> " or less aggressive than standard TCP congestion-control.

I think it's not just "ISPs" -- it's all network operators, right?  so, 
running with the "can't tell which applications are which" idea, maybe:

"In order to avoid congestion from such applications, more aggressive 
control is required in some circumstances than is provided by standard 
TCP congestion control.  Networks are currently unable to accurately 
detect these applications' traffic or the circumstances in which 
additional control should be applied.  "

> 
>> This has led some ISPs to deploy ad-hoc solutions such as volume
>> accounting, rate policing or deep packet inspection in an attempt to
>> distribute capacity differently.
> 
>    Yes.

Yes.

> 
>> The consequences of such practices are increasing calls for government
>> regulation and stifling innovation at the transport and application
>> layer (see for example, the problem statement I-D (ref below) and
>> RFC5594)."
> 
>    The reader stumbles a bit over this. Perhaps:
> " 
> " Since such practices cannot distinguish whether the policing actually
> " matches the problem, they tend to stifle innovation at the transport
> " and application layers. Also, such practices often appear to be aimed
> " at stifling competitors to those ISPs, leading to increasing calls for
> " government regulation.
> 


I think the rewrite loses the fact that government regulation could 
equally cause stifling of innovation.


Leslie.




> --
> John Leslie <[e-mail]>
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------