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
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?
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b29 : Thu Jul 31 2003 - 22:00:01 EST