Subject: [tcpm] informal poll about initial cwnd

From: Mark Allman <[email-masked]>
Date: Thu, 06 Jan 2011 13:19:46 -0500

Given that there are three proposals put down in I-D form in some matter
of baked-ness I am wondering if there is any sort of clear WG preference
on the *approach* to changing the initial window.  So, putting aside the
particulars for a moment and just thinking about the approach I'd like
to take a quick, informal, absolutely non-binding in any way (obviously)
poll to take the WG's pulse.

So, do you prefer ...

(A) To increase the current static IW definition to a single updated
    value.

    (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am
    explicitly not asking about IW=10, just IW=some_X.)

(B) To increase the current static IW definition with a schedule of IW
    updates to play out over some period of time.

    (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I am
    explicitly not asking if you like the given schedule.)

(C) To define a procedure for hosts to figure out how to adapt their IW
    over time.

    (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am
    explicitly not asking if you buy the particulars of this, just the
    overall approach.)

(D) The current IW seems OK and I haven't seen a good reason to think it
    needs changed.

Thanks!

allman

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Thu, 6 Jan 2011 12:34:50 -0600

I've been thinking we might wind up with some set of A/B/C in conjunction.  It seems like they don't have to be mutually exclusive since different hosts could implement different Experimenal policies, as long as each is felt to be reasonable for Experimental.  Of course, it would probably be better to have one Proposed Standard.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mark Allman [[email-masked]]
Sent: Thursday, January 06, 2011 1:19 PM
To: [email-masked]
Subject: [tcpm] informal poll about initial cwnd

So, do you prefer ...

Thanks!

allman

---

From: Michael Welzl <[email-masked]>
Date: Thu, 6 Jan 2011 19:45:59 +0100

>    explicitly not asking if you buy the particulars of this, just the

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 10:48:43 -0800

My preferences, in order:

> (D) The current IW seems OK and I haven't seen a good reason to think
> it needs changed.

> (C) To define a procedure for hosts to figure out how to adapt their
> IW over time.

More specifically, I'd say C should be:
	to define a procedure based on feedback that increases the IW
	only where it measurably doesn't do harm

If my draft doesn't do that, someone can write one that does.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Thu, 6 Jan 2011 12:58:32 -0800

On Thu, Jan 6, 2011 at 10:34 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE
CORP] <[email-masked]> wrote:

> I've been thinking we might wind up with some set of A/B/C in conjunction.
>  It seems like they don't have to be mutually exclusive since different
> hosts could implement different Experimenal policies, as long as each is
> felt to be reasonable for Experimental.  Of course, it would probably be
> better to have one Proposed Standard.
>

Agreed 100%.

To me it's an obvious choice if C) proves to be feasible, i.e., translating
into say,
no more than 50 lines of simple code, not inflicting any noticeable
performance
penalty, without any external dependencies, and actually works as expected
(i.e., attaining its goals of allowing a timely growth path for IW without
causing
significant more global congestions) then who would say no to that magic?

But it is still a long IF IMO. (Note I'm not saying I don't believe C) will
work.
It's just I still have my doubt.)

Also it seems to me a combination of A) and B) may serve those hosts that
just
can't do C) (e.g., either w/o persistent storage or having one but not
usable
for C)'s purpose).

Jerry

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

---

From: John Heffner <[email-masked]>
Date: Thu, 6 Jan 2011 16:20:16 -0500

As a firm believer in simplicity where possible, I have strong
reservations on (C).

If approach (D) is chosen, implementors will very soon start making
their own choices for non-standard IW.  It's not clear to me this is a
bad thing, but it could be.

  -John

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 6 Jan 2011 22:13:32 -0000

Certain implementors have already choosen, if the points in Dave's presentation are adopted to main linux, for all I know.

For the record, given the simplicity I would prefer (A) for low-end / "closed" environment applications, and (C) for high-volume + public deployments (ie. Home users/corporate intranets could do with a single updated IW; operators who could have an impact on a larger (global) scale to the public internet, should go with (C) - adding some accountability, basically).

Regards,
   Richard

> -----Original Message-----
> From: John Heffner [mailto:[email-masked]]
> Sent: Donnerstag, 06. Jänner 2011 22:20
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] informal poll about initial cwnd
> 
> IW
> it

---

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 7 Jan 2011 00:04:03 +0100

I would allow (A) because of its simplicity, but the same I-D should
also mandate implementors to carefully monitor the impact and strongly
recommend to revert to IW3 if any harm is observed. As one potential
(recommended?) solution for this, it could propose a procedure somehow
along the lines of (C).

IMHO implementors MUST really carefully monitor the impact of an
increased IW, in particular for large-scale deployments. This can be
done by a procedure similar to draft-touch-tcpm-automatic-iw-00, but
probably also by other control loops, e. g., by regularly monitoring
transaction times at application level. The IETF should describe one
application-agnostic way of monitoring the impact of a larger IW, but
also allow implementors to come up with other solutions.

Michael

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Allman
> Sent: Thursday, January 06, 2011 7:20 PM
> To: [email-masked]
> Given that there are three proposals put down in I-D form in 
> some matter of baked-ness I am wondering if there is any sort 
> of clear WG preference on the *approach* to changing the 
> initial window.  So, putting aside the particulars for a 
> moment and just thinking about the approach I'd like to take 
> a quick, informal, absolutely non-binding in any way 
> (obviously) poll to take the WG's pulse.
> 
> So, do you prefer ...
> 
>     (Current proposal: 
> draft-allman-tcpm-bump-initcwnd-00.txt, but I am

---

From: "Biswas, Anumita" <[email-masked]>
Date: Thu, 6 Jan 2011 17:22:36 -0800

Fwiw, I prefer us going with (C) as well. A static value always has the problem that it has to be revisited frequently and there is no guarantee that it is correct for a given environment. Some implementations may be more aggressive than others in setting the static value by not following the standard spec as well.

As we have seen from the many discussions on tcpm on IW, the problem is complex to solve. So I am not sure if we can reach consensus quickly on the algorithm to increase/decrease IW. In the spirit of making forward progress, perhaps it makes sense to increase the IW "somewhat" statically (option A) and continue to work on the dynamic algorithm proposal.

Also the loss distribution across all connections on a host is not uniform when that host has connections to destinations on widely varying networks (LANs and WANs). In a perfect world, path heuristics of each connection should play into the algorithm (RTT, delay, local/remote destination) so that the least lossy connections get the highest IW versus the most lossy connections getting lower IWs.

Cheers,
Anumita.

-----Original Message-----
From: Scheffenegger, Richard 
Sent: Thursday, January 06, 2011 2:14 PM
To: John Heffner; [email-masked]
Cc: [email-masked]
Subject: Re: [tcpm] informal poll about initial cwnd

Regards,
   Richard

---

From: Murari Sridharan <[email-masked]>
Date: Fri, 7 Jan 2011 02:45:12 +0000

Orders of magnitude jump in bandwidth, with majortiy of link upgrades take time so i prefer a simple approach, its been a while since we updated Cwnd and there is evidence of larger windows along the values proposed so i'd stongly prefer A. However hosts MUST monitor loss patterns and revert to older defaults and cache these settubgs per-network. We already cache per-network properties so it should be trivial to do. There are things i like in (B) which could be folded into a proposal recommending A. Everything else is unnecessarily complex and is likely to be error prone. 

Thanks
Murari 
________________________________________
From: [email-masked] [[email-masked]] on behalf of Mark Allman [[email-masked]]
Sent: Thursday, January 06, 2011 10:19 AM
To: [email-masked]
Subject: [tcpm] informal poll about initial cwnd

So, do you prefer ...

Thanks!

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Jan 2011 20:57:39 -0800

On 1/6/2011 6:45 PM, Murari Sridharan wrote:
> Orders of magnitude jump in bandwidth, with majortiy of link
> upgrades take time so i prefer a simple approach, its been a while
> since we updated Cwnd and there is evidence of larger windows along
> the values proposed so i'd stongly prefer A.

OK, so you're for (A).

> However hosts MUST
> monitor loss patterns and revert to older defaults and cache these
> settubgs per-network.

That's basically (C) - understanding that the particular algorithm is 
subject to revision.

 > We already cache per-network properties so it
> should be trivial to do. There are things i like in (B) which could
> be folded into a proposal recommending A.

That's now (B)?

I'm confused as to what your response supports, FWIW.

Joe

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 07 Jan 2011 10:12:26 +0100

Hi,

as many of us I believe that (d) is not a solution. If we miss the
opportunity to treat the IW now, implementers will do it for us...
(and without us)

In general I prefer (C), but besides the question on how we can
increase the IW (C or A), I see another big problem: TIME.

So, who is willing
  - to write I-D (C) 
  - to implement and demonstrate (Cs) (adress Jerry's concerns)

I we go the c-way, we really need an strict time schedule.

Alex

> Fwiw, I prefer us going with (C) as well. A static value always has the problem that it has to be revisited frequently and there is no guarantee that it is correct for a given environment. Some imp…

100% agreed.

> As we have seen from the many discussions on tcpm on IW, the problem is complex to solve. So I am not sure if we can reach consensus quickly on the algorithm to increase/decrease IW. In the spirit…

I like this idea.

> Anumita.

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 07 Jan 2011 18:21:10 +0800

On 01/ 7/11 02:34 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> I've been thinking we might wind up with some set of A/B/C in
> conjunction.  It seems like they don't have to be mutually exclusive
> since different hosts could implement different Experimenal policies,
> as long as each is felt to be reasonable for Experimental.  Of
> course, it would probably be better to have one Proposed Standard.

Agreed.  I don't think one size fits all.  A procedure to find out
the right value in one site may not be applicable to another site.
It seems that folks are too eager in finding a "universal" solution
when one may not exist.  If (C) is rephrased as

Define some guidelines which a site MAY follow to determine the
right IW.

I'd vote for that.  Otherwise, I'd vote for (A) and wait for the
next time this issue comes up again :-)  This is not (B) since
I cannot see the future so I don't believe a schedule of updates
can be made.

> From: [email-masked]
> [[email-masked]] On Behalf Of Mark Allman [[email-masked]]
> Sent: Thursday, January 06, 2011 1:19 PM To: [email-masked] Subject:
> [tcpm] informal poll about initial cwnd
>
> Given that there are three proposals put down in I-D form in some
> matter of baked-ness I am wondering if there is any sort of clear WG
> preference on the *approach* to changing the initial window.  So,
> putting aside the particulars for a moment and just thinking about
> the approach I'd like to take a quick, informal, absolutely
> non-binding in any way (obviously) poll to take the WG's pulse.
>
> So, do you prefer ...
>
> (B) To increase the current static IW definition with a schedule of
> IW updates to play out over some period of time.
>
> allman _______________________________________________ tcpm mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/tcpm

-- 

					K. Poon.
					[email-masked]

---

From: "t.petch" <[email-masked]>
Date: Fri, 7 Jan 2011 11:13:36 +0100

A) for me; it is simple.

C) is great for sophisiticated implementors with a sophisticated infrastructure
to suppport the implementation, which I think will often not be the case.
Perhaps
one for an xxxRG not a WG.

D) I do not believe will ever happen.

Tom Petch

---

From: rick jones <[email-masked]>
Date: Fri, 07 Jan 2011 08:23:20 -0800

>    explicitly not asking about IW=10, just IW=some_X.)

A.

Paint it yellow and ship it. (*)

rick jones

(*) http://greateasyjet.com/funny/paint_yellow.html

http://homepage.mac.com/perfgeek

---

From: Tim Hartrick <[email-masked]>
Date: Fri, 07 Jan 2011 10:40:29 -0700

All,

+1.

Tim Hartrick

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sun, 16 Jan 2011 20:58:18 -0000

+1 (reasons mentioned earlier).

Richard

> From: Tim Hartrick [mailto:[email-masked]]
> Sent: Freitag, 07. Jänner 2011 18:40
> To: rick jones
> Cc: [email-masked]; [email-masked]