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
