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: 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
