Subject: Quick Elephants

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Feb 2017 10:17:40 -0800

Dear all,

I'm not that familiar with the state of play here, but in the future
we will have more and more LFN network connections (long fat pipe:
high bandwidth-delay product with long delays), as well as wireless
networks where packet losses are not necessarily due to contention on
the shared channel.

My understanding is currently we have a bunch of dirty hacks (like
locally resending data over the lossy bit) to make this work, a lot of
which will stop working with QUIC.  What can we recommend for
congestion control algorithms and multiplexing use to alleviate the
problems?

Sincerely,
Watson

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Feb 2017 10:31:37 -0800

Hi Watson,

The current plan is to write up NewReno as the congestion controller for
QUIC. I don't think we need to make special recommendations for networks
with large BDPs in terms of congestion control, since QUIC can use the same
congestion controller as TCP for these networks. Specifically, if you have
dirty hacks that you use to make TCP (with NewReno or Cubic) work, you
ought to be able to do the same trickery with QUIC.

(I can't think of new multiplexing recommendations for these networks.)

- jana

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 23 Feb 2017 13:42:29 -0800

I also think we don't need to make special recommendations. But, if the
dirty hacks include transparent PEPs, I guess it will be difficult to do
with QUIC.
--
Yoshi

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 24 Feb 2017 14:40:01 +0100

Yes, the problem is that you don’t see anymore with quic that a packet was lost, so you can’t retransmit locally (I think this is totally independent of the congestion control though…)

Mirja

> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida <[email-masked]>:
> 
> I also think we don't need to make special recommendations. But, if the dirty hacks include transparent PEPs, I guess it will be difficult to do with QUIC.
> --
> Yoshi
> 
> The current plan is to write up NewReno as the congestion controller for QUIC. I don't think we need to make special recommendations for networks with large BDPs in terms of congestion control, since QUIC can use the same congestion controller as TCP for these networks. Specifically, if you have dirty hacks that you use to make TCP (with NewReno or Cubic) work, you ought to be able to do the same trickery with QUIC.
>

---

From: Roland Zink <[email-masked]>
Date: Fri, 24 Feb 2017 16:14:08 +0100

Don't think this is completely independent of the congestion control. 
Resending lost packets also make the ack coming earlier. The congestion 
algorithm will behave different, for example packet losses may be 
hidden. As this doesn't work with QUIC the NewReno or Cubic congestion 
control algorithms may show bad performance and will be unable to fill 
the pipe depending on the link error rate.

Roland

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Feb 2017 07:45:15 -0800

On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink <[email-masked]> wrote:
> algorithm will behave different, for example packet losses may be hidden. As
> this doesn't work with QUIC the NewReno or Cubic congestion control
> algorithms may show bad performance and will be unable to fill the pipe
> depending on the link error rate.

There are new link error insensitive algorithms which learn the error
rate and congestion separately. We might want
to recommend using one of those.

>> Yes, the problem is that you don’t see anymore with quic that a packet was
>> lost, so you can’t retransmit locally (I think this is totally independent
>> of the congestion control though…)
>>
>> Mirja
>>
>>
>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, you ought
>>> to be able to do the same trickery with QUIC.
>>>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Roland Zink <[email-masked]>
Date: Fri, 24 Feb 2017 17:04:42 +0100

Sounds good to me. However when the endpoing vendors / operators don't 
consider this the link vendor / operator can't do anything about it. So 
this may cause network ossification.

Roland

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Feb 2017 17:37:06 +0000

On 24/02/2017 16:04, Roland Zink wrote:
>>> hidden. As
>>>> lost, so you can’t retransmit locally (I think this is totally
>>>> independent of the congestion control though…)
>>>>
>>>> Mirja
>>>>
>>>>

Normally new  congestion control methods need to be reviewed by ICCRG 
before they are progressed by a TSV working group. Have any of these 
algorithms being presented to the IETF (point me please to presentations 
i can look at).  I'm assuming the same applies for QUIC also when it 
comes to this sort change?

Gorry

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 24 Feb 2017 09:43:22 -0800

The charter says:

"Work on congestion control will describe use of a
standardized congestion controller as a default scheme for
QUIC. Defining new congestion control schemes is explicitly out of
scope for this group."

The current plan is to describe NewReno for QUIC in
draft-ietf-quic-recovery. If there's interest in writing a Cubic for QUIC
document after the cubic doc is finished in TCPM, I'd be fine with that
being a later additional doc.

Subsequent non-standardized controllers however should follow a similar
process as we expect for TCP today. At any rate, this won't appear in any
of the current QUIC wg documents unless we re-charter.

On Fri, Feb 24, 2017 at 9:37 AM, Gorry Fairhurst <[email-masked]>
wrote:

> algorithms being presented to the IETF (point me please to presentations i
> can look at).  I'm assuming the same applies for QUIC also when it comes to
> this sort change?
>
> Gorry
>
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 24 Feb 2017 12:12:48 -0800

> being a later additional doc.

After 12 years since Cubic escaped onto the Internet and was used by
default in Linux, it still isn't standardized... I imagine Google's
new one isn't going to even start.
http://queue.acm.org/detail.cfm?id=3022184

> process as we expect for TCP today. At any rate, this won't appear in any of
> the current QUIC wg documents unless we re-charter.

Ah, I hadn't realized that there were no loss-tolerant control
protocols standardized yet. I guess we're going to be stuck with this
wireless problem then, absent some creative vendor solutions (like
per-packet acks? aggressive coding?). What can we do to help some of
these solutions?

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 24 Feb 2017 12:32:37 -0800

> http://queue.acm.org/detail.cfm?id=3022184

There are a lot more congestion controllers in use today than those
standardized. There are about a dozen of these available to any Linux
server today for TCP. This is partly because congestion control does not
need interoperability, and the ones that the IETF ends up documenting are
still Informational (see cubic draft
<https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04>.)

The reason for IETF documentation of these controllers is not to write "yet
another standard that's late," but to have a reference for others wanting
to implement it because it's proven. Bear in mind that before the IETF
documented LEDBAT, there was no documentation for it, and there's no real
documentation for Cubic either (modulo their paper, which is inadequate for
an implementer.) Sure Cubic could have been documented earlier, but AIUI,
Lars had to expend some energy getting the Cubic designers to do this at
the IETF.

Implementations haven been free to choose their own controller for TCP;
indeed that's how Google experimented with BBR. Google is experimenting
with BBR in QUIC
<https://cs.chromium.org/chromium/src/net/quic/core/congestion_control/> as
well, but I don't think it ought to be documented in the IETF yet since
it's still quite experimental.

> per-packet acks? aggressive coding?). What can we do to help some of

Yeah there aren't any loss tolerant ones standardized yet because we have
very little publicly-shared experience with those as a community. I suspect
that the most widely deployed controllers right now for TCP are Cubic,
NewReno, and FastTCP, but only two of those are documented in the IETF.
This shouldn't keep folks from trying with loss-tolerant ones though!

And if you know of any such work, please get them to show up in ICCRG!
(ICCRG-chair hat on :-))

> >>>>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd <
> [email-masked]>
> >>>>>>> wrote:
> >>>>>>> Dear all,
> >>>>>>>

---

From: Kyle Rose <[email-masked]>
Date: Fri, 24 Feb 2017 16:20:17 -0500

> <https://tools.ietf.org/html/draft-ietf-tcpm-cubic-04>.)

I didn't think about this during charter-bashing, but is the charter boxing
QUIC into a set of congestion control algorithms limited to TCP-style
metrics (packets in flight, RTT, etc., plus ECN), and is there any downside
to that?

A strength of the TCP approach of completely abstracting congestion control
is that there is a well-defined space for experimentation, where such
experimentation does not require interop. Does QUIC as-proposed provide
sufficient feedback from the peer to cover any known or proposed congestion
control that (at least in theory) might provide benefit over what is
possible with TCP today?

Kyle

---

From: joel jaeggli <[email-masked]>
Date: Sat, 25 Feb 2017 09:50:53 -0800

> per-packet acks? aggressive coding?). What can we do to help some of
802.11foo variants feature reliable delivery for unicast traffic even
when you wish they wouldn't.