Subject: [tcpm] [Fwd: Confirmation for Auto-Post of I-D draft-ietf-tcpm-newcwv]

From: [email-masked]
Date: Mon, 16 Dec 2013 21:28:16 -0000

We've submitted a revised ID for new-cwv.

There are 2 main updates:

- The draft now firmly recommends the use of pacing. We will provide
performance data on pacing for the next IETF.

- The draft has a small amendment to the algorithm to ensure that the NVP
does not inhibit cwnd growth when a sender fully consumes the cwnd. There
was previously a corner case in the measurement of pipeACK when a flow
started or resumed that could result making newCWV more conservative than 
standard TCP (e.g. for a bulk flow). We think the correction is within the
original spirit of new CWV.

We'd welcome feedback on these or any other aspects.

Best wishes,

the new CWV authors

--------------------------------------------------------------------------

Hi,

The IETF datatracker draft submission service has received your draft
draft-ietf-tcpm-newcwv-04, and requires a
confirmation step in order to be able to complete the posting of
the draft.

Please follow this link to the page where you can confirm the posting:
Confirmation URL:
http://datatracker.ietf.org/submit/status/56402/confirm/c575579feb585d58d82af80a319918630e8d0529/

Best regards,

	The IETF Secretariat
	through the draft submission service

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 16 Dec 2013 19:55:10 -0800

> We'd welcome feedback on these or any other aspects.
I appreciate the new section on burst mitigation but why standard track?

The change has pro-found impact on congestion control as it changes
how cwnd increases per ACK and after idle. There are a lot to
experiment before we know this works well in real networks.

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

---

From: [email-masked]
Date: Tue, 17 Dec 2013 08:28:32 -0000

> I appreciate the new section on burst mitigation but why standard track?
The previous discussions on STD track centres on whether we would include
require a burst mitigation section, so this is now a good question.

> experiment before we know this works well in real networks.
Are you referring to the new ack-mitigation section - requiring pacing
after idle?

Gorry

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 17 Dec 2013 07:58:41 -0800

> Are you referring to the new ack-mitigation section - requiring pacing
I am referring to the main changes proposed in the draft, not just
pacing after idle.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 17 Dec 2013 16:10:32 +0000

> I am referring to the main changes proposed in the draft, not just
OK, so this algorithm hasn't changed much for a couple of IETFs.

Do you have concerns about relaxing the Standard behaviour (collapsing 
to IW after one RTO), and that letting apps maintain a higher cwnd has 
dangers?

Or do you think the algorithm may keep to high a cwnd when non-validated?

Or is it something else?

- I'm happy to document/discuss (potential) concerns.

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 17 Dec 2013 08:39:51 -0800

On Tue, Dec 17, 2013 at 8:10 AM, Gorry Fairhurst <[email-masked]> wrote:
> Do you have concerns about relaxing the Standard behaviour (collapsing to IW
> after one RTO), and that letting apps maintain a higher cwnd has dangers?
>
something else.

I thought standard means people have used it, found it working, and
like how it works. May I am wrong.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sun, 22 Dec 2013 15:12:22 +0000

> like how it works. May I am wrong.

A general remark...

Section 4.1.1 of RFC 2026 defines Proposes Standard as follows:

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

   The IESG may require implementation and/or operational experience
   prior to granting Proposed Standard status to a specification that
   materially affects the core Internet protocols or that specifies
   behavior that may have significant operational impact on the
   Internet.

According to the second paragraph, implementation or operational experience is formally *not* required. However, there is the third paragraph, and TCP is probably a core Internet protocol with significant operational impact on the Internet ;)

According to related past discussions, my understanding is that a large part of the TCPM community wants to have implementation and operational experience for all TCPM standards track documents. That is a high bar, and it may be one of the reasons why TCPM publishes many documents as experimental (first). (See also MPTCP as another example.)

<chair hat off>
In my personal view, publishing a proposed standard in TCPM that has low likelihood of Internet-scale deployment doesn't make a lot of sense. This is my general thinking, and it is entirely independent of this specific discussion of draft-ietf-tcpm-newcwv. 
</chair hat off>

Michael