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

Joe Touch <touch@ISI.EDU> Sat, 29 July 2006 01:24 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G6dZ1-00084J-MT; Fri, 28 Jul 2006 21:24:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G6dZ0-00084B-AZ for; Fri, 28 Jul 2006 21:24:22 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G6dYy-0005Qd-Vk for; Fri, 28 Jul 2006 21:24:22 -0400
Received: from [] ( []) by (8.11.6p2+0917/8.11.2) with ESMTP id k6T1N8Y29332; Fri, 28 Jul 2006 18:23:08 -0700 (PDT)
Message-ID: <>
Date: Fri, 28 Jul 2006 18:23:02 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
Subject: Re: [TERNLI] Notes from tonight's ad hoc
References: <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB81CC137C7A015550693110"
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc:, Michael Welzl <>
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: <>, <>

Mark Allman wrote:
> I am not quite sure if I agree with (or understand)  everything you
> said, Joe.  But, ...
>> IMO, the most interesting question is "why are you saying this", and
>> "is this the right information to pass between these two layers". The
>> network can't care that the modulation changed (that's a link/physical
>> issue), but it can care about what that means (latency changed, error
>> rate changed, etc.).
> this is basically what I was trying to get at, but put much better.
> I see it as somewhat of a balancing act.  We don't want to give
> information that another layer just cannot do anything with, but we also
> don't want to get too narrow or prescriptive either.

Right. I like the idea of "only give info that you think the next layer
can use", but not "tell the next layer what you want it to do". Also,
the information passed ought to be something that makes sense in the
context of the next layer, e.g., tell the network layer about a path
property, not about a link technology, etc.