Hi, Alexey After some discussion with other people in the mail list, now I have new ideas. Welcome your comments! 1 As for the IPCOMP case, although it's unfair to check pmtu against the packet size before doing the IPCOMP transformation, I still believe that it's appropriate to check pmtu against the packet size before doing the IPCOMP transformation. Let me explain the reason: even if we find that the packet size exceed the pmtu value after doing the IPCOMP transformation, we'll have no way to figure out the accurate pmtu value to be returned to the real source, because we can't know the compression rate. So I think this is a better solution in the case there's no a best solution. Also this solution is based on the worst-case scenario, that is, as if the packet is not compressible. 2 As for the ESP alignment padding, I have two proposals for the solution a) The first is the simplest and based on the worst-case scenario. That is, we always calculate the length of alignment padding as 255 bits long. This scenario is not accurate but it can work. b) The second is accurate but need a bit more modifications to the source code. That is, we check the pmtu against the packet size after doing the transformation. This will make it necessary to store the original packet header in "struct sk_buff", because the "real packet header" will be encapsulated after doing transformation. So we need to add a new data field to struct sk_buff to store the packet header. If the packet size exceeds the pmtu, we can send the PMTU message to the real source according to the original packet header stored in sk_buff. Is there anything that I missed? Thanks, Forrest - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
