Subject: Re: [tcpm] IW10 & queuebloat

From: Bob Briscoe <[email-masked]>
Date: Mon, 2 Apr 2012 16:05:51 +0100

Mark,

1/ There may be some missing context for those not at the Paris tcpm meeting...

Just because I mentioned the two things in the same email, I didn't 
mean I want IW10 to stall on the outcome of the experiment I would 
like to see. I merely sent my email to correct a remark from Jerry 
(in Paris) that seems to have been said in haste (after the chairs 
moved discussion to the list).

2/ That said, I do want to correct a perception that I chose DCTCP 
because it's *my* notion of what the future Internet will be like. 
DCTCP is in the Windows 8 Server Edition Beta. Therefore it is 
reasonable to assume that DCTCP could be a major part of the future 
mix of TCP response algorithms, even though (for now) Microsoft has 
arranged DCTCP to only enable itself in sub-20ms RTT environments 
where the OS is also configured with a "data-center" template.

More generally, we do have some responsibility to check whether 
combinations of new approaches will be counterproductive.

3/ Increasing IW a little should improve performance. Increasing IW 
too much would worsen performance on average. This is not an exact 
science, it all depends which environments we consider to be the ones 
we care about. The idea of developments like DCTCP is to leave plenty 
of spare buffer to absorb bursts, so that we are less sensitive to 
the chosen value of IW. But we don't want IW to grow so much 
(ultimately) that it just negates any hard-won benefit we might one 
day see, if we can find a way to widely deploy advances like 
DCTCP  on the public Internet.

Bob

At 15:28 30/03/2012, Mark Allman wrote:

>With all due respect Bob,
>
>Bob:
> > > I would like to see experiments with IW10 in a simulation
> > > modelling how the Internet is likely to be in future (with more
> > > DCTCP-like protocols and shallower AQM) rather than just how the
> > > Internet is now. I'm not saying whether IW10 is good or bad for
> > > "queuebloat", because I haven't done such experiments.
>
>More Bob:
> > I'd love to see the people who are making the proposal pay for the
> > research ;)
>
>Surely the bar for getting something standardized these days is not
>assessing how a proposal measures up to someone's notion of "how the
>Internet is likely to be in [the] future".
>
>Put another way, I don't think you'd appreciate this bar being applied
>to your proposals and my volumous notions about the future Internet,
>would you?  (Hint: I am *full* of (ahem) "vision".)
>
>Silliness.
>
>
>Dear TCPM chairs, Can we please WGLC IW10?  We have been talking about
>it for eons.  There is much empirical / simulation / testbed assessment
>of it.  The pros and cons have been discussed to death.  Everyone will
>never agree with it.  But, lets put a stake in the ground and see where
>we're at WRT WG consensus.  If we have consensus then lets move it.  If
>we don't have consensus then lets table it.  It is time.
>
>allman
>
>
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Apr 2012 11:43:33 -0700

On 3/30/2012 10:41 AM, Yuchung Cheng wrote:
...
> A gentle reminder the intended status is experimental which calls for more
> experiments like what Bob and others are suggesting.

 From the TAO of the IETF:

---
Experimental RFCs are for specifications that may be interesting, but 
for which it is unclear if there will be much interest in implementing 
them, or whether they will work once deployed. That is, a specification 
might solve a problem, but if it is not clear that many people think 
that the problem is important, or think that they will bother fixing the 
problem with the specification, the specification might be labeled an 
Experimental RFC. If, later, the specification becomes popular (or 
proves that it works well), it can be re-issued as a standards-track 
RFC. Experimental RFCs are also used to get people to experiment with a 
technology that looks like it might be standards-track material, but for 
which there are still unanswered questions.
---

AFAICT, this proposal isn't experimental at all if the point is to 
deploy it as default in widely-used systems on the Internet.

IMO, experimental RFCs ought to require an explanation of the experiment 
expected. It's disingenuous (at best) and misleading to call IW10 
"experimental".

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 2 Apr 2012 12:03:31 -0700

On Mon, Apr 2, 2012 at 11:43 AM, Joe Touch <[email-masked]> wrote:
> Experimental RFCs are for specifications that may be interesting, but for
> which it is unclear if there will be much interest in implementing them, or
> whether they will work once deployed. That is, a specification might solve a
> problem, but if it is not clear that many people think that the problem is
> important, or think that they will bother fixing the problem with the
> specification, the specification might be labeled an Experimental RFC. If,
> later, the specification becomes popular (or proves that it works well), it
> can be re-issued as a standards-track RFC. Experimental RFCs are also used
> to get people to experiment with a technology that looks like it might be
> standards-track material, but for which there are still unanswered
> questions.
> ---
>
> AFAICT, this proposal isn't experimental at all if the point is to deploy it
> as default in widely-used systems on the Internet.

which part in our draft talks the point you mentioned? we'll be happy
to correct it.

"""
2.  TCP Modification

   This document proposes an increase in the permitted upper bound for
   TCP's initial window (IW) to 10 segments depending on the MSS. This
   increase is optional: a TCP MAY start with an initial window that is
   smaller than 10 segments.

   More precisely, the upper bound for the initial window will be

         min (10*MSS, max (2*MSS, 14600))                            (1)
"""

"""
12. Usage and Deployment Recommendations

   Further experiments are required before a larger initial window shall
   be enabled by default in the Internet. The existing measurement
   results indicate that this does not cause significant harm to other
   traffic. However, widespread use in the Internet could reveal issues
   not known yet, e.g., regarding fairness or impact on latency-
   sensitive traffic such as VoIP.
"""

> expected. It's disingenuous (at best) and misleading to call IW10
We didn't get to determine the status, the WG did.

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Apr 2012 12:54:47 -0700

On 4/2/2012 12:03 PM, Yuchung Cheng wrote:
> On Mon, Apr 2, 2012 at 11:43 AM, Joe Touch<[email-masked]>  wrote:
>>
>>

This is inconsistent with the following, from the Intro:

    We recommend that all TCP implementations have a settable TCP IW
    parameter. As of 2011 an appropriate value for this parameter is 10
    segments as long as there is a reasonable effort to monitor for
    possible interactions with other Internet applications and services.
    Furthermore, it is understood that the appropriate value for IW is
    likely to continue to rise in the future, but this document does not
    include any supporting evidence for larger values of IW.

> We didn't get to determine the status, the WG did.

Agreed, but it's now your responsibility to ensure that the doc reflects 
that status.

Joe

---

From: Joseph Ishac <[email-masked]>
Date: Mon, 2 Apr 2012 18:02:20 -0400

> >> as default in widely-used systems on the Internet.

No where in the TAO do I see it discouraging use on production servers,
nor do I see anything that specifies how many servers is "too many" or
the magic number to "become popular".  I'd imagine that the more servers
that implement the option, the more data that's available to determine
if it works well, and if others take interest in the specification.

>     include any supporting evidence for larger values of IW.

I assume the contention is with the word "all"?

I don't think it's necessary to introduce wiggle words into every part
of an experimental draft.  That by noting the draft as experimental, I
can read the above section of the introduction without treating it as a
levied requirement or BCP.  The text helps to highlight the overall goal
and vision of the experimental option, which in turn would help
highlight how one might actually experiment with it and who might be
interested in the concept (in this case the author argues "everyone").

> >> expected. It's disingenuous (at best) and misleading to call IW10

I would claim that the goal of the document should focus more on the
concept and not exactly what type of experiment needs to be run.  The
very nature of experimentation means that there may be ways or angles to
test a concept or hypothesis... I wouldn't burden the document with
trying to capture all of them or how to analyze the data.  In fact
different analysis of the impact is what will help determine if the
concept succeeds or fails.

I would consider IW10 ready for WGLC.

-Joseph

---

From: Joe Touch <[email-masked]>
Date: Mon, 02 Apr 2012 15:10:24 -0700

> I assume the contention is with the word "all"?

All should have settable IWs.

The objection is to the claim that the appropriate default is 10.

This is inconsistent with the document's own assertion in section 12 
(the first sentence).

> interested in the concept (in this case the author argues "everyone").

The intro is in direct conflict with the recommendations in sec 12.

> concept succeeds or fails.

The key here is that an experiment involves:

	- collecting data
	- reporting data
	- analyzing results

What data is relevant to collect?

Where is that data reported?

What is the expected outcome, i.e., predict some alternate results and 
say what would happen.

Without these, it's not an experiment.

Joe

---

From: Mark Allman <[email-masked]>
Date: Mon, 02 Apr 2012 22:09:30 -0400

> IMO, experimental RFCs ought to require an explanation of the
> experiment expected.

I have made such comments sometimes.  But, I don't think IW10 needs
that.  I think the docs that need to sketch an experiment---at least on
the mailing list---are those for which the experiment isn't obvious.  It
seems pretty obvious what an IW10 experiment would try to get at.  Hell,
the WG has been looking at experiments involving IW10 for a long time
now. 

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Apr 2012 08:49:15 -0700

> the WG has been looking at experiments involving IW10 for a long time

FWIW, I'm talking about:

- how does an individual user know whether this is good or bad, and when to start/stop participating in the experiment?

- how will the IETF community gather some of that information?

If the argument is "try it" as an experiment, then the mere lack of explicit reports to the contrary will be taken as evidence it's safe (as per many "it's been deployed, so it's safe" arguments in this group in the past). That doesn't cut it.

I don't expect a scientist-level experiment, but at least a way for users to know when to play and when not, and a way for the community to have POSITIVE information (rather than the lack of negative) is needed here.

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 03 Apr 2012 12:27:00 -0400

> - how does an individual user know whether this is good or bad, and
>   when to start/stop participating in the experiment? 

They won't.

Even if you write something down in an RFC.

> - how will the IETF community gather some of that information?

Same way we have previously done when we advance things.  We look at the
available evidence and decide.

My vote: The experiment is obvious.  The document is fine without
sketching out experiments.

allman

---

From: Andre Oppermann <[email-masked]>
Date: Tue, 03 Apr 2012 19:04:51 +0200

> I assume the contention is with the word "all"?

I'm very uneasy with arbitrary user-settable numeric IW parameters.

Half-knowledge abounds in user-circles and I see too many users and
sysadmins randomly cranking up every possible network related value
under the assumption that it makes it "faster" and "better".  l33t

With arbitrary IW values this backfires in a big and very non-obvious
way.  I'm all for letting people shoot into their own foot, however
in this case they are into shooting everbody else's foot as well without
being aware of it.  Upon that at least partial congestion collapse follows.
I can already hear the ringing of 1982 calling the phone booth down the road.

The Internet and TCP only survives (and survived) because of the
cooperative restraint of a very large majority of the participants.
If more than just a few give up the restraint we have the tragedy
of the commons again.  This we supposedly learned early in the 80's
after some troublesome times with little goodput.  Lets not break it
too easily again.

-- 
Andre

---

From: Martin Röhricht <[email-masked]>
Date: Wed, 04 Apr 2012 09:19:48 +0200

Hi Joe,

On 02.04.2012 20:43 Joe Touch wrote:
> If, later, the specification becomes popular (or proves that it works
> well), it can be re-issued as a standards-track RFC.

just out of curiosity: has that ever happened or do you know of any RFCs
that moved from experimental to standards track?

Martin

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 4 Apr 2012 09:25:56 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Martin Röhricht
> Sent: Wednesday, April 04, 2012 9:20 AM
> To: Joe Touch
> Cc: tcpm IETF list
> Subject: Re: [tcpm] IW10 & queuebloat
> 
> Hi Joe,
> 
> just out of curiosity: has that ever happened or do you know 
> of any RFCs that moved from experimental to standards track?

RFC 4138 -> RFC 5682

Michael

---

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 4 Apr 2012 07:26:22 +0000

Hi Martin,

yes: F-RTO.

Regards
Alex

________________________________________
Von: [email-masked] [[email-masked]]&quot; im Auftrag von &quot;Martin Röhricht [[email-masked]]
Gesendet: Mittwoch, 4. April 2012 09:19
An: Joe Touch
Cc: tcpm IETF list
Betreff: Re: [tcpm] IW10 & queuebloat

Hi Joe,

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 04 Apr 2012 07:46:56 -0400

> just out of curiosity: has that ever happened or do you know of any
> RFCs that moved from experimental to standards track?

It happened the last time we increased the initial window.  RFC 2414 is
the experimental version.  That became RFC 3390 which is PS version.
The initial window from 3390 was then rolled into RFC 5681 which is a
draft standard.

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 04 Apr 2012 07:13:55 -0700

Others answered with a few examples. There may be more. Regardless of 
how many or few, that's a viable - and appropriate - path.

Joe

---

From: Joseph Ishac <[email-masked]>
Date: Wed, 4 Apr 2012 18:58:01 -0400

> This is inconsistent with the document's own assertion in section 12 

I think there is a distinction between "enabling this option in general"
(Section 12) and "if you enable this option, we think a good value is
10" (Intro, Par 5)  which is how the two sentences read to me.

Perhaps to better clarify, the line in the into should reference the
appropriate sections of the text that support those statements?  I
suggest paragraph 5 of the intro tweaked to something like:

"We recommend that all TCP implementations have a settable TCP IW
parameter as long as there is a reasonable effort to monitor for
possible interactions with other Internet applications and services as
described in Section 12.  Furthermore, Section 10 details why 10
segments may be an appropriate value for this parameter, and while that
value may continue to rise in the future, this document does not include
any supporting evidence for values of IW larger than 10."

> Without these, it's not an experiment.

I understand those are important parts of experimenting, and the draft
already mentions some metrics of interest and cites more detailed
experiments, which is more than sufficient.  "Where is that data
reported?" sounds like you are suggesting that the draft needs to spell
out how to "report" findings, and I disagree.  The community has avenues
for that including the mailing list.

-Joseph

---

From: Martin Röhricht <[email-masked]>
Date: Thu, 05 Apr 2012 09:12:00 +0200

Hi,

thanks for the examples. Sure, this is an appropriate way as long as it
is used. :-) I was just not aware of any RFCs to which that happened
within the last years.

Martin

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 05 Apr 2012 08:15:11 +0100

I agree to making the experiments clearer at the start:
- Safety of the method for TCP
- Safety of the method for other Internet traffic
- Selection of suitable fall-back methods, when need.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Apr 2012 11:34:15 -0700

If you want a current example, MPTCP is in the process of that excursion 
*as we speak* (I think it's WAY premature, but they're trying).

Joe

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Apr 2012 21:27:47 +0200

On Apr 5, 2012, at 09:12, Martin Röhricht wrote:

> I was just not aware of any RFCs to which that happened
> within the last years.

Two off the top of my head (and transport protocols to boot):

RFC 3941 (exp, Nov 2004) -> RFC 5401 (stds track, Nov 2008)
RFC 3940 (exp, Nov 2004) -> RFC 5740 (stds track, Nov 2009)

(RFC 5740 is also my personal record of maturation time, resulting from work I started to do around 1993.  But that's a long story...)

Grüße, Carsten