On Nov 19, 2008, at 11:23 , Erik Nordmark wrote:
Doesn't this imply that the sender needs to know whether the
destination is on the far side of a router which does the
decompression?
Decompression usually happens at the L2-L3 boundary, so it is always
the case that the packet undergoes decompression before being handed
to a router or app.
Yes, L4 compression is undone before any L3 forwarding (did I mention
"layer violation"?).
(Implementations can optimize that so a L3 forwarder does not really
have to decompress/compress if the packet goes into a similar network,
but conceptually it has to.)
I don't see how it can tell that since we've been talking about
- using the same subnet prefix for an extended 6lowpan
- having the decompression happen in the ER
- having hosts on the backbone
The L3 forwarder cannot make that optimization then.
Thus when a host on the backbone sends a packet your first paragraph
seems to say that the UDP checksum can not be compressed, since the
packet is forwarded by a (compressing) ER.
Correct.
Also, when a UDP-checksum-elided packet traverses the backbone, it
will be sent back into the lowpan without the elision optimization.
Big deal, I'd say; not the case we are optimizing for.
Think "outsourcing the checksum computation to the ER".
Assuming the sending 6lowpan node uses the destination prefix ("is
it in my subnet prefix?") to determine whether or not a MIC is
included and the UDP checksum compressed out, then the hosts on the
backbone will receive some UDP packets with a MIC, and other UDP
packets (from other hosts) without a MIC.
I think Pascal is right that this is a first-hop (plus all contiguous
hops that can make the above optimization in their forwarders)
optimization. The app can then simply signal the applicability of UDP
checksum elision down the stack.
IMHO it would be a lot more robust to define a new IP protocol
number for the "UDP with a MIC" protocol.
Yes, in a greenfield world.
The problem is that the correspondent nodes are random legacy PCs and
such stuff.
How do you handle "UDP with a MIC" in Windows 3.1?
(Yes, that is a rhetorical question, since 3.1 did not have IPv6.)
Gruesse, Carsten
PS.: I'm not saying the whole ordeal is worth it. I'm just saying it
can be made to work.
Sometimes complexity like this is needed for political reasons.
Convince me that it is.
It will be much harder to convince me that there is a technical reason.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
