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

[Christian Hopps <[e-mail]>]

I believe this is a good time to apply KISS method.

We have a lost packet timer and additionally this is the "in order delivery" mode. Let's not make this more complex to try and eek out every ounce of potential, especially given we are already documenting 2 possible receiver behaviors (instead of 1 recommended one) specifically b/c we need to gain more experience for what affects they have on the inner traffic and various applications.

Please also consider this from the perspective of congestion control. When a packet is considered lost it will trigger various actions in the congestion control algorithms.

Let's just keep lost packets lost for now.

Thanks,
Chris.

Tero Kivinen <[e-mail]> writes:

> [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.