Re: [re-ECN] DRAFT minutes from the CONEX BoF at IETF76

[Leslie Daigle <[e-mail]>]

Hi,

Thanks -- changes in the text I'm about to send round as noted below:

Bob Briscoe wrote:
>> == ISP Context/motivation [Rich Woundy]
>>
>> Enable customers to control their own network experience - take ISP 
>> out of the loop of being 'congestion police'
> 
> I'm pretty sure Rich didn't say it like this.
> s/congestion/application/


Done.

>>
>> == Technical problem [Mark Handley]
>>
>> whenever he presents about congestion people say 'we're 
>> overprovisioned, don't care' - he doesn't subscribe to that - will 
>> talk about why we need to care about congestion
> 
> (he = Mark)
> 

Changed first instance of "he" to Mark.

> 
>> TCP isn't broken, but we can do better
>>
>> used to be receive window limited in end systems - no longer the case 
>> in popular modern TCP stacks
>>
>> goal should be for congested networks, at least at the bottleneck
> 
> Mark added:
> 
> "That doesn't mean persistently congested. But a transport that can't 
> congest a bottleneck is broken."

Added.

>> > Geoff Huston: making a good use of the network in either case (re: 
>> latency,
>>   latency, latency) slide.
>>
>> > Mark H: better from a user's perspective
> 
> Discussion after Mark's summary slide:

Added.


>> == Overview of re-ECN   [Bob Briscoe]
>>
>> > Greg L:
> 
> (re: slide 4: measuring contribution to congestion of scavenger vs 
> bursty user)
> 

Inserted.

>> before when we saw that sometimes there is a long duration connection
>>   and something that was very short has to wait, in that case, one of 
>> them
>>   will show the network is very bad, and the other one showing that the
>>   network is very working well.
> 
> s/very working/working very/

Fixed.

>>
>> > Bob B: box in middle just enforces congestion volume allowance, in one
>>   possible deployment.
>>
>> > Lars Eggert: trying to show that the problem is solvable, not that this
>>   is the solution.
>>
>> > Lars Eggert:
> 
> (interrupting at start of slide 9:)

Inserted "(at start of slide 9):"

> 
>> we believe you Bob that you can't cheat (leap of faith)
>>
>> > Murari S:
> 
> (back to thinking about slide 4)

Did not add -- seems like too much detail to inform reader without 
referring to slides and might be whiplash if also referring to slides.

> 
>> Thought I understood conex, not I'm confused.
> 
> s/not/now/

Done.

> 
>> If you only look
>>   at the problem of short flows coming in and using lots of BW, problem
>>   can be solved if all the bulk users used scavenger service.  Problem 
>> would
>>   automatically solve itself.
>>
>> > Bob B: ISPs can't see congestion, how do you get a free pass.
> 
> a/...to use scavenger and not have volume counted against you./

Added.
>> > Jana Iyengar: incentive issue with LEDBAT; end hosts may choose not to
>>   use it.
>>
>> > Bob B: what about big-big flows and little-big flows?  Two classes 
>> may not
>>   be enough.
>>
>> > Stanislav Shalunov: why send the info the user?
> 
> s/the info the user?/the info from the user?/

Fixed.

> 
>> Why not keep it within
>>   the ISP, so that you can evolve the algorithm.
>>
>> > Bob B: don't want to do congestion control within the network.
>>
>> > Stanislav S: seems like two justifications: solve the LEDBAT 
>> problem, ??
>>
>> > Lars Eggert: bunch of questions, high-level question is whether we all
>>   understand what the problem is, seems like it.  Questions that relate
>>   to whether exposing congestion solves the problems.  Then questions 
>> around
>>   how re-ECN exposes congestion.
> 
> At some point, which I think was now (?), I asked for a show of hands on 
> who understands the problem. 
> 

I think it was Lars that asked the question, and it is reflected above. 
  I've changed the text to read:

Lars Eggert: bunch of questions, high-level question is whether we all 
  understand what the problem is (pauses for show of hands) -- seems 
like it.


>> > Leslie: moving discussion to whether there is a problem for the IETF to
>>   solve.
>>
>> > Lars Eggert: knew that this wasn't an easy thing to get your head 
>> around.
>>   Who has read the documents? (several hands).
> 
> I was surprised at the large number who put up their hands. I'm sure it 
> was more than several [for me, it helped explain the earlier number of 
> hands who said they understood].

"Several" is subjective -- I could say it fits with what I saw, and we'd 
both be right.

I suggest:

"(several hands -- more than a dozen, around the room)"


> 
>> Who thought that the documents
>>   were perfectly clear? (didn't check for hands).  Expected more 
>> discussion
>>   on the mailing list.  Disappointed.  Not sure if we are ready at 
>> this point
>>   to discuss a charter.  Problem statement is good to discuss now.  If we
>>   are going for a second BoF, shouldn't spend time on tutorials.
>>
>> > Matt Mathis: how much risk there is associated with starting the 
>> work before
>>   everything else is clear.  Launch with a draft charter.
>>
>> > Bob B: one way to ask the question is whether those who don't 
>> understand it
>>   from stopping those that do from solving it.
> 
> s/from stopping/want to stop/

Changed.

>> > Leslie: two things: deployment considerations, how this would be 
>> considered
>>   useful in practice
>>
>> > Alissa Cooper: tried hard to keep the potential uses apart from what is
>>   being exposed, but it makes it more difficult to understand why this is
>>   useful without describing assumptions about ISP business models.
> 
> [Alissa's point was well made. I think it is better put as follows:]
> 
>  > Alissa Cooper: presenters have tried hard to keep the potential uses 
> apart
>   from what is being exposed, but it makes it more difficult to understand
>   why this is useful. In future, it would be better to be able to talk 
> about
>   potential uses, but carefully state assumptions about ISP business 
> models.
> 

Changed.

>> > Stanislav S: difference between restaurants and data transmission is 
>> ratio of cost of billing to cost of goods. Restaurants will itemise, 
>> but in data networks models are simpler.
>>
>> > Bob B: reason I put up congestion volume bill, was because it is 
>> simple.
> 
> s/bill/limit at flat fee/

Changed to:

  Bob B: reason I put up congestion volume billing (limit at flat fee), 
was because it is simple.


> 
> (Stas gave thumbs up)
> 
>> > Francois L: agree?
>>
>> > Stanislav S: ISPs will expose congestion, but sometimes you will get to
>>   send more, sometimes less. I expect that ISPs would use flat-pricing 
>> but impose different congestion limits.
>>
>> > Francois L: something better than flat rate will evolve.  Like saying
>>   unlimited calling for cell phones.
>>
>> > Stanislav S: that is how things are rapidly evolving
>>
>> > Leslie: should a WG be formed with this charter + some word-smithing
>>   - Yes (some hums)
>>   - No  (some hums)
> 
> I understand it's hard to call whether it was 70:30 or 80:20, but we 
> should surely record that the Yes hum was definitely louder than the No.

Changed to:

   "Yes" hum was distinctly louder than "no".  Seems that there is rough 
consensus to form a WG.  Willing to declare victory.


Thanks,
Leslie.

> 
>>   Seems that there is rough consensus to form a WG.  Willing to 
>> declare victory.
>>
>> > Philip E: demo will start in 5 minutes.
>>
>>
>> Meeting adjourned.
>>
>>
>> Agenda items not formally not addressed:
> 
> delete one not.
> 
> Cheers
> 
> 
> Bob
> 
> 
>> Discussion of potential IETF work
>>   Constraints [10 mins] [Philip Eardley]
>>   Discussion of viability of congestion exposure [40 mins] [Leslie 
>> Daigle]
>>   Draft charter discussion [20 mins]
>>
>>
>>
>> -- 
>>
>> -------------------------------------------------------------------
>> "Reality:
>>      Yours to discover."
>>                                 -- ThinkingCat
>> Leslie Daigle
>> [e-mail]
>> -------------------------------------------------------------------
>> _______________________________________________
>> re-ECN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 

-- 

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