Re: IETF58 - Network Status
I already indicated before: 100-150 Euros more is not a big issue. Other standards bodies charge very similar amounts for meetings, and also have very hefty annual membership fees. The IETF is in a very unusual position, as far as standards bodies goes, in that we strive for complete openness and inclusiveness as opposed to corporate membership. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- In the beginning was the word...and it was the wrong length. --Bob Barton (Burroughs computer architect)
Re: IETF58 - Network Status
Just want to add that the network worked perfectly for me during the entire IETF, I didn't have any problems at plenary either. Twice in the lobby bar I lost the association with the access point for a short while, but apart from that... I used 802.11b most of the time. I don't know if I'm exceptional or if it's just that only people with problems are posting... For me this was one of the better wireless IETFs, with Vienna being the best. The most important now is perhaps to start writing down how it should be done, so that the next host has some good advice, and then revise that after next IETF and so on. Stig
Re: IETF58 - Network Status
Kevin C. Almeroth wrote: It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. I'm not sure there should be any difference. I was the host in Adelaide but I didn't do the radios, I out sourced them to a local company that specialises in that sort of stuff. They were interested in seeing a large deployment of radios and understanding the problems encountered. Perhaps we should be targeting these sort of companies to help us? Mark.
Re: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stig Venaas wrote: | Just want to add that the network worked perfectly for me during the | entire IETF, I didn't have any problems at plenary either. Mee to. I even had good reception in my room at the doubletree. leifj -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vW7r8Jx8FtbMZncRAtJZAJ94JN+mjew9NdpmB/IPxZb2uzlxkQCfSwVW 07BOt7eJdtQkoJwGp1gmy9Q= =xavr -END PGP SIGNATURE-
Re: IETF58 - Network Status
Wednesday 19 November 2003, Stig wrote: Just want to add that the network worked perfectly for me during the entire IETF, I didn't have any problems at plenary either. Twice in the lobby bar I lost the association with the access point for a short while, but apart from that... I used 802.11b most of the time. Ditto to all of the above. Linux/Debian with Aironet 340. Henrik
Re: [58crew] RE: IETF58 - Network Status
Masataka Ohta [EMAIL PROTECTED] writes: Because of exponential backoff, aggregated bandwidth of multiple TCP over congested WLAN should not be so bad. However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. A RED approach would be good, but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. Perry
Re: IETF58 - Network Status
As for the network: Vienna has shown that it's possible to do better. At the same time, with 1000+ people in a room performance isn't going to be great. Poor network performance during plenaries and other crowded sessions isn't the end of the world as long as the network functions well elsewhere. It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. Having a host is a good thing but few companies are willing to step forward anymore. Solve that problem and many other problems get solved... including more important ones like having a T-shirt. -kevin
Re: IETF58 - Network Status
On Wed, 19 Nov 2003, Iljitsch van Beijnum wrote: As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. if you want to show up with encoders I'll give you an audio/video feed... then you can baby your boxes and not go to any meeting you want all week just like me. I would be able lot cheaper and less work if the multicast folks just paid to go to the meeting like normal people. Actually, I'm not even sure I agree with this. The reason is because if we had more than a handful of people watching remotely, it would add quite a bit of congestion to the network link. So, if you are willing to be sent a unicast stream and then provide the bandwidth to replicate it to everyone else in the world who wants it by unicast, then I think we have a doable solution. -kevin
Re: IETF58 - Network Status
On Wed, 19 Nov 2003, Kevin C. Almeroth wrote: On Wed, 19 Nov 2003, Iljitsch van Beijnum wrote: As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. if you want to show up with encoders I'll give you an audio/video feed... then you can baby your boxes and not go to any meeting you want all week just like me. I would be able lot cheaper and less work if the multicast folks just paid to go to the meeting like normal people. Actually, I'm not even sure I agree with this. The reason is because if we had more than a handful of people watching remotely, it would add quite a bit of congestion to the network link. So, if you are willing to be sent a unicast stream and then provide the bandwidth to replicate it to everyone else in the world who wants it by unicast, then I think we have a doable solution. I'm sorry I sort of assumed that would be necessary for anything beyond minimal bitrates... We source around 6Mb/s from the ietf, even the sources we reflect to other multicast streams (like the ssm sources) we do from some location off of the conference network, such as the UO. -kevin -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
On Wed, Nov 19, 2003 at 09:21:59AM -0800, Kevin C. Almeroth wrote: It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. And a host that did not document what it did for the WLAN provision, despute requests to do so. Tim
Re: IETF58 - Network Status
I don't think so, sorry. The network setup is not different (it should not be), if we have a host or not. I'm convinced the secretariat has the expertise to do it well. We have been in the same hotel other times, and it worked fine. We just need to discover exactly what happened, and most probably comparing with Vienna could be a good way to attack the problems ! Also, there are still few companies willing to host IETF. I've offered Madrid (Spain) since 2.5 years ago ... the process is very slow. The secretariat already visited the hotel, and they agreed that is a very good installation, if I'm not wrong, their words were excellent, one of the best properties that we never seen (actually the bigger hotel in Europe), and it already has Ethernet (with IPv6, for free) in every guest room. The network is ready in every meeting room, in the corridors, ... We have already organized big events there. The issue, according to what I talked last week with the Secretariat and Harald (just a very few minutes), is that the hotel is not located downtown, but just in front of the airport, and they argue the transport isn't good. I can tell that there is no metro, right, but there are 4 bus lines in the door, a free shuttle to the airport (then metro 12 minutes to the center of the city), and I offered also a free shuttle service to downtown. Even more, a taxi either to the metro or to downtown will cost less than 4-5 Euros (what about sharing it among different participants). I don't see the problem, but of course I'm local and know it very well. My proposal also included a social, and may be a change in the schedule of the meetings. Trying to lunch downtown at 11:30 is impossible (of course no problem if in the hotel), or even to dinner at 17:30, so I suggested trying to adapt the agenda to the local timing, have a kind of extended coffee break or snack before the last meeting (i.e. plenary), then have dinner after, starting at 20:30-21:00. And I know the cost of the IETF in Madrid will be probably one of the cheaper ... and hopefully very well attended. Anyway, the target was 2004, but now is too late. I'm preparing a short report to try to convince Harald and whoever needs to be convinced and I will be happy to circulate it in this list. Now I already offered Madrid for 2005, and 1.5-2 years later in Barcelona. But unless we react soon, the hotel pre-booking that I did, will go for 2005 also. But of course, my offer can't last for ever. Actually is costing me more time and effort to convince the IETF to come here, than probably setup it, even with a good network ;-) Regards, Jordi - Original Message - From: Kevin C. Almeroth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 6:21 PM Subject: Re: IETF58 - Network Status As for the network: Vienna has shown that it's possible to do better. At the same time, with 1000+ people in a room performance isn't going to be great. Poor network performance during plenaries and other crowded sessions isn't the end of the world as long as the network functions well elsewhere. It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. Having a host is a good thing but few companies are willing to step forward anymore. Solve that problem and many other problems get solved... including more important ones like having a T-shirt. -kevin ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: [58crew] RE: IETF58 - Network Status
Perry; Because of exponential backoff, aggregated bandwidth of multiple TCP over congested WLAN should not be so bad. However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. A RED approach would be good, but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. We are saying the same thing. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. With exponential back-off with base 2, 10ms of initial delay becomes 40s after 12 attempts of retry. Note that 25000ms of delay does not necessarily mean that a station has a large buffer. Masataka Ohta
Re: [58crew] RE: IETF58 - Network Status
On 19-nov-03, at 17:45, Perry E.Metzger wrote: However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. A RED approach would be good, 15 authors of RFC 2309 can't be wrong. :-) but in general there has to be a limit on the queue. Your wireless interface should not become a packet long term storage facility. I've seen RTTs to the base stations on the order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a packet a through 300ns distance of air in 10ms, it is probably time to drop it. I think there is some middle ground between 25000 and 10 ms. While the former is definitely too long, the latter is probably too short. (Ignoring the fact that base stations may need to buffer packets for much longer than this when clients are in power save mode.) But the problem with sharing the airwaves is that you can't be sure how long it's going to take to deliver packets. The difference between first try @ 11 Mbps and having to retry several times @ 1 Mbps can easily be a factor 40. Last but not least, any system sitting between a high bandwidth link (100 Mbps ether) and a low bandwidth link (802.11b) needs to buffer to accommodate for the bursty nature of IP. Usually a round trip time worth of buffer memory is recommended. So that would be around 300 ms worth of 6 Mbps (= net throughput at 11 Mbps) = 220 kilobyte.
Re: [58crew] RE: IETF58 - Network Status
Iljitsch van Beijnum [EMAIL PROTECTED] writes: I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Coupled with aggressive FEC, that's more than enough time. But the problem with sharing the airwaves is that you can't be sure how long it's going to take to deliver packets. Actually, the speed of light is remarkably deterministic. If the network is so loaded that you can't send a packet in that period, you should drop so that all the TCPs back off. The difference between first try @ 11 Mbps and having to retry several times @ 1 Mbps can easily be a factor 40. None the less, it ends up being much lower by orders of magnitude than what the standards currently permit. The packet dumps I got from the 802.11b networks during the worst periods at IETF revealed what you would readily expect -- that TCP collapses badly when the underlying network does something very dumb. By the way, it would also be a good idea if the standard did proper power control of the mobile stations. -- Perry E. Metzger[EMAIL PROTECTED]
Re: [58crew] RE: IETF58 - Network Status
On 19-nov-03, at 23:16, Perry E.Metzger wrote: I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte packet already takes 12 ms, without any link layer overhead, acks/naks or retransmits. End-to-end retransmits take even longer because of speed of light delays., Coupled with aggressive FEC, that's more than enough time. FEC sucks because it also eats away at usable bandwidth when there are no errors. But the problem with sharing the airwaves is that you can't be sure how long it's going to take to deliver packets. Actually, the speed of light is remarkably deterministic. Yes, but unfortunately, bit errors aren't. If the network is so loaded that you can't send a packet in that period, you should drop so that all the TCPs back off. Absolutely not. This leads to constant packet loss because of minor bursts, which TCP reacts very badly to. Try setting the output queues of your friendly neighborhood router to something extremely low and you'll see what I mean. The packet dumps I got from the 802.11b networks during the worst periods at IETF revealed what you would readily expect -- that TCP collapses badly when the underlying network does something very dumb. So let's: 1. Make sure access points don't have to contend with each other for airtime on the same channel 2. Make sure access points transmit with enough power to be heard over clients associated with other access points 3. Refrain from using too much bandwidth 4. Make use of higher-bandwidth wireless standards such as 802.11g By the way, it would also be a good idea if the standard did proper power control of the mobile stations. Why? Raising the power output of the stuff you want to hear over these clients is much, much simpler. Also, all of this makes it sound like the network was very bad in Minneapolis. That isn't my experience: I usually had good bandwidth, with the exception of just a couple of sessions, and I ended up associated with an ad-hoc network only a few times. By the way, I did some testing today and the results both agree with and contradict conventional wisdom with regard to 802.11 channel utilization. When two sets of systems communicating over 802.11b/g are close together, they'll start interfering when the channels are 3 apart (ie, 5 and 8), slowing down data transfer significantly. This indicates that in the US only three channels can be used close together, but four in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT close together (but still well within range), such as with a wall in between them, 3 channels apart doesn't lead to statistically significant slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b and 50% slowdown at 802.11g. So that would easily give us four usable channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or even six / seven (all odd channels) in a pinch. (As always, your milage may vary. These results were obtained with spare hardware lying around my house.)
Re: [58crew] RE: IETF58 - Network Status
Iljitsch van Beijnum [EMAIL PROTECTED] writes: On 19-nov-03, at 23:16, Perry E.Metzger wrote: I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte packet already takes 12 ms, without any link layer overhead, acks/naks or retransmits. Most of us are not running at that speed on 802.11b. Obviously if you're running at a lower speed adjustments should be made. End-to-end retransmits take even longer because of speed of light delays., We're talking about to the base stations only. End to end is not the issue. The issue is 802.11 tries to be reliable to the base station, with disastrous results. Coupled with aggressive FEC, that's more than enough time. FEC sucks because it also eats away at usable bandwidth when there are no errors. Having TCP collapse sucks too, because then no one can use the network. In any case, one can adjust the the armor to cope with the average bullet density. If the S/N is clean, you don't need as much FEC. If the network is so loaded that you can't send a packet in that period, you should drop so that all the TCPs back off. Absolutely not. Well, then, I'm sorry that you don't understand what happens to TCP under these circumstances, but some of the rest of us do. I was seeing packet traces showing clear signs of congestive collapse on the radio networks, and most of it was created by the packet warehousing our lovely 802.11 hardware believes it should do to help with the packet loss problems. It all reminded me horribly of the sorts of packet traces one saw on ARPANET and NYSERNET before VJ flow control became the norm. I really regret not saving packet traces. If I had known some people didn't understand congestion control I wouldn't thrown them away. Luckily, there is always the next conference. Perry
Re: [58crew] RE: IETF58 - Network Status
Iljitsch; I think there is some middle ground between 25000 and 10 ms. 10ms is the middle ground. That's enough for a bunch of retransmits on modern hardware. Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte packet already takes 12 ms, without any link layer overhead, acks/naks or retransmits. End-to-end retransmits take even longer because of speed of light delays., That is a improper calculation. The requirement from TCP is that, on lightly loaded link, probability of packet drop should be very small. For example, if probability of collision is (despite CSMA/CA) 0.1, 2 retries will be enough to make packet drop probability 0.1%. If there are hidden terminals, probability of interference will get worse that more retry will be desired. And, with exponential back-off, delay will be doubled as the number of retries in increased by 1. Coupled with aggressive FEC, that's more than enough time. FEC sucks because it also eats away at usable bandwidth when there are no errors. Wrong reason. FEC is fine against thermal noise. However, FEC does not work at all here, because, with a collision, contents of colliding packets will be lost almost entirely. So let's: 1. Make sure access points don't have to contend with each other for airtime on the same channel 2. Make sure access points transmit with enough power to be heard over clients associated with other access points 3. Refrain from using too much bandwidth 4. Make use of higher-bandwidth wireless standards such as 802.11g No. 2 should be: Make sure clients and access points transmit with equal power to be heard over each other to enable CSMA/CA collision avoidance with random delay 1 is a performance improvement but is not a serious problem if CSMA/CA is working well. 3 is not specific to wireless and is irrelevant. 4 helps little but is not very meaningful as PPS, rather than BPS, is becoming the limiting factor, especially for applications with small packets such as VOIP. By the way, it would also be a good idea if the standard did proper power control of the mobile stations. Why? Raising the power output of the stuff you want to hear over these clients is much, much simpler. It is a good idea for some wireless protocol. However, it is the worst thing to do against CSMA/CA. Others won't notice your presence and won't reduce transmission rate. By the way, I did some testing today and the results both agree with and contradict conventional wisdom with regard to 802.11 channel utilization. When two sets of systems communicating over 802.11b/g are close together, they'll start interfering when the channels are 3 apart (ie, 5 and 8), slowing down data transfer significantly. This indicates that in the US only three channels can be used close together, but four in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT close together (but still well within range), such as with a wall in between them, 3 channels apart doesn't lead to statistically significant slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b and 50% slowdown at 802.11g. So that would easily give us four usable channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or even six / seven (all odd channels) in a pinch. (As always, your milage may vary. These results were obtained with spare hardware lying around my house.) The results, it seems to me, completely agree with the conventional wisdom. Masataka Ohta
Re: [58crew] RE: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE- Franck == Franck Martin [EMAIL PROTECTED] writes: Franck My question, how can we deployed WiFi networks in town for global Franck roaming with SIP phones when the IETF itself has trouble to Franck deploy it... Franck Is there something wrong in the WiFi protocol that needs fixing? Yes, despite all of 802.11i, the beacons are not authenticated. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7nH2IqHRg3pndX9AQFV8gP9GICZ3J3Iej+N2QRxOnpjYGoH/VPI7Ivs ExdG3LNzTtI1tvfBRFBDcIC9/wLdTzb5GKIuU2WvMuSJKZUFynktDNzBG/LFbqVW mNWKezXpRCDGEnyc4PoACXu1tE1ZeobkLS+ynznPsx/ryYSX0NC1lB0BXCYTgcrM 4NN8OYjdYLs= =M5UK -END PGP SIGNATURE-
Re: IETF58 - Network Status
I have a similar opinion ... I believe that the terminal room, with wired connectivity, is no longer needed. But the terminal room, as a place with tables, is very convenient (but still using wireless). We can save in the cost of the wired network, and the cost of the security to keep that room surveilled. The NOC can have a different room, with a key, and even an IP camera looking at the terminal room if is considered that a minimum surveillance is still useful/needed (I don't think anyone want to take out the printer, but just in case !). An alternative is to ask for some tables in all the meeting rooms. This was actually quite useful in Vienna. Regards, Jordi - Original Message - From: Bob Hinden [EMAIL PROTECTED] To: Keith Moore [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 17, 2003 11:13 PM Subject: Re: IETF58 - Network Status Keith, Maybe that's the real problem - people think they are paying for the wireless network as part of the conference fee, when the reality (as I understand it) is that a substantial part of the cost of the wireless network comes from sponsors, donors, and/or volunteers. The network (i.e., internet connectivity, wired infrastructure, and wireless) is the responsibility of the local host or in the case of the no-host meetings (like Minneapolis) the IETF secretariat. So I think at least in the case of the no-host meetings we are paying for the network (wired and wireless). My understanding is that even with lots of donations of services, the network is an expensive undertaking. Also, from our experience hosting the Atlanta meeting I suspect that not having a terminal room and only having wireless access probably saves money. Bob ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: [58crew] RE: IETF58 - Network Status
Michael Richardson [EMAIL PROTECTED] writes: Franck == Franck Martin [EMAIL PROTECTED] writes: Franck My question, how can we deployed WiFi networks in town for global Franck roaming with SIP phones when the IETF itself has trouble to Franck deploy it... Franck Is there something wrong in the WiFi protocol that needs fixing? Yes, despite all of 802.11i, the beacons are not authenticated. There are other problems too. The fact that 802.11 tries to be reliable by doing its own retransmits results in massive congestive collapse when a protocol like TCP is run over it. The designers did not read our documents on requirements for link layers. A knob that allowed you to turn off (or at least tune down) the retransmission on a network would be very valuable, but I know of no gear that does that. Also, 11b has a poorly selected set of channels that overlap. My biggest piece of advice, though, to those setting up such networks is to deploy monitoring stations in addition to deploying base stations. That way you'll have some idea of how performance is doing without needing your users to tell you that there is a problem. Perry
Re: IETF58 - Network Status
On Tue, 18 Nov 2003 15:53:09 +0100 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: I believe that the terminal room, with wired connectivity, is no longer needed. But the terminal room, as a place with tables, is very I disagree here. Having a _stable_ (fallback) network access, especially when shifting around larger files, is very convenient. I'm not in favor of abandoning the fixed net access (except if cutting down the costs require it). Regards, Roland
Re: [58crew] RE: IETF58 - Network Status
Perry E.Metzger wrote: Michael Richardson [EMAIL PROTECTED] writes: Franck == Franck Martin [EMAIL PROTECTED] writes: Franck My question, how can we deployed WiFi networks in town for global Franck roaming with SIP phones when the IETF itself has trouble to Franck deploy it... Franck Is there something wrong in the WiFi protocol that needs fixing? Yes, despite all of 802.11i, the beacons are not authenticated. There are other problems too. The fact that 802.11 tries to be reliable by doing its own retransmits results in massive congestive collapse when a protocol like TCP is run over it. The designers did not read our documents on requirements for link layers. A knob that allowed you to turn off (or at least tune down) the retransmission on a network would be very valuable, but I know of no gear that does that. Also, 11b has a poorly selected set of channels that overlap. My biggest piece of advice, though, to those setting up such networks is to deploy monitoring stations in addition to deploying base stations. That way you'll have some idea of how performance is doing without needing your users to tell you that there is a problem. In the presence of ARP spoofing, 802.11i, either with TKIP or CCM will not provide any guarantees of security. My advise would be to continue to place your 802.11 networks out in front of an IPSec gateway.
RE: IETF58 - Network Status
An alternative is to ask for some tables in all the meeting rooms. This was actually quite useful in Vienna. I found it disturbing that people in meeting rooms were sitting with their backs to the meeting. We should NOT do that agin (in my perosnal opinion) Bert
Re: IETF58 - Network Status
Sorry, you're right: The collocation of the tables in Vienna was not good, because they where in the walls ... instead, I still like tables, but collocated in normal rows. I've used this scheme in some conferences, instead of all with tables or all with just chairs, half and half. Regards, Jordi - Original Message - From: Wijnen, Bert (Bert) [EMAIL PROTECTED] To: JORDI PALET MARTINEZ [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 5:21 PM Subject: RE: IETF58 - Network Status An alternative is to ask for some tables in all the meeting rooms. This was actually quite useful in Vienna. I found it disturbing that people in meeting rooms were sitting with their backs to the meeting. We should NOT do that agin (in my perosnal opinion) Bert ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IETF58 - Network Status
The point is that WLAN should be warranted to work, first. Actually, in my last 2-3 IETFs (my be more, but not sure), I never used the wired connectivity. The WLAN in the terminal room was excellent. Regards, Jordi - Original Message - From: Roland Bless [EMAIL PROTECTED] To: JORDI PALET MARTINEZ [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 4:39 PM Subject: Re: IETF58 - Network Status On Tue, 18 Nov 2003 15:53:09 +0100 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: I believe that the terminal room, with wired connectivity, is no longer needed. But the terminal room, as a place with tables, is very I disagree here. Having a _stable_ (fallback) network access, especially when shifting around larger files, is very convenient. I'm not in favor of abandoning the fixed net access (except if cutting down the costs require it). Regards, Roland ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IETF58 - Network Status
On Tue, Nov 18, 2003 04:39:03PM +0100, Roland Bless allegedly wrote: On Tue, 18 Nov 2003 15:53:09 +0100 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: I believe that the terminal room, with wired connectivity, is no longer needed. But the terminal room, as a place with tables, is very I disagree here. Having a _stable_ (fallback) network access, especially when shifting around larger files, is very convenient. I'm not in favor of abandoning the fixed net access (except if cutting down the costs require it). Fairly soon, all relevant hotels will offer their own wireless access, as well as connectivity from your room, and from suites, as a fallback. Also, in a meeting, one can pass CDs or USB thingies around. Risk of serious long-term wireless outage is low. How much are you willing to pay in order to reduce risk to 0% and to have your fallback network be nice and convenient? IETF finances are not in good shape.
Re: [58crew] RE: IETF58 - Network Status
On 18-nov-03, at 15:56, Perry E.Metzger wrote: The fact that 802.11 tries to be reliable by doing its own retransmits results in massive congestive collapse when a protocol like TCP is run over it. Hardly. TCP plays nice and slows down when either the RTTs go up or there is packet loss (which will happen due to congestion eventually). Radio links like this are simply too unreliable to run without additional protection: TCP isn't equipped to operate in environments with double digit packet loss percentages. What I saw in some rooms at some times in Minneapolis and also in Atlanta is massive packet loss and huge round trip times. This indicates there are simply too many people trying to cram too much data through the wireless network. This isn't going to work well whichever way you slice it. Also, 11b has a poorly selected set of channels that overlap. 1. Talk to the FCC. 2. Why do you think there are 11 overlapping channels rather than 3 non-overlapping channels? Our colleagues at the IEEE aren't stupid.
Re: [58crew] RE: IETF58 - Network Status
Iljitsch van Beijnum [EMAIL PROTECTED] writes: On 18-nov-03, at 15:56, Perry E.Metzger wrote: The fact that 802.11 tries to be reliable by doing its own retransmits results in massive congestive collapse when a protocol like TCP is run over it. Hardly. TCP plays nice and slows down when either the RTTs go up or there is packet loss (which will happen due to congestion eventually). I would suggest that you have a look at what tcpdump looks like in a conference room at the IETF. It isn't pretty. I'm kicking myself for not saving my packet traces -- they would make my point far better for me than any amount of argumentation in English. Radio links like this are simply too unreliable to run without additional protection: TCP isn't equipped to operate in environments with double digit packet loss percentages. A protocol that had been tuned for use with TCP would have been fine -- heavy FEC and some moderate retransmissions in case of corruption or station handoffs are okay. The problem is not when you try to be reliable in the face of radio interference, but when you also try to be reliable in the face of congestion -- which is precisely what the system does. Storing huge queues of packets when there is congestion does no one any favors. TCP needs packet drops and fairly low standard deviations on packet delays to do its job well, and 802.11 does precisely the wrong thing. Perry
Re: IETF58 - Network Status
I already indicated before: 100-150 Euros more is not a big issue. My time retrying my connection hundreds of times during a week cost much more and my productivity and concentration goes low. I'm sure is the same for a lot of people ! Regards, Jordi - Original Message - From: Scott W Brim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 5:45 PM Subject: Re: IETF58 - Network Status On Tue, Nov 18, 2003 04:39:03PM +0100, Roland Bless allegedly wrote: On Tue, 18 Nov 2003 15:53:09 +0100 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: I believe that the terminal room, with wired connectivity, is no longer needed. But the terminal room, as a place with tables, is very I disagree here. Having a _stable_ (fallback) network access, especially when shifting around larger files, is very convenient. I'm not in favor of abandoning the fixed net access (except if cutting down the costs require it). Fairly soon, all relevant hotels will offer their own wireless access, as well as connectivity from your room, and from suites, as a fallback. Also, in a meeting, one can pass CDs or USB thingies around. Risk of serious long-term wireless outage is low. How much are you willing to pay in order to reduce risk to 0% and to have your fallback network be nice and convenient? IETF finances are not in good shape. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IETF58 - Network Status
On Tue, Nov 18, 2003 at 11:45:22AM -0500, Scott W Brim wrote: Fairly soon, all relevant hotels will offer their own wireless access, as well as connectivity from your room, and from suites, as a fallback. Also, in a meeting, one can pass CDs or USB thingies around. Risk of serious long-term wireless outage is low. How much are you willing to pay in order to reduce risk to 0% and to have your fallback network be nice and convenient? IETF finances are not in good shape. But hotels will not be geared up for 1000 WLAN laptops... Tim
Re: [58crew] RE: IETF58 - Network Status
Perry; Radio links like this are simply too unreliable to run without additional protection: TCP isn't equipped to operate in environments with double digit packet loss percentages. I agree with you, Iljitsch. A protocol that had been tuned for use with TCP would have been fine -- heavy FEC and some moderate retransmissions in case of corruption or station handoffs are okay. The problem is not when you try to be reliable in the face of radio interference, but when you also try to be reliable in the face of congestion -- which is precisely what the system does. Storing huge queues of packets when there is congestion does no one any favors. TCP needs packet drops and fairly low standard deviations on packet delays to do its job well, and 802.11 does precisely the wrong thing. But, Ethernet does (or did, when it was CSMA) the same thing and RFC1958 says: To quote from [Saltzer], The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) Because of exponential backoff, aggregated bandwidth of multiple TCP over congested WLAN should not be so bad. However, RED like approach to attempt retries only a few times may be a good strategy to improve latency. Masataka Ohta
Re: IETF58 - Network Status
the hhonors ap's at the hilton were nat-ed and behind a business cable-modem that's about average for the hotels I've seen... you won't find to many hotels with ds3's and /19s worth of address-space. if enough peopel fall back on the hotel you'll melt it... joelja On Tue, 18 Nov 2003, Tim Chown wrote: On Tue, Nov 18, 2003 at 11:45:22AM -0500, Scott W Brim wrote: Fairly soon, all relevant hotels will offer their own wireless access, as well as connectivity from your room, and from suites, as a fallback. Also, in a meeting, one can pass CDs or USB thingies around. Risk of serious long-term wireless outage is low. How much are you willing to pay in order to reduce risk to 0% and to have your fallback network be nice and convenient? IETF finances are not in good shape. But hotels will not be geared up for 1000 WLAN laptops... Tim -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
Keith, Maybe that's the real problem - people think they are paying for the wireless network as part of the conference fee, when the reality (as I understand it) is that a substantial part of the cost of the wireless network comes from sponsors, donors, and/or volunteers. The network (i.e., internet connectivity, wired infrastructure, and wireless) is the responsibility of the local host or in the case of the no-host meetings (like Minneapolis) the IETF secretariat. So I think at least in the case of the no-host meetings we are paying for the network (wired and wireless). My understanding is that even with lots of donations of services, the network is an expensive undertaking. Also, from our experience hosting the Atlanta meeting I suspect that not having a terminal room and only having wireless access probably saves money. Bob
Re: IETF58 - Network Status
I have a similar opinion ... I believe that the terminal room, with wired connectivity, is no longer needed. My experience last week was otherwise. There were times at which the only reliable connectivity I could find (well, in a smoke-free area, anyway) was via a wired network connection. Or at least after trying to find a wireless connection a 3 or 4 places, I was glad to be able to give up and just go to the terminal room. Of course the terminal room is much more accessible these days now that wireless in the meeting rooms/hallways can relieve some of the need to provide space and cables for everyone...
Re: IETF58 - Network Status
Fairly soon, all relevant hotels will offer their own wireless access, as well as connectivity from your room, and from suites, as a fallback. if your hotel is a few blocks (or habitrail tunnels) away then the overhead of obtaining fallback access (from your room, or if limited to registered guests) becomes fairly significant... also I seriously doubt that most hotels will provision their fallback networks adequately fairly soon.
Re: IETF58 - Network Status
I already indicated before: 100-150 Euros more is not a big issue. I strongly and emphatically disagree, and I strongly object to attempts to use of increased meeting feeds to discourage some parties from participating at IETF. Basically this kind of fee increase is completely and absolutely unacceptable.
Re: IETF58 - Network Status
On 18-nov-03, at 19:48, Keith Moore wrote: I already indicated before: 100-150 Euros more is not a big issue. I strongly and emphatically disagree, and I strongly object to attempts to use of increased meeting feeds to discourage some parties from participating at IETF. Basically this kind of fee increase is completely and absolutely unacceptable. Especially considering the fact that based on the budget for 2003 (see http://www.ietf.org/u/ietfchair/budget-2003.html ) the costs per attendee are less than 300 dollars, even at the lower than projected attendance. Maybe this would be a good time to explain what the IETF needs a 9.33 person secretariat for, and why the secretariat must be entirely funded by meeting fees. As for the network: Vienna has shown that it's possible to do better. At the same time, with 1000+ people in a room performance isn't going to be great. Poor network performance during plenaries and other crowded sessions isn't the end of the world as long as the network functions well elsewhere.
Re: IETF58 - Network Status
In message [EMAIL PROTECTED], Iljitsch van Beijn um writes: On 18-nov-03, at 19:48, Keith Moore wrote: I already indicated before: 100-150 Euros more is not a big issue. I strongly and emphatically disagree, and I strongly object to attempts to use of increased meeting feeds to discourage some parties from participating at IETF. Basically this kind of fee increase is completely and absolutely unacceptable. Especially considering the fact that based on the budget for 2003 (see http://www.ietf.org/u/ietfchair/budget-2003.html ) the costs per attendee are less than 300 dollars, even at the lower than projected attendance. Maybe this would be a good time to explain what the IETF needs a 9.33 person secretariat for, and why the secretariat must be entirely funded by meeting fees. Y'know, IETFers always have fun comparing the size of our secretariat to those from other standards organizations. The phrase order of magnitude smaller comes to mind. The Secretariat handles I-D processing, meeting planning, IESG telechats, software development and systems administration to support all that, and much, much more. As for the network: Vienna has shown that it's possible to do better. There were at least two major external items that were different this time: nasty, aggressive worms, both inside and outside -- *why* should anyone clueful enough to attend an IETF meeting not know how to run AV software, at the very least! -- and helpful operating systems that think that going into IBSS mode when they don't hear a base station is user-friendly. --Steve Bellovin, http://www.research.att.com/~smb
Re: IETF58 - Network Status
On 18-nov-03, at 23:44, Steven M. Bellovin wrote: Maybe this would be a good time to explain what the IETF needs a 9.33 person secretariat for, and why the secretariat must be entirely funded by meeting fees. The Secretariat handles I-D processing, meeting planning, IESG telechats, software development and systems administration to support all that, and much, much more. I have no first-hand information on how much time this costs, but 9.33 people for all of this seems like a lot. I-Ds could be automated, and I gather the actual work in getting meetings off the ground is handled by an outside bureau anyway. As for the network: Vienna has shown that it's possible to do better. There were at least two major external items that were different this time: nasty, aggressive worms, both inside and outside Ok, so we should make sure that incoming access to the network has wormfilters and the access points must support blocking certain mac addresses from connecting to the network. Wouldn't it make sense to require people to register their mac address, by the way? This should make tracking down misbehaving hosts much easier. and helpful operating systems that think that going into IBSS mode when they don't hear a base station is user-friendly. I think part of the blame should go to the access points that kept disappearing. Someone told me this was because the AP transmitters were set to just 1 mw. If this is true, it was obviously a very big mistake. As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway.
Re: IETF58 - Network Status
On Wed, 19 Nov 2003, Iljitsch van Beijnum wrote: As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. if you want to show up with encoders I'll give you an audio/video feed... then you can baby your boxes and not go to any meeting you want all week just like me. I would be able lot cheaper and less work if the multicast folks just paid to go to the meeting like normal people. -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
I have no first-hand information on how much time this costs So I'll dream up what I think the right number of people should be! I think part of the blame should go to the access points that kept disappearing. Someone told me this was because the AP transmitters were set to just 1 mw. If this is true, it was obviously a very big mistake. Oh really?! Please explain why. Your words strike me as those of a volunteer for South Korea. Do I have that about right? As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. Will you happily pay for the privilege? Eliot
Re: IETF58 - Network Status
At 07:38 PM 11/18/2003, Eliot Lear wrote: I have no first-hand information on how much time this costs So I'll dream up what I think the right number of people should be! I think part of the blame should go to the access points that kept disappearing. Someone told me this was because the AP transmitters were set to just 1 mw. If this is true, it was obviously a very big mistake. Oh really?! Please explain why. Your words strike me as those of a volunteer for South Korea. Do I have that about right? As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. Will you happily pay for the privilege? I have been offering that for several years. I've stood up at Plenaries and asked too. If the IETF needs funds, then a remote-attendance fee makes sense. However, if there's going to be a remote-attendance fee, there needs to be live streaming that works on networks where multicast isn't available, and there'd need to be coverage from ALL rooms. (Yes, it'd be nice if I could get multicast in my office, but it's just not available at present on the only broadband provider covering my area). Much as I'd like to make all meetings, this just isn't possible. Using only meeting attendance fees to fund all activities, such as I-D processing, seems wrong. I use those services, even if I don't attend all meetings. So maybe the question is wider than meeting fees and remote attendance fees.
Re: IETF58 - Network Status
On 19-nov-03, at 1:38, Eliot Lear wrote: I think part of the blame should go to the access points that kept disappearing. Someone told me this was because the AP transmitters were set to just 1 mw. If this is true, it was obviously a very big mistake. Oh really?! Please explain why. Ok, maybe not so obvious then... Under the best of circumstances dialing down the transmit power neither helps nor hurts as both the signal we're interested in and the noise generated by signals we're not interested in become weaker so the signal to noise ratio remains the same. So even under ideal conditions there is no reason to do this. However, in practice the conditions aren't ideal, as receiver sensitivity remains the same, and AFAIK 802.11b has no mechanisms to make clients lower their signal output. And even if it had, this presumably wouldn't apply to rogue p2p networks. So the net effect of lowering access point transmit levels is that interference from clients goes way up, as a 30 mw client at 15 meters (50 ft) is received stronger than a 1 mw AP at 3 meters (assuming the antennas are equivalent). This means that a client sitting in one of these artificially shrunk access point service areas can easily interfere with the transmissions of another access point further away using the same channel. And when a client doesn't see its access point anymore because of some temporary problem (someone walking through the line of sight or something) it is almost guaranteed that if there are any rogue p2p networks, these will have a stronger signal as seen from the client than the remaining access points. Your words strike me as those of a volunteer for South Korea. Do I have that about right? I'd be happy to volunteer but I don't think I'll attend IETF59 as I've attended three of the last four meetings which is already more than I planned. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. Will you happily pay for the privilege? So how much would this have to cost? As things are now, getting multicast service is more expensive for me than attending the meetings in person...
Re: IETF58 - Network Status
On Tue, 18 Nov 2003 16:38:12 -0800, Eliot Lear [EMAIL PROTECTED] said: As long as we're bitching about the network: would it be possible to start doing some unicast streaming of sessions in the future? Access to multicast hasn't gotten significantly better the past decade, but streaming over unicast is now routine as the codecs are so much better these days, as is typical access bandwidth. I'll happily take 40 kbps MPEG-4 audio only; the video is so badly out of sync that it is unwatchable most of the time anyway. Will you happily pay for the privilege? FWIW, I would not mind paying. My ISP has been filtering ICMP for the past 6 months, and it was a pain just getting to the right person who knows the reason. I don't think I want to even try talking to them about multicast.. CP
Re: IETF58 - Network Status
Umm, having worked for a different standards organization (the OSF and The Open Group) and being somewhat familiar with their current operations, now, I can say the following: Back when I worked at OSF, it had about 325 employees and some additional number of sabbaticals and contractors not counted as employees, spread across 3 continents. Of course, it actually implemented or integrated quite a bit of code, or specified and supervised the work done at other companies, as well as evaluated a ton-load more code from other companies. Having had a key to the technoloy submission room, I can attest to the vastness of these submissions. That was then. Later I was a consultant to The Open Group as it merged the activities of X/Open and the X Consortium and downsized to its current form. The current operations are much, much leaner. But they do not generally develop code any more, except in the Research group, which is also much, much smaller. Unlike the IETF, The Open Group is involved in the administration of technology licencing and collection of royalties and all that is involved with that. There are probably other differences that I am not aware of. One may be fond of the phrase 'order of magnitude smaller', but I don't think it bears close scrutiny. I don't want to say that these 9.33 people in the secretariate aren't doing their job, or that they aren't necessary. I don't have sufficient information to judge that. That is really the task of the executive director. But how they are organized, what their work is, and what, if anything, can be automated, does seem to be a reasonable question. Platitudes are not sufficient. However, I would repeat a previous criticism of the IETF operations as being sloppy on the administration of its process, particularly in regard to the execution of the IETF process rules regarding when and how standards proposals are to be moved through the process or dropped. There could be many reasons for this particular failure. It could be the IETF is understaffed, it could be the IETF is simply poorly organized, or it could be something else. But it is in our mutual interest to find out, and correct the problem. --Dean On Tue, 18 Nov 2003, Steven M. Bellovin wrote: Maybe this would be a good time to explain what the IETF needs a 9.33 person secretariat for, and why the secretariat must be entirely funded by meeting fees. Y'know, IETFers always have fun comparing the size of our secretariat to those from other standards organizations. The phrase order of magnitude smaller comes to mind. The Secretariat handles I-D processing, meeting planning, IESG telechats, software development and systems administration to support all that, and much, much more. As for the network: Vienna has shown that it's possible to do better. There were at least two major external items that were different this time: nasty, aggressive worms, both inside and outside -- *why* should anyone clueful enough to attend an IETF meeting not know how to run AV software, at the very least! -- and helpful operating systems that think that going into IBSS mode when they don't hear a base station is user-friendly. --Steve Bellovin, http://www.research.att.com/~smb
Re: [58crew] RE: IETF58 - Network Status
rb == Randy Bush [EMAIL PROTECTED] writes: rb basic lessons previously learned were not put to use here, e.g., rb lowering the radios so wetware limits range and reduces xmtrs rb bandwidth fight. As someone who has only been peripherally aware of the activities of the NOC Team wireless specialists to implement those basic lessons and the rest of their art, I do not believe this statement is warranted. As always, constructive suggestions are appreciated. -Scott
Re: [58crew] RE: IETF58 - Network Status
On Thu, 13 Nov 2003, Randy Bush wrote: basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. Right. Like this really works. This just ensures that the folks in the middle of the room will get really bad performance. Been there. Chris. randy ___ 56crew mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/56crew Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA | | 919-392-2146 .:|:|:. [EMAIL PROTECTED]c i s c o S y s t e m s
Re: IETF58 - Network Status
This is not the solution. I'm not going to change the technology that I use because we haven't been able to setup a good network here. We should learn from the mistakes and do it better next time, as we know it worked in Vienna. I use b or g, because is what I carry with me, and I will not accept being forced to move to a, because we aren't able to fix problem that can be solved, is not rational ! If the network is a/b/g, then no problem, but not restrict the support for one or the other. We know b and g work ! Using this logic, we might still be back in the dark ages... technology evolves, new/better technology comes along. You cannot expect to use the same technology meeting-after-meeting when the volume of traffic, kinds of operating systems, viruses, etc. are changing. The network is important for most of us. I'm not going to attend to more meeting if the network is not warranted to work, because this is taking a lot of my time, and I need facilities to do it, not difficulties. The volunteer effort need some compensation, and we only demand for a stable network. I think is not too much, specially because we know that can be done. On this front... the IETF is running into the same problem as the airlines... being asked to do more work with fewer people while at the same time charging the attendees more (who then expect MORE service for their money). Such is the times we live in. -Kevin
Re: IETF58 - Network Status
Yes, technology evolves, but not from day to night ... we need a transition period if we want to fix only a. I never said that I don't want to pay 50 or even 150 Euros more to attend the meetings, but I can't be forced to: 1) Have no stable network 2) Change my computer because it doesn't support a, BECAUSE we know that b or g work (and worked in previous events). Regards, Jordi - Original Message - From: Kevin C. Almeroth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 17, 2003 5:37 PM Subject: Re: IETF58 - Network Status This is not the solution. I'm not going to change the technology that I use because we haven't been able to setup a good network here. We should learn from the mistakes and do it better next time, as we know it worked in Vienna. I use b or g, because is what I carry with me, and I will not accept being forced to move to a, because we aren't able to fix problem that can be solved, is not rational ! If the network is a/b/g, then no problem, but not restrict the support for one or the other. We know b and g work ! Using this logic, we might still be back in the dark ages... technology evolves, new/better technology comes along. You cannot expect to use the same technology meeting-after-meeting when the volume of traffic, kinds of operating systems, viruses, etc. are changing. The network is important for most of us. I'm not going to attend to more meeting if the network is not warranted to work, because this is taking a lot of my time, and I need facilities to do it, not difficulties. The volunteer effort need some compensation, and we only demand for a stable network. I think is not too much, specially because we know that can be done. On this front... the IETF is running into the same problem as the airlines... being asked to do more work with fewer people while at the same time charging the attendees more (who then expect MORE service for their money). Such is the times we live in. -Kevin ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
RE: IETF58 - Network Status
On this front... the IETF is running into the same problem as the airlines... being asked to do more work with fewer people while at the same time charging the attendees more (who then expect MORE service for their money). Such is the times we live in. The good news for these of us using airlines services quite often is that airlines still perform better than the IETF network did last week :-) Now, seriously and with all due respect and all the collegial understanding to the fellows who ran the network last week - Guys, you had a problem! For many people the network service they received were much worse than the service they received at the previous four or five IETF meting, or similar gatherings in the last couple of years. The folks who paid 500 USD registration fee expect you to face the problem, and come with solutions to avoid such problems at the next meetings. These solutions would better be something else than placing an upfront warning like 'Use card A and driver B - instead of card C and driver D' especially if C and D are quite widely deployed industry solutions. However, even this type of warning was not in place at the last meeting. People came with their standard equipment, that worked perfectly at many other events, and just could not do their work with the wireless network last week. Regards, Dan
Re: [58crew] RE: IETF58 - Network Status
I have been following this thread... My question, how can we deployed WiFi networks in town for global roaming with SIP phones when the IETF itself has trouble to deploy it... Is there something wrong in the WiFi protocol that needs fixing? Cheers On Fri, 2003-11-14 at 14:38, Chris Elliott wrote: On Thu, 13 Nov 2003, Randy Bush wrote: basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. Right. Like this really works. This just ensures that the folks in the middle of the room will get really bad performance. Been there. Chris. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard
Re: IETF58 - Network Status
The folks who paid 500 USD registration fee expect you to face the problem, and come with solutions to avoid such problems at the next meetings. Maybe that's the real problem - people think they are paying for the wireless network as part of the conference fee, when the reality (as I understand it) is that a substantial part of the cost of the wireless network comes from sponsors, donors, and/or volunteers. In other words, you get a lot more than what you pay for, but it's hardly a surprise if the quality of free service varies widely. Consistency costs money too. Personally I think the registration fee is already too high, so I'd be very reluctant to pay a substantially higher fee in order to get better wireless connectivity in the meeting rooms. Those who really need a stable network can still plug in at the terminal room. While wireless could possibly have been better than it was last week, the technology doesn't yet seem to be of the quality/maturity that 1200 people can demand free, production-quality wireless service when they're densely crammed into a few meeting rooms (in Minneapolis, most of which were really a single large meeting room partitioned with fuzzy walls). Maybe in a few years with some combination of phased-array antennas, 802.11a, more wisdom about placement, and smarter host software things will be better. It never ceases to amaze me when people who claim to be network engineers can't tolerate a week on the bleeding edge. What ever happened to eating your own dogfood? Keith
Re: IETF58 - Network Status
IEEE 802 doesn't seem to have as much of a problem at their plenary meetings Clint (JOATMON) Chaplin Keith Moore [EMAIL PROTECTED] 11/17/03 12:53:49 The folks who paid 500 USD registration fee expect you to face the problem, and come with solutions to avoid such problems at the next meetings. Maybe that's the real problem - people think they are paying for the wireless network as part of the conference fee, when the reality (as I understand it) is that a substantial part of the cost of the wireless network comes from sponsors, donors, and/or volunteers. In other words, you get a lot more than what you pay for, but it's hardly a surprise if the quality of free service varies widely. Consistency costs money too. Personally I think the registration fee is already too high, so I'd be very reluctant to pay a substantially higher fee in order to get better wireless connectivity in the meeting rooms. Those who really need a stable network can still plug in at the terminal room. While wireless could possibly have been better than it was last week, the technology doesn't yet seem to be of the quality/maturity that 1200 people can demand free, production-quality wireless service when they're densely crammed into a few meeting rooms (in Minneapolis, most of which were really a single large meeting room partitioned with fuzzy walls). Maybe in a few years with some combination of phased-array antennas, 802.11a, more wisdom about placement, and smarter host software things will be better. It never ceases to amaze me when people who claim to be network engineers can't tolerate a week on the bleeding edge. What ever happened to eating your own dogfood? Keith This email has been scanned for computer viruses.
Re: IETF58 - Network Status
IEEE 802 doesn't seem to have as much of a problem at their plenary meetings are they trying to recover their entire organization's operating expenses by holding three meetings a year?
Re: IETF58 - Network Status
Well, that is an interesting question. Basically, IEEE 802 exists as an independent entity, with their own meeting budget. I don't believe that IEEE 802 has any other source of income, but then again, IEEE 802 doesn't have the entire IEEE organization to drag along behind it. Your point. Clint (JOATMON) Chaplin Keith Moore [EMAIL PROTECTED] 11/17/03 16:09:00 IEEE 802 doesn't seem to have as much of a problem at their plenary meetings are they trying to recover their entire organization's operating expenses by holding three meetings a year? This email has been scanned for computer viruses.
Re: IETF58 - Network Status
On 14-nov-03, at 23:08, Henk Uijterwaal (RIPE-NCC) wrote: I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) If we go for 802.11a, I sugggest that we ask a vendor (or two) to come with a pile of cards that people can borrow for a few $$ more than the manufactuiring price, and can return after the meeting, or not. Note that 802.11a isn't an option for everyone due to lack of PCMCIA ports or driver support. Also, I don't think the troubles we had are inherent to 802.11b. In Vienna there were even a few more people, but IIRC not wireless problems to speak of. I do seem to remember there were huge amounts of base stations deployed there and they used overlapping channels. (But I may be wrong.) I believe we had two problems the past week: 1. Congestion 2. Clients jumping to peer to peer networks Ignoring obvious solutions to 1. such as more 802.11a and better RF surveying/design, I think adding some 802.11g to the mix might also help. If the number of 802.11g capable hosts is large it would make sense to put them on a separate channel (and possibly SSID) where the higher bandwidth allows for a larger number of clients on a single channel and the other channels can be used by 802.11b-only hosts. If the number of 802.11g hosts is small, then it would probably be a good idea to have the base stations in mixed mode. The g hosts can still achieve higher speeds this way (although not as high as in g-only mode) so they'll leave the channel free for b traffic a larger percentage of the time. Also, the RTS/CTS mechanism that is used to make the b-only stuff be quiet while 802.11g is doing its thing could in itself be helpful. As for 2., it seems some stuff tries to hang on to the same base station network when the base station in use disappears while other implementations simply jump to the strongest network they can find, even if this is a different SSID (when the SSID isn't explicitly selected) or a peer to peer network using the same SSID. Obviously it would help if the clients improved their behavior, but wouldn't it also make sense for the base stations to simply not disappear? That would also solve the problem.
Re: IETF58 - Network Status
- Original Message - From: Iljitsch van Beijnum [EMAIL PROTECTED] As for 2., it seems some stuff tries to hang on to the same base station network when the base station in use disappears while other implementations simply jump to the strongest network they can find, even if this is a different SSID (when the SSID isn't explicitly selected) or a peer to peer network using the same SSID. I am not an 802.11 genius and am not trying to debug a LAN protocol I understand vaguely on the IETF discussion list without looking at the specs first, BUT this is approximately the behavior I thought I was seeing, too - I happened to be running Network Stumbler, especially Tuesday and Wednesday (just before the network hygiene signs were taped to all the rest room doors, in a burst of fitting irony). What I THOUGHT I was seeing was a heckuvalotta peer-to-peer transmitters insisting they were ietf58, but (at least by the time I noticed a problem and turned my attention to Network Stumbler) there were also a pretty good collection of access points for ietf58 that were reachable and active. FWIW, if my (Dell TrueMobile) card had lost its mind and connected to a different SSID based on signal strength, I would have expected to see the Hilton network pop up at least once, and I never did, so I'd be a tiny bit surprised if that was happening. It looks more like the check was for strongest signal with same SSID, not including is this also an access point? check. Once that happened, of course, I was off into the land of link-local addresses, etc. Obviously it would help if the clients improved their behavior, but wouldn't it also make sense for the base stations to simply not disappear? That would also solve the problem. I had a nice conversation with one of the university NOC chaps on Friday morning, who said a lot of the access points came up transmitting at 1 milliwatt, which was plenty until somebody walked between you and the transmitter. This should have been fine (just find another transmitter, right?), but the process kept stumbling over adjacent machines already announcing ietf58 in ad hoc mode, and (like all great networking phenomenon these days) the problem managed to spread because when (if?) the new machine went into ietf58 peer-to-peer mode, it's now close to other machines, so the next time someone interrupts their signal from the access point, they home on you, and... Sorry I don't remember the name - hope I said thank you then! Spencer
Re: IETF58 - Network Status
Marcus Leech wrote: Atheros released open-source linux drivers for their chips and the corresponding reference design. I don't know which cards use the Atheros chipset, other than ours. The atheros folks are also cooperating with the FreeBSD project, so they are making a good commitment to open source with their products. FWIW, my trusty old Netgear MA401 card could barely hold a connection in Minneapolis, but my shiny new D-Link DWL-AG650 did a much better job. This is from ath(4) on FreeBSD. Not intended to be a complete list, just a good starting point. CardChip BusStandard D-Link DWL-AB650AR5211CardBusa/b D-Link DWL-AG520AR5212PCIa/b/g D-Link DWL-AG650AR5212CardBusa/b/g D-Link DWL-G520BAR5212PCIb/g D-Link DWL-G650BAR5212CardBusb/g I/O Data WN-AG/CB AR5212CardBusa/b/g Linksys WMP55AG AR5212PCIa/b/g Linksys WPC51AB AR5211CardBusa/b Linksys WPC55AG AR5212CardBusa/b/g NEC PA-WL/54AG AR5212CardBusa/b/g Netgear WAG311 AR5212PCIa/b/g Netgear WAB501 AR5211CardBusa/b Netgear WAG511 AR5212CardBusa/b/g Netgear WG311 AR5212PCIb/g Netgear WG511T AR5212PCIb/g Nortel 2201 AR5212CardBusa/b Orinoco 8480AR5212CardBusa/b/g Proxim Skyline 4030 AR5210CardBusa Proxim Skyline 4032 AR5210PCIa Hope this helps, Doug
Re: IETF58 - Network Status
On Nov 13, 2003, at 12:46 PM, Randy Bush wrote: Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now Actually, no. 802.11a is inherently better for this sort of environment than 802.11b or 802.11g. Instead of having 3 non-overlapping channels, it has 8. Also, being at 5G it doesn't propagate as far as the 2.4G, which for us would be a real win since it would reduce interference even further. Oh, and you get 54M to share rather than 11M to boot :-) I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) - Jim IETF 58 NOC
Re: IETF58 - Network Status
On Thu, 13 Nov 2003 23:22:25 -0500 Theodore Ts'o [EMAIL PROTECTED] wrote: Another suggestion - it would have been real useful if the software on my laptop could have been told to ignore some APs (or some other laptops pretending to be APs), or to only listen to this other set of APs. White/black listing of APs... On Linux machines, as root type the command: iwconfig eth1 ap 00:0C:30:1A:69:A2 To force the access point to be 00:0c:30:1A:69:A2 You're lucky that your driver and card support this. I don't know if there's a way to make this work for those cards where the ap selection is done in firmware. Unfortunately, the driver for my Lucent card doesn't support this command and I presume that it's not possible w/ the current firmware. As someone already stated: though the card was quite good and stable at past meetings, this time it was really annoying. Either the firmware needs an update to take the new conditions (mixed environment w/ ad-hoc nets) into account or I'll have to change the vendor. Roland
Re: IETF58 - Network Status
Deploy both and we can suck it and see... On Thu, Nov 13, 2003 at 02:15:39PM -0800, Jim Martin wrote: On Nov 13, 2003, at 12:46 PM, Randy Bush wrote: Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now Actually, no. 802.11a is inherently better for this sort of environment than 802.11b or 802.11g. Instead of having 3 non-overlapping channels, it has 8. Also, being at 5G it doesn't propagate as far as the 2.4G, which for us would be a real win since it would reduce interference even further. Oh, and you get 54M to share rather than 11M to boot :-) I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) - Jim IETF 58 NOC
Re: IETF58 - Network Status
On Thu, 13 Nov 2003, Jim Martin wrote: On Nov 13, 2003, at 12:46 PM, Randy Bush wrote: Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now Actually, no. 802.11a is inherently better for this sort of environment than 802.11b or 802.11g. Instead of having 3 non-overlapping channels, it has 8. Also, being at 5G it doesn't propagate as far as the 2.4G, which for us would be a real win since it would reduce interference even further. Oh, and you get 54M to share rather than 11M to boot :-) I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) 5ghz unii allocations differ by country as well. in the US we have 5.15-5.35 for indoor/outdoor and 5.725-5.825 for outdoor. japan has 5.15-5.25 and europe has 5.15-5.35 and 5.47-5.725. I'm not sure what the allocation is in korea but it may well be different than that supported by regulatory domain A US card was built for. I would note that the a hopeful sign is that samung is a vendor of 802.11a equipment. - Jim IETF 58 NOC -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
On Fri, Nov 14, 2003 at 03:51:34PM +0100, Roland Bless wrote: You're lucky that your driver and card support this. I don't know if there's a way to make this work for those cards where the ap selection is done in firmware. Unfortunately, the driver for my Lucent card doesn't support this command and I presume that it's not possible w/ the current firmware. As someone already stated: though the card was quite good and stable at past meetings, this time it was really annoying. Either the firmware needs an update to take the new conditions (mixed environment w/ ad-hoc nets) into account or I'll have to change the vendor. I strongly recommend the Cisco Aironet 350 cards. They're a bit more expensive, but they support iwlist eth1 scan (to list all available access points and their ssid's), as well as forcing the use of a specific access point via iwconfig eth1 ap macaddr. They also have a stronger transmitter (100mW), and a more sensitive receiver, so they tend to work better in marginal areas (such when you're trying to sponge off a carelessly left wide-open Linksys router in someone's apartment in NYC :-). I generally travel with an old Orinoco (Lucent) card for lending to people who need cards, and a prism 2 card for special situations (i.e., airsnort and special driver hacking), but most of the time, I use the Aironet 350 card as the best, most flexible 802.11b client adapter that I've found to date. - Ted
Re: IETF58 - Network Status
Unfortunately, the driver for my Lucent card doesn't support this command and I presume that it's not possible w/ the current firmware. As someone already stated: though the card was quite good and stable at past meetings, this time it was really annoying. Either the firmware needs an update to take the new conditions (mixed environment w/ ad-hoc nets) into account or I'll have to change the vendor. I'm pretty sure its not fireware thats tthe issue. Make sure your kernel is patched with the latest version of wireless extensions, then compile wireless-tools calling includes from the patched kernel headers. Roland sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: IETF58 - Network Status
On Thu, 13 Nov 2003 11:51:57 -0500 (EST) shogunx [EMAIL PROTECTED] wrote: Unfortunately, the driver for my Lucent card doesn't support this command and I presume that it's not possible w/ the current firmware. As someone already stated: though the card was quite good and stable at past meetings, this time it was really annoying. Either the firmware needs an update to take the new conditions (mixed environment w/ ad-hoc nets) into account or I'll have to change the vendor. I'm pretty sure its not fireware thats tthe issue. Make sure your kernel is patched with the latest version of wireless extensions, then compile wireless-tools calling includes from the patched kernel headers. Though I'm able to do this (which may not be true for other linux users), and, it really costs a lot of time to do it. I've done it several times at past meetings, because the driver wasn't stable enough and crashed my kernel several times. This time I contacted the author of the driver and he had no idea how to override the firmware's handover decision, sorry. Roland
Re: IETF58 - Network Status
Roland, Though I'm able to do this (which may not be true for other linux users), and, it really costs a lot of time to do it. I've done it several times at past meetings, because the driver wasn't stable enough and crashed my kernel several times. Which driver/kernel version are you working with? I have been using a collection of prism2 chipset based card on my clustered lan, where the parallel processing traffic is significant, running a hostap and openmosix patched 2.4.20 kernel, and have never had a problem. This time I contacted the author of the driver and he had no idea how to override the firmware's handover decision, sorry. Do you have the code for the firmware, or only a binary? Scott Roland sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: IETF58 - Network Status
On Thu, 13 Nov 2003, Jim Martin wrote: I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) If we go for 802.11a, I sugggest that we ask a vendor (or two) to come with a pile of cards that people can borrow for a few $$ more than the manufactuiring price, and can return after the meeting, or not. Henk -- Henk Uijterwaal Email: [EMAIL PROTECTED] RIPE Network Coordination CentreWWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB AmsterdamFax: +31.20.5354445 The NetherlandsThe Netherlands Mobile: +31.6.55861746 -- That problem that we weren't having yesterday, is it better? (Big ISP NOC)
Re: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE- Theodore == Theodore Ts'o [EMAIL PROTECTED] writes: Theodore On Linux machines, as root type the command: Theodore iwconfig eth1 ap 00:0C:30:1A:69:A2 Theodore To force the access point to be 00:0c:30:1A:69:A2 Theodore I don't know if there's a way to make this work for those cards Theodore where Theodore the ap selection is done in firmware. It does not work. You get an error. And your solution keeps you from roaming to other APs as you move. We need 1) whitelists and blacklists 2) a way to authenticate the APs ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7T8JoqHRg3pndX9AQEwxwP+L2IVv7oMF62NjX9bf3cLvHsYuPuEXOlw lyY6zrZIyqAs/HSXRAkbeHyZ4LcdMvNTflRpnxOwGfpjRo5wybiocAyig+3dRUDa D8pqVnhTkBKE122SWxy1X9xYD899VekGF0n60sg/3Y4LZtFCYjTnJxvMrEmgBhIM EuQBRVJvFz0= =s6zE -END PGP SIGNATURE-
Re: IETF58 - Network Status
This is not the solution. I'm not going to change the technology that I use because we haven't been able to setup a good network here. We should learn from the mistakes and do it better next time, as we know it worked in Vienna. I use b or g, because is what I carry with me, and I will not accept being forced to move to a, because we aren't able to fix problem that can be solved, is not rational ! If the network is a/b/g, then no problem, but not restrict the support for one or the other. We know b and g work ! The network is important for most of us. I'm not going to attend to more meeting if the network is not warranted to work, because this is taking a lot of my time, and I need facilities to do it, not difficulties. The volunteer effort need some compensation, and we only demand for a stable network. I think is not too much, specially because we know that can be done. We have less and less people attending the meeting, and I feel that if we can't keep going with our obligations (daily work) together with our IETF volunteer effort, the attendance with drop more and more. I hope we can solve this problem soon. Regards, Jordi - Original Message - From: Henk Uijterwaal (RIPE-NCC) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 14, 2003 4:08 PM Subject: Re: IETF58 - Network Status On Thu, 13 Nov 2003, Jim Martin wrote: I strongly encourage people to consider bringing 802.11a cards to future meetings! (Note: Of course, now that I've said that, the future hosts will decide against deploying it) If we go for 802.11a, I sugggest that we ask a vendor (or two) to come with a pile of cards that people can borrow for a few $$ more than the manufactuiring price, and can return after the meeting, or not. Henk -- Henk Uijterwaal Email: [EMAIL PROTECTED] RIPE Network Coordination CentreWWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB AmsterdamFax: +31.20.5354445 The NetherlandsThe Netherlands Mobile: +31.6.55861746 -- That problem that we weren't having yesterday, is it better? (Big ISP NOC) ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Re: IETF58 - Network Status
Just to echo Randall here - it seemed especially brutal last night, when we were all in Salon D. I didn't start Network Stumbler during the Plenary, but I did earlier in the week, and was seeing as many as 15-20 machines announcing ad-hoc ietf58. If I hadn't been typing as fast as I could, I would have suggested that we stop the plenary long enough to turn off all the offenders! But perhaps we could make this announcement tonight, after everyone gets inside and turns their machines on? Spencer - Original Message - From: Randall Gellens [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 11:15 PM Subject: Re: IETF58 - Network Status I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- SFPD Homicide: Our Day Begins when Yours End --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re[2]: IETF58 - Network Status
I have seen the exact same phenomena this afternoon and evening. I am starting to get paranoid. Is there a vengeful person out there who wants us to stop reading mail and listen to the WG meetings? Is there a bit pattern that someone is broadcasting on purpose that causes this problem? It is not working. It is just making everybody play with their network settings all the time! Even less attention is going to the WG meetings! Oh well, Cyrus On Wed, 12 Nov 2003 21:15:35 -0800 Randall Gellens [EMAIL PROTECTED] wrote: randy I have been consistently unable to maintain a connection for more randy than a very few minutes, usually not even long enough to establish a randy VPN tunnel and fetch one message. The 802.11 coverage comes and randy goes; the APs seem to vanish and I see nothing for a while, randy eventually the network comes back but only briefly. This has been randy the case in every session I've attended, as well as tonight's randy plenary. It doesn't seem to matter if the room is crowded or empty, randy or where I sit. randy randy I have attempted to only select the 'ietf58' network, but often the randy network vanishes and there are no networks visible; other times the randy only visible network is an ad-hoc calling itself 'ietf58'. randy -- randy Randall Gellens randy Opinions are personal;facts are suspect;I speak for myself only randy -- Randomly-selected tag: --- randy SFPD Homicide: Our Day Begins when Yours End --Slogan seen on back of randy San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle randy randy ___ randy This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re[2]: IETF58 - Network Status
this is partially a product of your driver and it's user-interface... if you can really truely statically configure your adhesion to managed network it will work better. joelja On Wed, 12 Nov 2003, Cyrus Shaoul wrote: I have seen the exact same phenomena this afternoon and evening. I am starting to get paranoid. Is there a vengeful person out there who wants us to stop reading mail and listen to the WG meetings? Is there a bit pattern that someone is broadcasting on purpose that causes this problem? It is not working. It is just making everybody play with their network settings all the time! Even less attention is going to the WG meetings! Oh well, Cyrus On Wed, 12 Nov 2003 21:15:35 -0800 Randall Gellens [EMAIL PROTECTED] wrote: randy I have been consistently unable to maintain a connection for more randy than a very few minutes, usually not even long enough to establish a randy VPN tunnel and fetch one message. The 802.11 coverage comes and randy goes; the APs seem to vanish and I see nothing for a while, randy eventually the network comes back but only briefly. This has been randy the case in every session I've attended, as well as tonight's randy plenary. It doesn't seem to matter if the room is crowded or empty, randy or where I sit. randy randy I have attempted to only select the 'ietf58' network, but often the randy network vanishes and there are no networks visible; other times the randy only visible network is an ad-hoc calling itself 'ietf58'. randy -- randy Randall Gellens randy Opinions are personal;facts are suspect;I speak for myself only randy -- Randomly-selected tag: --- randy SFPD Homicide: Our Day Begins when Yours End --Slogan seen on back of randy San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle randy randy ___ randy This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
RE: IETF58 - Network Status
Randall Gellens wrote: I have been consistently unable to maintain a connection for more than a very few minutes, usually not even lon enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have had the same issue. Not suggesting the way I solved it is the right one, it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. If your WiFi card is a removable PCMCIA one, try to swap it temporarily with another one; some of the older card would work fine in less crowded environments but can't take the heat of the kind of WiFi we have for meetings. Michel.
RE: IETF58 - Network Status
Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Bless Sent: 13 November, 2003 7:08 PM To: Randall Gellens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IETF58 - Network Status Hi Randall, I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been I can partly confirm your observations, since I often see my driver reporting a signal strength of 0 for seconds. The connection is somehow unstable as my log also reports (NSIS meeting this morning, actually not crowded) Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) ... and so on... however, it seems also to depend on the cards firmware and driver, so other people may have no problems at all... Inspite all the problems, it works well enough to get things actually done. the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. I wasn't often successful to reattach to APs after my card was hi-jacked to ad-hoc cards announcing ietf58. Setting the essid again to the same value seems to do trick, however, often I see signals of strength 0 (maybe the card is confused then..). Furthermore, it happens often that I don't get an IPv6 address directly after activating the card (maybe the RA doesn't get through). Cheers, Roland
Re: IETF58 - Network Status
Michel Py [EMAIL PROTECTED] writes: I have had the same issue. Not suggesting the way I solved it is the right one, it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. Note that getting 802.11a works even better. Perry
Re: IETF58 - Network Status
Joel Jaeggli wrote: this is partially a product of your driver and it's user-interface... if you can really truely statically configure your adhesion to managed network it will work better. I don't know. I can configure my linux card to be in managed mode on ssid ietf58, but that seems to mainly achieve the situation where I don't hear any APs whatsoever. From where I sit, it looks like the APs just disappear. This could of course also be an issue with my drivers getting confused about the many other APs appearing and disappearing -- but can someone confirm that the official APs are up and running and are not crashing? Anyway, I don't want us to organize a witch hunt for the poor folks who forgot to turn of ad-hoc mode in their machines. The protocols and products should work better than this, imho. --Jari
Re: IETF58 - Network Status
Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now
Re: IETF58 - Network Status
Randy Bush writes: Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now I think 802.11a should be able to support more than twice as many users than 802.11b. At least in the US, the band reserved for 802.11a has more channels available than the one for 802.11b, in particular more non-overlapping channels. For this reason, and because of the lack of competition from 802.11b users, 802.11a should also support more users than 802.11g (54 Mb/s in the 2.4 GHz band). So for settings such as IETF/NANOG etc. this seems very attractive. If someone knows which 802.11a PCMCIA card can be made to work reliably under Linux (with 2.6 kernel!), I'd really like to hear about it... -- Simon.
Re: IETF58 - Network Status
it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. Similarly, when I put a $70 Linksys WPC54G (directly supported by Mac OS X 10.2.8) into my Powerbook to override the builtin (Lucent-made) Airport card, and switched on Interference Robustness, I got much more consistent network access. I'm still losing network access now and then, and my TCP connections mysteriously wedge sooner or later, but I'm functional. I would suspect that most people complaining are using the time-tested Lucent/Orinoco card, which is now getting a bit old. It sure makes sense to have a deck of cards available if you really need the Wi-Fi. Gruesse, Carsten
Re: IETF58 - Network Status
Simon Leinen wrote: If someone knows which 802.11a PCMCIA card can be made to work reliably under Linux (with 2.6 kernel!), I'd really like to hear about it... Atheros released open-source linux drivers for their chips and the corresponding reference design. I don't know which cards use the Atheros chipset, other than ours.
Re: [58crew] RE: IETF58 - Network Status
On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote: Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. The only thing thing you have to be sorry for is not coming to us sooner. If you had come to us sooner, we could have been able to solve some of your problems or fix it all together. We hope that by working together to solve these problems we can help you out. I have heard many comments from many people that this has been a great wireless IETF. We identified several client problems, and we saw a larger number of infected machines. If the wireless did suffer (which I don't think it did because of our volunteer team who worked VERY hard and configuring it) it was due to problems simply beyond our control. And as always, we are happy to take in more volunteers. If there is something you don't like, hop on board and solve the problems! Cheers, and I hope to hear more from you, in realtime next time these issues pop up. --Brett Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Bless Sent: 13 November, 2003 7:08 PM To: Randall Gellens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IETF58 - Network Status Hi Randall, I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been I can partly confirm your observations, since I often see my driver reporting a signal strength of 0 for seconds. The connection is somehow unstable as my log also reports (NSIS meeting this morning, actually not crowded) Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) ... and so on... however, it seems also to depend on the cards firmware and driver, so other people may have no problems at all... Inspite all the problems, it works well enough to get things actually done. the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. I wasn't often successful to reattach to APs after my card was hi-jacked to ad-hoc cards announcing ietf58. Setting the essid again to the same value seems to do trick, however, often I see signals of strength 0 (maybe the card is confused then..). Furthermore, it happens often that I don't get an IPv6 address directly after activating the card (maybe the RA doesn't get through). Cheers, Roland ___ 56crew mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/56crew
Re: [58crew] RE: IETF58 - Network Status
Brett, It would be great if you could publish all the issues that came up, how you fixed them, and a brief overview of what you deployed (at the start and end) for the event. Tim On Thu, Nov 13, 2003 at 06:50:11PM -0500, Brett Thorson wrote: On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote: Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. The only thing thing you have to be sorry for is not coming to us sooner. If you had come to us sooner, we could have been able to solve some of your problems or fix it all together. We hope that by working together to solve these problems we can help you out. I have heard many comments from many people that this has been a great wireless IETF. We identified several client problems, and we saw a larger number of infected machines. If the wireless did suffer (which I don't think it did because of our volunteer team who worked VERY hard and configuring it) it was due to problems simply beyond our control. And as always, we are happy to take in more volunteers. If there is something you don't like, hop on board and solve the problems! Cheers, and I hope to hear more from you, in realtime next time these issues pop up. --Brett Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Bless Sent: 13 November, 2003 7:08 PM To: Randall Gellens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IETF58 - Network Status Hi Randall, I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been I can partly confirm your observations, since I often see my driver reporting a signal strength of 0 for seconds. The connection is somehow unstable as my log also reports (NSIS meeting this morning, actually not crowded) Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) ... and so on... however, it seems also to depend on the cards firmware and driver, so other people may have no problems at all... Inspite all the problems, it works well enough to get things actually done. the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. I wasn't often successful to reattach to APs after my card was hi-jacked to ad-hoc cards announcing ietf58. Setting the essid again to the same value seems to do trick, however, often I see signals of strength 0 (maybe the card is confused then..). Furthermore, it happens often that I don't get an IPv6 address directly after activating the card (maybe the RA doesn't get through). Cheers, Roland ___ 56crew mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/56crew
Re: IETF58 - Network Status
You can probably find that info at http://personaltelco.net although I'm not sure you will be able to take advantage of the Prism2 chipset AP fuctions avialable using 80211b. Scott On Thu, 13 Nov 2003, Simon Leinen wrote: Randy Bush writes: Note that getting 802.11a works even better. until everybody does, and 'everbody' is twice as many people as now I think 802.11a should be able to support more than twice as many users than 802.11b. At least in the US, the band reserved for 802.11a has more channels available than the one for 802.11b, in particular more non-overlapping channels. For this reason, and because of the lack of competition from 802.11b users, 802.11a should also support more users than 802.11g (54 Mb/s in the 2.4 GHz band). So for settings such as IETF/NANOG etc. this seems very attractive. If someone knows which 802.11a PCMCIA card can be made to work reliably under Linux (with 2.6 kernel!), I'd really like to hear about it... -- Simon. sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
RE: IETF58 - Network Status
--On 13. november 2003 21:46 +0200 Romascanu, Dan (Dan) [EMAIL PROTECTED] wrote: Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. not been around long? I remember one of the earlier Washington IETFs a LOT fewer laptops, but even bigger problems. And that even without the misbehaviour seen today. we're living on the bleeding edge, and this time it seems we're bleeding more than usual, thanks to some problems we still don't understand fully. so rather than worrying, let's see what we can do to help if someone - for instance - has EFFECTIVE tools for triangulating and locating ad-hoc stations, perhaps they can bring them to the next IETF meeting? hARALD
RE: IETF58 - Network Status
basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. randy
RE: IETF58 - Network Status
Sitting in the Thursday plenary, I note none of the network-to-ad-hoc flappage that have been plaguing us the past few days. Did the attackers get bored and go home? Did the accidental ad-hocers finally get their settings right? Did someone deploy a good blocking mechanism? --Paul Hoffman, Director --Internet Mail Consortium
Re: IETF58 - Network Status
In message [EMAIL PROTECTED], Randy Bush writes: basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. We also had the new overly helpful operating systems and a variety of infected machines eating bandwidth. --Steve Bellovin, http://www.research.att.com/~smb
Re: IETF58 - Network Status
On Thu, Nov 13, 2003 at 07:57:33PM -0600, Harald Tveit Alvestrand wrote: so rather than worrying, let's see what we can do to help if someone - for instance - has EFFECTIVE tools for triangulating and locating ad-hoc stations, perhaps they can bring them to the next IETF meeting? Another suggestion - it would have been real useful if the software on my laptop could have been told to ignore some APs (or some other laptops pretending to be APs), or to only listen to this other set of APs. White/black listing of APs... --asp
Re: IETF58 - Network Status
On 13-nov-03, at 16:44, Carsten Bormann wrote: it turned out that when I replaced my Linksys 802.11b with a brand new Motorola 802.11g the problem went away; there is a Radio Shark on the third floor of City Center that sells them for $70. Similarly, when I put a $70 Linksys WPC54G (directly supported by Mac OS X 10.2.8) into my Powerbook to override the builtin (Lucent-made) Airport card, and switched on Interference Robustness, I got much more consistent network access. I'm still losing network access now and then, and my TCP connections mysteriously wedge sooner or later, but I'm functional. Hm, I've only really lost connectivity a few times but I did suffer from hanging TCP sessions fairly consistently when sending somewhat large amounts of data at some times in some rooms. But in those cases the packet loss was double and the RTTs to the first router triple digits. This is with a week old Powerbook with built-in 802.11g.
Re: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE- IMC == IMC Paul writes: IMC Sitting in the Thursday plenary, I note none of the network-to-ad-hoc IMC flappage that have been plaguing us the past few days. IMC Did the attackers get bored and go home? No, you are just sitting in the wrong part of the room. But, it is much better than it was at SAAG. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian/notebook using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7REQIqHRg3pndX9AQFYUQQA76jiRGOZNwSfJV4J668xMKAQ9f9ORnbK YcZb3mELHP6WL6Qr2hpwwZnHgjiwSUSMXWZ7xW50OJSOL0RXUgTkpaKaJOy80EzG lM/Ta4uu4ze/E8xuDxuoHjoJtREUMeC/W4g/O/LTy5sZMAhB6k3sebtXTWW3Hjkj WTDwhNp7aFo= =ERVG -END PGP SIGNATURE-
RE: IETF58 - Network Status
I would have agreed with you until I just bounced onto the aodv network - oh well Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman / IMC Sent: Thursday, November 13, 2003 6:23 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: IETF58 - Network Status Sitting in the Thursday plenary, I note none of the network-to-ad-hoc flappage that have been plaguing us the past few days. Did the attackers get bored and go home? Did the accidental ad-hocers finally get their settings right? Did someone deploy a good blocking mechanism? --Paul Hoffman, Director --Internet Mail Consortium
Re: IETF58 - Network Status
On Thu, Nov 13, 2003 at 09:33:30PM -0500, Andrew Partan wrote: Another suggestion - it would have been real useful if the software on my laptop could have been told to ignore some APs (or some other laptops pretending to be APs), or to only listen to this other set of APs. White/black listing of APs... On Linux machines, as root type the command: iwconfig eth1 ap 00:0C:30:1A:69:A2 To force the access point to be 00:0c:30:1A:69:A2 I don't know if there's a way to make this work for those cards where the ap selection is done in firmware. - Ted
Re: IETF58 - Network Status
We also had the new overly helpful operating systems and a variety of infected machines eating bandwidth. How depressing. Does anybody have any good estimate on what % of machines were infected with one or more of the usual standard-equipment pieces of bandwidth-sucking malware? It's sad that at an IETF this is a problem, preaching to the choir and all that. On the other hand, it's not an IETF-only problem. I was at a SANS class we were hosting a few months ago on using tcpdump. So just for grins, I set up a little tcpdump script, and after about 2 hours, right before the lunch break, I announced We have some 280 people in this lecture hall, and so far I've seen 97 MAC addresses on the wireless talking to POP-over-SSL on port 995, and 80 or so talking cleartext POP. Some guy in the back of the room asked if I was grabbing passwords, and I told him I'm a white hat. I was gathering *only* SYN packets for statistical purposes. I have *no* idea what anybody *else* in this 100,000 square foot building was grabbing out of the air. It was pretty easy to identify the 80 or so then... all deer in headlights and tapping at keyboards furiously.. :) pgp0.pgp Description: PGP signature
Re: [58crew] RE: IETF58 - Network Status
basic lessons previously learned were not put to use here, e.g., lowering the radios so wetware limits range and reduces xmtrs bandwidth fight. Right. Like this really works. This just ensures that the folks in the middle of the room will get really bad performance. Been there. the opposite. it allows us to put xmtrs in the middle of the room without contending with others. randy
Re: IETF58 - Network Status
I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- SFPD Homicide: Our Day Begins when Yours End --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle
Re: IETF58 - Network Status - 12:05PM Local Time
There is an AODV test running but it requires, uh, running AODV. See: http://moment.cs.ucsb.edu/aodv-ietf It actually has nothing to do with the evil that is MSFT's ad hoc. And, it also works if you get everything configured correctly. However, it is currently shutdown until the wireless is working happily. As for those people who run around with their cards in ad hoc mode, yes, especially here, they should know better. As one of the people working on the tests, I'll send out email to [EMAIL PROTECTED] when we are bringing the AODV network back up to explain how to and how NOT to use it. -Kevin
Re: IETF58 - Network Status - 12:05PM Local Time
It sounds to me like this at least as likely to be caused by cluelessness as malice. If we eventually want a world where networks this big are everywhere, we can't afford to blame the users for cluelessness when those networks break, especially since the average user in that future will be at least *slightly* more clueless than the average IETF attendee. And if it's this easy to mess up maliciously, well maybe we should be commissioning an IETF police force that will develop the tools to track down the offending laptops in real time and pour diet Coke in their network cards? -- Nathaniel On Mon, 10 Nov 2003, JORDI PALET MARTINEZ wrote: Is a very bad behavior from some people that it seems don't know how to use their own computer. I will say that this people should pay 5 times the normal fee in the next IETF meeting, because the big number of troubles that they create to the rest of the participants. We all have a lot of work to do, and can't waste our time because this people. Sorry, but is what I feel right now, after spending 2 hours trying to get my email. Regards, Jordi
Re: IETF58 - Network Status - 12:05PM Local Time
As for those people who run around with their cards in ad hoc mode, yes, especially here, they should know better. One problem may be those helpful features where the OS is switching to ad-hoc when there is no base station to be seen. In Mac OS X 10.2, you can disable that (switch off Allow this computer to create networks in Airport tab of Network pane), but you cannot disable joining to an existing IBSS if the base station goes away. As the base stations seem to go away a lot (an effect I don't understand yet), once *somebody* starts an ad-hoc, the Macs will sooner or later find it and then sustain it, as each IBSS Mac serves as a condensation point for other Macs. Oops. Fixed in 10.3, AFAIK. Unfortunately, not everyone is running that yet. Now in Windows XP, it seems to have become positively hard to enable Ad-hoc. Previous Windowses are a different story... Gruesse, Carsten
Re: IETF58 - Network Status - 12:05PM Local Time
On Tue, 11 Nov 2003 09:55:59 EST, Nathaniel Borenstein [EMAIL PROTECTED] said: And if it's this easy to mess up maliciously, well maybe we should be commissioning an IETF police force that will develop the tools to track down the offending laptops in real time and pour diet Coke in their network cards? -- Nathaniel Remember that half the people out there are of below average intelligence. Also, half of them are below average moral fiber. Any protocol that doesn't allow for this is doomed to disaster. The only reason BGP works is most providers do at least some filtering of the cluon-lacking before giving them the enable password on the routers. Similarly, the current spam problem is due to SMTP's design ignoring the second (I'll leave open the question on whether this is a sender or receiver issue ;) Even given the tools, who will track down offending laptops in real time once it deploys in the real world? (I have at least 3 co-workers that I know of that have laptops with wireless for use at work, who have been surprised to find themselves on a wireless net when they get home, even when they don't have an access point. Sometimes, the line between ad-hoc and ad-crock is drawn with a #00 pencil). pgp0.pgp Description: PGP signature
Re: IETF58 - Network Status - 12:05PM Local Time
Totally agree with your view, sorry if I was too much rude. But the result is that today the network is working better than never ! Regards, Jordi - Original Message - From: Nathaniel Borenstein [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 8:55 AM Subject: Re: IETF58 - Network Status - 12:05PM Local Time It sounds to me like this at least as likely to be caused by cluelessness as malice. If we eventually want a world where networks this big are everywhere, we can't afford to blame the users for cluelessness when those networks break, especially since the average user in that future will be at least *slightly* more clueless than the average IETF attendee. And if it's this easy to mess up maliciously, well maybe we should be commissioning an IETF police force that will develop the tools to track down the offending laptops in real time and pour diet Coke in their network cards? -- Nathaniel On Mon, 10 Nov 2003, JORDI PALET MARTINEZ wrote: Is a very bad behavior from some people that it seems don't know how to use their own computer. I will say that this people should pay 5 times the normal fee in the next IETF meeting, because the big number of troubles that they create to the rest of the participants. We all have a lot of work to do, and can't waste our time because this people. Sorry, but is what I feel right now, after spending 2 hours trying to get my email. Regards, Jordi ** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
