On Nov 21, 2008, at 17:56 , Geoff Mulligan wrote:

Just so we are clear:
- the only place that this compression will now happen is at the
  source of the packet on a 6lowpan node

Correct.

- this does not work for inbound packets

Correct.
The argument was made that the nodes that would benefit most are sensors with mostly outbound packets.

- it doesn't have applicability to legacy tunneled protocols

Not sure we have consensus on this issue yet.
We need to develop some useful criteria for when a ULTP/app checksum is good enough so we can write these into the document.

- for the source to compress the udp checksum the application must have
  a layer 7 MIC that calculates the MIC over the application payload
  AND the pseudo header and signal to the 6lowpan layer that UDP
  checksum compression is ok

that is a sufficient condition.
is it exactly the necessary one?

- the edge router, when it gets a packet with the c bit set it will
  compute the udp checksum and insert it in the full ipv6/udp header
  and send the packet on it's way.

As I said, conceptually, this happens at every decompressor.
The edge router cannot optimize it away, as opposed to intra-lowpan hosts and forwarders.

- the edge router has no way to verify the ip addresses since there is
  no checksum and there is no validity check on the packet header or
  the new checksum

Correct.
But it has the indication that the peer (if its address wasn't corrupted in transit) is going to check the MIC in the form of the C bit.

- when the MIC is calculated over the IP and udp headers the udp
  checksum value should be zero

(or excluded from the computation, whatever.)

- in the end we save 2 bytes on some packets

Yes, and we spend 0.125 (but in a byte that is mostly unused right now).
<broken-record>We don't have a benchmark that we could use to judge that gain.</broken-record>

Good summary, except that I'm not fully sure about the criteria yet.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to