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
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
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
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
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
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,
-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
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
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
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
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
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
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
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
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
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
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.
19 matches
Mail list logo
