MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha1; boundary=Apple-Mail-2-288377491
From: Alexander Zimmermann <alexander.zimmermann@comsys.rwth-aachen.de>
In-reply-to: <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com>
Date: Wed, 17 Nov 2010 08:58:26 +0100
Content-transfer-encoding: 7bit
Message-id: <686EBD23-7B65-455F-9348-196BBFD88ECD@comsys.rwth-aachen.de>
References: <20101110152857.GA5094@hell>
 <804D02FE-39AF-4437-BB15-C2247842E120@mac.com> <20101110170017.GF5094@hell>
 <97C75EA8-6CC7-444C-A19D-370148B81918@mac.com> <20101110174056.GH5094@hell>
 <AANLkTim7g=XqfSMHpHVbw1qqPOL-oNApt2i_2RCt0SCi@mail.gmail.com>
 <AD2BFE84-CA5B-4CDC-8822-1FC2713E3AE0@cisco.com>
 <alpine.DEB.2.00.1011161345170.11898@wel-95.cs.helsinki.fi>
 <E798B9A8-29BB-425B-B0C2-2B2735C49948@cisco.com>
 <5FDC413D5FA246468C200652D63E627A0B7BD0DF@LDCMVEXC1-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
Cc: tcpm <tcpm@ietf.org>,
 "david.borman@windriver.com Borman" <david.borman@windriver.com>
Subject: Re: [tcpm] [Tmrg]  Increasing the Initial Window - Notes
Precedence: list

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2-288377491
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1

Hi Richard,

exactly, this is the point!

IMO, two things are crystal clear:

1. We have to touch/increase the IW
2. We have to do it now

Also, IMO he have a rough consensus on these two points.

What I like two see now, or discuss now, is a strategy how we can =
progress.

Mark proposed something, but what are thoughts from the document author/
other group members/chairs/AD on this point?

Alex

Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard:

>=20
> Group,
>=20
> Just one additional data point: Obviously, there are already =
applications in the wild, that use persistent connections and disable =
the slow-start-restart mechanism on these sessions. The expectations of =
the programmers making use of these socket options is to reduce the =
latency for their appliaction... In effect, these Apps seem use IW=3D44 =
(and hurting themselves more than anybody else).
>=20
> See "Profiling Network Performance in Multi-Tier Data Center =
Applications", Section 6.1, "cwnd failing to prevent sudden bursts", =
http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
>=20
>=20
> IMHO this is evidence that some action in this space is absolutely =
needed (even if it is "only" strong advice to apps programmers), or =
there will be even more proliferation of clumsy workarounds that are =
even less well understood and investigated than IW10 already is. Keeping =
IW3 "forever" may be more problematic than addressing emerging =
application needs with well-tested transport-layer approaches...
>=20
>=20
> Richard Scheffenegger
>=20
>=20
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]=20
>> Sent: Dienstag, 16. November 2010 15:10
>> To: "Ilpo J=E4rvinen"
>> Cc: tcpm; tmrg
>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes
>>=20
>>=20
>> On Nov 16, 2010, at 10:01 PM, Ilpo J=E4rvinen wrote:
>>=20
>>> On Tue, 16 Nov 2010, Fred Baker wrote:
>>>=20
>>>> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>>>>=20
>>>>> I wonder what factors will argue that the initial quantum=20
>> can't be changed?
>>>>> Someone has argued in the past IW10 effectively "disable=20
>> CC algorithm".
>>>>> But haven't we already done that years ago when moving up=20
>> IW from 1=20
>>>>> to 3 if one insisted then that the initial quantum must be 1?
>>>>=20
>>>> Actually, no. I may be the person who said that this effectively=20
>>>> disables congestion control in the average case; my reason=20
>> for saying=20
>>>> that is that per what little data I have, the average TCP=20
>> transfer is=20
>>>> on the order of 15K bytes, which is about ten 1460 byte segments.
>>>=20
>>> It only "disables" it if there was no congestion to control in the=20=

>>> first place.
>>=20
>> How do you turn off something that's not on?
>>=20
>> I refer to this as in the average case turning off congestion=20
>> control because the transmission requires ten data packets=20
>> and they all get sent in a single burst. There is no=20
>> congestion control, with IW=3D10, in the case of the=20
>> average-sized (which is actually gar above the median-sized)=20
>> file transfer.
>>=20
>>> Could you on your behalf answer how does IW=3D3 affect=20
>> parallel sessions=20
>>> on the same kind of environment? ...I've done research on this (and=20=

>>> Jerry has
>>> too) and I know that the answer is not an intuitive one. Then we=20
>>> changed to IW10 in the same environment and observe no (consistent)=20=

>>> change. The results are driven by problems already with IW3 so IW10=20=

>>> won't make it any worse or the effect is just too small to=20
>> be measured=20
>>> among the other troubles that happen.
>>=20
>> That may be true. I have asked to see data describing the=20
>> impact. I haven't seen the data. Maybe I missed something?
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// 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: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-2-288377491
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEUEARECAAYFAkzjiyIACgkQdyiq39b9uS7RaACgkewlY6c17IYn7aJ9GXYJK0IG
H6kAmIN1QTU3jOzDyvz+EVohn7W+5sM=
=M+Wo
-----END PGP SIGNATURE-----

--Apple-Mail-2-288377491--