Re: The internet architecture

[Rémi Després <remi.despres at free.fr>]

Title: Re: The internet architecture

John Day  -  le (m/j/a) 12/29/08 4:24 PM:

No it isFrom ietf-bounces at ietf.org Mon Dec 29 08:07:05 2008 Return-Path: X-Original-To: ietf-archive at megatron.ietf.org Delivered-To: ietfarch-ietf-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B352F3A68C5; Mon, 29 Dec 2008 08:07:05 -0800 (PST) X-Original-To: ietf at core3.amsl.com Delivered-To: ietf at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87CFA28C21E for ; Mon, 29 Dec 2008 08:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSaVu1Fm-kWJ for ; Mon, 29 Dec 2008 08:07:03 -0800 (PST) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by core3.amsl.com (Postfix) with ESMTP id 7E7483A68B9 for ; Mon, 29 Dec 2008 08:07:03 -0800 (PST) Received: from smtp1-g21.free.fr (unknown [212.27.42.1]) by postfix2-g20.free.fr (Postfix) with ESMTP id BBD572E625E6 for ; Mon, 29 Dec 2008 15:06:38 +0100 (CET) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 65EB058C; Mon, 29 Dec 2008 17:06:43 +0100 (CET) Received: from RD.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp1-g21.free.fr (Postfix) with ESMTP id 377C131D; Mon, 29 Dec 2008 17:06:40 +0100 (CET) Message-ID: <4958F519.1060008 at free.fr> Date: Mon, 29 Dec 2008 17:04:41 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: John Day Subject: Re: The internet architecture References: <20081130151159.418826BE571 at mercury.lcs.mit.edu> <676530.29665.qm at web31814. mail.mud.yahoo.com> <49494DC8.1020503 at employees.org> <2093978A-667A-498B-BD6 9-B75ABC17E732 at gmail.com> <2EB8416D-799A-4F17-AA19-412E0DD49010 at let.de> <661D82BF-2C24-4152-B395-8793E57CD3C5 at let.d e> <2788466ED3E31C418E9ACC5C316615572FFC36 at mou1wnexmb09.vcorp.ad.vrsn.com> <3EFC6F1A8324616A9DE63869 at p3.int.jck.com> <4958CF2B.1050302 at free.fr> In-Reply-To: Cc: John C Klensin , Bryan Ford , ietf at ietf.org X-BeenThere: ietf at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0536418860==" Sender: ietf-bounces at ietf.org Errors-To: ietf-bounces at ietf.org

Title: Re: The internet architecture

John Day  -  le (m/j/a) 12/29/08 4:24 PM:

No it isn't Trann't Transport's job.  Transport has one and only one purpose: end-to-end reliability and flow control.

"Managing" the resources of the network is the network layer's job.

Reliably... and also efficiently.
To transmit as fast as possible, including with load sharing among several parallel paths, the flow control function (i.e. the transport layer, right?) has, in my understanding, to know how many address couples it uses.

Whether the transport layer can delegate some of its flow control function to an intermediate layer is IMO a terminology question.

Although, these distinctions of Network and Transport Layer are . . . shall we say, quaint.

Yes, indeed.

Multihoming is fundamentally a routing problem.  SCTP tries to claim to solve it by changing the definition, an old trick.

I am not sure what the two definitions are.
Being more specific would be helpful.

... Multihoming has nothing to do with what has traditionally been called the "Transport Layer."

It is a problem of routing not be able to recognize that two points of attachment go to the same place. ...

In my understanding, knowing that two locators are those of  a common destination is  the normal result from getting these locators by translation of an identifier, e.g. a domain name.

RD

At 14:22 +0100 2008/12/29, Rémi Després wrote:

John,

To pick a local interface for an outgoing connection isn't the transport layer, e.g. SCTP, well placed to do the job (or some intermediate layer function like Shim6)?
Thus, ordinary applications wouldn't need to be concerned.

RD

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf