From touch at isi.edu Mon Feb 10 18:31:35 2014 From: touch at isi.edu (Joe Touch) Date: Mon, 10 Feb 2014 18:31:35 -0800 Subject: [e2e] Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> Message-ID: <52F98B87.6060004@isi.edu> On 1/11/2014 3:40 AM, Jon Crowcroft wrote: > In missive <52D04B36.9010005 at web.de>, Detlef Bosau typed: > > >>I would like to discuss the talk > >>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf > >>given by John Day. > >> > >>What do you think, e.g., of the claim > >>> ??? > >>> TCP was split in the Wrong Direction! > >>> ??? It is one layer, not two. > > should have been 3 - as per the transport services work - its clear > you need a sublayer convergence (as per day's work) I disagree. There are three layers, but it's TCP that's incomplete. I don't at all understand the difference between a "network layer" and an "internetwork layer". I.e., the current layers are: TCP + the pseudoheader (derived from the IP layer) the endpoint IDs here combine the IP address and TCP ports IP (the internetworking layer) endpoints = IP addresses link endpoints = link addresses I have no idea what a 'network' layer is that is different from what we currently call the link layer. Links layers *are* networks (Ethernet, SONET, etc.), except when there's no network at all (point-to-point links that need no L2). > but also the > socket layer needs revising badly to allow for a wider set of > transport service semantics than came out of the fast > hack that bbn and berkeley did The real 'disconnect' (pun intended) is that TCP uses the initial SYN destination port as both a service identifier and as part of the connection demultiplexer (i.e., address at the TCP layer), (see http://tools.ietf.org/html/draft-touch-tcpm-sno-00) *and* that both TCP and IP layers use IP addresses as part of their endpoint IDs (vs. having unique TCP endpoint addresses). If there are additional semantics needed, IMO there is the need for an additional layer and demultiplexer (at whatever layer you need that semantics). Joe From touch at isi.edu Mon Feb 10 18:37:49 2014 From: touch at isi.edu (Joe Touch) Date: Mon, 10 Feb 2014 18:37:49 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <52F98B87.6060004@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> Message-ID: <52F98CFD.70909@isi.edu> On 2/10/2014 6:31 PM, Joe Touch wrote: > I have no idea what a 'network' layer is that is different from what we > currently call the link layer. Links layers *are* networks (Ethernet, > SONET, etc.), except when there's no network at all (point-to-point > links that need no L2). PS - I disagree that the layer that's missing is the "AS" layer. If that's what you really want, then you get that using a recursive network layer - e.g., LISP. The result is precisely what happens if you add a true networking layer below IP but above ethernet. And it includes the baggage that it should - of cross-domain resolution for encapsulation. See http://www.isi.edu/rna/ Joe From jnc at mercury.lcs.mit.edu Mon Feb 10 20:11:57 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Feb 2014 23:11:57 -0500 (EST) Subject: [e2e] Lost Layer? Message-ID: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> > From: Joe Touch > I don't at all understand the difference between a "network layer" and > an "internetwork layer". ATM stuff, etc = 'network layer'. (Or, reaching further back, ARPANET stuff.) IPvN = 'internetwork layer'. > I have no idea what a 'network' layer is that is different from what we > currently call the link layer. The thing is that for more complex networks (like ATM, ARPANET, etc) you have 'link' layers which are lower/more-local than the system-wide 'network' layer. For example, in the ARPANET example, ISTR that one of the interface modes involved using an HDLC link to talk to the IMP. On top of that one ran 1822 headers (with the destination IMP/port, etc); the latter being the 'network' layer. Not all situations include a network layer. Most often (especially these days), the internetwork layer runs directly on top of the link layer. But sometimes there's a network layer sandwiched in there too. Not so much any more, though, because with the increasing prevalence of internetworking protocols, there's no real use for a network layer - it's just replication of functionality, usually. So people just run the internetwork layer directly on top of the link layer, and the functionality that would usually be supplied by the network layer (e.g. path selection across the 'subnetwork', in the older sense of that word - not to be confused with IPvN 'subnets') is supplied by the internetwork layer instead. Noel From gds at gds.best.vwh.net Tue Feb 11 00:17:19 2014 From: gds at gds.best.vwh.net (Greg Skinner) Date: Tue, 11 Feb 2014 08:17:19 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu>; from jnc@mercury.lcs.mit.edu on Mon, Feb 10, 2014 at 11:11:57PM -0500 References: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> Message-ID: <20140211081719.A53735@gds.best.vwh.net> On Mon, Feb 10, 2014 at 11:11:57PM -0500, Noel Chiappa wrote: > > From: Joe Touch > > > I don't at all understand the difference between a "network layer" and > > an "internetwork layer". > > ATM stuff, etc = 'network layer'. (Or, reaching further back, ARPANET stuff.) > > IPvN = 'internetwork layer'. > > > I have no idea what a 'network' layer is that is different from what we > > currently call the link layer. > > The thing is that for more complex networks (like ATM, ARPANET, etc) you have > 'link' layers which are lower/more-local than the system-wide 'network' layer. > > For example, in the ARPANET example, ISTR that one of the interface modes > involved using an HDLC link to talk to the IMP. On top of that one ran 1822 > headers (with the destination IMP/port, etc); the latter being the 'network' > layer. Correct. It was called HDH. There's a short description of it in http://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n9.1. --gregbo From Jon.Crowcroft at cl.cam.ac.uk Tue Feb 11 00:53:13 2014 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 11 Feb 2014 08:53:13 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> References: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> Message-ID: yes, but for the fact that MOST things now have a net later as well as a link layer in fact, because most the world is either in a data center or on a cellular data net, and both have topology that is manged by routingthat runs below the IP layer and is tech specific - sure, some peopel call the datacenter (common) case L2 routing, but its still a network since there are (loads of) switches and topology maintenance - even more so with cellular - indeed, when you roam, you're internetworking at the cel layer too so all those recursive layering lessons come home to roost the other net layer stuff that happened in the "old days" when IP ran on complicated interconnects of a single kind was traffic management (e.g. link layer flow control and reliability in the x.25 and arpanet cases) which again shows up today in cellular and data center (where 'orrible 'acks 'ave to be perpertrated with fancy interframe ethernet delays to solve tcp incast problems) not that I am saying this is good mecessarily, just that it keeps re-emergeing - of course with SDN and NVF stuff, its all moot what is a layer (it always was, but now its explicit again) "i am not a layer, nor do i play one on iptv" might be a sig we could put here.. In missive <20140211041157.7F5E518C0CA at mercury.lcs.mit.edu>, Noel Chiappa typed : >> > From: Joe Touch >> >> > I don't at all understand the difference between a "network layer" and >> > an "internetwork layer". >> >>ATM stuff, etc = 'network layer'. (Or, reaching further back, ARPANET stuff.) >> >>IPvN = 'internetwork layer'. >> >> > I have no idea what a 'network' layer is that is different from what we >> > currently call the link layer. >> >>The thing is that for more complex networks (like ATM, ARPANET, etc) you have >>'link' layers which are lower/more-local than the system-wide 'network' layer. >> >>For example, in the ARPANET example, ISTR that one of the interface modes >>involved using an HDLC link to talk to the IMP. On top of that one ran 1822 >>headers (with the destination IMP/port, etc); the latter being the 'network' >>layer. >> >>Not all situations include a network layer. Most often (especially these >>days), the internetwork layer runs directly on top of the link layer. But >>sometimes there's a network layer sandwiched in there too. >> >>Not so much any more, though, because with the increasing prevalence of >>internetworking protocols, there's no real use for a network layer - it's >>just replication of functionality, usually. So people just run the >>internetwork layer directly on top of the link layer, and the functionality >>that would usually be supplied by the network layer (e.g. path selection >>across the 'subnetwork', in the older sense of that word - not to be confused >>with IPvN 'subnets') is supplied by the internetwork layer instead. >> >> Noel cheers jon From l.wood at surrey.ac.uk Tue Feb 11 00:57:13 2014 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Tue, 11 Feb 2014 08:57:13 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <52F98B87.6060004@isi.edu> References: <52D04B36.9010005@web.de> ,<52F98B87.6060004@isi.edu> Message-ID: <290E20B455C66743BE178C5C84F1240847E633470B@EXMB01CMS.surrey.ac.uk> says Joe: > I have no idea what a 'network' layer is that is different from what we > currently call the link layer. RFC3819/BCP 89, which Joe wrote, calls ATM stuff etc. "subnetworks". Which is to say, Joe wasn't calling them link layers then. Lloyd Wood http://about.me/lloydwood ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Joe Touch [touch at ISI.EDU] Sent: 11 February 2014 02:31 To: Jon Crowcroft; Detlef Bosau Cc: Subject: Re: [e2e] Lost Layer? On 1/11/2014 3:40 AM, Jon Crowcroft wrote: > In missive <52D04B36.9010005 at web.de>, Detlef Bosau typed: > > >>I would like to discuss the talk > >>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf > >>given by John Day. > >> > >>What do you think, e.g., of the claim > >>> ??? > >>> TCP was split in the Wrong Direction! > >>> ??? It is one layer, not two. > > should have been 3 - as per the transport services work - its clear > you need a sublayer convergence (as per day's work) I disagree. There are three layers, but it's TCP that's incomplete. I don't at all understand the difference between a "network layer" and an "internetwork layer". I.e., the current layers are: TCP + the pseudoheader (derived from the IP layer) the endpoint IDs here combine the IP address and TCP ports IP (the internetworking layer) endpoints = IP addresses link endpoints = link addresses I have no idea what a 'network' layer is that is different from what we currently call the link layer. Links layers *are* networks (Ethernet, SONET, etc.), except when there's no network at all (point-to-point links that need no L2). > but also the > socket layer needs revising badly to allow for a wider set of > transport service semantics than came out of the fast > hack that bbn and berkeley did The real 'disconnect' (pun intended) is that TCP uses the initial SYN destination port as both a service identifier and as part of the connection demultiplexer (i.e., address at the TCP layer), (see http://tools.ietf.org/html/draft-touch-tcpm-sno-00) *and* that both TCP and IP layers use IP addresses as part of their endpoint IDs (vs. having unique TCP endpoint addresses). If there are additional semantics needed, IMO there is the need for an additional layer and demultiplexer (at whatever layer you need that semantics). Joe From fred at cisco.com Tue Feb 11 01:09:46 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Tue, 11 Feb 2014 09:09:46 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <52F98B87.6060004@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> Message-ID: <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> On Feb 10, 2014, at 6:31 PM, Joe Touch wrote: > There are three layers, but it's TCP that's incomplete. I don't at all understand the difference between a "network layer" and an "internetwork layer". Well, the deal is that layers can be sub-layered. Yes, the Internetwork layer is perhaps unfortunately named, in that it doesn't always interconnect networks. But it comes down to this. First, consider that each layer answers a fundamental question. The physical layer provides the physical interconnect between a system and a neighboring system. The Link Layer provides the interpretation of signals on the physical medium connecting neighboring systems. The network layer connects a system to another system that it is not necessarily directly connected to. The Transport Layer provides needed services end to end across that network. In TCP's case, the service is that of a sequential, reliable, octets stream; in the case of UDP... SCTP..., and so on. In real operational networks, in 2014, we have at least three common sub-layers within the network layer. One is what we call the Internetwork Layer and should be called, perhaps, the Inter-network sub-layer. It provides the end to end datagram service that TCP and other transports ride atop. Another might, by analogy, be called the Intra-network sublayer. It connects systems that are not necessarily directly connected, but use the same technology and are operated by a common administration. Switched Ethernets, 802.11 networks, MPLS, ATM, Frame Relay, and X.25 are all examples of Intra-network protocols. And then there is what one might call the virtualization sublayer, which is when, whatever we call it, we use an IP tunnel between the Internetwork and Intranetwork layers. Static IP/IP and GRE/IP tunnels, LISP, Mobile IP, L2TP, ... They all do the same basic function: the connect systems that are not necessarily directly connected (and so are in the network layer), providing a service to the transport. > The real 'disconnect' (pun intended) is that TCP uses the initial SYN destination port as both a service identifier and as part of the connection demultiplexer (i.e., address at the TCP layer), (see http://tools.ietf.org/html/draft-touch-tcpm-sno-00) > > *and* that both TCP and IP layers use IP addresses as part of their endpoint IDs (vs. having unique TCP endpoint addresses). Well, I suspect that what is needed is a counterpart to Courier, something that would let an incoming TCP-or-whatever session identify the application it wants to connect to and would identify the connecting party, so that ports could simply be random numbers identifying sessions. The, I imagine, is something that the XNS Internet Transport got right, or a little more right than the IP folks did. I agree that the concept of location should not be part of the end to end session identifier; it's pretty useful in the IP address, because an IP address first gets a packet to a location and then to an interface at that location, but having done that, it's irrelevant. From l.wood at surrey.ac.uk Tue Feb 11 04:24:40 2014 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Tue, 11 Feb 2014 12:24:40 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu>, <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> Message-ID: <290E20B455C66743BE178C5C84F1240847E633470C@EXMB01CMS.surrey.ac.uk> > Well, the deal is that layers can be sub-layered I am reminded of Orman's SIGCOMM'99 outrageous opinion slides http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/orman-outrageous-opinion.pdf alas, in monochrome. Lloyd Wood http://about.me/lloydwood "fill the whole world with a rainbow!" ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Fred Baker (fred) [fred at cisco.com] Sent: 11 February 2014 09:09 To: Joe Touch Cc: Detlef Bosau; Jon Crowcroft; Subject: Re: [e2e] Lost Layer? On Feb 10, 2014, at 6:31 PM, Joe Touch wrote: > There are three layers, but it's TCP that's incomplete. I don't at all understand the difference between a "network layer" and an "internetwork layer". Well, the deal is that layers can be sub-layered. Yes, the Internetwork layer is perhaps unfortunately named, in that it doesn't always interconnect networks. But it comes down to this. First, consider that each layer answers a fundamental question. The physical layer provides the physical interconnect between a system and a neighboring system. The Link Layer provides the interpretation of signals on the physical medium connecting neighboring systems. The network layer connects a system to another system that it is not necessarily directly connected to. The Transport Layer provides needed services end to end across that network. In TCP's case, the service is that of a sequential, reliable, octets stream; in the case of UDP... SCTP..., and so on. In real operational networks, in 2014, we have at least three common sub-layers within the network layer. One is what we call the Internetwork Layer and should be called, perhaps, the Inter-network sub-layer. It provides the end to end datagram service that TCP and other transports ride atop. Another might, by analogy, be called the Intra-network sublayer. It connects systems that are not necessarily directly connected, but use the same technology and are operated by a common administration. Switched Ethernets, 802.11 networks, MPLS, ATM, Frame Relay, and X.25 are all examples of Intra-network protocols. And then there is what one might call the virtualization sublayer, which is when, whatever we call it, we use an IP tunnel between the Internetwork and Intranetwork layers. Static IP/IP and GRE/IP tunnels, LISP, Mobile IP, L2TP, ... They all do the same basic function: the connect systems that are not necessarily directly connected (and so are in the network layer), providing a service to the transport. > The real 'disconnect' (pun intended) is that TCP uses the initial SYN destination port as both a service identifier and as part of the connection demultiplexer (i.e., address at the TCP layer), (see http://tools.ietf.org/html/draft-touch-tcpm-sno-00) > > *and* that both TCP and IP layers use IP addresses as part of their endpoint IDs (vs. having unique TCP endpoint addresses). Well, I suspect that what is needed is a counterpart to Courier, something that would let an incoming TCP-or-whatever session identify the application it wants to connect to and would identify the connecting party, so that ports could simply be random numbers identifying sessions. The, I imagine, is something that the XNS Internet Transport got right, or a little more right than the IP folks did. I agree that the concept of location should not be part of the end to end session identifier; it's pretty useful in the IP address, because an IP address first gets a packet to a location and then to an interface at that location, but having done that, it's irrelevant. From detlef.bosau at web.de Tue Feb 11 05:41:15 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Feb 2014 14:41:15 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52F98B87.6060004@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> Message-ID: <52FA287B.3090104@web.de> Am 11.02.2014 03:31, schrieb Joe Touch: > > > On 1/11/2014 3:40 AM, Jon Crowcroft wrote: >> In missive <52D04B36.9010005 at web.de>, Detlef Bosau typed: >> >> >>I would like to discuss the talk >> >>http://rina.tssg.org/docs/JohnDay-LostLayer120306.pdf >> >>given by John Day. >> >> >> >>What do you think, e.g., of the claim >> >>> ??? >> >>> TCP was split in the Wrong Direction! >> >>> ??? It is one layer, not two. >> >> should have been 3 - as per the transport services work - its clear >> you need a sublayer convergence (as per day's work) > > I disagree. > > There are three layers, but it's TCP that's incomplete. I don't at all > understand the difference between a "network layer" and an > "internetwork layer". > > I.e., the current layers are: > > TCP + the pseudoheader (derived from the IP layer) > the endpoint IDs here combine the IP > address and TCP ports > > IP (the internetworking layer) > endpoints = IP addresses > > link > endpoints = link addresses > > I have no idea what a 'network' layer is that is different from what > we currently call the link layer. And you are not the only one to have this problem. When you have a look at @article{cerf, title={ Protocol for Packet Network Intercommunication}, author={V.~ Cerf and R.~Kahn}, journal={IEEE Transactions on Communications}, month= "May", year= "1974", volume = "22", number = "5", pages = "637-- 648" } Cerf and Kahn had the same problem - and that's the reason for our problems until today. For about 40 years now, our "TCP System Model" is Sender --------------------- Pipeline ------------------------------- Receiver. That "Pipeline" can be a network path in a packet switched network is simply ignored. Cerf in RFC 675: > We specifically assume that fragments are transmitted from Host to > Host through means of a PACKET SWITCHING NETWORK [PSN] [ROWE70, > POUZ73]. This assumption is probably unnecessary, since a circuit > switched network could also be used, but for concreteness, we > explicitly assume that the hosts are connected to one or more PACKET > SWITCHES [PS] of a PSN [HEKA7O, POUZ74, SCWI71] To make my comment as concise as possible: Ouch. (in other words: Refer to RFC 675 and you find the lost layer. It is exactly the layer which Vint Cerf ignored.) BTW: A look in RFC 896 and Nagle's algorithem exhibits, that eventually someone told to the community that we talk about (infinite) flows and not about (finite) messages. (a note to John Day: You sometimes refer to Metcalf and his remark, networking would be interprocess communication. In conjunction with the quote from Cerf, this is exactly the reason why we don't have a functional congestion control. We repeat the same misconceptions for 40 years now.) From touch at isi.edu Tue Feb 11 06:17:00 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 06:17:00 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633470B@EXMB01CMS.surrey.ac.uk> References: <52D04B36.9010005@web.de> , <52F98B87.6060004@isi.edu> <290E20B455C66743BE178C5C84F1240847E633470B@EXMB01CMS.surrey.ac.uk> Message-ID: <52FA30DC.1060204@isi.edu> On 2/11/2014 12:57 AM, l.wood at surrey.ac.uk wrote: > says Joe: >> I have no idea what a 'network' layer is that is different from what we >> currently call the link layer. > > RFC3819/BCP 89, which Joe wrote, calls ATM stuff etc. "subnetworks". > > Which is to say, Joe wasn't calling them link layers then. The abstract explains that "subnetwork" is RFC-speak for the link layer: This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks)... Joe From touch at isi.edu Tue Feb 11 06:29:20 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 06:29:20 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> Message-ID: <52FA33C0.8010702@isi.edu> On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: > In real operational networks, in 2014, we have at least three common > sub-layers within the network layer. One is what we call the > Internetwork Layer and should be called, perhaps, the Inter-network > sub-layer. It provides the end to end datagram service that TCP and > other transports ride atop. ... The layer that TCP rides over that spans heterogeneous network technologies is IP, the Internet(working) layer. > ...Another might, by analogy, be called the > Intra-network sublayer. It connects systems that are not necessarily > directly connected, but use the same technology and are operated by a > common administration.Switched Ethernets, 802.11 networks, MPLS, > ATM, Frame Relay, and X.25 are all examples of Intra-network > protocols. In ISO that's the link layer (the Internet originally called these subnetworks), the homogeneous network technology span. > And then there is what one might call the virtualization > sublayer, which is when, whatever we call it, we use an IP tunnel > between the Internetwork and Intranetwork layers. Static IP/IP and > GRE/IP tunnels, LISP, Mobile IP, L2TP, Tunnels don't map to any static definition of layers, exactly because they can always be placed between any pair of layers - including other tunnel layers. A tunnel is link, not a network. A set of tunnels can represent a network to the layer above it. This last reality is why it's so easy to get tunneling wrong. E.g., a tunnel can transit a "largest" packet - which defines the tunnel MTU; that MTU is *not* the 'largest unfragmented message' that can transit the tunnel. We don't have a concept of 'natural chunksize', and confusion between that and the largest message transmissible is the reason for a lot of really badly crafted tunnel specs. So all these layers end up being defined by the layer above and the layer below, e.g., if IP runs over them, they had better act a lot like what RFC3819 expects, or things will (and do) work badly. (that relative relationship is what RNA is all about). Joe From touch at isi.edu Tue Feb 11 06:39:36 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 06:39:36 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> Message-ID: <52FA3628.50007@isi.edu> On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: > > On Feb 10, 2014, at 6:31 PM, Joe Touch wrote: > >> There are three layers, but it's TCP that's incomplete. I don't at >> all understand the difference between a "network layer" and an >> "internetwork layer". > > Well, the deal is that layers can be sub-layered. If you mean that every layer expects similar things from the layer below, I agree (that's RNA). It expects a way to transit a set of nodes using a path, and accepts that there will need to be a way to map nodes at the upper layer to nodes at the lower layer (e.g., resolution, ala Google, BGP, and ARP, depending on what layer you look at). > Yes, the > Internetwork layer is perhaps unfortunately named, in that it doesn't > always interconnect networks. But you can't tell the difference when it isn't. > But it comes down to this. > > First, consider that each layer answers a fundamental question. Each answers exactly the same fundamental question - how do I transit hops at my layer using what I think are links at my layer, by using what look like hops and links that are really a service provided by the next layer down. > The > physical layer provides the physical interconnect between a system and a > neighboring system. The physical layer is just the base case where the signal receives this 'service' from a real, physical entity. > The Link Layer provides the interpretation of > signals on the physical medium connecting neighboring systems. That translation of format can happen at every layer in a stack of layers. It happens when tunnels encrypt/decrypt. It happens when a stream of messages are FEC encoded. It happens when we stripe over different channels to emulate a mega-channel. > The > network layer connects a system to another system that it is not > necessarily directly connected to. That happens at every layer, because every layer can include forwarding. Link layers forward, and transport layers can relay (forward) too. > The Transport Layer provides needed > services end to end across that network. That's what IP provides across different link layers. It's what a link layer provides over separate physical connections. Again, all the same. > In TCP's case, the service is > that of a sequential, reliable, octets stream; in the case of UDP... > SCTP..., and so on. And SONET provides a stream over frames. Ethernet provides packet relay over packet links, as does IP. Joe From touch at isi.edu Tue Feb 11 06:56:58 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 06:56:58 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> References: <20140211041157.7F5E518C0CA@mercury.lcs.mit.edu> Message-ID: <52FA3A3A.9010901@isi.edu> On 2/10/2014 8:11 PM, Noel Chiappa wrote: > > I don't at all understand the difference between a "network layer" and > > an "internetwork layer". > > ATM stuff, etc = 'network layer'. (Or, reaching further back, ARPANET stuff.) The Internet docs call that a subnetwork layer, which is RFC-speak for what the ISO calls the link layer. > IPvN = 'internetwork layer'. Which is what ISO calls the network layer, which is why I map the two as equal. You can argue that the ISO link layer is the Internet "network" layer, but that's not what the Internet specs call that layer. Joe From touch at isi.edu Tue Feb 11 07:10:35 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 07:10:35 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <52FA287B.3090104@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> Message-ID: <52FA3D6B.5040309@isi.edu> On 2/11/2014 5:41 AM, Detlef Bosau wrote: > Am 11.02.2014 03:31, schrieb Joe Touch: ... >> I have no idea what a 'network' layer is that is different from what >> we currently call the link layer. > > And you are not the only one to have this problem. > > When you have a look at > @article{cerf, > title={ Protocol for Packet Network Intercommunication}, > author={V.~ Cerf and R.~Kahn}, > journal={IEEE Transactions on Communications}, > month= "May", > year= "1974", > volume = "22", > number = "5", > pages = "637-- 648" > } At that time, the terminology was in flux. By the mid-1980s, it had settled as: Internet ISO application layer app, presentation, & session layers transport layer transport layer Internet layer network layer subnetwork layer link layer The other ISO layers were often buried inside the Internet's app layer, though they're now split out (e.g., for the web HTTP is a session layer, HTML a presentation layer, and the content the app layer). And we now (I hope) understand (or are starting to) that all the layers are really just relative to each other. All are just copies of the single step that wraps a lot of the ISO layers into a single function: layer (message, from-addr, to-addr) { if (my-location == to-addr) then { return } else { next-message = translate(message, nextlayer), i.e., translate the message to a format for the next layer, including any/all of: error correction flow control congestion control data content translation data format conversion fragment/reassembly translate this layer's identifiers to the next's: next-from = lookup(from-addr, nextlayer); next-to = lookup(to-addr, nextlayer); recurse: layer(next-message, next-from, next-to); } } (note that forwarding is just tail recursion of this function). Joe From snoeren at cs.ucsd.edu Mon Feb 10 20:41:48 2014 From: snoeren at cs.ucsd.edu (Alex C. Snoeren) Date: Mon, 10 Feb 2014 20:41:48 -0800 Subject: [e2e] CFP: IEEE Micro Special Issue: High-Speed Data Center Interconnects Message-ID: <7E23767F-97CC-45C2-B1B1-58EC154078DE@cs.ucsd.edu> ==================================================== IEEE Micro Special Issue: High-Speed Data Center Interconnects George Papen, George Porter, Alex C. Snoeren (UCSD), Guest Editors SUBMISSION DEADLINE: MARCH 7, 2014 ==================================================== The demands being placed upon datacenter networks continue to expand along a number of dimensions. Today?s massive datacenters interconnect tens to hundreds of thousands of machines while attempting to deliver high bisection bandwidths and low latency under practical power and cost constraints. Meeting these challenges is becoming increasingly difficult as the port speed of individual server NICs moves past 10 Gbps. Next-generation Ethernet specifications focus on delivering aggregate bandwidth through multiple parallel channels, and call for link rates of 100 Gbps, 400 Gbps, and beyond. Moreover, disruptive changes at the end host such as disaggregated server designs have the potential to dramatically change traffic demands. Designing cost-effective scalable interconnect technologies at these speeds is an open challenge. Both academic and industrial researchers are actively exploring new control planes that attempt to harness the incredible capacity of these next-generation network fabrics while still delivering reasonable levels of utilization and performance. These approaches are pushing the boundaries of what is currently understood regarding both traditional and software-defined networking (SDN) technologies, including how to leverage fast programmable TCAMs, optical transport, and even on- board server NIC capacity. Designing practical high-speed interconnects to deliver on the promise of next-generation data centers and cloud-based computing calls for new architectural advances. This IEEE Micro special issue seeks original papers on a range of topics related to such interconnects. Areas of interest include, but are not limited to: ? Highly scalable data center network designs ? Novel and innovative interconnect architectures ? NIC designs supporting 100 Gbps and beyond ? The applicability of merchant silicon to next-generation network designs ? Reliability and fault tolerance in data center networks ? Hybrid interconnect designs, relying on wireless and/or optical circuit switching ? Control planes based on software designed networking (SDN) ? Processor design implications of high-speed data center interconnect Important dates: Initial submissions due: March 7, 2014 Author notification: April 30, 2014 Final version due: June 23, 2014 Publication timeframe: Sept-Oct 2014 Submission procedure: Log onto IEEE CS Manuscript Central ( https://mc.manuscriptcentral.com/micro-cs) and submit your manuscript. Please direct questions to the IEEE Micro magazine assistant (micro-ma at computer.org). For the manuscript submission, acceptable file formats include Microsoft Word and PDF. Manuscripts should not exceed 5,000 words including references, with each average-size figure counting as 150 words toward this limit. Please include all figures and tables, as well as a cover page with author contact information (name, postal address, phone, fax, and e-mail address) and a 200-word abstract. Submitted manuscripts must not have been previously published or currently submitted for publication elsewhere, and all manuscripts must be cleared for publication. All previously published papers must have at least 30% new content compared to any conference (or other) publication. Accepted articles will be edited for structure, style, clarity, and readability. For more information, please visit the IEEE Micro Author Center (http://www2.computer.org/portal/web/peerreviewmagazines/acmicro) Questions? Contact the guest editors: ieee-micro-dc-editors at sysnet.ucsd.edu From jnc at mercury.lcs.mit.edu Tue Feb 11 08:09:29 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 11 Feb 2014 11:09:29 -0500 (EST) Subject: [e2e] Lost Layer? Message-ID: <20140211160929.CAC1E18C0D2@mercury.lcs.mit.edu> > From: Joe Touch >> IPvN = 'internetwork layer'. > Which is what ISO calls the network layer, which is why I map the two > as equal. There are (at least) three layers there. If you persist in trying to name them with only two names, you will of course run into insuperable Procustean difficulties. > From: Jon Crowcroft > MOST things now have a net later as well as a link layer in fact, > because most the world is either in a data center or on a cellular data > net, and both have topology that is manged by routing that runs below > the IP layer and is tech specific I'd forgotten all about mobile! Amazing how the world has come full circle and we once again have complex (subnetwork-wide) network layers underneath the internetwork layer. (To me, a sign that the internetwork layer architecture is lacking in functionality/capability/flexibility... but I digress.) I'm not sure I'd go so far as to say 'most' as I think a lot of home links don't have a complex network layer, since they are often via CATV (and, in more advance plant, fiber to the home) - but then again, a lot of home links are via DSL, and I don't know how that's carried inside the ISPs these days (it used to be ATM), so perhaps your 'most' is correct. Noel From fred at cisco.com Tue Feb 11 10:47:00 2014 From: fred at cisco.com (Fred Baker (fred)) Date: Tue, 11 Feb 2014 18:47:00 +0000 Subject: [e2e] Lost Layer? In-Reply-To: <52FA33C0.8010702@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> Message-ID: <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> On Feb 11, 2014, at 6:29 AM, Joe Touch wrote: > > > On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: >> In real operational networks, in 2014, we have at least three common >> sub-layers within the network layer. One is what we call the >> Internetwork Layer and should be called, perhaps, the Inter-network >> sub-layer. It provides the end to end datagram service that TCP and >> other transports ride atop. ... > > The layer that TCP rides over that spans heterogeneous network technologies is IP, the Internet(working) layer. > >> ...Another might, by analogy, be called the >> Intra-network sublayer. It connects systems that are not necessarily >> directly connected, but use the same technology and are operated by a >> common administration.Switched Ethernets, 802.11 networks, MPLS, >> ATM, Frame Relay, and X.25 are all examples of Intra-network >> protocols. > > In ISO that's the link layer (the Internet originally called these subnetworks), the homogeneous network technology span. Actually, no. In IEEE/ANSI politics circa 1985, there was an understanding that the network layer belonged to ANSI, and the link layer belonged to IEEE. IEEE 802 started work on 802.1 through 802.5, including two different ways to build networks out of what at the time were called Packet Repeaters or Bridges. They bypassed the understanding by calling them MAC Layer bridges, and they justified the appellation by noting that the bridges operated on the link layer header, whether transparently or by source-route bridging. X.25 was a place where the nomenclature battle was fought heavily. In Europe, X.25 was, at the time, *the* network, and the definitive network layer. To the ARPA folks, it was an API that allowed someone to inject a packet into a network; it might come out a different API that was not X.25. In CSNET, IP ran atop X.25, and IP was the API that allowed someone to select which X.25 destination they might go to. Get over it. X.25 is a network, and the Internet is a Network, and one often runs over the other. As in X.25/TCP/IP/CSNET and other bizarre things. ISO had nothing to do with that. >> And then there is what one might call the virtualization >> sublayer, which is when, whatever we call it, we use an IP tunnel >> between the Internetwork and Intranetwork layers. Static IP/IP and >> GRE/IP tunnels, LISP, Mobile IP, L2TP, > > Tunnels don't map to any static definition of layers, exactly because they can always be placed between any pair of layers - including other tunnel layers. A tunnel is link, not a network. A set of tunnels can represent a network to the layer above it. > > This last reality is why it's so easy to get tunneling wrong. E.g., a tunnel can transit a "largest" packet - which defines the tunnel MTU; that MTU is *not* the 'largest unfragmented message' that can transit the tunnel. We don't have a concept of 'natural chunksize', and confusion between that and the largest message transmissible is the reason for a lot of really badly crafted tunnel specs. > > So all these layers end up being defined by the layer above and the layer below, e.g., if IP runs over them, they had better act a lot like what RFC3819 expects, or things will (and do) work badly. (that relative relationship is what RNA is all about). > > Joe > ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies From touch at isi.edu Tue Feb 11 11:24:12 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 11:24:12 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> Message-ID: <52FA78DC.4030909@isi.edu> On 2/11/2014 10:47 AM, Fred Baker (fred) wrote: > > On Feb 11, 2014, at 6:29 AM, Joe Touch > wrote: > >> >> >> On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: >>> In real operational networks, in 2014, we have at least three common >>> sub-layers within the network layer. One is what we call the >>> Internetwork Layer and should be called, perhaps, the Inter-network >>> sub-layer. It provides the end to end datagram service that TCP and >>> other transports ride atop. ... >> >> The layer that TCP rides over that spans heterogeneous network technologies is IP, the Internet(working) layer. >> >>> ...Another might, by analogy, be called the >>> Intra-network sublayer. It connects systems that are not necessarily >>> directly connected, but use the same technology and are operated by a >>> common administration.Switched Ethernets, 802.11 networks, MPLS, >>> ATM, Frame Relay, and X.25 are all examples of Intra-network >>> protocols. >> >> In ISO that's the link layer (the Internet originally called these >> subnetworks), the homogeneous network technology span. > > Actually, no. > > In IEEE/ANSI politics circa 1985, there was an understanding that > thenetwork layer belonged to ANSI, and the link layer belonged to IEEE. Neither of which being the ISO. Now you're just adding yet another set of groups that use terminology differently. > IEEE 802 started work on 802.1 through 802.5, including two different > ways to build networks out of what at the time were called Packet > Repeaters or Bridges. They bypassed the understanding by calling them > MAC Layer bridges, and they justified the appellation by noting that the > bridges operated on the link layer header, whether transparently or by > source-route bridging. To the Internet, that's all subnet, not network. > X.25 was a place where the nomenclature battle was fought heavily. > InEurope, X.25 was, at the time, *the* network, and the definitive network > layer. Sure, and there's also ATM folk who entered the fray in the late 1980s too. Not to mention SONET, which is a network too (it has a multihop path). > To the ARPA folks, it was an API that allowed someone to inject a > packet into a network; it might come out a different API that was not > X.25. Sure, because what IP thought of as a subnet included translation gateways rather than using strict layering. All bets are off when you "cross the streams" that way (conceptually, as well as literally). > In CSNET, IP ran atop X.25, and IP was the API that allowed > someone to select which X.25 destination they might go to. IP decided which IP destination they went to. Somebody mapped that to X.25 locations (either dynamically, ala ARP, or statically), but they were selecting IP addresses. If the API involved selecting X.25 destinations, then they served two different purposes (and could easily have had different values): something like DNS names (that translate to IP address), and something like ARP (to map back to X.25 for layering). > Get over it. X.25 is a network, and the Internet is a Network, and > oneoften runs over the other. As in X.25/TCP/IP/CSNET and other bizarre things. Sure. They're all "networks". But when we talk about the "network layer" in the Internet architecture, it refers to IP. The stuff IP runs over is the subnet layer, and the stuff that runs over IP is the transport layer. > ISO had nothing to do with that. Sure - I was mapping the Internet layer names and ISO names; throw more organizations into the mix and the translation matrix gets more complex and more overloaded. Joe From jeanjour at comcast.net Tue Feb 11 11:50:55 2014 From: jeanjour at comcast.net (John Day) Date: Tue, 11 Feb 2014 14:50:55 -0500 Subject: [e2e] Fwd: Re: Historical question: Link layer flow control / silent discard Message-ID: Apparently, one must repeat explanations to rectify misconceptions about the past. The accounts today exhibit the same errors that they did 7 months ago. >X-CAA-SPAM: 00000 >Date: Wed, 29 May 2013 12:04:41 -0400 >To: Joe Touch , John Day >From: John Day >Subject: Re: [e2e] Historical question: Link layer flow control / silent > discard >Cc: braden at isi.edu, end2end-interest at postel.org > >OSI divided the Network Layer into 3 sub-layers (not all of which >were present for all networks): 3a Subnet Access, 3b Subnet >Dependent, and 3c Subnet Independent. (see the Internal >Organization of the Network Layer, ISO 8648). > >X.25 was (according to its title) 3a Subnet Access. The PTTs had >the "foresight" ;-) to call it a Data-Terminating-Equipment (DTE) to >Data Communicating Equipment (DCE) interface. (Don't you love the >nomenclature!) X.25 was just at the boundary of the network. In >other words, Host to Network protocol, the equivalent of BBN1822! >;-) So OSI took them at their word. ;-) If the network had X.25, >then it was at 3a. > >Whether a PTT used X.25 internal to its network was its business and >not within the purview of CCITT. I believe most X.25 networks at >the time heavily modified it beyond what the Recommendation said. >(CCITT's habit of defining its recommendations as the interfaces >between boxes is why I refer to this as the beads-on-a-string model! >boxes strung together with a wire!) > >With X.25, LAPB (also known as HDLC) was the Data Link Layer. > >CLNP was 3c, Subnet Independent. > >One can think of 3a/3b as a traditional network layer for networks >that had that; and 3c/Transport as the Internet Layer. 3c >addresses were global, while addresses in 3a/3b were only >unambiguous within the network. Think of 3a/3b as points of >attachment addresses, and 3c as node addresses. (see the Saltzer >paper RFC 1498 for background on this) > >Take care, >John > >At 8:31 AM -0700 5/29/13, Joe Touch wrote: >>On 5/28/2013 2:02 PM, John Day wrote: >>>Just for the record and then I will let this discussion go on, but X.25 >>>was not at the core of the OSI Model. >> >>FWIW, there was an implementation of ISO - ISODE (the ISO >>development environment). UPenn was snail-mailing out 9-track tapes >>and 8mm cassettes back in the early 90's when I was there. I still >>have one of the enamel pins. >> >>It implemented layers 3-6, and could be configured to run over X.25 >>- thus the possible confusion that X.25 was its L2. >> >>Joe From detlef.bosau at web.de Tue Feb 11 12:25:54 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Feb 2014 21:25:54 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA3D6B.5040309@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> Message-ID: <52FA8752.8030804@web.de> Am 11.02.2014 16:10, schrieb Joe Touch: > > > On 2/11/2014 5:41 AM, Detlef Bosau wrote: >> Am 11.02.2014 03:31, schrieb Joe Touch: > ... >>> I have no idea what a 'network' layer is that is different from what >>> we currently call the link layer. >> >> And you are not the only one to have this problem. >> >> When you have a look at >> @article{cerf, >> title={ Protocol for Packet Network Intercommunication}, >> author={V.~ Cerf and R.~Kahn}, >> journal={IEEE Transactions on Communications}, >> month= "May", >> year= "1974", >> volume = "22", >> number = "5", >> pages = "637-- 648" >> } > > At that time, the terminology was in flux. Isn't it today? And I well try to understand thins in their temporal context. However, I think that an "entity" (not necessarily "layer") flow, as it is known in multimedia architectures, is useful here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Feb 11 12:49:40 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Feb 2014 21:49:40 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA3D6B.5040309@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> Message-ID: <52FA8CE4.8060809@web.de> However, don't you agree that the basic system model in a TCP connection is sill Endpoint 1 -------------------- Pipe -------------------------- Endpoint 2 ? We can well discuss the nature of the "Pipe", particularly the correspondence CWND = Pipe's capacity. (As you may see: I well put the end 2 end principle in question....., however I think this is acceptable. @DPR: IIRC, you said yourself: Science is about asking questions and finding answers.) From dhc2 at dcrocker.net Tue Feb 11 12:59:08 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 11 Feb 2014 12:59:08 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <52F98CFD.70909@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52F98CFD.70909@isi.edu> Message-ID: <52FA8F1C.80904@dcrocker.net> > PS - I disagree that the layer that's missing is the "AS" layer. > > If that's what you really want, then you get that using a recursive > network layer - e.g., LISP. Looking at this latest sequence of notes on this thread, I think that what's missing is any sort of summary problem statement, put into essentially non-technical, functional terms, without directing the answer. By non-technical, I don't mean anything as extreme as prohibiting reference to layers or the like, but that functional separation needs to be described in very basic terms, with an explanation of what major improvement is achieved by satisfying that need. For reference, "multi-homing" is an example of an appealing need, but it's too broad a concept. For example, host multi-homing versus net multi-homing is an important basic distinction. Similarly for mobility. The different styles of mobility can get solved in /very/ different ways, for different host functions. So it's important to clarify. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From touch at isi.edu Tue Feb 11 13:11:55 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 13:11:55 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <52FA8CE4.8060809@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> <52FA8CE4.8060809@web.de> Message-ID: <52FA921B.2010600@isi.edu> On 2/11/2014 12:49 PM, Detlef Bosau wrote: > However, don't you agree that the basic system model in a TCP connection > is sill > > Endpoint 1 -------------------- Pipe > -------------------------- Endpoint 2 Yes, TCP presents a service of a reliable ordered bytestream between two endpoints. > We can well discuss the nature of the "Pipe", particularly the > correspondence CWND = Pipe's capacity. The 'capacity' of the pipe is an ill-defined term; it can mean: - amount of sustained throughput through the pipe - amount of data stored temporarily inside the pipe as a side-effect of efficient communication i.e., the average sustained throughput * average E2E delay CWND-MAX is usually set to the latter of these as one optimization, but there are others for which that might not be true. CWND is a part of currently specified TCP congestion control, but not the only means nor necessarily the optimium. Joe From richard at bennett.com Tue Feb 11 13:20:36 2014 From: richard at bennett.com (Richard Bennett) Date: Tue, 11 Feb 2014 13:20:36 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> Message-ID: <52FA9424.9060603@bennett.com> Mobile makes this a relevant issue today and in the future. There's a lot of functional richness below IP, without which IP datagrams would never get delivered. Personally, I've always regarded IP as a stub or a placeholder for a real protocol, but I don't think APIs and protocols are interchangeable. RB On 2/11/14, 10:47 AM, Fred Baker (fred) wrote: > On Feb 11, 2014, at 6:29 AM, Joe Touch > wrote: > >> >> On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: >>> In real operational networks, in 2014, we have at least three common >>> sub-layers within the network layer. One is what we call the >>> Internetwork Layer and should be called, perhaps, the Inter-network >>> sub-layer. It provides the end to end datagram service that TCP and >>> other transports ride atop. ... >> The layer that TCP rides over that spans heterogeneous network technologies is IP, the Internet(working) layer. >> >>> ...Another might, by analogy, be called the >>> Intra-network sublayer. It connects systems that are not necessarily >>> directly connected, but use the same technology and are operated by a >>> common administration.Switched Ethernets, 802.11 networks, MPLS, >>> ATM, Frame Relay, and X.25 are all examples of Intra-network >>> protocols. >> In ISO that's the link layer (the Internet originally called these subnetworks), the homogeneous network technology span. > Actually, no. > > In IEEE/ANSI politics circa 1985, there was an understanding that the network layer belonged to ANSI, and the link layer belonged to IEEE. IEEE 802 started work on 802.1 through 802.5, including two different ways to build networks out of what at the time were called Packet Repeaters or Bridges. They bypassed the understanding by calling them MAC Layer bridges, and they justified the appellation by noting that the bridges operated on the link layer header, whether transparently or by source-route bridging. > > X.25 was a place where the nomenclature battle was fought heavily. In Europe, X.25 was, at the time, *the* network, and the definitive network layer. To the ARPA folks, it was an API that allowed someone to inject a packet into a network; it might come out a different API that was not X.25. In CSNET, IP ran atop X.25, and IP was the API that allowed someone to select which X.25 destination they might go to. > > Get over it. X.25 is a network, and the Internet is a Network, and one often runs over the other. As in X.25/TCP/IP/CSNET and other bizarre things. > > ISO had nothing to do with that. > >>> And then there is what one might call the virtualization >>> sublayer, which is when, whatever we call it, we use an IP tunnel >>> between the Internetwork and Intranetwork layers. Static IP/IP and >>> GRE/IP tunnels, LISP, Mobile IP, L2TP, >> Tunnels don't map to any static definition of layers, exactly because they can always be placed between any pair of layers - including other tunnel layers. A tunnel is link, not a network. A set of tunnels can represent a network to the layer above it. >> >> This last reality is why it's so easy to get tunneling wrong. E.g., a tunnel can transit a "largest" packet - which defines the tunnel MTU; that MTU is *not* the 'largest unfragmented message' that can transit the tunnel. We don't have a concept of 'natural chunksize', and confusion between that and the largest message transmissible is the reason for a lot of really badly crafted tunnel specs. >> >> So all these layers end up being defined by the layer above and the layer below, e.g., if IP runs over them, they had better act a lot like what RFC3819 expects, or things will (and do) work badly. (that relative relationship is what RNA is all about). >> >> Joe >> > ------------------------------------------------------ > 8 issues in virtual infrastructure > http://dcrocker.net/#fallacies > -- Richard Bennett Visiting Fellow, American Enterprise Institute Center for Internet, Communications, and Technology Policy Editor, High Tech Forum From detlef.bosau at web.de Tue Feb 11 14:05:08 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Feb 2014 23:05:08 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA921B.2010600@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> <52FA8CE4.8060809@web.de> <52FA921B.2010600@isi.edu> Message-ID: <52FA9E94.3070705@web.de> Am 11.02.2014 22:11, schrieb Joe Touch: > > > On 2/11/2014 12:49 PM, Detlef Bosau wrote: >> However, don't you agree that the basic system model in a TCP connection >> is sill >> >> Endpoint 1 -------------------- Pipe >> -------------------------- Endpoint 2 > > Yes, TCP presents a service of a reliable ordered bytestream between > two endpoints. That's the view from the application layer. I refer to the "pipe" between the sockets. > >> We can well discuss the nature of the "Pipe", particularly the >> correspondence CWND = Pipe's capacity. > > The 'capacity' of the pipe is an ill-defined term; it can mean: > > - amount of sustained throughput through the pipe > that would be even more ill-defined. In the general (best effort) case, there is no such thing like sustained throughput in the pipe. > - amount of data stored temporarily inside the > pipe as a side-effect of efficient communication > i.e., the average sustained throughput * > average E2E delay this ill-definition is not that obvious ;-) The misconception is that the "pipe" is taken as some kind of homogeneous storage here where data temporarily "resides". The hard problem is: Buffers (at nodes) can accept data and can _keep_ data. Links can generally _carry_ data, they cannot _keep_ data. (Some weeks ago, I compared this to the situation of passengers on an escalator. You will of course object that an escalator well may keep passengers, o.k., let's modify the model and remove the emergency brake ;-)) (Or take a vertical water pipe. Yes, it may carry water and so there is an amount of water in the pipe. However, it cannot keep the water. When there is water in the pipe, it will eventually run of the pipe and don't stay there.) In this respect, the "storage" along the pipe is heterogeneous. > > CWND-MAX is usually set to the latter of these as one optimization, > but there are others for which that might not be true. > > CWND is a part of currently specified TCP congestion control, but not > the only means nor necessarily the optimium. The question is whether it provides a useful abstraction, whatever will be modelled by CWND. (A quantitative interpretation of CWND is always difficult, or should I say: most likely wrong. The qualitative interpretation, which is actually being used in the congavoid-paper, is certainly more appropriate.) Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Feb 11 14:40:18 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 11 Feb 2014 23:40:18 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA921B.2010600@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> <52FA8CE4.8060809@web.de> <52FA921B.2010600@isi.edu> Message-ID: <52FAA6D2.2060305@web.de> In a sense, the situation is similar to the isarithmic approach back in 1972. Following this approach, a network is congestion free when the amount of data in the network is limited by a certain maximum - call it CWND. This approach was not generally adopted because the same amount of data in the net could mean an underload situation or an overload situation, depending on where the data actually resides. The end to end congestion window in TCP suffers from exactly the same weakness. The same amount of data which means underload on a 2000 kilometres fibre line with TBit/s throughput will mean overload on a BNC cable of 10 metres length used for a shared Ethernet connection. Basically, the end to end CWND is the isarithmic approach applied to an end to end path through a network. The more an Internet path resemled a "line switched path", which may have been through in the early 80s when the Internet was build on the same physic as the ARPAnet, this analogy will hold. The more the Internet becomes heterogeneous, data rates along a path may vary on a scale of 8 orders of magnitude or more, wireless links may render the classical idea of links being "on" or "off" useless, the more this analogy may become questionable. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From erozner1 at gmail.com Tue Feb 11 16:51:08 2014 From: erozner1 at gmail.com (Eric Rozner2) Date: Tue, 11 Feb 2014 18:51:08 -0600 Subject: [e2e] CFP: IEEE Workshop on Local and Metropolitan Area Networks (LANMAN) Message-ID: Note: Deadlines approaching! CALL FOR PAPERS IEEE Workshop on Local and Metropolitan Area Networks (LANMAN) http://www.ieee-lanman.org/#papers IEEE LANMAN has an established tradition as a forum for presenting and discussing the latest technical advances in local and metropolitan area networking. Continuing that tradition, IEEE LANMAN 2014 invites cutting-edge papers spanning both theory and experimentation. Papers are solicited in all areas of networking, but in keeping with the current research trend, this workshop's central theme is data center networking. The intimate single-track session format of the workshop encourages stimulating exchanges between researchers. The workshop is expected to be a forum for discussion of new and interdisciplinary ideas on architectures, service models, pricing, and performance. Speculative and potentially transformative ideas are particularly encouraged, as are studies reporting measurements from real-life networks and testbeds. Papers are solicited on any LANMAN topic including, but not limited to, the following: Novel data center network architectures Data center network virtualization Energy-efficiency in data centers Routing and transport protocols in data center networks Software defined data center networks Data center network pricingResource allocation in data center networks Performance measurement and modeling of data centersInter-data center network issues Reliable data center networks Broadband wireless access, including WiMAX, LTE WiFi: roaming services, architectures, and performance Metropolitan and residential networks and architectures including Ethernet in the first mile, EPONs, FTTx, etc. Network management related to edge networks Heterogeneous wireless and ad-hoc networks Local-area and metropolitan-area network security LAN-based and MAN-based applications (gaming, distributed computing, media distribution to and in the home, enterprise applications, ambient technology, wearable-computing) Impact of sensors everywhere including homes IEEE LANMAN 2014 solicits paper submissions of Regular Papers (up to 6 pages) and Short Papers (up to 2 pages). The short papers will be presented in a poster session. Also, some of regular paper submissions may be accepted as short papers by the TPC. The page limits include all figures, tables, and references. All papers must be electronically submitted in PDF according to the guidelines in the workshop website http://www.ieee-lanman.org. The proceedings will be published by IEEE Xplore and will include both short and regular papers presented at the workshop. Best Paper Award will be given to the paper(s) with the highest technical merit. Selected papers will be invited for submission and fast track review by IEEE Transactions on Cloud Computing and Elsevier Computer Communications Journal. The paper submission site is https://www.easychair.org/conferences/?conf=lanman2014 All IEEE LANMAN 2014 technical papers and posters must be associated with an author registration at the full rate. For authors presenting multiple papers/posters, one full registration is valid for up to three papers/posters. IEEE reserves the right to exclude a paper/poster from distribution after the workshop (e.g., removal from IEEE Xplore) if the paper/poster is not presented at the workshop. Important dates: Abstract Registration: Feb 14, 2014, Friday Paper Submission: Feb 21, 2014, Friday Acceptance Notification: Mar 28, 2014, Friday Camera-ready Submission: Apr 18, 2014, Friday From touch at isi.edu Tue Feb 11 17:05:44 2014 From: touch at isi.edu (Joe Touch) Date: Tue, 11 Feb 2014 17:05:44 -0800 Subject: [e2e] Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: References: Message-ID: <52FAC8E8.2060805@isi.edu> On 2/11/2014 11:50 AM, John Day wrote: > Apparently, one must repeat explanations to rectify misconceptions about > the past. The accounts today exhibit the same errors that they did 7 > months ago. Yes, in that running over X.25 and talking about the service X.25 provides to IP relative to Internet terminology still has nothing to do with the terminology used within either X.25 or OSI. Joe >> X-CAA-SPAM: 00000 >> Date: Wed, 29 May 2013 12:04:41 -0400 >> To: Joe Touch , John Day >> From: John Day >> Subject: Re: [e2e] Historical question: Link layer flow control / silent >> discard >> Cc: braden at isi.edu, end2end-interest at postel.org >> >> OSI divided the Network Layer into 3 sub-layers (not all of which were >> present for all networks): 3a Subnet Access, 3b Subnet Dependent, and >> 3c Subnet Independent. (see the Internal Organization of the Network >> Layer, ISO 8648). >> >> X.25 was (according to its title) 3a Subnet Access. The PTTs had the >> "foresight" ;-) to call it a Data-Terminating-Equipment (DTE) to Data >> Communicating Equipment (DCE) interface. (Don't you love the >> nomenclature!) X.25 was just at the boundary of the network. In >> other words, Host to Network protocol, the equivalent of BBN1822! ;-) >> So OSI took them at their word. ;-) If the network had X.25, then it >> was at 3a. >> >> Whether a PTT used X.25 internal to its network was its business and >> not within the purview of CCITT. I believe most X.25 networks at the >> time heavily modified it beyond what the Recommendation said. (CCITT's >> habit of defining its recommendations as the interfaces between boxes >> is why I refer to this as the beads-on-a-string model! boxes strung >> together with a wire!) >> >> With X.25, LAPB (also known as HDLC) was the Data Link Layer. >> >> CLNP was 3c, Subnet Independent. >> >> One can think of 3a/3b as a traditional network layer for networks >> that had that; and 3c/Transport as the Internet Layer. 3c addresses >> were global, while addresses in 3a/3b were only unambiguous within the >> network. Think of 3a/3b as points of attachment addresses, and 3c as >> node addresses. (see the Saltzer paper RFC 1498 for background on this) >> >> Take care, >> John >> >> At 8:31 AM -0700 5/29/13, Joe Touch wrote: >>> On 5/28/2013 2:02 PM, John Day wrote: >>>> Just for the record and then I will let this discussion go on, but X.25 >>>> was not at the core of the OSI Model. >>> >>> FWIW, there was an implementation of ISO - ISODE (the ISO development >>> environment). UPenn was snail-mailing out 9-track tapes and 8mm >>> cassettes back in the early 90's when I was there. I still have one >>> of the enamel pins. >>> >>> It implemented layers 3-6, and could be configured to run over X.25 - >>> thus the possible confusion that X.25 was its L2. >>> >>> Joe From l.wood at surrey.ac.uk Tue Feb 11 17:24:00 2014 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Wed, 12 Feb 2014 01:24:00 +0000 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: References: Message-ID: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> On repeating the past: Worth noting that the archives of the end2end mailing list prior to 2001 and the Postel Center/Touch takeover are no longer available at: ftp://ftp.isi.edu/end2end/ All that knowledge, cast into the abyss, like tears in the wind. Lloyd Wood http://about.me/lloydwood ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of John Day [jeanjour at comcast.net] Sent: 11 February 2014 19:50 To: end2end-interest at postel.org Subject: [e2e] Fwd: Re: Historical question: Link layer flow control / silent discard Apparently, one must repeat explanations to rectify misconceptions about the past. The accounts today exhibit the same errors that they did 7 months ago. From dhc2 at dcrocker.net Tue Feb 11 21:44:50 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Tue, 11 Feb 2014 21:44:50 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> Message-ID: <52FB0A52.3010009@dcrocker.net> On 2/11/2014 10:47 AM, Fred Baker (fred) wrote: > In CSNET, IP ran atop X.25, and IP was the API that allowed someone to select which X.25 destination they might go to. > > Get over it. X.25 is a network, and the Internet is a Network, and one often runs over the other. As in X.25/TCP/IP/CSNET and other bizarre things. CSNet had an even earlier bit of layer that you might enjoy: RFC733/CSNet Mail/CSNet Phonenet/X.25 Since CSNet had Internet (well, initially Arpanet) gateways at UDel and Rand, this meant that end-to-end Arpanet/Internet mail often transited over a telephone link and mail protocol which ran over X.25. Wouldn't surprise me if some example had RFC822/CSNetMail/Phonenet/X.25 X.25/IP/TCPSMTP/RFC822 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeanjour at comcast.net Wed Feb 12 04:29:02 2014 From: jeanjour at comcast.net (John Day) Date: Wed, 12 Feb 2014 07:29:02 -0500 Subject: [e2e] Lost Layer? In-Reply-To: <52FA78DC.4030909@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> <52FA78DC.4030909@isi.edu> Message-ID: Snip >> >>In IEEE/ANSI politics circa 1985, there was an understanding that >>thenetwork layer belonged to ANSI, and the link layer belonged to IEEE. > >Neither of which being the ISO. > >Now you're just adding yet another set of groups that use >terminology differently. Actually, all of the IEEE standards of this period are also ISO standards. The two groups worked rather closely together. The link layer did not exactly belong to IEEE. ISO did work on HDLC and revised it at least once in this period. But IEEE did stay quite close to the ISO work adopting a number of their conventions. > >>ISO had nothing to do with that. > >Sure - I was mapping the Internet layer names and ISO names; throw >more organizations into the mix and the translation matrix gets more >complex and more overloaded. Actually, you weren't using the ISO names. ISO refined its concept of network layer in 8648. This was the whole point. Take care, John From detlef.bosau at web.de Wed Feb 12 04:56:01 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Feb 2014 13:56:01 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA3D6B.5040309@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52FA287B.3090104@web.de> <52FA3D6B.5040309@isi.edu> Message-ID: <52FB6F61.7050505@web.de> Am 11.02.2014 16:10, schrieb Joe Touch: > > > On 2/11/2014 5:41 AM, Detlef Bosau wrote: >> Am 11.02.2014 03:31, schrieb Joe Touch: > ... >>> I have no idea what a 'network' layer is that is different from what >>> we currently call the link layer. >> >> And you are not the only one to have this problem. >> >> When you have a look at >> @article{cerf, >> title={ Protocol for Packet Network Intercommunication}, >> author={V.~ Cerf and R.~Kahn}, >> journal={IEEE Transactions on Communications}, >> month= "May", >> year= "1974", >> volume = "22", >> number = "5", >> pages = "637-- 648" >> } > > At that time, the terminology was in flux. > > By the mid-1980s, it had settled as: > > Internet ISO > > application layer app, presentation, & session layers > > transport layer transport layer > > Internet layer network layer > > subnetwork layer link layer > > The other ISO layers were often buried inside the Internet's app > layer, though they're now split out (e.g., for the web HTTP is a > session layer, HTML a presentation layer, and the content the app layer). > > And we now (I hope) understand (or are starting to) that all the > layers are really just relative to each other. All are just copies of > the single step that wraps a lot of the ISO layers into a single > function: > > > layer (message, from-addr, to-addr) { > if (my-location == to-addr) then { > return > } else { > next-message = translate(message, nextlayer), i.e., > translate the message to a format for the next layer, > including any/all of: > error correction > flow control > congestion control > data content translation > data format conversion > fragment/reassembly > translate this layer's identifiers to the next's: > next-from = lookup(from-addr, nextlayer); > next-to = lookup(to-addr, nextlayer); > recurse: > layer(next-message, next-from, next-to); > } > } In a sense, you repeat e.g. congestion control throughout the layers, hence congestion control may occur on every layer. Where I do not agree is that you do both, flow control and congestion control. I think this is THE basic misconception in internetworking that these two were different. They aren't. To my understanding, the term congestion control is meaningless. Period. It tries to cover a conceptual design fault. In a sense (the very sense of Simon & Garfunkel) it is "kodachrome". May I refer to my favourite network technology, GPRS. A service time for a 1024 byte packet in GPRS to be successfully delivered may vary from 1 ms up to 6 minutes (= 600.000 ms). So, in a setting endpoint GPRS link endpoint how many packets may be in transit? One? Or sixhundredthousand? The "congestion control work" gives a precise answer here: CWND/packet size. That's the precise number of packets, which may be in transit. (I don't know the english word for this kind of ultraprecise numbers. In German, we would say: "soundsoviele". There may be "soundsoviele" packets in transit. And when you ask what "soundsoviele" means in English, you ask the very question of TCP congestion control.) From detlef.bosau at web.de Wed Feb 12 06:18:23 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Feb 2014 15:18:23 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA30DC.1060204@isi.edu> References: <52D04B36.9010005@web.de> , <52F98B87.6060004@isi.edu> <290E20B455C66743BE178C5C84F1240847E633470B@EXMB01CMS.surrey.ac.uk> <52FA30DC.1060204@isi.edu> Message-ID: <52FB82AF.3020003@web.de> May I ask an indecent question? Do we talk about line switching or about packet switching? It was, amongst others, Vint Cerf himself in RFC 675 who denied the difference. And since these days, we take the internet as a "magic cloud" where isolated (!!!!!!! in the very meaning of H?rder/Reuter and the ACID transcations) flows exist - and appear to the user exactly in the same way as they would in line switched networks. Replace the line by endpoints in the cloud - and play the Telix/Kermit/xmodem/ymodem/zmodem/UUCP game - hopefully, it will work. My idea of layers is that a layer n provides services to layer n+1. And these services are transparent and isolated, hence when two TCP flows use the "IP cloud" the two flows expect an isolated view. So the service as seem by flow 1 does not depend on whether flow 2 is active or not. (When you hear your neighbour while you both do a phone call - not to each other, this should be due to the thin walls or your neighbour's loud voice. Not to the telephone system. ) (Of course, this concept of isolation is extreme and not sound in a network where ressources are shared. However the question is which view is presented by a "network layer" to upper layers? And are "layers" in this context are a useful idea at all?) Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jnc at mercury.lcs.mit.edu Wed Feb 12 07:03:34 2014 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 12 Feb 2014 10:03:34 -0500 (EST) Subject: [e2e] Lost Layer? Message-ID: <20140212150334.A36F918C0C6@mercury.lcs.mit.edu> Just saw a reference to this in a later message, I'd missed it: > From: "Fred Baker (fred)" > we have at least three common sub-layers within the network layer. One > is what we call the Internetwork Layer and should be called, perhaps, > the Inter-network sub-layer. It provides the end to end datagram > service that TCP and other transports ride atop. Another might .. be > called the Intra-network sublayer. It connects systems that are not > necessarily directly connected, but use the same technology and are > operated by a common administration. .. MPLS, ATM, Frame Relay, and > X.25 are all examples of Intra-network protocols. And then there is > what one might call the virtualization sublayer, which is when, > whatever we call it, we use an IP tunnel between the Internetwork and > Intranetwork layers. Static IP/IP and GRE/IP tunnels, LISP, Mobile IP, > L2TP, ... Not sure about everthing in that last list, but for things like ILNP and LISP (and maybe HIP too) it's actually a shim layer between what you call the internetwork sub-layer and the _transport_ layer above, not the layer below. The reason is that things like ILNP and LISP attempt to provide persistent names for use by the transport layer, ones which is not affected by i) change of internetwork sub-layer names (i.e. addresses), ii) use of multiple internetwork sub-layer names, etc. I.e. they are directly below the transport layer. > From: John Day > Actually, you weren't using the ISO names. ISO refined its concept of > network layer in 8648. Perhaps, but the fact remains that the original 7-layer ISO model was a poor match to the Internet, because the ISO model had too few layers on the lower end, and too many on the upper - at least, to model the Internet well. (Although, as someone pointed out, now that we have HTTP/HTML/etc the upper layers are better matched.) Noel From faber at isi.edu Wed Feb 12 09:10:31 2014 From: faber at isi.edu (Ted Faber) Date: Wed, 12 Feb 2014 09:10:31 -0800 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> Message-ID: <52FBAB07.4000900@isi.edu> On 02/11/14 17:24, l.wood at surrey.ac.uk wrote: > On repeating the past: > > Worth noting that the archives of the end2end mailing list prior to 2001 and the Postel Center/Touch takeover are no longer available at: > ftp://ftp.isi.edu/end2end/ > > All that knowledge, cast into the abyss, like tears in the wind. > http://www.youtube.com/watch?v=NOW4QiOD-oc "I've seen things you people wouldn't believe..." -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG From braden at isi.edu Wed Feb 12 10:42:37 2014 From: braden at isi.edu (Bob Braden) Date: Wed, 12 Feb 2014 10:42:37 -0800 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: <52FBAB07.4000900@isi.edu> References: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> <52FBAB07.4000900@isi.edu> Message-ID: <52FBC09D.50309@isi.edu> On 2/12/2014 9:10 AM, Ted Faber wrote: > On 02/11/14 17:24, l.wood at surrey.ac.uk wrote: >> On repeating the past: >> >> Worth noting that the archives of the end2end mailing list prior to 2001 and the Postel Center/Touch takeover are no longer available at: >> ftp://ftp.isi.edu/end2end/ >> >> All that knowledge, cast into the abyss, like tears in the wind. >> > I am pretty sure they still exist on ISI's apparently inexhaustable disks. Will check. Bob Braden From detlef.bosau at web.de Wed Feb 12 11:46:14 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Feb 2014 20:46:14 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA9424.9060603@bennett.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA33C0.8010702@isi.edu> <5D2B2349-38B3-43AE-803C-04E6E8B75203@cisco.com> <52FA9424.9060603@bennett.com> Message-ID: <52FBCF86.8020601@web.de> Am 11.02.2014 22:20, schrieb Richard Bennett: > Mobile makes this a relevant issue today and in the future. There's a > lot of functional richness below IP, without which IP datagrams would > never get delivered. Personally, I've always regarded IP as a stub or > a placeholder for a real protocol, but I don't think APIs and > protocols are interchangeable. > > RB However, it is exactly this functional richness, which renders the traditional end to end view, that a TCP flow is controlled from the end points and only from the endpoints, highly questionable. IP and TCP/IP are expected to cope with mobile links. That's the reason why I bother the community with my (sometimes nasty) view on the matter. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From touch at isi.edu Wed Feb 12 12:52:37 2014 From: touch at isi.edu (Joe Touch) Date: Wed, 12 Feb 2014 12:52:37 -0800 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> Message-ID: <52FBDF15.1070301@isi.edu> FYI, these just came up fine in my browser. I'm investigating whether there are problems accessing the info off-site now, and it will be resolved shortly. So it's not gone, but this is the first I've heard it's not accessible, and will tend to it ASAP. Joe On 2/11/2014 5:24 PM, l.wood at surrey.ac.uk wrote: > On repeating the past: > > Worth noting that the archives of the end2end mailing list prior to 2001 and the Postel Center/Touch takeover are no longer available at: > ftp://ftp.isi.edu/end2end/ > > All that knowledge, cast into the abyss, like tears in the wind. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of John Day [jeanjour at comcast.net] > Sent: 11 February 2014 19:50 > To: end2end-interest at postel.org > Subject: [e2e] Fwd: Re: Historical question: Link layer flow control / silent discard > > Apparently, one must repeat explanations to rectify misconceptions > about the past. The accounts today exhibit the same errors that they > did 7 months ago. > From touch at isi.edu Wed Feb 12 13:51:50 2014 From: touch at isi.edu (Joe Touch) Date: Wed, 12 Feb 2014 13:51:50 -0800 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: <52FBDF15.1070301@isi.edu> References: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> <52FBDF15.1070301@isi.edu> Message-ID: <52FBECF6.7010001@isi.edu> Hi, all, The site is back. We had a hiccup this AM that affected the entire FTP site, but it's been corrected since. Joe On 2/12/2014 12:52 PM, Joe Touch wrote: > FYI, these just came up fine in my browser. I'm investigating whether > there are problems accessing the info off-site now, and it will be > resolved shortly. > > So it's not gone, but this is the first I've heard it's not accessible, > and will tend to it ASAP. > > Joe > > On 2/11/2014 5:24 PM, l.wood at surrey.ac.uk wrote: >> On repeating the past: >> >> Worth noting that the archives of the end2end mailing list prior to >> 2001 and the Postel Center/Touch takeover are no longer available at: >> ftp://ftp.isi.edu/end2end/ >> >> All that knowledge, cast into the abyss, like tears in the wind. >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: end2end-interest-bounces at postel.org >> [end2end-interest-bounces at postel.org] On Behalf Of John Day >> [jeanjour at comcast.net] >> Sent: 11 February 2014 19:50 >> To: end2end-interest at postel.org >> Subject: [e2e] Fwd: Re: Historical question: Link layer flow control / >> silent discard >> >> Apparently, one must repeat explanations to rectify misconceptions >> about the past. The accounts today exhibit the same errors that they >> did 7 months ago. >> From detlef.bosau at web.de Thu Feb 13 05:26:45 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Feb 2014 14:26:45 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52FA8F1C.80904@dcrocker.net> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52F98CFD.70909@isi.edu> <52FA8F1C.80904@dcrocker.net> Message-ID: <52FCC815.1060808@web.de> Am 11.02.2014 21:59, schrieb Dave Crocker: > >> PS - I disagree that the layer that's missing is the "AS" layer. >> >> If that's what you really want, then you get that using a recursive >> network layer - e.g., LISP. > > > Looking at this latest sequence of notes on this thread, I think that > what's missing is any sort of summary problem statement, put into > essentially non-technical, functional terms, without directing the > answer. That's exactly my problem. What makes me upset with my remarks is that I did not yet get any technical answer. Only offences, one blamed me (and it is no blame, he may be right actually) I would propose to abandon congestion control. Actually I will - as long as we agree upn the solution here but never agreed upon a problem. Having a look at some of the messages here, some people even talk about "mobilty". Yeah. So eventually, we managed to realize that there are mobile networks around. (Please don't be scared when you leave your house: There is an earth outside! O.k., mobile networks may be somewhat younger, but we deal with them for 30 years or so now, so networking should accept that they do exist.) I would greatly appreciate avoiding the words ANSI, IEEE, OSI etc., these are standards and standard organizations and they may well issue their, excuse me, bullshit in printed form and give it numbers etc. I would like to discuss technical issues. Perhaps, when we talk about TCP, a concrete question. (And I would appreciate a concrete answer.) What's the use of VJCC when I connect two notebooks via a Wifi ad hoc network? - What are the problems to be solved? - What are possible solutions? To be even more concrete: Let's assume, both notebooks would run TCP as proposed in RFC 793. And we want to transfer file from notebook a to notebook b, e.g. an image of the most recemt Ubuntu CD. Simple scenario, simple question: What are the problems to be solved? (And forgive me being nasty here. But you will agree: WHEN you are interested in scientific questions, don't ask students or professors, but ask a kid.) From detlef.bosau at web.de Thu Feb 13 07:26:46 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 13 Feb 2014 16:26:46 +0100 Subject: [e2e] Lost Layer? In-Reply-To: <52F98CFD.70909@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52F98CFD.70909@isi.edu> Message-ID: <52FCE436.2060708@web.de> Am 11.02.2014 03:37, schrieb Joe Touch: > > > On 2/10/2014 6:31 PM, Joe Touch wrote: >> I have no idea what a 'network' layer is that is different from what we >> currently call the link layer. Links layers *are* networks (Ethernet, >> SONET, etc.), except when there's no network at all (point-to-point >> links that need no L2). > > PS - I disagree that the layer that's missing is the "AS" layer. > > If that's what you really want, then you get that using a recursive > network layer - e.g., LISP. > > The result is precisely what happens if you add a true networking > layer below IP but above ethernet. And it includes the baggage that it > should - of cross-domain resolution for encapsulation. > > See http://www.isi.edu/rna/ > > Joe Is the similarity in the name to "RINA" by chance? Sometimes, I think we reinvent the wheel again and again - and repeating the same approaches lead to the same results. Could it be that we have lost the focus? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Feb 13 15:53:09 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Feb 2014 00:53:09 +0100 Subject: [e2e] Lost Layer? In-Reply-To: References: Message-ID: <52FD5AE5.8020602@web.de> Am 12.02.2014 21:55, schrieb Ivancic, William D. (GRC-RHN0): > Hence the lost layer. Or not the lost layer. Admittedly, I'm a bit annoyed by the term "layer". > > IMHO, IP is can be viewed in some respects as just a multi-hop forwarding > system. The problem is TCP used IP point-of-attachment (POA) addresses as > it's end-point identifiers. That's not a problem, that's IP. > So, if you are mobile (your IP POA changes) > or are multi-homed (you have more than one POA), then TCP doesn't handle > this well. We should be precise here: TCP doesn't handle this at all. TCP doesn't care about the path or path changes. (Or, nasty me, about path capacity changes, which may happen every few milliseconds, particularly in multi-homed scenarios.) > Mobile-ip is sort of a misnomer as mobile-ip is really there > to make the POA used by layers above IP appear unchanged. Hence, the "layering" covers the reality behind some kind of neat masquerade. > So then you > implement mobile-ip, SCTP and HIP and other techniques to try and overcome > the problem which is really a lost-layer problem (i.e. A incomplete or > poorly architected network). What I want to advocate is a model of flows. Not of layers but of flows. We use this in multimedia systems for years. Only in TCP, we insist of this "transparent IP cloud". This abstraction is much to coarse IMHO. > > Will > > > > > > > On 2/12/14 2:46 PM, "Detlef Bosau" wrote: > >> Am 11.02.2014 22:20, schrieb Richard Bennett: >>> Mobile makes this a relevant issue today and in the future. There's a >>> lot of functional richness below IP, without which IP datagrams would >>> never get delivered. Personally, I've always regarded IP as a stub or >>> a placeholder for a real protocol, but I don't think APIs and >>> protocols are interchangeable. >>> >>> RB >> However, it is exactly this functional richness, which renders the >> traditional end to end view, that a TCP flow is controlled from the end >> points and only from the endpoints, highly questionable. >> >> IP and TCP/IP are expected to cope with mobile links. That's the reason >> why I bother the community with my (sometimes nasty) view on the matter. >> >> -- >> ------------------------------------------------------------------ >> Detlef Bosau >> Galileistra?e 30 >> 70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >> detlef.bosau at web.de http://www.detlef-bosau.de >> -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Feb 13 16:35:29 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Feb 2014 01:35:29 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <52FA3628.50007@isi.edu> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> Message-ID: <52FD64D1.20502@web.de> Am 11.02.2014 15:39, schrieb Joe Touch: > > > On 2/11/2014 1:09 AM, Fred Baker (fred) wrote: >> >> On Feb 10, 2014, at 6:31 PM, Joe Touch wrote: >> >>> There are three layers, but it's TCP that's incomplete. I don't at >>> all understand the difference between a "network layer" and an >>> "internetwork layer". >> >> Well, the deal is that layers can be sub-layered. > > If you mean that every layer expects similar things from the layer > below, I agree (that's RNA). It expects a way to transit a set of > nodes using a path, and accepts that there will need to be a way to > map nodes at the upper layer to nodes at the lower layer (e.g., > resolution, ala Google, BGP, and ARP, depending on what layer you look > at). > >> Yes, the >> Internetwork layer is perhaps unfortunately named, in that it doesn't >> always interconnect networks. > > But you can't tell the difference when it isn't. I think we are talking at cross purposes here. Basically, each and every link along the path constitutes a "network" by itself, this no rocket science, this is the definition of a network. The problem is how a concatenation of networks ("a catenat") is presented to upper layers and what the properties of the concatenated networks are. And of course this is not independent from the protocol in use: - UDP is unreliable, - TCP is reliable, hence on a TCP path you may require a recovery layer. (Which is particularly part of each and every mobile network around this world and first, I was forbidden to understand this and now I'm forbidden to admit and to discuss this and this drives me crazy.) And yes, data corruption is a local problem as it is network congestion and yes, both problems are to be solved locally. Sorry for that. And yes, when recovery cannot be solved on a link, there will be some kind of escalation strategy to solve this problem from a less local but more global perspective, however there are more than the two alternatives - local retransmission and - global retransmission. However, to become acceptable for some kind of "part of TCP flow" this part has to provide a mechanism for reliable transmission which is best modelled by some kind of delivery time and some kind of SDU corruption probability. So we have some criteria whether the piece of network is acceptable as a "part of TCP flow" - or not. It doesn't matter whether an architecture with sets up, maintains and tears down this kind of flows is called a "layer" or "plate with popcorn". I am not interested in how things are named but which service they provide. Some evil tongues call this "object oriented thinking". And we're doing so - in multimedia architectures, - in software defined networks, - in component based middleware, CORBA and the like, - in programs - in Delay Tolerant Networks - in Overlay Networks however with respect to TCP, mankind sits in caves and thinks in the layers of 1970 or so. > >> But it comes down to this. >> >> First, consider that each layer answers a fundamental question. > > Each answers exactly the same fundamental question - how do I transit > hops at my layer using what I think are links at my layer, by using > what look like hops and links that are really a service provided by > the next layer down. Hang on. A TCP path is a chain of concatenated segments. So, why do we look at "layers"? Why don't we ask what we expect from the segments? And of course, each segment will provide a "packet transport service" with some properties (delivery time, SDU corruption ratio...) presented to the outside world and when we set up or maintain or tear down a flow, we have to assess whether the segments are suitable for our needs or not, what's the problem with this? And of course, each of these segments will encapsulate a system which implements some of the well known layers. I have to apologize for being a bit upset here. But sometimes I get the impression that many people have only worked with Ethernet so far, perhaps Fast Ethernet or Gig Ethernet. But whoever worked with mobile networks or point to point "links" passing an ATM cloud or a Frame Relay cloud which actually provide mechanisms like "tunnel bridges" should be familiar with this way of thinking and should have accepted the "OSI layers" as a neat picture from the text books and learned this stuff for exams - but I sincerely expect that none of us took this really seriously, at least not too much ;-) So start the encapsulation here: > >> The >> physical layer provides the physical interconnect between a system and a >> neighboring system. > > The physical layer is just the base case where the signal receives > this 'service' from a real, physical entity. > > > The Link Layer provides the interpretation of >> signals on the physical medium connecting neighboring systems. > > That translation of format can happen at every layer in a stack of > layers. It happens when tunnels encrypt/decrypt. It happens when a > stream of messages are FEC encoded. It happens when we stripe over > different channels to emulate a mega-channel. > > > The >> network layer connects a system to another system that it is not >> necessarily directly connected to. > > That happens at every layer, because every layer can include > forwarding. Link layers forward, and transport layers can relay > (forward) too. > and end it here. IP - Segment - IP. Period. Yes, in a sense similar to VJCC and others. But not for the whole Internet cloud but restricted to a segment where this abstraction makes sense! The rest might be called "object oriented networking" and instead of "routing" we would have something like "dynamic flow construction". > And SONET provides a stream over frames. Ethernet provides packet > relay over packet links, as does IP. > >From the perspective I tried to explain, it does not matter what SONET provides. (Or cell relay, or SDH which is slightly different from SONET, or PDH. Or a point to point net with a laser system. Or a satellite network. Or, very classic, carrier pidgeons. Of course no robins....) It must be suitable as a segment in a TCP flow, so it should provide a packet transport service with acceptable reliability and acceptable service time, the limits for both of which must be provided by the user. So, why don't we think in concatenated segments, call it "network objects" or "network path objects", whatever you like, and why don't we talk about the properties of these and talk about a much too coarse "layer model" instead? Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jamel at cin.ufpe.br Fri Feb 14 03:40:00 2014 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Fri, 14 Feb 2014 09:40:00 -0200 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <52FD64D1.20502@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> Message-ID: > The rest might be called "object oriented networking" and instead of > "routing" we would have something like "dynamic flow construction". > > Instead of looking at object oriented networking we would consider a more general peer level application orchestration of network functions. Think that applications may through requirements orchestrate the use of resources such as lightpath wavelengths, error correction, etc. This does not also have to be OO necessarily. New protocols (selection of functional objects) may be dynamically negotiated among intermediate as well as end systems. We could think of TCP as a special simple case and keep this as a fallback default. End applications and network relay nodes may organize the creation, aggregation, merging, combination of several flows in a dynamic way. A network may chose to add advertizing material to some content (different business model!) Current Network functions virtualizations (NFV) and SDN ideas would fit into this framework. The problem could be complexity/scalability as there seems to be no limit to the processing at end systems and relays. But the wide range of choice in terms of protocol (associations design) could lead to a much more efficient and flexible world while also keeping TCP default support Djamel From touch at isi.edu Fri Feb 14 06:44:45 2014 From: touch at isi.edu (Joe Touch) Date: Fri, 14 Feb 2014 06:44:45 -0800 Subject: [e2e] Lost Layer? In-Reply-To: <52FCE436.2060708@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <52F98CFD.70909@isi.edu> <52FCE436.2060708@web.de> Message-ID: <52FE2BDD.8080109@isi.edu> On 2/13/2014 7:26 AM, Detlef Bosau wrote: > Am 11.02.2014 03:37, schrieb Joe Touch: >> >> See http://www.isi.edu/rna/ >> >> Joe > > Is the similarity in the name to "RINA" by chance? It was coined publicly in 2006, before Day's book was public and before the RINA project based on that work. > Sometimes, I think we reinvent the wheel again and again - and repeating > the same approaches lead to the same results. In this case, it was more like a convergence - John came up with his concept in parallel with us coming up with ours. Joe From detlef.bosau at web.de Fri Feb 14 09:13:52 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Feb 2014 18:13:52 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> Message-ID: <52FE4ED0.3050601@web.de> So you want to orchestrate lightwaves etc. from the endpoints? One in New York, one at the north pole, you orchstrate all lightwaves in between without the least idea what's going on in between? Sorry for me being heterodox, but while I put in question the end to end principle, you overcome it's limits by a far end to far end problem..... -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jamel at cin.ufpe.br Fri Feb 14 10:18:10 2014 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Fri, 14 Feb 2014 16:18:10 -0200 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <52FE4ED0.3050601@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> Message-ID: On Fri, Feb 14, 2014 at 2:13 PM, Detlef Bosau wrote: > So you want to orchestrate lightwaves etc. from the endpoints? > > This is going to be the case "yes" at least from the point of view of Cloud/Data center peer application provisioning. Djamel > One in New York, one at the north pole, you orchstrate all lightwaves in > between without the least idea what's going on in between? > > Sorry for me being heterodox, but while I put in question the end to end > principle, you overcome it's limits by a far end to far end problem..... > > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > From detlef.bosau at web.de Fri Feb 14 11:45:49 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Feb 2014 20:45:49 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> Message-ID: <52FE726D.7080703@web.de> Am 14.02.2014 19:18, schrieb Djamel Sadok: > > > > On Fri, Feb 14, 2014 at 2:13 PM, Detlef Bosau > wrote: > > So you want to orchestrate lightwaves etc. from the endpoints? > > > This is going to be the case "yes" at least from the point of view of > Cloud/Data center peer application provisioning. > > Djamel > The point is what you want to "orchestrate". You may well orchestrate a path. You may well orchestrate constraints along a path, e.g. maximum corruption ratio, minimum throughput or the like. However, what I'm talking about is congestion and resource consumption. And there I think it to be a misconception to regard congestion as a global problem which has to be handled by the communication end points. When we have a transient throughput shortage on hop 47 out of 80 because of a short cross traffic consisting of one or two packets, it is certainly not adequate to change an end to end congestion window for this reason. A short backpressure which certainly will reach the source and throttle down the traffic for a short moment would fully suffice. Who, in your opinion, shall decide which sender should be throtted? Virtualizations are always nice - however, what happens concrete? In a sense, a virtualization is always an iconostasis. The community looks at the iconostasis, praying and worshiping - and has no idea what's happening behind it. The community only believes that bread and wine will transform into blood and flesh of christ. (To my knowledge, in orthodox services, the community does not see the consecration or Eucharistic change but only listens to the prayers and chants of the priests.) The religious believer believes, that by this act his sins are forgiven. The computer scientist believers, that by the act behind the iconostasis a packet is conveyed. Neither of these is interested in the details. From dhc2 at dcrocker.net Fri Feb 14 15:38:15 2014 From: dhc2 at dcrocker.net (Dave Crocker) Date: Fri, 14 Feb 2014 15:38:15 -0800 Subject: [e2e] Archives was Fwd: Re: Historical question: Link layer flow control / silent discard In-Reply-To: <52FBC09D.50309@isi.edu> References: <290E20B455C66743BE178C5C84F1240847E633470F@EXMB01CMS.surrey.ac.uk> <52FBAB07.4000900@isi.edu> <52FBC09D.50309@isi.edu> Message-ID: <52FEA8E7.5090306@dcrocker.net> On 2/12/2014 10:42 AM, Bob Braden wrote: > On 2/12/2014 9:10 AM, Ted Faber wrote: >>> Worth noting that the archives of the end2end mailing list prior to >>> 2001 and the Postel Center/Touch takeover are no longer available at: >>> ftp://ftp.isi.edu/end2end/ >>> >>> All that knowledge, cast into the abyss, like tears in the wind. >>> > >> I am pretty sure they still exist on ISI's apparently inexhaustable >> disks. Will check. > Bob Braden As with all of the early material, it would be worth trying to get it archived with a place that has the profession of archiving. It's not ISI's business, nor the IETFs, nor... We confuse "has been around a long time" with "know how to assure availability for hundreds of years." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jamel at cin.ufpe.br Mon Feb 17 05:22:02 2014 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Mon, 17 Feb 2014 10:22:02 -0300 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <52FE726D.7080703@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> Message-ID: On Fri, Feb 14, 2014 at 4:45 PM, Detlef Bosau wrote: > Am 14.02.2014 19:18, schrieb Djamel Sadok: > > > > > On Fri, Feb 14, 2014 at 2:13 PM, Detlef Bosau wrote: > >> So you want to orchestrate lightwaves etc. from the endpoints? >> >> > This is going to be the case "yes" at least from the point of view of > Cloud/Data center peer application provisioning. > > Djamel > > > > The point is what you want to "orchestrate". You may well orchestrate a > path. You may well orchestrate constraints along a path, e.g. maximum > corruption ratio, minimum throughput or the like. > > However, what I'm talking about is congestion and resource consumption. > And there I think it to be a misconception to regard congestion as a global > problem which has to be handled by the communication end points. > > When we have a transient throughput shortage on hop 47 out of 80 because > of a short cross traffic consisting of one or two packets, it is certainly > not adequate to change an end to end congestion window for this reason. A > short backpressure which certainly will reach the source and throttle down > the traffic for a short moment would fully suffice. > > Who, in your opinion, shall decide which sender should be throtted? > > It all depends on the scope of the problem. Within a domain for example, instead of throttling sources for example, a path computation element would offer a better solution as it can control/orchestrate the lighpaths. The situation gets out of hand when inter-domain management is involved. Djamel From detlef.bosau at web.de Mon Feb 17 18:15:10 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Feb 2014 03:15:10 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> Message-ID: <5302C22E.9070905@web.de> Am 17.02.2014 14:22, schrieb Djamel Sadok: > > It all depends on the scope of the problem. Within a domain for example, > instead of throttling sources for example, a path computation element would > offer a better solution as it can control/orchestrate the lighpaths. The > situation gets out of hand when inter-domain management is involved. > > Djamel What is "interdomain management" here? The telephone system worked with path computaton, multimedia systems work with path computation. Hence, path computation is obviously possible. The central question is what we want to achieve at all. And when we want to achieve proper resource management in TCP flows, the very first step is to identify, which resources are shared and who are the competing flows. In my opinion, our actual system model is oversimplified and hence we end up in a sequence of kludges here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Feb 18 06:16:58 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Feb 2014 15:16:58 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> Message-ID: <53036B5A.8050703@web.de> Am 18.02.2014 04:47, schrieb David P. Reed: > The interdomain issue is crucial. The point of the Internet is that it > is not owned or controlled by a single entity. Period. There is no > global agreement on any measure of optimality. If there were, then it > would NOT BE AN INTERNET. You're mixing up things here. The Internet is not controlled by a single entity ("oh that bad telcos....") but it requires a consistent agreements on protocols. Your argument sounds a bit like: "Oh, the WTC towers are burning? Let them burn, calling the fire brigade is prohibited for political reasons." To my understanding, Cerf's catenet model required a certain amount of interoperability between concatenated networks, this is even the reason for IP. (However: IP dropped quite some requirements from the catenet model, sometimes even silently.) When you talk about waste of time, David it may sound harsh, but when a system model is wrong, there is an old saying: "If you see that you're riding a dead horse, dismount". And you might never forgive me that sentence and declare me for stupid or ill, but the more I think about it, the end to end religion is not only a dead horse, it is horse butcher's bonanza. And what's particularly embarrassing with this approach is that we CS guys are not the only ones in the world to deal with control problems, there are similar issues in other disciplines as well. And nobody, absolutely nobody, controls a complex system only at the end points. This is not even an academic insight, this is high school physics. From detlef.bosau at web.de Tue Feb 18 07:54:31 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Feb 2014 16:54:31 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <1392735042.09327130@apps.rackspace.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> Message-ID: <53038237.4050702@web.de> Am 18.02.2014 15:50, schrieb dpreed at reed.com: > First of all, I am well trained in both queueing theory and control theory. If you want to talk about the mathematics of optimal control in non-guassian, non-poisson systems that have coupling between service rate and request rate, I'm your man. You guys are so far less informed about the fundamental theory, it's sad. Obviously not enough. The whole situation is (extremely well!) comparable to our current macroeconomics situation - and you are trapped in exactly the same pitfall as Ben Bernanke, Wolfgang Sch?uble, our Iron Lady (AKA "The Nought"), President Obama and most of the world: Irving Fishwer was awarded the noble price for the concept of monetarism. If the money supply is perfect, anything is perfect. Refined by Milton Friedman: The only important thing is the money supply, so we must control the money supply. I think it will take a second world wide crisis in economics until we eventually understand, that the money supply is simply not the matter of interest, but the distribution of assets is the very point. I don't know whether half of Greece's population must starve to death or whether Larry Fink must have his teeth replaced by diamonds first, but at the end of the day, we will understand that any successful control system requires two inevitable elements: First a correct system model, second a correct understanding what should be achieved. Both failed in both cases, in economy (where the monetaristic syststem is simply nonsense and controlling the money supply is even more nonsense, but perhaps Larry Fink enjoys fried dollar bills with a tasty sauce) and in networks as well. We focus on the amount of data passing around in the network, excuse me, that simply does not matter, that was clear even in 1972 when we dropped Davies isarithmic approach which was exactly the same. Today whe have thousands of reasons why a CWND of, say, 1 MByte is absolutely correct for a certain TCP connection. Unfortunately the mobile node who surfs the Internet moves aside some centimetres and his radio interface suffers from multipath intereference - and the path cannot carry 1 MByte any longer but only 100 kByte. In that case, we can simply forget all mathematical models and statistics and control theory - or we could apply it correctly. Basically, this is absolutely no rocket science. But it requires the courage to eventually address the right things. And the first thing to address is the word "congestion". We are talking about a chain of flow control problems here - no TCP sender is interested in what a final receiver will accept but what the next hop will accept! And the plant from sender to receiver is not a "stationary telephone line with some well defined capacity", so we can play Telix and Kermit about it but it is much more complex and our models are way to coarse here. I have to apologize for being upset. But the analogies to macroeconomics are evident here - and perhaps it is not shon on national TV or on CBS, but there are people starving to death because some lunatic politicians and economists address the wrong things! From detlef.bosau at web.de Tue Feb 18 11:39:44 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Feb 2014 20:39:44 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <1392746427.24473918@apps.rackspace.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> Message-ID: <5303B700.4020609@web.de> Am 18.02.2014 19:00, schrieb dpreed at reed.com: > Well, if you compare economics (barely a science, but only when it actually allows data to disconfirm hypotheses, which almost never happens) with queueing theory and control theory, I cannot refute you. You cannot refute queueing theory and control theory. (Listen to yourself ;-) You quite often do EXACTLY this ;-)) However, the question is whether these two apply to computer networks. You told us more than once that we have hardly realistic models for user behaviour. (We know how to model Monsieur Poisson and Andrej Andrejewich Markov - however, how do we model the rest of the world?) Than all these theories assume potentially infinite buffers. And for control theory: If you really want to apply system theory here (you did not appreciate my thoughts in this direction in some off list discussions) you are in the need of a model. No problem: The packets are the "energy": packets on the fly (links) are "kinetic energy", packets in queues are "power", the state variables are buffer queues (which are limited in real life) and links (the transport capacity of which is HIGHLY volatile as we discussed in many details) , in addition: Which state variables are to be taken into consideration? (Of course the links and buffers along the path, unfortunately, this may change.) VJ even talks about a "Ljapunov function" which is actually ludicrous. The concept of Ljapunov stability intends wo make a system behave close to a given trajectory in state space. How do we apply this concept to a flow where we cannot even agree upon the state variables in charge. Yes, you cannot refute queuing theory and control theory. But applying these to a model, where they do not apply is hand waving with formulae. And that's exactly what you often refuse when being done by others ;-) From andrewmcgr at google.com Tue Feb 18 15:54:12 2014 From: andrewmcgr at google.com (Andrew Mcgregor) Date: Wed, 19 Feb 2014 10:54:12 +1100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <5303B700.4020609@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> Message-ID: I had this in another tab: ftp://ftp.feq.ufu.br/Luis/HYBRID/Hibrido_Curso/Ref/shs-ijhs04.pdf We have some really good models, that paper is the tip of a really large iceberg. The hard thing is shoehorning them in to a legacy protocol's header fields, and then getting agreement across some large number of administrative domains to actually use the resulting protocols. On 19 February 2014 06:39, Detlef Bosau wrote: > Am 18.02.2014 19:00, schrieb dpreed at reed.com: > > Well, if you compare economics (barely a science, but only when it > actually allows data to disconfirm hypotheses, which almost never happens) > with queueing theory and control theory, I cannot refute you. > > You cannot refute queueing theory and control theory. (Listen to > yourself ;-) You quite often do EXACTLY this ;-)) > > However, the question is whether these two apply to computer networks. > > You told us more than once that we have hardly realistic models for user > behaviour. (We know how to model Monsieur Poisson and Andrej Andrejewich > Markov - however, how do we model the rest of the world?) Than all these > theories assume potentially infinite buffers. > > And for control theory: If you really want to apply system theory here > (you did not appreciate my thoughts in this direction in some off list > discussions) you are in the need of a model. > > No problem: The packets are the "energy": packets on the fly (links) are > "kinetic energy", packets in queues are "power", the state variables are > buffer queues (which are limited in real life) and links (the transport > capacity of which is HIGHLY volatile as we discussed in many details) , > in addition: Which state variables are to be taken into consideration? > (Of course the links and buffers along the path, unfortunately, this may > change.) > > VJ even talks about a "Ljapunov function" which is actually ludicrous. > The concept of Ljapunov stability intends wo make a system behave close > to a given trajectory in state space. How do we apply this concept to a > flow where we cannot even agree upon the state variables in charge. > > Yes, you cannot refute queuing theory and control theory. > > But applying these to a model, where they do not apply is hand waving > with formulae. > > And that's exactly what you often refuse when being done by others ;-) > > -- Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 1071 2221 From detlef.bosau at web.de Wed Feb 19 00:36:30 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 19 Feb 2014 09:36:30 +0100 Subject: [e2e] Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <1392762531.99455268@apps.rackspace.com> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> Message-ID: <53046D0E.1040401@web.de> because I'm out and about to see my dentist. (very adequate for a networking guy: I will get a bridge.) We all remember Ethernet. (This funny network with the yellow garden hose.) And - jamming. Why was jamming necessary? Because of the systems step response function applied to the first bit of the preamble. And "Gibbs phenomenon". So a sending Ethernet card ignores excess voltage on the line for the first 40 (?) bit in order to ignore a "spurious collision". Unfortunately, system theory does not really apply here, otherwise we could eventually solve our energy problems because in the mathematical abstraction, some voltages and currents in step- or impulse responses grow beyond all limits. In the formulae. Actually, and luckily, some of the voltages and currents are restricted by the power supply. When you start with control theory on simple systems - and the literally station wagon hurtling down the highway (Tanenbaum) runs with ten times the speed of the light, you may perhaps discover, may, some people don't ever, understand that models are only an approximation to reality and perhaps some models are not always helpful. And with particular respect to networks: State variables in difference or differential equations are never bounded. In theory, they may grow beyond all limits. Both for power (infinite storage capacity in bridges, hopefully my mouth will be big enough in a few minutes because of the dimensions of my new bridge) and "kinetic energy" on links (this damned speed of the light, I will send a severe complaint to Albert afterwards). That was the long explanation. Executive summary for "control theory applied to computer networks": Forget it. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Feb 19 00:56:27 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 19 Feb 2014 09:56:27 +0100 Subject: [e2e] Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <53046D0E.1040401@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> Message-ID: <530471BB.3020601@web.de> And this is particularly true for engineers as they often don't see the "real" system equations but only the Laplace transform. (And from linear systems we know even the problem of hidden oscillations (is the term correct?) which are hidden by the calculus - not in physical reality. However a VERY TOUGH!!!! problem for a pure end to end approach.) (I don't know, whether this saying is really common in English but it was common for our former chancellor Schroeder: "When the going gets tough, the tough get going.) Am 19.02.2014 09:36, schrieb Detlef Bosau: > because I'm out and about to see my dentist. (very adequate for a > networking guy: I will get a bridge.) > > We all remember Ethernet. (This funny network with the yellow garden hose.) > > And - jamming. Why was jamming necessary? Because of the systems step > response function applied to the first bit of the preamble. > And "Gibbs phenomenon". > So a sending Ethernet card ignores excess voltage on the line for the > first 40 (?) bit in order to ignore a "spurious collision". > > Unfortunately, system theory does not really apply here, otherwise we > could eventually solve our energy problems because in the mathematical > abstraction, some voltages and currents in step- or impulse responses > grow beyond all limits. > > In the formulae. > > Actually, and luckily, some of the voltages and currents are restricted > by the power supply. > > When you start with control theory on simple systems - and the literally > station wagon hurtling down the highway (Tanenbaum) runs with ten times > the speed of the light, you may perhaps discover, may, some people don't > ever, understand that models are only an approximation to reality and > perhaps some models are not always helpful. > > And with particular respect to networks: State variables in difference > or differential equations are never bounded. In theory, they may grow > beyond all limits. Both for power (infinite storage capacity in bridges, > hopefully my mouth will be big enough in a few minutes because of the > dimensions of my new bridge) and "kinetic energy" on links (this damned > speed of the light, I will send a severe complaint to Albert afterwards). > > That was the long explanation. > > Executive summary for "control theory applied to computer networks": > > > Forget it. > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Feb 19 06:55:23 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 19 Feb 2014 15:55:23 +0100 Subject: [e2e] Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> Message-ID: <5304C5DB.3030700@web.de> Am 19.02.2014 12:22, schrieb Saverio Mascolo: > On Wed, Feb 19, 2014 at 9:56 AM, Detlef Bosau > wrote: > > And this is particularly true for engineers as they often don't > see the > "real" system equations but only the Laplace transform. > > > laplace transform are equivalent to linear differential equation Yes. And pigs can fly. You never read a text book on analysis and the requirements for the backward transformation to be unique? At least, things are extremele tricky here. Nevertheless: Differential equations are not suitable for the Internet, neither is the Laplace Transform. It is funny how the reactions are when I only point to what everyone knows for decades: We worship a religion here. From l.wood at surrey.ac.uk Wed Feb 19 12:46:57 2014 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Wed, 19 Feb 2014 20:46:57 +0000 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <5303B700.4020609@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com>,<5303B700.4020609@web.de> Message-ID: <290E20B455C66743BE178C5C84F1240847E6334720@EXMB01CMS.surrey.ac.uk> look at Fred Soddy's criticisms of economics, based on his modelling of physical systems and use of entropy and thermodynamics. congestion can be seen as heat being introduced into a physical system. routers and gateways are basically Maxwell's Demon. discards are lowering to ground state. if we're going to play analogies, let's use the physical universe for the analogy. refute THAT. someone must have had this thought already. would appreciate pointers to the literature. thanks Lloyd Wood http://about.me/lloydwood ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Detlef Bosau [detlef.bosau at web.de] Sent: 18 February 2014 19:39 To: dpreed at reed.com Cc: Ralph A. Schmid, dk5ras; end2end-interest at postel.org; Lars Wolf Subject: Re: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? Am 18.02.2014 19:00, schrieb dpreed at reed.com: > Well, if you compare economics (barely a science, but only when it actually allows data to disconfirm hypotheses, which almost never happens) with queueing theory and control theory, I cannot refute you. You cannot refute queueing theory and control theory. (Listen to yourself ;-) You quite often do EXACTLY this ;-)) However, the question is whether these two apply to computer networks. You told us more than once that we have hardly realistic models for user behaviour. (We know how to model Monsieur Poisson and Andrej Andrejewich Markov - however, how do we model the rest of the world?) Than all these theories assume potentially infinite buffers. And for control theory: If you really want to apply system theory here (you did not appreciate my thoughts in this direction in some off list discussions) you are in the need of a model. No problem: The packets are the "energy": packets on the fly (links) are "kinetic energy", packets in queues are "power", the state variables are buffer queues (which are limited in real life) and links (the transport capacity of which is HIGHLY volatile as we discussed in many details) , in addition: Which state variables are to be taken into consideration? (Of course the links and buffers along the path, unfortunately, this may change.) VJ even talks about a "Ljapunov function" which is actually ludicrous. The concept of Ljapunov stability intends wo make a system behave close to a given trajectory in state space. How do we apply this concept to a flow where we cannot even agree upon the state variables in charge. Yes, you cannot refute queuing theory and control theory. But applying these to a model, where they do not apply is hand waving with formulae. And that's exactly what you often refuse when being done by others ;-) From andrewmcgr at google.com Wed Feb 19 13:54:33 2014 From: andrewmcgr at google.com (Andrew Mcgregor) Date: Thu, 20 Feb 2014 08:54:33 +1100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <290E20B455C66743BE178C5C84F1240847E6334720@EXMB01CMS.surrey.ac.uk> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <290E20B455C66743BE178C5C84F1240847E6334720@EXMB01CMS.surrey.ac.uk> Message-ID: The best attempt at that so far as I know is "Joseph Hui and Ezhan Karasan, A Thermodynamic Theory of Broadband Networks with Application to Dynamic Routing, IEEE J. Selected Areas of Communications, 1995, v13 pp 991--1003". It works, but isn't as illuminating as some of the more recent work, using new mathematics to help. Keyword for that is 'network calculus'. On 20 February 2014 07:46, wrote: > look at Fred Soddy's criticisms of economics, based on his modelling of > physical systems and use of entropy and thermodynamics. > > congestion can be seen as heat being introduced into a physical system. > routers and gateways are basically Maxwell's Demon. discards are lowering > to ground state. > > if we're going to play analogies, let's use the physical universe for the > analogy. refute THAT. > > someone must have had this thought already. would appreciate pointers to > the literature. > > thanks > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: end2end-interest-bounces at postel.org [ > end2end-interest-bounces at postel.org] On Behalf Of Detlef Bosau [ > detlef.bosau at web.de] > Sent: 18 February 2014 19:39 > To: dpreed at reed.com > Cc: Ralph A. Schmid, dk5ras; end2end-interest at postel.org; Lars Wolf > Subject: Re: [e2e] Why don't we talk about segments/objects instaead of > layers? Re: Lost Layer? > > Am 18.02.2014 19:00, schrieb dpreed at reed.com: > > Well, if you compare economics (barely a science, but only when it > actually allows data to disconfirm hypotheses, which almost never happens) > with queueing theory and control theory, I cannot refute you. > > You cannot refute queueing theory and control theory. (Listen to > yourself ;-) You quite often do EXACTLY this ;-)) > > However, the question is whether these two apply to computer networks. > > You told us more than once that we have hardly realistic models for user > behaviour. (We know how to model Monsieur Poisson and Andrej Andrejewich > Markov - however, how do we model the rest of the world?) Than all these > theories assume potentially infinite buffers. > > And for control theory: If you really want to apply system theory here > (you did not appreciate my thoughts in this direction in some off list > discussions) you are in the need of a model. > > No problem: The packets are the "energy": packets on the fly (links) are > "kinetic energy", packets in queues are "power", the state variables are > buffer queues (which are limited in real life) and links (the transport > capacity of which is HIGHLY volatile as we discussed in many details) , > in addition: Which state variables are to be taken into consideration? > (Of course the links and buffers along the path, unfortunately, this may > change.) > > VJ even talks about a "Ljapunov function" which is actually ludicrous. > The concept of Ljapunov stability intends wo make a system behave close > to a given trajectory in state space. How do we apply this concept to a > flow where we cannot even agree upon the state variables in charge. > > Yes, you cannot refute queuing theory and control theory. > > But applying these to a model, where they do not apply is hand waving > with formulae. > > And that's exactly what you often refuse when being done by others ;-) > > > -- Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 1071 2221 From detlef.bosau at web.de Thu Feb 20 05:26:16 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 20 Feb 2014 14:26:16 +0100 Subject: [e2e] Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <290E20B455C66743BE178C5C84F1240847E6334720@EXMB01CMS.surrey.ac.uk> Message-ID: <53060278.8020709@web.de> Am 19.02.2014 22:54, schrieb Andrew Mcgregor: > The best attempt at that so far as I know is "Joseph Hui and Ezhan Karasan, A > Thermodynamic Theory of Broadband Networks with Application to Dynamic > Routing, IEEE J. Selected Areas of Communications, 1995, v13 pp 991--1003". > It works, but isn't as illuminating as some of the more recent work, using > new mathematics to help. Keyword for that is 'network calculus'. > > Thermodynamic Theory. Please get alive. Cars travel along streets, people walk along the pavement, neither of them suffers from congestion related drop, neither knows about "Thermodynamics". I once was told a VERY basic wisdom of engineering. "What cannot be achieved by a simple means can neither be achieved by a sopisticated means". So networking should be done by simple, well understood mechanisms. I don't see a real use for overcomplicated calculus. Particularly when the models are not really close to reality. From saverio.mascolo at gmail.com Fri Feb 21 02:07:10 2014 From: saverio.mascolo at gmail.com (Saverio Mascolo) Date: Fri, 21 Feb 2014 11:07:10 +0100 Subject: [e2e] Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <5304C5DB.3030700@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> Message-ID: On Wed, Feb 19, 2014 at 3:55 PM, Detlef Bosau wrote: > Am 19.02.2014 12:22, schrieb Saverio Mascolo: > > On Wed, Feb 19, 2014 at 9:56 AM, Detlef Bosau wrote: > >> And this is particularly true for engineers as they often don't see the >> "real" system equations but only the Laplace transform. >> > > laplace transform are equivalent to linear differential equation > > > Yes. And pigs can fly. > i would say like planets that fly following the Newton differential equations. I think you really need to do some fundamental studies, starting back since leonardo da vinci and galileo *?* La filosofia ? scritta in questo grandissimo libro che continuamente ci sta aperto innanzi a gli occhi (io dico l'universo), ma non si pu? intendere se prima non s'impara a intender la lingua, e conoscer i caratteri, ne' quali ? scritto. *Egli ? scritto in lingua matematica, *e i caratteri son triangoli, cerchi, ed altre figure geometriche, senza i quali mezzi ? impossibile a intenderne umanamente parola; senza questi ? un aggirarsi vanamente per un oscuro laberinto. *?* (Galileo Galilei, *Il Saggiatore *, Cap. VI ) > You never read a text book on analysis and the requirements for the > backward transformation to be unique? At least, things are extremele tricky > here. > of course are unique in all cases that are of practical interest. did you ever had a basic control course? the one where they teach how to use laplace transform to solve differential equations? > > Nevertheless: Differential equations are not suitable for the Internet, > neither is the Laplace Transform. > van Jacobson: "a network is made of gains, integrator and delays" please go back to study ;) On Wed, Feb 19, 2014 at 3:55 PM, Detlef Bosau wrote: > Am 19.02.2014 12:22, schrieb Saverio Mascolo: > > On Wed, Feb 19, 2014 at 9:56 AM, Detlef Bosau wrote: > >> And this is particularly true for engineers as they often don't see the >> "real" system equations but only the Laplace transform. >> > > laplace transform are equivalent to linear differential equation > > > Yes. And pigs can fly. > > You never read a text book on analysis and the requirements for the > backward transformation to be unique? At least, things are extremele tricky > here. > > Nevertheless: Differential equations are not suitable for the Internet, > neither is the Laplace Transform. > > It is funny how the reactions are when I only point to what everyone knows > for decades: We worship a religion here. > -- Saverio Mascolo, Full Professor Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo at poliba.it http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. From detlef.bosau at web.de Fri Feb 21 04:17:14 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 21 Feb 2014 13:17:14 +0100 Subject: [e2e] Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> Message-ID: <530743CA.4020309@web.de> In addition: The Laplace transform is not the problem. The problem is that the models are inadequate, no matter whether they are stated in differential equations (where particularly state variables are unbounded, hence packets may travel with tenfold the speed of the light or buffers must keep 1000 terabytes of data) or whether the same system is written in "frequency space". I know dozens of paper which pursue a control theoretic approach to Internet congestion control - I did not yet see even a single one which correctly modelled congestion drop. Most of the work even did not model the sliding window mechanism but was rate based. This is always funny as a game with numbers. But it does not describe the real world! E.g,, I'm actually sitting here in front of my PC and in a few seconds, I'm going to have finished this post and will click the "send" button in my MUA. As we all can imagine, my MUA will establish a TCP connection to my ISP's Remailer then and submit my mail for delivery. This TCP connection is most likely (I did not yet verify this in the Ubuntu kernel code) to be credit driven and not rate driven. And the relationship between credits/windows on the one hand and rates on the other is anything but trivial. I can't help it but I cannot split my brain and think about reality with the one half and about models with the other one. I don't want to bother anyone. But I think it is allowed to point out differences between the real world and models. Particularly as those differences are not rare in computer networking. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From andrewmcgr at google.com Fri Feb 21 09:10:56 2014 From: andrewmcgr at google.com (Andrew Mcgregor) Date: Sat, 22 Feb 2014 04:10:56 +1100 Subject: [e2e] Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <530743CA.4020309@web.de> References: <52D04B36.9010005@web.de> <52F98B87.6060004@isi.edu> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> Message-ID: You didn't read the paper I was pointing you at then. It models the window, and all the timers, and includes provision for cwnd clamping and various other optional features of TCP. The limitations you point out are indeed things that happen in naiive models. Not all models are that naiive. On 21 February 2014 23:17, Detlef Bosau wrote: > In addition: The Laplace transform is not the problem. The problem is > that the models are inadequate, no matter whether they are stated in > differential equations (where particularly state variables are > unbounded, hence packets may travel with tenfold the speed of the light > or buffers must keep 1000 terabytes of data) or whether the same system > is written in "frequency space". > > I know dozens of paper which pursue a control theoretic approach to > Internet congestion control - I did not yet see even a single one which > correctly modelled congestion drop. Most of the work even did not model > the sliding window mechanism but was rate based. > > This is always funny as a game with numbers. > > But it does not describe the real world! > > E.g,, I'm actually sitting here in front of my PC and in a few seconds, > I'm going to have finished this post and will click the "send" button in > my MUA. As we all can imagine, my MUA will establish a TCP connection to > my ISP's Remailer then and submit my mail for delivery. > > This TCP connection is most likely (I did not yet verify this in the > Ubuntu kernel code) to be credit driven and not rate driven. > And the relationship between credits/windows on the one hand and rates > on the other is anything but trivial. > > I can't help it but I cannot split my brain and think about reality with > the one half and about models with the other one. > > I don't want to bother anyone. But I think it is allowed to point out > differences between the real world and models. Particularly as those > differences are not rare in computer networking. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > -- Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 1071 2221 From detlef.bosau at web.de Fri Feb 21 11:05:40 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 21 Feb 2014 20:05:40 +0100 Subject: [e2e] Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> Message-ID: <5307A384.4070006@web.de> Am 21.02.2014 18:10, schrieb Andrew Mcgregor: > You didn't read the paper I was pointing you at then. It models the > window, and all the timers, and includes provision for cwnd clamping > and various other optional features of TCP. > > The limitations you point out are indeed things that happen in naiive > models. Not all models are that naiive. Shame on me. However, I did not expect that much news from a "thermodramatic" model ;-) However, I'm currently reading it. On page 2 I hang on: > For queues driven by point arrival processes the fluid-fl ow > approximation is valid when the > mean bu ffer length and the bu ffer size are large Hm. How do we model arrival processes? (When I have a glance at the paper, I read about Markov- and Poisson-Processes.) In addition, large buffer lengths and sizes sometimes are not our primary intention. Particularly, my comments to Saverio Masolo apply for fluid flow model as well. Particularly they do not cover some (unwanted but often not fully avoidable) effects like unused time slots, in other words: Fluid flow models have an inherent work conservative view. While links in practical networks may stay idle. > > > On 21 February 2014 23:17, Detlef Bosau > wrote: > > In addition: The Laplace transform is not the problem. The problem is > that the models are inadequate, no matter whether they are stated in > differential equations (where particularly state variables are > unbounded, hence packets may travel with tenfold the speed of the > light > or buffers must keep 1000 terabytes of data) or whether the same > system > is written in "frequency space". > > I know dozens of paper which pursue a control theoretic approach to > Internet congestion control - I did not yet see even a single one > which > correctly modelled congestion drop. Most of the work even did not > model > the sliding window mechanism but was rate based. > > This is always funny as a game with numbers. > > But it does not describe the real world! > > E.g,, I'm actually sitting here in front of my PC and in a few > seconds, > I'm going to have finished this post and will click the "send" > button in > my MUA. As we all can imagine, my MUA will establish a TCP > connection to > my ISP's Remailer then and submit my mail for delivery. > > This TCP connection is most likely (I did not yet verify this in the > Ubuntu kernel code) to be credit driven and not rate driven. > And the relationship between credits/windows on the one hand and rates > on the other is anything but trivial. > > I can't help it but I cannot split my brain and think about > reality with > the one half and about models with the other one. > > I don't want to bother anyone. But I think it is allowed to point out > differences between the real world and models. Particularly as those > differences are not rare in computer networking. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > > mobile: +49 172 6819937 > > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de > http://www.detlef-bosau.de > > > > > -- > Andrew McGregor | SRE | andrewmcgr at google.com > | +61 4 1071 2221 -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri Feb 21 13:22:34 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 21 Feb 2014 22:22:34 +0100 Subject: [e2e] A note on entropy Re: Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> Message-ID: <5307C39A.30503@web.de> Am 21.02.2014 18:10, schrieb Andrew Mcgregor: > You didn't read the paper I was pointing you at then. It models the > window, and all the timers, and includes provision for cwnd clamping and > various other optional features of TCP. > > The limitations you point out are indeed things that happen in naiive > models. Not all models are that naiive. Where I run into trouble with the paper you pointed to is the non decreasing level of entropy in closed systems. I think the model of Hui is a quite straight forward interpretation of VJCC. However, I encountered the most severe problems with wireless networks where you will fail to interpret the propagation of information as a "transport" of energy which is continuously conveyed between buffers / increasing the level of entropy. Perhaps the most important lesson I learned during the past 14 years is that there is no reasonable way to model mobile networks. Meanwhile, I think it is not even necessary to "model" links from a congestion control perspective to model links for a simple reason: Congestion does not occur on a link but on switching nodes. So the idea is to focus on the nodes - and not primarily on the links (which are reasonably dealt with by schedulers.) From andrewmcgr at google.com Fri Feb 21 14:01:56 2014 From: andrewmcgr at google.com (Andrew Mcgregor) Date: Sat, 22 Feb 2014 09:01:56 +1100 Subject: [e2e] A note on entropy Re: Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: <5307C39A.30503@web.de> References: <52D04B36.9010005@web.de> <698FB1BF-0C39-4BDB-8912-864DB86C6D05@cisco.com> <52FA3628.50007@isi.edu> <52FD64D1.20502@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> Message-ID: You still need a model of the link's distribution of forwarding, to allow any useful end-to-end conclusions. That can be done, but of course those distributions are often fairly pathological for wireless links. On 22 February 2014 08:22, Detlef Bosau wrote: > Am 21.02.2014 18:10, schrieb Andrew Mcgregor: > > You didn't read the paper I was pointing you at then. It models the > > window, and all the timers, and includes provision for cwnd clamping and > > various other optional features of TCP. > > > > The limitations you point out are indeed things that happen in naiive > > models. Not all models are that naiive. > Where I run into trouble with the paper you pointed to is the non > decreasing level of entropy in closed systems. > > I think the model of Hui is a quite straight forward interpretation of > VJCC. > > However, I encountered the most severe problems with wireless networks > where you will fail to interpret the propagation of information as a > "transport" of energy which is continuously conveyed between buffers / > increasing the level of entropy. > > Perhaps the most important lesson I learned during the past 14 years is > that there is no reasonable way to model mobile networks. > > Meanwhile, I think it is not even necessary to "model" links from a > congestion control perspective to model links for a simple reason: > Congestion does not occur on a link but on switching nodes. > So the idea is to focus on the nodes - and not primarily on the links > (which are reasonably dealt with by schedulers.) > > -- Andrew McGregor | SRE | andrewmcgr at google.com | +61 4 1071 2221 From detlef.bosau at web.de Fri Feb 21 15:13:10 2014 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 22 Feb 2014 00:13:10 +0100 Subject: [e2e] A note on entropy Re: Are our models correct? Re: Just a very quick remark on system theory Re: Why don't we talk about segments/objects instaead of layers? Re: Lost Layer? In-Reply-To: References: <52D04B36.9010005@web.de> <52FE4ED0.3050601@web.de> <52FE726D.7080703@web.de> <5302C22E.9070905@web.de> <53036B5A.8050703@web.de> <1392735042.09327130@apps.rackspace.com> <53038237.4050702@web.de> <1392746427.24473918@apps.rackspace.com> <5303B700.4020609@web.de> <1392762531.99455268@apps.rackspace.com> <53046D0E.1040401@web.de> <530471BB.3020601@web.de> <5304C5DB.3030700@web.de> <530743CA.4020309@web.de> <5307C39A.30503@web.de> Message-ID: <5307DD86.6020503@web.de> Am 21.02.2014 23:01, schrieb Andrew Mcgregor: > You still need a model of the link's distribution of forwarding, to > allow any useful end-to-end conclusions. For conclusions you may be right. However, the question is whether we inevitably need it for decisons. > That can be done, but of course those distributions are often fairly > pathological for wireless links. > ;-) That's the point. And even more: They are sometimes hardly reproducible. Perhaps, I should make a difference here between conclusions and decisions. (Once again, I refer to Nagle's algorithm. The rational behind his "decision algorithm", i.e. when a packet smaller than MSS may be sent, is quite interesting here. There is a decision to be made - without any knowledge about the source or a links possible throughput. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de