Hi >From my experience there's lots of network devices that can easily process traffic out of order.
If you have multiple cores, different packets can be anchored to different cores. If one core is busier this can result in backpressure and traffic lost or delayed. I've seen other devices that supposedly guarantee packets to flow out, in the order they flowed in, but in reality they didn't.. Wireshark captures either side of the device proving this. I spent nearly 10 years in professional services, working with customers and saw this more than not.. cheers On Mon, Sep 6, 2021 at 8:17 PM Christian Hopps <cho...@chopps.org> wrote: > > Tero Kivinen <kivi...@iki.fi> writes: > > > Christian Hopps writes: > >> > >> Christian Hopps <cho...@chopps.org> writes: > >> > > >> > I'm saying we should add new text that mentions the use of this > >> > drop timer to drop missing packets after a short waiting time > >> > instead of just waiting for it to slide out of the reorder window. > >> > Then there is no issue to discuss anymore AFAICT. > >> > >> A new version has been published which modifies the text in question > >> and changes it to RECOMMENDING the use of a drop timer. > >> > >> I believe this is a good change, and addresses Tero's concern about > >> long delays if a timer is not used. > > > > No it does only notes there is an issue, and proposes a partial > > solution to it, but still does not really address it. > > > > I still do not understand why you insist on in order processing of the > > outer frames? > > Because IMO this is one of those micro-optimizations for a pathalogical > case that are never worth the complexity that they add. > > If the packets are coming in out of order then even if they were *not* in > this tunnel they would be being delivered down stream out of order and thus > they would be DELAYED. All that we are doing, again for a pathalogical > case, is adding a bit of bursty-ness to things. > > But more importantly, you are optimizing for a case that is simply NOT > going to happen in the real world. The reason packets get out of order is > b/c you have multiple paths along the way. *ALL* modern routers at LEAST > look at source and destination IP when they do ECMP selection. They do this > exactly so that things like tunnels don't get delivered out of order! > > At this point please suggest the text that you would like changed or added > to this document. I object to having to add it, but you are the chair and > you are blocking this document so we must accept. > > Thanks, > Chris. > > > I mean IPsec is never ever tried to protect you from the packet > > reordering, but IPTFS adds this new protection and this causes delays > > and dropped frames even at the small reordering. > > > > Why do you not want to allow processing outer frames as they come in, > > and sending all the fully reassmebled (or fully received) inner frames > > out as soon as you have them in your posession? > > > > I.e., if you say receiver is allowed to send fully received inner > > frames out as soon as they are fully received, and is allowed to > > process outer frames in the order they are received that would solve > > the problem. > > > > I mean that also solves the memory requirement, as you do not need to > > keep all the packets in the reorder window in the memory, you only > > need to keep the those parts of the outer frames which have not yet > > been able to be reassembled in memory, and immediately when you can > > reassmeble the frame, you can do that, send it out and free the > > memory. > > > > IPsec replay protection will guarantee that you are not seeing any of > > those outer frames again, even if attacker would retransmit them, so > > there is no need to keep outer frames which have been fully processed > > in the memory at all. > > > > With your new text you are just limiting the number of frames you need > > to keep in the memory to smaller amount by setting the reorder window > > smaller (drop timers just make reorder window smaller with IP-TFS as > > packets are sent as continuous stream). > > > > The the issue is still in the text 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). > > > > I.e., the one which do require in-order processing of AGGFRAG_PAYLOAD > > payloads. > > > > I.e., looking at the Appendix A, if the ESP1 is lost (or delayed > > because of reordering), and we see the ESP2 packet first, why the > > received cannot send the 60 octet and 240 octet inner frames out > > immediately when ESP2 frame is received, and keep the first 100 bytes > > of the ESP2 in memory just in case the ESP1 packet is received later > > (and of course also keep the last 1100 at the end of ESP2 frame i.e., > > the beginning of the 4000 octet frame as that is not fully received at > > that point). > > > > Then if we next received ESP3, and ESP4, then we can forawrd the 4000 > > octet frame to the network (and after that we only still need to keep > > the 100 bytes in the reassembly buffer, we can free everything else > > from the queue). If we then happen to receive the ESP1 (which was not > > dropped, only reordered), we can then forward the first 800 octet > > frame out, and reassemble the second 800 octet frame and send that out > > also to the network. > > > >> > >> New text follows: > >> > >> Please note when IP-TFS sends a continuous stream of packets, there > >> is no requirement for an explicit drop timer; however, using a drop > >> timer is RECOMMENDED. If an implementation does not use a drop timer > >> and only considers an outer packet lost when the reorder window moves > >> by it, the inner traffic can be delayed by up to the reorder window > >> size times the per packet send rate. This amount of delay could be > >> significant for slower send rates or when larger reorder window sizes > >> are in use. > > > > I think the amout of delay will also completely mess up any kind of > > video and audio streams, and most likely mess up the TCP > > retransmission and ack timers. > > > > And even when we do have the congestion information inside the IP-TFS, > > I do not see any way we can actually transmit that information from > > the security gateway doing the IP-TFS to the actual end node that > > would need to get that information, thus the congestion information is > > just used to limit the IP-TFS data rate, it does not help at all for > > traffic inside the tunnel. > > > > Note, that this issue was also pointed out as the "most significant > > concern" in transport area review: > > > > > https://datatracker.ietf.org/doc/review-ietf-ipsecme-iptfs-03-tsvart-early-touch-2020-12-03/ > > > > The most significant concern is not at the transport layer – it is > > the assumption of in-order delivery and insufficient consideration > > of the impact of loss at the network layer. Loss could orphan > > received fragments – for which a timeout should be recommended. > > Loss or reordering could generate faulty reassembly at the egress > > – which is actually very likely here, e.g., when a short packet is > > followed by a sequence of packets that are exactly the tunnel MAP > > (as defined in draft-ietf-intarea-tunnels). As noted below, > > persistent fragmentation could make this situation worse, esp. in > > the presence of frequent reordering or loss. > > > > I do not want to go back to see old diffs before this review, but how > > did you address that concern from the tsv-review. I just see that > > there was a text section addded which do say we do order frames before > > doing reassmebly process, i.e., adding in-order processing requirement > > (which is still needed for frames which cross multiple frames), but > > having some restrictions to frames which are already fully received > > inside the inner frame will mess up things. > > _______________________________________________ > 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
