Subject: [QUIC] Comments on charter

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 12 Sep 2016 19:22:41 +0000

Hi

I have read the charter, some comments.

1) 
Congestion control : First to make sure I understand.
The text reads 
Quote : “The following work items are explicitly out of scope for this group:
- Defining new congestion control schemes.”
But then I find the milestone
“Loss detection and Congestion Control document to IESG”
My interpretation of this is that an already defined CC algo should be specified for QUIC, that is confirmed by “Work on congestion control will describe use of an existing congestion controller as a default scheme for QUIC”. The wording here is vague, I understand the goal to settle for an already established CC algo (that is standardized) and I can imagine that folks already have a candidate here already.
Did I understand this correctly ?
Besides this, I believe that it makes sense to exclude work on new CC algorithms , what is however desired is that it is verified that the protocol feedback can support additions of new CC algorithms. I have successfully implemented the Hybrid Cubic CC algorithm from https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 with the already existing protocol feedback. Question is if this feedback is sufficient enough for future use ?
One practical matter around congestion control: CC algorithms are not exactly pluggable in proto-quic, at least not as pluggable as e.g. congestion control algos are in the Linux TCP stack. Not sure if this is something that belongs to this group as it may be an implementation matter, one question is however if there are any security concerns with Linux style pluggable congestion controls as QUIC can be implemented in user space ?. 

2)
ECN : I don’t see it mentioned in the charter. Perhaps this is implied in the text ? (“options negotiation”). What is necessary here is the negotiation of the use of ECN and a proper ECN feedback (ECN-echo) that can support L4S. Preferably this ECN echo should go into the default feedback, but this is probably a later discussion.

Regards
/Ingemar  
====================================
Ingemar Johansson  M.Sc. 
Master Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com

The secret of getting ahead is getting started
                    Mark Twain
=====================================

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 12 Sep 2016 14:31:46 -0500

Hi, Ingemar,

Quoting from your signature line,

"The secret of getting ahead is getting started" - Mark Twain

I'm working on a revised proposed charter to send for community review.
I've seen your feedback below, and will try to Do The Right Thing, but may
end up treating some of it as the first feedback after the IESG asks for
feedback.

And thanks for sending it. It's helpful.

Spencer, as responsible AD for QUIC

On Mon, Sep 12, 2016 at 2:22 PM, Ingemar Johansson S <
[email-masked]> wrote:

> My interpretation of this is that an already defined CC algo should be
> specified for QUIC, that is confirmed by “Work on congestion control will
> describe use of an existing congestion controller as a default scheme for
> QUIC”. The wording here is vague, I understand the goal to settle for an
> already established CC algo (that is standardized) and I can imagine that
> folks already have a candidate here already.
> Besides this, I believe that it makes sense to exclude work on new CC
> algorithms , what is however desired is that it is verified that the
> protocol feedback can support additions of new CC algorithms. I have
> successfully implemented the Hybrid Cubic CC algorithm from
> https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-02 with the
> already existing protocol feedback. Question is if this feedback is
> sufficient enough for future use ?
> One practical matter around congestion control: CC algorithms are not
> exactly pluggable in proto-quic, at least not as pluggable as e.g.
> congestion control algos are in the Linux TCP stack. Not sure if this is
> something that belongs to this group as it may be an implementation matter,
> one question is however if there are any security concerns with Linux style
> pluggable congestion controls as QUIC can be implemented in user space ?.
>
> 2)
> ECN : I don’t see it mentioned in the charter. Perhaps this is implied in
> the text ? (“options negotiation”). What is necessary here is the
> negotiation of the use of ECN and a proper ECN feedback (ECN-echo) that can
> support L4S. Preferably this ECN echo should go into the default feedback,
> but this is probably a later discussion.
>
> Regards
> /Ingemar
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 13 Sep 2016 13:21:30 +0000

OK, I figured that I was perhaps a bit early ☺
Thanks for taking the comments into consideration.

/Ingemar

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: den 12 september 2016 21:32
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>
Subject: Re: [QUIC] Comments on charter

Hi, Ingemar,

I'm working on a revised proposed charter to send for community review. I've seen your feedback below, and will try to Do The Right Thing, but may end up treating some of it as the first feedback after the IESG asks for feedback.

On Mon, Sep 12, 2016 at 2:22 PM, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:
Hi

1)

2)

Regards
/Ingemar

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042<tel:%2B46-1071%2043042>
SMS/MMS +46-73 078 3289<tel:%2B46-73%20078%203289>
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>

[email-masked]<mailto:[email-masked]>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 21 Sep 2016 09:13:12 -0500

Dear QUICsters,

Now that we're actually in External Review, I'd like to hear people's
thoughts on Ingemar's comments ...

I have a couple of thoughts below.

Spencer

> Did I understand this correctly ?

Now that we've adjusted "an existing congestion controller" to be "a
standardized congestion controller" in the version of the charter that's
out for comments, what are people thinking this document would say about
"Congestion Control"?

> but this is probably a later discussion.

I had assumed that ECN would be implied, but that's likely because I'm also
reading e-mail about L4S. What are other people thinking? Understanding
that would be helpful before we approve the working group charter.

Spencer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 09:49:02 +1000

> thoughts on Ingemar's comments ...

I think that the vagueness is OK.  We have to leave some work for the
working group to do, and we can't get all the arguing out the way
before we start.

For the milestone, we have decided in other groups to not fill a
milestone, or to fill two milestones with one document.  If - as the
charter suggests - there isn't really a milestone here and all we do
is point at an existing spec for CC, then that's OK by this charter,
we just point that milestone at the protocol doc.  On balance, I would
prefer that we not include a specific document for CC in the charter,
but don't care to fight about it.

As for ECN, yeah, that's just another signal. Which I hope will be
used by the CC we pick.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 26 Sep 2016 12:18:59 -0700

I agree with Martin that I'm fine with not specifying more things charter.
I'll note a couple of things however:
- There's more work than just pointing to a CC doc. The problem with
current CC standards is that they're written in TCP-ese, which means we'd
have to rewrite them for QUIC in the loss-recovery and congestion control
doc. This is far lesser work than specifying a new CC algorithm, but more
work than simply adding a reference.
- QUIC signaling needs to be specified for ECN, similar to how RFC 3168
specifies it for TCP <https://tools.ietf.org/html/rfc3168#section-6>. I
think this was a bit of an oversight, but again, I don't think this needs
to be worded into the charter, since I would expect this to happen with no
contention. I'm not opposed to adding wording about ECN support either, if
not having an explicit mention bothers folks. This should probably go into
the same congestion control draft, but may need a hook (maybe?) in the core
doc.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 27 Sep 2016 12:05:22 -0500

Just to follow up on Ingemar/Martin/Jana's conversation here ...

On 09/26/2016 02:18 PM, Jana Iyengar wrote:
> I agree with Martin that I'm fine with not specifying more things 
> charter. I'll note a couple of things however:
> current CC standards is that they're written in TCP-ese, which means 
> we'd have to rewrite them for QUIC in the loss-recovery and congestion 
> control doc. This is far lesser work than specifying a new CC 
> algorithm, but more work than simply adding a reference.

That's also my understanding. My intention with the current charter text 
is that the work Jana describes is in scope for a standardized 
congestion controller, but is limited to standardized congestion 
controllers.

Brilliant plans for new congestion controllers for QUIC will happen the 
way they would happen for a new congestion controller for any other 
transport protocol, and not in the QUIC working group.

Does this need to be clearer?

> - QUIC signaling needs to be specified for ECN, similar to how RFC 
> 3168 specifies it for TCP 
> <https://tools.ietf.org/html/rfc3168#section-6>. I think this was a 
> bit of an oversight, but again, I don't think this needs to be worded 
> into the charter, since I would expect this to happen with no 
> contention. I'm not opposed to adding wording about ECN support 
> either, if not having an explicit mention bothers folks. This should 
> probably go into the same congestion control draft, but may need a 
> hook (maybe?) in the core doc.

My expectation would be that if QUIC needs to use ECN, that would happen 
whether it's in the charter or not. Figuring that out is something I'd 
prefer to leave to the working group.

Do people think it needs to be mentioned in the charter?

Thanks,

Spencer

> On Wed, Sep 21, 2016 at 4:49 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/quic>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 27 Sep 2016 10:10:37 -0700

FWIW, I think the text captures that intent well enough... I'm comfortable
with the text as it currently is.

On Tue, Sep 27, 2016 at 10:05 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> is that the work Jana describes is in scope for a standardized congestion
> controller, but is limited to standardized congestion controllers.
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 27 Sep 2016 19:39:01 +0000

I am happy with the clarifications and happy with the charter text as is.

Regards
/Ingemar

From: Jana Iyengar [mailto:[email-masked]]
Sent: den 27 september 2016 19:11
To: Spencer Dawkins at IETF <[email-masked]>
Cc: Martin Thomson <[email-masked]>; Ingemar Johansson S <[email-masked]>; [email-masked]; The IESG <[email-masked]>
Subject: Re: [QUIC] Comments on charter

FWIW, I think the text captures that intent well enough... I'm comfortable with the text as it currently is.

On Tue, Sep 27, 2016 at 10:05 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

On 09/26/2016 02:18 PM, Jana Iyengar wrote:
I agree with Martin that I'm fine with not specifying more things charter. I'll note a couple of things however:
- There's more work than just pointing to a CC doc. The problem with current CC standards is that they're written in TCP-ese, which means we'd have to rewrite them for QUIC in the loss-recovery and congestion control doc. This is far lesser work than specifying a new CC algorithm, but more work than simply adding a reference.

That's also my understanding. My intention with the current charter text is that the work Jana describes is in scope for a standardized congestion controller, but is limited to standardized congestion controllers.

Brilliant plans for new congestion controllers for QUIC will happen the way they would happen for a new congestion controller for any other transport protocol, and not in the QUIC working group.

- QUIC signaling needs to be specified for ECN, similar to how RFC 3168 specifies it for TCP<https://tools.ietf.org/html/rfc3168#section-6>. I think this was a bit of an oversight, but again, I don't think this needs to be worded into the charter, since I would expect this to happen with no contention. I'm not opposed to adding wording about ECN support either, if not having an explicit mention bothers folks. This should probably go into the same congestion control draft, but may need a hook (maybe?) in the core doc.

My expectation would be that if QUIC needs to use ECN, that would happen whether it's in the charter or not. Figuring that out is something I'd prefer to leave to the working group.

Thanks,

Spencer

On Wed, Sep 21, 2016 at 4:49 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
On 22 September 2016 at 00:13, Spencer Dawkins at IETF