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

Greg Minshall <minshall@ipsilon.com> Tue, 06 August 1996 20:05 UTC

Received: from ietf.org by ietf.org id aa20745; 6 Aug 96 16:05 EDT
Received: from cnri by ietf.org id aa20741; 6 Aug 96 16:05 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa13901; 6 Aug 96 16:04 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA10696; Wed, 7 Aug 1996 05:55:59 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA10667; Wed, 7 Aug 1996 05:53:55 +1000
Received: from mailhost.ipsilon.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA14228; Wed, 7 Aug 1996 05:53:54 +1000 (from minshall@Ipsilon.COM)
Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id MAA27842; Tue, 6 Aug 1996 12:53:52 -0700
Message-Id: <199608061953.MAA27842@mailhost.Ipsilon.COM>
X-Mailer: exmh version 1.6.4 10/10/95
To: "Kent W. England" <kwe@6sigmanets.com>
Cc: big-internet@munnari.oz.au
Subject: Re: Comparing an old flow snapshot with some packet size data
In-Reply-To: Your message of "Mon, 05 Aug 1996 17:08:36 PDT." <2.2.32.19960806000836.00d194b8@mail.cts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 06 Aug 1996 12:53:51 -0700
Sender: ietf-archive-request@ietf.org
From: Greg Minshall <minshall@ipsilon.com>
Precedence: bulk

Kent,

Having cogitated a bit...

> All in all, these three data sources (Claffy/Scharf, Doran, Spero) seem
> relatively consistent. An overwhelming amount of the flows in the Internet
> seem to be small file transfers, the TCP payload for this traffic is mostly
> <=512 bytes, when it could easily be <=1460 bytes. And slow start adds at
> least one extra RTT to each transfer that might be avoided if the payloads
> were 1460 instead of 512.

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.

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*?)

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