From rbriscoe at jungle.bt.co.uk Tue Apr 4 10:59:04 2006 From: rbriscoe at jungle.bt.co.uk (Bob Briscoe) Date: Tue, 04 Apr 2006 18:59:04 +0100 Subject: [e2e] Can we revive T/TCP ? In-Reply-To: <4429D8A1.2080003@isi.edu> References: <84a612dd0603270848x28e1dc6fy7aae01139caff79f@mail.gmail.com> <5.2.1.1.2.20060324110234.00b118e0@boreas.isi.edu> <005901c64ffd$57c5aa50$0200a8c0@fun> <84a612dd0603270848x28e1dc6fy7aae01139caff79f@mail.gmail.com> Message-ID: <5.2.1.1.2.20060404184952.03d3df48@pop3.jungle.bt.co.uk> Mark, There's a wrinkle that argues against demux at the TCP layer, and instead argues for demux at the app layer in these cases: Equal Cost Multipath Routing (ECMP). Some vendor implementations of ECMP forward flows deterministically on the same path by hashing packets based on ip addr & port numbers to choose which interface to forward out of. Others ignore port numbers. But changing port numbers can mean your packet ends up crossing different routes. So, changing port numbers can imply the congestion information learned from the previous connection is no longer valid. The alternative is to be more prescriptive by saying ECMP algorithms MUST NOT use port numbers, but these algs are already out there. Another answer is encryption, to stop these boxes fishing around where they have no business anyway. Or you could use a role-based architecture :) Bob >Mark Handley wrote: > > On 3/25/06, Michael Welzl wrote: > >> The delay of these function calls (which is apparently the result > >> of SOAP processing more than anything else, but connection > >> setup can also take a while if nodes are very far from each other - > >> which, for instance, is true for some nodes in the EGEE Grid) > >> limits the parallelization granularity in Grids - reducing it would > >> be a real win in my opinion. > > > > I think the right solution to the T/TCP problem would be to clone an > > existing connection. This would remove most of the security issues, > > and let you bootstrap the congestion control state. > > > > Suppose you have an existing connection from A port p1 to B port p2. A > > then wants a new connection, so it sends a message from A port p3 to B > > port p2, with the SYN bit set, and a "connection clone" option that > > gives port p1 and the current sequence number from the first > > connection, together with the first mss of data. > > > > Basically this is data that could have been sent on the first > > connection anyway, but demuxing it at the TCP layer makes more sense > > for many applications. > > > > As this is a cloned connection, the congestion control state in both > > directions can be copied from the first connection (duplicate the RTT, > > split cwnd between the two), so there's no need to slowstart, and no > > startup transients to disrupt other network traffic. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 From touch at ISI.EDU Tue Apr 4 15:24:00 2006 From: touch at ISI.EDU (Joe Touch) Date: Tue, 04 Apr 2006 15:24:00 -0700 Subject: [e2e] Can we revive T/TCP ? In-Reply-To: <5.2.1.1.2.20060404184952.03d3df48@pop3.jungle.bt.co.uk> References: <84a612dd0603270848x28e1dc6fy7aae01139caff79f@mail.gmail.com> <5.2.1.1.2.20060324110234.00b118e0@boreas.isi.edu> <005901c64ffd$57c5aa50$0200a8c0@fun> <84a612dd0603270848x28e1dc6fy7aae01139caff79f@mail.gmail.com> <5.2.1.1.2.20060404184952.03d3df48@pop3.jungle.bt.co.uk> Message-ID: <4432F200.1070504@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Briscoe wrote: > Mark, > > There's a wrinkle that argues against demux at the TCP layer, and > instead argues for demux at the app layer in these cases: Equal Cost > Multipath Routing (ECMP). > > Some vendor implementations of ECMP forward flows deterministically on > the same path by hashing packets based on ip addr & port numbers to > choose which interface to forward out of. Others ignore port numbers. Whether that matches your intent is determined by your definition of "flow". > But changing port numbers can mean your packet ends up crossing > different routes. So, changing port numbers can imply the congestion > information learned from the previous connection is no longer valid. There are many forwarding algorithms that use information beyond that of only endpoint address, generally called 'policy routing'. Yes, they break the notion of transport flows - for almost any definition of transport flow anyway. > The alternative is to be more prescriptive by saying ECMP algorithms > MUST NOT use port numbers, but these algs are already out there. Even if port numbers aren't used, source address can be, so can other fields (IPv6 flowspec, etc.). > Another answer is encryption, to stop these boxes fishing around where > they have no business anyway. You can encrypt anything you don't want the network to see - or possibly forward differentially on. All that does is encourage differential forwarding on SPIs, though. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMvIAE5f5cImnZrsRAjLxAKDPzj75N2kkRDwgA3i4sDG0TeO6VACginFT 3tsUSVDT/oS6UhZyFH1vZMc= =Wwuz -----END PGP SIGNATURE----- From MURSHEDM at uiu.edu Fri Apr 7 15:22:32 2006 From: MURSHEDM at uiu.edu (MURSHEDM) Date: Fri, 7 Apr 2006 17:22:32 -0500 Subject: [e2e] end-to-end delay Message-ID: <5151ECD6856C0F4493E3DD985A64671F034265C7@uiu-ex1.uiu.uiu.edu> Hi all, Could anybody please let me know a suitable code to calculate the end-to-end delay. Suppose source s1 to s5 is sending packets to destination s6 through a bottleneck router. I need to calculate the average delivery delay. Thanks Murshed From mbaugher at cisco.com Fri Apr 7 16:29:04 2006 From: mbaugher at cisco.com (Mark Baugher) Date: Fri, 7 Apr 2006 16:29:04 -0700 Subject: [e2e] end-to-end delay In-Reply-To: <5151ECD6856C0F4493E3DD985A64671F034265C7@uiu-ex1.uiu.uiu.edu> References: <5151ECD6856C0F4493E3DD985A64671F034265C7@uiu-ex1.uiu.uiu.edu> Message-ID: <9D77186D-31D4-45CE-BE28-9BD6B3D3C1DC@cisco.com> Queueing Systems, Leonard Kleinrock, Wiley International On Apr 7, 2006, at 3:22 PM, MURSHEDM wrote: > Hi all, > > Could anybody please let me know a suitable code to calculate the > end-to-end delay. Suppose source s1 to s5 is sending packets to > destination s6 through a bottleneck router. I need to calculate the > average delivery delay. > > Thanks > > Murshed From jason.wangz at gmail.com Mon Apr 10 06:12:47 2006 From: jason.wangz at gmail.com (Jason) Date: Mon, 10 Apr 2006 21:12:47 +0800 Subject: [e2e] 802.11g performance in the mixed enviroment. Message-ID: <68a815150604100612q398c1aaaw533733a22ebe4a00@mail.gmail.com> Hi: Does anyone has experience about the throughput of 802.11g in the following scenario? The scenario is described as below: Let us say a 3D 9meter*9meter*9meter space is divided into 27 3D 3meter*3meter*3meter boxes by concrete. In each 3m*3m*3m box, two 802.11g device transfer data between each other at 54Mbps ad-hoc. There is no data transfer between boxes. I am expecting 16mbps throughput of two devices in one boxes. But some 802.11g chip vendor told me that it is impossible. Any comments? Best regards! Jason Wang From fahad.dogar at gmail.com Mon Apr 10 12:20:47 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Tue, 11 Apr 2006 00:20:47 +0500 Subject: [e2e] use of MAC addresses Message-ID: Hi all, I have a very basic question: in theory, can we NOW use IP addresses in place of MAC addresses. In other words, is there any other use of MAC addresses other than using them for legacy reasons? Thanks in advance, Fahad From faber at ISI.EDU Tue Apr 11 11:59:20 2006 From: faber at ISI.EDU (Ted Faber) Date: Tue, 11 Apr 2006 11:59:20 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: Message-ID: <20060411185920.GB8500@hut.isi.edu> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: > Hi all, > > I have a very basic question: in theory, can we NOW use IP addresses > in place of MAC addresses. Short answer: "yes," with an "if." Long answer: "no," with a "but." IP addresses are (in principle) globally routable. Having a locally routable namespace under your link layer's complete control may be a useful thing. It's rare in the world of computers that removing a layer of indirection makes your system more versatile. There are quite a few tricks that take advantage of the layer of indirection that a link layer address provides to give faster response on a subnet basis, simple redundancy, etc. Of course you could get rid of them (assuming you're willing to live in the smaller, more constained IP address space). An identifier's an identifier. Why would you want to? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060411/82e1c5bf/attachment.bin From mycroft at netbsd.org Tue Apr 11 12:46:01 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Tue, 11 Apr 2006 15:46:01 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: References: Message-ID: <20060411194601.GR29472@multics.mit.edu> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: > I have a very basic question: in theory, can we NOW use IP addresses > in place of MAC addresses. In other words, is there any other use of > MAC addresses other than using them for legacy reasons? I think this depends a little on whether you're talking strictly about the host side, or if you're including networking equipment. MAC addresses are used in spanning tree, for example, which is pretty fundamental to modern Ethernet switching. They're also heavily used in 802.11. Also, there are some advantages to having a globally unique identifier: * The separation is used to detect IP address duplication. * MAC address filtering is used by some whizzy hotel connectivity solutions that don't require users to reconfigure their laptops (even though they may have conflicting IP addresses). * An interface may have many IP addresses (I've considered allowing mask-based addresses in NetBSD; i.e. configure an interface to respond to 128.52.26/24), but only one MAC address, which simplifies the address filtering on the NIC. (This is not so important with P2P links, and you'll notice that many P2P protocols don't have link-level addresses.) So, the short answer is that you *could* eliminate MAC addresses, but it would involve changing several well-established protocols, and you'd potentially lose some functionality. So why bother? From perfgeek at mac.com Tue Apr 11 17:41:47 2006 From: perfgeek at mac.com (rick jones) Date: Tue, 11 Apr 2006 17:41:47 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: Message-ID: On Apr 10, 2006, at 12:20 PM, Fahad Dogar wrote: > I have a very basic question: in theory, can we NOW use IP addresses > in place of MAC addresses. In other words, is there any other use of > MAC addresses other than using them for legacy reasons? I thought that IP (v4) addresses preceded MAC addresses? And it seems odd to present it as a either-or proposition. rick jones Wisdom teeth are impacted, people are affected by the effects of events From touch at ISI.EDU Wed Apr 12 08:50:53 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 08:50:53 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: <20060411185920.GB8500@hut.isi.edu> References: <20060411185920.GB8500@hut.isi.edu> Message-ID: <443D21DD.1010709@isi.edu> Ted Faber wrote: > On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: >> Hi all, >> >> I have a very basic question: in theory, can we NOW use IP addresses >> in place of MAC addresses. > > Short answer: "yes," with an "if." > Long answer: "no," with a "but." > > IP addresses are (in principle) globally routable. ^ easily You can route on MAC addresses too, but being flat that means core routing tables would need to be flooded with everyone's MAC address. Look at the size of your routing table. Then look at the size of your ARP table. If your routing table has anything except default addresses, consider that ARP table size multipled by the size of the number of subnets at each other route entry. Joe Having a locally > routable namespace under your link layer's complete control may be a > useful thing. > > It's rare in the world of computers that removing a layer of indirection > makes your system more versatile. There are quite a few tricks that > take advantage of the layer of indirection that a link layer address > provides to give faster response on a subnet basis, simple redundancy, > etc. > > Of course you could get rid of them (assuming you're willing to live in > the smaller, more constained IP address space). An identifier's an > identifier. > > Why would you want to? > From touch at ISI.EDU Wed Apr 12 10:13:42 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 10:13:42 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> Message-ID: <443D3546.60506@isi.edu> Fahad Dogar wrote: > I understand why IP addresses (which are hierarchical in nature) are > needed but can't seem to appreciate the use of MAC addresses, in > addition to using IP addresses. That's for the level of indirection Ted was noting. > Practically I can understand that they > are being used for legacy purposes and a move towards using IP > addresses as layer 2 addresses would require changes in ethernet > switches etc. Another reason is that ethernet switches are simpler to implement than (IP) routers. A final one is to limit broadcast; right now, broadcast pervades (most) ethernet switches, but is halted by IP routers (even subnet-directed broadcast is defaulted that way). It's not clear how to allow broadcast to go more than one hop and control flooding (with all-1's) or defeat DOS attacks (subnet broadcast). > But I am interested in knowing whether, in theory, we > would be restricted in functionality if we use IP addresses for layer > 2 addressing. Suppose we were to redesign layer 2 technologies now, > can we use IP addresses in place of MAC addresses. With IPv6 I can't > even see any constraint on the address space. IPv6 addresses may seem large at first, but given how they're hierarchically delegated and managed, they're not all that big. Joe > > Thanks, > Fahad > > On 4/12/06, Joe Touch wrote: >> >> Ted Faber wrote: >>> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: >>>> Hi all, >>>> >>>> I have a very basic question: in theory, can we NOW use IP addresses >>>> in place of MAC addresses. >>> Short answer: "yes," with an "if." >>> Long answer: "no," with a "but." >>> >>> IP addresses are (in principle) globally routable. >> ^ >> easily >> >> You can route on MAC addresses too, but being flat that means core >> routing tables would need to be flooded with everyone's MAC address. >> >> Look at the size of your routing table. Then look at the size of your >> ARP table. If your routing table has anything except default addresses, >> consider that ARP table size multipled by the size of the number of >> subnets at each other route entry. >> >> Joe >> >> >> >> >> >> >> >> >> Having a locally >>> routable namespace under your link layer's complete control may be a >>> useful thing. >>> >>> It's rare in the world of computers that removing a layer of indirection >>> makes your system more versatile. There are quite a few tricks that >>> take advantage of the layer of indirection that a link layer address >>> provides to give faster response on a subnet basis, simple redundancy, >>> etc. >>> >>> Of course you could get rid of them (assuming you're willing to live in >>> the smaller, more constained IP address space). An identifier's an >>> identifier. >>> >>> Why would you want to? >>> From detlef.bosau at web.de Wed Apr 12 11:11:16 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Apr 2006 20:11:16 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: References: Message-ID: <443D42C4.3020809@web.de> rick jones wrote: > > On Apr 10, 2006, at 12:20 PM, Fahad Dogar wrote: > >> I have a very basic question: in theory, can we NOW use IP addresses >> in place of MAC addresses. In other words, is there any other use of >> MAC addresses other than using them for legacy reasons? > > > I thought that IP (v4) addresses preceded MAC addresses? And it seems > odd to present it as a either-or proposition. > This is particularly true as some kinds of links don?t even have MAC addresses, think of P-2-P links for example. In other kinds of networks, subnet specific addresses as MAC addresses are required for some technology specific tasks, think of the MAC algorithm in Token Bus networks for example. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From touch at ISI.EDU Wed Apr 12 11:13:39 2006 From: touch at ISI.EDU (Joe Touch) Date: Wed, 12 Apr 2006 11:13:39 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> Message-ID: <443D4353.80004@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fahad Dogar wrote: > On 4/12/06, Joe Touch wrote: >> >> Fahad Dogar wrote: >>> I understand why IP addresses (which are hierarchical in nature) are >>> needed but can't seem to appreciate the use of MAC addresses, in >>> addition to using IP addresses. >> That's for the level of indirection Ted was noting. >> >>> Practically I can understand that they >>> are being used for legacy purposes and a move towards using IP >>> addresses as layer 2 addresses would require changes in ethernet >>> switches etc. >> Another reason is that ethernet switches are simpler to implement than >> (IP) routers. A final one is to limit broadcast; right now, broadcast >> pervades (most) ethernet switches, but is halted by IP routers (even >> subnet-directed broadcast is defaulted that way). It's not clear how to >> allow broadcast to go more than one hop and control flooding (with >> all-1's) or defeat DOS attacks (subnet broadcast). > > By using IP addresses for layer 2 routing, I am not implying the > replacement of ethernet switches with routers. The ethernet protocol > remains the same but the MAC address of every station is the same as > its IP address. So these addresses have different interpretation (and > subsequent forwarding) in a LAN compared to routing at layer 3. So we > can block broadcast at layer 3 (routers) and allow broadcost at layer > 2 (ethernet switches). Again, I am asking purely from the > functionality point of view. It may not be practical to do such a > thing. With Ethernet, unique MACs are burned-in when a device is created. If the L2 address matches the L3 address, that can't happen at device creation time. How would you pick your first MAC address, e.g., to bootstrap the device via DHCP? If the L2 address need not match the L3, then there's no real reason not to call it an IP address, but no reason to do so either. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPUNTE5f5cImnZrsRAmjlAKDOWifR9NBlLQmI4J2+/2TYEU8n4wCfcciN qhzOdOgQZw3ZUC2B+G8v6Es= =Oe2x -----END PGP SIGNATURE----- From faber at ISI.EDU Wed Apr 12 11:28:29 2006 From: faber at ISI.EDU (Ted Faber) Date: Wed, 12 Apr 2006 11:28:29 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> Message-ID: <20060412182829.GF25372@hut.isi.edu> On Wed, Apr 12, 2006 at 10:35:33PM +0500, Fahad Dogar wrote: > By using IP addresses for layer 2 routing, I am not implying the > replacement of ethernet switches with routers. The ethernet protocol > remains the same but the MAC address of every station is the same as > its IP address. So these addresses have different interpretation (and > subsequent forwarding) in a LAN compared to routing at layer 3. So we > can block broadcast at layer 3 (routers) and allow broadcost at layer > 2 (ethernet switches). Again, I am asking purely from the > functionality point of view. It may not be practical to do such a > thing. The process of "removing" MAC addresses is perfectly straightforward. It's the motivation that remains obscure. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060412/f532c96c/attachment.bin From detlef.bosau at web.de Wed Apr 12 12:11:46 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 12 Apr 2006 21:11:46 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <443D42C4.3020809@web.de> References: <443D42C4.3020809@web.de> Message-ID: <443D50F2.1020604@web.de> In addition, I?m not quite sure, whether we have only "pure IP networks" or whether there may exist other protocols, e.g. old IPX installations or SNA protocols. So, this level of indirection may still be useful. -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mycroft at netbsd.org Wed Apr 12 12:56:01 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Wed, 12 Apr 2006 15:56:01 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <443D50F2.1020604@web.de> References: <443D42C4.3020809@web.de> <443D50F2.1020604@web.de> Message-ID: <20060412195601.GB29472@multics.mit.edu> On Wed, Apr 12, 2006 at 09:11:46PM +0200, Detlef Bosau wrote: > > In addition, I?m not quite sure, whether we have only "pure IP networks" > or whether there may exist other protocols, e.g. old IPX installations > or SNA protocols. I don't think you're going to get much sympathy for IPX or SNA here. Many of us would like to pretend they never existed. :-) From bmanning at vacation.karoshi.com Wed Apr 12 14:18:33 2006 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Wed, 12 Apr 2006 21:18:33 +0000 Subject: [e2e] use of MAC addresses In-Reply-To: <20060412195601.GB29472@multics.mit.edu> References: <443D42C4.3020809@web.de> <443D50F2.1020604@web.de> <20060412195601.GB29472@multics.mit.edu> Message-ID: <20060412211833.GA18178@vacation.karoshi.com.> On Wed, Apr 12, 2006 at 03:56:01PM -0400, Charles M. Hannum wrote: > On Wed, Apr 12, 2006 at 09:11:46PM +0200, Detlef Bosau wrote: > > > > In addition, I?m not quite sure, whether we have only "pure IP networks" > > or whether there may exist other protocols, e.g. old IPX installations > > or SNA protocols. > > I don't think you're going to get much sympathy for IPX or SNA here. > Many of us would like to pretend they never existed. :-) ok then... DECnet PhaseV. --bill From fahad.dogar at gmail.com Wed Apr 12 10:02:33 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Wed, 12 Apr 2006 22:02:33 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <443D21DD.1010709@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> Message-ID: I understand why IP addresses (which are hierarchical in nature) are needed but can't seem to appreciate the use of MAC addresses, in addition to using IP addresses. Practically I can understand that they are being used for legacy purposes and a move towards using IP addresses as layer 2 addresses would require changes in ethernet switches etc. But I am interested in knowing whether, in theory, we would be restricted in functionality if we use IP addresses for layer 2 addressing. Suppose we were to redesign layer 2 technologies now, can we use IP addresses in place of MAC addresses. With IPv6 I can't even see any constraint on the address space. Thanks, Fahad On 4/12/06, Joe Touch wrote: > > > Ted Faber wrote: > > On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: > >> Hi all, > >> > >> I have a very basic question: in theory, can we NOW use IP addresses > >> in place of MAC addresses. > > > > Short answer: "yes," with an "if." > > Long answer: "no," with a "but." > > > > IP addresses are (in principle) globally routable. > ^ > easily > > You can route on MAC addresses too, but being flat that means core > routing tables would need to be flooded with everyone's MAC address. > > Look at the size of your routing table. Then look at the size of your > ARP table. If your routing table has anything except default addresses, > consider that ARP table size multipled by the size of the number of > subnets at each other route entry. > > Joe > > > > > > > > > Having a locally > > routable namespace under your link layer's complete control may be a > > useful thing. > > > > It's rare in the world of computers that removing a layer of indirection > > makes your system more versatile. There are quite a few tricks that > > take advantage of the layer of indirection that a link layer address > > provides to give faster response on a subnet basis, simple redundancy, > > etc. > > > > Of course you could get rid of them (assuming you're willing to live in > > the smaller, more constained IP address space). An identifier's an > > identifier. > > > > Why would you want to? > > > From fahad.dogar at gmail.com Wed Apr 12 10:35:33 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Wed, 12 Apr 2006 22:35:33 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <443D3546.60506@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> Message-ID: On 4/12/06, Joe Touch wrote: > > > Fahad Dogar wrote: > > I understand why IP addresses (which are hierarchical in nature) are > > needed but can't seem to appreciate the use of MAC addresses, in > > addition to using IP addresses. > > That's for the level of indirection Ted was noting. > > > Practically I can understand that they > > are being used for legacy purposes and a move towards using IP > > addresses as layer 2 addresses would require changes in ethernet > > switches etc. > > Another reason is that ethernet switches are simpler to implement than > (IP) routers. A final one is to limit broadcast; right now, broadcast > pervades (most) ethernet switches, but is halted by IP routers (even > subnet-directed broadcast is defaulted that way). It's not clear how to > allow broadcast to go more than one hop and control flooding (with > all-1's) or defeat DOS attacks (subnet broadcast). By using IP addresses for layer 2 routing, I am not implying the replacement of ethernet switches with routers. The ethernet protocol remains the same but the MAC address of every station is the same as its IP address. So these addresses have different interpretation (and subsequent forwarding) in a LAN compared to routing at layer 3. So we can block broadcast at layer 3 (routers) and allow broadcost at layer 2 (ethernet switches). Again, I am asking purely from the functionality point of view. It may not be practical to do such a thing. > > But I am interested in knowing whether, in theory, we > > would be restricted in functionality if we use IP addresses for layer > > 2 addressing. Suppose we were to redesign layer 2 technologies now, > > can we use IP addresses in place of MAC addresses. With IPv6 I can't > > even see any constraint on the address space. > > IPv6 addresses may seem large at first, but given how they're > hierarchically delegated and managed, they're not all that big. > > Joe > > > > > Thanks, > > Fahad > > > > On 4/12/06, Joe Touch wrote: > >> > >> Ted Faber wrote: > >>> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: > >>>> Hi all, > >>>> > >>>> I have a very basic question: in theory, can we NOW use IP addresses > >>>> in place of MAC addresses. > >>> Short answer: "yes," with an "if." > >>> Long answer: "no," with a "but." > >>> > >>> IP addresses are (in principle) globally routable. > >> ^ > >> easily > >> > >> You can route on MAC addresses too, but being flat that means core > >> routing tables would need to be flooded with everyone's MAC address. > >> > >> Look at the size of your routing table. Then look at the size of your > >> ARP table. If your routing table has anything except default addresses, > >> consider that ARP table size multipled by the size of the number of > >> subnets at each other route entry. > >> > >> Joe > >> > >> > >> > >> > >> > >> > >> > >> > >> Having a locally > >>> routable namespace under your link layer's complete control may be a > >>> useful thing. > >>> > >>> It's rare in the world of computers that removing a layer of indirection > >>> makes your system more versatile. There are quite a few tricks that > >>> take advantage of the layer of indirection that a link layer address > >>> provides to give faster response on a subnet basis, simple redundancy, > >>> etc. > >>> > >>> Of course you could get rid of them (assuming you're willing to live in > >>> the smaller, more constained IP address space). An identifier's an > >>> identifier. > >>> > >>> Why would you want to? > >>> > From touch at ISI.EDU Thu Apr 13 09:05:52 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 09:05:52 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> Message-ID: <443E76E0.1040600@isi.edu> Fahad Dogar wrote: > On 4/12/06, Joe Touch wrote: >> >> Fahad Dogar wrote: >>> I understand why IP addresses (which are hierarchical in nature) are >>> needed but can't seem to appreciate the use of MAC addresses, in >>> addition to using IP addresses. >> That's for the level of indirection Ted was noting. >> >>> Practically I can understand that they >>> are being used for legacy purposes and a move towards using IP >>> addresses as layer 2 addresses would require changes in ethernet >>> switches etc. >> Another reason is that ethernet switches are simpler to implement than >> (IP) routers. A final one is to limit broadcast; right now, broadcast >> pervades (most) ethernet switches, but is halted by IP routers (even >> subnet-directed broadcast is defaulted that way). It's not clear how to >> allow broadcast to go more than one hop and control flooding (with >> all-1's) or defeat DOS attacks (subnet broadcast). > > By using IP addresses for layer 2 routing, I am not implying the > replacement of ethernet switches with routers. The ethernet protocol > remains the same but the MAC address of every station is the same as > its IP address. Please explain how ARP and DHCP would then work. Or router discovery and host address assignment in IPv6. The ethernet address is required to determine the IP address in both cases. Use of the IP address as a MAC address: - creates a circularity in the above protocols, i.e., they no longer work - enables hosts to collide on MAC addresses; spanning tree algorithms don't react well to having the same address attached at multiple points in the tree - defeats the use of different MAC addresses for the same IP address, the so-called "weak host" model (see RFC1122) Joe So these addresses have different interpretation (and > subsequent forwarding) in a LAN compared to routing at layer 3. So we > can block broadcast at layer 3 (routers) and allow broadcost at layer > 2 (ethernet switches). Again, I am asking purely from the > functionality point of view. It may not be practical to do such a > thing. > >>> But I am interested in knowing whether, in theory, we >>> would be restricted in functionality if we use IP addresses for layer >>> 2 addressing. Suppose we were to redesign layer 2 technologies now, >>> can we use IP addresses in place of MAC addresses. With IPv6 I can't >>> even see any constraint on the address space. >> IPv6 addresses may seem large at first, but given how they're >> hierarchically delegated and managed, they're not all that big. >> >> Joe >> >>> Thanks, >>> Fahad >>> >>> On 4/12/06, Joe Touch wrote: >>>> Ted Faber wrote: >>>>> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: >>>>>> Hi all, >>>>>> >>>>>> I have a very basic question: in theory, can we NOW use IP addresses >>>>>> in place of MAC addresses. >>>>> Short answer: "yes," with an "if." >>>>> Long answer: "no," with a "but." >>>>> >>>>> IP addresses are (in principle) globally routable. >>>> ^ >>>> easily >>>> >>>> You can route on MAC addresses too, but being flat that means core >>>> routing tables would need to be flooded with everyone's MAC address. >>>> >>>> Look at the size of your routing table. Then look at the size of your >>>> ARP table. If your routing table has anything except default addresses, >>>> consider that ARP table size multipled by the size of the number of >>>> subnets at each other route entry. >>>> >>>> Joe >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Having a locally >>>>> routable namespace under your link layer's complete control may be a >>>>> useful thing. >>>>> >>>>> It's rare in the world of computers that removing a layer of indirection >>>>> makes your system more versatile. There are quite a few tricks that >>>>> take advantage of the layer of indirection that a link layer address >>>>> provides to give faster response on a subnet basis, simple redundancy, >>>>> etc. >>>>> >>>>> Of course you could get rid of them (assuming you're willing to live in >>>>> the smaller, more constained IP address space). An identifier's an >>>>> identifier. >>>>> >>>>> Why would you want to? >>>>> From touch at ISI.EDU Thu Apr 13 09:19:40 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 09:19:40 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: <443E76E0.1040600@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> Message-ID: <443E7A1C.2040606@isi.edu> Joe Touch wrote: > > Fahad Dogar wrote: >> On 4/12/06, Joe Touch wrote: >>> Fahad Dogar wrote: >>>> I understand why IP addresses (which are hierarchical in nature) are >>>> needed but can't seem to appreciate the use of MAC addresses, in >>>> addition to using IP addresses. >>> That's for the level of indirection Ted was noting. >>> >>>> Practically I can understand that they >>>> are being used for legacy purposes and a move towards using IP >>>> addresses as layer 2 addresses would require changes in ethernet >>>> switches etc. >>> Another reason is that ethernet switches are simpler to implement than >>> (IP) routers. A final one is to limit broadcast; right now, broadcast >>> pervades (most) ethernet switches, but is halted by IP routers (even >>> subnet-directed broadcast is defaulted that way). It's not clear how to >>> allow broadcast to go more than one hop and control flooding (with >>> all-1's) or defeat DOS attacks (subnet broadcast). >> By using IP addresses for layer 2 routing, I am not implying the >> replacement of ethernet switches with routers. The ethernet protocol >> remains the same but the MAC address of every station is the same as >> its IP address. > > Please explain how ARP and DHCP would then work. Or router discovery and > host address assignment in IPv6. > > The ethernet address is required to determine the IP address in both > cases. Use of the IP address as a MAC address: > - creates a circularity in the above protocols, i.e., > they no longer work As others have pointed out, they're not needed on point-to-point links. But assuming a subnet - i.e., a shared link or the equivalent - they are used heavily in the Internet. See RFC 3819. > > - enables hosts to collide on MAC addresses; spanning > tree algorithms don't react well to having the same > address attached at multiple points in the tree > > - defeats the use of different MAC addresses for the same > IP address, the so-called "weak host" model (see RFC1122) > > Joe > > > > So these addresses have different interpretation (and >> subsequent forwarding) in a LAN compared to routing at layer 3. So we >> can block broadcast at layer 3 (routers) and allow broadcost at layer >> 2 (ethernet switches). Again, I am asking purely from the >> functionality point of view. It may not be practical to do such a >> thing. >> >>>> But I am interested in knowing whether, in theory, we >>>> would be restricted in functionality if we use IP addresses for layer >>>> 2 addressing. Suppose we were to redesign layer 2 technologies now, >>>> can we use IP addresses in place of MAC addresses. With IPv6 I can't >>>> even see any constraint on the address space. >>> IPv6 addresses may seem large at first, but given how they're >>> hierarchically delegated and managed, they're not all that big. >>> >>> Joe >>> >>>> Thanks, >>>> Fahad >>>> >>>> On 4/12/06, Joe Touch wrote: >>>>> Ted Faber wrote: >>>>>> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I have a very basic question: in theory, can we NOW use IP addresses >>>>>>> in place of MAC addresses. >>>>>> Short answer: "yes," with an "if." >>>>>> Long answer: "no," with a "but." >>>>>> >>>>>> IP addresses are (in principle) globally routable. >>>>> ^ >>>>> easily >>>>> >>>>> You can route on MAC addresses too, but being flat that means core >>>>> routing tables would need to be flooded with everyone's MAC address. >>>>> >>>>> Look at the size of your routing table. Then look at the size of your >>>>> ARP table. If your routing table has anything except default addresses, >>>>> consider that ARP table size multipled by the size of the number of >>>>> subnets at each other route entry. >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Having a locally >>>>>> routable namespace under your link layer's complete control may be a >>>>>> useful thing. >>>>>> >>>>>> It's rare in the world of computers that removing a layer of indirection >>>>>> makes your system more versatile. There are quite a few tricks that >>>>>> take advantage of the layer of indirection that a link layer address >>>>>> provides to give faster response on a subnet basis, simple redundancy, >>>>>> etc. >>>>>> >>>>>> Of course you could get rid of them (assuming you're willing to live in >>>>>> the smaller, more constained IP address space). An identifier's an >>>>>> identifier. >>>>>> >>>>>> Why would you want to? >>>>>> From craig at aland.bbn.com Thu Apr 13 10:06:48 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 13 Apr 2006 13:06:48 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: Your message of "Wed, 12 Apr 2006 22:35:33 +0500." Message-ID: <20060413170648.8BFAE67@aland.bbn.com> In message , "Faha d Dogar" writes: >By using IP addresses for layer 2 routing, I am not implying the >replacement of ethernet switches with routers. The ethernet protocol >remains the same but the MAC address of every station is the same as >its IP address. So these addresses have different interpretation (and >subsequent forwarding) in a LAN compared to routing at layer 3. So we >can block broadcast at layer 3 (routers) and allow broadcost at layer >2 (ethernet switches). Again, I am asking purely from the >functionality point of view. It may not be practical to do such a >thing. I think you've just walked into the IP address = interface issues. That is, I can have a system with two MAC addresses and one IP address (although it is painful). In your scheme, I can't do that unless I'm sure the two MAC interfaces are on disjoint (from the MAC-level) networks. More broadly, you're raising a fun point but the details make my head hurt. For instance, if I don't have a MAC address but have an IP address, does the IP address stay with me when I move? E.g., do I show up in Starbucks and join the 802.11 wireless using my "assigned" IP address? If so, we've destroyed IP routing hierarchy (or we're using one of the myriad of mobile IP protocols that everyone seems to find painful). If I get a new IP address from the 802.11 wireless network, how does it give me the new IP address if I don't have any addresses??? Craig From touch at ISI.EDU Thu Apr 13 10:39:04 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 10:39:04 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> Message-ID: <443E8CB8.8090601@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fahad Dogar wrote: > On 4/13/06, Joe Touch wrote: ... >> Please explain how ARP and DHCP would then work. Or router discovery and >> host address assignment in IPv6. > > I agree --- we would require changes to DHCP and probably would not > require ARP at all. A very naivete alternative to DHCP could be: new > node generating a random number which acts as its temporary address > and is used by the DHCP server to assign the IP address. With flash > memory, writing layer 2 addresses in this manner shouldn't be a > problem as well. The problem with 'try and fail' is that these approaches may kill the link layer, e.g., spanning tree. We already use them at L3 (see RFC 3330), but resolution of conflicts relies on unique L2s. You still, however, have not explained why unique MAC addresses isn't sufficient. They're simple, and already widely in use. And they're cheap - - a great description of how cheap: - use the serial number of a US dollar bill - burn the bill I.e., the upper bound cost is exactly 1 USD. > IMHO, we have to change these protocols because they have been > designed keeping in view the presence of MAC addresses and how they > work. If we were to redesign Internet and networking technologies > (clean slate approach), do we need to have a different MAC address. > Shouldn't IP address be sufficient? It is like assigning a globally > unique name to every person and then asking him to maintain an > additional name for 'local' identification. This is one of the biggest problems with the phrase "clean slate". It does NOT mean that you MUST start with a blank page and throw out everything FIRST. It means you _can_ redesign any part you NEED to redesign. As Ted pointed out, you haven't explained the problem with unique MAC addresses that needs to be solved yet. Once you have that, then you can erase the slate. That said, blank slates aren't how we build networks. We start with ideas, not just empty space. Once you show the need to erase, you have to have a workable solution as an alternative. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPoy4E5f5cImnZrsRAr52AJ4igDG/mfv2bvl4mjRNpx0355bBoQCgkHNH qgvWsY5EBI94M48YComndQs= =Qs80 -----END PGP SIGNATURE----- From craig at aland.bbn.com Thu Apr 13 11:09:23 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 13 Apr 2006 14:09:23 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: Your message of "Thu, 13 Apr 2006 18:57:13 BST." <20060413175713.94669.qmail@web25412.mail.ukl.yahoo.com> Message-ID: <20060413180923.8ED2867@aland.bbn.com> This is replacing one MAC identifier with another one. You're recreating the construct (with some modest semantic variations). Craig In message <20060413175713.94669.qmail at web25412.mail.ukl.yahoo.com>, Puddinhead Wilson writes: >The local attachment identifer when I am on a >wireless, could be anything, including a name, and >that could be "my identity, my cell number, my postal >address" > >Another algorithm could be >"my device sends my name/mobile number/Enum number to >the base station or a freq designated for something >like DHCP, the base station sends out sends out a >response like : Number so and so:use this freq and >this code" for yourself. > >I somehow feel making the "end point device identifier >unique/my cell number/my name" is much easier than >using a locally significant MAC. Finally people will >want to talk to "me" on a number which is globally >routable and if it identifies me on the network, might >as well make it "me" for all transactions, to the BTS >or to anyone else, not to my dynamic IP or my local >MAC. > >of course IP would do the same thing. The IP would be >local, but I wonder what would be "global" for me, an >ENUM entry pointing back to my IP? or a CNAME record >pointing back to my address? >wilson.thatstreet.thatcity.country is now a >CNAME localuser1234.thisbts.thiscity.thiscountry > >for fixed wireline, i guess the port identifer could >be the postal address itself. > >Comments? (to afake id) ;) > > > > > >___________________________________________________________ >Does your mail provider give you FREE antivirus protection? >Get Yahoo! Mail http://uk.mail.yahoo.com From mycroft at netbsd.org Thu Apr 13 11:59:56 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Thu, 13 Apr 2006 14:59:56 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <443E8CB8.8090601@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> Message-ID: <20060413185956.GF29472@multics.mit.edu> On Thu, Apr 13, 2006 at 10:39:04AM -0700, Joe Touch wrote: > Fahad Dogar wrote: > > IMHO, we have to change these protocols because they have been > > designed keeping in view the presence of MAC addresses and how they > > work. If we were to redesign Internet and networking technologies > > (clean slate approach), do we need to have a different MAC address. > > Shouldn't IP address be sufficient? It is like assigning a globally > > unique name to every person and then asking him to maintain an > > additional name for 'local' identification. I'm still trying to figure out where this notion of IP addresses being "globally unique" came from. IP addresses are *not* globally unique. Even if we ignore NAT, they are still ephemeral due to DHCP, ND, etc. The big selling point of MAC addresses is to make it easy to implement determistic algorithms for discovering and maintaining IP address mappings. (Spanning tree came later, but is also important.) If you ditch MAC addresses, then you just have to create some other unique ID for this -- and if you go with something like the person's name, as has been suggested, then it's in direct control of the user, and that will only make things worse. MAC addresses as currently implemented are simple and sane. They are not a scourge that needs to be destroyed. From faber at ISI.EDU Thu Apr 13 12:25:01 2006 From: faber at ISI.EDU (Ted Faber) Date: Thu, 13 Apr 2006 12:25:01 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: <443E76E0.1040600@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> Message-ID: <20060413192501.GC47522@hut.isi.edu> On Thu, Apr 13, 2006 at 09:05:52AM -0700, Joe Touch wrote: > [replacing MAC addresses with 32-bit MAC addresses that directly > correspond to IP addresses deleted] > > Please explain how ARP and DHCP would then work. Or router discovery and > host address assignment in IPv6. I'm not sure this is worthy of a Socratic dialog, Joe. I'm sure you can come up with 3 designs that would work for dynamic address allocation in such a system, so you know a person could do it. If you're trying to focus this fellow's discussion, I'm not convinced that the point of the discussion is in the details of a dynamic address allocation implementation. "Why make the MAC/IP address replacement?" is the question. So far, I haven't seen anything that it simplifies: you still have to do all the MAC functions, you just do them on this 32- (or 128-) bit identifier that you have to coordinate with the network layer besides. I also don't see any new function that's enabled by it, and without a layer of indirection that the link layer provides, many old functions are more cumbersome to implement. I do think that one could eliminate all link layer identifiers. And if it's impossible, I really don't care yet. If I could do it, why would I want to? We're spending a lot of time talking about an idea that strikes me as about as attractive as do-it-yourself dentistry. That activity may also be *possible*, but I'd want to see an awfully big upside before I'd try it. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060413/4d34c747/attachment.bin From fahad.dogar at gmail.com Thu Apr 13 10:31:15 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Thu, 13 Apr 2006 22:31:15 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <443E76E0.1040600@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> Message-ID: On 4/13/06, Joe Touch wrote: > > > Fahad Dogar wrote: > > On 4/12/06, Joe Touch wrote: > >> > >> Fahad Dogar wrote: > >>> I understand why IP addresses (which are hierarchical in nature) are > >>> needed but can't seem to appreciate the use of MAC addresses, in > >>> addition to using IP addresses. > >> That's for the level of indirection Ted was noting. > >> > >>> Practically I can understand that they > >>> are being used for legacy purposes and a move towards using IP > >>> addresses as layer 2 addresses would require changes in ethernet > >>> switches etc. > >> Another reason is that ethernet switches are simpler to implement than > >> (IP) routers. A final one is to limit broadcast; right now, broadcast > >> pervades (most) ethernet switches, but is halted by IP routers (even > >> subnet-directed broadcast is defaulted that way). It's not clear how to > >> allow broadcast to go more than one hop and control flooding (with > >> all-1's) or defeat DOS attacks (subnet broadcast). > > > > By using IP addresses for layer 2 routing, I am not implying the > > replacement of ethernet switches with routers. The ethernet protocol > > remains the same but the MAC address of every station is the same as > > its IP address. > > Please explain how ARP and DHCP would then work. Or router discovery and > host address assignment in IPv6. I agree --- we would require changes to DHCP and probably would not require ARP at all. A very naivete alternative to DHCP could be: new node generating a random number which acts as its temporary address and is used by the DHCP server to assign the IP address. With flash memory, writing layer 2 addresses in this manner shouldn't be a problem as well. IMHO, we have to change these protocols because they have been designed keeping in view the presence of MAC addresses and how they work. If we were to redesign Internet and networking technologies (clean slate approach), do we need to have a different MAC address. Shouldn't IP address be sufficient? It is like assigning a globally unique name to every person and then asking him to maintain an additional name for 'local' identification. Fahad > > The ethernet address is required to determine the IP address in both > cases. Use of the IP address as a MAC address: > - creates a circularity in the above protocols, i.e., > they no longer work > > - enables hosts to collide on MAC addresses; spanning > tree algorithms don't react well to having the same > address attached at multiple points in the tree > > - defeats the use of different MAC addresses for the same > IP address, the so-called "weak host" model (see RFC1122) > > Joe > > > > So these addresses have different interpretation (and > > subsequent forwarding) in a LAN compared to routing at layer 3. So we > > can block broadcast at layer 3 (routers) and allow broadcost at layer > > 2 (ethernet switches). Again, I am asking purely from the > > functionality point of view. It may not be practical to do such a > > thing. > > > >>> But I am interested in knowing whether, in theory, we > >>> would be restricted in functionality if we use IP addresses for layer > >>> 2 addressing. Suppose we were to redesign layer 2 technologies now, > >>> can we use IP addresses in place of MAC addresses. With IPv6 I can't > >>> even see any constraint on the address space. > >> IPv6 addresses may seem large at first, but given how they're > >> hierarchically delegated and managed, they're not all that big. > >> > >> Joe > >> > >>> Thanks, > >>> Fahad > >>> > >>> On 4/12/06, Joe Touch wrote: > >>>> Ted Faber wrote: > >>>>> On Tue, Apr 11, 2006 at 12:20:47AM +0500, Fahad Dogar wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I have a very basic question: in theory, can we NOW use IP addresses > >>>>>> in place of MAC addresses. > >>>>> Short answer: "yes," with an "if." > >>>>> Long answer: "no," with a "but." > >>>>> > >>>>> IP addresses are (in principle) globally routable. > >>>> ^ > >>>> easily > >>>> > >>>> You can route on MAC addresses too, but being flat that means core > >>>> routing tables would need to be flooded with everyone's MAC address. > >>>> > >>>> Look at the size of your routing table. Then look at the size of your > >>>> ARP table. If your routing table has anything except default addresses, > >>>> consider that ARP table size multipled by the size of the number of > >>>> subnets at each other route entry. > >>>> > >>>> Joe > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Having a locally > >>>>> routable namespace under your link layer's complete control may be a > >>>>> useful thing. > >>>>> > >>>>> It's rare in the world of computers that removing a layer of indirection > >>>>> makes your system more versatile. There are quite a few tricks that > >>>>> take advantage of the layer of indirection that a link layer address > >>>>> provides to give faster response on a subnet basis, simple redundancy, > >>>>> etc. > >>>>> > >>>>> Of course you could get rid of them (assuming you're willing to live in > >>>>> the smaller, more constained IP address space). An identifier's an > >>>>> identifier. > >>>>> > >>>>> Why would you want to? > >>>>> > From puddinghead_wilson007 at yahoo.co.uk Thu Apr 13 10:57:13 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Thu, 13 Apr 2006 18:57:13 +0100 (BST) Subject: [e2e] use of MAC addresses In-Reply-To: <20060413170648.8BFAE67@aland.bbn.com> Message-ID: <20060413175713.94669.qmail@web25412.mail.ukl.yahoo.com> The local attachment identifer when I am on a wireless, could be anything, including a name, and that could be "my identity, my cell number, my postal address" Another algorithm could be "my device sends my name/mobile number/Enum number to the base station or a freq designated for something like DHCP, the base station sends out sends out a response like : Number so and so:use this freq and this code" for yourself. I somehow feel making the "end point device identifier unique/my cell number/my name" is much easier than using a locally significant MAC. Finally people will want to talk to "me" on a number which is globally routable and if it identifies me on the network, might as well make it "me" for all transactions, to the BTS or to anyone else, not to my dynamic IP or my local MAC. of course IP would do the same thing. The IP would be local, but I wonder what would be "global" for me, an ENUM entry pointing back to my IP? or a CNAME record pointing back to my address? wilson.thatstreet.thatcity.country is now a CNAME localuser1234.thisbts.thiscity.thiscountry for fixed wireline, i guess the port identifer could be the postal address itself. Comments? (to afake id) ;) ___________________________________________________________ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com From puddinghead_wilson007 at yahoo.co.uk Thu Apr 13 11:22:21 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Thu, 13 Apr 2006 19:22:21 +0100 (BST) Subject: [e2e] Fwd: Re: use of MAC addresses Message-ID: <20060413182221.38485.qmail@web25405.mail.ukl.yahoo.com> Note: forwarded message attached. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com -------------- next part -------------- An embedded message was scrubbed... From: Puddinhead Wilson Subject: Re: [e2e] use of MAC addresses Date: Thu, 13 Apr 2006 19:12:37 +0100 (BST) Size: 2864 Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060413/9c23046e/attachment.mht From puddinghead_wilson007 at yahoo.co.uk Thu Apr 13 12:02:23 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Thu, 13 Apr 2006 20:02:23 +0100 (BST) Subject: [e2e] use of MAC addresses In-Reply-To: <443E8CB8.8090601@isi.edu> Message-ID: <20060413190223.76954.qmail@web25409.mail.ukl.yahoo.com> I think what is confusing him is that "the mac address is not what identifies the end device". If it did, perhaps the confusion would not be there. What we tend to do is "stack identifiers" or tend to "keep them local". We have MAC, then IP then again MAC. Now if MAC was global we could all "talk on MAC plane". I would dial the MAC. though flow switching is prone to hash collisions.. as far as I can make out. ideally it should be: i transact from MAC A to MAC B, my "demux is local" but my connection is global. The problem i think comes when one tries to couple the "end point identifier" with the "switching identifier". There is a whole lot on "connectionless and connection oriented but I think TCP" is connection oriented too while IP isnt so am not clear on the semantics --- Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Fahad Dogar wrote: > > On 4/13/06, Joe Touch wrote: > ... > >> Please explain how ARP and DHCP would then work. > Or router discovery and > >> host address assignment in IPv6. > > > > I agree --- we would require changes to DHCP and > probably would not > > require ARP at all. A very naivete alternative to > DHCP could be: new > > node generating a random number which acts as its > temporary address > > and is used by the DHCP server to assign the IP > address. With flash > > memory, writing layer 2 addresses in this manner > shouldn't be a > > problem as well. > > The problem with 'try and fail' is that these > approaches may kill the > link layer, e.g., spanning tree. We already use them > at L3 (see RFC > 3330), but resolution of conflicts relies on unique > L2s. > > You still, however, have not explained why unique > MAC addresses isn't > sufficient. They're simple, and already widely in > use. And they're cheap > - - a great description of how cheap: > > - use the serial number of a US dollar bill > - burn the bill > > I.e., the upper bound cost is exactly 1 USD. > > > IMHO, we have to change these protocols because > they have been > > designed keeping in view the presence of MAC > addresses and how they > > work. If we were to redesign Internet and > networking technologies > > (clean slate approach), do we need to have a > different MAC address. > > Shouldn't IP address be sufficient? It is like > assigning a globally > > unique name to every person and then asking him to > maintain an > > additional name for 'local' identification. > > This is one of the biggest problems with the phrase > "clean slate". It > does NOT mean that you MUST start with a blank page > and throw out > everything FIRST. It means you _can_ redesign any > part you NEED to redesign. > > As Ted pointed out, you haven't explained the > problem with unique MAC > addresses that needs to be solved yet. Once you have > that, then you can > erase the slate. > > That said, blank slates aren't how we build > networks. We start with > ideas, not just empty space. Once you show the need > to erase, you have > to have a workable solution as an alternative. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > iD8DBQFEPoy4E5f5cImnZrsRAr52AJ4igDG/mfv2bvl4mjRNpx0355bBoQCgkHNH > qgvWsY5EBI94M48YComndQs= > =Qs80 > -----END PGP SIGNATURE----- > Send instant messages to your online friends http://uk.messenger.yahoo.com From touch at ISI.EDU Thu Apr 13 14:29:07 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 14:29:07 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: <20060413185956.GF29472@multics.mit.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> <20060413185956.GF29472@multics.mit.edu> Message-ID: <443EC2A3.3000508@isi.edu> Charles M. Hannum wrote: ... > I'm still trying to figure out where this notion of IP addresses being > "globally unique" came from. IP addresses are *not* globally unique. RFC1122, pg. 18. There are exceptions where a number of interfaces are working together, whether on a single host or multiples, as a single virtual device, but that's a very subtle issue by comparison. > Even if we ignore NAT, they are still ephemeral due to DHCP, ND, etc. Ephemeral doesn't mean that at a given time only one host (or virtual host) should be using a single IP address. > The big selling point of MAC addresses is to make it easy to implement > determistic algorithms for discovering and maintaining IP address > mappings. That's only relevant for shared media. Point-to-point media don't need that capability. Joe From touch at ISI.EDU Thu Apr 13 14:50:52 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 14:50:52 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> Message-ID: <443EC7BC.2080709@isi.edu> Fahad Dogar wrote: > On 4/13/06, Joe Touch wrote: ... > IMHO, we have to change these protocols because they have been > designed keeping in view the presence of MAC addresses and how they > work. You need to change the protocols only if they don't do something you need to do. What is it you need to do? > If we were to redesign Internet and networking technologies > (clean slate approach), do we need to have a different MAC address. > Shouldn't IP address be sufficient? It is like assigning a globally > unique name to every person and then asking him to maintain an > additional name for 'local' identification. The locally unique address is how you know you're different from someone else before you get (or pick a random, possibly colliding) IP address. The reason for that need is the MAC protocol - bridging, backoff, spanning tree, etc. If you design a multi-access subnet that doesn't need unique a-priori addresses, then you might be able to reuse IP addresses. I.e., this needs to be motivated at the MAC layer. Joe From mycroft at netbsd.org Thu Apr 13 15:06:03 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Thu, 13 Apr 2006 18:06:03 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <443EC2A3.3000508@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> <20060413185956.GF29472@multics.mit.edu> <443EC2A3.3000508@isi.edu> Message-ID: <20060413220603.GM29472@multics.mit.edu> On Thu, Apr 13, 2006 at 02:29:07PM -0700, Joe Touch wrote: > > The big selling point of MAC addresses is to make it easy to implement > > determistic algorithms for discovering and maintaining IP address > > mappings. > > That's only relevant for shared media. Point-to-point media don't need > that capability. Great, so little's ditch traditional shared Ethernet, Ethernet switching and 802.11 -- which are all forms of "shared media." Let's build a New Internet with only point-to-point links! Wait, whose fantasy world is this? From touch at ISI.EDU Thu Apr 13 15:45:23 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 13 Apr 2006 15:45:23 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: <20060413220603.GM29472@multics.mit.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> <20060413185956.GF29472@multics.mit.edu> <443EC2A3.3000508@isi.edu> <20060413220603.GM29472@multics.mit.edu> Message-ID: <443ED483.1080805@isi.edu> Charles M. Hannum wrote: > On Thu, Apr 13, 2006 at 02:29:07PM -0700, Joe Touch wrote: >>> The big selling point of MAC addresses is to make it easy to implement >>> determistic algorithms for discovering and maintaining IP address >>> mappings. >> That's only relevant for shared media. Point-to-point media don't need >> that capability. > > Great, so little's ditch traditional shared Ethernet, Ethernet switching > and 802.11 -- which are all forms of "shared media." Let's build a New > Internet with only point-to-point links! > > Wait, whose fantasy world is this? The "" in your response is important; many "shared media" these days aren't. That doesn't mean the MAC address isn't still useful, but it does mean it may not be necessary. Joe From detlef.bosau at web.de Thu Apr 13 16:11:15 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Apr 2006 01:11:15 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <20060413175713.94669.qmail@web25412.mail.ukl.yahoo.com> References: <20060413175713.94669.qmail@web25412.mail.ukl.yahoo.com> Message-ID: <443EDA93.7010600@web.de> Puddinhead Wilson wrote: > The local attachment identifer when I am on a > wireless, could be anything, including a name, and > that could be "my identity, my cell number, my postal > address" > Of course. And it even may be the burned in hardware address, every wireless unit is shipped with. > Another algorithm could be > "my device sends my name/mobile number/Enum number to > the base station or a freq designated for something > like DHCP, the base station sends out sends out a > response like : Number so and so:use this freq and > this code" for yourself. Hm. Sounds like: Why do we use something which a) exists, b) works and c) is amazingly simple? This is boring. Why shouldn?t we invent something new that a) does not yet exist, b) perhaps will never work and c) is hopefully terrible complicated? BTW: I found Craigs argument one of the most compelling ones. Particularly in mobile networks, you will distinguish between "micromobility" and "macromobility". Much of actual mobility issues will be covered by "micromobilty", i.e. are handled by the mobile network?s internal mechanisms and hidden from IP. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From garmitage at swin.edu.au Thu Apr 13 16:13:34 2006 From: garmitage at swin.edu.au (grenville armitage) Date: Fri, 14 Apr 2006 09:13:34 +1000 Subject: [e2e] use of MAC addresses In-Reply-To: <20060413185956.GF29472@multics.mit.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> <20060413185956.GF29472@multics.mit.edu> Message-ID: <443EDB1E.9000403@swin.edu.au> Charles M. Hannum wrote: [..] > I'm still trying to figure out where this notion of IP addresses being > "globally unique" came from. IP addresses are *not* globally unique. > Even if we ignore NAT, they are still ephemeral due to DHCP, ND, etc. Being ephemeral, and being unique while assigned, seem orthogonal to me. cheers, gja From detlef.bosau at web.de Thu Apr 13 16:20:12 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Apr 2006 01:20:12 +0200 Subject: [e2e] Fwd: Re: use of MAC addresses In-Reply-To: <20060413182221.38485.qmail@web25405.mail.ukl.yahoo.com> References: <20060413182221.38485.qmail@web25405.mail.ukl.yahoo.com> Message-ID: <443EDCAC.3060208@web.de> Puddinhead Wilson wrote: > > > no, i m saying use what is anyway unique to the "end > point" as it's idenfier. Then, we should use the hardware address, typically the burned in MAC address. > > If the MAC address is what people "dial" then the mac > address it is. if the "phone number is what people > dial" then let it be the phone number. Hm. I?m not quite sure whether the good ol?POTS is still in use in the UK. At least, I have an ISDN phone, and the phone number is not a suitable means to identify a terminal. It can be reassigned exactly like an IP address. Therefore, directing a phone call onto the correct terminal is bascially a routing problem. Perhaps, you have noticed that telco-guys typically talk about "layer 3" when they talk about those problems. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mycroft at netbsd.org Thu Apr 13 17:13:48 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Thu, 13 Apr 2006 20:13:48 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <443EDB1E.9000403@swin.edu.au> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443E8CB8.8090601@isi.edu> <20060413185956.GF29472@multics.mit.edu> <443EDB1E.9000403@swin.edu.au> Message-ID: <20060414001348.GO29472@multics.mit.edu> On Fri, Apr 14, 2006 at 09:13:34AM +1000, grenville armitage wrote: > Charles M. Hannum wrote: > [..] > >I'm still trying to figure out where this notion of IP addresses being > >"globally unique" came from. IP addresses are *not* globally unique. > >Even if we ignore NAT, they are still ephemeral due to DHCP, ND, etc. > > Being ephemeral, and being unique while assigned, seem orthogonal to me. I saw no qualifier of "while assigned". For many of the uses of MAC addresses -- e.g. DHCP -- the permanance of the uniqueness actually matters (in several different ways). For that matter, consider 802.11. An AP may not even have an IP address, if it's bridging, so the *only* identifier is a MAC address. Like an Ethernet switch, it's specifically designed to be transparent to IP and blend in with the Ethernet switch architecture. What's the advantage of changing that? (Besides screwing all the cable users who can't get more than one IP address, and forcing them to use NAT even if they have a single machine! Now there's a good goal.) From mycroft at netbsd.org Thu Apr 13 17:17:28 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Thu, 13 Apr 2006 20:17:28 -0400 Subject: [e2e] [mycroft@MIT.EDU: Re: use of MAC addresses] Message-ID: <20060414001728.GQ29472@multics.mit.edu> Whoops, fired from the wrong address before. ----- Forwarded message from "Charles M. Hannum" ----- Return-Path: mycroft at MIT.EDU Received: from po12.mit.edu ([unix socket]) by po12.mit.edu (Cyrus v2.1.5) with LMTP; Thu, 13 Apr 2006 20:05:23 -0400 X-Sieve: CMU Sieve 2.2 Received: from fort-point-station.mit.edu by po12.mit.edu (8.13.6/4.7) id k3E05Ep9021570; Thu, 13 Apr 2006 20:05:22 -0400 (EDT) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3E04XuZ011477 for ; Thu, 13 Apr 2006 20:04:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix) id 747AE63B13B; Fri, 14 Apr 2006 00:04:33 +0000 (UTC) Delivered-To: mycroft at netbsd.org Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) by mail.netbsd.org (Postfix) with ESMTP id 258C663B134 for ; Fri, 14 Apr 2006 00:04:33 +0000 (UTC) Received: (from mycroft at localhost) by multics.mit.edu (8.12.9) id k3E04SHB015708; Thu, 13 Apr 2006 20:04:28 -0400 (EDT) Date: Thu, 13 Apr 2006 20:04:28 -0400 From: "Charles M. Hannum" To: Joe Touch Cc: "Charles M. Hannum" , Fahad Dogar , Ted Faber , end2end-interest at postel.org Subject: Re: [e2e] use of MAC addresses Message-ID: <20060414000428.GN29472 at multics.mit.edu> References: <443D3546.60506 at isi.edu> <443E76E0.1040600 at isi.edu> <443E8CB8.8090601 at isi.edu> <20060413185956.GF29472 at multics.mit.edu> <443EC2A3.3000508 at isi.edu> <20060413220603.GM29472 at multics.mit.edu> <443ED483.1080805 at isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <443ED483.1080805 at isi.edu> User-Agent: Mutt/1.5.6i X-Spam-Score: 3.548 X-Spam-Level: *** (3.548) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 On Thu, Apr 13, 2006 at 03:45:23PM -0700, Joe Touch wrote: > The "" in your response is important; many "shared media" these days > aren't. That doesn't mean the MAC address isn't still useful, but it > does mean it may not be necessary. Sure. As I pointed out before, lots of point-to-point protocols don't have a notion of "link layer" addresses. Take PPP, for example -- for purposes of assigning addresses, it typically uses a combination of {POP,user} as a unique identifier. This works because the owner of the POP can guarantee that the users are unique. In a hypothetical setup where we have people roaming around between different APs/POPs/whatever using possibly-conflicting identifiers, this is all going to fall down. Having a globally unique identifier simplifies the problem tremendously. What's the advantage of changing it? Some mythical notion that MAC addresses are "outdated" isn't going to cut it. Besides, we've already discussed several useful purposes that the MAC address serves, so it's rather clearly *not* outdated. ----- End forwarded message ----- From weigengyu at hotmail.com Thu Apr 13 20:01:47 2006 From: weigengyu at hotmail.com (weigengyu) Date: Fri, 14 Apr 2006 11:01:47 +0800 Subject: [e2e] Fwd: Re: use of MAC addresses References: <20060413182221.38485.qmail@web25405.mail.ukl.yahoo.com> <443EDCAC.3060208@web.de> Message-ID: ----- Original Message ----- From: "Detlef Bosau" To: Sent: Friday, April 14, 2006 7:20 AM Subject: Re: [e2e] Fwd: Re: use of MAC addresses > > Hm. I?m not quite sure whether the good ol?POTS is still in use in the > UK. At least, I have an ISDN phone, and the phone number is not a > suitable means to identify a terminal. It can be reassigned exactly like > an IP address. Therefore, directing a phone call onto the correct > terminal is bascially a routing problem. Perhaps, you have noticed that > telco-guys typically talk about "layer 3" when they talk about those > problems. > > Detlef > Historically, the telephone number was the same as the hardware address, so identified the physical position on the frame. Now it is becoming a logical number, but there are means to record the relation of the hardware address and the telephone number (or ISDN number). >From the experience of telecom, separation of logical number and physical number is necessary; and separation of IP address function and Mac address is also necessary. Gengyu > > -- > Detlef Bosau > Galileistrasse 30 > 70565 Stuttgart > Mail: detlef.bosau at web.de > Web: http://www.detlef-bosau.de > Mobile: +49 172 681 9937 > > From fahad.dogar at gmail.com Fri Apr 14 02:45:21 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Fri, 14 Apr 2006 14:45:21 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <443EC7BC.2080709@isi.edu> References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443EC7BC.2080709@isi.edu> Message-ID: On 4/14/06, Joe Touch wrote: > > > Fahad Dogar wrote: > > On 4/13/06, Joe Touch wrote: > ... > > IMHO, we have to change these protocols because they have been > > designed keeping in view the presence of MAC addresses and how they > > work. > > You need to change the protocols only if they don't do something you > need to do. What is it you need to do? > > > If we were to redesign Internet and networking technologies > > (clean slate approach), do we need to have a different MAC address. > > Shouldn't IP address be sufficient? It is like assigning a globally > > unique name to every person and then asking him to maintain an > > additional name for 'local' identification. > > The locally unique address is how you know you're different from someone > else before you get (or pick a random, possibly colliding) IP address. I think this is one very valid answer to my question. My question was not on whether we should do away with MAC addresses. As has been rightly pointed out in this thread there is no need to do this --- both from cost and efficiency point of view. I was interested in knowing whether we can do this in 'theory' i.e. if we can identify an interface by an IP address then in theory we should be able to reach that interface without requiring any other form of identification. You have right mentioned the need for another address during the phase when the IP address is not assigned (DHCP). Any other alternative based on (name, address) combination is effectively an alternate to MAC address which shows that we DO need an identifier in addition to the IP address. Thanks, Fahad > The reason for that need is the MAC protocol - bridging, backoff, > spanning tree, etc. If you design a multi-access subnet that doesn't > need unique a-priori addresses, then you might be able to reuse IP > addresses. > > I.e., this needs to be motivated at the MAC layer. > > Joe > > From detlef.bosau at web.de Fri Apr 14 08:26:10 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Apr 2006 17:26:10 +0200 Subject: [e2e] Fwd: Re: use of MAC addresses In-Reply-To: References: <20060413182221.38485.qmail@web25405.mail.ukl.yahoo.com> <443EDCAC.3060208@web.de> Message-ID: <443FBF12.5080708@web.de> weigengyu wrote: > From the experience of telecom, separation of logical number and physical number is necessary; > and separation of IP address function and Mac address is also necessary. > Basically, that?s the very question: Is the seperation of logical and physical addresses really _necessary_? Or ist it done for historical reasons? What I find particularly interesting in this discussion is, that it?s obviously difficult, to find compelling reasons for this separation. In fact, when I read Craig?s remark on mobility, this was perhaps the most compelling reason for this separation in the whole discussion. The reason for this might be, that IP is basically nothing else then a protocol for a "generic network" which is in fact quite similar to the interconnected "subnets". We establish an "internetwork" consisting on a number of "subnetworks". Of course, some of the subnetworks in use have mechanisms which are not available to other ones, e.g. we can find upper limits for transportation times in Token Ring whereas the same task is not possible for Ethernet. If we combine those different subnetwokrss to an internetworks, the internetwork?s feature set is necessarily the intersection of the combined subnet?s ones. Sometimes, I ask people for the difference between routing and bridging. And then I get long answers, even longer than one of my posts. However, the answer is astonishing simple: Basically, there is none. In either case, a store and forward system receives a packet and has to decide where to send it. Typically, IP routing is characterized by three tasks: 1. Addressing. Find a common address space for the whole network and a unique address for each member. 2. Segmentation and Reassembly. 3. Routing. The second one is obsolete, as we dropped transparent segmentation in favour of do path MTU discovery. The third one is basically the same on L2 and L3. The first one is a matter of definition. However, I said routing was _basically_ the same one. In fact, there are often subtle differences between routing in a LAN, in a WAN, in small networks with only a few nodes, in large networks with a huge number of nodes or in networks with mobile nodes which can be attached to the network in different position. And of course, we did not talk about network specific requirements yet, like functional addresses or certain address formats for member solicitations, which are beyound the scope of IP. If you look at an IP network and e.g. an Ethernet from a programmers point of view, the differences are sometimes very subtle. And this may be the reason for the confusion. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Apr 14 09:44:32 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 14 Apr 2006 18:44:32 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443EC7BC.2080709@isi.edu> Message-ID: <443FD170.7020208@web.de> Fahad Dogar wrote: > I think this is one very valid answer to my question. My question was > not on whether we should do away with MAC addresses. As has been > rightly pointed out in this thread there is no need to do this --- > both from cost and efficiency point of view. I was interested in > knowing whether we can do this in 'theory' i.e. if we can identify an > interface by an IP address then in theory we should be able to reach > that interface without requiring any other form of identification. I think, Joe correctly refered to the MAC layer and MAC protocol. > You have right mentioned the need for another address during the phase > when the IP address is not assigned (DHCP). Any other alternative DHCP is one very special issue. IP is an abstraction. IP based internetworks are an abstraction. They _hide_ any subnetwork specific technology / requirement from upper layers. Nevertheless, the subnetworks themselves exist. Wether we have a Token Bus system which frequently solicits new terminals to join the network or whether we have a PSTN which needs (phone) numbers for dialing and reaching a peer - either way, subnetworks exist and so do their requirements. It is something _hidden_ by IP and it is something taken care of by subnetworks. From a top down perpective, the only function provided by a packet switching network is to convey a packet from terminal A to terminal B. And you don?t care about how this is achieved. In fact, the capability of conveying a packet from terminal A to terminal B in a subnetwork is the only requirement for this subnetwork to be part of an internetwork. Unfortunately, this argument might not work the other way round. Being capable of having an IP address migth be not sufficient for a subnetwork to work. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From dga+ at cs.cmu.edu Fri Apr 14 17:28:08 2006 From: dga+ at cs.cmu.edu (David G. Andersen) Date: Fri, 14 Apr 2006 20:28:08 -0400 Subject: [e2e] CFP: WORLDS'06, Workshop on Real, Large Distributed Systems Message-ID: <20060415002808.GA24119@cs.cmu.edu> WORLDS '06 Call for Papers 3rd Workshop on Real, Large Distributed Systems (WORLDS '06) November 5, 2006 Seattle, WA, USA Sponsored by USENIX, the Advanced Computing Systems Association Co-located with the 7th Symposium on Operating Systems Design and Implementation (OSDI '06), which takes place November 6-8, 2006. Important Dates Paper submissions due: July 7, 2006, 11:59 p.m. PDT Notification to authors: August 8, 2006 Demo submissions due: September 7, 2006 Final papers due: September 8, 2006 Workshop Organizers Program Co-Chairs David Andersen, Carnegie Mellon University Neil Spring, University of Maryland Preliminary Program Committee Mike Afergan, Akamai Mike Dahlin, University of Texas, Austin Marc Fiuczynski, Princeton University Michael Freedman, New York University Krishna Gummadi, Max Planck Institute for Software Systems Dina Katabi, Massachusetts Institute of Technology Jay Lepreau, University of Utah Dan Rubenstein, Columbia University Martin Swany, University of Delaware Matt Welsh, Harvard University Janet Wiener, Hewlett-Packard Ming Zhang, Microsoft Research Workshop Overview The 3rd Workshop on Real, Large Distributed Systems will bring together people who are exploring the new challenges of building widely distributed networked systems and who lean toward the "rough consensus and running code" school of systems building. WORLDS is a place to share new ideas, experiences, and work in progress, with an emphasis on systems that actually run in the wide area and the specific challenges they present for designers and researchers. Workshop means the emphasis is on focused, fresh ideas and experience. Talks will be short (about 15 minutes long) to leave plenty of time for general discussion. Attendance will consist of contributors to the workshop and a subset of the OSDI attendees, with the number of non-contributors limited to encourage lively discussion between the participants. Real means that the workshop will concentrate on systems designed to run on a real platform for a period of time. Such systems might be research projects, teaching exercises, or more permanent services, but they should address technical issues of actual widely distributed systems. We also welcome papers that explore the extent to which results obtained from simulation or testbed deployments retain validity when transferred to more representative network environments. Large refers to the numerical and geographical dimensions of the system: WORLDS emphasizes distributed systems that span a significant portion of the globe and are spread over a large number of sites. Submitting a Paper Submissions should be at most 5 U.S. letter pages long, two-column format, using 10-point type on 12-point (single-spaced) leading within a 6.5" x 9" text block. Participants will be invited based on their ability to convince the program committee that they have built, are building, or are experimenting with a Real, Large Distributed System and have useful ideas, tools, experience, data, or research directions to share with the community that will stimulate discussion at the workshop. Submit your paper via the Web form, which will be available here soon. Online copies of the position papers will be made available before the workshop to registered attendees and will be added to the USENIX proceedings library after the workshop. Participants may update their papers to incorporate workshop feedback. USENIX policy on simultaneous paper subission: Simultaneous submission of the same work to multiple venues, submission of previously published work, and plagiarism constitute dishonesty or fraud. USENIX, like other scientific and technical conferences and journals, prohibits these practices and may, on the recommendation of a program chair, take action against authors who have committed them. In some cases, program committees may share information about submitted papers with other conference chairs and journal editors to ensure the integrity of papers under consideration. If a violation of these principles is found, sanctions may include, but are not limited to, barring the authors from submitting to or participating in USENIX conferences for a set period, contacting the authors' institutions, and publicizing the details of the case. Authors uncertain whether their submission meets USENIX's guidelines should contact the program chairs, worlds06chairs at usenix.org, or the USENIX office, submissionspolicy at usenix.org. Demo Session This year, WORLDS will again feature a demo session in which researchers will have the opportunity to demonstrate the real, running distributed systems they have built. Authors who have their full 5-page workshop papers accepted will automatically be granted the opportunity to present a demo. Others who wish to present a demo should submit a single-page demo description that (a) concretely describes the research problem solved by the system to be demonstrated and (b) concretely describes what will be shown at the demo. Submit your demo via the Web form, which will be available here soon. Awards We expect to offer both a best paper award and a best demo award. From best at cs.bu.edu Fri Apr 14 19:40:51 2006 From: best at cs.bu.edu (Azer Bestavros) Date: Fri, 14 Apr 2006 22:40:51 -0400 Subject: [e2e] CFP: HotWeb -- IEEE Workshop on Hot Topics in Web Systems and Technologies Message-ID: <0511C607B17F804EBE96FFECD1FD9859D0A25C@cs-exs2.cs-nt.bu.edu> HotWeb'06: First Workshop on Hot Topics in Web Systems and Technologies (IEEE Sponsorship Pending) http://www.cs.bu.edu/pub/hotweb06 Boston, Massachusetts, USA November 13-15, 2006 ------------------------------------------------------------ Preliminary Call for Papers HotWeb is a forum that brings together researchers and practitioners interested in the design, implementation, and evaluation of Internet systems and applications. The workshop seeks to act as a conduit for presentation of novel approaches used in support of performance, scalability, and security of Internet applications, including Web searching and indexing, content distribution and delivery networks, Web services, and edge and grid computing. Areas of interest include, but are not limited to: + Content delivery architectures + Peer-to-Peer systems + Support for mobile and wireless systems + Web caching and replication + Edge services and dynamic content delivery + Multimedia content distribution + Overlay networks + Content placement and request routing + Measurement studies of deployed systems + Security and privacy + Wide-area upload and content gathering + Novel web-based applications + Web/database integration + Information retrieval and searching + Electronic commerce + Internet telephony The HotWeb workshop is the successor of the WCW (Workshop on Web Content Caching and Distribution), and the WIAPP (Workshop on Internet Applications) workshops, both of which are merging to form HotWeb. HotWeb 2006 is sponsored by the IEEE Computer Society (support pending) and will be held in Boston during the week of November 12, 2006. ------------------------------------------------------------ Organizing Committee: General Chair: Azer Bestavros, Boston University Program Chair: Bruce Maggs, Carnegie Mellon and Akamai Technologies Program Committee: Pei Cao, Stanford Armando Fox, Stanford Arun Iyengar, IBM Bruce Maggs, Carnegie Mellon and Akamai Technologies Venkat Padmanabhan, Microsoft Vivek Pai, Princeton Pablo Rodriquez Rodriquez, Microsoft Ramesh Sitaraman, U. Massachusetts and Akamai Technologies Oliver Spatscheck, AT&T Andrew Tomkins, Yahoo! Leonidas Kontothanassis, Intel Steve Vinoski, IONA Technologies Tina Wong, Carnegie Mellon ------------------------------------------------------------ Steering Committee: Azer Bestavros, Boston University Fred Douglis, IBM Jeff Dean, Google Arun Iyengar, IBM Michael Rabinovich, Case Western Reserve Pablo Rodriguez Rodriguez, Microsoft Prabhakar Raghavan, Yahoo! ------------------------------------------------------------ Important Dates: Submission deadline: June 15, 2006 Notification: July 31, 2006 Workshop: November 13-15, 2006 ------------------------------------------------------------ For more information check http://www.cs.bu.edu/pub/hotweb06 From lisongxu2 at gmail.com Sat Apr 15 13:10:32 2006 From: lisongxu2 at gmail.com (Lisong Xu) Date: Sat, 15 Apr 2006 15:10:32 -0500 Subject: [e2e] admission control vs congestion control Message-ID: Hi everybody, Both congestion control-based and admission control-based approaches were proposed for multimedia streaming over the Internet a few years ago. Intuitively, admission control is more suitable for multimedia streaming than congestion control, since admission control can provide some guaranteed bandwidth. However, it seems that congestion control-based approaches are accepted by more people. I am wondering what the fundamental reason is. Is it because congestion control-based approaches are tcp-friendly, and then safer to implement in the Internet? Thanks in advance! Lisong From detlef.bosau at web.de Mon Apr 17 09:47:15 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 17 Apr 2006 18:47:15 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <20060417151537.89294.qmail@web25405.mail.ukl.yahoo.com> References: <20060417151537.89294.qmail@web25405.mail.ukl.yahoo.com> Message-ID: <4443C693.5090503@web.de> Puddinhead Wilson wrote: > --- Detlef Bosau wrote: > > > > Yes so why not carry out all transcations using that address? IIRC, Joe discussed this before. The routing algorithms simply do not scale up to millions of nodes when you use a "flat" address room. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From dmchiu at ie.cuhk.edu.hk Mon Apr 17 10:06:47 2006 From: dmchiu at ie.cuhk.edu.hk (Dah Ming Chiu) Date: Tue, 18 Apr 2006 01:06:47 +0800 Subject: [e2e] admission control vs congestion control References: Message-ID: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> Hi Lisong, This is an interesting question! I believe your intuition is quite right. In fact I had the same intuition. So the question is how do you show it is true. This question cannot be easily answered using the currently widely accepted models for studying congestion controls. We have developed a methodology to compare the two traffic controls in a heterogeneous environment (when you have both kinds of traffic). Basically, we propose a way to compute "utility throughput" for each kind of traffic, which can be done under a variety of "workloads". A traffic control is "better" if it is no worse off in generating both kinds of utility throughput in comparison to another traffic control. Based on this, we are able to show that admission control is more suitable than congestion control over a wide spectrum of workloads. We have published a couple of conference papers on this topic: a) "Network fairness for heterogeneous applications", Sigcomm Asia Workshop 2005 b) "A Case for TCP-friendly Admission Control", to appear in IWQoS 2006 A more complete technical report summing up all the results is in c) "Redefining Fairness in the Study of TCP-friendly Traffic Controls" All of them are posted on my web page http://personal.ie.cuhk.edu.hk/~dmchiu/publications.html An updated version of (c) will be posted in a few days if you can wait. Regards Dah Ming ----- Original Message ----- From: "Lisong Xu" To: Sent: Sunday, April 16, 2006 4:10 AM Subject: [e2e] admission control vs congestion control > Hi everybody, > > Both congestion control-based and admission control-based approaches > were proposed for multimedia streaming over the Internet a few years > ago. Intuitively, admission control is more suitable for multimedia > streaming than congestion control, since admission control can provide > some guaranteed bandwidth. > > However, it seems that congestion control-based approaches are > accepted by more people. I am wondering what the fundamental reason > is. Is it because congestion control-based approaches are > tcp-friendly, and then safer to implement in the Internet? > > Thanks in advance! > Lisong > From detlef.bosau at web.de Mon Apr 17 15:18:51 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Apr 2006 00:18:51 +0200 Subject: [e2e] admission control vs congestion control In-Reply-To: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> Message-ID: <4444144B.7000507@web.de> Dah Ming Chiu wrote: > Hi Lisong, > > This is an interesting question! I believe your intuition is quite > right. In fact > I had the same intuition. So the question is how do you show it is true. > This question cannot be easily answered using the currently widely accepted > models for studying congestion controls. > I tend to disagree here. From my point of view, the objective of admission control and congestion control is bascially different. Perhaps, I?m somewhat disappointed by experiences I made myself during the last about seven years. However, _basically_, and I?m ready to see contradiction here, bringing multimedia to the Internet is reinventing the wheel. There are dozens of PhD-theses which provide mechanisms for admission control and discuss how to provide for QoS and so on. Excuse me: What?s the very difference between these mechanisms and good ol? TDM as it is used in line switched networks with excellent results for decacdes now? (I know, this question is provoking and it?s intended to be.) Most of the proposed protocols and mechanism do nothing else them implement Telco protocols and mechanisms using IP packets, including replacing best effort store?n forwared nodes with switches using schedulers. That?s nothing else than a digital Strowger Gear, which is known to work fine for decades. We should leave it for the Kansas City cemetery, perhaps at good ol? Almons tombstone ;-) As a concrete example consider wide area mobile networks. Why do we discuss "multimedia over IP" in this context for no reasons, when actually availabe line switching mechanisms marvelously serve this very purpose? O.k., perhaps there _are_ resons to consider multimedia over IP, but then we should agree upon a concrete system model which is to be discussed here. So, _admission_ _control_ serves the purpose to maintain QoS agreements and to allocate ressources to streams applying for them. _Congestion_ _control_ prevents the path capacity from being exceeded in a best effort environment. In a very concise manner we can say: Admission control is a _hierarchical_ concept whereas congestion control is a _heterarchical_ concept. Often we follow an hybrid approach: We reserve parts of a network?s capacity for hierarchical purposes and QoS whereas the rest of the network is left to heterarchical best effort communication. Of course, we can define arbitrary utility functions to have the ressource partitioning follow a set of rules or policies. One of these policies could be to make a real time rate controlled flow "TCP friendly". However, all of these policies are basically a matter of definition. And definitions are generally that difficult to prove ;-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From day at std.com Tue Apr 18 06:54:14 2006 From: day at std.com (John Day) Date: Tue, 18 Apr 2006 09:54:14 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443EC7BC.2080709@isi.edu> Message-ID: This has been an unbelievable discussion. That in 2006, there is still such confusion. Fahad asked a perfectly reasonable theoretical question. First, Fahad please read carefully Jerry Saltzer's 1982 paper, RFC1498. Most of what you want is in there. Saltzer gets it right. In addressing, one has a choice of naming interfaces or protocol machines. It doesn't matter which as long as you are consistent. Naming the interface is equivalent to naming the lower protocol machine it is bound to. So to answer your question, yes, the IP address and the MAC address do name the same thing. As has been pointed out, strictly speaking on a point to point media one does not need the lower address, but one does on a shared media. Actually for authentication purposes, you probably always want to have some identifier from the new device to ensure that he is who you think he is. Something like a serial number. And given that MAC addresses were originally assigned at the factory, that is precisely what it is, a serial number, not an address. (And as someone pointed out, the MAC address has greater scope than the IP address, which is strange since scope should increase as one goes up in the architecture.) Saltzer says that a complete addressing architecture needs Application Names, Node Addresses, Point of Attachment Addresses and from all of this we get routes. There is one refinement I would make to Saltzer which I think was overlooked because it hadn't occurred when he wrote the paper. Salzter talks about the mappings of application names to node addresses, node addresses to point of attachment addresses and points of attachments to routes. The refinement is that routes are sequences of node addresses. The routers must also maintain the mappings of node addresses to points of attachment addresses for all nearest neighbors. Once the next hop is determined from the route, this last mapping is used to determine the choice of *path* to the next hop. Multiple paths between next hops were rare or non-existent in 82, so it isn't surprising Saltzer missed it. Actually, this refinement brings a very nice symmetry to the whole structure. The implications are interesting. If you carefully read Saltzer's description and construct what he says and then hold it up to our current situation, you find that we are missing half of the necessary elements. We have no application names and no node addresses. IP addresses by naming the interface are points of attachments. And as you figured out we name the point of attachment twice. There are a number of implications that fall out of this that explain why some things are so cumbersome in the current architecture and would be no-brainers if it were complete. (For those who were worrying about an identifier that doesn't change, it is the application name. All the others do change.) When I worked through this and was quite surprised by the outcome, I began to wonder on how we got here. As I turned over in my head those early events that was even more surprising. Basically the Internet addressing architecture is an unfinished demo. And the demo was ICCC 72! ;-) We jury-rigged stuff for the demo and never went back to finish the job. It is almost criminal that none of this is explained in any textbook currently out there, especially given that it is something we have known for almost a quarter century. This is the scientific explanation, now of course the engineering explanation is a bit different. Take care, John At 14:45 +0500 2006/04/14, Fahad Dogar wrote: >On 4/14/06, Joe Touch wrote: >> >> >> Fahad Dogar wrote: >> > On 4/13/06, Joe Touch wrote: >> ... >> > IMHO, we have to change these protocols because they have been >> > designed keeping in view the presence of MAC addresses and how they >> > work. >> >> You need to change the protocols only if they don't do something you > > need to do. What is it you need to do? >> >> > If we were to redesign Internet and networking technologies >> > (clean slate approach), do we need to have a different MAC address. >> > Shouldn't IP address be sufficient? It is like assigning a globally > > > unique name to every person and then asking him to maintain an >> > additional name for 'local' identification. >> >> The locally unique address is how you know you're different from someone >> else before you get (or pick a random, possibly colliding) IP address. > >I think this is one very valid answer to my question. My question was >not on whether we should do away with MAC addresses. As has been >rightly pointed out in this thread there is no need to do this --- >both from cost and efficiency point of view. I was interested in >knowing whether we can do this in 'theory' i.e. if we can identify an >interface by an IP address then in theory we should be able to reach >that interface without requiring any other form of identification. > >You have right mentioned the need for another address during the phase >when the IP address is not assigned (DHCP). Any other alternative >based on (name, address) combination is effectively an alternate to >MAC address which shows that we DO need an identifier in addition to >the IP address. > >Thanks, >Fahad > >> The reason for that need is the MAC protocol - bridging, backoff, >> spanning tree, etc. If you design a multi-access subnet that doesn't >> need unique a-priori addresses, then you might be able to reuse IP >> addresses. >> >> I.e., this needs to be motivated at the MAC layer. >> >> Joe >> >> From dga+ at cs.cmu.edu Tue Apr 18 07:38:25 2006 From: dga+ at cs.cmu.edu (David Andersen) Date: Tue, 18 Apr 2006 10:38:25 -0400 Subject: [e2e] Naming (was: MAC addresses) In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443EC7BC.2080709@isi.edu> Message-ID: On Apr 18, 2006, at 9:54 AM, John Day wrote: > > Saltzer says that a complete addressing architecture needs > Application Names, Node Addresses, Point of Attachment Addresses > and from all of this we get routes. There is one refinement I > would make to Saltzer which I think was overlooked because it > hadn't occurred when he wrote the paper. Salzter talks about the > mappings of application names to node addresses, node addresses to > point of attachment addresses and points of attachments to routes. I think there are others, and I may be missing some. User names and content names come immediately to mind. Without them, things like Web pages are inextricably bound to either a particular application instance (obviously bad), a node address (how do you akamize? how do you change to a different akamai w/out renaming?), or a point of attachment address (erk). Of course, this is pretty much the situation today, but it doesn't have to be. SFR (Semantic Free References) - http://nms.lcs.mit.edu/projects/sfr/ Walfish, Balakrishnan, and Shenker -> Human *un*readable permanent identifiers for content, resolved through a flat naming infrastructure. Allows things like web links or email addresses to persist through name changes, business reorganization, etc. DOT (Data-Oriented Transfer) - http://www.cs.cmu.edu/~dga/dot/ (Myself, Kaminsky, Tolia, Patil) -> Decouples data transfer from endpoints and applications by going indirectly through a content-hash (a'la what BitTorrent does, but generalized in an application-independent manner for point-to- point transfers). Benefit: Makes things like caching, akamizing, mirroring, etc., ridiculously simple. Has other cool benefits too, but I'll stop beating that drum. :) > (For those who were worrying about an identifier that doesn't > change, it is the application name. All the others do change.) I'm not sure this is correct. If the application name is an unchanging, long-term identifier, then you're not able to distinguish between a session identifier (e.g., tcp migrate, bits of sctp, etc.) and a persistent content ID. Or I'm wrong. :) -Dave, adding a level of indirection. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060418/c9eb1aed/PGP.bin From huitema at windows.microsoft.com Tue Apr 18 08:21:19 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Tue, 18 Apr 2006 08:21:19 -0700 Subject: [e2e] use of MAC addresses In-Reply-To: Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0645CD502@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > Saltzer says that a complete addressing architecture needs > Application Names, Node Addresses, Point of Attachment Addresses and > from all of this we get routes. There is one refinement I would make > to Saltzer which I think was overlooked because it hadn't occurred > when he wrote the paper. Salzter talks about the mappings of > application names to node addresses, node addresses to point of > attachment addresses and points of attachments to routes. Another refinement is the use of multiple hosts for a single application, e.g. load balancing across a farm of web servers. There is a need to independently name the application (e.g. the web page at www.example.com), and the application instance (something like www.host29.example.com). If you think in terms of DNS mapping to IP addresses, as we do today, the first name maps to the entire list of IP addresses of all the servers in the pool; the second name maps only to the IP addresses of the specific host handling a specific session. One may also need a name for the session itself, as it could in theory be "load balanced" between servers. -- Christian Huitema From detlef.bosau at web.de Tue Apr 18 09:49:09 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 18 Apr 2006 18:49:09 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> References: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> Message-ID: <44451885.5090902@web.de> Puddinhead Wilson wrote: > Scale up for what? > Reachability and switching methods and end point > identifiers are all different topics. > Reachability / Throughput. In principle, you can interconnect all computers in the world via a flat Ethernet. (Define a "DS-Ethernet" := Deep Sea Ethernet for intercontinental lines if necessary.) How large will the switching tables be? Can we extend this until the switching tables grow beyond all limits? And so does the processing time on routers? How much papers did you see which take into account the processing delay of a packet on a switch / router? I personally did not see that many. Routing is a wonderful topic. I?ve seen even people talking about "GeoCast". (Totally outdated IMHO, I think the minimum should be GalaxyCast or UniCast, which means not Unicast but Universe Cast ;-)) In my opinion, the most basic reason for IP?s success is that IP addresses both for nodes and networks as well make addressing, subnetting and routing outstandingly simple. If I ever were to tell three strokes of genius which make internetworking work, the IP addressing scheme were surely among them. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From braden at ISI.EDU Tue Apr 18 09:58:13 2006 From: braden at ISI.EDU (Bob Braden) Date: Tue, 18 Apr 2006 09:58:13 -0700 (PDT) Subject: [e2e] use of MAC addresses Message-ID: <200604181658.JAA03622@gra.isi.edu> John, That line of reasoning (Saltzer plus) does not seem to clarify a central distinction: media-dependent addressing vs. media dependent addressing. No one thought about building one universal address space for media addresses, because we assumed that each distinct medium would naturally have its own form of addressing. (Today, there is a tendency for (almost) all media to look like Ethernets, so perhaps one exploit that fact). IP addresses were built to provide a universal address space, with essentially an indirection linking to the corresponding media-dependent addresses of connection points. Bob Braden From day at std.com Tue Apr 18 10:56:47 2006 From: day at std.com (John Day) Date: Tue, 18 Apr 2006 13:56:47 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0645CD502@WIN-MSG-21.wingroup.windeploy.ntde v.microsoft.com> References: <70C6EFCDFC8AAD418EF7063CD132D0645CD502@WIN-MSG-21.wingroup.windeploy.ntde v.microsoft.com> Message-ID: At 8:21 -0700 2006/04/18, Christian Huitema wrote: > > Saltzer says that a complete addressing architecture needs >> Application Names, Node Addresses, Point of Attachment Addresses and >> from all of this we get routes. There is one refinement I would make >> to Saltzer which I think was overlooked because it hadn't occurred >> when he wrote the paper. Salzter talks about the mappings of >> application names to node addresses, node addresses to point of >> attachment addresses and points of attachments to routes. > >Another refinement is the use of multiple hosts for a single >application, e.g. load balancing across a farm of web servers. There is >a need to independently name the application (e.g. the web page at >www.example.com), and the application instance (something like >www.host29.example.com). If you think in terms of DNS mapping to IP >addresses, as we do today, the first name maps to the entire list of IP >addresses of all the servers in the pool; the second name maps only to >the IP addresses of the specific host handling a specific session. One >may also need a name for the session itself, as it could in theory be >"load balanced" between servers. Yea, as I commented to David, this is what I would term a general form of anycast address or name. i.e. the name of a set such that referencing the name returns a member of the set according to some rule. Take care, John From day at std.com Tue Apr 18 11:00:11 2006 From: day at std.com (John Day) Date: Tue, 18 Apr 2006 14:00:11 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <200604181658.JAA03622@gra.isi.edu> References: <200604181658.JAA03622@gra.isi.edu> Message-ID: At 9:58 -0700 2006/04/18, Bob Braden wrote: >John, > >That line of reasoning (Saltzer plus) does not seem to clarify >a central distinction: media-dependent addressing vs. >media dependent addressing. No one thought about building one >universal address space for media addresses, because we assumed >that each distinct medium would naturally have its own form >of addressing. (Today, there is a tendency for (almost) all >media to look like Ethernets, so perhaps one exploit that >fact). IP addresses were built to provide a universal >address space, with essentially an indirection linking to the >corresponding media-dependent addresses of connection points. I am sorry, Bob, but I don't have a clue what you are talking about. I fail to see how medium affects addressing. Any medium has limited scope and hence a limited address space. As I commented earlier, I have always thought it peculiar that MAC addresses had a larger address space than IP addresses. By my calculation, they are about 3 - 4 times larger than they need to be, i.e. the maximum number of devices one would reasonably expect on a single LAN segment. This confusion of IEEE 802 universal serial numbers with addresses always seemed a little strange to me. It is also a little strange that *IP* addresses name a *subnet* point of attachment. ;-) Take care, John From day at std.com Tue Apr 18 10:56:42 2006 From: day at std.com (John Day) Date: Tue, 18 Apr 2006 13:56:42 -0400 Subject: [e2e] Naming (was: MAC addresses) In-Reply-To: References: <20060411185920.GB8500@hut.isi.edu> <443D21DD.1010709@isi.edu> <443D3546.60506@isi.edu> <443E76E0.1040600@isi.edu> <443EC7BC.2080709@isi.edu> Message-ID: At 10:38 -0400 2006/04/18, David Andersen wrote: >On Apr 18, 2006, at 9:54 AM, John Day wrote: > >> >>Saltzer says that a complete addressing architecture needs >>Application Names, Node Addresses, Point of Attachment Addresses >>and from all of this we get routes. There is one refinement I >>would make to Saltzer which I think was overlooked because it >>hadn't occurred when he wrote the paper. Salzter talks about the >>mappings of application names to node addresses, node addresses to >>point of attachment addresses and points of attachments to routes. > >I think there are others, and I may be missing some. User names and >content names come immediately to mind. Without them, things like >Web pages are inextricably bound to either a particular application >instance (obviously bad), a node address (how do you akamize? how >do you change to a different akamai w/out renaming?), or a point of >attachment address (erk). Of course, this is pretty much the >situation today, but it doesn't have to be. > > SFR (Semantic Free References) - http://nms.lcs.mit.edu/projects/sfr/ > Walfish, Balakrishnan, and Shenker > > -> Human *un*readable permanent identifiers for content, resolved >through a flat naming infrastructure. Allows things like web links >or email addresses to persist through name changes, business >reorganization, etc. > > DOT (Data-Oriented Transfer) - http://www.cs.cmu.edu/~dga/dot/ > (Myself, Kaminsky, Tolia, Patil) > > -> Decouples data transfer from endpoints and applications by >going indirectly through a content-hash (a'la what BitTorrent does, >but generalized in an application-independent manner for >point-to-point transfers). Benefit: Makes things like caching, >akamizing, mirroring, etc., ridiculously simple. Has other cool >benefits too, but I'll stop beating that drum. :) Ahhh, yes. All of that. I was trying to keep it simple in the first approximation. ;-) There is a need to distinguish applications, multiple instances of applications, something I prefer to call the application-protocol (of which an application can have more than one) and multiple instances of these. As well as various sets of these things, which I have usually called group addresses and generic addresses. Others have called the latter anycast addresses but I think usually in a narrower sense than I have in mind. >>(For those who were worrying about an identifier that doesn't >>change, it is the application name. All the others do change.) > >I'm not sure this is correct. If the application name is an >unchanging, long-term identifier, then you're not able to >distinguish between a session identifier (e.g., tcp migrate, bits of >sctp, etc.) and a persistent content ID. Or I'm wrong. :) Yea, this is where the instance level naming is required. ;-) Actually, one thing I didn't mention in that first email is that that application names are supposedly location-independent and node addresses and point of attachment addresses are location-dependent. Of course the problem with this characterization is what the heck does location-dependent mean in an arbitrary graph. Over time, I have come to the conclusion that it translates to topologically dependent, but I do mean *topological* and not graph. This field tends to abuse the word topology because it sounds so much more intelligent. Upon reflection, one realizes that application names are topologically dependent as well, just in a very different topology. In fact, virtually all identifiers in computer science are used to "locate" things in some sense. We really have very little use for names. Some but not much. Take care, John From mycroft at netbsd.org Tue Apr 18 11:51:16 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Tue, 18 Apr 2006 14:51:16 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <44451885.5090902@web.de> References: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> <44451885.5090902@web.de> Message-ID: <20060418185116.GF27689@multics.mit.edu> On Tue, Apr 18, 2006 at 06:49:09PM +0200, Detlef Bosau wrote: > In principle, you can interconnect all computers in the world via a flat > Ethernet. (Define a "DS-Ethernet" := Deep Sea Ethernet for > intercontinental lines if necessary.) Actually, even 1000 nodes on a single Ethernet starts to get problematic in practice -- even in a star topology (where you don't necessarily have collision problems), you get nailed by ARP probes pretty quickly. > How large will the switching tables be? But it's true that routing/switching tables are also a problem. From puddinghead_wilson007 at yahoo.co.uk Mon Apr 17 08:15:37 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Mon, 17 Apr 2006 16:15:37 +0100 (BST) Subject: [e2e] use of MAC addresses In-Reply-To: <443EDA93.7010600@web.de> Message-ID: <20060417151537.89294.qmail@web25405.mail.ukl.yahoo.com> --- Detlef Bosau wrote: > Puddinhead Wilson wrote: > > The local attachment identifer when I am on a > > wireless, could be anything, including a name, and > > that could be "my identity, my cell number, my > postal > > address" > > > > Of course. And it even may be the burned in hardware > address, every > wireless unit is shipped with. Yes so why not carry out all transcations using that address? ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From fred at cisco.com Mon Apr 17 19:25:44 2006 From: fred at cisco.com (Fred Baker) Date: Mon, 17 Apr 2006 22:25:44 -0400 Subject: [e2e] admission control vs congestion control In-Reply-To: References: Message-ID: To be very honest, it is because people don't think objectively. Objectively, TCP-like approaches work well for TCP-like traffic, which is to say traffic that will adjust itself to available bandwidth, and people are familiar with this model. However, real- time streams (which include voice, video, and telemetry applications) send data at a fixed rate or within a fixed range, and as a result has limited ability if any to adapt to competing traffic or available capacity. As you say, if you really want to control real-time traffic congestion in a world of finite bandwidth - however large that bandwidth might be - admission at bottlenecks becomes critical. It turns out that there are requirements also that networks be able to make decisions according to a stated policy. Policies being discussed today include such questions as "is there enough bandwidth", "is this guy my subscriber", "is this a subscriber with a special contract that lets him in when others aren't allowed in", and "is this a subscriber with a very extremely special contract that calls for me to push someone else out to let him in?". In that last case, "and whom do I push out, how do I push out only the ones I need to, and how do I tell them I have decided to do so" becomes pretty important. TCP-like approaches provide no such possibility. There is the ECN thing being proposed by BT and Nortel in the IETF. There are a number of interesting assumptions built into that along these lines: that new calls come in at a rate less than some threshold, above which matters become far less deterministic, that the probe traffic is not seen as competition to existing calls to a sufficient extent that existing calls come down, and that edge systems cooperate with the network in certain ways. Network operators of my acquaintance don't trust the edge... The usual reason given for avoiding admission models is that people don't want to build large amounts of state into the network. Having said that, network operators then build MPLS or other circuit-switch infrastructures, and perhaps engineer those routes to maximize the traffic they can send over them or to maximize their ability to recover cleanly from failures. This involves a *lot* of state in the network, much more than bandwidth admission techniques call for. People avoid bandwidth admission techniques, and love to hate them, because they don't think objectively. If they thought objectively, they would find they were the simplest approach to the problem, involve the least state, the least heuristics, and where heuristics are required, the most predictable ones. I, of course, have no opinion :-) On Apr 15, 2006, at 2:10 PM, Lisong Xu wrote: > Hi everybody, > > Both congestion control-based and admission control-based > approaches were proposed for multimedia streaming over the Internet > a few years ago. Intuitively, admission control is more suitable > for multimedia streaming than congestion control, since admission > control can provide some guaranteed bandwidth. > > However, it seems that congestion control-based approaches are > accepted by more people. I am wondering what the fundamental reason > is. Is it because congestion control-based approaches are tcp- > friendly, and then safer to implement in the Internet? > > Thanks in advance! > Lisong From puddinghead_wilson007 at yahoo.co.uk Tue Apr 18 00:48:37 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Tue, 18 Apr 2006 08:48:37 +0100 (BST) Subject: [e2e] use of MAC addresses In-Reply-To: <4443C693.5090503@web.de> Message-ID: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> Scale up for what? Reachability and switching methods and end point identifiers are all different topics. --- Detlef Bosau wrote: > Puddinhead Wilson wrote: > > --- Detlef Bosau wrote: > > > > > > > > > Yes so why not carry out all transcations using > that address? > > IIRC, Joe discussed this before. > > The routing algorithms simply do not scale up to > millions of nodes when > you use a "flat" address room. > > Detlef > > -- > Detlef Bosau > Galileistrasse 30 > 70565 Stuttgart > Mail: detlef.bosau at web.de > Web: http://www.detlef-bosau.de > Mobile: +49 172 681 9937 > > Send instant messages to your online friends http://uk.messenger.yahoo.com From lisongxu2 at gmail.com Tue Apr 18 08:22:28 2006 From: lisongxu2 at gmail.com (Lisong Xu) Date: Tue, 18 Apr 2006 10:22:28 -0500 Subject: [e2e] admission control vs congestion control In-Reply-To: References: Message-ID: On 4/17/06, Fred Baker wrote: > The usual reason given for avoiding admission models is that people > don't want to build large amounts of state into the network. Having > said that, network operators then build MPLS or other circuit-switch > infrastructures, and perhaps engineer those routes to maximize the > traffic they can send over them or to maximize their ability to > recover cleanly from failures. This involves a *lot* of state in the > network, much more than bandwidth admission techniques call for. I agree with you that "people don't want to build large amounts of state into the network." But there are also admission control methods that do not build any state into the network, such as probing-based methods. Why these methods have not been widely accepted and implemented? I guess the tcp friendliness is one of the reasons, are there any other fundamental reasons? Thanks Lisong From fred at cisco.com Tue Apr 18 08:33:51 2006 From: fred at cisco.com (Fred Baker) Date: Tue, 18 Apr 2006 11:33:51 -0400 Subject: [e2e] admission control vs congestion control In-Reply-To: <4444144B.7000507@web.de> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> Message-ID: <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> On Apr 17, 2006, at 6:18 PM, Detlef Bosau wrote: > Excuse me: What?s the very difference between these mechanisms and > good ol? TDM as it is used in line switched networks with excellent > results for decacdes now? simple. TDM is not statistical; these are. In other words, if you allocate mumble percent of a link for video, and have several video streams using the capacity, in a TDM world the bits arrive in an orderly fashion and get clocked out the other side. The only "congestion" is that you might use up the capacity you have allocated. In the Internet, each video stream might, under certain circumstances, have the first packet of its frame arrive simultaneously, building up a queue. Without admission control, it is possible to get more data streams (and therefore more offered load) than you have engineered capacity for. The result is not that the new video stream is dropped; it is that all of them are compromised until some of them (in no particular order) have their users give up on them. That is essentially a useless service. With admission control, you only allow sessions to use capacity while there is more capacity to use. All of the sessions get decent quality without a lot of histrionics. If I have to use TDM to get decent video, we have all failed, haven't we? From fred at cisco.com Tue Apr 18 08:42:19 2006 From: fred at cisco.com (Fred Baker) Date: Tue, 18 Apr 2006 11:42:19 -0400 Subject: [e2e] admission control vs congestion control In-Reply-To: References: Message-ID: <59F13E9A-1A8F-4309-B1C4-A868CAF16621@cisco.com> On Apr 18, 2006, at 11:22 AM, Lisong Xu wrote: > But there are also admission control methods that do not build any > state into the network, such as probing-based methods. Why these > methods have not been widely accepted and implemented? Because they don't actually work very well. They have been studied to death and variously reported on. Let me give you a simple example. MPEG-4 is a variable-rate-within- boundaries codec. It might send 80 KBPS when the camera is pointed at a blank wall, and 800 KBPS if the camera is pointed at the ocean. IT won't ever send less than the 80 KBPS, and it won't send more than the 800, but typically it is somewhere in between. Let's suppose that there are right now five MPEG-4 streams using a certain bit of capacity, and that capacity is enough for them to all go all out. But right now, what they are each showing is a green field with a few bits of color moving around as players bounce whatever kind of ball or frisbee their game requires. They are each averaging, let's say, 200 KBPS. Sixty seconds from now, they are each going to cut to commercials, with lots of motion on the screen and therefore a high bit rate. If I probe right now, my probe will say that there is no problem. But should I then start streaming my favorite video stream, sixty seconds from now the whole place is going to come down around my ears - and the ears of the five data streams I am competing with. As stock brokers are reported to comment: Past performance is no guarantee of future performance. It is at best a heuristic. From hgs at cs.columbia.edu Tue Apr 18 13:52:15 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Tue, 18 Apr 2006 16:52:15 -0400 Subject: [e2e] admission control vs congestion control In-Reply-To: References: Message-ID: <4445517F.1070706@cs.columbia.edu> - Delay until admission decision makes many such techniques unsuitable for applications where humans are waiting ("post-dial delay") - Overhead of probing, particularly if the probe has to be repeated after a failure - Guarantees tend to be weak, i.e., you may get a positive answer and still suffer packet loss, particularly if the number of flows is small and flows are bursty or on-off (such as voice) if the probe gets "lucky" > I agree with you that "people don't want to build large amounts of > state into the network." But there are also admission control methods > that do not build any state into the network, such as probing-based > methods. Why these methods have not been widely accepted and > implemented? I guess the tcp friendliness is one of the reasons, are > there any other fundamental reasons? > > Thanks > Lisong From zartash at lums.edu.pk Tue Apr 18 14:19:26 2006 From: zartash at lums.edu.pk (Zartash Afzal Uzmi) Date: Wed, 19 Apr 2006 02:19:26 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <44451885.5090902@web.de> Message-ID: Detlef Bosau wrote: > ... > In principle, you can interconnect all computers in the world via a flat > Ethernet. (Define a "DS-Ethernet" := Deep Sea Ethernet for > intercontinental lines if necessary.) > > How large will the switching tables be? > > Can we extend this until the switching tables grow beyond all limits? > And so does the processing time on routers? > If we do consider a "DS-Ethernet", switching tables (whatever they mean) will explode and processing times will be too long. However, this was not the intent of the original post. I see some people in the discussion are still concerned about table entries and scalability. Let me try to phrase the original question, in an attempt to bring more clarity: Consider a node that uses two identifiers: an ethernet address (call it E) and an IPv4 address (call it I). Theoretically, do we need two separate identifiers? In other words, can these two identifiers I and E be equal? Please note that this does not mean that any change is proposed to the way forwarding is done in either LAN or WAN. Lets assume we have one single identifier (let me call it X). Now, LAN devices have exactly the same forwarding tables as before (when we were using two identifiers E and I) except that E is replaced by X. Similarly, WAN devices (routers) also do not have anything different from the previous case (when two separate identifiers were used) except that I is replaced by X in all the table entries. Absolutely, no change in table size! This is possible, at least in theory. First we assume that each node somehow knows (or gets) its IP address which is nothing more than a sequence of bits. Then the network card is made to use the same identifier as the ethernet address. While this seems theoretically possible, one real "technical" issue would be how a node will get the IP address in the first place? For DHCP to work as it does today, one has to has an ethernet address a priori. If everyone harcodes the IP (again, only a theoretical whim), we are okay and can use same identifier as the ethernet address too; otherwise we may use some other mechanism to first acquire IP address (without having an ethernet address). The issue of initial acquisition of IP address has been pointed out by some people (refer to the emails by Joe and Craig, specifically). Is inital acquisition of IP address the only issue? I am not sure but I find no other "theoretical" reason in the discussion so far. Well, with the frequency of posts on this topic, other reasons may have appeared on the list while I wrote this email :) But obviously, two unique identifiers, ethernet and IP, work. There does not seem any apparent practical reason one should use the same identifier for both just for the sake of saving some identifiers that will not be used anyways! Regards, Zartash From dpreed at reed.com Tue Apr 18 14:26:16 2006 From: dpreed at reed.com (David P. Reed) Date: Tue, 18 Apr 2006 17:26:16 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: References: <200604181658.JAA03622@gra.isi.edu> Message-ID: <44455978.6060307@reed.com> John Day wrote: > I have always thought it peculiar that MAC addresses had a larger > address space than IP addresses. Yup, we have always known that IP address space was too small to be correct. To be specific, we includes, without being limited to, Xerox PARC and the Saltzer, Clark, Reed group at MIT. > This confusion of IEEE 802 universal serial numbers with addresses > always seemed a little strange to me. This goes back to Xerox PARC, whose researchers recognized the very low cost and very high value of guaranteed unique identifiers as the base name space for networking, given the fact that networks are transient collections of devices, so binding naming to the particular topology merely made the system architecture more complex than necessary. A simple way to realized that this is not strange is that the integers are the same mathematical objects, no matter whether you choose to represent them in decimal, hex or floating point ternary. Same with endpoints. They are the same no matter what network they are temporarily attached to. Only people who thought that the wires and topology are more conceptually important than the endpoints would have decided that mobility was of such little importance that they would bind addressing to topological happenstance. In other words, in IP, the "routerheads" won - rather than the "internetworkers". 48-bits was chosen by the Xerox-DEC-Intel group as a compromise. Most of us researchers were convinced that 64 bits would have been more easily allocated. From day at std.com Tue Apr 18 14:38:55 2006 From: day at std.com (John Day) Date: Tue, 18 Apr 2006 17:38:55 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <44455978.6060307@reed.com> References: <200604181658.JAA03622@gra.isi.edu> <44455978.6060307@reed.com> Message-ID: You know Dave, you really should get better at noticing when one's tongue is in one's cheek. ;-) At 17:26 -0400 2006/04/18, David P. Reed wrote: >John Day wrote: >>I have always thought it peculiar that MAC addresses had a larger >>address space than IP addresses. >Yup, we have always known that IP address space was too small to be >correct. To be specific, we includes, without being limited to, >Xerox PARC and the Saltzer, Clark, Reed group at MIT. >>This confusion of IEEE 802 universal serial numbers with addresses >>always seemed a little strange to me. >This goes back to Xerox PARC, whose researchers recognized the very >low cost and very high value of guaranteed unique identifiers as the >base name space for networking, given the fact that networks are >transient collections of devices, so binding naming to the >particular topology merely made the system architecture more complex >than necessary. > >A simple way to realized that this is not strange is that the >integers are the same mathematical objects, no matter whether you >choose to represent them in decimal, hex or floating point ternary. >Same with endpoints. They are the same no matter what network they >are temporarily attached to. > >Only people who thought that the wires and topology are more >conceptually important than the endpoints would have decided that >mobility was of such little importance that they would bind >addressing to topological happenstance. In other words, in IP, the >"routerheads" won - rather than the "internetworkers". > > >48-bits was chosen by the Xerox-DEC-Intel group as a compromise. >Most of us researchers were convinced that 64 bits would have been >more easily allocated. From jjackson at billyjoe.canc.com Tue Apr 18 15:20:31 2006 From: jjackson at billyjoe.canc.com (jjackson@billyjoe.canc.com) Date: Tue, 18 Apr 2006 17:20:31 -0500 Subject: [e2e] admission control vs congestion control In-Reply-To: References: Message-ID: <20060418222031.GA26089@billyjoe.canc.com> I'm probably stating the obvious, but from a service provider perspective it is much easier to keep throwing bandwidth at the problem. In my experience, the only use of MPLS-TE is MPLS-FRR using loose paths and DiffServ in the forwarding plane. There are now some IETF drafts for IP-FRR w/o MPLS. James On Tue, Apr 18, 2006 at 10:22:28AM -0500, Lisong Xu wrote: > On 4/17/06, Fred Baker wrote: > > The usual reason given for avoiding admission models is that people > > don't want to build large amounts of state into the network. Having > > said that, network operators then build MPLS or other circuit-switch > > infrastructures, and perhaps engineer those routes to maximize the > > traffic they can send over them or to maximize their ability to > > recover cleanly from failures. This involves a *lot* of state in the > > network, much more than bandwidth admission techniques call for. > > I agree with you that "people don't want to build large amounts of > state into the network." But there are also admission control methods > that do not build any state into the network, such as probing-based > methods. Why these methods have not been widely accepted and > implemented? I guess the tcp friendliness is one of the reasons, are > there any other fundamental reasons? > > Thanks > Lisong From dmchiu at ie.cuhk.edu.hk Tue Apr 18 20:00:37 2006 From: dmchiu at ie.cuhk.edu.hk (Dah Ming Chiu) Date: Wed, 19 Apr 2006 11:00:37 +0800 Subject: [e2e] admission control vs congestion control References: <4445517F.1070706@cs.columbia.edu> Message-ID: <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> How about a "quick-brobing delayed blocking" approach? In other words, you only probe for tolerable "post-dial delay" and admit if okay or uncertain. When things get bad, the call may be dropped in the middle. Hopefully with sufficient over-provisioning, the "delayed blocking" happens very rarely. This may be what is already "implemented" in the sense that the "quick probing" part is "no probing" and the "delayed blocking" part is done by the human user. Dah Ming ----- Original Message ----- From: "Henning Schulzrinne" To: "Lisong Xu" Cc: "Fred Baker" ; Sent: Wednesday, April 19, 2006 4:52 AM Subject: Re: [e2e] admission control vs congestion control >- Delay until admission decision makes many such techniques unsuitable > for applications where humans are waiting ("post-dial delay") > - Overhead of probing, particularly if the probe has to be repeated > after a failure > - Guarantees tend to be weak, i.e., you may get a positive answer and > still suffer packet loss, particularly if the number of flows is small > and flows are bursty or on-off (such as voice) if the probe gets "lucky" > >> I agree with you that "people don't want to build large amounts of >> state into the network." But there are also admission control methods >> that do not build any state into the network, such as probing-based >> methods. Why these methods have not been widely accepted and >> implemented? I guess the tcp friendliness is one of the reasons, are >> there any other fundamental reasons? >> >> Thanks >> Lisong > From fred at cisco.com Wed Apr 19 04:23:41 2006 From: fred at cisco.com (Fred Baker) Date: Wed, 19 Apr 2006 07:23:41 -0400 Subject: [e2e] admission control vs congestion control In-Reply-To: <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> References: <4445517F.1070706@cs.columbia.edu> <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> Message-ID: Would you find that acceptable as a service? Would you pay for it? Or would you say "this crappy service is unreliable; I would rather go to the corner store and rent the movie than wonder whether the rental from my ISP is going to actually stay up or maybe have little squares all over it half the time"? On Apr 18, 2006, at 11:00 PM, Dah Ming Chiu wrote: > How about a "quick-brobing delayed blocking" approach? > In other words, you only probe for tolerable "post-dial delay" and > admit if okay or uncertain. When things get bad, the call may be > dropped in the middle. Hopefully with sufficient over-provisioning, > the "delayed blocking" happens very rarely. This may be what is > already "implemented" in the sense that the "quick probing" part is > "no > probing" and the "delayed blocking" part is done by the human user. > > Dah Ming > > ----- Original Message ----- From: "Henning Schulzrinne" > > To: "Lisong Xu" > Cc: "Fred Baker" ; > Sent: Wednesday, April 19, 2006 4:52 AM > Subject: Re: [e2e] admission control vs congestion control > > >> - Delay until admission decision makes many such techniques >> unsuitable for applications where humans are waiting ("post-dial >> delay") >> - Overhead of probing, particularly if the probe has to be >> repeated after a failure >> - Guarantees tend to be weak, i.e., you may get a positive answer >> and still suffer packet loss, particularly if the number of flows >> is small and flows are bursty or on-off (such as voice) if the >> probe gets "lucky" >>> I agree with you that "people don't want to build large amounts of >>> state into the network." But there are also admission control >>> methods >>> that do not build any state into the network, such as probing-based >>> methods. Why these methods have not been widely accepted and >>> implemented? I guess the tcp friendliness is one of the reasons, are >>> there any other fundamental reasons? >>> Thanks >>> Lisong >> From lisongxu2 at gmail.com Wed Apr 19 07:25:50 2006 From: lisongxu2 at gmail.com (Lisong Xu) Date: Wed, 19 Apr 2006 09:25:50 -0500 Subject: [e2e] admission control vs congestion control In-Reply-To: References: <4445517F.1070706@cs.columbia.edu> <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> Message-ID: You are right that no one would pay for it. But if it is free, I guess it is still very attractive compared to the current best-effort service. Lisong On 4/19/06, Fred Baker wrote: > Would you find that acceptable as a service? Would you pay for it? Or > would you say "this crappy service is unreliable; I would rather go > to the corner store and rent the movie than wonder whether the rental > from my ISP is going to actually stay up or maybe have little squares > all over it half the time"? > > On Apr 18, 2006, at 11:00 PM, Dah Ming Chiu wrote: > > > How about a "quick-brobing delayed blocking" approach? > > In other words, you only probe for tolerable "post-dial delay" and > > admit if okay or uncertain. When things get bad, the call may be > > dropped in the middle. Hopefully with sufficient over-provisioning, > > the "delayed blocking" happens very rarely. This may be what is > > already "implemented" in the sense that the "quick probing" part is > > "no > > probing" and the "delayed blocking" part is done by the human user. > > > > Dah Ming > > > > ----- Original Message ----- From: "Henning Schulzrinne" > > > > To: "Lisong Xu" > > Cc: "Fred Baker" ; > > Sent: Wednesday, April 19, 2006 4:52 AM > > Subject: Re: [e2e] admission control vs congestion control > > > > > >> - Delay until admission decision makes many such techniques > >> unsuitable for applications where humans are waiting ("post-dial > >> delay") > >> - Overhead of probing, particularly if the probe has to be > >> repeated after a failure > >> - Guarantees tend to be weak, i.e., you may get a positive answer > >> and still suffer packet loss, particularly if the number of flows > >> is small and flows are bursty or on-off (such as voice) if the > >> probe gets "lucky" > >>> I agree with you that "people don't want to build large amounts of > >>> state into the network." But there are also admission control > >>> methods > >>> that do not build any state into the network, such as probing-based > >>> methods. Why these methods have not been widely accepted and > >>> implemented? I guess the tcp friendliness is one of the reasons, are > >>> there any other fundamental reasons? > >>> Thanks > >>> Lisong > >> > From detlef.bosau at web.de Wed Apr 19 09:07:14 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 19 Apr 2006 18:07:14 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <20060418185116.GF27689@multics.mit.edu> References: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> <44451885.5090902@web.de> <20060418185116.GF27689@multics.mit.edu> Message-ID: <44466032.7000408@web.de> Charles M. Hannum wrote: > Actually, even 1000 nodes on a single Ethernet starts to get problematic > in practice -- even in a star topology (where you don't necessarily have > collision problems), you get nailed by ARP probes pretty quickly. Hm. May I play the advocatus diaboly here? If we only use Ethernet addresses and no IP - where are the ARP probes then? ;-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mycroft at netbsd.org Wed Apr 19 11:05:42 2006 From: mycroft at netbsd.org (Charles M. Hannum) Date: Wed, 19 Apr 2006 14:05:42 -0400 Subject: [e2e] use of MAC addresses Message-ID: <20060419180542.GC17674@multics.mit.edu> On Wed, Apr 19, 2006 at 06:07:14PM +0200, Detlef Bosau wrote: > Charles M. Hannum wrote: > > >Actually, even 1000 nodes on a single Ethernet starts to get problematic > >in practice -- even in a star topology (where you don't necessarily have > >collision problems), you get nailed by ARP probes pretty quickly. > > Hm. May I play the advocatus diaboly here? > > If we only use Ethernet addresses and no IP - where are the ARP probes > then? ;-) Sure. Still, I'd like to see how long it takes spanning tree to converge -- or if it ever does. From Mario.Holbe at TU-Ilmenau.DE Wed Apr 19 12:08:46 2006 From: Mario.Holbe at TU-Ilmenau.DE (Mario 'BitKoenig' Holbe) Date: Wed, 19 Apr 2006 21:08:46 +0200 Subject: [e2e] use of MAC addresses In-Reply-To: <44466032.7000408@web.de> References: <20060418074838.72314.qmail@web25413.mail.ukl.yahoo.com> <44451885.5090902@web.de> <20060418185116.GF27689@multics.mit.edu> <44466032.7000408@web.de> Message-ID: <20060419190846.GM31637@darkside.22.kls.lan> On Wed, Apr 19, 2006 at 06:07:14PM +0200, Detlef Bosau wrote: > If we only use Ethernet addresses and no IP - where are the ARP probes > then? ;-) Well, you could use the resources freed due to the unnecessarity of ARP for establishing RRP (Route Resolution Protocol) then :) Mario -- talk softly and carry a keen sword -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: Digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060419/17882d73/attachment.bin From zartash at lums.edu.pk Wed Apr 19 14:00:02 2006 From: zartash at lums.edu.pk (Zartash Afzal Uzmi) Date: Thu, 20 Apr 2006 02:00:02 +0500 Subject: [e2e] use of MAC addresses In-Reply-To: <20060419180542.GC17674@multics.mit.edu> Message-ID: Charles M. Hannum wrote: > > On Wed, Apr 19, 2006 at 06:07:14PM +0200, Detlef Bosau wrote: > > Charles M. Hannum wrote: > > > > >Actually, even 1000 nodes on a single Ethernet starts to get > problematic > > >in practice -- even in a star topology (where you don't > necessarily have > > >collision problems), you get nailed by ARP probes pretty quickly. > > > > Hm. May I play the advocatus diaboly here? > > > > If we only use Ethernet addresses and no IP - where are the ARP probes > > then? ;-) > > Sure. Still, I'd like to see how long it takes spanning tree to > converge -- or if it ever does. > Assuming that we are still talking about single identifier for IP and MAC, why does it affect the working of spanning tree at all? The spanning tree algorithm does not care whether an end station has two different identifiers (IP and MAC different) or just one identifier (IP=MAC). In fact, the STA does not care whether there are any end stations at all! From dmchiu at ie.cuhk.edu.hk Wed Apr 19 18:51:34 2006 From: dmchiu at ie.cuhk.edu.hk (Dah Ming Chiu) Date: Thu, 20 Apr 2006 09:51:34 +0800 Subject: [e2e] admission control vs congestion control References: <4445517F.1070706@cs.columbia.edu> <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> Message-ID: <007001c6641c$f7a5add0$db60bd89@iepclan.ie.cuhk.edu.hk> You can think of both congestion control and admission control as traffic controls used to allocate resources to flows. Furthermore, these traffic controls may need to co-exist in the same network, allocating the same set of resources together somehow. Maybe if you pre-supposed that these two mechanisms are to deal with separate pools of resources, then they would not be related. Regards Dah Ming ----- Original Message ----- From: "Fahad Dogar" To: "Lisong Xu" Cc: "Fred Baker" ; ; "Dah Ming Chiu" Sent: Thursday, April 20, 2006 2:29 AM Subject: Re: [e2e] admission control vs congestion control >I can understand the need for admission control and how it can result > in some QoS guarantees for applications. However, I fail to understand > the relationship between congestion control mechanisms (employed by > TCP) and QoS for multimedia applications. Can anyone clarify? > > Regards, > Fahad > > > > On 4/19/06, Lisong Xu wrote: >> You are right that no one would pay for it. But if it is free, I guess >> it is still very attractive compared to the current best-effort >> service. >> Lisong >> >> On 4/19/06, Fred Baker wrote: >> > Would you find that acceptable as a service? Would you pay for it? Or >> > would you say "this crappy service is unreliable; I would rather go >> > to the corner store and rent the movie than wonder whether the rental >> > from my ISP is going to actually stay up or maybe have little squares >> > all over it half the time"? >> > >> > On Apr 18, 2006, at 11:00 PM, Dah Ming Chiu wrote: >> > >> > > How about a "quick-brobing delayed blocking" approach? >> > > In other words, you only probe for tolerable "post-dial delay" and >> > > admit if okay or uncertain. When things get bad, the call may be >> > > dropped in the middle. Hopefully with sufficient over-provisioning, >> > > the "delayed blocking" happens very rarely. This may be what is >> > > already "implemented" in the sense that the "quick probing" part is >> > > "no >> > > probing" and the "delayed blocking" part is done by the human user. >> > > >> > > Dah Ming >> > > >> > > ----- Original Message ----- From: "Henning Schulzrinne" >> > > >> > > To: "Lisong Xu" >> > > Cc: "Fred Baker" ; >> > > Sent: Wednesday, April 19, 2006 4:52 AM >> > > Subject: Re: [e2e] admission control vs congestion control >> > > >> > > >> > >> - Delay until admission decision makes many such techniques >> > >> unsuitable for applications where humans are waiting ("post-dial >> > >> delay") >> > >> - Overhead of probing, particularly if the probe has to be >> > >> repeated after a failure >> > >> - Guarantees tend to be weak, i.e., you may get a positive answer >> > >> and still suffer packet loss, particularly if the number of flows >> > >> is small and flows are bursty or on-off (such as voice) if the >> > >> probe gets "lucky" >> > >>> I agree with you that "people don't want to build large amounts of >> > >>> state into the network." But there are also admission control >> > >>> methods >> > >>> that do not build any state into the network, such as probing-based >> > >>> methods. Why these methods have not been widely accepted and >> > >>> implemented? I guess the tcp friendliness is one of the reasons, >> > >>> are >> > >>> there any other fundamental reasons? >> > >>> Thanks >> > >>> Lisong >> > >> >> > >> From Mikael.Latvala at nokia.com Thu Apr 20 04:04:28 2006 From: Mikael.Latvala at nokia.com (Mikael.Latvala@nokia.com) Date: Thu, 20 Apr 2006 14:04:28 +0300 Subject: [e2e] use of MAC addresses In-Reply-To: <44455978.6060307@reed.com> Message-ID: <326A98184EC61140A2569345DB3614C102C74B97@esebe105.NOE.Nokia.com> At least when looking at the public OUI listing (http://standards.ieee.org/regauth/oui/oui.txt) one could come to a conclusion that there is no need to start working on MACv2 in the near future. But then again this kind of a statement could be on par with "64KB should be enough" declaration. Has anybody seen a better estimate on the consumption of MAC addresses? /Mikael > >48-bits was chosen by the Xerox-DEC-Intel group as a >compromise. Most of us researchers were convinced that 64 >bits would have been more easily allocated. > > From day at std.com Thu Apr 20 06:08:10 2006 From: day at std.com (John Day) Date: Thu, 20 Apr 2006 09:08:10 -0400 Subject: [e2e] use of MAC addresses In-Reply-To: <326A98184EC61140A2569345DB3614C102C74B97@esebe105.NOE.Nokia.com> References: <326A98184EC61140A2569345DB3614C102C74B97@esebe105.NOE.Nokia.com> Message-ID: At 14:04 +0300 2006/04/20, wrote: >At least when looking at the public OUI listing >(http://standards.ieee.org/regauth/oui/oui.txt) one could come to a >conclusion that there is no need to start working on MACv2 in the near >future. But then again this kind of a statement could be on par with >"64KB should be enough" declaration. > >Has anybody seen a better estimate on the consumption of MAC addresses? As far as addressing is concerned, you can't run out of MAC addresses because they only need to be unambiguous within the scope of the layer in which they are used, i.e. LAN segment. Now MAC addresses as serial numbers is a different story. Take care, John From fahad.dogar at gmail.com Wed Apr 19 11:29:11 2006 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Wed, 19 Apr 2006 23:29:11 +0500 Subject: [e2e] admission control vs congestion control In-Reply-To: References: <4445517F.1070706@cs.columbia.edu> <0a9d01c6635d$72c85dc0$db60bd89@iepclan.ie.cuhk.edu.hk> Message-ID: I can understand the need for admission control and how it can result in some QoS guarantees for applications. However, I fail to understand the relationship between congestion control mechanisms (employed by TCP) and QoS for multimedia applications. Can anyone clarify? Regards, Fahad On 4/19/06, Lisong Xu wrote: > You are right that no one would pay for it. But if it is free, I guess > it is still very attractive compared to the current best-effort > service. > Lisong > > On 4/19/06, Fred Baker wrote: > > Would you find that acceptable as a service? Would you pay for it? Or > > would you say "this crappy service is unreliable; I would rather go > > to the corner store and rent the movie than wonder whether the rental > > from my ISP is going to actually stay up or maybe have little squares > > all over it half the time"? > > > > On Apr 18, 2006, at 11:00 PM, Dah Ming Chiu wrote: > > > > > How about a "quick-brobing delayed blocking" approach? > > > In other words, you only probe for tolerable "post-dial delay" and > > > admit if okay or uncertain. When things get bad, the call may be > > > dropped in the middle. Hopefully with sufficient over-provisioning, > > > the "delayed blocking" happens very rarely. This may be what is > > > already "implemented" in the sense that the "quick probing" part is > > > "no > > > probing" and the "delayed blocking" part is done by the human user. > > > > > > Dah Ming > > > > > > ----- Original Message ----- From: "Henning Schulzrinne" > > > > > > To: "Lisong Xu" > > > Cc: "Fred Baker" ; > > > Sent: Wednesday, April 19, 2006 4:52 AM > > > Subject: Re: [e2e] admission control vs congestion control > > > > > > > > >> - Delay until admission decision makes many such techniques > > >> unsuitable for applications where humans are waiting ("post-dial > > >> delay") > > >> - Overhead of probing, particularly if the probe has to be > > >> repeated after a failure > > >> - Guarantees tend to be weak, i.e., you may get a positive answer > > >> and still suffer packet loss, particularly if the number of flows > > >> is small and flows are bursty or on-off (such as voice) if the > > >> probe gets "lucky" > > >>> I agree with you that "people don't want to build large amounts of > > >>> state into the network." But there are also admission control > > >>> methods > > >>> that do not build any state into the network, such as probing-based > > >>> methods. Why these methods have not been widely accepted and > > >>> implemented? I guess the tcp friendliness is one of the reasons, are > > >>> there any other fundamental reasons? > > >>> Thanks > > >>> Lisong > > >> > > > From the_lord_of_the_hosts at yahoo.com Thu Apr 20 07:36:42 2006 From: the_lord_of_the_hosts at yahoo.com (Tom Bombadil) Date: Thu, 20 Apr 2006 07:36:42 -0700 (PDT) Subject: [e2e] NETLeMMings I-D Message-ID: <20060420143642.43790.qmail@web38312.mail.mud.yahoo.com> I'd like to call your attention to the following I-D. http://www.ietf.org/internet-drafts/draft-bombadil-netlemmings-00.txt It celebrates the oft forgotten wonder of the end-to-end principle, and satirically comments on current happenings in the Internet Area concerning Mobility which contradict some of the very principles that make the Internet what we know and, in my case, greatly care for. Regards, Tom --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060420/dcc430b6/attachment.html From detlef.bosau at web.de Fri Apr 21 09:20:40 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 21 Apr 2006 18:20:40 +0200 Subject: [e2e] admission control vs congestion control In-Reply-To: <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> Message-ID: <44490658.1050509@web.de> Fred Baker wrote: > > On Apr 17, 2006, at 6:18 PM, Detlef Bosau wrote: > >> Excuse me: What?s the very difference between these mechanisms and >> good ol? TDM as it is used in line switched networks with excellent >> results for decacdes now? > > > simple. TDM is not statistical; these are. > > In other words, if you allocate mumble percent of a link for video, > and have several video streams using the capacity, in a TDM world the > bits arrive in an orderly fashion and get clocked out the other side. > The only "congestion" is that you might use up the capacity you have > allocated. In the Internet, each video stream might, under certain > circumstances, have the first packet of its frame arrive > simultaneously, building up a queue. O.k., this is the particular story with speech compression etc. There _are_ scenarios where this approach makes sense (and is thus conducted for some years now.) In addition, media streams will typically remain quite time sensitive and you will have to provide appropriate switching mechanims. What I?ve seen als "multimedia over the Internet" so far is not convincing. And this is not surprising as I do not see a real chance to have multimedia work in a best effort network. You talk about decent video. Is this "decent"? You surely don?t talk about these funny webcam pictures and this stuff. This is not "decent". This is ridiculous. There was a certain multimedia over IP hype in the 90s. Thank?s god, it?s over now. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri Apr 21 15:23:48 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 22 Apr 2006 00:23:48 +0200 Subject: [e2e] admission control vs congestion control In-Reply-To: <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> <44490658.1050509@web.de> <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> Message-ID: <44495B74.4000209@web.de> Fred Baker wrote: > For the record, there are products out there that are indeed > delivering video on IP. My company has a couple, so do many others. Yes. I noticed your e-mail domain :-) And I see, that there _are_ scenarios where multimedia over IP does make sense. However, I don?t see those scenarios in "The Internet". > You are correct that it requires steps to be taken to ensure that > delivery is consistent. > > One of our ISP friends on this list commented that the right solution > is to make sure that the problem is swamped with bandwidth. That would > be my preferred solution as well if infinite bandwidth were available > for free regardless of location. And I think, it?s the general way to go e.g. for VoIP in company networks. However, for the general Internet, when I see RSVP and QoS and all these things, it?s not only that these apply TDM techniques to the Internet. It?s the question how "telco like" the Internet shall be? The more QoS we bring to the Internet the more "telco like" the Internet will become - and the more expensive. Detlef From fred at cisco.com Fri Apr 21 12:58:24 2006 From: fred at cisco.com (Fred Baker) Date: Fri, 21 Apr 2006 12:58:24 -0700 Subject: [e2e] admission control vs congestion control In-Reply-To: <44490658.1050509@web.de> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> <44490658.1050509@web.de> Message-ID: <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> For the record, there are products out there that are indeed delivering video on IP. My company has a couple, so do many others. You are correct that it requires steps to be taken to ensure that delivery is consistent. One of our ISP friends on this list commented that the right solution is to make sure that the problem is swamped with bandwidth. That would be my preferred solution as well if infinite bandwidth were available for free regardless of location. Where cheap bandwidth is in fact available, it is my recommendation. My observation, however, is that many places that worry about QoS do so because bandwidth is not cheap nor necessarily readily available (fiber to the airplane, fiber to the ship at sea, fiber to the atoll..., fiber to the Congo), and even in well-engineered service networks published papers say that there are measurable service bumps that may be correlated with competing data streams that synchronize. On Apr 21, 2006, at 9:20 AM, Detlef Bosau wrote: > Fred Baker wrote: > >> >> On Apr 17, 2006, at 6:18 PM, Detlef Bosau wrote: >> >>> Excuse me: What?s the very difference between these mechanisms >>> and good ol? TDM as it is used in line switched networks with >>> excellent results for decacdes now? >> >> >> simple. TDM is not statistical; these are. >> >> In other words, if you allocate mumble percent of a link for >> video, and have several video streams using the capacity, in a >> TDM world the bits arrive in an orderly fashion and get clocked >> out the other side. The only "congestion" is that you might use >> up the capacity you have allocated. In the Internet, each video >> stream might, under certain circumstances, have the first packet >> of its frame arrive simultaneously, building up a queue. > > O.k., this is the particular story with speech compression etc. > > There _are_ scenarios where this approach makes sense (and is thus > conducted for some years now.) > In addition, media streams will typically remain quite time > sensitive and you will have to provide appropriate switching > mechanims. > > What I?ve seen als "multimedia over the Internet" so far is not > convincing. And this is not surprising as I do not see a real > chance to have multimedia work in a best effort network. > > You talk about decent video. > > Is this "decent"? You surely don?t talk about these funny webcam > pictures and this stuff. This is not "decent". This is ridiculous. > There was a certain multimedia over IP hype in the 90s. > > Thank?s god, it?s over now. > > Detlef > > -- > Detlef Bosau > Galileistrasse 30 > 70565 Stuttgart > Mail: detlef.bosau at web.de > Web: http://www.detlef-bosau.de > Mobile: +49 172 681 9937 From fred at cisco.com Fri Apr 21 15:58:21 2006 From: fred at cisco.com (Fred Baker) Date: Fri, 21 Apr 2006 15:58:21 -0700 Subject: [e2e] admission control vs congestion control In-Reply-To: <44495B74.4000209@web.de> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> <44490658.1050509@web.de> <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> <44495B74.4000209@web.de> Message-ID: <3070223D-A5FE-47C6-84E1-E59142822AA8@cisco.com> On Apr 21, 2006, at 3:23 PM, Detlef Bosau wrote: > However, for the general Internet, when I see RSVP and QoS and all > these things, it?s not only that these apply TDM techniques to the > Internet. It?s the question how "telco like" the Internet shall be? > > The more QoS we bring to the Internet the more "telco like" the > Internet will become - and the more expensive. I'm not so convinced. First, if you're worried about being Telco-like, don't talk to me about a protocol that asks whether there is enough bandwidth available to do the job. Talk to me about the NGN initiative and the deployment of IMS to manage ISPs. There is a *lot* that is happening in the exact direction you are pointing. Second, face facts. The Internet is in fact in the process of becoming the underlying substrate for a variety of communication technologies. We call this "convergence", and where five years ago it might have been a marketing story, it is today a reality - whether that is pleasant or not. It takes less bits per second to deliver voice using TDM than through the Internet from a cost/bit perspective, but that requires one to have two services at the house or office, or in the ISP. If one is sufficient... the sense at the moment is that one is indeed sufficient, hence the entire NGN initiative. The underlying economics of things suggest that we will indeed run voice and video on IP, the only question is when and how. Look at the names of the larger companies that deliver internet services: of the so-called Tier 1 and Tier 2 players, how many do NOT use the word "telecom" in some language somewhere in their name, and of those that don't, how many are not in fact telcos? And look at the services we are being asked for. Precedence in calling, preemption of calls, Lawful Intercept ... I realize that this is not the dream we had 20 years ago. Oh, yes, I realize that. On alternate Tuesdays, I have to at least nod at the existence of the real world... Basically, the question is not whether you would like the companies to be telcos. The question is how to offer the services that people are in fact demanding that the Internet provide to them. And BTW, RSVP is not the same as "being a telco". Since it only has to be implemented at bottlenecks, it becomes a way of applying policy at interconnect points in the cloud and allowing the cloud to do its thing where it is capable of doing so. That is *hugely* different than installing and tearing down circuits. From algold at rnp.br Sun Apr 23 04:21:10 2006 From: algold at rnp.br (Alexandre Grojsgold) Date: Sun, 23 Apr 2006 08:21:10 -0300 Subject: [e2e] admission control vs congestion control In-Reply-To: <3070223D-A5FE-47C6-84E1-E59142822AA8@cisco.com> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> <44490658.1050509@web.de> <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> <44495B74.4000209@web.de> <3070223D-A5FE-47C6-84E1-E59142822AA8@cisco.com> Message-ID: <444B6326.7090307@rnp.br> Fred Baker wrote: > [...] > > I realize that this is not the dream we had 20 years ago. Oh, yes, I > realize that. On alternate Tuesdays, I have to at least nod at the > existence of the real world... Basically, the question is not whether > you would like the companies to be telcos. The question is how to > offer the services that people are in fact demanding that the Internet > provide to them. I think that some care needs to be taken here. We know well that the internet (and telco, and TI) market is largely buzzword driven. From the customer point of view, and from the provider?s as well. People are often pushed to believe they need tnings that prove useless with time. We should also not underestimate the conservativeness of customers. I think that much of what is called "user needs" is in fact no more than a reaction of customers against the new communication pradaigms the Internet propose them, a desesperate attempt to make the new tools behave the way they are used to. An exemple: we see a lot of companies buying VPN when all they needed was N (network). Not totaly useless: at least the telcos make a lot of money selling people an "enhanhed quality" connection that, most of the time, if not all the time, will behave exectly as well as an ordinary Internet connection. I am stiil a believer of the old dream. :-) I admit that there is a "real world", made of people that will not sleep well if they cannot see the circuits in what they sell and buy. This is not a real world to conform to. This a world to change. -- Alexandre. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060423/afd5877f/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Sun Apr 23 04:56:11 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 23 Apr 2006 12:56:11 +0100 Subject: [e2e] admission control vs congestion control Message-ID: congestion control and admission control are just two points on a large spectrum of design space for deferred gratification. whatever you do to control the operating point of a network for users, individually and collectively, you will a) not run a net at 100% b) not let all the users do all they want all the time. 1. call blocking versus rate adaption myth: what you have to ascertain are i) overheads of different mechanisms (reservation, AQM, loss based feedback etc) ii) loss of customer base and customer satisfaction due to either rate limit, or call blocking. it turns out no-one has _ever_ done this in a single public network, so we actually dont know how to trade off users willingness to pay, and users' experience/satisfaction with how long we defer gratification during congested periods, which i define as periods when some users traffic will displace other users traffic, downloads go slower with rate adaption, but realtime services like voice move into a regime of being (nearly or completely) unusuable and are either blocked, or the users try and give up - 2. elestic versus inelestic myth: but are these a simple pair of opposites? no they arent. you cannot tell how _important_ it is that an activity be completed by a certain point in time, whether that activity is to hold a voice conversation, watch a movie, or just to download the train timetable, election result, or some file to execute or print - it isnt _intrinsic in the data, its extrinsic (in the users' requirements). 3. overprovisioning versus user controls myth you can currently overprovision the core, so really we are mainly looking at these mechanisms operating at the edges - so why would you need network admission control at the edge? yo dont (except perhaps in overloaded servers, which _already do it). 4. devil in the details non myth of course, on the congested knee, there _is_ a problem of jitter and loss _today_ in the current internet due to large buffers causing potentially large delay and delay variance which does mean that just before the system starts to displace significant other users traffic, it also has moved the operating point for voice/video to where its unpleasant - but there's a LOT of useful debate right now on smaller buffers and on better edge control mechanisms 5. the problem of adapting multimedia and user satisfaction myth so we spent a long time in 1985-1995 trying to do congestion control for multimedia flows - there's a whole pile of code (and papers) dedicated to adaptive audio and loss toelrant audio (and video) - turns out this is not a good idea according to later papers on user tolerance for adaption. BUT it is a good idea to choose the right codec up front, and _collectively, in aggregate_, this is good enough to survive the knee effect above, but of course, then you are probably super critical in terms of failure if any more load is added. of course, most streaming tools today (and some interactive audio tools) make the initial codec (and parameter) selection pretty well... Putting this all together is quite an intersting challenge, and as time moves on things change - for example, core nets may not be fast enough soon:) then we can have this debate all over again... my three cybercents cheers j. From detlef.bosau at web.de Mon Apr 24 03:31:40 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 24 Apr 2006 12:31:40 +0200 Subject: [e2e] admission control vs congestion control In-Reply-To: <444B6326.7090307@rnp.br> References: <06c301c66241$675e08d0$db60bd89@iepclan.ie.cuhk.edu.hk> <4444144B.7000507@web.de> <58660D24-2722-4D41-8C65-3CA5935E4F4C@cisco.com> <44490658.1050509@web.de> <326DF379-3F7F-42A2-81E2-AE173E40F17A@cisco.com> <44495B74.4000209@web.de> <3070223D-A5FE-47C6-84E1-E59142822AA8@cisco.com> <444B6326.7090307@rnp.br> Message-ID: <444CA90C.7080002@web.de> Alexandre Grojsgold wrote: > > An exemple: we see a lot of companies buying VPN when all they needed > was N (network). Not totaly useless: at least the telcos make a lot of > money selling people an "enhanhed quality" connection that, most of > the time, if not all the time, will behave exectly as well as an > ordinary Internet connection. In fact, the term VPN itself is a buzzword. Nowadays, VPN means nothing else than an IPsec tunnel throughout the Internet which makes a node from outside a network behave and feel like a node inside a network. Some years ago. I found the term VPN used for a number of FR connections offered by some telco in oder to establish a company network connecting different locations. So, the term VPN is somewhat "polymorphic" :-) Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937