GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: IP and TCP checksums [7:80346] posted 12/05/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


garrett.allen@xxxxxxxxxxx wrote:
> 
> payload fragmentation and reassembly?

As in a bug in the software that reassembles the fragments??


> 
> thanks.
> > I hijacked another message and am starting a new thread.
> > 
> > Howard said something about a new version of TCPv6 to go with
> IPv6 that will
> > have the capability to checksum the 128-bit IPv6 addresses,
> if I understood
> > him right.
> > 
> > My students hounded me the other day about the stupidiy of IP
> or TCP even
> > having a checksum. It's interesting teaching computer science
> students. They
> > haven't gotten very good at configuring routers and switches,
> but they are
> > good at thinking about optimization, etc.
> > 
> > Anyway, how important is it for upper layers to checksum?
> What does it
> > protect against? Software bugs, RAM parity errors? The MAC
> layer, of course,
> > would discard a frame that got damaged in transit so the
> upper layers don't
> > protect against that.
> > 
> > If I remember correctly, IPv6 doens't actually have a
> checksum, which the
> > students liked hearing. :-)
> > 
> > Just got me thinking.
> > 
> > Priscilla
> > 
> > Howard C. Berkowitz wrote:
> > > 
> > > At 1:16 AM +0000 12/5/03, Priscilla Oppenheimer wrote:
> 
> > > >This is a strange one. It sounds sort of like the AIX has a
> > > poor
> > > >implementation of TCP, which doesn't adjust well to the low
> > > bandwidth. This
> > > >would be difficult to troubleshoot and fix. What more can
> you
> > > tell us about
> > > >the AIX? Software version, hardware, amount of RAM, CPU?
> Maybe
> > > it is a
> > > >clunker.
> > > 
> > > Since at least part of the problem appears to be with TCP,
> one
> > > of the
> > > first things I'm wondering about is whether the AIX
> > > implementation
> > > tries to avoid slow start to optimize throughput. Current
> > > research is
> > > suggesting that a larger starting window may be reasonable
> in
> > > some
> > > networks, but that certainly can't be generalized to all
> > > networks.
> > > 
> > > I've run across a horrible implementation of
> large-window-start
> > > that
> > > didn't pay much attention to IP MTU, and didn't do MTU path 
> > > discovery. So, it merrily tried to send its 4K starting
> window,
> > > fragmenting everything.
> > > 
> > > I'd look closely for evidence of fragmentation, and, if you
> can
> > > get
> 
> > > it from a protocol analyzer, the host, etc., I'd want to
> know
> > > the TCP
> > > starting segment size.
> > > 
> > > >
> > > >A few comments and requests for clarifications below....
> > > >
> > > >Dave C. wrote:
> > > >>
> > > >>  We have been fighting a battle with a problem on a new
> > > network
> > > >>  that we are installing (and need to have working by
> tomorrow
> > > >>  morning).
> > > >>
> > > >>  It is a very simple network.  (At least we thought...)
> > > >>
> > > >>  Here is a diagram:                     CIR=384
> > > >>                                         Port=768
> > > >>  HOME ----------Frame-Relay Network------------SITE_A
> > > >>       CIRA=384            |
> > > >>       CIRB=768            |
> > > >>       Port=1544           |
> > > >>                           |
> > > >>                           |CIR=768
> > > >>                           |Port=1544
> > > >>                           |
> > > >>                          SITE_B
> > > >>
> > > >>  All routers at HOME, Site_A, and SITE_B have 10/half
> > > ethernet
> 
> > > >>  interfaces.  At the Home location, I have 1 AIX box,
> and a
> > > >>  Win2K Server.  The SITE_A location has an FTP server.
> > > >>
> > > >>  A description of the problem
> > > >>  ----------------------------
> > > >>
> > > >>  Users at SITE_A and SITE_B experience slow response
> from AIX
> > > >>  box at HOME.
> > > >
> > > >Slow response time in general? With all applications?
> > > >
> > > >>  FTP traffic from HOME to SITES A & B run approx.
> > > >>  1/2 of CIR for the SITE.
> > > >
> > > >This is the main problem, eh?
> > > >
> > > >When testing with FTP be sure to use a large enough file
> that
> > > TCP can start
> > > >to consume bandwidth. By default, TCP does slow start and
> > > doesn't take
> > > >advantage of the bandwidth. With short transfers it never
> gets
> > > out of slow
> > > >start.
> > > 
> > > But there are implementations that aren't slow start
> compliant.
> > > I
> > > don't remember the number, but there is an Experimental RFC 
> > > suggesting there are times that slow start is not a good
> idea.
> > > 
> 
> > > I know there were times where, working in carrier-class
> router
> > > development, I cranked up the initial window. The reason I
> did
> > > that
> > > was to speed initial BGP convergence with full tables. I
> knew
> > > that
> > > the media were high-speed, high-reliable optical, and, until
> > > BGP was
> > > operational, there wouldn't be any other traffic to congest
> the
> > > link.
> > > 
> > > In the dim past, IBM tended to take defaults to optimize for
> > > SNA over
> > > IP. I have no idea of AIX did this, but, a number of years
> ago,
> > > IBM
> > > routers did not use the default timer values in OSPF, but
> > > shortened
> > > them significantly to reduce convergence time, trading it
> off
> > > against
> > > increased OSPF bandwidth and processor load.  Of course,
> > > mismatched
> > > timers caused interoperability problems with the Cisco
> routers
> > > using
> > > the RFC-recommended defaults.  Just something to think
> about.
> > > 
> > > >
> > > >>  Traffic from each site to HOME is
> > > >>  close to CIR.  Users that FTP to and from the Win2K at
> HOME
> 
> > > >>  server experience rates close to CIR.  FTP traffic
> between
> > > >>  SITE_A and SITE_B in both directions was close to CIR
> (note:
> > > >>  There is not a PVC between Site_A and B.  Traffic has
> to go
> > > >>  from SITE A to HOME to SITE B).
> > > >
> > > >So all that sounds fine? You can't expect better than CIR?
> > > >
> > > >>
> > > >>  The frame-relay service provider does not see any
> FECN's,
> > > >>  BECN's, or DE's.  There are no physical errors or duplex
> > > >  > mismatches on any of the router or switch interfaces. 
> Show
> > > >>  frame-relay pvc at each site is clean.
> > > >>
> > > >>  A user that is not on the frame-relay network, but is
> > > behind a
> > > >>  10/half router (with T1), and still goes through all
> switch
> > > >>  infrastructure as other users, gets xfer rate TO AND
> FROM
> > > AIX
> > > >  > box of 1.3 Mbps.
> > > >
> > > >  >
> > > >>  We sniffed the FTP traffic and found MTU sizes were
> correct
> > > and
> > > >>  compared Win2K server with AIX box.
> > > >
> > > >When sniffing, was there any evidence of other traffic
> > > consuming bandwidth,
> 
> > > >taking it away from the AIX? On the other hand, that
> wouldn't
> > > just affect
> > > >the AIX...
> > > 
> > > Again while sniffing, what were the packet sizes and was
> there
> > > evidence of fragmentation?
> > > 
> > > >
> > > >>
> > > >>  On AIX box, we found that FTP and Telnet were trying to
> use
> > > >>  TCP6 insead of TCP (for version 4).  Changed to TCP and
> NO
> > > >>  CHANGE.
> > > >
> > > >What? I didn't know there even was such a thing as TCPv6.
> Or
> > > is that what
> > > >AIX calls IPv6. Sounds weird but not relevant probably
> unless
> > > it was
> > > >consuming bandwidth.
> > > 
> > > I'm not sure what this is either.  There's IETF work in
> > > progress
> > > called TCPv6, which optimizes TCP to run over IPv6 (e.g., 
> > > checksumming to reflect the longer addresses).
> > > 
> > > >
> > > >>
> > > >>  On AIX box we found TCP window size was set for 16xxx. 
> > > Win2K
> > > >>  server TCP window size was set for 65535.  We
> re-adjusted
> > > >>  window size on AIX box to 160xxx and enabled RFC1323 to
> > > support
> 
> > > >>  window size over 65535. AT THIS TIME, WE ARE NOT
> CERTAIN IF
> > > >>  THIS IMPROVED PERFORMANCE.
> > > 
> > > It's a tossup. 1323 definitely helps for fast links, and I
> > > consider
> > > it necessary at T3 rates and above. It probably doesn't
> make a
> > > lot of
> > > difference at T1 and sub-T1 rates.
> > > 
> > > I'm not convinced, however, that increasing the window is
> > > necessarily
> > > a fix, if some TCP is behaving obviously. How many
> concurrent
> > > FTP
> > > transfers are occurring?
> > > 
> > > >
> > > >Setting the window size on the AIX would help when the AIX
> is
> > > receiving
> > > >data. A larger window would cause the AIX to tell the other
> > > side to pump out
> > > >more data without stopping and waiting for an ACK.
> > > >
> > > >But to optimize the AIX sending, the other computers would
> > > have to be
> > > >tweaked for a larger receive window, which is probably not
> > > worth the effort.
> > > >
> > > >>
> > > >  > Carrier found no circuit issues.
> > > >  >
> > > 
> > > Do they ever? :-(
> > **Please support GroupStudy by purchasing from the GroupStudy
> Store:
> > http://shop.groupstudy.com
> > FAQ, list archives, and subscription info: 
> > http://www.groupstudy.com/list/cisco.html
> 
> 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=80349&t=80346
--------------------------------------------------
**Please support GroupStudy by purchasing from the GroupStudy Store:
http://shop.groupstudy.com
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html