Re: [TERNLI] question about layer focus

Joe Touch <touch@ISI.EDU> Tue, 13 June 2006 17:08 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FqCNB-0002fC-No; Tue, 13 Jun 2006 13:08:13 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FqCNB-0002f7-8w for; Tue, 13 Jun 2006 13:08:13 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FqCN9-0006UM-U2 for; Tue, 13 Jun 2006 13:08:13 -0400
Received: from [] ( []) by (8.11.6p2+0917/8.11.2) with ESMTP id k5DH7c612003; Tue, 13 Jun 2006 10:07:38 -0700 (PDT)
Message-ID: <>
Date: Tue, 13 Jun 2006 10:07:32 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20060516)
MIME-Version: 1.0
Subject: Re: [TERNLI] question about layer focus
References: <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFB3DFAFB6EA68D05D16C071"
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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: <>, <>

Wesley Eddy wrote:
> On Tue, Jun 13, 2006 at 09:03:02AM -0700, Joe Touch wrote:
>> Hi, all,
>> I noticed that the BOF title and description focuses on transport
>> interactions with network layer indications.
>> However, some of the background reading suggests link-transport
>> interaction. IMO, this has been the previous issue with some previous
>> attempts near this solution space; is this difference being addressed in
>> this BOF, or is the BOF setting a boundary (i.e., only transport-net and
>> net-link are allowed, but not transport-link?)
> I think one idea that some people share is that while transport-link has
> been used pretty frequently, implementing these hacks doesn't scale as
> the number of link technologies with subtle differences grows, and so it
> is architecturally vital to transition to a transport-net model where
> link-independent signals are passed.

It's more than that, IMO. Any property that is of a link, rather than of
a path, is inappropriate to expose to the transport layer. There are
current exceptions that are based on 'best guess', i.e., starting PMTU
at the MTU of the first link hop as a starting point; that's fine, as
would any other similar starting guess. However, I think of that as a
guess that could as easily have been passed through the layers (i.e.,
the network layer indicates that all paths originating from this IP
address start with the MTU of its link, passing that then from the net
to the transport).