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

Joe Touch <touch@ISI.EDU> Thu, 03 August 2006 17:41 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G8hBy-0001s2-Em; Thu, 03 Aug 2006 13:41:06 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G8hBx-0001rx-Ew for; Thu, 03 Aug 2006 13:41:05 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G8hBw-0001dS-3l for; Thu, 03 Aug 2006 13:41:05 -0400
Received: from [] ( []) by (8.11.6p2+0917/8.11.2) with ESMTP id k73HeIY25408; Thu, 3 Aug 2006 10:40:18 -0700 (PDT)
Message-ID: <>
Date: Thu, 03 Aug 2006 10:42:11 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
To: Lars Eggert <>
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="------------enig4D595E84610FA5B7F3188A44"
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: Aaron Falk <falk@ISI.EDU>,
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: <>, <>

Lars Eggert wrote:
> Hi,
> On Aug 2, 2006, at 22:29, Bob Briscoe wrote:
>> Basically, I'm saying
>> a) Instead of signalling "something's changed", I believe it is more
>> practical to continuously signal the "something".
> That's an interesting observation. By constantly providing the raw
> information, it is up to the transports to decide what difference
> constitutes a "change" vs. having the network layer decide that a
> "change" has occurred. It also allows transports to process the raw
> information into events any way they see fit, instead of assuming one
> specific way at the layer below.

So you have congestion. It affects, e.g., only TCP port 80. The network
layer doesn't know that, so it continually tells every transport layer
that congestion has occurred. It's blathering that something needs to be
done, when in fact only one protocol really sees any change.

And congestion can change without affecting latency, and vice-versa. How
do you know what to send the transport? How do you know what it cares about?

The network can't measure *transport* latency, which is what the
transport layer really cares about. Something specific like "the network
layer has lower RTTs right now" assumes that this matters to the
transport layer; it really doesn't, e.g., if the transport on the other
end has larger latency at the same time (due to transport processing load).

I don't much care what the network layer tells the transport; it's the
transport's obligation to verify whether it sees the same thing, or in
fact what it sees anyway.

IMO, 'please re-check the network now' is the primary signal of
interest. Everything else "goes to intent" and makes the network layer
(in this case) recapitulate what it *thinks* the transport layer wants,
 and that isn't particularly informative.

(FWIW, the same is true for link/net interactions)