Subject: [tcpm] Rechartering TCPM for alternative congestion control algorithms

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 27 Jan 2015 10:21:47 +0000

Hi,

This e-mails asks for community feedback on a suggested small addon to the TCPM charter [1].

In the last TCPM meeting [2] there was strong support for adopting a document describing the CUBIC congestion control algorithm [3]. To the chairs, it is not entirely obvious whether this document, or possibly other similar documents, would indeed be in scope of the current TCPM charter. Given the importance of the TCP congestion control, we prefer a community consensus explicitly documented in the charter instead of ambiguity.

The current charter limits the scope of TCPM to "modest changes to the protocol, algorithms, and interfaces". It allows "incremental enhancements of TCP's standard congestion control" but explicitly mandates rechartering for fundamental changes [1]: 

OLD:

TCPM also provides a venue for standardization of incremental
enhancements of TCP's standard congestion control, but such changes
may require additional review by the IRTF Congestion Control
Research Group (ICCRG). Fundamental changes to TCP or its congestion
control algorithms (e.g., departure from loss-based congestion
control) will be handled by other working groups or will require
rechartering.

We suggest to update this paragraph in the TCPM charter by an explicit statement that "TCPM may document alternative congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet":

NEW:

TCPM also provides a venue for standardization of incremental
enhancements of TCP's standard congestion control. In addition,
TCPM may document alternative congestion control algorithms
that are known to be widely deployed, and that are considered
safe for large-scale deployment in the Internet. Changes of algorithms
may require additional review by the IRTF Congestion Control
Research Group (ICCRG). Fundamental changes to TCP or its congestion
control algorithms (e.g., departure from loss-based congestion
control) will be handled by other working groups or will require
rechartering.

In our reading, "TCP's standard congestion control" is currently defined by RFC 5681.

This e-mail and the suggested rechartering does not imply any adoption of one or more alternative congestion control algorithms.

Any feedback regarding this suggested rechartering would be very welcome. In particular, please let us know if there are any concerns with this proposal or if you have suggestions for a different wording. Please let us know any thoughts until Feb. 15, 2015.

Thanks a lot!

Michael, Pasi, Yoshifumi

[1] https://datatracker.ietf.org/wg/tcpm/charter/

[2] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm

[3] https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic/

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Jan 2015 11:31:46 +0100

> On 27 Jan 2015, at 11:21, Scharf, Michael (Michael) <[email-masked]> wrote:
> 
> Hi,
> 
How would the usage of TCP based CCs in SCTP be handled? Would it be covered in
the documents in TCPM? Would there additional documents be needed? If yes, would
they go also to TCPM or to TSVWG? Just wondering...

Best regards
Michael
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 27 Jan 2015 12:08:08 +0000

> they go also to TCPM or to TSVWG? Just wondering...

Good question. I can only respond as far as TCPM is concerned. The current TCPM charter states in two other paragraphs [1]:

The focus of the working group is TCP. In cases where small
changes are directly applicable to other transports (e.g., SCTP or
DCCP), the mappings to other transports may be specified alongside
that for TCP, but other significant additions and changes to other
transports are not in scope.

[...]

TCP's congestion control algorithms are the model followed by
alternate transports (e.g., SCTP or DCCP), which are standardized in
other working groups, such as the Transport Area WG (tsvwg). In the
past, the IETF has worked on several documents about algorithms that
are specified for multiple protocols (e.g., TCP and SCTP) in the
same document. Which WG shepherds such documents will be determined
on a case-by-case basis. In any case, the TCPM WG will remain in
close contact with other relevant WGs working on these protocols to
ensure openness and stringent review from all angles.

My current thinking is to leave these two paragraphs in the TCPM charter unchanged. As far as I recall, in the past TCPM has handled basically all documents specifying algorithms both for TCP and for SCTP. In contrast, SCTP-only documents are explicitly outside of the current charter of TCPM (i.e., they probably have to go to TSVWG). Thus, it would depend whether a CC algorithm would be specified for TCP and SCTP in the same document, or not. I could also think of TCPM documents describing the usage in SCTP in a non-normative section or an appendix.

The proposed TCPM charter is very explicitly limited to CC algorithms "known to be widely deployed". Adoption in TCPM would probably require that said algorithm has been tested very extensively in TCP stacks (e.g., experiments in which the algorithm has been enabled by default). I don't know whether there is a way to ensure comprehensive testing of an algorithm both for TCP and SCTP. Therefore, I don't think we should mandate that all CC algorithms submitted to TCPM have to be specified both for TCP and SCTP in the same document. The congestion control in RFC 5681 is also specified for TCP only.

Are there any suggestion for an alternative handling?

Thanks

Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 27 Jan 2015 12:21:25 +0000

Hi Michael, Chairs,

First, I think the proposed change to the charter is a good one - especially in the light that there is a recent push to try and document what is currently deployed.

Second, for Cubic specifically there is a single reference to SCTP which indicates that cubic can also be applied to SCTP. However, other than this introductory mentioning, nothing specific is there. But if one builds a CC specific to either TCP or SCTP - which does NOT apply to the other protocol, a document should clearly state so and treated in the respective WG.

In the generic case - that is, CC which applies equally to SCTP and TCP, I think the current provision of having TCPM and ICCRG denting the algorithm out, and then when the time comes, having it in TCPM seems natural, not?

Best regards,
  Richard

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Michael Tuexen
> Sent: Dienstag, 27. Jänner 2015 11:32
> To: Scharf, Michael (Michael)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] Rechartering TCPM for alternative congestion control
> algorithms
> 
> > On 27 Jan 2015, at 11:21, Scharf, Michael (Michael)
> <[email-masked]> wrote:
> >
> > Hi,
> >
> > In the last TCPM meeting [2] there was strong support for adopting a
> document describing the CUBIC congestion control algorithm [3]. To the
> chairs, it is not entirely obvious whether this document, or possibly
> other similar documents, would indeed be in scope of the current TCPM
> charter. Given the importance of the TCP congestion control, we prefer a
> community consensus explicitly documented in the charter instead of
> ambiguity.
> >
> > The current charter limits the scope of TCPM to "modest changes to the
> protocol, algorithms, and interfaces". It allows "incremental enhancements
> of TCP's standard congestion control" but explicitly mandates rechartering
> for fundamental changes [1]:
> >
> > OLD:
> >
> > may require additional review by the IRTF Congestion Control Research
> > Group (ICCRG). Fundamental changes to TCP or its congestion control
> > algorithms (e.g., departure from loss-based congestion
> > We suggest to update this paragraph in the TCPM charter by an explicit
> statement that "TCPM may document alternative congestion control
> algorithms that are known to be widely deployed, and that are considered
> safe for large-scale deployment in the Internet":
> >
> > NEW:
> >
> > enhancements of TCP's standard congestion control. In addition, TCPM
> > may document alternative congestion control algorithms that are known
> > to be widely deployed, and that are considered safe for large-scale
> > deployment in the Internet. Changes of algorithms may require
> > additional review by the IRTF Congestion Control Research Group
> > (ICCRG). Fundamental changes to TCP or its congestion control
> > algorithms (e.g., departure from loss-based congestion
> > This e-mail and the suggested rechartering does not imply any adoption
> > of one or more alternative congestion control algorithms.
> >
> > Any feedback regarding this suggested rechartering would be very
> > welcome. In particular, please let us know if there are any concerns with
> > this proposal or if you have suggestions for a different wording. Please
> > let us know any thoughts until Feb. 15, 2015.
>
>
> How would the usage of TCP based CCs in SCTP be handled? Would it be
> covered in the documents in TCPM? Would there additional documents be
> needed? If yes, would they go also to TCPM or to TSVWG? Just wondering...
> 
> Best regards
> Michael
> >
> > Thanks a lot!
> >
> > Michael, Pasi, Yoshifumi
> >
> >

---

From: Mark Allman <[email-masked]>
Date: Tue, 27 Jan 2015 07:48:50 -0500

> algorithms that are known to be widely deployed, and that are
> considered safe for large-scale deployment in the Internet": 

Seems fine to me.  No need to make easy things difficult; make the
change!

allman

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Jan 2015 14:06:21 +0100

> On 27 Jan 2015, at 13:08, Scharf, Michael (Michael) <[email-masked]> wrote:
> 
>> covered in
OK. Makes sense. If we need modifications for SCTP we can go through TSVWG...

Best regards
Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 07:33:49 -0800

Hi, all,

I disagree; TCP congestion control algorithms are also deployed in other 
transports, and thus this seems more appropriate for TSVWG.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 27 Jan 2015 15:56:24 +0000

Hi Joe,

The current TCPM charter very explicitly includes "incremental enhancements of TCP's standard congestion control". RFC 5681 is a TCPM document.

Are you suggesting that *all* documents dealing with TCP congestion control should be moved from TCPM to TSVWG, including e.g. potential future updates of RFC 5681?

I guess this would result in a major re-chartering both of TCPM and TSVWG. And it could be a slippery road. A lot of TCPM documents affect congestion control at least partly.

Thanks

Michael

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, January 27, 2015 4:34 PM
> To: Scharf, Michael (Michael); [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] Rechartering TCPM for alternative congestion
> control algorithms
> 
> Hi, all,
> 
> charter. Given the importance of the TCP congestion control, we prefer
> a community consensus explicitly documented in the charter instead of
> ambiguity.
> >
> > The current charter limits the scope of TCPM to "modest changes to
> the protocol, algorithms, and interfaces". It allows "incremental
> enhancements of TCP's standard congestion control" but explicitly
> mandates rechartering for fundamental changes [1]:
> >
> > OLD:
> >
> > We suggest to update this paragraph in the TCPM charter by an
> explicit statement that "TCPM may document alternative congestion
> control algorithms that are known to be widely deployed, and that are
> > This e-mail and the suggested rechartering does not imply any
> adoption of one or more alternative congestion control algorithms.
> >
> welcome. In particular, please let us know if there are any concerns
> with this proposal or if you have suggestions for a different wording.
> Please let us know any thoughts until Feb. 15, 2015.
> >
> > Thanks a lot!
> >
> > Michael, Pasi, Yoshifumi
> >
> >

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 08:04:11 -0800

On 1/27/2015 7:56 AM, Scharf, Michael (Michael) wrote:
> Hi Joe,
>
> The current TCPM charter very explicitly includes "incremental
> enhancements of TCP's standard congestion control". RFC 5681 is a TCPM
> document.

Yes, where incremental would include things like tweaking RTO or ACK counts.

> Are you suggesting that *all* documents dealing with TCP congestion
> control should be moved from TCPM to TSVWG, including e.g. potential
> future updates of RFC 5681?

Major changes that aren't specific to TCP, IMO yes, and yes, that would 
definitely IMO include updates to RFC5681.

The community affected and interested in such changes is far beyond that 
of just TCPM. IMO, this is better for TCMP, TSVWG, and the development 
of overarching mechanisms.

> I guess this would result in a major re-chartering both of TCPM and
> TSVWG. And it could be a slippery road. A lot of TCPM documents affect
> congestion control at least partly.

We already have that sort of slippery slope issue. The general rule, 
AFAICT, is "minor" stays in TCPM and major goes to TSVWG. Major always 
includes changes that affect other transports as much as they affect TCP.

(we could even say that adopting CUBIC should happen in TSVWG, but that 
later minor tweaks could happen in TCPM)

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 27 Jan 2015 11:40:05 -0500

> I guess this would result in a major re-chartering both of TCPM and TSVWG. And it could be a slippery road. A lot of TCPM documents affect congestion control at least partly.

When you read the TSVWG or TCPM mailing lists or go to the
meetings, it's a heavily overlapping set of names and faces,
so this is really about which mailing list to use and which
set of chairs will run the process, IMHO.

In the past, when CTCP, CUBIC, and HTCP were being proposed,
TCPM was the group that would have taken them, as mentioned
in the IESG statement from back then:
https://www.ietf.org/iesg/statement/congestion-control.html

TCPM should definitely be the home for this, and TSVWG can be
copied on the adoption call in case some folks there who aren't
following TCPM want to participate.

Either way, reviewing the draft is more important than which
list's name it happens under, so there's no need to have a
constitutional crisis over it.

-- 
Wes Eddy
MTI Systems

---

From: Mark Allman <[email-masked]>
Date: Tue, 27 Jan 2015 12:03:47 -0500

> constitutional crisis over it.

Don't make easy things difficult.  Both directions have valid
arguments.  Someone should decide and we should work on difficult
things.

Sheesh.

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Jan 2015 09:08:10 -0800

+1.

I was making the point that this should be moved to TSVWG instead of 
TCPM, *especially* because of past presentations on new algorithms.

I've made my point. This isn't a "crisis", it's a viewpoint.

The IESG needs to make a decision after others weigh in too.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 27 Jan 2015 17:23:35 +0000

> arguments.  Someone should decide and we should work on difficult

The proposed addon to the TCPM charter is explicitly limited to documenting TCP algorithms "known to be widely deployed". Getting feedback and reviews from TCP implementers is indeed the actual challenge in this case.

I believe (well, actually I hope) that implementers of major stacks indeed follow the TCPM list. In my opinion, we should not make it too complex for them to figure out what is done where in the IETF.

Michael

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Jan 2015 23:41:15 +0100

+1 for TCPM

> On 27. jan. 2015, at 18.23, Scharf, Michael (Michael) <[email-masked]> wrote:
>