Re: [rohc] Re: Review of draft-bormann-rohc-over-802-00.txt

Hi Pedro,

this is a very good point.

> In this case, if the AP chooses to use DIX Frames,

I should have been more specific in section 5: The idea is to use an 
encapsulation that is *not* the equivalent of a DIX (type-based) frame.
So the AP will simply not have that choice.

E.g., in variant 3 we would use an OUI that is not zero.

I would still prefer to use variant 2 or 1, which both also don't have 
that problem (variant 2 will be seen as a non-zero OUI by a standard 
SNAP implementation, and variant 1 cannot be mistaken as SNAP).

Variant 1: constant overhead of three bytes (LLC) plus possibly one 
byte used for demultiplexing (e.g., short vs. long CID, other IETF 
protocols sharing the LSAP allocation).
We need to go to ISO to get an LSAP.

Variant 2: as with the 3+1 subvariant of variant 1.
We would have to agree with 802 to use the reserved value 1 of the M 
bit.
Also, it would probably not be a good idea to send less than 8 bytes in 
total, so there is a minimum ROHC frame size of 4 bytes (not a problem, 
since we have padding built in to ROHC).

Variant 3:
a) constant overhead of at least six bytes (3 LLC, 3 OUI -- we can use 
the type ID part of the SNAP "protocol identifier" as we want), with a 
minimum ROHC frame size of 2 bytes (at least have to complete the 802 
"protocol identifier").
b) constant overhead of seven bytes (3 LLC, 3 OUI, 1 demux -- again in 
the type ID), with a minimum ROHC frame size of 1 bytes.
We need an OUI (or possibly re-use the IETF OUI -- I haven't checked 
who else uses this).

Resulting VoIP header sizes, assuming we have a way to use short CIDs 
(add one otherwise):

1a	4
1b	5
2	5 (with at least 3 bytes of payload)
3a	7 (with at least 1 byte of payload)
3b	8

Gruesse, Carsten

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc