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
- [rohc] Review of draft-bormann-rohc-over-802-00.t… Bernard Aboba
- [rohc] Re: Review of draft-bormann-rohc-over-802-… Carsten Bormann
- Re: [rohc] Re: Review of draft-bormann-rohc-over-… Pedro Fortuna
- Re: [rohc] Re: Review of draft-bormann-rohc-over-… Pedro Fortuna
- Re: [rohc] Re: Review of draft-bormann-rohc-over-… Carsten Bormann
- Re: [rohc] Review of draft-bormann-rohc-over-802-… Carsten Bormann
- Re: [rohc] Re: Review of draft-bormann-rohc-over-… Pedro Fortuna
- Re: [rohc] question about draft-bormann-rohc-over… Ana Minaburo
- Re: [rohc] question about draft-bormann-rohc-over… Pedro Fortuna
- Re: [rohc] question about draft-bormann-rohc-over… Ana Minaburo
- Re: [rohc] question about draft-bormann-rohc-over… Pedro Fortuna
- Re: [rohc] question about draft-bormann-rohc-over… Carsten Bormann
- Re: [rohc] question about draft-bormann-rohc-over… Pedro Fortuna
- Re: [rohc] question about draft-bormann-rohc-over… Carsten Bormann