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 b
>
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
>
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 t
> 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, event
and 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
"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
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
> Note that getting 802.11a works even better.
until everybody does, and 'everbody' is twice
as many people as now
the map coloring problem is a lot easier with 8 non-overlaping channels.
joelja
On Thu, 13 Nov 2003, Randy Bush wrote:
> > Note that getting 802.11a works even better.
>
> until everybody does, and 'everbody' is twice
> as many people as now
>
>
--
--
Joel Jaeggli <[EMAIL PROTECTED]> writes:
> the map coloring problem is a lot easier with 8 non-overlaping channels.
And indeed, it isn't even possible with just three.
Perry
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 avai
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 o
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 A
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.
>
--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
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
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, Dir
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 b
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?
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 supp
-BEGIN PGP SIGNED MESSAGE-
> "IMC" == IMC 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 wro
: 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
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 l
> 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
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
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
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
> > o
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
> >
> >
>
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
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 supp
>
> 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 u
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
>
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 wor
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
-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 kno
ginal 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
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 t
- 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 t
>>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
r 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,
>
> 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 th
> 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
unders
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
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?
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
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 1
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
There is a difference between having a couple of hubs in the middle of a
table with a box of patch cables nearby (or bring your own) versus the
current carefully laid cable bundles with a drop at each seat. It's mostly
a question of what gets used or not. I remember not so long ago we had
LocalTalk
> 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
f 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
>
ROTECTED]>
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:
>
&g
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
quot;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 PALE
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-ter
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
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., intern
> 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 connectio
> 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
> 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
un
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
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
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 deve
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
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
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 tr
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
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
> >
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 counte
>>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 wel
>>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 un
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 signifi
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
k ;-)
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
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 excep
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 th
-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 SIGNATUR
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 use
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
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
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 a
---
> > 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 Ra
op 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
> > >
>> 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 oppos
> "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 wirele
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
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
-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 somet
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...
>
> F
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
Fra
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 wi
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
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 s
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
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
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 in
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 ai
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,
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 hardw
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, a
We currently have three external routes, all are up.
Wireless has been deployed to the hotel, and we are still working to get good
signal coverage to the Brit's Pub. We have a solution that will start to get
executed later this afternoon. That should dramatically increase the
coverage in that
1 - 100 of 118 matches
Mail list logo
