> On Aug 16, 2021, at 1:45 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Christian Hopps writes: >> During the last IETF meeting it was agreed that we would move >> quickly to resolve any issues that Tero had left, and get this >> document submitted to the IESG. So asking again if the new version >> (published prior to the meeting) satisfied the issues so we can move >> forward? > > No. You did not address any of my concerns there. I am not even sure > if you read my email where I presented my concerns, as I have not seen > any other comment on them than except complaining that this is not > meant for low bandwith situations and my examples using them were not > interesting. > > Last week when I was reading your draft I got really disappointed when > I noticed that section 2.5 was completely unchanged, when you did say > you had addressed my comments. I got so annoyed, that I decided to > wait before sending my reply as I know how hard it is write > constructive text when you are annoyed. > > You seemed way too much concentrating on my example using slow link > speed, and not to the fact that section 2.5 (implictly) requires you > to wait for packets to drop out of reorder window before they can be > processed at all:
I believe I was focused on slow links b/c it seemed that you were focused on a concern of “large delays”, and the only large delays happen if there are slow links or inappropriately large reorder windows. In any case the revised text talks to these points. > Essentially the section 2.5 says that you first reorder, and wait for > all missing packets and finally processes the in-order payload streams > to extract the inner-packets. > >> From my original email: > > ---------------------------------------------------------------------- > 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. > ---------------------------------------------------------------------- > > I.e., I want section 2.5 to explictly mention how to do processing of > the AGGFRAG_PAYLOADS, i.e., is receiver allowed to forward parts of > the inner packets out even when previous packets are missing, and they > of course need to wait until all piecess of large fragmented packets > arrive before they can forward it, but can they send packets that were > in the first packet which did arrive out immediately when they arrive > (I would assume yes), and if some packets are missing in the middle, I > would assume that they can extract the inner-packets from later > packets too even when there is some packets missing. > > The last paragraph of 2.5 which says: > > Finally, the receiver processes the now in-order AGGFRAG_PAYLOAD > payload stream to extract the inner-packets (Section 2.2.3, > Section 6.1). > > would indicate that you do require full completele in-order payload > stream before you start extracting any inner-packets from the stream, > meaning that for every single lost or reordered frame you need to > stall until that frame drops out of reordering window to make sure > they have in-order payload stream. Only after the packet drops out > from the reorder window they can be sure it was lost thus only after > that they know they do have in-order stream that do have some gaps in > it. > > So adding text saying "Receiver MAY process any completely received > inner-packets immediately they are fully received." would solve a lot > of problems, but of course that would contradict the last paragraph > which do say we process inner-packets only in order. > > Also if we do allow processing inner-packets immediately when we have > received full packet inside the AGGFRAG_PAYLOAD payload stream this > may will cause the reordering which happened in the outer transport to > be duplicated for inner-packets too, so we should most likely add note > for that. > > If we do not allow processing inner-packets immediately but must wait > until all the packets are received and the missing packet drops out of > reorder buffer that will cause us to create extra buffering and extra > burstines, so then we should add note about that. We certainly did not want to specify whether an implementation SHOULD forward complete inner packets, out of order, or not, b/c that is not required for interoperability. Implementations could very well decide to offer one or both options. Our job is to specify the on-the-wire behavior so that implementations interoperate. You are suggesting that we should add a “MAY” to the same affect though. That seems like a non-controversial change that could be made. Adding a more text pointing out the obvious results of this choice (i.e., that sending inner packets early can create downstream out of order delivery, or that waiting for outer packets can add delay and bursti-ness) would not be my preference. As a general rule I try (and I’m not alone in this) to avoid adding unneeded text, b/c the best you can hope for is to not say it wrong. That said if you believe the text must also include these 2 points as well i will add them in order to move things forward. Would you be agreeable to just adding the clarifying “MAY” statement? Thanks, Chris. > -- > 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
