Re: [TERNLI] Notes from tonight's ad hoc

Michael Welzl <> Fri, 28 July 2006 12:06 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G6R6c-0007Nk-MO; Fri, 28 Jul 2006 08:06:14 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G6R6c-0007Nf-0k for; Fri, 28 Jul 2006 08:06:14 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1G6R6a-0004mK-D2 for; Fri, 28 Jul 2006 08:06:13 -0400
Received: from localhost ( []) by (8.13.1/8.13.1/F1) with ESMTP id k6SC64kF016421; Fri, 28 Jul 2006 14:06:04 +0200
Received: from ( []) by (IMP) with HTTP for <>; Fri, 28 Jul 2006 14:06:04 +0200
Message-ID: <>
Date: Fri, 28 Jul 2006 14:06:04 +0200
From: Michael Welzl <>
Subject: Re: [TERNLI] Notes from tonight's ad hoc
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.6
X-Scanned-By: MIMEDefang 2.52 at on
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> > 802.16 also has adaptive modulation and coding that alter the rate of
> > the channel and may vary as the distance between a base station and
> > subscriber station changes.  Adaptive coding is common for satellite
> > links as well.  It seems like this type of event could be useful to
> > signal if it resulted in more than a doubling or halving of capacity, as
> > a simple filter.
> One way to look at this is that the "type of event" is not at all
> important to communicate.  The real thing to get across is the available
> capacity has changed somewhat dramatically.  Does it really matter if
> this is because 802.11 dropped us from 11mbps to 2mbps or some BoD
> system just allocated us a ton of capacity or we moved much closer to
> some access point / basestation and now have a much better signal?
> Does this make sense?

A lot!

I was about to say something similar in case the discussion
would have moved further in this direction (signaling irrelevant
details about link layer occurrences to the transport layer).
I think that any comunication from lower layers up to the
transport layer should be converted to a transport-layer-related
format (where we're interested in things such as the RTT,
capacity (even though this is usually not available at the
transport layer - but it's an upper limit, so why not
communicate it?), all kinds of traffic related information
(e.g. imminent sudden growth), ...).

I don't want to turn this into an acedemic exercise - all
I'm suggesting is to think in such terms when looking at
link layer events that should somehow be communicated to
the endpoints.