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

Michael Welzl <Michael.Welzl@uibk.ac.at> Fri, 28 July 2006 12:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6R6c-0007Nk-MO; Fri, 28 Jul 2006 08:06:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6R6c-0007Nf-0k for ternli@ietf.org; Fri, 28 Jul 2006 08:06:14 -0400
Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6R6a-0004mK-D2 for ternli@ietf.org; Fri, 28 Jul 2006 08:06:13 -0400
Received: from localhost (lwm2.uibk.ac.at [138.232.1.161]) by smtp.uibk.ac.at (8.13.1/8.13.1/F1) with ESMTP id k6SC64kF016421; Fri, 28 Jul 2006 14:06:04 +0200
Received: from 30-6-248.wireless.csail.mit.edu (30-6-248.wireless.csail.mit.edu [128.30.6.248]) by web-mail2.uibk.ac.at (IMP) with HTTP for <c70370@mail1.uibk.ac.at>; Fri, 28 Jul 2006 14:06:04 +0200
Message-ID: <1154088364.44c9fdac35be3@web-mail2.uibk.ac.at>
Date: Fri, 28 Jul 2006 14:06:04 +0200
From: Michael Welzl <Michael.Welzl@uibk.ac.at>
To: mallman@icir.org
Subject: Re: [TERNLI] Notes from tonight's ad hoc
References: <20060728114353.275FB444296@lawyers.icir.org>
In-Reply-To: <20060728114353.275FB444296@lawyers.icir.org>
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-Originating-IP: 128.30.6.248
X-Forwarded-For:
X-Spam-Score: -7.4 () ALL_TRUSTED,RCV_SMTP_UIBK,RCV_WEBMAIL
X-Scanned-By: MIMEDefang 2.52 at uibk.ac.at on 138.232.1.140
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

> > 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.

Cheers,
Michael