Hi Tero,
see below
On 11/5/2021 3:09 PM, Tero Kivinen wrote:
Lou Berger writes:
I'd prefer to see the SHOULD and MAY reversed -- intentionally
introducing additional reordering is generally considered something to
avoid.
Yes, intentionally introducing reordering or delay SHOULD be avoided,
thats why it is important to keep the SHOULD and MAY as they are.
The current text does NOT add any reordering, it just does NOT fix the
reordering that has already happened. I.e., if the outer packets come
in-order there is no reordering happening.
Following this SHOULD will actually *amplify* reordering as seen by the
end user/application.
Consider a TFS tunnel that aggregates (on average) 3 inner packets. A
single tunnel reorder (packet O2 followed by packet O1 in reception
sequence, i.e. [O2, O1]) will result in each of the miss-ordered inner
packets being N packets out of order, (for a resulting example sequence
of [I4,I5,I6], [I1,I2,I3]). A miss-order of 2 outer packets, would
result in a 2N miss-order (O2,O3,O1 --> [I4,I5,I6], [I7,I8,I9],
[I1,I2,I3]).
So in this case a *SHOULD* is likely to result in significant change in
the number of out of order packets seen in any application that doesn't
use large packets -- and this might break such applications. For such
applications seeing added delay may also have negative impact, but
variable latency on the internet is a pretty normal event that
applications already have to allow for.
The question is what
happens when there is reordering happening in the outer packets.
Keeping the SHOULD in first case says that we do not want to
intentionally add any new delay, thus we process the outer packets
immediately when they come in, but to do that we allow the reordering
that happened in the outer packets to be propagated to the inner
packets too.
I think adding delay is safe for general internet applications, i.e.,
existing end to end applications will continue to function albeit with,
perhaps, more jitter due to intermediate reordering. Adding more
reordering is something that applications may not be able to tolerate,
so this seems quite risky as the RECOMMENDED option.
FWIW I'm basing my comments on my routing area experience where a huge
amount of work has been put into maintaining ordering experienced by
user traffic at significant implementation expense, i.e., in support of
ECMP and other multipath solutions in protocols and hardware.
I'd also be fine with both being a MAY and a recommendation for
this to be configurable.
I strongly belive that we should not intentionally add reordering OR
delay, and we SHOULD try to keep the conditions as they are, i.e., if
there is reordering happening in the outer packets, lets allow it to
be propagated to inner packets.
If there is lost packet in the outer packets we SHOULD NOT cause extra
delay when trying to fix reordering... I myself think that lost
packets are much more common than reordered packets, and thus causing
extra delays for each lost packets just to be able to fix reordering
cases is much worse than allowing reordering to go through.
I think this really depends on your operational environment. If you are
operating over fiber networks, loss really only happens due to
congestion and in many place is pretty rare. On the other hand if your
tunnels are operating over wireless networks, loss will be quite
common. So we may really be heading towards a deployment choice, with
the recommendation to do both and support configuration.
Lou
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
