Subject: Re: [iccrg] Bufferbloat and Congestion Control

From: Jim Gettys <[email-masked]>
Date: Sat, 1 Apr 2017 10:15:17 -0400

On Fri, Mar 31, 2017 at 10:51 PM, Joe Touch <[email-masked]> wrote:

>
>
> On 3/31/2017 4:30 PM, Jim Gettys wrote:
>
>
>
> On Fri, Mar 31, 2017 at 6:18 PM, Joe Touch <[email-masked]> wrote:
>
>>
>>
>> On 3/31/2017 7:47 AM, Jim Gettys wrote:
>> > One full size packet @ 1mbps == 13 milliseconds.
>> That sort of blocking is its own problem and the only solution is to use
>> smaller packets.
>>
>> It can be solved at TCP by pushing the MSS down, but for UDP that's
>> another good reason for considering UDP options as a TSVWG WG item!
>>
>
> ​Yes, but without better packet scheduling such as fq_codel at the
> bottleneck, it won't help.  But I'm decently optimistic that ​that
> fq_codel/cake/other things will be deploying widely, since we're seeing
> fq_codel appear in commercial products at this date.
>
>
> No amount of scheduling overcomes a limit on the unit of scheduling - the
> packet size, which has increasing impact as link bandwidth decreases.
>
> Better scheduling is important necessary too, but by itself insufficient.
>

​Agree entirely. Both are necessary, and either by itself insufficient.
                                    - Jim

                                     ​

>
>
> Joe
>
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 4 Apr 2017 08:32:22 -0700

> another good reason for considering UDP options as a TSVWG WG item!
I'm not sure how much having MSS for UDP solves. MSS doesn't give us
path MTU, we still need some PMTU discovery in TCP and presumably need
this for connected UDP.

Tom

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 11 Apr 2017 21:03:50 +0000

On 2017-3-31, at 6:41, Bless, Roland (TM) <[email-masked]> wrote:
> Lars Eggert said something like:
> "Bufferbloat is something that a congestion controller
> can't really do anything about anyway...
> it's not necessarily a congestion control problem."

So just for the record, I don't think that was me, because I missed that session.

Lars

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 12 Apr 2017 11:01:52 +0200

Hi Lars,

> So just for the record, I don't think that was me, because I missed that session.

It seemed to be in tsvarea II session and I thought you made that
comment roughly at 01:25:00:

https://play.conf.meetecho.com/Playout/?session=IETF98-TSVAREA-20170327-1520

If it wasn't you, I'm sorry for wrongly stating that.

Best regards,
 Roland

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Apr 2017 11:14:53 -0700

On 3/31/2017 6:41 AM, Bless, Roland (TM) wrote:
> I believe that this statement is not correct.
FWIW, I can see both sides.

I agree with Roland that a single endpoint *can* avoid the impact of
bufferbloat *on its individual connection*, e.g., using delay-based
feedback.

However, having listened again to Lars's comments at the mic, I infer
that he's right too - no amount of pairwise congestion control can avoid
the aggregate effects of bufferbloat on a path. If others are creating
the bloat - individually or by aggregation - then nothing you can do
will avoid it.

I.e., a solution to bufferbloat always requires fixing the queuing in
the buffers that bloat. It's critical to ensure that flows don't create
bloated delays for each other, but much less critical that they
necessarily correct for the mistakes of a single endpoint pair (unless
that's part of fixing the former).

Joe

---

From: Roland Bless <[email-masked]>
Date: Fri, 14 Apr 2017 22:55:19 +0200

Hi Joe,

> the bloat - individually or by aggregation - then nothing you can do

I tried to give a counter example that congestion control
could avoid bufferbloat, however, under the assumption that
_everyone_ uses the same delay-based congestion control.
Since one can't exclude misbehaving flows,
an AQM is a good safe guard, that also enables the
use of ECN. So yes, we better use both mechanisms.

Regards,
 Roland

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 15 Apr 2017 10:18:58 +0000

> If it wasn't you, I'm sorry for wrongly stating that.

Ah, sorry - I got this via the ICCRG list, and thought you referred to that session.

Lars