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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
