[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Standard - No Flow Control?
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.
-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
Follow-Ups:
References: