I also need to point out that we are only talking about the case where the implementation doesn’t use a timer to timeout missing packets. We specifically added text highlighting that implementations are free to timeout missing packets much earlier if they so choose. Perhaps we should also highlight this again??
Thanks, Chris. > On Aug 17, 2021, at 9:22 AM, Christian Hopps <cho...@chopps.org> wrote: > > In particular why don’t we simply indicate that a lost packet can induce a > delay of the fixed packet interval times the window size - 1, and so the > widow size should be kept to a minimum, and leave it at that. > > Thanks, > Chris. > >> On Aug 17, 2021, at 9:15 AM, Christian Hopps <cho...@chopps.org> wrote: >> >> Hi Tero, >> >> Let’s keep things simple here at this point in the process, and also match >> the results we have already verified with running code. >> >> We can add more text that talks directly about how the reorder widnow size >> should be kept as small as possible (it should NEVER be 1000 packets, I’m >> not sure where you got 1000 from but that’s not a reasonable number so >> perhaps pointing this out IS important). It should be something between 0 >> and 5 perhaps 10 if you want to really handle wild cases of reordering (you >> probably dont). >> >> Regular packet loss kills TCP etc.. we do not need to optimize the protocol >> for this condition; however, this brings me to the next point: >> >> We are not transport experts here and we need to stay away from straying >> into that area. We had this draft reviewed and approved by the transport >> area (the experts) because of this. We should not start getting into >> transport area issues of describing affects on the network of jitter or >> re-ordered or lost packets etc. This is not our expertise and will only >> cause trouble when this comes before the transport area AD. >> >> We have approved text from the transport experts now (in addition to >> clearing WG LC). I do not want to open this draft back up for major >> modifications that start talking about new ways to handle packets and their >> affects on the drownstream network etc. This is not our area of expertise, >> and we have already received approval from the experts for the text that we >> have. Let’s stick with the approved text and make clarifying modifications >> only. >> >> Thanks, >> Chris. >> >> >> >> >>> On Aug 17, 2021, at 6:48 AM, Tero Kivinen <kivi...@iki.fi> wrote: >>> >>> Christian Hopps writes: >>>>>> It might be obvious to you, but it might not be obvious to the person >>>>>> doing the actual implementations. I always consider it a good idea to >>>>>> point out pitfalls and cases where implementor should be vary to the >>>>>> implementor and not to assume that implementor actually realizes this. >>>>> >>>>> I agree with that sentiment. >>>> >>>> This is the specific case here: >>> >>> No it is not. >>> >>>> “Given an ordered packet stream, A, B, C, if you send B before A you >>>> will be sending packets in a different order” >>> >>> The question there is that it is very hard to see from the text in >>> current draft section 2.5 that it can cause extra 32-1000 packets >>> (reorder window size) of buffering for every single lost packet. >>> >>> And that current text does not allow the sending packets in different >>> order, as it does not allow processing packets in any other order than >>> in-order. >>> >>> So there are multiple choises here, which affect how the >>> implementation behaves: >>> >>> 1) Make sure that packets are processed in-order always, i.e., do >>> not allow any outer packets to be processed until you are sure they >>> are in-order thus causing extra buffering/latency if any packet is >>> lost, as you need to wait for that packet to drop out of reorder >>> window before you know it is lots, thus before you can continue >>> processing packets. This will not cause any reordering of packets. >>> >>> 2) Process incoming outer packets as they come in, and do not >>> reorder them before processing. In that case you need to process >>> outer packets partially, i.e., only send those inner packets out >>> which have been fully received, but buffer those pieces of inner >>> packets which are still missing pieces as outer packets were either >>> lost or reordered. In this case if there is reordering in the outer >>> packets this will cause this reordering on the inner packets too. >>> >>> 3) Do hybrid version where when you notice missing packet on the >>> outer packets you postpone processing of it for short duration and >>> to see the reordering was only very small (for example wait for just >>> next outer packet). If the outer packet stream can be reordered >>> inside this small window you do that and process packets in order >>> and send them out in order, but you limit the latency caused by this >>> to for example only for one packet and if larger reordering is >>> happening then you still buffer wait until the full reorder window >>> until you deem that you are not able to process that inner packet as >>> it was not completely received because of missing packet. >>> >>> The current text only allows option 1, and I would like to allow >>> options 2 and 3 and perhaps also others, but I would also like to have >>> some text explaining the trade offs of different options. This does >>> not affect the interoperability as such, as two implementations using >>> different methods will interoperate, but this might cause very bad >>> performance issues. >>> >>> Actually I think option 1 (the one only allowed now) can and will >>> cause large jitter for round trip times for every single lost frame. I >>> am not sure what large jitter of round trip times does for different >>> protocols running inside the tunnel. I would assume that any kind of >>> audio conferencing system would have really bad performance if run >>> over such system. >>> >>>> Again I’ll put this text to unblock this document, but really, >>>> sometimes things *are* obvious. >>> >>> I had to parse the section 2.5 several times before I realised that it >>> do really require me to process packets in-order i.e., it forbids >>> options 2 and 3. >>> >>> It might be obvious for you, but it was not obvious for me, and I >>> think that restriction do make the performance really bad. >>> -- >>> kivi...@iki.fi >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
