From kelsayed at gmail.com Wed May 2 02:19:32 2007 From: kelsayed at gmail.com (Khaled Elsayed) Date: Wed, 02 May 2007 11:19:32 +0200 Subject: [e2e] Packet dropping Message-ID: <463857A4.1020205@gmail.com> Given a per-connection queue that could potentially become full (or in case of RED, hits dropping threshold), an incoming packet arrives and finds the queue full. What would be the best policy: 1) admit the new packet and drop one at the queue front 2) drop the newly arriving packet. For real-time connections, it is intuitive that dropping at queue front would tend to result in better delay responses (this was already shown in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993). What about data/non-real time connections? Assume an FTP or HTTP session subject to above situation, would TCP behave better if packet is dropped from front or the new packet is dropped? I have no evidence but I tend to feel that if the congestion is persistent for some reasonable time, it would make more sense to deliver whatever is in the queue right now and drop the new ones at the expense of increasing overall avg. packet delay. If the congestion duration is small, it would not make a lot of difference (I guess). Any thoughts? Khaled From craig at aland.bbn.com Wed May 2 03:33:08 2007 From: craig at aland.bbn.com (Craig Partridge) Date: Wed, 02 May 2007 06:33:08 -0400 Subject: [e2e] Packet dropping In-Reply-To: Your message of "Wed, 02 May 2007 11:19:32 +0200." <463857A4.1020205@gmail.com> Message-ID: <20070502103308.0E521123842@aland.bbn.com> For non-real time, the answer I believe is drop the new packet. Dropping the earlier packet (assuming the earlier packet has a lower sequence number) is more likely to slow effective delivery of data to the recipient and require a more complex set of retransmissions to recover from. Craig In message <463857A4.1020205 at gmail.com>, Khaled Elsayed writes: >Given a per-connection queue that could potentially become full (or in >case of RED, hits dropping threshold), an incoming packet arrives and >finds the queue full. What would be the best policy: > >1) admit the new packet and drop one at the queue front >2) drop the newly arriving packet. > >For real-time connections, it is intuitive that dropping at queue front >would tend to result in better delay responses (this was already shown >in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993). >What about data/non-real time connections? Assume an FTP or HTTP session >subject to above situation, would TCP behave better if packet is dropped >from front or the new packet is dropped? > >I have no evidence but I tend to feel that if the congestion is >persistent for some reasonable time, it would make more sense to deliver >whatever is in the queue right now and drop the new ones at the expense >of increasing overall avg. packet delay. If the congestion duration is >small, it would not make a lot of difference (I guess). > >Any thoughts? > >Khaled From Jon.Crowcroft at cl.cam.ac.uk Tue May 1 23:40:07 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 02 May 2007 07:40:07 +0100 Subject: [e2e] Collaboration on Future Internet Architectures Message-ID: virtualization could be a very good thing for solving one past and one future problem. 1/ some people have claimed that one can build many-to-many multihop radio systems that offer more capacity as the number of nodes join. If this is true, this can operate within quite a narrow band (e.g. ISM) and should be sufficient for a very long time. If we can show its true in that band, other bands can follow - within regions we still need to multipelx spectrum in some hard non liquid (dave reed) way just til some of the technology is better the identifiers and management of this could be done through Virtual Private Wireless Channel Idenfiers which might use some name space we have seen before 2/ some people claim that IPv6 will never deploy in the core, and that we have to live with IPv4 core networks even thugh practically all significant end systems are IPv6 capable. on the other hand other people have looked at the net and decided that one of the big problems is that receivers can be sent data from just about anywhere even though their kinship groups are relalyl quite limited. what we need is a virtual private IPv4 internet per kinship group, and the VPII (Virtual Private Internet Identifier, yes it does sound like a VPI in ATM speak:) would be the IPv6 provider number (yes this isn't new, but i thought i'd spell it out) of course, with plutarch, all this would be easy, but its taking us longer to code than we expected:-) >>A vital part of this effort concerns fostering collaboration and >>consensus-building among researchers working on future global network >>architectures. To this end, NSF has created a FIND Planning Committee >>that works with NSF to organize a series of meetings among FIND grant >>recipients structured around activities to identify and refine >>overarching concepts for networks of the future. As part of the research >>we leave open the question of whether there will be one Internet or >>several virtualized Internets. I made some comments on FIND in a podcast given by the guardian newspaper online people - linked froom iTunes podcast stuff (its free) or probably findable via http://blogs.guardian.co.uk/podcasts/2007/04/science_weekly_for_april_30.html cheers jon p.s. is this what they mean by being poleaxed: http://news.bbc.co.uk/1/hi/world/europe/6613261.stm From msaqibilyas74 at yahoo.co.uk Wed May 2 04:44:24 2007 From: msaqibilyas74 at yahoo.co.uk (Saqib Ilyas) Date: Wed, 2 May 2007 12:44:24 +0100 (BST) Subject: [e2e] Packet dropping In-Reply-To: <20070502103308.0E521123842@aland.bbn.com> Message-ID: <62857.93128.qm@web25415.mail.ukl.yahoo.com> I would expect for non-real-time protocols such as FTP that if the packet at the head of the queue is dropped, there'd be several duplicate acks which could trigger congestion control. Regards Craig Partridge wrote: For non-real time, the answer I believe is drop the new packet. Dropping the earlier packet (assuming the earlier packet has a lower sequence number) is more likely to slow effective delivery of data to the recipient and require a more complex set of retransmissions to recover from. Craig In message <463857A4.1020205 at gmail.com>, Khaled Elsayed writes: >Given a per-connection queue that could potentially become full (or in >case of RED, hits dropping threshold), an incoming packet arrives and >finds the queue full. What would be the best policy: > >1) admit the new packet and drop one at the queue front >2) drop the newly arriving packet. > >For real-time connections, it is intuitive that dropping at queue front >would tend to result in better delay responses (this was already shown >in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993). >What about data/non-real time connections? Assume an FTP or HTTP session >subject to above situation, would TCP behave better if packet is dropped >from front or the new packet is dropped? > >I have no evidence but I tend to feel that if the congestion is >persistent for some reasonable time, it would make more sense to deliver >whatever is in the queue right now and drop the new ones at the expense >of increasing overall avg. packet delay. If the congestion duration is >small, it would not make a lot of difference (I guess). > >Any thoughts? > >Khaled Muhammad Saqib Ilyas Assistant Professor Department of Computer and Information Systems Engineering NED University of Engineering and Technology, Karachi, Pakistan http://www.saqibilyas.info Graduate Student, LUMS Country Leader, INETA Pakistan Microsoft Most Valuable Professional - C++ --------------------------------- Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your freeaccount today. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070502/8f37a190/attachment.html From craig at aland.bbn.com Wed May 2 10:36:30 2007 From: craig at aland.bbn.com (Craig Partridge) Date: Wed, 02 May 2007 13:36:30 -0400 Subject: [e2e] Packet dropping In-Reply-To: Your message of "Wed, 02 May 2007 12:44:24 BST." <62857.93128.qm@web25415.mail.ukl.yahoo.com> Message-ID: <20070502173630.AAF1E123842@aland.bbn.com> In message <62857.93128.qm at web25415.mail.ukl.yahoo.com>, Saqib Ilyas writes: >I would expect for non-real-time protocols such as FTP that if the packet at t >he head of the queue is dropped, there'd be several duplicate acks which coul >d trigger congestion control. > Regards I understand that point. My reasoning may be flawed, but just to dig myself deeper. The question was what's the best way for the queue to drain? So let's consider ten packets 0-9 in flight at sender, router and receiver In the scenario, the router is about to receive buffer 9 Sender's buffer Router Buffer Receiver Buffer 012345679 012345679 If it drops 9, then in one RTT we'll have Sender's buffer Router Buffer Receiver Buffer 9abcdefghi If it drops 0, then in one RTT with fast retransmit we'll have Sender's buffer Router Buffer Receiver Buffer 012345679 0 123456789 In either case the router queue looks similar -- the issue is which wins going forward. And it wasn't immediately clear to me that fast retransmit was better. If we drop 0, we're in fast retransmit and about to enter slow start on packet a. If we drop 9, we're about to fire off dupe acks on a-i, and will enter fast retransmit on packet b. Craig From roman at pletka.ch Wed May 2 12:58:25 2007 From: roman at pletka.ch (Roman Pletka) Date: Wed, 02 May 2007 21:58:25 +0200 Subject: [e2e] Packet dropping In-Reply-To: <463857A4.1020205@gmail.com> References: <463857A4.1020205@gmail.com> Message-ID: <4638ED61.8010902@pletka.ch> Hi Khaled, I did some research on the impact of dropping packets from the front of a queue that might be of interest for you. It was related to the approximative longest queue drop algorithm and shows how packet drops from the front of a queue can help TCP to maintain a certain bandwidth share in presence of a non-responsive source. Have a look at section 3 in the report: http://ecwww.eurecom.fr/~pletka/publications/report-pletka-99.pdf Best regards, Roman Khaled Elsayed wrote: > Given a per-connection queue that could potentially become full (or in > case of RED, hits dropping threshold), an incoming packet arrives and > finds the queue full. What would be the best policy: > > 1) admit the new packet and drop one at the queue front > 2) drop the newly arriving packet. > > For real-time connections, it is intuitive that dropping at queue front > would tend to result in better delay responses (this was already shown > in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993). > What about data/non-real time connections? Assume an FTP or HTTP session > subject to above situation, would TCP behave better if packet is dropped > from front or the new packet is dropped? > > I have no evidence but I tend to feel that if the congestion is > persistent for some reasonable time, it would make more sense to deliver > whatever is in the queue right now and drop the new ones at the expense > of increasing overall avg. packet delay. If the congestion duration is > small, it would not make a lot of difference (I guess). > > Any thoughts? > > Khaled > > -- --------------------------------------------------------------------------- Dr. Roman Pletka roman at pletka.ch Meilibachweg 11 Private: +41 43 244 6654 CH-8810 Horgen Mobile: +41 79 293 6948 --------------------------------------------------------------------------- From arjuna at erg.abdn.ac.uk Wed May 2 23:00:02 2007 From: arjuna at erg.abdn.ac.uk (Arjuna Sathiaseelan) Date: Thu, 3 May 2007 07:00:02 +0100 Subject: [e2e] Packet dropping (Khaled Elsayed) In-Reply-To: Message-ID: <200705030600.l436086w010745@erg.abdn.ac.uk> My belief is as Craig said, for real-time packets - dropping the oldest packet would be the best solution - so it would be better to drop from the front of the queue, as most of the real-time packets (VoIP, videoconferencing) would be carried on UDP or DCCP - which do not require transport layer retransmissions. We need to note dropping real-time packets such as VoIP packets (carried by UDP or DCCP) would be more of a concern to the application layer rather than the transport layer. But for non-real time applications running over TCP - then I would prefer to see the new packet being dropped rather the oldest packet - as it would be a burden to the transport layer - since the transport layer has to buffer up all the out of order packets! Arjuna ------------------------------ Message: 2 Date: Wed, 02 May 2007 06:33:08 -0400 From: Craig Partridge Subject: Re: [e2e] Packet dropping To: Khaled Elsayed Cc: end2end-interest at postel.org Message-ID: <20070502103308.0E521123842 at aland.bbn.com> For non-real time, the answer I believe is drop the new packet. Dropping the earlier packet (assuming the earlier packet has a lower sequence number) is more likely to slow effective delivery of data to the recipient and require a more complex set of retransmissions to recover from. Craig *************************************** From dpreed at reed.com Thu May 3 07:21:41 2007 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 May 2007 10:21:41 -0400 Subject: [e2e] Packet dropping In-Reply-To: <20070502103308.0E521123842@aland.bbn.com> References: <20070502103308.0E521123842@aland.bbn.com> Message-ID: <4639EFF5.6090700@reed.com> Dropping the new packet slows the current TCP congestion control algorithm's response, leading to slower and slower clogged Stevens' pipes, and a long time to recover. Making the control loop for congestion faster end-to-end is a real-time problem embedded in non-real-time data transfers, and it affects overall performance. Craig Partridge wrote: > For non-real time, the answer I believe is drop the new packet. > > Dropping the earlier packet (assuming the earlier packet has a lower > sequence number) is more likely to slow effective delivery of data > to the recipient and require a more complex set of retransmissions to > recover from. > > Craig > > > In message <463857A4.1020205 at gmail.com>, Khaled Elsayed writes: > > >> Given a per-connection queue that could potentially become full (or in >> case of RED, hits dropping threshold), an incoming packet arrives and >> finds the queue full. What would be the best policy: >> >> 1) admit the new packet and drop one at the queue front >> 2) drop the newly arriving packet. >> >> For real-time connections, it is intuitive that dropping at queue front >> would tend to result in better delay responses (this was already shown >> in an early paper by Yin and Hluchyj in IEEE Trans. Comm, June 1993). >> What about data/non-real time connections? Assume an FTP or HTTP session >> subject to above situation, would TCP behave better if packet is dropped >> > >from front or the new packet is dropped? > >> I have no evidence but I tend to feel that if the congestion is >> persistent for some reasonable time, it would make more sense to deliver >> whatever is in the queue right now and drop the new ones at the expense >> of increasing overall avg. packet delay. If the congestion duration is >> small, it would not make a lot of difference (I guess). >> >> Any thoughts? >> >> Khaled >> > > From dpreed at reed.com Thu May 3 07:30:35 2007 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 May 2007 10:30:35 -0400 Subject: [e2e] Packet dropping (Khaled Elsayed) In-Reply-To: <200705030600.l436086w010745@erg.abdn.ac.uk> References: <200705030600.l436086w010745@erg.abdn.ac.uk> Message-ID: <4639F20B.5030302@reed.com> Actually, TCP typically retransmits all the "out of order" packets you refer to Arjuna, because the sender won't know the receiver has received them unless SACK is working, an option that is not necessarily there. So the receiver can just drop all the out of order packets after a loss due to congestion without affecting throughput. If you had a channel that could carry acknowledgements faster than the speed of light (a so-called ESP channel), of course you could invent a more interesting protocol than TCP. But then you'd have to require that of every technology supported by TCP, and it's important to remember that TCP is a protocol for interop among heterogeneous technologies as its number one goal. Super hyper optimized multihop subnets of uniform technology are best deployed as an underlay under TCP, and viewed as a link. Arjuna Sathiaseelan wrote: > My belief is as Craig said, for real-time packets - dropping the oldest > packet would be the best solution - so it would be better to drop from the > front of the queue, as most of the real-time packets (VoIP, > videoconferencing) would be carried on UDP or DCCP - which do not require > transport layer retransmissions. We need to note dropping real-time packets > such as VoIP packets (carried by UDP or DCCP) would be more of a concern to > the application layer rather than the transport layer. > > But for non-real time applications running over TCP - then I would prefer to > see the new packet being dropped rather the oldest packet - as it would be a > burden to the transport layer - since the transport layer has to buffer up > all the out of order packets! > > > Arjuna > > ------------------------------ > > Message: 2 > Date: Wed, 02 May 2007 06:33:08 -0400 > From: Craig Partridge > Subject: Re: [e2e] Packet dropping > To: Khaled Elsayed > Cc: end2end-interest at postel.org > Message-ID: <20070502103308.0E521123842 at aland.bbn.com> > > > For non-real time, the answer I believe is drop the new packet. > > Dropping the earlier packet (assuming the earlier packet has a lower > sequence number) is more likely to slow effective delivery of data > to the recipient and require a more complex set of retransmissions to > recover from. > > Craig > *************************************** > > > From perfgeek at mac.com Thu May 3 08:16:49 2007 From: perfgeek at mac.com (rick jones) Date: Thu, 3 May 2007 08:16:49 -0700 Subject: [e2e] Packet dropping In-Reply-To: <20070502173630.AAF1E123842@aland.bbn.com> References: <20070502173630.AAF1E123842@aland.bbn.com> Message-ID: <342865cd2bb214aa635405fc9d80082f@mac.com> On May 2, 2007, at 10:36 AM, Craig Partridge wrote: > My reasoning may be flawed, but just to dig myself deeper. The > question was what's the best way for the queue to drain? > > So let's consider ten packets 0-9 in flight at sender, router and > receiver > > In the scenario, the router is about to receive buffer 9 > > Sender's buffer Router Buffer Receiver Buffer > > 012345679 012345679 > > If it drops 9, then in one RTT we'll have > > Sender's buffer Router Buffer Receiver Buffer > > 9abcdefghi > > If it drops 0, then in one RTT with fast retransmit we'll have > > Sender's buffer Router Buffer Receiver Buffer > 012345679 0 123456789 > > > In either case the router queue looks similar -- the issue is which > wins > going forward. And it wasn't immediately clear to me that fast > retransmit > was better. If we drop 0, we're in fast retransmit and about to enter > slow start on packet a. If we drop 9, we're about to fire off dupe > acks > on a-i, and will enter fast retransmit on packet b. At the risk of ignoring previously stated context I think it is prudent to _not_ assume there will be segments abcdfeghi, in which case, dropping 0 gives us the best chance at having fast retransmit in the first place rather than a retransmission timeout. rick jones there is no rest for the wicked, yet the virtuous have no pillows From Anil.Agarwal at viasat.com Thu May 3 08:43:10 2007 From: Anil.Agarwal at viasat.com (Agarwal, Anil) Date: Thu, 3 May 2007 11:43:10 -0400 Subject: [e2e] Packet dropping (Khaled Elsayed) In-Reply-To: <4639F20B.5030302@reed.com> Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B0654F0C40@VGAEXCH01.hq.corp.viasat.com> David reed wrote: > Actually, TCP typically retransmits all the "out of order" packets you refer to Arjuna, > because the sender won't know the receiver has received > them unless SACK is working, an option that is not necessarily there. > So the receiver can just drop all the out of order packets after a loss due to > congestion without affecting throughput. This is not quite true (perhaps this is a simplified explanation), since the sender, after a timeout will proceed to do slow start, starting with cwnd = 1 segment. If the receiver has buffered segments received after the lost packet in question, it will ack all segments after the lost segment retransmission is received; the other segments will not be retransmitted. Similarly, a fast retransmit (without SACK) will cause the lost segment to be retransmitted. If the retransmission succeeds, then no other segments will be retransmitted, if the receiver has buffered other segments. Also, slow-start will not be triggered. Hence, it helps to buffer out-of-sequence receive segments. Anil Arjuna Sathiaseelan wrote: > My belief is as Craig said, for real-time packets - dropping the > oldest packet would be the best solution - so it would be better to > drop from the front of the queue, as most of the real-time packets > (VoIP, > videoconferencing) would be carried on UDP or DCCP - which do not > require transport layer retransmissions. We need to note dropping > real-time packets such as VoIP packets (carried by UDP or DCCP) would > be more of a concern to the application layer rather than the transport layer. > > But for non-real time applications running over TCP - then I would > prefer to see the new packet being dropped rather the oldest packet - > as it would be a burden to the transport layer - since the transport > layer has to buffer up all the out of order packets! > > > Arjuna > > ------------------------------ > > Message: 2 > Date: Wed, 02 May 2007 06:33:08 -0400 > From: Craig Partridge > Subject: Re: [e2e] Packet dropping > To: Khaled Elsayed > Cc: end2end-interest at postel.org > Message-ID: <20070502103308.0E521123842 at aland.bbn.com> > > > For non-real time, the answer I believe is drop the new packet. > > Dropping the earlier packet (assuming the earlier packet has a lower > sequence number) is more likely to slow effective delivery of data to > the recipient and require a more complex set of retransmissions to > recover from. > > Craig > *************************************** > > > From dpreed at reed.com Thu May 3 07:18:47 2007 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 May 2007 10:18:47 -0400 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: Message-ID: <4639EF47.1080909@reed.com> Jon Crowcroft wrote: > 1/ some people have claimed that one can build many-to-many multihop radio > systems that offer more capacity as the number of nodes join. If this is true, > this can operate within quite a narrow band (e.g. ISM) and should be sufficient > for a very long time. If we can show its true in that band, other bands can > follow - within regions we still need to multipelx spectrum in some hard non > liquid (dave reed) way just til some of the technology is better the identifiers > and management of this could be done through Virtual Private Wireless Channel > Idenfiers which might use some name space we have seen before > A linear growth in capacity as nodes join probably does not provide more capacity per node. The simple model one might imagine achieving is: Cap[System] = o(M*W*log(S/N)) where M is the number of nodes, W is the bandwidth, and S is signal power per station. It is actually unknown whether this is an upper bound, if only because the standard analysis presumes that the noise process is independent at each receiver, an overly non-physical and way-too-conservative-assumption by a factor likely o(M^k) where k is >= 1. The per-node capacity in this hypothetical conservative model is thus Cap[node] = o(W*log(S/N)), and as you can see from that the English language translation would be "narrow band radio sucks!" or "narrow band radio is good for cooking!" W is a limit, unless you want to fry any biological organisms in the field who respond not o(log(S)) but o(S). In other words, the reason for multiplexing a wideband system is that everyone can potentially achieve much higher burst rates without turning the world into a microwave oven. This is the same reason that packet systems rather than rate-limited systems are better for many applications other than 3 kHz telephony - around which one might believe the entire communications incumbency rallies every time its government or god granted monopoly is threatened by technology change. But there are still people out there who reason that "no one will ever need more bits per second than a human can type or a human can read", and US Senators who babble about Internets made of clogged pipes. > From marbukh at antd.nist.gov Wed May 2 10:39:41 2007 From: marbukh at antd.nist.gov (marbukh@antd.nist.gov) Date: Wed, 02 May 2007 13:39:41 -0400 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: Message-ID: <7.0.1.0.2.20070502133411.025ba8a0@antd.nist.gov> Just a note to 1/: As the number of nodes grows, the upper limit capacity per node drops. This may have negative implications for large-scale, purely wireless networks. Regards, Vladimir ----------------------------------------------------------- At 02:40 AM 5/2/2007, Jon Crowcroft wrote: >virtualization could be a very good thing for solving one past and one future >problem. > >1/ some people have claimed that one can build many-to-many multihop radio >systems that offer more capacity as the number of nodes join. If this is true, >this can operate within quite a narrow band (e.g. ISM) and should be >sufficient >for a very long time. If we can show its true in that band, other bands can >follow - within regions we still need to multipelx spectrum in some hard non >liquid (dave reed) way just til some of the technology is >better the identifiers >and management of this could be done through Virtual Private Wireless Channel >Idenfiers which might use some name space we have seen before > >2/ some people claim that IPv6 will never deploy in the core, and >that we have to >live with IPv4 core networks even thugh practically all significant >end systems >are IPv6 capable. on the other hand other people have looked at the net and >decided that one of the big problems is that receivers can be sent >data from just >about anywhere even though their kinship groups are relalyl quite >limited. what >we need is a virtual private IPv4 internet per kinship group, and the VPII >(Virtual Private Internet Identifier, yes it does sound like a VPI >in ATM speak:) >would be the IPv6 provider number (yes this isn't new, but i thought >i'd spell it >out) > >of course, with plutarch, all this would be easy, but its taking us longer to >code than we expected:-) > > >>A vital part of this effort concerns fostering collaboration and > >>consensus-building among researchers working on future global network > >>architectures. To this end, NSF has created a FIND Planning Committee > >>that works with NSF to organize a series of meetings among FIND grant > >>recipients structured around activities to identify and refine > >>overarching concepts for networks of the future. As part of the research > >>we leave open the question of whether there will be one Internet or > >>several virtualized Internets. > >I made some comments on FIND in a podcast given by the guardian >newspaper online >people - linked froom iTunes podcast stuff (its free) or probably findable via >http://blogs.guardian.co.uk/podcasts/2007/04/science_weekly_for_april_30.html > > >cheers >jon >p.s. is this what they mean by being poleaxed: >http://news.bbc.co.uk/1/hi/world/europe/6613261.stm From dxu at cs.purdue.edu Wed May 2 12:25:06 2007 From: dxu at cs.purdue.edu (Dongyan Xu) Date: Wed, 2 May 2007 15:25:06 -0400 (EDT) Subject: [e2e] ACM NOSSDAV 2007 (June 4-5, U. of Illinois at Urbana-Champaign) Message-ID: Dear Colleague: I'd like to bring to your attention the upcoming NOSSDAV 2007 Workshop at the University of Illinois at Urbana-Champaign. My sincere apologies if you receive multiple copies of this information. Regards, Dongyan Xu Publicity Co-Chair ACM NOSSDAV 2007 8-<--------------------------------------------------------------------- CALL FOR PARTICIPATION The 17th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2007) Urbana-Champaign, IL, USA June 4-5, 2007 Sponsored by ACM SIGMM http://www.nossdav.org/2007 Early registration deadline: May 14, 2007 ---------------------------------------------------------------------- The 17th NOSSDAV will be held in June 2007 at the University of Illinois at Urbana-Champaign, IL, USA. We invite you to attend this workshop that is known as an event where new and controversial ideas are presented and receive strong feedback. At NOSSDAV, seasoned researchers meet students for lively discussions. The workshop provides a time and venue to inspire discussion among its participants. NOSSDAV fosters cutting-edge, state-of-the-art research in multimedia and newly emerging areas. From its original focus on support for audio and video, the scope of NOSSDAV has broadened to include networked games, sensor networks, multimedia interfaces, and peer-to-peer networking. At this year's NOSSDAV, Professor Ralf Steimetz presents us with a new challenge in this keynote speech "QoS in Wireless Mesh Networks: A Challenging Endeavor", and industry meets academia in a panel discussion on "Large Scale Peer-to-Peer Streaming & IPTV Technologies". 18 presenters from 9 countries will present their exciting research on new forms of streaming, gaming, coding, IPTV, measurement, mobility, and middleware, and they expect your feedback and challenges. You can find the detailed program at http://www.nossdav.org/2007/program.html If you have any questions, please get in touch with the co-chairs: Reza Rejaie (University of Oregon) Klara Nahrstedt (UIUC) From tvpoh at essex.ac.uk Fri May 4 08:44:06 2007 From: tvpoh at essex.ac.uk (Tze-Ven Poh) Date: Fri, 4 May 2007 16:44:06 +0100 Subject: [e2e] Premium Service Message-ID: <03ad01c78e63$0ca22d50$cf3df59b@essex.ac.uk> Why the new Expedited Forwarding PHB (RFC 3246) memo regards Expedited Forwarding PHB concept as a service which offers QoS guarantee with bounded delay and bounded jitter (see section 2.4)? But on refering to original memo RFC 2598, the service for offering low loss, low latency, low jitter, and assured bandwidth through DS domains. It says nothing about bounding the delay or bounding jitter. This is also stated in the 1st page of RFC 3246. RFC 3246 states that eq. 3 on page 5 must be satisfied which makes it sounds more like delivering hard type of QoS rather than soft. In my imagination, low latency means offering latency at it best (subject to instantenous conditions or other constraints) but not guaranteeing it. Was this what the original definition of Expedited Forwarding supposed to be? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070504/02f1ed74/attachment.html From huitema at windows.microsoft.com Thu May 3 09:22:00 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Thu, 3 May 2007 09:22:00 -0700 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064046A8DD5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > 1/ some people have claimed that one can build many-to-many multihop > radio > systems that offer more capacity as the number of nodes join. Some have claimed it, but it is far from being proved. The number of hops tend to increase with the number of nodes -- typically scaling as the square root of that number if the nodes are arranged in a plane. The available bandwidth per node tends thus to decrease with the number of nodes. -- Christian Huitema From Jon.Crowcroft at cl.cam.ac.uk Fri May 4 00:49:59 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 04 May 2007 08:49:59 +0100 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: Message from Christian Huitema of "Thu, 03 May 2007 09:22:00 PDT." <70C6EFCDFC8AAD418EF7063CD132D064046A8DD5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: aside from using mobility (as per grossglauser/tse), see: A. Ozgur, O. Leveque and D. Tse, "Hierarchical Cooperation Achieves Optimal Capacity Scaling in Ad Hoc Networks", submitted to the IEEE Transactions on Information Theory, Sept. 2006 (Revised Feb. 2007). http://www.eecs.berkeley.edu/~dtse/pub.html for an example of a scheme which might work main problems with cooperation techniques is achieving them in practice may not be do-able (it reminds me of quantum computing in this regard, full of promises, but possibly impossible:) In missive <70C6EFCDFC8AAD418EF7063CD132D064046A8DD5 at WIN-MSG-21.wingroup.windeploy.ntdev.m icrosoft.com>, Christian Huitema typed: >>> 1/ some people have claimed that one can build many-to-many multihop >>> radio >>> systems that offer more capacity as the number of nodes join.=20 >> >>Some have claimed it, but it is far from being proved. The number of >>hops tend to increase with the number of nodes -- typically scaling as >>the square root of that number if the nodes are arranged in a plane. The >>available bandwidth per node tends thus to decrease with the number of >>nodes. >> >>-- Christian Huitema >> >> >> cheers jon From dpreed at reed.com Fri May 4 17:18:20 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 May 2007 20:18:20 -0400 Subject: [e2e] moderation criteria awareness? Message-ID: <463BCD4C.1040709@reed.com> Can anyone decode "the message headers matched a filter rule" that was applied in this case? > -------- Original Message -------- > Subject: Your message to end2end-interest awaits moderator approval > From: end2end-interest-bounces at postel.org > To: dpreed at reed.com > Date: Fri, 04 May 2007 16:48:51 -0700 > > > > Your mail to 'end2end-interest' with the subject > > Re: [e2e] Collaboration on Future Internet Architectures > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > The message headers matched a filter rule > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: Surely computers can be capable of (say) telling us *what* filter rule, and perhaps even telling us the human meaningful version of the reason for that rule, e.g. "sender is a known flamer" or "some blackhole vigilante site blackballed your MTA because Paul Vixie doesn't like them". It would be nice to know why one's posts are rejected, perhaps lessening one's paranoia... It's an "end to end" protocol issue when mail is not delivered to the endpoints named in the message, and instead stopped by an incomprehensible middlebox. From cottrell at slac.stanford.edu Fri May 4 18:31:02 2007 From: cottrell at slac.stanford.edu (Cottrell, Les) Date: Fri, 4 May 2007 18:31:02 -0700 Subject: [e2e] moderation criteria awareness? In-Reply-To: <463BCD4C.1040709@reed.com> References: <463BCD4C.1040709@reed.com> Message-ID: <35C208A168A04B4EB99D1E13F2A4DB0101DCC29C@exch-mail1.win.slac.stanford.edu> It may be an issue of not telling the spammers how to avoid the filter, i.e. it is a conflict of helpfulness vs. security. It is also possible the filters are hardly easy to interpret simply. -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of David P. Reed Sent: Friday, May 04, 2007 5:18 PM To: end2end-interest list Subject: [e2e] moderation criteria awareness? Can anyone decode "the message headers matched a filter rule" that was applied in this case? > -------- Original Message -------- > Subject: Your message to end2end-interest awaits moderator approval > From: end2end-interest-bounces at postel.org > To: dpreed at reed.com > Date: Fri, 04 May 2007 16:48:51 -0700 > > > > Your mail to 'end2end-interest' with the subject > > Re: [e2e] Collaboration on Future Internet Architectures > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > The message headers matched a filter rule > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: Surely computers can be capable of (say) telling us *what* filter rule, and perhaps even telling us the human meaningful version of the reason for that rule, e.g. "sender is a known flamer" or "some blackhole vigilante site blackballed your MTA because Paul Vixie doesn't like them". It would be nice to know why one's posts are rejected, perhaps lessening one's paranoia... It's an "end to end" protocol issue when mail is not delivered to the endpoints named in the message, and instead stopped by an incomprehensible middlebox. From szander at swin.edu.au Sat May 5 18:52:19 2007 From: szander at swin.edu.au (Sebastian Zander) Date: Sun, 06 May 2007 11:52:19 +1000 Subject: [e2e] Netgames 2007 deadline is approaching (May 13th) Message-ID: <463D34D3.2060700@swin.edu.au> We apologize if you receive multiple copies of this announcment. +++++++++++++++++++++ Netgames 2007 Call for Papers +++++++++++++++++++++++ 6th Annual Workshop on Network and Systems Support for Games: Netgames 2007 September 19th and 20th 2007, Melbourne, Australia http://caia.swin.edu.au/netgames2007/ In co-operation with ACM SIGCOMM OVERVIEW ======== The NetGames workshop brings together researchers and developers from academia and industry to present new research in understanding networked games and in enabling the next generation of them. Submissions are sought in any area related to networked games. In particular, topics of interest include (but are not limited to) game-related work in: * Network measurement, usage studies and traffic modeling * System benchmarking, performance evaluation, and provisioning * Latency issues and lag compensation techniques * Cheat detection and prevention * Service platforms, scalable system architectures, and middleware * Network protocol design * Multiplayer mobile and resource-constrained gaming systems * Augmented physical gaming systems * User and usability studies * Quality of service and content adaptation * Artificial intelligence * Security, authentication, accounting and digital rights management * Networks of sensors and actuators for games * Impact of online game growth on network infrastructure * Text and voice messaging in games SUBMISSIONS =========== We solicit submisisons of full papers with a limit of 6 pages (inclusive of all figures, references and appendices). Authors must submit their papers in PDF and use single-spaced, double column ACM conference format. Reviews will be single-blind, authors must include their names and affiliations on the first page. Papers will be judged on their relevance, technical content and correctness, and the clarity of presentation of the research. Accepted papers will be archived in the ACM Digital Library and published in the workshop proceedings pending the participation of the authors in the workshop. Paper submissions will be via online upload to EDAS (http://edas.info/5431). Submission of a paper for review will be considered your agreement that at least one author will register and attend if your paper is accepted. Detailed paper submission guidelines are available at http://caia.swin.edu.au/netgames2007/submissions.html COMMITTEE ========= WORKSHOP CHAIR: Grenville Armitage (Swinburne University of Technology, Australia) PROGRAM COMMITTEE: Philip Branch (Swinburne University of Technology, Australia) Kuan-Ta Chen (Academia Sinica, Taiwan) Adrian Cheok (National University of Singapore) Mark Claypool (Worcester Polytechnic Institute, USA) Jon Crowcroft (University of Cambridge, UK) Wu-chang Feng (Portland State University, USA) Carsten Griwodz (University of Oslo, Norway) Tristan Henderson (Dartmouth College, USA) Yutaka Ishibashi (Nagoya Institute of Technology, Japan) Michael J. Katchabaw (University of Western Ontario, Canada) Yoshihiro Kawahara (The University of Tokyo, Japan) Martin Mauve (Heinrich-Heine-Universitat, Germany) John Miller (Microsoft Research, Cambridge, UK) Brian Levine (University of Massachusetts Amherst, USA) Wei Tsang Ooi (National University of Singapore) Lars Wolf (TU Braunschweig, Germany) Hartmut Ritter (Freie Universitat Berlin, Germany) Farzad Safaei (University of Wollongong, Australia) Jochen Schiller (Freie Universitat Berlin, Germany) Sebastian Zander (Swinburne University of Technology, Australia) WEBSITE / PUBLICITY: Lucas Parry (Swinburne University of Technology, Australia) LOCAL ARRANGEMENTS: Warren Harrop (Swinburne University of Technology, Australia) Lawrence Stewart (Swinburne University of Technology, Australia) Netgames 2007 will be held on September 19th and 20th 2007 in Melbourne, Australia. KEY DATES ========= Paper registration opens: March 25th, 2007 Paper registration closes: May 13th, 2007 (11:59pm New York) Full-paper submission: May 20th, 2007 (11:59pm New York) Notification to authors: July 6th, 2007 Early-bird and presenter Registration opens: July 13th, 2007 Camera ready manuscript: August 10th, 2007 (11:59pm New York) Early-bird and presenter registration closes: August 10th, 2007 Workshop: September 19-20th, 2007 +++++++++++++++++++++ Netgames 2007 Call for Papers +++++++++++++++++++++++ From lachlan.andrew at gmail.com Fri May 4 09:49:45 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 4 May 2007 09:49:45 -0700 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: <4639EF47.1080909@reed.com> References: <4639EF47.1080909@reed.com> Message-ID: On 03/05/07, David P. Reed wrote: > the standard analysis > presumes that the noise process is independent at each receiver, an > overly non-physical and way-too-conservative-assumption by a factor > likely o(M^k) where k is >= 1. Thermal noise in the radio fround-end is almost certain to be independent at each receiver. If all other noise can be averaged out, this noise will still exist, and give the standard assumption. > The per-node capacity in this hypothetical conservative model is thus > Cap[node] = o(W*log(S/N))... ... if we have a single receiver. That is why David Tse's work is all MIMO. $0.02 Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From dpreed at reed.com Fri May 4 11:40:06 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 May 2007 14:40:06 -0400 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: <4639EF47.1080909@reed.com> Message-ID: <463B7E06.2090607@reed.com> Nothing magic about MIMO in this regard. Lachlan Andrew wrote: > On 03/05/07, David P. Reed wrote: >> the standard analysis >> presumes that the noise process is independent at each receiver, an >> overly non-physical and way-too-conservative-assumption by a factor >> likely o(M^k) where k is >= 1. > > Thermal noise in the radio fround-end is almost certain to be > independent at each receiver. If all other noise can be averaged out, > this noise will still exist, and give the standard assumption. I agree, but thermal noise in the radio front-end is a controllable of the radio design of the front-end - it's not a limit on capacity that depends either on the number of radios or on the environment in which the radios operate. There is no obvious reason in our analysis that is intended to cover all possible realizable radio systems, to hold the receiver design constant (including its internal noise process, which is not actually "thermal" - in the strict sense of being caused by "temperature" - which is not a physical quantity, just a statistical measure of actual physical processes.) Thermal noise is any statistical input whose behavior relates to temperature - in electronic receivers (based on QED effects) it is due to various statistics of electrons in condensed matter systems. Those statistics are bulk properties that can be varied by choosing metals or semiconductors or other exotic materials. Thermal noise in a superconductor is different in quality than thermal noise in a semiconductor or in a copper wire. If we are considering all possible receivers, we should stop at the process that interacts with the electromagnetic field - be it a wire or plate antenna, or a SQUID. > >> The per-node capacity in this hypothetical conservative model is thus >> Cap[node] = o(W*log(S/N))... > > ... if we have a single receiver. That is why David Tse's work is all > MIMO. You didn't follow my derivation. If the total system capacity of M radios is o(M*W*log(S/N)), then the per-node capacity is o(W*log(S/N)). Simple division has nothing to do with MIMO. In fact, there is nothing magic about MIMO systems at all - the magic arises from the shape of space, which means that the waveform output by an antenna is a 3D waveform, so that the signals from ANY two antennas are orthogonal in 3-space. That's equivalent to saying that the only thing that can interfere with a photon is the photon itself - a basic axiom of quantum mechanics that goes back to the beginning of the 20th century. This orthogonality is the basis (get the pun) of MIMO systems, but it is exploitable by any system that samples space-time in multiple distinct points. (of course you have to have think in 4D vector spaces, rather than in scalar functions of time to get the point). From lachlan.andrew at gmail.com Fri May 4 12:59:51 2007 From: lachlan.andrew at gmail.com (Lachlan Andrew) Date: Fri, 4 May 2007 12:59:51 -0700 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: <463B7E06.2090607@reed.com> References: <4639EF47.1080909@reed.com> <463B7E06.2090607@reed.com> Message-ID: On 04/05/07, David P. Reed wrote: > Nothing magic about MIMO in this regard. > > Lachlan Andrew wrote: > > > > Thermal noise in the radio frount-end... > I agree, but thermal noise in the radio front-end is a controllable of > the radio design of the front-end - it's not a limit on capacity that > depends either on the number of radios or on the environment in which > the radios operate. True, but if we ignore noise that is independent between receivers, I doubt that N (and hence S) would be big enough to do much cooking-with-narrowband. However, I don't have figures, and would be happy to be proved wrong :) As an aside, it would be interesting to see if there are further physical limits imposed by the need to have super-cooled receivers near our hot transmitters; could the shielding intrinsically interfere with the radiation patters or something? Maxwell's daemon comes to mind... > > ... if we have a single receiver. That is why David Tse's work is all > > MIMO. > Simple division has nothing to do with MIMO. *grin* Oops. I wasn't thinking... Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Phone: +1 (626) 395-8820 Fax: +1 (626) 568-3603 From dpreed at reed.com Fri May 4 16:48:40 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 May 2007 19:48:40 -0400 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: <4639EF47.1080909@reed.com> <463B7E06.2090607@reed.com> Message-ID: <463BC658.6090802@reed.com> Lachlan Andrew wrote: > > True, but if we ignore noise that is independent between receivers, I > doubt that N (and hence S) would be big enough to do much > cooking-with-narrowband. However, I don't have figures, and would be > happy to be proved wrong :) Depends on the system architecture. Today's radio designs certainly have no ability to scale their power down as the density goes up. > > As an aside, it would be interesting to see if there are further > physical limits imposed by the need to have super-cooled receivers > near our hot transmitters; could the shielding intrinsically interfere > with the radiation patters or something? Maxwell's daemon comes to > mind... > > I completely agree that this is an intersting direction. As a hobby, I've been wondering if the "reversible computing" or "conservative logic" concepts can be applied sensibly to communications. The minimum energy needed to communicate one bit of information from one point in a thermodynamic system to another with perfect reliability would seem to be a simple thermodynamic problem to solve. There is no obvious reason why spatial separation should be a bound... Bennet/Landauer tell us what the minimum energy to destroy a bit of information during a computation must be, and suggest that that is the only essential energy that must be expended in a computation. And there is a standard cionjecture/result from quantum gravity that suggests that the total amount of information within a bounded region of space is proportional to the surface area of that space (thus a fractal surface can enclose more information than a tight convex one). From avg at kotovnik.com Fri May 4 15:20:00 2007 From: avg at kotovnik.com (Vadim Antonov) Date: Fri, 4 May 2007 15:20:00 -0700 (PDT) Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064046A8DD5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: People who claim that increasing the density of raido nodes will increase the per-node bandwidth (or at least leave it unchanged) are simply not good with arithmetic. Let's look at a plane with some distribution of radio nodes on it, with per-node characteristic bandwidth B, achieved at signal/noise ration SN0. Let's now scale down that plane by reducing all distances by factor F. Node-to-node signal changes as square of distance, i.e. we can get the same power at receiver by transmitting at 1/F^2 of the original power. The total noise from interference from other transmitters is proportional to the density of transmitters times their power - density increases as F^2, power of each transmitter is adjused by 1/F^2, as above. Thus by scaling distances down and reducing the power of transmitters accordingly, we end up with the same S/N, and the same bandwidth per node. Which means that we get same effective bandwidth _for the same average number of hops_ (Beff = B/Nhops). But each hop is now shorter; so a packet has to make F times more hops. This makes effective bandwidth from two fixed points (same between the original and scaled network) to decrease: BEFFscaled = BEFForig/F. Note that this result does not depend on directionality of antennae, method of sharing the medium capacity, quality of receivers, etc. Just increasing the number of nodes in a multihop system HAS to decrease the effective bandwidth as square root of the number of nodes. The way to achieve the claimed scaling is to have an overlay short-cut non-interfering network (i.e. fiber-optic, etc) with a number of interconnection points proportional to the number of radio nodes. (Another option is to exploit smaller scale in order to make use of higher-frequency (i.e. free-space optical) interconnects unfeasible at longer distances). --vadim On Thu, 3 May 2007, Christian Huitema wrote: > > 1/ some people have claimed that one can build many-to-many multihop > > radio > > systems that offer more capacity as the number of nodes join. > > Some have claimed it, but it is far from being proved. The number of > hops tend to increase with the number of nodes -- typically scaling as > the square root of that number if the nodes are arranged in a plane. The > available bandwidth per node tends thus to decrease with the number of > nodes. > > -- Christian Huitema > > > > From touch at ISI.EDU Sun May 6 20:52:01 2007 From: touch at ISI.EDU (Joe Touch) Date: Sun, 06 May 2007 20:52:01 -0700 Subject: [e2e] moderation criteria awareness? In-Reply-To: <463BCD4C.1040709@reed.com> References: <463BCD4C.1040709@reed.com> Message-ID: <463EA261.7080708@isi.edu> David (et al.), As one whose posts have matched filter rules before, I am surprised to see this incident raise the issue. David P. Reed wrote: > Can anyone decode "the message headers matched a filter rule" that was > applied in this case? There are a variety of filters used on this list to support the list policies, noted on the www.postel.org/e2e.htm site that describes this list. Further comments below... >> -------- Original Message -------- >> Subject: Your message to end2end-interest awaits moderator approval >> From: end2end-interest-bounces at postel.org >> To: dpreed at reed.com >> Date: Fri, 04 May 2007 16:48:51 -0700 >> >> >> >> Your mail to 'end2end-interest' with the subject >> >> Re: [e2e] Collaboration on Future Internet Architectures >> >> Is being held until the list moderator can review it for approval. >> >> The reason it is being held: >> >> The message headers matched a filter rule >> >> Either the message will get posted to the list, or you will receive >> notification of the moderator's decision. If you would like to cancel >> this posting, please visit the following URL: > > Surely computers can be capable of (say) telling us *what* filter rule, > and perhaps even telling us the human meaningful version of the reason > for that rule, e.g. "sender is a known flamer" or "some blackhole > vigilante site blackballed your MTA because Paul Vixie doesn't like them". Computers can; Mailman, as installed, does not. There are a variety of reasons this could be the case, but you should contact the Mailman developers to answer that one. > It would be nice to know why one's posts are rejected, perhaps lessening > one's paranoia... Held != rejected; this message was held for approval, and you'll note it was approved. If you want to know why a message is held (or rejected) in general, please view our website with our list posting policy; that's good advice for any list, prior to posting anyway. As to why an particular item matched our filter rules, they are not perfect and are designed to err on the side of false positives which are merely held for review. > It's an "end to end" protocol issue when mail is not delivered to the > endpoints named in the message, and instead stopped by an > incomprehensible middlebox. If you want to know more about this list, please read the information that is available on our website; any search engine would suffice, or use the link above. If you have issue with the software, Mailman is open source and accepts contributions. Joe (as list admin) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070506/02dcf57a/signature.bin From touch at ISI.EDU Mon May 7 09:11:31 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 07 May 2007 09:11:31 -0700 Subject: [e2e] moderation criteria awareness? In-Reply-To: <35C208A168A04B4EB99D1E13F2A4DB0101DCC29C@exch-mail1.win.slac.stanford.edu> References: <463BCD4C.1040709@reed.com> <35C208A168A04B4EB99D1E13F2A4DB0101DCC29C@exch-mail1.win.slac.stanford.edu> Message-ID: <463F4FB3.4010803@isi.edu> PS - one strong hint: Since I try to moderate all CFPs posted to this list, posting a follow-up to a CFP is a nearly sure way to end up having your post also held. Hint: if you have a new topic of discussion (i.e., you're not really following up to the CFP, but perhaps inspired by it), start a new thread with a new header Joe (as list admin) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070507/d22eb465/signature.bin From L.Wood at surrey.ac.uk Mon May 7 08:27:22 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Mon, 7 May 2007 16:27:22 +0100 Subject: [e2e] Collaboration on Future Internet Architectures References: <4639EF47.1080909@reed.com> <463B7E06.2090607@reed.com> <463BC658.6090802@reed.com> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316AB2@EVS-EC1-NODE1.surrey.ac.uk> David P. Reed wrote: > And there is a standard cionjecture/result from quantum gravity that > suggests that the total amount of information within a bounded region > of space is proportional to the surface area of that space (thus a > fractal surface can enclose more information than a tight convex one). This is why David's beard makes him look more knowledgeable. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070507/a406458d/attachment-0001.html From Jon.Crowcroft at cl.cam.ac.uk Mon May 7 09:51:40 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 07 May 2007 17:51:40 +0100 Subject: [e2e] moderation criteria ignorance? In-Reply-To: Message from Joe Touch of "Mon, 07 May 2007 09:11:31 PDT." <463F4FB3.4010803@isi.edu> Message-ID: of course, MCI is no excuse :-) In missive <463F4FB3.4010803 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enig9A828E52C0FAAF9735077E7F >>Content-Type: text/plain; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>PS - one strong hint: >> >>Since I try to moderate all CFPs posted to this list, posting a >>follow-up to a CFP is a nearly sure way to end up having your post also >>held. >> >>Hint: if you have a new topic of discussion (i.e., you're not really >>following up to the CFP, but perhaps inspired by it), start a new thread >>with a new header >> >>Joe (as list admin) >> >> >>--------------enig9A828E52C0FAAF9735077E7F >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.3 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFGP0+zE5f5cImnZrsRAtMuAJ9pGKGj8Fo8IQKG06sbPyok14A7MQCgjzpS >>OG1upUBaS6YBULxKZxA1AZw= >>=R0uy >>-----END PGP SIGNATURE----- >> >>--------------enig9A828E52C0FAAF9735077E7F-- >> cheers jon From Jon.Crowcroft at cl.cam.ac.uk Thu May 10 02:19:13 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 10 May 2007 10:19:13 +0100 Subject: [e2e] on detecting social nets and using them for optimising dtn forwarding algorithms Message-ID: the following technical report http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-684.html is available for your perusal. Due to circumstances beyond our control, we won't be talking about it in Kyoto unless you want to chat in the baths or temples... Bubble Rap: Forwarding in small world DTNs in ever decreasing circles In this paper we seek to improve understanding of the structure of human mobility, and to use this in the design of forwarding algorithms for Delay Tolerant Networks for the dissemination of data amongst mobile users. Cooperation binds but also divides human society into communities. Members of the same community interact with each other preferentially. There is structure in human society. Within society and its communities, individuals have varying popularity. Some people are more popular and interact with more people than others; we may call them hubs. Popularity ranking is one facet of the population. In many physical networks, some nodes are more highly connected to each other than to the rest of the network. The set of such nodes are usually called clusters, communities, cohesive groups or modules. There is structure to social networking. Different metrics can be used such as information flow, Freeman betweenness, closeness and inference power, but for all of them, each node in the network can be assigned a global centrality value. What can be inferred about individual popularity, and the structure of human society from measurements within a network? How can the local and global characteristics of the network be used practically for information dissemination? We present and evaluate a sequence of designs for forwarding algorithms for Pocket Switched Networks, culminating in Bubble, which exploit increasing levels of information about mobility and interaction. j&b with apologies to magritte, ceci n'est pas un sigcomm papier From dpreed at reed.com Thu May 10 07:25:33 2007 From: dpreed at reed.com (David P. Reed) Date: Thu, 10 May 2007 10:25:33 -0400 Subject: [e2e] on detecting social nets and using them for optimising dtn forwarding algorithms In-Reply-To: References: Message-ID: <46432B5D.5060809@reed.com> I am told that this problem was solved by Nokia already. Perhaps they patented it. Jon Crowcroft wrote: > the following technical report > http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-684.html > is available for your perusal. Due to circumstances beyond > our control, we won't be talking about it in Kyoto > unless you want to chat in the baths or temples... > > Bubble Rap: Forwarding in small world DTNs in ever decreasing circles > > In this paper we seek to improve understanding of the structure of human mobility, and to use this in the > design of forwarding algorithms for Delay Tolerant Networks for the dissemination of data amongst mobile users. > > Cooperation binds but also divides human society into communities. Members of the same community interact with > each other preferentially. There is structure in human society. Within society and its communities, individuals > have varying popularity. Some people are more popular and interact with more people than others; we may call > them hubs. Popularity ranking is one facet of the population. In many physical networks, some nodes are more > highly connected to each other than to the rest of the network. The set of such nodes are usually called > clusters, communities, cohesive groups or modules. There is structure to social networking. Different metrics > can be used such as information flow, Freeman betweenness, closeness and inference power, but for all of them, > each node in the network can be assigned a global centrality value. > > What can be inferred about individual popularity, and the structure of human society from measurements within a > network? How can the local and global characteristics of the network be used practically for information > dissemination? We present and evaluate a sequence of designs for forwarding algorithms for Pocket Switched > Networks, culminating in Bubble, which exploit increasing levels of information about mobility and interaction. > > j&b > with apologies to magritte, > ceci n'est pas un sigcomm papier > > From dpreed at reed.com Fri May 11 20:07:44 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 11 May 2007 23:07:44 -0400 Subject: [e2e] It's all my fault Message-ID: <46452F80.9040801@reed.com> As the person who argued for source routing in the original design, I guess I must confess that I am the devil incarnate. Steve Crocker and others will probably want to join me at the guillotine. Apparently the Vixie and other paranoiacs and vigilantes have gotten it into their heads that RH0 in IPv6 is one "denial of service on steroids" and should be deleted immediately. SInce source routing has many benefits, as those of us (such as Dave Farber) have advocated, one might hope that there would be rational folks who would consider this as a balanced issue. But since the "security" experts (who never saw a deep packet inspection they didn't love) have decided that firewalls can intuit intent 100% correctly merely by inspecting bits, they have decided to declare that single path routing is by definition optimal and good enough for all users. By all means, recreate the fixed-route bellhead net of 1969. And please, let's have the middleboxes decide what messages we ought to be allowed to send - after all, the brilliant routerheads know that us "lusers" at the edge of the net are stupid fools who should never be allowed to actually run any applications that they haven't anticipated. All Hail Paul Vixie! Heil Paul! From randy at psg.com Sat May 12 07:57:53 2007 From: randy at psg.com (Randy Bush) Date: Sat, 12 May 2007 17:57:53 +0300 Subject: [e2e] It's all my fault In-Reply-To: <46452F80.9040801@reed.com> References: <46452F80.9040801@reed.com> Message-ID: <4645D5F1.5030801@psg.com> it would be considerably more helpful if, instead of ad homina and vituperation, you actually spoke to the rh0 security issues and possible approaches to mitigation as a technical and engineering problem. randy From jeroen at unfix.org Sat May 12 09:02:27 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 12 May 2007 17:02:27 +0100 Subject: [e2e] It's all my fault In-Reply-To: <4645D5F1.5030801@psg.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> Message-ID: <4645E513.2090209@spaghetti.zurich.ibm.com> Randy Bush wrote: > it would be considerably more helpful if, instead of ad homina and > vituperation, you actually spoke to the rh0 security issues and possible > approaches to mitigation as a technical and engineering problem. Well, one of the main mitigation methods is very easy, and actually already takes care that RH0 is useless: uRPF. If all networks would properly implement BCP38 and thus do RPF checks packet bouncing would not be possible. Unfortunately there are a lot of networks connected to the Internet who are not following the Best Common Practices. IMHO there should be an organization that keeps a close eye on Internet providers, that is organisztions who carry packets from A to B. Their job would be to say "this organization is taking good care of their network, they apply BCP38, they resolve problems in adequate manner etc". Then, as an operator who is following this organization one can sandbox the organizations (read: prefixes/asn's) who are not belonging to this and let them play on the toy Internet. Then, when there is a mechanism similar to RH0, you can actually trust your peers to resolve problems quickly, instead of having to wail because finding the source of the problem is impossible and contacting the right people to get it fixed is not possible either. Of course, the first thing that one does is contact the upstream etc, but as the upstream at a certain point is a transit they will say "we do not know where it is coming from". Nice issues: technical with a flake of politics. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070512/0ec8a8d8/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Fri May 11 06:06:11 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 11 May 2007 14:06:11 +0100 Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: References: Message-ID: In missive , Vadim Antonov typed: >>People who claim that increasing the density of raido nodes will increase >>the per-node bandwidth (or at least leave it unchanged) are simply not >>good with arithmetic. conversely, at geometry >>Let's look at a plane with some distribution of radio nodes on it, with >>per-node characteristic bandwidth B, achieved at signal/noise ration SN0. try a volume, not a plane. the number of alternate paths the the volume goes up faster, and one can use lots of disperity tricks (path, code etc) to make the alternates only have epsilon interference - if you then alternate dynamic power over a short haul hop to spread the signal to a neighbourhood, with dynamic coding for longer haul to get the message to the next neighbourhood, you get capacity within epsilon*Nhops of N - conjecture: a sequence of "knights moves" of 1 hop up, 2 hops forward can tile a volume in a systematic way and use the scheme above (due to Tse) in a very easy to self organised fashion... Imagine a field full of children all sitting in groups, and at the middle of each group is a teacher. You can ask the teacher a question by putting up your hand, and each teacher can listen and answer one child at a time. If two groups of children are too close together, then one child asking a question, or one teacher answering may drown out the other group. We try and have enough teachers so that if all the children who want to ask a question at the same time do so, then there are enough teachers to answer. If the teacher you are asking is busy, you might go from the edge of the group you are in, nearer to the edge of another group and try and ask their teacher. But imagine you can't be bothered to move, but you notice that the teacher nearest is busy, and a teacher further is not busy. What if you shout your question? What if the teacher nearby can still manage to lisen to the nearby child, even while one or two of you shout to a further teacher? An interesting question to ask is: how many more questions can the teachers and groups of children answer if the teachers can deal with sorting out different people speaking? so now have kids either sit or stand to ask a question, and speak in a low or high squeeky voice, and have teachers sit or stand, and choose to listen to high or low grumbly voices... j. From jari.arkko at piuha.net Sat May 12 10:17:36 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Sat, 12 May 2007 20:17:36 +0300 Subject: [e2e] It's all my fault In-Reply-To: <4645D5F1.5030801@psg.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> Message-ID: <4645F6B0.1090004@piuha.net> Randy, David, > it would be considerably more helpful if, instead of ad homina and > vituperation, you actually spoke to the rh0 security issues and possible > approaches to mitigation as a technical and engineering problem. > Indeed. Implementors have largely already done the right thing already earlier or else released patches in recent weeks. We are also dealing with the removal/disable of RH0 in the IPv6 WG list discussion. Other parts of the protocol stack that needed something like routing header have already years ago been designed to do something safe instead of RH0. My advice: if you have something to say about the way which we should disable RH0, go to the IPv6 list. Or if you can, apply a patch in your company's products or networks. Or apply your energy in figuring out what other vulnerabilities we have in our stacks; there's plenty of work in this space... Jari From dpreed at reed.com Sat May 12 11:27:52 2007 From: dpreed at reed.com (David P. Reed) Date: Sat, 12 May 2007 14:27:52 -0400 Subject: [e2e] It's all my fault In-Reply-To: <4645D5F1.5030801@psg.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> Message-ID: <46460728.4050006@reed.com> Regarding what Vixie said, see the following. Apparently he is fanning a flame that somehow the invention of source routing or its inclusion in the IP standard causes or amplifies attacks on network resources. http://www.theregister.com/2007/05/11/ipv6_flaw_scramble/ I didn't start the ad hominem attacks or vituperation. Read Vixie's words. Randy Bush wrote: > it would be considerably more helpful if, instead of ad homina and > vituperation, you actually spoke to the rh0 security issues and possible > approaches to mitigation as a technical and engineering problem. > > randy > > From dpreed at reed.com Sat May 12 11:40:58 2007 From: dpreed at reed.com (David P. Reed) Date: Sat, 12 May 2007 14:40:58 -0400 Subject: [e2e] It's all my fault In-Reply-To: <4645F6B0.1090004@piuha.net> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <4645F6B0.1090004@piuha.net> Message-ID: <46460A3A.2030004@reed.com> Jari - Implementors who remove or disable source routing are (in my opinion, of course) taking matters into their own hands on the basis of a misguided theory that source routing *causes* denial of service. Source routing is a standard, and was not included in the standard as a "mistake" (either in IPv4 or in IPv6). It was included as a useful tool. It was intended that end users would be able to use it. Blocking end users from using it is vigilante action. That would be appropriate if source routing were a bad idea. It is not. It is a tool, which can be misused. Removing screwdrivers from the workbench because they can be used to stab people through the eye is the same sort of logic. There is a rather nice analysis of the utility of source routing that Jerry Saltzer and I wrote many years ago. We did not invent the idea - Dave Farber used it prior to that. And source routing is a well understood routing technique taught in the literature. Regarding Bush's point about "amelioration" of source routing's effects. Source routing does not have effects. Denial of service attacks have effects. I am happy to talk about amelioration of denial of service attacks. Regarding Paul Vixie - I rarely speak out against people, mostly going after their ideas. But Vixie has a track record. He is one of the inventors, apologists, and promoters of aggressive spam blackhole lists: holding non-offenders by the thousands accountable for the actions of a few spammers. I and many others have been held hostage by having our email blocked by his "blackhole vigilantes". He has never apologized for it. I personally think he could be sued for millions of dollars of lost work and aggravation. Your mileage may vary. Jari Arkko wrote: > Randy, David, > > >> it would be considerably more helpful if, instead of ad homina and >> vituperation, you actually spoke to the rh0 security issues and possible >> approaches to mitigation as a technical and engineering problem. >> >> > > Indeed. > > Implementors have largely already done the right thing > already earlier or else released patches in recent weeks. > We are also dealing with the removal/disable of RH0 in the > IPv6 WG list discussion. Other parts of the protocol stack > that needed something like routing header have already > years ago been designed to do something safe instead of > RH0. > > My advice: if you have something to say about the way > which we should disable RH0, go to the IPv6 list. Or if > you can, apply a patch in your company's products or > networks. Or apply your energy in figuring out what > other vulnerabilities we have in our stacks; there's > plenty of work in this space... > > Jari > > > From sthaug at nethelp.no Sat May 12 12:12:00 2007 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Sat, 12 May 2007 21:12:00 +0200 (CEST) Subject: [e2e] It's all my fault In-Reply-To: <46460728.4050006@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> Message-ID: <20070512.211200.71125708.sthaug@nethelp.no> > Regarding what Vixie said, see the following. Apparently he is fanning > a flame that somehow the invention of source routing or its inclusion in > the IP standard causes or amplifies attacks on network resources. > > http://www.theregister.com/2007/05/11/ipv6_flaw_scramble/ > > I didn't start the ad hominem attacks or vituperation. Read Vixie's words. As far as I can see he was speaking specifically about the IPv6 RH0 problem, not about source routing in general. Are you saying he is wrong about the IPv6 RH0 problem? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From dubey.ism at gmail.com Sat May 12 17:47:43 2007 From: dubey.ism at gmail.com (Ashutosh Dubey) Date: Sat, 12 May 2007 17:47:43 -0700 Subject: [e2e] RSA Algorithm for large texts Message-ID: <827f3eeb0705121747r3e9fcd2ej673790d071ee877d@mail.gmail.com> Hi all, Can we use RSA algorithm for encrypting large texts by:- breaking them into small blocks,the length of blocks may not be constant each time. Do we need to tell the length of blocks at the decrypter end? -- Ashutosh Kr. Dubey Indian School of Mines,Dhanbad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070512/0b3ae894/attachment.html From detlef.bosau at web.de Mon May 14 08:17:41 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 14 May 2007 17:17:41 +0200 Subject: [e2e] I got lost in opportunistic scheduling. In-Reply-To: <4616E722.3070402@web.de> References: <4616E722.3070402@web.de> Message-ID: <46487D95.4040104@web.de> Excuse me, when I return to this somewhat annoying subject. Admittedly, I get somewhat lost here. My leading question is: - Are there any peculiarities in mobile networks, which can affect upper layers? Then I got lost in the assumption, that PF scheduling may lead to delay spikes which can cause trouble to upper layers. My next question was. How large are these? So, I read a lot of papers, put them into water and converted them into paper-mache and built a new house from it - and totally got lost. So, my first question is, and if there is anybody who can help me there I would greatly appreciate this: Why are we doing opportunistic scheduling at all? The question seems to be very "local" at a first glance, but in fact opportunistic scheduling basically may turn store?n forward components into stop?n pray for restart components, so at least they are not "completely transparent" from an end to end perspective. To my understanding, the key idea in opportunistic scheduling is to have a user (in a multiuser mobile network) send preferably in periods of "good network condition" (whatever this may be). To my understanding, one reason for doing so is to increase the spectral efficiency in a network. Instead of mitigating errors by averaging, as it is done as a side effect from spreading by the use of long spreading sequences, the user avoids sending in periods with "bad network condtion" (w.t.m.b.) and therefore errors are avoided. Side effect: Spreading sequences can be shortened and throughput can be increased. At least, I think that is one lesson I have learned from some slides by David Tse. So, we have three issues here. 1. A user shall send in periods with "good network condtion" (...). However, there are two ancillary conditions: 2. There shall be fairness between users. (There exists some work on this, I did not yet read this all, otherwise our whole street would have got new houses from paper-mache. We could rename it then from "Galileistrasse" into "Potemkin Boulevard".) 3. From an end to end perspective, a user wating for a time slot allocation might want to get it allocated some day. ("When I get older, losing my hear...") In David Tse?s talks about "Multiuser Diversity", the first issue corresponds to "Hitting the Peaks". The other ones correspond to the scheduling metric which is actually chosen and the time constants of smoothing components being actually in use. Perhaps, the fist problem is of particularly interest for people living in San Franciso: I?m told, that there are small and tiny earth quakes almost every few days. So it?s not the problem to escape from an average earthquake but it?s interesting to know to "hit the peak" - and hit the road then, because it?s eventually quite a good idea to leave the city ;-) However, I totally got lost here and even for the very simple question of finding appropriate EWMA filters or to decide which kind of filter makes sense, I don?t see where to start. Perhas, some better understanding of some communication engineering details would be helpful here - but at the moment I simply got lost. So, I would appreciate any hint here. Thanks. 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 Mon May 14 09:01:48 2007 From: touch at ISI.EDU (Joe Touch) Date: Mon, 14 May 2007 09:01:48 -0700 Subject: [e2e] It's all my fault In-Reply-To: <46460728.4050006@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> Message-ID: <464887EC.1020502@isi.edu> David P. Reed wrote: ... > I didn't start the ad hominem attacks or vituperation. Read Vixie's words. This list isn't for starting, continuing, or ending ad hominem attacks. Please take such messages elsewhere. Discussions of the issues is, as always, welcome. Joe (as list admin) From avg at kotovnik.com Sat May 12 15:47:10 2007 From: avg at kotovnik.com (Vadim Antonov) Date: Sat, 12 May 2007 15:47:10 -0700 (PDT) Subject: [e2e] Collaboration on Future Internet Architectures In-Reply-To: Message-ID: On Fri, 11 May 2007, Jon Crowcroft wrote: > In missive , Vadim Antonov typed: > > >>People who claim that increasing the density of raido nodes will increase > >>the per-node bandwidth (or at least leave it unchanged) are simply not > >>good with arithmetic. > > conversely, at geometry > > try a volume, not a plane. the number of alternate paths the the volume > goes up faster, and one can use lots of disperity tricks (path, code etc) > to make the alternates only have epsilon interference - if you then alternate > dynamic power over a short haul hop to spread the signal to a neighbourhood, > with dynamic coding for longer haul to get the message to the next neighbourhood, > you get capacity within epsilon*Nhops of N - conjecture: a sequence of > "knights moves" of 1 hop up, 2 hops forward can tile a volume in a systematic way and use the > scheme above (due to Tse) in a very easy to self organised fashion... You're talking about technology, not about scaling. The path and code dispersion tricks work just as well for nodes placed on some 2D surface. Regarding scaling, with volume density of nodes in the network d the received signal power is proportional to d^(2/3) while noise power is proportional to d. If transmitters emit any RF energy only during actual data transmission, the transmitter duty cycle (given some constant S/N required by the technology) goes down with increased density as 1/(d^(1/3)). The average path length (in hops) increases with density as d^(1/3). Thus the amount of bandwidth between fixed points in space depends on 3D density of nodes as 1/(d^(2/3)). Which is even worse than 2D case. Note that this result does not depend on communication scheduling, antennae directionality, etc, etc, etc. Improvements in any of those are merely constants, and do not affect scaling properties of the system. > Imagine... I don't need to imagine when I can calculate. The saving grace of the smart dust is not in the density of motes, but rather in ability to shift to higher frequencies (optical and above) because reduced distances reduce high-frequency signal scattering in the atmosphere. (Actually, the same is true for macroscopic radio systems... with "atmosphere" being replaced with buildings, trees, fences, and such). --vadim From dpreed at reed.com Mon May 14 12:03:54 2007 From: dpreed at reed.com (David P. Reed) Date: Mon, 14 May 2007 15:03:54 -0400 Subject: [e2e] It's all my fault In-Reply-To: <464887EC.1020502@isi.edu> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> Message-ID: <4648B29A.30202@reed.com> Joe Touch wrote: > Discussions of the issues is, as always, welcome. > No problem. I am eager to discuss the basic rationale fo9r removing an end-to-end capability from users to enhance the value of the network for applications. It should not be based on claims of harm that are unsubstantiated and unsubstantiatable. A factor of 80 in harm due to RH0 is baldly asserted. I'd like to see data, or a proof, or even a technical argument. If someone could point us to such a measurement of harm - in particular actual demonstrated harm, rather than fear of harm - that would be great. One known benefit of source routing is support for edge-based multipath routing, incorporating knowledge about application needs into the decision to have resilient path selection (either concurrently or as a hot spare that is kept alive and measured for congestion). That is one of the technical arguments made in Saltzer, Reed Clark - Source Routing for Campus-wide Internet Transport (finally published in 1980). Others can be found there as well, and were well-discussed beginning with the beginnings of the Internet design, and continuing up to and through the standards track evolution of IPv6. Active use of source routing in research contexts continue today - despite attempts by "firewall mavens" to declare source routing to be a "security hole" without any evidence. If a feature is to be effectively removed from IPv6 that has many uses, that removal should be justified by more than a vituperative attack at CanSecWest on IETF and its processes, coupled with a false assertion of a claim that :"source routing" was invented solely for mobile users. It wasn't even invented for mobile users primarily, much less solely. From an end-to-end protocol point of view it has always been unclear that routing should be centrally controlled. AS's are in charge of their own routing - though many choose to adopt common solutions, the IP standard *deliberately* does not specify how routing is to be done, and explicity includes the option of source routing as a choice. > From detlef.bosau at web.de Mon May 14 13:28:22 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 14 May 2007 22:28:22 +0200 Subject: [e2e] I got lost in opportunistic scheduling. In-Reply-To: <7.0.1.0.2.20070514143809.02813318@antd.nist.gov> References: <4616E722.3070402@web.de> <46487D95.4040104@web.de> <7.0.1.0.2.20070514143809.02813318@antd.nist.gov> Message-ID: <4648C666.9000607@web.de> marbukh at antd.nist.gov wrote: > It appears that problems you touched are pretty much open. Hopefully :-) At the moment, I see two possible problems: - Either I?m too stupid to find the solutions in literature, - or I?m too stupid to find the solutions myself ;-) And the more I try to understand these issues, the more I see, that this seems to be really difficult. > > Opportunistic scheduling allows one to achieve > the maximum theoretical end-to-end throughput region > without knowing the pattern of link capacity variability, > e.g., due to fading, mobility, etc. > O.k., so my guess is correct: The reason for op. sch. is to achieve maximum spectral efficiency ( = throughput / bandwidth), correct? If so, I finally have understood, why we?re doing this :-) > The problem is that it can be done at the expense of > the end-to-end delays, while throughput/delay trade-offs > in variable connectivity networks with opportunistic scheduling > is to a large degree an open problem. > Fine :-) > Some initial ideas include delay-limited bandwidth, > but as far as I know these ideas have been developed > only for cellular networks. > To my understanding, opportunistic scheduling mainly exploits multi user diversity, sometimes it?s metioned in conjuncition with multi path diversity and thus with the MIMO- and beamforming stuff. To my understanding, both approaches / ideas primarily attempt to mitigate the effects of fast faiding (typically modeled as Rayleigh fading) in wireless networks, hcne things become interesting for _fast_ moving users. (whatever may be the meaning of "fast (tm)"). (A rough definition of fast is "neither still standing nor pedestrian".) What makes things extremely difficult is that I have absolutely no idea how to model the wireless channel. (I?m computer scientist and no communication engineer, so I?m in the need of advice here.) Ideally, I would appreciate a model which yields a BLER with respect to time. However, I don?t know whether we have those models. And I dare not to think about HARQ there, because a simple BLER model perhaps will not be sufficient when it comes to adaptive puncturing which is as well a technique to adapt to fast fading and wich to my understanding also may change delay because it changes the "payload length" of a radio block. O.k., I learned that CE people do not understand me here, so it changes the code rate with respect to time. %-) I got in touch with a colleague here in Germany about this topic, but at the moment we both got mad about the differences in terminology. 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 L.Wood at surrey.ac.uk Mon May 14 13:47:24 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Mon, 14 May 2007 21:47:24 +0100 Subject: [e2e] It's all Farber's fault In-Reply-To: <4648B29A.30202@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> Message-ID: <200705142047.VAA04296@cisco.com> If only Farber had patented source routing, we wouldn't be using it, and wouldn't be having this tedious discussion. From faber at ISI.EDU Mon May 14 14:04:16 2007 From: faber at ISI.EDU (Ted Faber) Date: Mon, 14 May 2007 14:04:16 -0700 Subject: [e2e] It's all my fault In-Reply-To: <46460A3A.2030004@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <4645F6B0.1090004@piuha.net> <46460A3A.2030004@reed.com> Message-ID: <20070514210416.GA2264@hut.isi.edu> On Sat, May 12, 2007 at 02:40:58PM -0400, David P. Reed wrote: > There is a rather nice analysis of the utility of source routing that > Jerry Saltzer and I wrote many years ago. Must be this one (first Google hit) or you'd've been more specific. http://web.mit.edu/Saltzer/www/publications/sourcerouting/SourceRouting.html I haven't looked it over yet, but I can't help but notice the word "Campus" in the title. -- 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://mailman.postel.org/pipermail/end2end-interest/attachments/20070514/d8a9ec93/attachment.bin From randy at psg.com Mon May 14 14:45:36 2007 From: randy at psg.com (Randy Bush) Date: Mon, 14 May 2007 23:45:36 +0200 Subject: [e2e] It's all my fault In-Reply-To: <20070514210416.GA2264@hut.isi.edu> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <4645F6B0.1090004@piuha.net> <46460A3A.2030004@reed.com> <20070514210416.GA2264@hut.isi.edu> Message-ID: <4648D880.2050805@psg.com> on the production internet, source routing has been occasionally used to enforce strange aups; and that usually did not last for long. lsr traceroute is occasionally used for inter-provider debugging at inter-provider borders only. it allows provider A to know how provider B is forwarding (and hence implies routing info) for a prefix without having to have complex inter-noc email/voice. randy From huitema at windows.microsoft.com Mon May 14 15:12:48 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Mon, 14 May 2007 15:12:48 -0700 Subject: [e2e] It's all my fault In-Reply-To: <4648B29A.30202@reed.com> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > One known benefit of source routing is support for edge-based multipath > routing, incorporating knowledge about application needs into the > decision to have resilient path selection (either concurrently or as a > hot spare that is kept alive and measured for congestion). That is > one > of the technical arguments made in Saltzer, Reed Clark - Source Routing > for Campus-wide Internet Transport (finally published in 1980). Others > can be found there as well, and were well-discussed beginning with the > beginnings of the Internet design, and continuing up to and through the > standards track evolution of IPv6. Active use of source routing in > research contexts continue today - despite attempts by "firewall > mavens" > to declare source routing to be a "security hole" without any evidence. There is an obvious tension between source routing and traffic engineering. The security concern with denial of service by spiral routes is only an extreme example of that tension. Fundamentally, source routing allows users to direct traffic on user-chosen routes across the network. Users sees that as a great way to go around network limitations. Network owners see that as bypassing their policy or engineering decisions of the network providers. The old UUCP path rewriting logic was a solution to that tension. Usenet relied on source routing, so they had to support it but they went to extreme lengths to tame it. Usenet was relatively low bandwidth, so it was OK to check the path before forwarding a file. Modern IP networks are supposed to forward packets in a fraction of micro second, they cannot really rewrite paths as they go along, so they end up simply dropping the packets. -- Christian Huitema From randy at psg.com Mon May 14 15:15:16 2007 From: randy at psg.com (Randy Bush) Date: Tue, 15 May 2007 00:15:16 +0200 Subject: [e2e] It's all my fault In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <4648DF74.3040002@psg.com> > The old UUCP path rewriting logic was a solution to that tension. Usenet > relied on source routing, so they had to support it but they went to > extreme lengths to tame it. Usenet was relatively low bandwidth, so it > was OK to check the path before forwarding a file. before we really rathole, uucp != the usenet From huitema at windows.microsoft.com Mon May 14 15:20:56 2007 From: huitema at windows.microsoft.com (Christian Huitema) Date: Mon, 14 May 2007 15:20:56 -0700 Subject: [e2e] It's all my fault In-Reply-To: <4648DF74.3040002@psg.com> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640485DDCE@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > > The old UUCP path rewriting logic was a solution to that tension. > Usenet > > relied on source routing, so they had to support it but they went to > > extreme lengths to tame it. Usenet was relatively low bandwidth, so > it > > was OK to check the path before forwarding a file. > > before we really rathole, uucp != the usenet Yes. Sorry about that. Should have written UUCP all the way. From our neck of the wood in the early 80's, the two pretty much appeared as one, but that certainly is not the case anymore. -- Christian Huitema From randy at psg.com Mon May 14 15:35:44 2007 From: randy at psg.com (Randy Bush) Date: Tue, 15 May 2007 00:35:44 +0200 Subject: [e2e] It's all my fault In-Reply-To: <4648B29A.30202@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> Message-ID: <4648E440.5080602@psg.com> > One known benefit of source routing is support for edge-based multipath > routing on the real internet, s/known/theoretical/ btw, i am not against source routing. but i am strongly for reality based discussion. on that line, do folk have more minimal proposals for plugging the rthdr0 hole? randy From day at std.com Mon May 14 16:26:31 2007 From: day at std.com (John Day) Date: Mon, 14 May 2007 19:26:31 -0400 Subject: [e2e] It's all Farber's fault In-Reply-To: <200705142047.VAA04296@cisco.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <200705142047.VAA04296@cisco.com> Message-ID: At 21:47 +0100 2007/05/14, Lloyd Wood wrote: >If only Farber had patented source routing, we wouldn't be using it, >and wouldn't be having this tedious discussion. I tell my students that source routing is a male thing: The same as refusing to stop and ask directions. ;-) From gds at best.com Mon May 14 16:37:39 2007 From: gds at best.com (Greg Skinner) Date: Mon, 14 May 2007 23:37:39 +0000 Subject: [e2e] It's all my fault In-Reply-To: <4648DF74.3040002@psg.com>; from randy@psg.com on Tue, May 15, 2007 at 12:15:16AM +0200 References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> Message-ID: <20070514233739.A61045@gds.best.vwh.net> On Tue, May 15, 2007 at 12:15:16AM +0200, Randy Bush wrote: > Christian Huitema wrote: > > The old UUCP path rewriting logic was a solution to that tension. Usenet > > relied on source routing, so they had to support it but they went to > > extreme lengths to tame it. Usenet was relatively low bandwidth, so it > > was OK to check the path before forwarding a file. > > before we really rathole, uucp != the usenet Actually, usenet posts were not distributed via source routing. They were exchanged with neighboring sites. The "bang paths" that were generated as a result of a post making its way through usenet were used by uucp mail as a reverse path to the original poster. Path rewriting (using programs such as pathalias) came into play as more optimal routes were able to be computed using the connectivity data from uucp maps. --gregbo From L.Wood at surrey.ac.uk Mon May 14 16:38:58 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Tue, 15 May 2007 00:38:58 +0100 Subject: [e2e] It's all Farber's fault In-Reply-To: References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <200705142047.VAA04296@cisco.com> Message-ID: <200705142339.AAA15419@cisco.com> At Monday 14/05/2007 19:26 -0400, John Day wrote: >At 21:47 +0100 2007/05/14, Lloyd Wood wrote: >>If only Farber had patented source routing, we wouldn't be using it, and wouldn't be having this tedious discussion. > >I tell my students that source routing is a male thing: The same as refusing to stop and ask directions. ;-) Actually, source routing comes out of the confluence of identity and location in address. If we had clear separation there, we wouldn't have source routing... From detlef.bosau at web.de Mon May 14 17:33:53 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 15 May 2007 02:33:53 +0200 Subject: [e2e] It's all my fault In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640485DDCE@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDCE@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <4648FFF1.5050006@web.de> Christian Huitema wrote: >> >> before we really rathole, uucp != the usenet >> > > Yes. Sorry about that. Should have written UUCP all the way. From our > neck of the wood in the early 80's, the two pretty much appeared as one, > but that certainly is not the case anymore. > > -- Christian Huitema > But didn?t this mixup, if by accident, match the point? Basically, the good ol? bang path offered a neat way to add application based routing / overlay networks to a heterogeneous world. And this kind of routing was active until recently / is still active, e.g. when you are offered to take part in the usenet by uucp. So basically, when we talk about source routing, we talk about heterogenous overlay networks. These are well known, pretty understood, work fine. There are many well known applications for that, usenet news, Internet mail, SAP and saprouter, EDI in all flavours, only to name a few. (And even Geocast is to come :-)) In my humble opinion, we have seen a more elegant way for interconnecting heteregenous systems and to offer things like - path transparency, - path redundancy, - reliability and avoiding single points of failure. It?s called the Internet and IP :-) Basically, I tend to agree with Lloyd. I think, if we did not knew about source routing - we surely wouldn?t miss it. And even for overlay networking, I wonder whether we really need _application_ _based_ routing. If we need a mesh of nodes for a certain application, SAP, IRC, usenet, mail, skype, whatever, isn?t it sufficient to assign an IP address to these and then to rely upon well known and well understood internetworking techniques? And of course _with_ end to end path transparency, end to end path redundancy etc.? Perhaps it?s advisable to provide some mapping between application specific names (organisational, geographical, functional, whatever) to IP adresses. Perhaps, I have a somewhat restricted way of thinking there, but I always think of the DNS as a model for services like that and that one should provide a similar service to applications if necessary - and that?s it. Basically there are two compelling reasons for doing so: 1.: It?s always a good idea to rely upon something that is known to work. 2.: K.I.S.S. (Keep It Small and Simple.) And it?s needless to say that the idea of end to end path transparency / redundancy / reliability cannot be overempasized here. It?s to my understaning _the_ very basic rationale behind the whole Internet. Detlef (who just thinks of saprouters - and that?s really an evil hack to undermine just _all_ security policies and routing / traffic engineering considerations one can think of. I always prefer the front door over the back door.) From day at std.com Mon May 14 17:24:35 2007 From: day at std.com (John Day) Date: Mon, 14 May 2007 20:24:35 -0400 Subject: [e2e] It's all Farber's fault In-Reply-To: <200705142339.AAA15419@cisco.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <200705142047.VAA04296@cisco.com> <200705142339.AAA15419@cisco.com> Message-ID: At 0:38 +0100 2007/05/15, Lloyd Wood wrote: >At Monday 14/05/2007 19:26 -0400, John Day wrote: >>At 21:47 +0100 2007/05/14, Lloyd Wood wrote: >>>If only Farber had patented source routing, we wouldn't be using >>>it, and wouldn't be having this tedious discussion. >> >>I tell my students that source routing is a male thing: The same >>as refusing to stop and ask directions. ;-) > >Actually, source routing comes out of the confluence of identity and >location in address. If we had clear separation there, we wouldn't >have source routing... You are right. That is an even better joke than mine. ;-) Good one! From detlef.bosau at web.de Mon May 14 17:41:29 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 15 May 2007 02:41:29 +0200 Subject: [e2e] It's all my fault In-Reply-To: <20070514233739.A61045@gds.best.vwh.net> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> <20070514233739.A61045@gds.best.vwh.net> Message-ID: <464901B9.9000303@web.de> Greg Skinner wrote: > > > Actually, As you say: _Actually_. And in case of all servers being connected to the Internet. It?s not that long ago that I had only usenet access via uucp and therefore, anything worked with good ol? bang paths. For both purposes, routing to the correct "rnews" node you want to send your news to and avoiding cycles / "backward flooding" as well. To my knowledge, usenet news started with uucp. From ggm at apnic.net Mon May 14 18:45:52 2007 From: ggm at apnic.net (George Michaelson) Date: Tue, 15 May 2007 11:45:52 +1000 Subject: [e2e] It's all my fault In-Reply-To: <46452F80.9040801@reed.com> References: <46452F80.9040801@reed.com> Message-ID: <20070515114552.7f8d0f4c@garlique.algebras.org> Did phone systems have toll-select and explicit long-haul select before IP networks? manually, I would argue yes. morally, I think asking the operator to connect your call via a specific path is loose-source.. (for quite a while, it paid to know the fax-attuned IDD prefix to hop off australia. the QDU's on the line were lower, and it took less traffic. It seemed to be easier to get round the IDD jogjam at christmas if you knew the prefix) back in the JANET coloured book day.. applications like mail had to have loose-source equivalent because they were lower-stack agile. the transforms on mail represented paths into the transports along the way were (to say the least) amusing, and the potential for mish-mash (ARPA to uk/janet to ARPA to uucp to DECNET to ..) fantastic. Yes, Peter Honeyman made life easier, in the sense that an offline pre-compute of the flatness to user at host worked. Sometimes I wish BGP was offline, and we had defined statics in the DFZ. -Geographics could work in that model, but I don't think you much want that raised here.. SERC mail was pretty flat, but I believe you could specific explicit paths. I don't think they mapped cleanly to X.25 hops, but my memory fades. (mostly, I (and I think everyone else) used X.25 PAD to hop onto the end system, and logged in to mail local users. I certainly did this to EMAS at Edinburgh from YKXA on SERCnet. But I do recall an explicit path notation in a Dec-10 inter-site mailsystem, and in the Jacob Palme news system which pre-dated UUCP/USENET as far as I know, on Tops-10) And I think several people independently (re)implemented mail level explicit path hacks into local mail transports. over and over again. These kinds of things meant that the clue-density for the userbase was higher, with respect to what the likely behaviours were for having explicit control of the lower level packet routing: mentally, you already had to know this kind of connectivity anyway. I only used the telnet @path options once myself. But I know of somebody who used it to force a path into a recalcitrant network when his interior route died on him. This was in the mod 1990s so its within living memory that people understood and expected to use this kind of thing, in extremis. I was very dissapointed when I discovered how small ATM network addressing was. Amazing to see a 19th Century circuit switched model with tiny numberspace for endpoint addressing, and lowly engineers in boilersuits polishing the shiny brass knobs on crossbar switching between elements in the path. You really DO know that its a specific lightpath sometimes. Should a network prevent people from directing packet-paths? Why? Should users expect to be able to direct packet paths? Why? cui bono? Beerworthy. But pragmatically, we've taken ourselves to a world where the dialogue, and the outcome are divorced from this discussion. -G From djm at mindrot.org Mon May 14 19:38:20 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 May 2007 12:38:20 +1000 (EST) Subject: [e2e] It's all my fault In-Reply-To: <4648B29A.30202@reed.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> Message-ID: On Mon, 14 May 2007, David P. Reed wrote: > Joe Touch wrote: > > Discussions of the issues is, as always, welcome. > > > No problem. I am eager to discuss the basic rationale fo9r removing an > end-to-end capability from users to enhance the value of the network for > applications. It should not be based on claims of harm that are > unsubstantiated and unsubstantiatable. > > A factor of 80 in harm due to RH0 is baldly asserted. I'd like to see data, > or a proof, or even a technical argument. If someone could point us to such a > measurement of harm - in particular actual demonstrated harm, rather than fear > of harm - that would be great. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf It is a simple consequence of the fact that you can stuff over 40 address pairs into a RH0, and each pair causes a round trip. -d From jnc at mercury.lcs.mit.edu Mon May 14 19:39:59 2007 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 14 May 2007 22:39:59 -0400 (EDT) Subject: [e2e] It's all Farber's fault Message-ID: <20070515023959.4524287307@mercury.lcs.mit.edu> > From: Lloyd Wood > Actually, source routing comes out of the confluence of identity and > location in address. If we had clear separation there, we wouldn't have > source routing... No. Path != destination. Think about the real-world analogy. My identity and my address are different, but still, if you want to drive to my house, you still might want to control the path you take to get there (which is all the source-routing is - path control by the entity using the service, rather than by the service itself). Noel From Jon.Crowcroft at cl.cam.ac.uk Mon May 14 22:59:08 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 15 May 2007 06:59:08 +0100 Subject: [e2e] It's all my fault In-Reply-To: <20070515114552.7f8d0f4c@garlique.algebras.org> References: <46452F80.9040801@reed.com> <20070515114552.7f8d0f4c@garlique.algebras.org> Message-ID: exactly - the benefits of long haul provider selection are clear note also source route is not necessarily spiral routing (as christian huiteman said) - BGP already results in longer routes than "optimal" in the user sense, and for the same reasons that users want to choose different carriers in phone nets (price, performance, mileage deals), there are sound business reasons for users to ask for different IP segements to there paths - see the MIT RON papers to see how this can be done with overlays to improve resilience. current IP routing is not optimal since it is about expressing ISP business relationshios, not user preferences - the balance has tipped way too far - all the "business case" arguments you hear in favour or against his or that IP technologiy are almost always about ISPs or router vendors rather than users - if the people making these arguments actually were on the sharp end of business, they'd be out of it pretty soon:) of course optimality (and rationality) have had little to do with IP design since the late 1980s... :-) on DDoS prevention/mitigation and ip (loose) source routing: since we have had ddos attacxks for some time without LSR, what is the actual evidence that LSR makes it i) harder to mitgate ii) easier to find the source? given the source is a traffic generator (and often distributed over a botnet) the ways to find it and mitgate it are based on detecting an unusual set of destiantions and inter-transmission intervals to a wider than usual set of IP destinations, NEAR THE SOURCE, not at the sink where it is already too late whether the traffic goes via a "3rd party" (e.g. gosh, a router:), or taxi, plane, satellite, mars lander, or via your pet cat's radio in her golf ball is irrelevant - if you're looking there, you've already missed the bus. In missive <20070515114552.7f8d0f4c at garlique.algebras.org>, George Michaelson typed: >> >>Did phone systems have toll-select and explicit long-haul select before >>IP networks? manually, I would argue yes. morally, I think asking the >>operator to connect your call via a specific path is loose-source.. >> >>(for quite a while, it paid to know the fax-attuned IDD prefix to hop >>off australia. the QDU's on the line were lower, and it took less >>traffic. It seemed to be easier to get round the IDD jogjam at >>christmas if you knew the prefix) >> >>back in the JANET coloured book day.. applications like mail had to >>have loose-source equivalent because they were lower-stack agile. the >>transforms on mail represented paths into the transports along the way >>were (to say the least) amusing, and the potential for mish-mash (ARPA >>to uk/janet to ARPA to uucp to DECNET to ..) fantastic. Yes, Peter >>Honeyman made life easier, in the sense that an offline pre-compute of >>the flatness to user at host worked. Sometimes I wish BGP was offline, and >>we had defined statics in the DFZ. -Geographics could work in that >>model, but I don't think you much want that raised here.. >> >>SERC mail was pretty flat, but I believe you could specific explicit >>paths. I don't think they mapped cleanly to X.25 hops, but my memory >>fades. (mostly, I (and I think everyone else) used X.25 PAD to hop onto >>the end system, and logged in to mail local users. I certainly did this >>to EMAS at Edinburgh from YKXA on SERCnet. But I do recall an explicit >>path notation in a Dec-10 inter-site mailsystem, and in the Jacob Palme >>news system which pre-dated UUCP/USENET as far as I know, on Tops-10) >>And I think several people independently (re)implemented mail level >>explicit path hacks into local mail transports. over and over again. >> >>These kinds of things meant that the clue-density for the userbase was >>higher, with respect to what the likely behaviours were for having >>explicit control of the lower level packet routing: mentally, you >>already had to know this kind of connectivity anyway. >> >>I only used the telnet @path options once myself. But I know of >>somebody who used it to force a path into a recalcitrant network when >>his interior route died on him. This was in the mod 1990s so its within >>living memory that people understood and expected to use this kind of >>thing, in extremis. >> >>I was very dissapointed when I discovered how small ATM network >>addressing was. Amazing to see a 19th Century circuit switched model >>with tiny numberspace for endpoint addressing, and lowly engineers in >>boilersuits polishing the shiny brass knobs on crossbar switching >>between elements in the path. You really DO know that its a specific >>lightpath sometimes. >> >>Should a network prevent people from directing packet-paths? Why? >>Should users expect to be able to direct packet paths? Why? >> >>cui bono? >> >>Beerworthy. But pragmatically, we've taken ourselves to a world where >>the dialogue, and the outcome are divorced from this discussion. >> >> >>-G cheers jon From gds at best.com Mon May 14 23:57:57 2007 From: gds at best.com (Greg Skinner) Date: Tue, 15 May 2007 06:57:57 +0000 Subject: [e2e] It's all my fault In-Reply-To: <464901B9.9000303@web.de>; from detlef.bosau@web.de on Tue, May 15, 2007 at 02:41:29AM +0200 References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> <20070514233739.A61045@gds.best.vwh.net> <464901B9.9000303@web.de> Message-ID: <20070515065757.A61621@gds.best.vwh.net> On Tue, May 15, 2007 at 02:41:29AM +0200, Detlef Bosau wrote: > As you say: _Actually_. And in case of all servers being connected to > the Internet. It?s not that long ago that I had only usenet access via > uucp and therefore, anything worked with good ol? bang paths. For both > purposes, routing to the correct "rnews" node you want to send your news > to and avoiding cycles / "backward flooding" as well. Hmmm ... I'm not aware of people commonly using source routing to get their news posted at a news server of their choice. While I suppose it was theoretically possible (if one had permission to execute uux directly), it would defeat the purpose of having the articles distributed to all of the intermediate news servers along the path (assuming they ran usenet news). And the articles from the receiving news site would eventually make their way back along the source-routed path, thus wasting the initial uux. OTOH, anyone with access to a mail UA could specify their own path for their mail, even paths that were not the result of the distribution of usenet articles. Those individuals who had knowledge of uucp topology could often find better paths than those the usenet articles took. (In some cases, uucp paths existed that did not also involve usenet news transfer.) The path rewriting of pathalias actually served as a traffic engineering aid, rather than as a means of circumventing policy. Usenet neighbors tended to be chosen for reasons of convenience, rather than as a result of careful engineering. Pathalias actually reduced the overall number of hops email took between uucp nodes, and made reasonable attempts to use the best performance paths. Some of those best performance paths went via the old ARPAnet, which was a controversial subject at the time, especially among site managers who were concerned that such "transit" was in violation of their ARPAnet authorization. Paths that performed less well might also have transited the old ARPAnet, as there were ARPAnet sites who remotely executed rnews over TCP connections. (And eventually uucp was rewritten to use TCP connections.) --gregbo From jeroen at unfix.org Tue May 15 02:05:12 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 15 May 2007 10:05:12 +0100 Subject: [e2e] It's all my fault In-Reply-To: <4648E440.5080602@psg.com> References: <46452F80.9040801@reed.com> <4645D5F1.5030801@psg.com> <46460728.4050006@reed.com> <464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <4648E440.5080602@psg.com> Message-ID: <464977C8.5050403@spaghetti.zurich.ibm.com> Randy Bush wrote: >> One known benefit of source routing is support for edge-based multipath >> routing > > on the real internet, s/known/theoretical/ > > btw, i am not against source routing. but i am strongly for reality based > discussion. on that line, do folk have more minimal proposals for plugging > the rthdr0 hole? Use uRPF as per BCP38, that will at least keep it in your internal network, thus filter the header at the borders and some other key locations and presto, see also my flamishbait at: http://lists.cluenet.de/pipermail/ipv6-ops/2007-May/001344.html Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070515/70b75be8/signature.bin From kelsayed at gmail.com Tue May 15 02:40:18 2007 From: kelsayed at gmail.com (Khaled Elsayed) Date: Tue, 15 May 2007 12:40:18 +0300 Subject: [e2e] I got lost in opportunistic scheduling. In-Reply-To: <4648C666.9000607@web.de> References: <4616E722.3070402@web.de> <46487D95.4040104@web.de> <7.0.1.0.2.20070514143809.02813318@antd.nist.gov> <4648C666.9000607@web.de> Message-ID: <46498002.9000903@gmail.com> Detlef, There are some papers that discuss the relation between OS at MAC/PHY and TCP. For example check http://www.isr.umd.edu/~baras/publications/reports/2002/SrinivasanB_TR_2002-48.htm But there are also more recent stuff. I think that implementation of pure OS without some compensation for users with consistent bad channels does not make sense. I have some results on that for RT services that was published in MSWIM 2004. E-mail me if interested. Khaled From avg at kotovnik.com Tue May 15 03:44:43 2007 From: avg at kotovnik.com (Vadim Antonov) Date: Tue, 15 May 2007 03:44:43 -0700 (PDT) Subject: [e2e] It's all my fault In-Reply-To: Message-ID: "I need source routing" is an euphemism for "my TE sucks". The fundamental problem with SR is that endpoints do not have information about network topology necessary for making intelligent path choices. It is as simple as that. If you really want end hosts (and not gateways which actually know which trunks are up and which are down and what the preferences are because they do the little pesky things like ISIS, OSPF and BGP) to control which path is taken, use the gawd-given TOS field to mark the packets. And add some rules to the gateway route maps. This way you can have both path selection *and* ability to route around failures. I never ever in my long career as a backbone engineer had any legitimate need to use SR options. As a network hardware and software designer I spent quite a few of my grey cells trying to figure how to handle the damn options fast enough in silicon so as to prevent script kiddies from DDOSing the boxes to death. So, here we are - having a lot of crud (which, by the way, most vendors get wrong, which never seems to bother anyone because nobody actually uses it) in the fast path because somebody somewhere thought that source routing is a neat trick. Oh. And SR is not really a security problem simply because the first thing most real firewalls do is dropping all packets with these IP options. Simply put, SR is a Bad Idea. Just like not preserving port numbers in fragments, or doing ARP instead of simply programming NICs to map IP addresses to low-order bytes of MAC addresses. For a host stack designer these are mere annoyances (though if I had a buck every time I saw a buggy ARP implementation... heh), but working around these little cute design "features" at 10G makes life truly miserable. Keep It Simple. --vadim From detlef.bosau at web.de Tue May 15 04:19:06 2007 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 15 May 2007 13:19:06 +0200 Subject: [e2e] It's all my fault In-Reply-To: <20070515065757.A61621@gds.best.vwh.net> References: <46452F80.9040801@reed.com><4645D5F1.5030801@psg.com> <46460728.4050006@reed.com><464887EC.1020502@isi.edu> <4648B29A.30202@reed.com> <70C6EFCDFC8AAD418EF7063CD132D0640485DDBF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4648DF74.3040002@psg.com> <20070514233739.A61045@gds.best.vwh.net> <464901B9.9000303@web.de> <20070515065757.A61621@gds.best.vwh.net> Message-ID: <4649972A.7070203@web.de> Greg Skinner wrote: > On Tue, May 15, 2007 at 02:41:29AM +0200, Detlef Bosau wrote: > >> As you say: _Actually_. And in case of all servers being connected to >> the Internet. It?s not that long ago that I had only usenet access via >> uucp and therefore, anything worked with good ol? bang paths. For both >> purposes, routing to the correct "rnews" node you want to send your news >> to and avoiding cycles / "backward flooding" as well. >> > > Hmmm ... I'm not aware of people commonly using source routing to get > their news posted at a news server of their choice. Me neither :-) In my early usenet days, I did neither use IP nor did I use source routing. I made a phone / modem call with my PC to the neighbour node and sent/received my news batches via UUCP. And my neighbour node made phone calls (o.k., with an X.25 adaptor) to its neighbour nodes - and exchanged batches via UUCP. That?s were the term "store and forward" stems from: When your disk runs out of space, - store any incoming uucp batches on a quarter inch tape and if there?s no chance to deliver it via uucp, - forward the material to the reciever via your prefered parcel service. You may ridicule about this, but that?s the way I sent and received news up to 2000. Mail as well. And it?s highly efficient! My acutal ADSL provider still provides news access via UUCP, however this is UUCP over TCP and not the good ol? modem/POTS system :-) -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From chk at pobox.com Tue May 15 05:33:55 2007 From: chk at pobox.com (Harald Koch) Date: Tue, 15 May 2007 08:33:55 -0400 Subject: [e2e] It's all my fault In-Reply-To: References: Message-ID: <4649A8B3.7080000@pobox.com> Vadim Antonov wrote: > I never ever in my long career as a backbone engineer had any legitimate > need to use SR options. The LSRR option to traceroute was incredibly useful for debugging routing problems during CA*net's transition from the NSFnet to MCI back in 1994 (we were one of the first NSFnet "regionals" to leave, if I recall correctly). Of course, I only had a short career as a backbone engineer before leaping into network security, where I saw first-hand the "fun" that one could have with those same LSRR options. I straddle the fence on this one. Like so many other things in life, source routing is a tool that can be used for Good or Evil... -- Harald Koch chk at pobox.com From Jon.Crowcroft at cl.cam.ac.uk Tue May 15 06:22:29 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 15 May 2007 14:22:29 +0100 Subject: [e2e] It's all my fault In-Reply-To: <4649A8B3.7080000@pobox.com> References: <4649A8B3.7080000@pobox.com> Message-ID: if we took ALL routing out of routers, life _would_ be simpler - you'd only have yourself to blame as an end user for shooting yo