Re: [tcpm] Is this a problem?

Ethan Blanton <eblanton@cs.ohiou.edu> Wed, 21 November 2007 14:23 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqUg-0000FR-8A; Wed, 21 Nov 2007 09:23:58 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuqUf-0000D0-OT for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:23:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqUf-0000Cr-Bh for tcpm@ietf.org; Wed, 21 Nov 2007 09:23:57 -0500
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqUe-0002Lx-VO for tcpm@ietf.org; Wed, 21 Nov 2007 09:23:57 -0500
Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from <eblanton@cs.ohiou.edu>) id 1IuqUY-000ImD-Ff for tcpm@ietf.org; Wed, 21 Nov 2007 14:23:56 +0000
Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 121CF2BE21 for <tcpm@ietf.org>; Wed, 21 Nov 2007 09:23:47 -0500 (EST)
Received: by colt.internal (Postfix, from userid 3000) id 487E92840D; Wed, 21 Nov 2007 09:23:47 -0500 (EST)
Date: Wed, 21 Nov 2007 09:23:47 -0500
From: Ethan Blanton <eblanton@cs.ohiou.edu>
To: tcpm@ietf.org
Subject: Re: [tcpm] Is this a problem?
Message-ID: <20071121142347.GS5881@elb.elitists.net>
Mail-Followup-To: tcpm@ietf.org
References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> <200711210655.GAA05704@cisco.com>
MIME-Version: 1.0
In-Reply-To: <200711210655.GAA05704@cisco.com>
X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: -103.9 (---------------------------------------------------)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2073048442=="
Errors-To: tcpm-bounces@ietf.org

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.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm