Subject: [6lowpan] Hc-01 LOWPAN_UDP encoding

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 8 Oct 2008 11:22:42 +0200

Hi Jonathan, all,
 
one comment regarding hc-01 LOWPAN_UDP encoding
for now source and destination ports compression are splitted. It means
if only one of them is compressed, the UDP compressed fields will be 36
bits long (4bits port + 16 bits port + checksum). We lose byte alignment
this way.
 
to avoid this, you could either not split the compression of ports, or
when only one is compressed, pad to 3bytes (4 bits port + 16 bits port +
4bits padding)
What do you think?
 
Cheers,
Julien

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

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 8 Oct 2008 07:45:17 -0700

Hi Julien,

Fixing UDP compression was definitely on the list of TODOs.

So there are a few options:

1) Expand the compressed range to 256 ports (the encoding lengths for  
the ports are then 2, 3, or 4 bytes).

2) When compressing only one port, add a 4-bit pad as you suggest.  
However, I would rather add the 4-bit pad to be with the 4-bit  
compressed port and keep the 16-bit uncompressed port byte-aligned  
(the encoding options would be 1, 3, or 4 bytes).

3) A hybrid of the two: When only one port is compressed, the  
compressed form is 8 bits (don't waste the 4 bits on padding). But  
when both ports are compressed, both only 4 bits.
00 - Neither source nor dest are compressed
01 - Source port uncompressed, dest port 8 bits.
10 - Source port 8 bits, dest port uncompressed
11 - Source port 4 bits, dest port 4 bits.

Basic question to ask the group is if compressing both source and dest  
ports to 4 bits simultaneously useful?

--
Jonathan Hui

On Oct 8, 2008, at 2:22 AM, Julien Abeille (jabeille) wrote:

> for now source and destination ports compression are splitted. It  
> means if only one of them is compressed, the UDP compressed fields  
> will be 36 bits long (4bits port + 16 bits port + checksum). We lose  
> byte alignment this way.
>
> to avoid this, you could either not split the compression of ports,  
> or when only one is compressed, pad to 3bytes (4 bits port + 16 bits  
> port + 4bits padding)
> What do you think?
>
> Cheers,
> Julien
>
>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 8 Oct 2008 17:56:32 +0200

Hi Jonathan, 

I am ok with 2 or 3. 
Regarding compression of both ports simultaneously, I do not know if it
useful, but as we must support at least 3 scenarios (src only
compressed, dst only, or none), we need two bits. Hence I would say we
can reserve the 4th value for the case where both ports are compressed.

Regards,
Julien

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]] 
Sent: mercredi 8 octobre 2008 16:45
To: Julien Abeille (jabeille)
Cc: [email-masked]
Subject: Re: Hc-01 LOWPAN_UDP encoding

Hi Julien,

2) When compressing only one port, add a 4-bit pad as you suggest.  
However, I would rather add the 4-bit pad to be with the 4-bit
compressed port and keep the 16-bit uncompressed port byte-aligned (the
encoding options would be 1, 3, or 4 bytes).

3) A hybrid of the two: When only one port is compressed, the compressed
form is 8 bits (don't waste the 4 bits on padding). But when both ports
are compressed, both only 4 bits.
00 - Neither source nor dest are compressed
01 - Source port uncompressed, dest port 8 bits.
10 - Source port 8 bits, dest port uncompressed
11 - Source port 4 bits, dest port 4 bits.

--
Jonathan Hui

On Oct 8, 2008, at 2:22 AM, Julien Abeille (jabeille) wrote:

> Hi Jonathan, all,
>
> one comment regarding hc-01 LOWPAN_UDP encoding for now source and 
> destination ports compression are splitted. It means if only one of 
> them is compressed, the UDP compressed fields will be 36 bits long 
> (4bits port + 16 bits port + checksum). We lose byte alignment this 
> way.
>

> when only one is compressed, pad to 3bytes (4 bits port + 16 bits port

> + 4bits padding) What do you think?
>
> Cheers,
> Julien
>
>