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

Pedro Fortuna <pedro.fortuna@gmail.com> Mon, 20 December 2004 16:20 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13576 for <rohc-web-archive@ietf.org>; Mon, 20 Dec 2004 11:20:51 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgQQW-0004zv-MV for rohc-web-archive@ietf.org; Mon, 20 Dec 2004 11:30:30 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgQFT-0004M9-J1; Mon, 20 Dec 2004 11:19:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgQBq-0003ka-VC for rohc@megatron.ietf.org; Mon, 20 Dec 2004 11:15:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12539 for <rohc@ietf.org>; Mon, 20 Dec 2004 11:15:16 -0500 (EST)
Received: from mproxy.gmail.com ([216.239.56.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgQL8-0004iU-1w for rohc@ietf.org; Mon, 20 Dec 2004 11:24:55 -0500
Received: by mproxy.gmail.com with SMTP id q44so57709cwc for <rohc@ietf.org>; Mon, 20 Dec 2004 08:15:16 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DM7IhskZbOyWNOmmzDuNDeq6zPLN9szu7Cdxk/ZuFEuZZKZtr1CNDt7ch1S1gRLHMCND29gQj4p524/x2jsL57q6ih8Vp5V1yHIKX8eRi1kPTiet1Mhqt1ANYtpF1ck1mfhMPeB90sUk8TkoNiyHdle94X9vs5DfLom9KmOxmZ4=
Received: by 10.11.116.77 with SMTP id o77mr208961cwc; Mon, 20 Dec 2004 08:15:16 -0800 (PST)
Received: by 10.11.99.49 with HTTP; Mon, 20 Dec 2004 08:15:16 -0800 (PST)
Message-ID: <db95d40c04122008155a0416fe@mail.gmail.com>
Date: Mon, 20 Dec 2004 16:15:16 +0000
From: Pedro Fortuna <pedro.fortuna@gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: [rohc] Re: Review of draft-bormann-rohc-over-802-00.txt
In-Reply-To: <C7666E10-48EE-11D9-B3CF-000A95DC4DB6@tzi.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_788_4470748.1103559316093"
References: <3F2E01E1D7B04F4EBEC92D3FA324D8803857FC@rsys004a.roke.co.uk> <550877E8-420B-11D9-82C1-000A95DC4DB6@tzi.org> <db95d40c0412071707b0c2e1b@mail.gmail.com> <C7666E10-48EE-11D9-B3CF-000A95DC4DB6@tzi.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c
Cc: "rohc@ietf.org" <rohc@ietf.org>
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Pedro Fortuna <pedro.fortuna@gmail.com>
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b

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.



On Wed, 8 Dec 2004 08:57:16 +0100, Carsten Bormann <cabo@tzi.org> wrote:
> 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