From bwong at cs.cornell.edu Tue Nov 1 09:11:24 2005 From: bwong at cs.cornell.edu (Bernard Wong) Date: Tue, 01 Nov 2005 12:11:24 -0500 Subject: [e2e] Closestnode.com announcement Message-ID: <4367A1BC.8070200@cs.cornell.edu> We are writing to announce closestnode.com, a free, non-commercial service that we have recently deployed for directing clients to servers and peers that are close to them. Closestnode.com can be used for mapping clients to the closest DHT node, for selecting a nearby mirror a user can download content from, or for finding the closest game server a user can connect to in multiplayer online games. The service is very simple to use: You register a unique application name with us on the web (e.g. mycoolapp) and either link our library into your application or run our standalone program along your server nodes. Once that is done, any node performing a DNS lookup for mycoolapp.closestnode.com will receive the IP address of the the closest (lowest latency) node to itself that is currently running the mycoolapp application. Closestnode.com can be used to implement a generic anycast service. It supports hosts behind firewalls and NAT boxes. One caveat is that a cold lookup with unprimed caches may take up to a few hundred ms, so this system is best suited for distributed systems where sessions last a few seconds or more. More information, code and demos are available at http://www.closestnode.com. The system is an offshoot of recent research at Cornell university, described in the following paper: http://www.cs.cornell.edu/people/egs/papers/meridian-sigcomm05.pdf Don't hesitate to contact us if you have any questions. Best, Bernard, Alex, Gun. From jshen_cad at yahoo.com.cn Tue Nov 1 23:30:19 2005 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Wed, 2 Nov 2005 15:30:19 +0800 (CST) Subject: [e2e] not quite the differentiated services I was thinking of In-Reply-To: <4366C203.9040908@cs.columbia.edu> Message-ID: <20051102073019.8964.qmail@web15402.mail.cnb.yahoo.com> --- Ping Pan wrote: > Since when backbone QoS is designed for SPAM > prevention? :-) If you have > that much SPAM to contribute, the service providers > need to disconnect > you first. ;-) > I just mean current QoS mechanism does not help with those application level control requirement, but only focus on congestion alleviation. Both Diffserv and RSVP assume there will be congestion. Unfortunately, that's the common fact with narrowband internet but not with broadband internet.To my knowledge, congestion usually happens on interconnection links between ISPs ( e.g. between Chinanet and Sprint). But with differserv I can't guarantee a VIP that his/her access speed to any web site is faster than others. So, I need traffic management rather than DiffServ. To summurize : 1. Current QoS mechanism , Diffserv + CBWFQ, does not address the critical problem faced by Internet. ISPs need application level e2e QoS control even when they overprovision their network. 2. WRED does not show its value because application characteristics changes ( robust P2P contributes to that a lot) 3. Even with DiffServ itself, there is problem unsolved, e.g. security, network administration, network planning and SLA between ISPs. 4. IMHO, Internet should be with such a model, backbone is overprovisioned with a few intelligence (traffic engineering); more and more intelligence is built into access layer node. 5. We have to pay more attention to security problem and traffic identification requirement ( there is workshop on this in Sigcomm2005 ) Jing > Jing Shen wrote: > > --- Clark Gaylord : > > > >>That's why we have a protocol that is designed to > >>withstand nuclear war. > >> > > > > > > So, no QoS needed in backbone network; SPAM could > be > > transferred everywhere .... ??? > > > > I found this in Andrew's paper list,interesting > > > > > > > http://www.rnejournal.com/abstract_odlyzko_sept04.html > > > > Jing > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________ > > > ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä > > http://cn.mail.yahoo.com > ___________________________________________________________ ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä http://cn.mail.yahoo.com From aaa at cs.stanford.edu Thu Nov 3 18:35:39 2005 From: aaa at cs.stanford.edu (Amr A. Awadallah) Date: Thu, 03 Nov 2005 18:35:39 -0800 Subject: [e2e] Closestnode.com announcement In-Reply-To: <4367A1BC.8070200@cs.cornell.edu> References: <4367A1BC.8070200@cs.cornell.edu> Message-ID: <436AC8FB.5030700@cs.stanford.edu> Very cool. Does ClosetNode provide support for finding a server that is closest to multiple-clients at same time ? Specifically, for multiplayer clan matches, suppose there is 16 players (8 on each team), and there is 2000 game host servers distributed across the world available for hosting the match. Can we find where is the closet node to all 16 players such that the ping-differential between the players is minimized ? (note that a node that is actually further away on average, but reduces the delta between the players is preferred). The reason ping-differential is so important is to ensure fairness, otherwise certain players get the updates from the game server before other players (and hence can kill the other players in their future before they even see them !) Thanks, -- amr Bernard Wong wrote: > We are writing to announce closestnode.com, a free, non-commercial > service that we have recently deployed for directing clients to servers > and peers that are close to them. > > Closestnode.com can be used for mapping clients to the closest DHT node, > for selecting a nearby mirror a user can download content from, or for > finding the closest game server a user can connect to in multiplayer > online games. > > The service is very simple to use: You register a unique application > name with us on the web (e.g. mycoolapp) and either link our library > into your application or run our standalone program along your server > nodes. Once that is done, any node performing a DNS lookup for > mycoolapp.closestnode.com will receive the IP address of the the closest > (lowest latency) node to itself that is currently running the mycoolapp > application. > > Closestnode.com can be used to implement a generic anycast service. It > supports hosts behind firewalls and NAT boxes. One caveat is that a cold > lookup with unprimed caches may take up to a few hundred ms, so this > system is best suited for distributed systems where sessions last a few > seconds or more. > > More information, code and demos are available at > http://www.closestnode.com. The system is an offshoot of recent research > at Cornell university, described in the following paper: > > http://www.cs.cornell.edu/people/egs/papers/meridian-sigcomm05.pdf > > Don't hesitate to contact us if you have any questions. > > Best, > Bernard, > Alex, > Gun. From egs+e2e at cs.cornell.edu Thu Nov 3 20:12:55 2005 From: egs+e2e at cs.cornell.edu (Emin Gun Sirer) Date: Thu, 03 Nov 2005 23:12:55 -0500 Subject: [e2e] Closestnode.com announcement In-Reply-To: <436AC8FB.5030700@cs.stanford.edu> References: <4367A1BC.8070200@cs.cornell.edu> <436AC8FB.5030700@cs.stanford.edu> Message-ID: <1131077575.14062.39.camel@localhost.localdomain> Hi Amr, Good point - finding a centrally located node is often critical. Game servers would benefit from being centrally located (frankly, we thought of it purely as a performance enhancement since everyone would see lower server ping times, but your note points out that central leader election is _required_ to avoid giving some people an unfair advantage!). Content distribution/streaming multicast services may want to pick centrally located nodes for internal nodes of a distribution tree. The system we built, Meridian, that enables closestnode.com to return the closest node to a client can also be used for selecting a centrally located node. This is one of the three applications we implemented and measured for our SIGCOMM paper when evaluating Meridian (namely, the apps are closest node selection "find the closest server to me", central leader election "find the most central node among this given set of nodes", and multiple constraints "find a node within 50 ms. of the speakeasy colocation cluster in seattle, 30 ms. of cornell, and 25ms from the at&t peering point in virginia"). You can check it out through the "central leader election" demo here (http://www5.cs.cornell.edu/~bwong/deployment2.html). closestnode.com is a generic DNS front-end for the closest node application only. If you want to look up the most central node within a single set of nodes, we could create a new service called "centralleader.com" and run the central leader election algorithm in response to lookups for, say, mygame.centralleader.com. If this would be useful, we will be happy to support it. I suspect, though, that you will want to do central leader election from within sets that vary with each query. I.e. each query will have to specify the set of nodes among which it is trying to select the most central node. There is no way to do this elegantly with a DNS lookup, so you would be better off picking up the Meridian code (it's GPL'ed), and use it in your game clients to find centrally located nodes. We'll gladly help if you choose this route and have questions/suggestions etc. Best, Gun, Bernard & Alex. On Thu, 2005-11-03 at 18:35 -0800, Amr A. Awadallah wrote: > Very cool. > > Does ClosetNode provide support for finding a server that is closest to > multiple-clients at same time ? > > Specifically, for multiplayer clan matches, suppose there is 16 players > (8 on each team), and there is 2000 game host servers distributed across > the world available for hosting the match. Can we find where is the > closet node to all 16 players such that the ping-differential between > the players is minimized ? (note that a node that is actually further > away on average, but reduces the delta between the players is preferred). > > The reason ping-differential is so important is to ensure fairness, > otherwise certain players get the updates from the game server before > other players (and hence can kill the other players in their future > before they even see them !) > > Thanks, > > -- amr > > Bernard Wong wrote: > > > We are writing to announce closestnode.com, a free, non-commercial > > service that we have recently deployed for directing clients to servers > > and peers that are close to them. > > > > Closestnode.com can be used for mapping clients to the closest DHT node, > > for selecting a nearby mirror a user can download content from, or for > > finding the closest game server a user can connect to in multiplayer > > online games. > > > > The service is very simple to use: You register a unique application > > name with us on the web (e.g. mycoolapp) and either link our library > > into your application or run our standalone program along your server > > nodes. Once that is done, any node performing a DNS lookup for > > mycoolapp.closestnode.com will receive the IP address of the the closest > > (lowest latency) node to itself that is currently running the mycoolapp > > application. > > > > Closestnode.com can be used to implement a generic anycast service. It > > supports hosts behind firewalls and NAT boxes. One caveat is that a cold > > lookup with unprimed caches may take up to a few hundred ms, so this > > system is best suited for distributed systems where sessions last a few > > seconds or more. > > > > More information, code and demos are available at > > http://www.closestnode.com. The system is an offshoot of recent research > > at Cornell university, described in the following paper: > > > > http://www.cs.cornell.edu/people/egs/papers/meridian-sigcomm05.pdf > > > > Don't hesitate to contact us if you have any questions. > > > > Best, > > Bernard, > > Alex, > > Gun. > From inki at cs.bu.edu Sat Nov 5 09:20:52 2005 From: inki at cs.bu.edu (Niky Riga) Date: Sat, 05 Nov 2005 12:20:52 -0500 Subject: [e2e] ICNP 2005 sessions will be broadcasted Message-ID: <436CE9F4.8030905@cs.bu.edu> [Apologies if you receive multiple copies of this announcement, please feel free to distribute -- thanks] The sessions of ICNP 2005 are going to be broadcasted over the Internet using the End System Multicast. To check the ICNP program please visit: http://csr.bu.edu/icnp2005/program.htm To tune in and download the software follow the link: http://taj.cmcl.cs.cmu.edu/channels/detail/?uid=250&eid=1113 In addition to the live broadcast, participants will be able to interact with each other and comment on the panels through a web-based forum. These broadcasts are supported by IEEE ICNP (http://csr.bu.edu/icnp2005/index.htm), the Boston University WING Research Group (http://www.cs.bu.edu/groups/wing/) and the Carnegie Mellon University End System Multicast Research Project (http://esm.cs.cmu.edu). From matta at cs.bu.edu Sat Nov 5 12:52:56 2005 From: matta at cs.bu.edu (Ibrahim Matta) Date: Sat, 5 Nov 2005 15:52:56 -0500 Subject: [e2e] ICNP 2005 sessions will be broadcasted Message-ID: <0511C607B17F804EBE96FFECD1FD9859546858@cs-exs2.cs-nt.bu.edu> [Apologies if you receive multiple copies of this announcement, please feel free to distribute -- thanks] The sessions of ICNP 2005 are going to be broadcasted over the Internet using the End System Multicast. To check the ICNP program please visit: http://csr.bu.edu/icnp2005/program.htm To tune in and download the software follow the link: http://taj.cmcl.cs.cmu.edu/channels/detail/?uid=250&eid=1113 In addition to the live broadcast, participants will be able to interact with each other and comment on the panels through a web-based forum. These broadcasts are supported by IEEE ICNP (http://csr.bu.edu/icnp2005/index.htm), the Boston University WING Research Group (http://www.cs.bu.edu/groups/wing/), and the Carnegie Mellon University End System Multicast Research Project (http://esm.cs.cmu.edu). From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 7 02:28:16 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 07 Nov 2005 10:28:16 +0000 Subject: [e2e] SEuCN Message-ID: so reading re-feedback etc, and loss notification, wouldn't it be easier given most flows have feedback packets, to have an efficient common case encoding 1// the hop count in the net is rarely more than 32 so lets have a 32bit field which is called SEuCN and is Selective Explicit unCongested Notification. in outbound backets, each hop sets this bit (and its returned in acks) to say "all is well and good here". when combined with all the other dccp/xcp/tcp mechanisms you get all you want 97.3% of the time (explicit loss notification, and explicit congestion notification is stil explicit:) j. oh, ok, 64 bits then:) From rimac at bell-labs.com Mon Nov 7 12:54:02 2005 From: rimac at bell-labs.com (Ivica Rimac) Date: Mon, 07 Nov 2005 15:54:02 -0500 Subject: [e2e] SEuCN In-Reply-To: References: Message-ID: <436FBEEA.8080608@bell-labs.com> Hi Jon, > so reading re-feedback etc, and loss notification, wouldn't it be easier > given most flows have feedback packets, to have an efficient common case > encoding > 1// the hop count in the net is rarely more than 32 > so lets have a 32bit field which is called SEuCN > and is > Selective Explicit unCongested Notification. > > in outbound backets, each hop sets this bit > (and its returned in acks) to say "all is well and good here". I am curious how each hop would determine the bit it should set? Furthermore, since the bit is set in case there is no problem, how should an end node know that the x Zeros of the 32/64 bits are not an indication of problems but rather that the number of hops the packet passed is qual to 32/64-x? Hmm, might use the TTL field to determine the hop count and determining the corresponding bit at each hop ... But naivly asking, what do we gain for the transport layer mechanisms if we know how many hops are congested? It seems to me like the congestion level is much more interesting in order to apply different algorithms at different congestion levels on the transport layer (e.g., more aggresive increase algorithms, etc.), which however would require some mechanisms in the routers. Cheers, Ivica -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051107/7802a62e/smime.bin From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 7 14:23:19 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 07 Nov 2005 22:23:19 +0000 Subject: [e2e] SEuCN In-Reply-To: Message from Lloyd Wood of "Mon, 07 Nov 2005 21:13:37 GMT." Message-ID: can u say pgm In missive , Lloyd Wood typed: >>On Mon, 7 Nov 2005, Jon Crowcroft wrote: >> >>> so reading re-feedback etc, and loss notification, wouldn't it be easier >>> given most flows have feedback packets, to have an efficient common case >>> encoding >>> 1// the hop count in the net is rarely more than 32 >> >>Well, so much for multicast, where TTL thresholds are set. >> >>Can't we just fix the address shortage by reclaiming Class D addresses >>for CIDR and unicast? It's just a waste of space. >> >>L. >> >>or use it for HIP local scope identifiers? >> >> cheers jon From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 7 14:28:03 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 07 Nov 2005 22:28:03 +0000 Subject: [e2e] SEuCN In-Reply-To: Message from Ivica Rimac of "Mon, 07 Nov 2005 15:54:02 EST." <436FBEEA.8080608@bell-labs.com> Message-ID: well good question - gosh - perhaps routers can keep a per source prefix state saying what the ttl was, then use that as a "pretty good guess" as to the index to the bit position to set...for example.... lots of other soft state techniques suggest themselves... so why is this less good than ECN? seems like its moreinfo - what to do with it? well multiple bottlenecks remocing ambiguity of loss versus ecn lots of things really - miht be _really_ useful, for example, in a on demand MANET multihop route over wireless for example what do we gain in transport if we know how many and which hops are probably not congested AND didnt exaperience loss, on a per packet bassis? dunno - seems like information is better than no information tho:) like XCP-- In missive <436FBEEA.8080608 at bell-labs.com>, Ivica Rimac typed: >>This is a cryptographically signed message in MIME format. >> >>--------------ms060206000402050809000606 >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: 7bit >> >>Hi Jon, >> >>> so reading re-feedback etc, and loss notification, wouldn't it be easier >>> given most flows have feedback packets, to have an efficient common case >>> encoding >>> 1// the hop count in the net is rarely more than 32 >>> so lets have a 32bit field which is called SEuCN >>> and is >>> Selective Explicit unCongested Notification. >>> >>> in outbound backets, each hop sets this bit >>> (and its returned in acks) to say "all is well and good here". >> >>I am curious how each hop would determine the bit it should set? >>Furthermore, since the bit is set in case there is no problem, how >>should an end node know that the x Zeros of the 32/64 bits are not an >>indication of problems but rather that the number of hops the packet >>passed is qual to 32/64-x? Hmm, might use the TTL field to determine the >>hop count and determining the corresponding bit at each hop ... >>But naivly asking, what do we gain for the transport layer mechanisms if >>we know how many hops are congested? >>It seems to me like the congestion level is much more interesting in >>order to apply different algorithms at different congestion levels on >>the transport layer (e.g., more aggresive increase algorithms, etc.), >>which however would require some mechanisms in the routers. >> >>Cheers, From ikob at koganei.wide.ad.jp Mon Nov 7 16:38:55 2005 From: ikob at koganei.wide.ad.jp (Katsushi Kobayashi) Date: Mon, 7 Nov 2005 16:38:55 -0800 Subject: [e2e] SEuCN In-Reply-To: References: Message-ID: Hi, I submitted the mechanism to retrieve per hop router information using XCP-like mechanism. http://www.ietf.org/internet-drafts/draft-kobayashi-sirens-00.txt Although more than hop count packets is required to complete end-to-end path, the overhead may not be serious. That's why more than 800 packets are sent at a bandwidth of 100 Mbps, an RTT of 100 ms, and an MTU of 1500 bytes. Regards, On 2005/11/07, at 14:28, Jon Crowcroft wrote: > well good question - gosh - perhaps routers can keep a per source > prefix state saying what the ttl was, then use > that as a "pretty good guess" as to the index to the bit position > to set...for example.... > > lots of other soft state techniques suggest themselves... > > so why is this less good than ECN? seems like its moreinfo - > > what to do with it? well > multiple bottlenecks > remocing ambiguity of loss versus ecn > lots of things really - > > miht be _really_ useful, for example, in a on demand MANET multihop > route over wireless > > for example > > what do we gain in transport if we know how many and which hops are > probably not congested AND didnt exaperience > loss, on a per packet bassis? > > dunno - seems like information is better than no information tho:) > > like XCP-- > > In missive <436FBEEA.8080608 at bell-labs.com>, Ivica Rimac typed: > >>> This is a cryptographically signed message in MIME format. >>> >>> --------------ms060206000402050809000606 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> >>> Hi Jon, >>> >>>> so reading re-feedback etc, and loss notification, wouldn't it >>>> be easier >>>> given most flows have feedback packets, to have an efficient >>>> common case >>>> encoding >>>> 1// the hop count in the net is rarely more than 32 >>>> so lets have a 32bit field which is called SEuCN >>>> and is >>>> Selective Explicit unCongested Notification. >>>> >>>> in outbound backets, each hop sets this bit >>>> (and its returned in acks) to say "all is well and good here". >>> >>> I am curious how each hop would determine the bit it should set? >>> Furthermore, since the bit is set in case there is no problem, how >>> should an end node know that the x Zeros of the 32/64 bits are >>> not an >>> indication of problems but rather that the number of hops the packet >>> passed is qual to 32/64-x? Hmm, might use the TTL field to >>> determine the >>> hop count and determining the corresponding bit at each hop ... >>> But naivly asking, what do we gain for the transport layer >>> mechanisms if >>> we know how many hops are congested? >>> It seems to me like the congestion level is much more interesting in >>> order to apply different algorithms at different congestion >>> levels on >>> the transport layer (e.g., more aggresive increase algorithms, >>> etc.), >>> which however would require some mechanisms in the routers. >>> >>> Cheers, From rimac at bell-labs.com Tue Nov 8 08:24:42 2005 From: rimac at bell-labs.com (Ivica Rimac) Date: Tue, 08 Nov 2005 11:24:42 -0500 Subject: [e2e] SEuCN In-Reply-To: References: Message-ID: <4370D14A.2070409@bell-labs.com> Hello Jon, > well good question - gosh - perhaps routers can keep a per source prefix state saying what the ttl was, then use > that as a "pretty good guess" as to the index to the bit position to set...for example.... > > lots of other soft state techniques suggest themselves... but maybe we can even avoid any state just by using "encoding": initially, the sorce sets the lowest bit of each apcket to "1" and all others are set to "0". at each hop a bit-shift operation is performed and the lowest bit is set according to the congestion state. As a result, the routers do not have to worry about the index and the end host can extract the number of hops from the index of the "highest" 1. no ttl necessary. 8 bit example -------------- Sender: 0000 0001 1. Router (okay): 0000 0011 2. Router (cong): 0000 0110 .... 6. Roter (cong): 0110 1110 Receiver: 0110 1110 (To handle even overflow situations, we could use the highest bit for indication of overflow.) > > so why is this less good than ECN? seems like its moreinfo - obviuos, ECN uses just a single bit ;-) > what to do with it? well > multiple bottlenecks > remocing ambiguity of loss versus ecn > lots of things really - > > miht be _really_ useful, for example, in a on demand MANET multihop route over wireless > > for example > > what do we gain in transport if we know how many and which hops are probably not congested AND didnt exaperience > loss, on a per packet bassis? > > dunno - seems like information is better than no information tho:) > > like XCP-- > > In missive <436FBEEA.8080608 at bell-labs.com>, Ivica Rimac typed: > > >>This is a cryptographically signed message in MIME format. > >> > >>--------------ms060206000402050809000606 > >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >>Content-Transfer-Encoding: 7bit > >> > >>Hi Jon, > >> > >>> so reading re-feedback etc, and loss notification, wouldn't it be easier > >>> given most flows have feedback packets, to have an efficient common case > >>> encoding > >>> 1// the hop count in the net is rarely more than 32 > >>> so lets have a 32bit field which is called SEuCN > >>> and is > >>> Selective Explicit unCongested Notification. > >>> > >>> in outbound backets, each hop sets this bit > >>> (and its returned in acks) to say "all is well and good here". > >> > >>I am curious how each hop would determine the bit it should set? > >>Furthermore, since the bit is set in case there is no problem, how > >>should an end node know that the x Zeros of the 32/64 bits are not an > >>indication of problems but rather that the number of hops the packet > >>passed is qual to 32/64-x? Hmm, might use the TTL field to determine the > >>hop count and determining the corresponding bit at each hop ... > >>But naivly asking, what do we gain for the transport layer mechanisms if > >>we know how many hops are congested? > >>It seems to me like the congestion level is much more interesting in > >>order to apply different algorithms at different congestion levels on > >>the transport layer (e.g., more aggresive increase algorithms, etc.), > >>which however would require some mechanisms in the routers. > >> > >>Cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051108/d5f51c31/smime-0001.bin From sommerfeld at sun.com Tue Nov 8 16:17:07 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Tue, 08 Nov 2005 16:17:07 -0800 Subject: [e2e] Internet packet size distribution In-Reply-To: References: Message-ID: <1131495427.925.15.camel@localhost> > None of the 1300B packets seen in our Los Nettos and USC Internet2 traces > seem to be tunneled IPv6. The protocol field is almost always 6 (TCP) or > 17 (UDP). It's never 41 (IPv6). One of my coworkers reports, regarding a common VPN package: "upon installation of the product, the software changes the global MTU to 1300 in the registry for each interface. " so this mystery may be solved; if you've ever even install this package, your MTU will remain small.. - Bill From braden at ISI.EDU Wed Nov 9 14:23:38 2005 From: braden at ISI.EDU (Bob Braden) Date: Wed, 09 Nov 2005 14:23:38 -0800 Subject: [e2e] New leadership for the E2E RG Message-ID: <5.1.0.14.2.20051109104832.00b02ff8@boreas.isi.edu> The first meeting of the "Internet Task Force on New End-to-End Services" was held on January 10th and 11th [1985] at UCLA. The initial members were: myself (UCLA), Bob Gilligan (SRI), Rob Gurwitz (BBN), Alan Shelzter (UCLA), Jon Crowcroft (UCL), Annette DeSchon (ISI), and David Cheriton (Stanford). Dave Clark did not arrive until the second meeting, April 11-12, 1985 at BBN. Although the Task Force (later, Research Group) has always had a closed membership, it has maintained this public mailing list, end2end-interest, for general discussion of research areas relevant to the E-E architecture. It has been my privilege to chair this organization since the first meeting. After 20 years, it seems to be time for me to step down as chair. After all, even Allan Greenspan does not rule forever! Craig Partridge (BBN) and Karen Sollins (MIT) are the new co-chairs. This list has been managed with by Joe Touch under the auspices of the Postel Center for Experimental Networking, a living memorial to Jon Postel. He has agreed to continue to do so. So, back to discussing whatever it was we were discussing. Bob Braden From swolff at cisco.com Wed Nov 9 15:55:07 2005 From: swolff at cisco.com (Stephen Wolff) Date: Wed, 9 Nov 2005 18:55:07 -0500 Subject: [e2e] New leadership for the E2E RG In-Reply-To: <5.1.0.14.2.20051109104832.00b02ff8@boreas.isi.edu> References: <5.1.0.14.2.20051109104832.00b02ff8@boreas.isi.edu> Message-ID: <22268c63a368775e3bbe1c47c1c93362@cisco.com> OK Bob: You're allowed to quit as long as you agree not to be quiet. -s On Nov 9, 2005, at 17:23, Bob Braden wrote: > The first meeting of the "Internet Task Force on New End-to-End > Services" was held on January 10th and 11th [1985] at UCLA. The > initial > members were: myself (UCLA), Bob Gilligan (SRI), Rob Gurwitz (BBN), > Alan Shelzter (UCLA), Jon Crowcroft (UCL), Annette DeSchon (ISI), and > David Cheriton (Stanford). Dave Clark did not arrive until the second > meeting, April 11-12, 1985 at BBN. Although the Task Force (later, > Research Group) has always had a closed membership, it has maintained > this public mailing list, end2end-interest, for general discussion of > research areas relevant to the E-E architecture. > > It has been my privilege to chair this organization since the first > meeting. After 20 years, it seems to be time for me to step down > as chair. After all, even Allan Greenspan does not rule forever! > Craig Partridge (BBN) and Karen Sollins (MIT) are the new co-chairs. > > This list has been managed with by Joe Touch under the auspices of > the Postel Center for Experimental Networking, a living memorial > to Jon Postel. He has agreed to continue to do so. > > So, back to discussing whatever it was we were discussing. > > Bob Braden > > > stephen wolff +1.202.362.7110 (v) academic research and technology initiatives +1.202.362.1155 (f) cisco systems +1.202.361.9728 (m) From puddinghead_wilson007 at yahoo.co.uk Mon Nov 14 21:49:20 2005 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Tue, 15 Nov 2005 05:49:20 +0000 (GMT) Subject: [e2e] not quite the differentiated services I was thinking of In-Reply-To: <20051102073019.8964.qmail@web15402.mail.cnb.yahoo.com> Message-ID: <20051115054920.47700.qmail@web25401.mail.ukl.yahoo.com> hello, what is QoS in an overprovisioned network? Either I send the packet or I do not :( sending it a few milliiiiiiiseconds later would not matter, would it? ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From braden at ISI.EDU Tue Nov 15 09:14:47 2005 From: braden at ISI.EDU (Bob Braden) Date: Tue, 15 Nov 2005 09:14:47 -0800 (PST) Subject: [e2e] not quite the differentiated services I was thinking of Message-ID: <200511151714.JAA18903@gra.isi.edu> *> *> what is QoS in an overprovisioned network? Quite good, I would think. Bob Braden From Jon.Crowcroft at cl.cam.ac.uk Wed Nov 16 08:37:40 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 16 Nov 2005 16:37:40 +0000 Subject: [e2e] simulation, sanity, citation, and storage Message-ID: How perhaps not to do mobile nets research :- 1. The random waypoint mobility model (probably the most commonly used model for how devices move that is used in 100s of papers for simulation of how good my new mobile ad hoc routing protocol is compared to yours) - has non stationary distribution of velocity in pretty much any plausible 2D space, so you don't know when to stop/start simulators using the random waypoint mobility model: This paper is whats wrong, and how to fix it: "Perfect Simulation and Stationarity of a Class of Mobility Models," J.-Y. Le Boudec and M. Vojnovic, IEEE Infocom 2005, Miami, FL, 2005 (Infocom 2005 Best Paper Award) http://ica1www.epfl.ch/RandomTrip. 2. Many simulation papers have not only got non reproduceable results, but the quality of simulation papers is apparently getting worse over time: This paper is about how this trend has progressed, and should be essential reading for all 1st year grad students:) "{MANET} Simulation Studies: The Incredibles", by Stuart Kurkowski and Tracy Camp and Michael Colagrosso, mc2r, 2005, volume 9, 4, pages "50--61", "http://doi.acm.org/10.1145/1096166.1096174" Its pretty "interesting" how bad things are out there:) Two possible social solutions:- a) on the one hand, so how about we introduce the idea (e..g via Vint Cerf, now at google) to Google Scholar, of _negative_ citations. it ought to be easy to add to the pagerank algorithm:) Given we find that a numnber of papers have been written that are rooted on some baseline reference (e.g. the original NS code for mobile IP, or the original random waypoint) when we then show that the NS code is wrong, or the random waypoint model cannot be used to compare results in simulation experiments due to lack of stationarity, those papers all suddenly have their citation count reduced:) b) on the other hand, if people post their _code_, then bugfixes to the code would accrue _positive_ citations. we could use google base for this http://base.google.com/base/default could be a repository for simulation code, configurations and draft papers (A bit like the science preprints idea, but for _supporting_ evidence. cheers jon From dpreed at reed.com Wed Nov 16 09:52:41 2005 From: dpreed at reed.com (David P. Reed) Date: Wed, 16 Nov 2005 12:52:41 -0500 Subject: [e2e] simulation, sanity, citation, and storage In-Reply-To: References: Message-ID: <437B71E9.2050905@reed.com> Jon - really good main point. But is deciding when to start and stop a simulation the criteria for a realistic model? Sounds to me like saying we should assume everything is gaussian for the sake of simplifying the math. I don't know what a good mobility model would be, but I really suspect that mobility in rush hour is not at all like mobility on Friday afternoon before a long weekend, just as one example. And NEITHER is a distribution I would expect to be either uniform or stationary. From Dirk.Trossen at nokia.com Wed Nov 16 23:02:56 2005 From: Dirk.Trossen at nokia.com (Dirk.Trossen@nokia.com) Date: Thu, 17 Nov 2005 09:02:56 +0200 Subject: [e2e] simulation, sanity, citation, and storage Message-ID: <96D01537CAEBF940B0144E7F8E88229CBFE705@esebe102.NOE.Nokia.com> Jon, Sounds like a great idea, a reputation system for citations. Caution though has to be given to the basis of information to be used to build the system's information (I don't want to end up seeing researchers "googling" up their references artificially). Dirk >-----Original Message----- >From: end2end-interest-bounces at postel.org >[mailto:end2end-interest-bounces at postel.org] On Behalf Of ext >Jon Crowcroft >Sent: 16 November, 2005 18:38 >To: end2end-interest at postel.org >Subject: [e2e] simulation, sanity, citation, and storage > >How perhaps not to do mobile nets research :- > >1. The random waypoint mobility model >(probably >the most commonly used model for how devices move that is used >in 100s of papers for simulation of how good my new mobile ad >hoc routing protocol is compared to yours) - has non >stationary distribution of velocity in pretty much any >plausible 2D space, so you don't know when to stop/start >simulators using the random waypoint mobility model: > >This paper is whats wrong, and how to fix it: >"Perfect Simulation and Stationarity of a Class of Mobility Models," >J.-Y. Le Boudec and M. Vojnovic, IEEE Infocom 2005, Miami, FL, >2005 (Infocom 2005 Best Paper Award) http://ica1www.epfl.ch/RandomTrip. > >2. Many simulation papers have not only got non reproduceable >results, but the quality of simulation papers is apparently >getting worse over time: > >This paper is about how this trend has progressed, and should >be essential reading for all 1st year grad students:) > >"{MANET} Simulation Studies: The Incredibles", by Stuart >Kurkowski and Tracy Camp and Michael Colagrosso, mc2r, 2005, >volume 9, 4, pages "50--61", >"http://doi.acm.org/10.1145/1096166.1096174" > >Its pretty "interesting" how bad things are out there:) > > > >Two possible social solutions:- > >a) on the one hand, >so how about we introduce the idea (e..g via Vint Cerf, now at >google) to Google Scholar, of _negative_ citations. it ought >to be easy to add to the pagerank algorithm:) > >Given we find that a numnber of papers have been written that >are rooted on some baseline reference (e.g. the original NS >code for mobile IP, or the original random waypoint) when we >then show that the NS code is wrong, or the random waypoint >model cannot be used to compare results in simulation >experiments due to lack of stationarity, those papers all >suddenly have their citation count reduced:) > >b) on the other hand, >if people post their _code_, then bugfixes to the code would >accrue _positive_ citations. we could use google base for this >http://base.google.com/base/default >could be a repository for simulation >code, configurations and draft papers >(A bit like the science preprints idea, but for _supporting_ evidence. > >cheers > >jon > > > From fahad.dogar at gmail.com Fri Nov 18 07:41:47 2005 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Fri, 18 Nov 2005 20:41:47 +0500 Subject: [e2e] Preemption in a Multi-Class scenario Message-ID: Hi, Regarding preemption, I wonder if anyone can comment on how likely is that we will need to preempt several LSPs to accommodate a new LSP? We are currently considering the problem of preemption in a DiffServ aware MPLS environment. Various preemption schemes exist (in literature) some of which try to minimize the number of preempted LSPs. All such schemes assume that the average bandwidth of lower priority requests is *much* smaller as compared to the mean size of higher priority requests and, therefore, imply that multiple lower priority requests need to be preempted to accommodate a higher priority request. Is it reasonable to assume that in a multi-class environment, large variation in traffic patterns of different classes would exist? Any measurements or studies out there? Any justifications for assuming different mean sizes for traffic requests belonging to different classes? In contrast to the popular assumption, if the traffic distribution of different classes is similar in terms of mean bandwidth, it is very *likely* that accommodating one high-priority LSP would require preempting just one low-priority LSP, especially when the number of LSPs is large. This significantly reduces the complexity of preemption algorithm. How likely is it that for a given traffic request, typically we would need to preempt several LSPs (and not just one) in order to accommodate the new request. Thanks in advance, Fahad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051118/8160b8ae/attachment.html From braden at ISI.EDU Thu Nov 17 12:05:33 2005 From: braden at ISI.EDU (Bob Braden) Date: Thu, 17 Nov 2005 12:05:33 -0800 (PST) Subject: [e2e] CFP: The Third IEEE Workshop on Embedded Networked Sensors (EmNets 2006) Message-ID: <200511172005.MAA20663@gra.isi.edu> A non-text attachment was scrubbed... Name: not available Type: x-sun-attachment Size: 38033 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051117/6b5bcad1/attachment-0001.ksh From fred at cisco.com Fri Nov 18 11:15:01 2005 From: fred at cisco.com (Fred Baker) Date: Fri, 18 Nov 2005 11:15:01 -0800 Subject: [e2e] Preemption in a Multi-Class scenario In-Reply-To: References: Message-ID: I assume you are working on traffic engineering. You clearly are working on a case where the remaining unallocated capacity on a link is smaller than the need that you have for a given new LSP. Otherwise you wouldn't be preempting. I would also tend to assume that LSPs are of different sizes. Not all LSPs get the same capacity. So the capacity that you need to preempt is the capacity you need to allocate less the remaining unallocated capacity (eg, if you have a pipe that is 90% allocated and have a new LSP that needs 15% of the pipe, you need to preempt an LSP or set of LSPs that owns 5% of the pipe to aggregate the necessary bandwidth). If it is large enough, you can preempt a smaller LSP and meet the needs of the new one. But there probably isn't one that exactly meets your needs, so you will wind up preempting at least one LSP, combining the now-freed bandwidth with the remaining unallocated capacity, allocating the new LSP, and now having some amount left over. If what you preempted was smaller than what you allocated, what you have remaining is smaller than what you had before. If what you preempted was larger, you will have more left over. You now presumably have what you preempted to re-install. If it is smaller than what you installed, it will presumably be easier to route through the remaining network. If it is larger... Just thinking through things, the LSPs that I am most likely to be willing to re-route in favor of a new LSP are likely to be ones that are the same size or smaller than the new LSP (and BTW are most likely to be protection paths as opposed to LSPs currently bearing traffic). That leads me to believe that there is a significant probability that there is not magically an LSP that is "just right", and I will have a significant chance of having to combine two or more smaller LSPs to make capacity available. On Nov 18, 2005, at 7:41 AM, Fahad Dogar wrote: > Hi, > > Regarding preemption, I wonder if anyone can comment on how likely > is that we will need to preempt several LSPs to accommodate a new LSP? > > We are currently considering the problem of preemption in a > DiffServ aware MPLS environment. Various preemption schemes exist > (in literature) some of which try to minimize the number of > preempted LSPs. All such schemes assume that the average bandwidth > of lower priority requests is *much* smaller as compared to the > mean size of higher priority requests and, therefore, imply that > multiple lower priority requests need to be preempted to > accommodate a higher priority request. Is it reasonable to assume > that in a multi-class environment, large variation in traffic > patterns of different classes would exist? Any measurements or > studies out there? Any justifications for assuming different mean > sizes for traffic requests belonging to different classes? > > In contrast to the popular assumption, if the traffic distribution > of different classes is similar in terms of mean bandwidth, it is > very *likely* that accommodating one high-priority LSP would > require preempting just one low-priority LSP, especially when the > number of LSPs is large. This significantly reduces the complexity > of preemption algorithm. > > How likely is it that for a given traffic request, typically we > would need to preempt several LSPs (and not just one) in order to > accommodate the new request . > > Thanks in advance, > Fahad From jtw at ISI.EDU Fri Nov 18 19:13:45 2005 From: jtw at ISI.EDU (John Wroclawski) Date: Fri, 18 Nov 2005 19:13:45 -0800 Subject: [e2e] NSF NETS Future Internet Design Informational Meeting Message-ID: (Forwarded for "NSF NETS FIND Info Meeting " Please see the website or reply directly to that address for more info) Dear Colleague, This email is to invite you to an informational meeting about the upcoming NSF NETS Program's Future Internet Network Design (FIND) research initiative. The meeting will be held Monday, December 5, 2005, 9:00AM - 4:30PM, at the Hilton Washington Dulles Airport. The goals, structure, and emphasis of the FIND initiative differ somewhat from current NETS programs. For this reason, researchers interested in these topics are particularly encouraged to attend this informational meeting. Further information about the informational meeting is available below and at the meeting website, http://find.isi.edu. The FIND Program FIND (Future Internet Network Design) is a major new long-term initiative of the NSF NETS research program. FIND asks two broad questions: * What are the requirements for the global network of 15 years from now - what should that network look like and do? and * How would we re-conceive tomorrow's global network today, if we could design it from scratch? The FIND program will solicit "clean slate process" research proposals in the broad area of network architecture, principles, and design, aimed at answering these questions. The philosophy of the program is to help conceive the future by momentarily letting go of the present - freeing our collective minds from the constraints of the current. The intellectual scope of the FIND program is wide. As examples, FIND research might address questions such as: * What will the edge of the network look like in 15 years? How might the network architecture of 15 years hence best accommodate sensors, embedded systems, and the like? * How might the network of 15 years from now support what users really do (and care about)? How might such functions as information access, location management or identity management best fit into a new overall network architecture? * What will the core of the network look like in 15 years? How might the changing economics of optical systems affect the overall design of the larger network? The Informational Meeting The informational meeting will include a discussion of the scope, purpose, and intellectual underpinnings of the FIND program, guidance for potential proposers about the program's structure and review process, and community discussion and feedback about this exciting new initiative in networking research. The meeting will take place on Monday, December 5, 2005, at the Hilton Washington Dulles Airport. Further details about the meeting and hotel are available at http://find.isi.edu. A full agenda for the meeting will be posted shortly. Due to the short deadline, please register as soon as possible at http://find.isi.edu. There is no fee to register for the meeting. A block of rooms at the meeting hotel has been held at a preferential rate for the night of Sunday, December 4th. You must reserve your room by *Monday, November 28* to obtain this rate. Information needed to reserve rooms from this block is available at the meeting website. Please make your hotel reservations as soon as possible to ensure that the hotel is able to accommodate all attendees. Thanks for your interest in the FIND Program! From griff at ifi.uio.no Mon Nov 21 13:30:01 2005 From: griff at ifi.uio.no (Carsten Griwodz) Date: Mon, 21 Nov 2005 22:30:01 +0100 Subject: [e2e] CfP of NOSSDAV 2006 Message-ID: CALL FOR PAPERS NOSSSDAV 2006 For sixteen years, NOSSDAV has fostered cutting-edge, state-of-the-art research in multimedia and newly emerging areas such as networked games and peer-to-peer streaming. The workshop environment encourages lively discussion among participants and invites strong feedback for work in progress. In 2006, NOSSDAV will be held in Newport, Rhode Island. The beautiful harbor front location is home to sailing, beaches, golfing, biking, and fishing. NOSSDAV invites submissions on all areas of multimedia computing and networking and strongly encourages work in progress in emerging areas. Papers grounded in high-quality experimental research based on prototype and real systems are highly valued. Additionally, papers proposing new directions for research or calling into question existing conventional wisdom are welcomed. This year, NOSSDAV will give extra consideration to papers where the source code to experimental or real systems is released. And, NOSSDAV will also give extra consideration to papers that aim to comprehensively validate previous work in some topic within multimedia. Topics of interest include, but are not limited to: * Peer-to-peer streaming * Networked games * Sensor networks and architectures * In-network stream processing * Wireless and mobile multimedia systems * 3D multimedia and tele-immersion * Streaming 3D graphics and virtual worlds * Application-level multicast * Multimedia security * Digital rights management * Real-time operating system support for multimedia * Multimedia middleware and frameworks A broad view will be taken in deciding what topics are within scope. Please feel free to contact the workshop co-chairs if you are unsure and wish to check if a particular paper or topic is within the workshop scope. As always, student participation is strongly encouraged. To encourage a good mix of seasoned researchers as well as students, we will be offering discounted registration for student members who attend with their faculty advisor. Submissions (as well as the camera ready final versions of accepted papers) should be no longer than 6 pages. We expect these submissions to be the kernel of what will eventually lead to full-length papers at high-quality conferences or journals. Important Dates: Paper registration: February 8, 2006 (5pm Eastern US) Paper submission: February15, 2006 (5pm Eastern US) Notification: April 5, 2006 Camera ready: April 19, 2006 Conference: May 22-23, 2006 For further information see: http://www.nossdav.org/2006/ or contact the workshop co-chairs: Brian Levine (brian at cs.umass.edu) Mark Claypool (claypool at cs.wpi.edu) From padhye at microsoft.com Wed Nov 23 09:52:13 2005 From: padhye at microsoft.com (Jitu Padhye) Date: Wed, 23 Nov 2005 09:52:13 -0800 Subject: [e2e] FW: Mesh Networking Academic Resource Toolkit 2005 & Digital Inclusion Funding Opportunity Message-ID: I am re-posting the following announcement from the MANET mailing list. Apologies if you get multiple copies. - Jitu ======================================================================== === If you are a faculty member or a researcher at an accredited university or college, I invite you to use the Mesh Networking Academic Resource Toolkit 2005 as a research and teaching resource for exploring core technologies in wireless networking. The toolkit contains all the source code, binaries, and documentation you will need to get started. You will just need a PC with a wireless card and DVD/CD drive to work with it. Details at: http://research.microsoft.com/netres/kit Several of our colleagues are already using this toolkit and with this email we are opening up the program further. To see who is using the toolkit and what they are using it for, visit: http://research.microsoft.com/netres/kit/do.htm http://research.microsoft.com/netres/kit/Who.htm Additionally, I want to bring to your attention a $1.2 million funding opportunity from Microsoft that seeks to empower academic researchers worldwide to tackle technological challenges that positively impact health, education, and socio-economic conditions in underserved areas. Proposal Deadline is: Jan. 13, 2006, 12:00 PM, Noon, PST (8:00 PM UTC/GMT) Additional details are on: http://research.microsoft.com/ur/us/fundingopps/RFPs/DigitalInclusion_20 05_RFP.aspx Please forward this message to colleagues who may be interested in knowing about this. Thanks! Victor Bahl Microsoft Research From wuchang at cs.pdx.edu Tue Nov 29 17:34:35 2005 From: wuchang at cs.pdx.edu (Wu-chang Feng) Date: Tue, 29 Nov 2005 17:34:35 -0800 Subject: [e2e] IP puzzle implementation Message-ID: <438D01AB.7070702@cs.pdx.edu> For those who are interested, we've released a netfilter/iptables implementation of our IP layer puzzle system at... http://sourceforge.net/projects/ippuzzles The code was used in evaluating the hint-based hash reversal scheme described in the paper below.... Wu-chang Feng, Ed Kaiser, Wu-chi Feng, Antione Luu "The Design and Implementation of Network Puzzles" IEEE INFOCOM 2005. Wu From detlef.bosau at web.de Wed Nov 30 11:19:13 2005 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 30 Nov 2005 20:19:13 +0100 Subject: [e2e] A Question on the TCP handoff References: <92E20BAD-53D2-4A8F-A1C1-62E4C21D7DB0@mimectl>, <018f01c5c487$099117e0$f5f2010a@seashadow> <251995AB-69FA-49F9-8E51-585028CDAC49@mimectl> Message-ID: <438DFB31.689D138C@web.de> Alper Kamil Demir wrote: > > David, > Thank you very much for the reply. However, I think tcpcp will not > solve the problem because tcpcp is useful to migrate tcp connection > from place to place (correct me if I am wrong). What I want to achieve > is to replace the warm-up connection with an already > established actual connection (so that replaced new connection > both does have the same previous flow control of actual connection and > doesn't go into slow start process by having congestion control state > of warm-up). > Admittedly, I don?t quite understand what you mean by "warm up connection". However, IMHO there is some basic difficulty in any kind of TCP handover, which even holds in the existing and well known approaches. At least CWND is an estimator for a flow?s fair share of the end--to--end _storage_ _capacity_ of a path. Hence, each kind of "handover of a TCP connection from one path to another", even approaches which attempt to recover from wrong / inappropriate congestion control issues by recovery of a former state (to my understanding, this is done by TCP/Eifel) will only achieve its goal when the recovered/trasfered state variables are by some chance appropriate for the new path. I don?t expect this to happen quite often in reality. In my opinion, if the path of of a TCP flow changes, we cannot assume the former CWND to be appropriate, however it?s easier to keep the old value than to flip a coin for a new one. CWND is an estimator. So, if it is correct, anything is fine. If not: It will converge to the correct value due to TCP congestion control. Both cases are fine. So I don?t really understand people who are eager to maintain old states for new situations. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937