I'm not sure what you mean by Huge delays. Given an example of a 10 kilobit tunnel (really?) means *everything* is super slow, so then reporting raw wall clock times is a bit disingenuous I think. I didn't actually look over the math b/c this just doesn't seem realistic. Have you considered what happens to your inner TCP stream bandwidth when you have regular packet loss, regardless of IPTFS? I think a slight bursty-ness given regular packet loss is the least of your problems at that point. Thanks, Chris. Tero Kivinen <kivi...@iki.fi> writes:
While reviewing the draft for publication I found out that section 2.5 says that we first reorder packets, then make sure we have not missed any packets, and only after that we process the in-order payload streams to extract the inner-packets. The problem is that packet is considered lost only when it falls out of the re-ordering window. This will cause huge delays in the traffic flows every single time we loose even single outer packet. I.e., if we have following flow (O<n> = outer packet n, I<n> = inner packet n), assume packet bandwidth of 10 kB/s, 1400 byte packets, re-order/replay window of 32 (typical for IPsec settings). This means the packet send rate is 7.3 packets per second, and the size of reordering buffer is 4.3 seconds: Time Outer Inner 0.000 O<0> I<1>, pad 0.137 O<1> pad ... 0.411 O<3> pad 0.548 O<4> I<2>, pad 0.685 O<5> pad ... 2.055 O<15> pad 2.192 O<16> I<3>, pad 2.329 O<17> pad ... 3.014 O<22> pad, 3.151 O<23> I<4>, I<5frag1> 3.288 O<24> I<5frag2>, I<6frag1> 3.425 O<25> I<6frag2>, I<7>, pad 3.562 O<26> pad ... 4.247 O<31> pad 4.384 O<32> pad 4.521 O<33> pad Now if the packet O<1> is lost, the algorithm requires us to wait 4.384 seconds (i.e, up to time 4.521), before we can forward I<2> - I<7>, even when they were properly received several seconds before. I think we should allow forwarding the inner packets which are properly and completely received even when we have some earlier packets missing. This will of course also cause traffic to be very bursty in case of packet loss in the inner packets, i.e., instead of getting inner packets in same intervals they were sent, we suddenly receive all of them after the first lost packet drops out of re-ordering queue, i.e., for the final recipient the timing will look like follows: Time: 0.000 I<1> 4.384 I<2> 4.385 I<3> 4.386 I<4> ... I.e., suddenly at 4.384 seconds final recipient will suddenly get burst of back to back packets from the security gateway. This will most likely cause all kind of issues on its own timing algorithms... If we do allow forwarding complete packets in out of order manner, what should we do in case packet O<24> is lost? Should we allow forwarding I<7> immediately when we received O<25>, or do we need to wait 4 more seconds to see whether O<24> ever arrives before we deem both I<5> and I<6> as lost (because fragments of them are lost), and send I<4> and I<7> forward? If we do allow processing of outer packets in that kind of out of order manner, then that will of course mean that there might be reordering happening because of this, and this most likely needs to be mentioned in the draft too. On the other hand I would assume that in normal cases lost packets are much more common than reordered packets, but there are most likely cases where there is lots of reordering, but not that much of lost packets.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
