Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
- Subject: Re: Reducing the Minimum Packet Retransmit Delay on MacOS X
- From: David Garcea <email@hidden>
- Date: Thu, 16 Aug 2007 15:23:42 -0700
- Thread-topic: Reducing the Minimum Packet Retransmit Delay on MacOS X
Thanks for the quick response, Peter.
> I'm not familiar with a minimum RTO (RTO = srtt + 4*rttvar), so
> perhaps the problem is the rttvar (smoothed mean deviation estimator).
> Since you indicate packets are being dropped, this suggests you are
> overflowing some input queue which may result in a large value for rttvar.
Yes, we've been looking into this, trying to solve the problem that causes
the packets to be lost in the first place. However, even if we resolve that
issue, it does not eliminate the possibility of packet loss, and therefore
we would still like to be able to lower the minimum retransmit delay.
> From your description, it is unclear where packets are being dropped.
The packets that are being lost are sent from the Mac to the hardware
device. We believe they are being lost on the Mac, but the only test we've
devised to determine this involves introducing a switch between the Mac and
the device and watching the traffic using a mirrored port on the switch. In
that case, packets appear to be dropped by either the Mac, or the switch.
> Other features include "Duplicate ack fast retransmit"
> that allows a receiver to request a quick retransmission,
> and Selective Ack that allows the receiver to indicate the
> specific segments it needs retransmitted.
It appears as though the TCP implementation on the device does not support
Reno, or NewReno, and therefore can't request fast retransmit or use SACKs.
That is another area where we are looking to resolve the issue.
> The TCP Info tool in my own IPNetMonitorX might give you a bit
> more information as it plots duplicate and retransmit data in
> real time (free for 21 days).
Thanks, I'll give it a try.
The Darwin TCP code led us to believe that locking the RTT for that IP using
the route command line tool might allow us to bypass the minimum retransmit
delay, but we haven't gotten any change in behavior after doing that.
Regards,
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden