Christian Hopps writes: > Will you be able to provide the text changes that would cover the > issue you have? Would really like to get this submitted to IESG > before another IETF cycle completes.
How about following: ---------------------------------------------------------------------- 2.5. Summary of Receiver Processing An AGGFRAG enabled SA receiver has a few tasks to perform. The receiver SHOULD process incoming AGGFRAG_PAYLOAD payloads as soon as they arrive as much as it can. I.e., if the incoming AGGFRAG_PAYLOAD packet contains complete inner packet(s), receiver should extract them and forward them immediately. For partial packets the receiver needs to keep the partial packets in the memory until the they fall out from the reordering window, or until the missing parts of the packets is received, in which case it will reassemble them and send them out. If AGGFRAG_PAYLOAD payload contains multiple packets they SHOULD be sent out in the order they are in the AGGFRAG_PAYLOAD (i.e., keep the original order they were received on the other end). Instead of the method described in the previous paragraph the receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3), and only after it has in-order AGGFRAG_PAYLOAD payload stream, receiver extracts the inner-packets. In this case the receiver considers a packet lost when it's sequence number is abandoned (e.g., pushed out of the re-ordering window, or timed-out) by the reordering algorithm. Using this methold will make sure the packets are sent in-order, i.e., there is no reordering possible, but the cost is that any lost packet will cause delay of full reorder window, and there will be extra burstiness in the output stream (when lost packet is dropped out from the re-order window, all outer packets received after that are then immediately processed, and sent out back to back). Additionally, if congestion control is enabled, the receiver sends congestion control data (Section 6.1.2) back to the sender as described in Section 2.4.2 and Section 3. ---------------------------------------------------------------------- I think that captured what I proposed long time ago to you in several emails, but now this is full section so it should be easier to incorporate than the earlier proposed separate sentences. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
