Christian Hopps writes: > >> 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.
I think dropped packets and even reordering is thing that will happen on the internet. I can see you assume that those are rare cases, but if you try to work over mobile networks those things happen very often. Also at least in Finland it seems to be harder and harder to get copper or fiber, ISPs usually just offer mobile connections nowadays. Of course if this is only to be used between security gateways between two datacenters, or similar, then good networks might be something that can be expected, on the other hand when you are talking about long distance links, even they are not that good, and I do see packets dropping in those situations too. > 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. No, one delayed packet does not delay any of the other frames in normal case. I.e., if I have audio stream with packets A1, A2, A3, A4... A50, etc, and one of them gets delayed (or dropped), i.e., lets say A3 gets hold up by some buffering or got dropped. this means I do get A1, A2, A4, A5 ... A50 to the final destination and audio codecs usually take care of that and you do not loose that much of audio. Going over IP-TFS with replay and reorder window of 32, I get A1, A2, and then 32 outer IP-TFS frame long delay and then my end node gets burst of frames from A4..A32 (if we assume IP-TFS frame rate is same as audio frame rate). Now end node can either delay the whole audio link by 32-frames so there is extra delay on the link, or it needs to throw away frames A4..A32, as they are useless to him as they arrived too late. > But more importantly, you are optimizing for a case that is simply > NOT going to happen in the real world. I tell you packets are lost in real world. I do not know in which world you live, but I do see packets getting dropped quite often, especially over mobile links. > 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! This same thing happens also when you have any dropped frames. It is not only the case about the reordered frames. Yes, reordering happens much less frequently but even that can happen, but this issue is exactly same for each dropped frame. > 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. I am not talking here as chair, I am talking here as an developer who see no point of making crappy protocol. Thats why I said you either need to properly explain what are the real effects of requring all outer packets to processed in-order (and combined that with the case that packets are assumed to be lost only after they drop out from the re-ordering buffer, which means every single dropped frame completely stalls the in-order processing of outer frames), or I would prefer that you remove the in-order processing requirement and allow making usable and efficient protocol. I would expect that we would get similar comments from others also during the last call or even during the IESG telechat, and fixing those things during the working group processing usually makes things faster. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
