[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Standard - No Flow Control?
Derek Atkins writes:
> Actually, 1490 might not be "low enough" for ESP overhead, so you may
> still be getting fragmentation. You might want to try reducing your MSS
> to 1480, or maybe even 1400 and trying again.
Actually, I'd go for 1400 to be certain. For ethernet,
1536-14(eth)-20(ip)-20(tcp)-24(~ esp) = ~1458. If you
have AH turned on or tunnels as well, it will
be lower than 1458, so 1400 is probably a safe
lower bound.
Mike
>
> -derek
>
> Rett_Walters@payless.com writes:
>
> > The problem does not occur when IPSec isn't in the picture, hence, doing
> > un-encrypted transmissions over the same network works fine.
> >
> > Alot of subscribers mentioned that is seems that the TCP MSS is set to an
> > interesting size, this is due to the MTU of the Host device being set below
> > 1500 bytes to keep the IPSec Overhead from causing alot of fragmented
> > packets. This was at the suggestion of the vendor, and so far has not had
> > an effect on the problem.
> >
> > Thanks,
> >
> > Rett Walters
> >
> >
> >
> >
> > "Joergensen,
> > Michael" To: "'Rett_Walters@payless.com'" <Rett_Walters@payless.com>
> > <michael.joergensen@ cc:
> > intel.com> Subject: RE: IPSec Standard - No Flow Control?
> >
> > 07/24/2001 06:04 AM
> >
> >
> >
> >
> >
> >
> > Hi Rett,
> >
> > I've seen similar problems with our products, but there the problem was in
> > the TCP stack, and hence unrelated to the IPSec protocol. Do you observe
> > the
> > same behaviour when IPSec is disabled?
> >
> > As someone else suggested, it will be helpful to see the TCP headers of the
> > unencrypted data, i.e. a capture between the host and the IPSec gateway.
> > This will show where the delay is introduced. My guess is the problem is in
> > the host, not the gateway.
> >
> > Regards,
> > Michael Jorgensen
> > Embedded software engineer
> > Intel Denmark
> >
> >
> >
> > -----Original Message-----
> > From: Rett_Walters@payless.com [mailto:Rett_Walters@payless.com]
> > Sent: 24. juli 2001 04:58
> > To: Michael Thomas
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: IPSec Standard - No Flow Control?
> >
> >
> >
> > I am sorry... I misunderstood, however, I am a bit confused, because we
> > are not dropping packets in this situation, therefore I guess we should be
> > looking elsewhere. This issue is simply slow transfer, similiar to using a
> > small TCP window on a long delay network without any encryption. You don't
> > necessarily drop packets, just spend alot of time waiting on
> > acknowledgements.
> >
> > Rett Walters
> >
> >
> >
> > |--------+----------------------------->
> > | | Michael Thomas |
> > | | <mat@cisco.com> |
> > | | Sent by: |
> > | | owner-ipsec@lists.t|
> > | | islabs.com |
> > | | |
> > | | |
> > | | 07/23/2001 03:40 PM|
> > | | |
> > |--------+----------------------------->
> >
> > >
> > ---------------------------------------------------------------------------
> > ---------------------------------------------|
> > |
> > |
> > | To: Rett_Walters@payless.com
> > |
> > | cc: Derek Atkins <warlord@mit.edu>, ipsec@lists.tislabs.com
> > |
> > | Subject: Re: IPSec Standard - No Flow Control?
> > |
> >
> > >
> > ---------------------------------------------------------------------------
> > ---------------------------------------------|
> >
> >
> >
> >
> >
> > The suggestion was to make the IPsec replay window bigger -- not
> > the TCP window. I've heard that some hardware doesn't allow bigger
> > replay windows than 64 (??), which if this is the case, you probably
> > ought to set the TCP window *lower* so that you're at least not
> > dropping so many packets.
> >
> > Mike
> >
> > Rett_Walters@payless.com writes:
> > >
> > > Derek:
> > >
> > > Excuse my Terminology. It appears that for each Payload packet sent,
> > there
> > > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the
> > > encrypted Layer-4 acknowledgements. Here is a sample of the trace:
> > > # DeltaT Dest Src Size
> > > Summary
> > > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306
> > > ","IP"," ESP SPI=198778318"
> > > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306
> > > ","IP"," ESP SPI=198778318"
> > > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98
> > > ","IP"," ESP SPI=1261713583"
> > > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490
> > > ","IP"," ESP SPI=198778318"
> > >
> > > The problem seems to be a long delay between the 4th 98 (See Frame #9
> > and #
> > > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte
> > frames.
> > > The delay can be from anywhere around 260 MS to as low as 60 MS, usually
> > > closer to the former. This delay kills the throughput of the
> > connection.
> > >
> > > The implementation is from Newbridge Networks, with their "TimeStep
> > > PermitGate" product line. The vendor says this behavior is the nature
> > of
> > > the IPSec standard, and their is nothing they can do about it, this also
> > > appears to be the opinion of Netscreen Inc, who believe their products
> > > would suffer the same issue.
> > >
> > > Another ipsec list subscriber suggested that I increase the TCP window
> > size
> > > further than it is (64k). Unfortunately not all platforms support
> > larger
> > > windows, but I will give this a try.
> > >
> > > Thanks,
> > >
> > > Rett Walters
> > >
> > >
> > >
> >
> > > Derek Atkins
> >
> > > <warlord@MIT. To:
> > Rett_Walters@payless.com
> > > EDU> cc: ipsec@lists.tislabs.com
> >
> > > Subject: Re: IPSec Standard
> > - No Flow Control?
> > > 07/23/2001
> >
> > > 12:42 PM
> >
> > >
> >
> > >
> >
> > >
> > >
> > >
> > >
> > > There are no ACKs to ESP packets. The encapsulated TCP should be
> > > handling the ACKs at (encrypted) layer-4. Could you explain what you
> > > mean by a "trace analysis showing a large percentage of time spent
> > > waiting for CKs to transmitted ESP packets"? Also, what platform(s)
> > > and IPsec implementation(s) are you using?
> > >
> > > -derek
> > >
> > > Rett_Walters@payless.com writes:
> > >
> > > > I have a question regarding IPsec inner workings.....
> > > >
> > > > Is there a provision for Flow Control in the IPSec Standards?
> > > >
> > > > I understand that IPSec essentially runs at Layer 3 which does not
> > > include
> > > > flow control algorithms (usually left to Layer 4 protocols such as
> > TCP);
> > > > however I have noticed in live implementations of the protocol, long
> > > delay
> > > > networks (250ms round-trip) suffer serious performance issues when
> > > compared
> > > > to non-encrypted TCP communications such as Ftp's, using large (64k)
> > TCP
> > > > Receive Windows. Trace analysis shows a large percentage of time
> > spent
> > > > waiting for ACKs to transmitted ESP packets. Is there no way to
> > control
> > > > the amount of data "in flight", ie setting a higher Window? Using
> > IPSec
> > > > Encapsulation seems to override or Break the TCP Windows set in the
> > > > encrypted packet headers, do to its own method of flow control (or
> > lack
> > > > thereof).....
> > > >
> > > > I am wondering if this was overlooked?
> > > >
> > > > Thanks,
> > > >
> > > > ___________________________________
> > > > Rett D. Walters
> > > > Network Architect
> > > > Payless ShoeSource Inc.
> > > > Phone: 785-295-2049, Fax: 785-295-6666
> > > > Email: rett.walters@payless.com
> > > >
> > > >
> > >
> > > --
> > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > > Member, MIT Student Information Processing Board (SIPB)
> > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > > warlord@MIT.EDU PGP key available
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
References: