Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt

rick jones <perfgeek@mac.com> Wed, 10 March 2010 16:02 UTC

Return-Path: <perfgeek@mac.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00093A6B51 for <tcpm@core3.amsl.com>; Wed, 10 Mar 2010 08:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vV5SmgAu+yb for <tcpm@core3.amsl.com>; Wed, 10 Mar 2010 08:02:09 -0800 (PST)
Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by core3.amsl.com (Postfix) with ESMTP id C317D3A6B3B for <tcpm@ietf.org>; Wed, 10 Mar 2010 08:02:09 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ2008WKPVLA180@asmtp013.mac.com> for tcpm@ietf.org; Wed, 10 Mar 2010 08:02:10 -0800 (PST)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003100129
Message-id: <60D1C7D7-6456-440A-BF2B-33C0D75ED7BE@mac.com>
From: rick jones <perfgeek@mac.com>
To: Jerry Chu <hkchu@google.com>
In-reply-to: <d1c2719f1003092207g7c6bf2d3g302bb9b9f78c3eb0@mail.gmail.com>
Date: Wed, 10 Mar 2010 08:02:08 -0800
References: <d1c2719f1003021450mf70e338r8818fa4634e0f2e@mail.gmail.com> <d1c2719f1003081635r4299dfd8u174a5e797aae0c2e@mail.gmail.com> <FF762DF3-085C-4EB5-946B-B496842AC839@cs.ucl.ac.uk> <d1c2719f1003091125r7514cb73le8376f5851e5f5f5@mail.gmail.com> <4A655CBC-A0C4-48AF-B1D9-FB991051A08C@mac.com> <d1c2719f1003092207g7c6bf2d3g302bb9b9f78c3eb0@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk
Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2010 16:02:10 -0000

On Mar 9, 2010, at 10:07 PM, Jerry Chu wrote:

> On Tue, Mar 9, 2010 at 7:35 PM, rick jones <perfgeek@mac.com> wrote:
>> Is there a way to tease-out what the "typical" cwnd becomes in both  
>> the base
>> and exp cases?  Say from those services with larger responses? Does  
>> it
>> become 8*MSS?  12*MSS etc?  That would help show how "close to the  
>> edge" 10
>> segments might be yes?
>
> Yes it's certainly doable but one problem with most of the services is
> that there are fewer larger responses, interleaved with many smaller  
> responses, and the vast
> majority of HTTP connections don't persist long enough to allow cwnd/ 
> ssthresh to
> converge in a more meaningful way.
>
> In order to perform a more detailed analysis on some network  
> properties, we are
> thinking about instrumenting a bulk data service like Youtube to  
> avoid the above
> mentioned problem, as described in section 11.2 of the I-D. The idea
> is to monitor some key TCP parameters at various stage of a  
> connection (and Linux kernel
> already conveniently provide "TCP_INFO" socket option). But before  
> we proceed
> we like to first hear suggestions from the lists. This is because any
> large scale experiment can be very time/resource consuming. In this  
> case we'll likely have
> to set up a different logging system for Youtube, may even have to
> build and deploy a different kernel with the right instrumentation  
> (TCP_INFO may not provide all
> the info we'll need) to many thousand machines..., etc.

I probably would simply start with logging the cwnd, ssthresh,  
retransmission count and bytes transferred at the end of a  
connection.  Without having any firm basis to support it, I suspect  
that cwnd at the end of the connection is "good enough" and one  
doesn't need max cwnd.

>> WRT the retransmissions (table 7 in the paper), is it safe to ass-u- 
>> me that
>> the increase in retransmissions means a corresponding increase in  
>> "Internet"
>> bandwidth consumed to deliver the given quantity of data?
>
> I don't see why not. (Am I missing something?)

Probably not - I was simply wondering if I might have been - it does  
call for chaining an assumption or two about the distribution of the  
size of the retransmitted segments versus the whole along with the  
acceptance that 99 times out of 10 the losses are in the last mile.

rick jones
Wisdom teeth are impacted, people are affected by the effects of events