Christian Hopps writes: > Let’s keep things simple here at this point in the process, and also > match the results we have already verified with running code.
In real production use over internet or in the lab between two test machines (or inside one datacenter between machines there)? > We can add more text that talks directly about how the reorder > widnow size should be kept as small as possible (it should NEVER be > 1000 packets, I’m not sure where you got 1000 from but that’s not a > reasonable number so perhaps pointing this out IS important). It > should be something between 0 and 5 perhaps 10 if you want to really > handle wild cases of reordering (you probably dont). Reorder and replay windows are linked as there is no point of having replay window of 1000 packets if your reorder window is only few packets, as any packets which gets delayed more than that few packets which are accepted by replay window will be thrown away by reorder window, thus there is no point of having bigger replay window than reorder window. Minimum replay window size required for each implementation is 32, and I think that is very common default case, even though RFC4303 recommends window size of 64. From RFC4303 section 3.4.3: A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard. On fast links people want to increase that, as any packet which gets delayed will get delayed a lot when counted in packets as even delay of few tens of ms will mean there is lots of packets gone during that time. Actually I think it would be better to say that "replay window size MUST be larger than reorder window size." and also add text that says that if packet is out of reorder window (but was inside replay window as otherwise it would have never reached re-ordering process) the implementation can process the compelete inner packets from that packets even when partial packets inside that outer packets cannot be processed. The replay window will take care that this is not an attack, so it is safe to process such packets even when they are outside replay window. Of course if it is outside replay window that means we can't reassmeble partial packets that are part of that outer packet, but we can safely process the inner packets completely inside that outer packet. Adding text about that to the section 2.5 would also make the protocol better. > Regular packet loss kills TCP etc.. we do not need to optimize the > protocol for this condition; however, this brings me to the next > point: I do not belive so. I regularly use TCP over crappy mobile networks and they do have lots of packet loss. TCP works fine in such situations. It is not very fast, but it do work... I have no idea how it would work when each packet loss would not be a simple packet loss, but also a long delay before the further packets in the stream are being received (i.e., waiting for the reorder buffer to fill up before sending packets after the lot packet). I would assume selective ACK and such mechanism in TCP will not really work, but I am not expert, so I can't say that for sure. This would require someone from the transport area to comment, how well will TCP work when we randmly have extra 10x or 100x delay for packet transition and then we get lots of packet back to back.. > We are not transport experts here and we need to stay away from > straying into that area. We had this draft reviewed and approved by > the transport area (the experts) because of this. We should not > start getting into transport area issues of describing affects on > the network of jitter or re-ordered or lost packets etc. This is not > our expertise and will only cause trouble when this comes before the > transport area AD. True, but I am not sure if the transport area reviewer actually understood the behavior we have specified now. I did not understood that on my first reading. > We have approved text from the transport experts now (in addition to > clearing WG LC). I do not want to open this draft back up for major > modifications that start talking about new ways to handle packets > and their affects on the drownstream network etc. This is not our > area of expertise, and we have already received approval from the > experts for the text that we have. Let’s stick with the approved > text and make clarifying modifications only. When we find an issue in early phases of the document development (WGLC is still very early in the document development), we should address those. Also the section in 2.5 was written in such way that I myself did not understand the implications of the words "Finally, the receiver processes the now in-order AGGFRAG_PAYLOAD payload stream to extract the inner". I always assumed that we could process outer packets as they come in, and did not have to do stop and wait until we have confirmed that we have in-order stream (with perhaps some packets missing) before we continue processing. On the other hand it is true that we do get another transport are review during the last call phase, and we can of course ask this specific question from the reviewer at that time, but I think solving this problem now is better than during the IETF wide last call. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
