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

From: Pedro Fortuna <[email-masked]>
Date: Wed, 8 Dec 2004 01:07:06 +0000

Dear Carsten,

I've carefully read the draft but there an issue regarding section 5
(encapsulation proposal) that I didn't quite understood.
Let's say that we come to the conclusion that 802.3 LLC+SNAP
encapsulation is the best one for addressing the padding problem. With
this in mind, let's analyze the following example scenarios (see
attached gif):

Scenario 1
|  PC1 |====802.3======|  802.3/802.11 bridge |~~~~802.11~~~~|  PC2  |

PC1 sends RoHC packets encapsulated with 802.3 LLC+SNAP. The packets
arrive to the bridge where padding, if any, is stripped by the bridge
and the RoHC payload is then sent to PC2 encapsulated in 802.11 data
frames. This scenario works because we can make PC1 send packets with
the Ethernet encapsulation of our choice (i.e. 802.3 LLC+SNAP).

Scenario 2
|  PC1 |~~802.11~~| 802.11/802.3 bridge|==802.3==|802.3/802.11
bridge|~~802.11~~| PC2 |

Now we have two PC's connected to 2 different AP's, interconnected by
an 802.3 link. In this scenario PC1 sends RoHC packets encapsulated
with 802.3 LLC+SNAP. The packets arrive to the bridge with no padding
(since it is 802.11), then the bridge chooses one encapsulation type
and adds padding if necessary. Imagine that a set of particular
packets are small enough to need padding when crossing the 802.3 link.
In this case, if the AP chooses to use DIX Frames, then the second AP
will not be able to tell that the packet has padding (due to the fact
that we aren't carrying IP packets in the Ethernet frame's payload).
If this thought is correct, the padding will be transported in the
second 802.11 link, falling in the problem we are trying to resolve.
I made the following test: PC1 connected by a 802.11 link to one AP,
connected by 802.3 to a second PC. I sent a 0 byte ping packet sent
from PC1 to PC2, and after sniffing it in PC2, I got a DIX frame
(source MAC=PC1 mac,dest MAC=PC2). Is this a general AP behavior (i.e.
choosing DIX framing) ?
In this scenario the problem of padding isn't resolved because we
can't force bridges to use the Ethernet encapsulation of our choice
_WITHOUT_ changing the bridges software/firmware or some kind of
reconfiguration (if the bridge allows such reconfiguration).

So, unless I'm missing some major point, choosing an encapsulation
isn't enough. If that is the case, please fill me in on the pieces of
the puzzle that I'm missing.

Best Regards,
Pedro Fortuna
======================================
Pedro Fortuna <pfortuna_at_dei.isep.ipp.pt>, <pedro.fortuna_at_gmail.com>
Computer Engineering Department, ISEP-IPP
Polytechnic Institute of Porto
Rua Dr. António Bernardino de Almeida 431
P-4200-072 Porto - PORTUGAL
www: http://www.dei.isep.ipp.pt/~pfortuna/
Office Phone: +351 22 8340500 Ext. 1775
Fax: +351 228321159
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Pedro Fortuna <[email-masked]>
Date: Wed, 8 Dec 2004 01:23:43 +0000

Dear Carsten,

Scenario 1

Scenario 2

Best Regards,
Pedro Fortuna

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Dec 2004 08:57:16 +0100

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

---

From: Pedro Fortuna <[email-masked]>
Date: Mon, 20 Dec 2004 16:15:16 +0000

Hi Carsten,

Sorry for not answering sooner. I've read again my previous email, and
think I wasn't clear in some parts, and also I've found some errors
that might have led to some confusion. My fault! Anyway, you addressed
the issue I was trying to focus.

> So the AP will simply not have that choice.
This is what I was trying to say. No matter what encapsulation variant
is chosen, the solution will only work if the AP is forced to use the
chosen variant. This can only be achieved by changing in the embedded
software running on the AP's. My question is: can this be avoided in
any way?

Merry Christmas to all ROHCers :)

Best Regards,
Pedro Fortuna

====================================================
A revised and smaller version of my previous e-mail:
I've carefully read the draft but there is an issue regarding possible
changes in the software running in bridges that should be addressed.

To demonstrate my point, I provide a couple of example scenarios.
Let's say that we come to the conclusion that 802.3 LLC+SNAP
encapsulation is the best solution for addressing the padding problem
(I'm not trying to say that it is, I'm just using it as an example of
a possible solution).

Scenario 1 (See attached gif)
______                  ____________                   ______
|  PC1 |==802.3==|  802.3/802.11 |~~802.11~~|  PC2  |
|_____|                 | ___bridge____|                  |_____|

PC1 sends RoHC packets encapsulated with 802.3 LLC+SNAP. The packets
arrive to the bridge where padding, if any, is stripped by the bridge,
and then the RoHC payload is sent to PC2 with 802.11 Link Layer
encapsulation. This scenario works because we can make PC1 send frames
with the desired encapsulation. Also, changes to the embedded software
running in the bridge are not necessary.

Scenario 2 (See attached gif)
_____                   ___________                  ___________      
            _____
| PC1 |~~802.11~~| 802.11/802.3|==802.3==|802.3/802.11|~~802.11~~| PC2 |
|____|                   |___bridge___|                 |___bridge__| 
                 |____|

In this scenario, we have two PC's connected to 2 different AP's,
interconnected by a 802.3 link. In this scenario PC1 sends RoHC
packets with 802.11 Link Layer encapsulation. The packets arrive to
the bridge (with no padding), and at this point the bridge must choose
an Ethernet encapsulation type and add padding if necessary. The
problem is that, unless changes are made to the embedded software
running at the AP, it will always choose to use DIX Frames, thus
making it impossible for the second bridge to tell if the DIX Frames
carry padding or not, propagating the padding to the 802.11 link.