http://blog.gmane.org/gmane.network.end2end hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.end2end/7267 <pre> I am sorry Noel, but I have to disagree at least with the attitude. Flow control can occur at any layer and pretty much has. The fact that it may not currently doesn't mean it never will. This is precisely how the craft mentality that permeates this field got started. One of the things I impress on my students (with examples) is that old solutions never go away, they return, often with somewhat different parameters. At today's data rates, it is unlikely to see flow control at the data link layer, or elsewhere in between, but who knows! And why I define flow control as feedback co-located with the resource being controlled and congestion control as feedback not co-located with the resource and try to stay away from the more vocational definitions. Yes, it was quite clear at the time that flow control at the data link layer had a different purpose than flow control at the Transport layer. (I should probably qualify that. At least, it was quite clear to some people. I have had a few surprises of late of things that I thought were quite clear early on and seem to have been totally missed.) At the very least all of the networks at the time (ARPANET, NPL, CYCLADES, etc.) used a data link protocol that did retransmission and flow control. By the end of the 70s, it was probably disappearing. IEN#1 (1977) conjectures that ingress flow control at gateways is probably going to be important. By this time, quite a lot of research had been done on congestion control in these kinds of networks. Take care, John </pre> John Day 2013-05-24T21:09:13 http://permalink.gmane.org/gmane.network.end2end/7266 <pre>FWIW, history questions may be more usefully discussed here: internet-history&lt; at &gt;postel.org Joe On 5/24/2013 8:34 AM, Detlef Bosau wrote: </pre> Joe Touch 2013-05-24T21:10:57 http://permalink.gmane.org/gmane.network.end2end/7265 <pre> FWIW, in section 6.2 of ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.gz there's discussion of inferring that way back in the Dark Ages (mid-1990s) multiple TCP implementations did indeed respond to Source Quench. Vern </pre> vern< at >ee.lbl.gov 2013-05-24T20:31:46 http://permalink.gmane.org/gmane.network.end2end/7264 <pre> Noel, Jon Postel really wanted Source Quench to work. Walt Prue under Jon Postel's direction made an exhaustive study of possible source quench algorithms in their RFC 1016, July 1987, with the hopeful title: "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID) The following sentence from that document says it all; "All of our algorithms oscillate, some worse than others." Dave Clark is fond of saying that the distinctive property of research is that it is allowed to fail. Source Quench was a part of the TCP/IP development that failed. Another indication of its failure is that a SQ may go to a host that is not causing the congestion. AFAIK,no one ever used Source Quench, because of its apparent defects. Sending a packet when there is an overload must be a losing strategy! Yes, although we (and I think you were involved) did not have the courage to deprecate SQ when we wrote Host Requirements, a couple of years after 1016. I suspect SQ was finally killed in Router Requirements, RFC 1812, in 1995. Bob Braden </pre> Bob Braden 2013-05-24T19:22:40 http://permalink.gmane.org/gmane.network.end2end/7263 <pre>Am 24.05.2013 19:48, schrieb Noel Chiappa: That's certainly correct for TCP. I've not read that much papers on hop to hop flow control - although I think it could well make sense. In the case of TCP. ;-) As you may know, I'm putting a little question mark behind end to end congestion control. No doubt here. And (this is again history ;-)) why was this abandoned? (Does anyone happen to recall the reasons?) </pre> Detlef Bosau 2013-05-24T18:03:36 http://permalink.gmane.org/gmane.network.end2end/7262 <pre> &gt; From: Detlef Bosau &lt;detlef.bosau&lt; at &gt;web.de&gt; First, 'flow control' these days is taken to mean 'end-end' - i.e. the original source not sending data faster than the ultimate destination can use it. This has always been handled at the tranport layer - in the case of TCP, by the TCP window. Rate control based on the ability of the _network_ to carry traffic (which is what you seem to be asking about below) is now usually called 'congestion control'. I don't recall how carefully we differentiated between the two back then, although I am quite sure we already understood the difference. &gt; When I read the original catenet work by Cerf, the Catenet employed &gt; link layer flow control. I'm not sure that's quite correct: without checking the documents for myself, I suspect they would have understood that if the source is connected to network A (a fast network), and the next hop is network B (a slow network), the link layer flow control on network B would be no use in slowing down the host - since it's not connected to network B. As I recall, we thought ICMP Source Quench would be the way congestion control would be propogated back to the host. &gt; To my understanding, this was abandoned when the ARPAnet turned into &gt; the Internet (in 1981?). After this change, the link layer flow control &gt; was replaced by a "silent discard" of packets which cannot be accepted for &gt; delivery. &gt; Is this correct? &gt; What was the reason for this decision Source quench turned out not to work (for reasons I don't recall clearly any more - Google will probably turn some things up). Possibly we just didn't understand enough about congestion control at that early stage to make it work 'well'. I don't recall when we stopped trying to use it - I think it was a little later than the cutover, actually. We then ran without any congestion control at all for a while, and that caused massive problems. Finally Van Jacobsen turned up and saved the day. His approach turned out to only need packet drops as a congestion signal, so SQ was not needed any more (and IIRC it has been deprecated). &gt; have there been any alternative approaches? Well, there have been some alternatives explored, I'm not sure how widely any are used. RED detects incipient congestion, and 'signals' it by dropping packets (dropped packets being the typical 'congestion signal' post-Van). I classify this as a different approach because although the _signal_ is the same, the _triggering mechanism_ is different. ECN is another approach. It's different from the early Source Quench stuff in that i) I don't think it waits until queues are full (as SQ did), and it doesn't return a separate packet to the source. This is all from (dim) memory. Google will probably turn up more. Noel </pre> Noel Chiappa 2013-05-24T17:48:32 http://permalink.gmane.org/gmane.network.end2end/7261 <pre>Am 24.05.2013 19:16, schrieb John Day: However, the delay could be kept quite small - as wee see in TCP flow control. At least in CSMA/CD Ethernet, it is implicitly given by the MAC scheme: There can only be one packet on the media. As I said, I would like to understand these decisions, particularly as many of them are not self evident and perhaps may be questioned. </pre> Detlef Bosau 2013-05-24T18:16:07 http://permalink.gmane.org/gmane.network.end2end/7260 <pre>The nature of the link layer protocol is mostly determined by the characteristics of the media. In the early networks, it was not uncommon for the link layer to be a protocol that looked something like what we think of HDLC, i.e. ack/retransmission with fixed (usually small) window size. In these early fixed window protocols, ack and flow control were seen as all part of the window scheme. The quality of the lines pretty much dictated the use of these sorts of protocols over long distances. As the data rate increased, the delay imposed by this class of protocols made them inadequate. With the advent of LANs, these HDLC-like protocols were not really required. But to say, they went completely out of use by 1981 would probably be incorrect. In the US, some of the longer runs of the ARPANET, such as Illinois to Utah were relatively error free. At the same time, short runs like Rome, NY to Cambridge had much higher rates. It would be certainly be incorrect to conclude that a decision was made not to use them, especially since the ARPANET was not turned off until 1990 or thereabouts. At 5:34 PM +0200 5/24/13, Detlef Bosau wrote: </pre> John Day 2013-05-24T17:16:07 http://permalink.gmane.org/gmane.network.end2end/7259 <pre>O.k., perhaps this is for all readers with grey hair (if there is still hair at all....) and grey beards ;-) When I read the original catenet work by Cerf, the Catenet employed link layer flow control. To my understanding, this was abandoned when the ARPAnet turned into the Internet (in 1981?). After this change, the link layer flow control was replaced by a "silent discard" of packets which cannot be accepted for delivery. Is this correct? What was the reason for this decision and have there been any alternative approaches? </pre> Detlef Bosau 2013-05-24T15:34:27 http://permalink.gmane.org/gmane.network.end2end/7258 <pre> Boy, you are right about that! It is *one* of the failures. ;-) No, I am conflating address with the homeomorphism used to create the address space. No one suggested they did. The peculiar thing about examples is that they are *examples* and represent only a single point in what could be a very large space. They don't necessarily have all the properties of all the other examples from the same space. Very peculiar. Actually, this is incorrect. All addresses support aggregation (given the previous definitions I used). Although not all aggregations are useful for finding routes or establishing "physical nearness." Absolutely. An address is a type of name. Nothing new there. That has been well accepted as long as I have been around. John </pre> John Day 2013-05-10T22:22:05 http://permalink.gmane.org/gmane.network.end2end/7257 <pre> On May 8, 2013, at 1:45 PM, John Day &lt;jeanjour&lt; at &gt;comcast.net&gt; wrote: Agreed; this, however, is one of the key failures of the "slice" model of network virtualization. It binds network interfaces and to OS components (slivers), and maps slivers to virtual networks. That inherently inhibits gateways - devices (or slivers) that bridge traffic between different VNs. You're conflating "address" with a knowledge of the topology of its location space. Location spaces need not be Euclidean or even continuous. Consider street addresses in Tokyo; two addresses on the same street typically satisfy no spatial "nearness" metric (the numbers are sometimes assigned in the order they are built, so 'near' is a temporal metric, rather than spatial). And not all addresses support aggregation. Finally, addresses *are* names. A "name" is just an identifier; once you assign meaning, it becomes something else - an endpoint identifier, a location identifier, etc. Joe </pre> Joe Touch 2013-05-10T15:27:46 http://permalink.gmane.org/gmane.network.end2end/7256 <pre>Wasn't this obvious? This is why they were called network "addresses" and not names. The parallel was to OSs. As Shoch put it, Application names indicate "what" and addresses indicate "where" and routes were "how to get there." He didn't quite have the whole picture but close enough for this discussion. Application names are suppose to be location-independent. Except on broken OSs, you don't need to know what medium a file is on. Addresses are suppose to be location-dependent, where given two addresses you should be able to tell if they are "near" each other for some definition of "near." (not necessarily implying physical location, that while it can be useful is just the naive first thought.) Although street addresses often have this property to varying degrees. ;-) Chicago more so than Boston! ;-) Although as I finally realized, application names are location-dependent too, just with a different meaning of "location." At 2:52 PM -0400 5/8/13, Noel Chiappa wrote: </pre> John Day 2013-05-08T20:45:33 http://permalink.gmane.org/gmane.network.end2end/7255 <pre> &gt; (especially due to the much later decision to conflate &gt; endpoint-identifier with route that got made by default at BBN, perhaps &gt; just to get the thing bootstrapped) I see that differently... The thing is that path selection, to scale, just has to have a namespace in which things can be aggregated. (You just can't give everyone a complete map of every last physical asset in the entire network.) IP _only had one namespace available_. So, yeah, as the network grew it had to be organized in a way that was aggregatable. That started to happen early on, with subnets, although it didn't come into full flower until later, with CIDR. Yes, the very early network did have addresses that (at the 'network' level) were flat - but even then, hosts were not free to move from network to network and keep their 'identity' - because internet-wide path selection didn't (couldn't?) track individual hosts. It was inevitable that that aggregation would ensue as the network got larger - as a direct, and unavoidable consequence of the fact that IPv4 had only one namespace. A number of related issues were pointed out by Jerry in the paper that eventually became RFC-1498, and those too pointed the same way: not enough namespaces. Noel </pre> Noel Chiappa 2013-05-08T18:52:37 http://permalink.gmane.org/gmane.network.end2end/7254 <pre>Thanks, Dave. Those emails clarify a lot. At 7:53 AM -0400 5/3/13, dpreed&lt; at &gt;reed.com wrote: </pre> John Day 2013-05-04T22:25:21 http://permalink.gmane.org/gmane.network.end2end/7253 <pre> Right. Indeed, wireless can be point-to-point as well. Excellent. Alas, but you are right. The constraints of software are sufficiently weak that unlike those of physics which are more constraining, it is still often possible to do it wrong. "Deeply entrenched," indeed. (Some would say a synonym for tradition.) Strongly reasoned, less so. As recently described by its author, it is this binding that thwarts mobility. Indeed this "notion" exists in two different layers. In fact, it is a general property of all layers. But I fail to see how that is an argument to require a pseudo-header. It is far from distinct. The two are tightly bound by header if nothing else. Yes, most other protocols have not adopted that approach. But the coupling between the two is very very loose. I realize this is the definition, and I would even agree with including the same error-check-code, if they were in the same layer. But since it is said they aren't, I fail to see the need and I definitely see the constraints. Is there some condition in which a router might put a TCP packet on a different IP packet? The only reason I can see for having it. This was previously covered. There is no L7 or L6. Those were fictions that were dispensed with in 1983. Excellent. That was my point. The field has the wrong name. Actually no. It isn't useful and was only important to make the point that it was a "protocol-type" as opposed to merely a "protocol-id." If there was a "protocol-instance-id" I would think it would be more useful if one left the protocol out of it entirely. Of course, then it would be a port-id. ;-) Most definitely. That is my point. Excellent! then you agree! The purpose of the protocol-id field in IP is identify the syntax of the encapsulated protocol. Not of my concern. Good discussion, Joe. Take care, John </pre> John Day 2013-05-02T23:42:05 http://permalink.gmane.org/gmane.network.end2end/7252 <pre>Hi, John, On 5/2/2013 4:42 PM, John Day wrote: ... It's an argument that it IS required in all current Internet transports. It is NOT an argument that it has to be required in a new transport protocol in the Internet, or in other new stacks. ... A router should never do anything to the contents of an IP payload, IMO. However, isn't that the definition of how a NAT works? ... Yes, but when we're talking about existing protocols, the name is there. New protocols might use more accurate terms, just as IPv6 has a "hopcount" instead of a "TTL". ... The destination port ID in a SYN encodes the service protocol, which is a protocol-type-id. It isn't an instance-id; the instance-id is the combination of the IP addresses and port numbers taken as a set. Yes. Same for the destination port of the initial SYN in TCP. ... Back at ya' ;-) Joe </pre> Joe Touch 2013-05-02T23:58:26 http://permalink.gmane.org/gmane.network.end2end/7251 <pre>Hi, John, On 5/2/2013 6:22 AM, John Day wrote: ... Agreed; I mistyped; I meant "only if that point-to-point link". Wireless includes point-to-point links, in which the information is either collimated (e.g., space-based laser links) or otherwise restricted within the link layer (e.g., CDMA). But I think we now agree - connection ID is a connection demultiplexer within a context. It is required only if there is more than one connection to a given endpoint. An endpoint ID is an endpoint demultiplexer, and it is required only if there is more than one receiver on a link. In order to stripe connections or shift them across links or endpoints within a link, a connection ID needs to be context-independent, i.e., unique across the potentially shared uses. That's a distinct feature of some, but not all, connection IDs. The pseudoheader is an artifact of the TCP/IP split, which isn't as clean as often claimed. It is used in other transport protocols built on IP, e.g., DCCP and SCTP. It is not a matter of tradition; it is deeply entrenched with the notion of endpoint and that this notion exists at two different layers that share at least some of the context (IP addresses). I'm not sure why you consider TCP not to have separate control and data, but if it's not distinct enough, consider the other protocols cited above. The transport layer flow is *defined* as the socket pair, which is defined in TCP (and used in other Internet transports) as combining the transport header context (port pair) with the IP context (IP address pair), the latter of which is part of the pseudoheader for that reason. If the IDs are not carried within the messages, how are multiplexed messages to be demultiplexed? In the context of a transport protocol, the layer above that interacts with the protocol to create flows, respond to them, and send/receive messages is defined as the "application". That may or may not be L7. ... That depends on your parsing of "-id". I think you interpret "protocol-id" as meaning "protocol-instance-identifier", where the more common interpretation (AFAICT) is "protocol-type-identifier". That's because we don't typically have current cases with multiple instances of a single protocol. We have flows, but that's a different thing. There could be multiple protocol instances each with multiple flows. So I interpret "protocol-id" as I think most people do. It can't be a protocol instance field. But you haven't explained why this is important or useful. That's a separate thread, most likely. Type is required to demultiplex different upper layer protocols (here, network layers) that share a lower layer protocol (here, ethernet). Again, type is distinct from flow. Yes, that's what I said several times ;-) The only way around that is to indicate it out-of-band, e.g., in a different layer, and tie it to identifiers (demultiplexing of type or instance) at other layers or to a physical entity (a single physical link that isn't demuxed). The latter is more like a circuit. Joe </pre> Joe Touch 2013-05-02T17:13:58 http://permalink.gmane.org/gmane.network.end2end/7250 <pre>Sorry, I got a bit busy and then this got lost on my desktop. At 8:27 PM -0700 4/28/13, Joe Touch wrote: No, one does not need to go as far as multipoint links. All that is needed are multiple applications trying to use the same media on a point-to-point link. In that case, a connection-id or flow-id is required; however, addresses are not required. It is true, that if it is a multi-drop or multi-point link, then addresses are required. Basically, addresses are necessary, if 'the wire" ;-) has more than 2 ends! as wireless clearly does. Not in the least, owing to the distinctions noted earlier in this thread, so-called striping and changing addresses are handled quite elegantly. Actually not. That is one of the more interesting aspects. The argument for the pseudoheader has always been a bit shaky. No other Transport Protocol except UDP either within or outside the IETF found the need for it. There have been many discussions about removing it, but as you know tradition has always won out. But putting that aside, separating IP from TCP caused more problems than it solved. Frankly, looking at the range of experience with this class of protocols and a careful analysis of their structure indicates TCP was split in the wrong direction. It would be much more productive to separate it along lines of control and data. i.e. data transfer and feedback control. Then UDP is simply a degenerate case. Huh? Next you are going to tell me that it is "small, green and split three ways"! ;-) It is also worth noting that it is important that for security reasons, that identifiers shared between layers not be carried in protocol and that identifiers used by a protocol machine to distinguish flows be identifiers it created. I tried to be careful in how I worded that. It is true that something must respond to a request for connection and create a binding between the requested application and the flow that may be created. There is not necessary for the application to have done anything. See below. Ahhh, so the "protocol-id" field in IP is not a protocol-id field. Actually, that was my point. Given how it is used, it can't be a protocol-id field. That it is used to identify the kind of protocol in the layer above, i.e. as you say, the type. But why is it necessary to identify the "protocol-type"? Why are there such fields in IP and Ethernet? "Type" is not really required for multiplexing. There are much more flexible ways to identify flows for multiplexing. Why does the receiver need to know the type of protocol? Perhaps so it knows how to interpret the header in the layer above? Indeed. But this email is already too long. ;-) I think there is a reference someplace for this. I will have to find it. Take care, John </pre> John Day 2013-05-02T13:22:42 http://permalink.gmane.org/gmane.network.end2end/7249 <pre>The benefit of decoupling the service name from the destination port - in the current Internet - is an increased number of potential concurrent (or recently closed) connections. That's described in the draft I posted earlier. The overhead need apply only to the first packet of a TCP connection. Joe On 4/28/2013 12:11 PM, Kevin Mason wrote: </pre> Joe Touch 2013-04-29T22:00:22 http://permalink.gmane.org/gmane.network.end2end/7248 <pre>See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt Port numbers are still useful to demultiplex multiple connections to the same service, e.g., multiple concurrent HTTP sessions. But there's no reason to couple the destination demultiplexer with the service name. Joe On 4/26/2013 2:01 PM, christian.tschudin&lt; at &gt;unibas.ch wrote: </pre> Joe Touch 2013-04-29T21:58:40 http://permalink.gmane.org/gmane.network.end2end/7247 <pre> On 4/26/2013 9:11 PM, John Day wrote: If you want to go that far off the map, connection-id would be needed only if that multipoint link supported different connections, either concurrently or in series. Your definition implies that a connection ID differentiates connections only within one pair of source/destination addresses. That definition precludes connections that span multiple addresses, e.g., striping, or those that can shift addresses. The TCP header includes the IP pseudoheader - notably for the purpose of connection identification. So TCP is already inconsistent with your proposed definition (it includes addresses in its connection ID, not merely as context for its connection ID), and consistent with the way I already described connections. Transport layer ID that is based on a transport header that subsumes a subset of the network header. Something has to listen in order for communication to proceed. That event need not precede the request to initiate from the other end, but it does precede the connection. ... It might be informative for you to explain that logic. It's a protocol-type, not a protocol-ID; types to not typically indicate instances. If you want an instance ID at that layer (i.e., within IP to demux different TCP instances rather than connections within one instance) you would need another field for that purpose. Assertions do not surprise me; only counterexamples. ;-) Joe </pre> Joe Touch 2013-04-29T03:27:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.end2end