[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSec Standard - No Flow Control?
On Tue, Jul 24, 2001 at 09:20:21AM +0200, Joern Sierwald wrote:
> At 14:12 23.07.01 -0500, Rett_Walters@payless.com wrote:
> >
> >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"
>
> Well, the 1st hint is the packet size of 1490. Since this is the
> size after encryption, your IPsec has somehow managed to reduce the TCP MSS.
> Maybe the normal TCP MTU discovery dicovered the IPsec tunnel, maybe
> the IPsec fiddled with the MSS option.
Is it not just the opposite? That the segment size has increased? On
an Ethernet with 1500 MTU you should have 1460 MSS. This way the last
segment might get dropped at the receiving end, while the sender is
waiting for the ACK.
Ramin
>
> But this reduction is most likely the cause for the delay. If one of
> the TCP implementations has problems with an odd MSS, this might just
> explain the effect.
>
> Anyway, to go ahead you should try to get a trace of both encrypted and
> unecrypted traffic together in one trace. The traffic _and_the_delay_
> is caused by the TCP stack, not by the IPsec box. (That's me theory, anyway)
> Happy TCP analysing to you!
>
> Jñrn
Follow-Ups:
References: