Subject: RE: Congestion Control Questions

From: Lucas Pardue <[email-masked]>
Date: Fri, 1 Sep 2017 11:09:35 +0000

On Aug 29 2017, Spencer Dawkins wrote:

I'm hoping that's true, but feel I should ask if people are thinking about behavior that's NOT sender-side only, right about here, in this thread.

Two thoughts come to mind:

  1.  Previous discussions on unidirectional streams have elicited some ideas on unidirectional flows. Without falling into the multipath trap, do these have sender-side only CC characteristics?
  2.  Multicast. Trying to avoid opening that can of worms but there are some similarities to the above unidirectional flow thoughts. BCP 145 Section 4.1 covers this topic, stating “Applications using multicast SHOULD provide appropriate congestion control” and defines two styles of CC: “Feedback-based” and “Receiver-driven”. Receiver-driven CC can still be subject to congestion in the network[1], and while there may be some proposals (such as Circuit Breakers) to help avoid this, it still appears to be open.

I appreciate this is probably out of scope of QUIC at this time, however we have been playing with a form of Receiver-driven CC with QUIC.

Lucas

[1] https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-malicious-oversubscribing-in-multicast-problem-and-proposed-solution-00.pdf

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 1 Sep 2017 13:48:39 +0000

Hi
Not sure if I follow the intention with this congestion control discussion and where it is going.

If there are ideas to split congestion control between sender and receiver then I would ask people to at least think twice before going down that line. One big question mark is interoperability between versions, a sender based CC only (or receiver only) is much more likely to be interoperable between QUIC versions than a CC where parts are split up. My preference (reflected in the SCReAM work) is a sender side only as the sender for natural reasons has the best knowledge what it is to transmit.

I have some bad experience with the MTSI (Voice, Video) congestion control in 3GPP (which I am partly guilty of). It specifies a mix of congestion control algos, where some parts are implemented on the sender side and some parts are on the receiver side. The end result is quite messy. In some effort  of a defense for the MTSI congestion control is that it needed to work also with circuit switched connections, if re-done today I believe that it would be much cleaner but we are stuck with a need to interop with older legacy equipment..

/Ingemar

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: den 29 augusti 2017 16:37
To: Mirja Kühlewind <[email-masked]>
Cc: [email-masked]; Swindells, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]>; [email-masked]; Christian Huitema <[email-masked]>
Subject: Re: Congestion Control Questions

FWIW,

On Mon, Aug 28, 2017 at 12:23 PM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:
My thinking actually was that the recovery and congestion control schemes are in a separate document because this gives you the flexibility to specify alternatives in future.

That was certainly my understanding, when we were doing the charter.

If there are parts in this document that are mandatory for all future instances of this version of QUIC or specify requirements, they should go into the main transport spec. However, I think all we really need in the main spec is a requirement to do congestion control at all;

I would support that ... but, just to take a QUIC(!) sample ...

everything else in the recovery/cc draft should be sender-side only and can therefore be changed without requiring any negotiation or changes by the other end.

Spencer

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 1 Sep 2017 16:55:08 -0700

I would love to talk about other CC mechanisms, but in ICCRG :-)

Pull the conversation back to the spec, I think we should keep recovery and
CC both in this doc for now, and see if it's worth splitting them out
later. I'm not convinced that the receiver needs to have input into the ack
rate, but we can discuss that on issue #230.

On Fri, Sep 1, 2017 at 6:48 AM, Ingemar Johansson S <
[email-masked]> wrote:

> If there are ideas to split congestion control between sender and receiver
> then I would ask people to at least think twice before going down that
> line. One big question mark is interoperability between versions, a sender
> based CC only (or receiver only) is much more likely to be interoperable
> between QUIC versions than a CC where parts are split up. My preference
> (reflected in the SCReAM work) is a sender side only as the sender for
> natural reasons has the best knowledge what it is to transmit.
>
>
>
> I have some bad experience with the MTSI (Voice, Video) congestion control
> in 3GPP (which I am partly guilty of). It specifies a mix of congestion
> control algos, where some parts are implemented on the sender side and some
> parts are on the receiver side. The end result is quite messy. In some
> effort  of a defense for the MTSI congestion control is that it needed to
> work also with circuit switched connections, if re-done today I believe
> that it would be much cleaner but we are stuck with a need to interop with
> older legacy equipment..
>
>
>
> /Ingemar
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* den 29 augusti 2017 16:37
> *To:* Mirja Kühlewind <[email-masked]>
> *Cc:* [email-masked]; Swindells, Thomas (Nokia - GB/Cambridge, UK) <
> [email-masked]>; [email-masked]; Christian Huitema <
> [email-masked]>
> *Subject:* Re: Congestion Control Questions
>
>
>
> FWIW,
>
>
>
> On Mon, Aug 28, 2017 at 12:23 PM, Mirja Kühlewind <
> [email-masked]> wrote:
>
> My thinking actually was that the recovery and congestion control schemes
> are in a separate document because this gives you the flexibility to
> specify alternatives in future.
>
>
>
> If there are parts in this document that are mandatory for all future
> instances of this version of QUIC or specify requirements, they should go
> into the main transport spec. However, I think all we really need in the
> main spec is a requirement to do congestion control at all;
>
>
>
> everything else in the recovery/cc draft should be sender-side only and
> can therefore be changed without requiring any negotiation or changes by
> the other end.
>
>
>
> I'm hoping that's true, but feel I should ask if people are thinking about
> behavior that's NOT sender-side only, right about here, in this thread.
>
>
>
> Spencer
>