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

Carsten Bormann <cabo@tzi.org> Mon, 13 December 2004 15:18 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 KAA17860 for <rohc-web-archive@ietf.org>; Mon, 13 Dec 2004 10:18:00 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cds5P-0000Rx-9x for rohc-web-archive@ietf.org; Mon, 13 Dec 2004 10:26:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdrfI-0000R6-BE; Mon, 13 Dec 2004 09:59:08 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdrWE-0004ar-2y for rohc@megatron.ietf.org; Mon, 13 Dec 2004 09:49:46 -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 JAA15437 for <rohc@ietf.org>; Mon, 13 Dec 2004 09:49:44 -0500 (EST)
Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdre3-0008Bp-4N for rohc@ietf.org; Mon, 13 Dec 2004 09:57:51 -0500
Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id iBDEncXl020809; Mon, 13 Dec 2004 15:49:39 +0100 (MET)
In-Reply-To: <Pine.LNX.4.56.0411261659040.30341@internaut.com>
References: <Pine.LNX.4.56.0411261659040.30341@internaut.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <388536D0-4D16-11D9-A805-000A95DC4DB6@tzi.org>
Content-Transfer-Encoding: 7bit
From: Carsten Bormann <cabo@tzi.org>
Subject: Re: [rohc] Review of draft-bormann-rohc-over-802-00.txt
Date: Mon, 13 Dec 2004 15:49:41 +0100
To: Bernard Aboba <aboba@internaut.com>, rohc@ietf.org
X-Mailer: Apple Mail (2.619)
X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Content-Transfer-Encoding: 7bit
Cc: Carsten Bormann <cabo@tzi.org>
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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: 963faf56c3a5b6715f0b71b66181e01a
Content-Transfer-Encoding: 7bit

Bernard,
ROHCers,

I would like to thank Bernard again for his review.
We had a little offline mail exchange about this earlier.
I hadn't seen Bernard's copy of the review to the ROHC mailing list, so  
now here is my belated (and expanded) copy of the comments I already  
made in private mail.

> Here's my review.  There may be some tricky issues to watch out for  
> with
> respect to negotiation of ROHC capabilities on IEEE 802 networks that
> may make it difficult to achieve the desired level of uniformity.

We haven't really tackled the negotiation at all yet.
After a few experiments with our lab selection of 802.11 base stations,  
I believe there will be a need for some robustness features that are  
needed to make sure the elements in the 802 path are not doing strange  
things to sub-64-byte packets.
One problem with this is, of course, that the L2 path can change.

> Also, as noted by Mike Moreton:
>
> "The IEEE RAC gets very upset about anyone using OUIs in a non-standard
> way, so I doubt you'd get a lot of support for using the
> locally administered or I/G bits to distinguish your frames.  However,
> 802.11 already uses a full LLC/SNAP header, so using such
> a header would be fine for 802.11, and as you say elsewhere probably
> wouldn't make a great deal of difference for 802.3.

Well, 802.11 is using a SNAP header for Ethernet type packets, and can  
send other LLC natively.
If we use native LLC, we might get a shorter header than full SNAP.
This is what variant 1 and 2 in section 5 are about (variant 3 is full  
SNAP).
The variant 2 you are rightly criticizing is more of a last resort if  
using a different LSAP does not work out, though.

You are right, however, that the sentence about variant 3 "From an  
overhead perspective, this is not better than the PPPoE case..." is  
correct only for 802.3.

> I think the padding issue is interesting - it's funny how a drop-off in
> the original Ethernet specification is still causing us
> problems all these years later..."

Yes...

On to Bernard's review.

My original comment was:

> Some of the issues you have identified with the document are caused by  
> my negligence in making the terminology clear.
> E.g., where I talk about a "channel", I mean a "ROHC channel", which  
> in the architecture I'm proposing would likely encompass an 802.11 and  
> an 802.3 path segment.
> This is quite different from an architecture where ROHC would be  
> *below* the 802.1 bridging and thus would be implemented within the L2  
> nodes (access points/bridges), not just in the L2 interface of L3  
> nodes (hosts and routers) as I'm proposing.
> So, e.g., when I talk about setup/teardown, I mean the L3-node to  
> L3-node channel, not the L2 path segments like the 802.11 links.
>
> I propose that, before we seek wider review (and liaising with 802),  
> I'll try to make the document more accessible and clarify these  
> issues; again, your input is very useful here.
> I would like to keep some of the discussion material in the document,  
> perhaps more clearly identified as material that is going away before  
> the spec is completed.
>
> One specific question: When you talk about 802 invariants, where are  
> these documented?
> (I'm not talking about sequence preservation, which we actually need  
> to make ROHC in its current form work.)
> I'm seeing quite significant losses (and retransmission delays) in  
> today's 802.11 networks.
> In fact, once the link becomes lossy, it *also* acquires unpredictable  
> (though, fortunately, limited) delays.
> (The queueing delays, of course, also can be significant.)
> This is why my intuition says CRTP-style compression is less useful on  
> WLAN than ROHC-style compression.

to which Bernard replied:

>> So, e.g., when I talk about setup/teardown, I mean the L3-node to
>> L3-node channel, not the L2 path segments like the 802.11 links.
>
> Thanks.  If we're talking about ROHC capabilities negotiation between  
> L3
> endpoints (e.g. over IP) that will get around the issues with
> heterogeneity in IEEE 802 discovery facilities.
>
>> One specific question: When you talk about 802 invariants, where are
>> these documented?
>
> A good reference on IEEE 802 link invariants is "The Switch Book" by  
> Rich
> Seifert. Section 2.2.1 discusses "hard" invariants (non duplication and
> sequential delivery) and "soft" invariants (low error rate, high
> bandwidth, low delay).  See:
> http://www.amazon.com/exec/obidos/ASIN/0471345865/argospress-20/103 
> -5896643-7439011?creative=327641&camp=14573&link_code=as1
>
>> I'm seeing quite significant losses (and retransmission delays) in
>> today's 802.11 networks.
>> In fact, once the link becomes lossy, it *also* acquires unpredictable
>> (though, fortunately, limited) delays.
>
> In an indoor network, these issues are typically due to multi-path
> problems or coverage blackholes, exacerbated by poor implementations.
> In outdoor networks, the problems are more common.  For example, see:
> http://www.pdos.lcs.mit.edu/~rtm/papers/p442-aguayo.pdf
>
> Aspects of 802.11 behavior are not standardized, including roaming
> behavior and rate negotiation.  This means, for example, that some  
> 802.11
> NICs will retransmit for long periods of time before detecting that the
> connection has failed and scanning for another AP.  Even under  
> conditions
> of extreme congestion it is rare to require more than 3  
> retransmissions,
> and if the Beacon signal is missing in addition, there is little point  
> in
> continuing.  Yet, in our experiments we have seen NICs retransmit as  
> long
> as 30 seconds before scanning.

I assume fine-tuning ROHC-over-802 for existing 802.11 networks will  
require some more experiments and measurements akin to those that we  
did about LLC bridging in APs.

On to some more specific comments in the original review:

> [BA] 802.11 Access Points are not bridges as defined by 802.1D.  For
> example, they are not required to run spanning tree, do not maintain
> learning tables as specified in 802.1D, etc.

I believe this mainly identifies a terminology problem.  I need a term  
for all these bridge-like devices that are intermediate systems in the  
L2 paths we are trying to cross undamaged (and unpadded).
Any suggestion?

> [BA] Note that 802 links are only required to preserve ordering within
> a given 802.1p priority group.

Very good point; I'll add this.
(By comparison, RFC 3241 says:
    ROHC assumes that the link layer delivers packets in sequence.  PPP
    normally does not reorder packets.  When using reordering mechanisms
    such as multiclass multilink PPP [RFC2686], care must be taken so
    that packets that share the same compression context are not
    reordered.  (Note that in certain cases, reordering may be acceptable
    to ROHC, such as within a sequence of packets that all do not change
    the decompression context.)
)

There were a couple more comments similar to:

> [BA] Since it can be argued that knowledge of ROHC capabilities could  
> be
> relevant to 802.11 roaming decisions, it may not be possible to handle
> ROHC capability discovery in a generic manner for all IEEE 802 media.

If we stick with the "compression at L3-L2 boundary" model, this  
becomes a CARD/AR selection issue, I think.
Outside of 802 itself.

> [BA] LLC encapsulation does make sense to me since this is most general
> (e.g. works on 802.11 as well as 802.3).  I'd like to get more review
> comments on this from the IEEE 802 folks.

Yes, please!

I'll generate a -01 based on the discussion we had so far by this  
weekend.
I hope this will be clearer about the place in the architecture and  
more specific about the encapsulation considerations.
This might then be a good basis to try to elicit more feedback.

Gruesse, Carsten


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