On Nov 19, 2008, at 08:42 , Erik Nordmark wrote:
Carsten Bormann wrote:
One the way from the correspondent node to the 6lowpan node, an app
that implements the ULTP computes the MIC to allow the compressor
at the 6lowpan boundary to check it and, if that *and* the UDP
checksum were correct, to compress away the UDP checksum.
What happens if I have an application on a correspondent node which
sends a regular UDP packet? (i.e., without the ULTP MIC) How can the
compressor tell the difference between such a UDP packet and a UDP
packet which includes the ULTP MIC?
That is indeed the point I was making.
I wrote:
As is often the case with header compression, the compressor decides
by oracle that an ULTP was present (there is no indication in the
UDP packet); a matching MIC is a very good oracle, though. In any
case, header compression *is* layer violation, so there is nothing
new here.
So the answer is: If the MIC doesn't match (or there are not enough
bytes that this could be a MICed packet), the UDP checksum stays in.
If the MIC *does* match by accident, the compressor will likely decide
to take out the UDP checksum, which leads to the second half of my
point:
One interesting side effect of using the ULTP presence oracle in the
compressor is that, if the ULTP checksum happens to match, a random
6lowpan node (that does not implement ULTP) might get a UDP packet
with an elided checksum. If that still wants to check the packet,
it needs to implement the ULTP MIC (which we haven't standardized).
There is a low likelihood of that happening, but this is not just a
"packet loss", as it systematically will affect any packet that
happens to match the MIC even if retransmitted.
In effect, this makes ULTP implementation an all-or-nothing
requirement on the 6lowpan nodes. This is the only problem I see
with this kind of header compression. (Oh, and, if that is the
case, is there any point in compressing ULTP as well?)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
