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

Lars Eggert <> Sat, 29 July 2006 09:14 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G6ktc-0004hy-OR; Sat, 29 Jul 2006 05:14:08 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G6kta-0004ht-S4 for; Sat, 29 Jul 2006 05:14:06 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G6ktZ-0001uv-BA for; Sat, 29 Jul 2006 05:14:06 -0400
Received: from lars.local ( []) by (Postfix) with ESMTP id 32E321BAC4D; Sat, 29 Jul 2006 10:57:44 +0200 (CEST)
Received: from [] (localhost []) by lars.local (Postfix) with ESMTP id 7D2BD15F4FB; Sat, 29 Jul 2006 11:14:03 +0200 (CEST)
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-38--236417908; protocol="application/pkcs7-signature"
Message-Id: <>
From: Lars Eggert <>
Subject: Re: [TERNLI] Notes from tonight's ad hoc
Date: Sat, 29 Jul 2006 11:14:00 +0200
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
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: <>, <>


On Jul 29, 2006, at 3:23, Joe Touch wrote:
> 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.

this is probably one of the most precise - and concise - descriptions  
of the idea we've been kicking around I've see so far.

Also, we've so far mostly thought about the network/transport  
interface and what additional information could be passed across it  
that would allow some new response mechanisms at the transport layer  
to improve performance. However, the principle of extending  
interfaces in this way - as you've summarized above - can also be  
applied to the link/network and transport/application interface. The  
link/network part is to some degree looked at by mobopts (although  
maybe not following the approach identified above). I'm unaware of  
extensions to the transport/app interface.

Finally, this discussion has mostly talked about moving information  
of a certain kind up the stack in a certain way. Someone (Mark  
Handley?) had pointed out that the reverse direction may also be  
important to look at. Your text above can be read to apply to both  
directions, which is nice.

Lars Eggert                                     NEC Network Laboratories