Re: Comparing an old flow snapshot with some packet size data

"Kent W. England" <kwe@6sigmanets.com> Tue, 06 August 1996 22:02 UTC

Received: from ietf.org by ietf.org id aa23119; 6 Aug 96 18:02 EDT
Received: from cnri by ietf.org id aa23115; 6 Aug 96 18:02 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa15913; 6 Aug 96 18:02 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA10828; Wed, 7 Aug 1996 07:56:05 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA10798; Wed, 7 Aug 1996 07:40:14 +1000
Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA30748; Wed, 7 Aug 1996 07:40:12 +1000 (from kwe@6SigmaNets.com)
Received: from netguru.cts.com (kent-england.pbi.net [206.13.1.58]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id OAA29055; Tue, 6 Aug 1996 14:40:09 -0700
Message-Id: <2.2.32.19960806214515.006ffa20@mail.cts.com>
X-Sender: kwe@mail.cts.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 06 Aug 1996 14:45:15 -0700
To: Greg Minshall <minshall@ipsilon.com>, "Kent W. England" <kwe@6sigmanets.com>
Sender: ietf-archive-request@ietf.org
From: "Kent W. England" <kwe@6sigmanets.com>
Subject: Re: Comparing an old flow snapshot with some packet size data
Cc: big-internet@munnari.oz.au
Precedence: bulk

At 12:53 PM 8/6/96 -0700, Greg Minshall wrote:
>Kent,
>
>Having cogitated a bit...
>
My thanks.
>
>I think you are saying that if TCP sent 1460 bytes in the first [data] packet, 
>then lots of transfers would only have one data packet, but that since it is 
>using 512 bytes, transfers take 3 (say) data packets, so slow start kicks in 
>and it takes 2 RTTs to transfer that data.

Yes, but to be fair this is what Simon Spero first said in his paper on HTTP.
< http://sunsite.unc.edu/mdma-release/http-prob.html >
>
>I think that is probably true, though if transfer sizes are, say, 3000 bytes 
>(which you mentioned), then even with 1460, "slow start" imposes a 2.x RTT 
>"penalty".  On the other hand, that "penalty" is there, of course, to keep the 
>net alive.
>
>> Would there be any improvement if hosts used path MTU discovery, or would it
>> add up to about the same thing? I'm not sure whether you can do path MTU
>> discovery at the same time you are starting a TCP session or whether, as is
>> more likely, it is a separate process and uses an RTT or more before
>> starting the TCP session.
>
>(I guess i'm not totally sure what "constituency" you represent in this, in 
>the sense of i.e., PPP users at the end of 28.8 links, or network providers 
>trying to figure out how to provision, or corporate intXXnet builders, etc.  
>For example, when you say "improvement", improvement for *whom*?)
>

I was only thinking of "users", whoever they are (including me). But the GOP 
convention is happening in my hometown next week and if anyone on this list 
would be my constituency, I'll put myself down against ol' Bob as the
candidate! 
A vote for me is a vote for path MTU! :-)

Seriously, if RTTs are the problem then this issue holds for 28.8 PPP users as
well as corporate users. In fact, this problem came home to me in spades when
I upgraded my residential access from 28.8 to 112.5 (hardware, you know) ISDN
and found little performance improvement on many pages.

>You can do path MTU "at the same time" you are starting a TCP session.  *I* 
>think it would help.
>
>Systems are also free [encouraged! -- see http://info.internet.isi.edu:80/in-no
>tes/rfc/files/rfc1191.txt] to "remember" previous path MTU values to various 
>destinations to try to "optimize" the path MTU start up time; so, it would be 
>much better if each of the web pages downloads for images from a given site 
>didn't have to individually "learn" the path MTU, but could "share" that 
>knowledge from the first download.  Unfortunately, this involves a bit of 
>thinking and coding (neither of which i've done!), and so isn't totally 
>straightforward.
>
>Greg
>
>
Of course this is also addressed by HTTPng. Can we hold our breath that long?

See < http://www.w3.org/pub/WWW/Protocols/HTTP-NG/Overview.html >

--Kent