[IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt

[Tero Kivinen <[e-mail]>]

[e-mail] writes:
>         Title           : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security
> 	Filename        : draft-ietf-ipsecme-iptfs-12.txt

I checked the diffs, and I think this text is mostly ok.

I think there is still bit of tweaking that can be done, mostly as
what happens if using the 2nd option and the frame appears after the
lost timer, but inside the reorder window.

My understanding is that it would still be good idea to process that
frame, but there is text which says "Using this method will make sure
the packets are sent in-order, i.e., there is no reordering possible,
...", and that would indicate that we must drop that frame that comes
after the lost timer expire, but inside the reorder window, as if we
process it after the lost timer has expired this may cause inner
packets sent out of order.

The question really is do we want really make sure there can not be
reorderings on the 2nd option, i.e., we will drop all frames that
would send reordered inner frames?

In that case the reorder window size does not have any meaning if we
have loss timer defined.

On the other hand having small lost timer, but bigger reorder window
would allow fixing localized reorderings (i.e., like getting two outer
frames almost back to back, but in wrong order), but still not throw
away frames that come in too late.

To allow that we could simply change text to "Using this method will
make sure the packets are sent in-order as much is possible, ...".

Ps. Other option is to allow that kind of localized reorderings is to
add that option to 1st option, i.e., add sentence to the end of 1st
paragraph saying "The receiver MAY also have reordering timer, so that
when out of order outer packet comes in, the receiver waits for this
reordering timer to see if new packets comes during that time, and if
so it can reorder the frames before processing them.", but on the
other hand I do not think anything in the 1st option forbids doing
that anyways, so I do not think we need such text.
-- 
[e-mail]