[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSec Standard - No Flow Control?




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
 >
 >
 >
 >










Follow-Ups: