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: [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: [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: [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: [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: [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: [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: [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: [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: [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
