Re: [tcpm] Is this a problem?

Ted Faber <faber@ISI.EDU> Wed, 21 November 2007 17:19 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IutEX-000059-LE; Wed, 21 Nov 2007 12:19:29 -0500
Received: from tcpm by with local (Exim 4.43) id 1IutEW-000054-RO for; Wed, 21 Nov 2007 12:19:28 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IutEW-00004w-Fh for; Wed, 21 Nov 2007 12:19:28 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IutEV-0000Pm-UI for; Wed, 21 Nov 2007 12:19:28 -0500
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id lALHEFph011763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Wed, 21 Nov 2007 09:14:16 -0800 (PST)
Received: (from faber@localhost) by (8.14.2/8.14.2/Submit) id lALHEFwD014168 for; Wed, 21 Nov 2007 09:14:15 -0800 (PST) (envelope-from faber)
Date: Wed, 21 Nov 2007 09:14:15 -0800
From: Ted Faber <faber@ISI.EDU>
Subject: Re: [tcpm] Is this a problem?
Message-ID: <>
References: <> <> <> <> <> <> <> <>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1634763297=="

On Wed, Nov 21, 2007 at 09:23:47AM -0500, Ethan Blanton wrote:
> Lloyd Wood spake unto us the following wisdom:
> > At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote:
> > >Joe keeps making this point because it is _very important_.  Any
> > >feature which can be accomplished at Layer N can be accomplished at
> > >Layer N - 1, and vice-versa.  
> > 
> > One obvious exception: end-to-end reliabililty.
> > 
> > Another: error-coding for the channel.
> Not to digress, but ... I think this makes the argument beautifully.
> Either of these *can* be handled at any layer, but we obviously agree
> that it's a Bad Idea to push these all the way down to the MAC layer.
> There is nothing magical about layering, that says "a protocol can
> only work if layered".  Separation of concerns simply makes the model
> easier to grasp, and easier to Get Right.
> We could do end-to-end flow control, reliability, and link
> error-coding all in Layer 1 (or Layer 2, depending on which way you
> want to push), but we don't, and for a very good reason.

[hat off]

I think that any layer that can accomplish end-to-end reliability is
a transport layer by definition.

A link layer capable of end-to-end retransmission (say) is inherently
reaching beyond the link.  You could call such a layer a link layer, but
the presence of an end-to-end mechanism makes it a transport layer to

I actually think your functionality statement is a little backward -
anything you can do at layer N, you can do above at layer N+1.  That's
because the information to implement the new feature is potentially
available from the lower layers.  An application can implement
end-to-end reliability because the end-to-end structures/concepts are
created by the transport.

Implementing at layer N+1 also assumes that there's no implementation of
the functionality at layer N that will interfere with your design.
Implementing a retransmission strategy above TCP is fraught with peril.

Perhaps that's a way to reframe this discussion.  It's possible to
constrain TCP to provide this timer.  Are we sure that it's worth it in
terms of additional complexity in TCP and constraints on other
application resource management strategies?

Ted Faber           PGP:
Unexpected attachment on this mail? See
tcpm mailing list