Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Daniel W. McRobb
  • Date: Wed Aug 07 18:19:16 1996
  • Company: ANS
  • Location: ANS Network Services, Ann Arbor, MI
  • Position: Staff Engineer

> 
> In message <2.2.32.19960806173812.00711b8c@mail.cts.com>, "Kent W. England" wri
> tes:
> > NANOG Folks;
> > 
> [ ... 
> > 
> > Now, is there more data to bolster or refute these conclusions? I've done
> > what I can with what I've found, but there just isn't much data to go on
> > anymore. But I think it is pretty consistent with the view that a lot of the
> > traffic is WWW TCP sessions of a few kilobytes. Would you agree? Would path
> > MTU discovery help or could we all just informally set the Internet default
> > MTU up to 1500 bytes [as John Hawkinson suggested on big-internet] and
> > suffer a few fragmented slow speed links. Are most PPP MTUs set at the
> > default 1500 or no?
> > 
> > --Kent
> 
> 
> Hi there Kent,
> 
> Persistant connections is a prominant feature of HTTP 1.1, now in
> draft.  Maybe someone who follows that WG can comment on its progress.
> If on average there are 2-3 inline images per page (reasonable
> estimate IMO, though I have no data to back this up), then the average
> transfer size will increase.  I've heard (verbal at NANOG) that
> Netscape has promised to support persistant connections, with the only
> caveat that they will open one connection for the page itself and
> another for all the inlines so they can start rendering the first
> inline while a long page is being read.  They can probably avoid this
> for short pages.  This could lead to a significant improvement in the
> ability of the Internet traffic to respond to low levels of packet
> drop and make good use of TCP congestion control, plus it will
> significantly improve the speed of transfer on uncongested paths where
> currently TCP never gets out of the initial slow start.
> 
> Curtis

I did some analysis of the FIX-West traces a while back and posted it to
the nlanr mailing list.  It's been so long that I don't remember what I
posted, but I seem to recall trying to make a judgement as to how many
packets we'd eliminate with a mass migration to HTTP 1.1 and/or HTTP
with T/TCP.  I recall a figure around 14%, but that's just from memory.

I just looked at the ARTS data for July 1996 for traffic we're receiving
at the Sprint NAP, and the average packet size for WWW traffic was 231
bytes.  Also, HTTP accounts for about 73% of the traffic we receive from
peers at the Sprint NAP.

I generated an incomplete plot of HTTP traffic growth (as a percentage
of total packet traffic) for the ISMA workshop, and it's on the nlanr
WWW site at the bottom of:

   http://www.nlanr.net/NA/Learn/daily.html

I've been meaning to give a more recent plot to kc to place there, but
haven't gotten around to it yet.  The zero values for 05/95 and 08/95
are just due to me not having time to pull those months from tape.

At any rate, in our case, a significant reduction in HTTP traffic (by
caches, HTTP 1.1, T/TCP, whatever) would be nice since HTTP represents a
large chunk of our backbone traffic.

Daniel
~~~~~~
- - - - - - - - - - - - - - - - -




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.