Problems with SSH hangs over Clear WiMAX

[bea...@myrealbox.com]

I've been having my ssh sessions hang regularly since switching to Clear's
WiMAX Home service. Console-based IMAP+SSL sessions also hang. Hangs
occur anywhere from 5-25 minutes into the session, usually quicker if
idle for several minutes. I've added the following to my ssh_config file
in attempt to fix the issue:

ServerAliveInterval 15

It seems to help some. My setup is simply a NetBSD laptop connected
to the Motorola CPEi150 via CAT5. The CPE does DHCP & NAT; WiMAX
connection uses dynamic IPs, however my IP hasn't changed in several days.
The NIC's MTU is 1500. Is there something else I can do to fix this?
Plain old web browsing seems to work okay.

Regards,
Jeff

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---

[Tyler Booth]

As with any type of wireless connection (licensed or unlicensed), WiMAX is more susceptible to jitter, latency, packetloss, etc that can cause session based connections to behave badly. Web browsing, POP, SMTP, etc are all transactional in nature and more tolerant of latency.

If your session based connections are important to you, DSL is a far superior technology as there is no shared medium with the exception of the backhaul which in most cases these days is fiber and has plenty of capacity.

Tyler Booth // President
ph. 503.548.2000 | fx. 503.548.2002
921 SW Washington St, Suite 224
Portland OR 97205

[Conor Todd]

*ahem*

I regularly SSH through tunneled connections to the company I'm working for, and those sessions stay up, even when I bounce the tunneled connection (drop it and re-connect).  I find it difficult to believe that WiMAX is the sole source of the problem here, if indeed packets are having trouble getting through.

   - Conor

[Tyler Booth]

Just speaking from personal experience here. We provide wireless service to hundreds of customers and are quite familiar with Clear's network as well. It's -WIRELESS- not WiMAX as a specific technology that is the root of the issue, it's a heavily shared medium and susceptible to packet loss, latency and jitter all of which will cause poor performance on session based connections such as ssh, SIP, RDP, etc. Transactional based traffic such as HTTP, SMTP,etc, don't suffer from this.

Tyler Booth // President
ph. 503.548.2000 | fx. 503.548.2002
921 SW Washington St, Suite 224
Portland OR 97205

[Jim Blandy]

On Tue, Jan 20, 2009 at 12:37 PM, Tyler Booth <ty...@stephouse.net> wrote:
> Just speaking from personal experience here. We provide wireless service to
> hundreds of customers and are quite familiar with Clear's network as well.
> It's -WIRELESS- not WiMAX as a specific technology that is the root of the
> issue, it's a heavily shared medium and susceptible to packet loss, latency
> and jitter all of which will cause poor performance on session based
> connections such as ssh, SIP, RDP, etc. Transactional based traffic such as
> HTTP, SMTP,etc, don't suffer from this.

And these WiMAX issues are beyond TCP's ability to recover from?

[Tyler Booth]

Again, not just WiMAX, but any wireless is far more susceptible to this than wired connections. Cable internet excluded here as it's also a shared medium although as 

the DOCSIS standard evolves, this is less and less of an issue as the overall capacity of that shared medium increases.

And the short answer.....Yes.

[Jim Blandy]

On Wed, Jan 21, 2009 at 1:31 PM, Tyler Booth <ty...@stephouse.net> wrote:

On Tue, Jan 20, 2009 at 12:37 PM, Tyler Booth <ty...@stephouse.net> wrote:

Just speaking from personal experience here. We provide wireless service to

hundreds of customers and are quite familiar with Clear's network as well.

It's -WIRELESS- not WiMAX as a specific technology that is the root of the

issue, it's a heavily shared medium and susceptible to packet loss, latency

and jitter all of which will cause poor performance on session based

connections such as ssh, SIP, RDP, etc. Transactional based traffic such as

HTTP, SMTP,etc, don't suffer from this.

And these WiMAX issues are beyond TCP's ability to recover from?

Again, not just WiMAX, but any wireless is far more susceptible to this than wired connections. Cable internet excluded here as it's also a shared medium although as 

the DOCSIS standard evolves, this is less and less of an issue as the overall capacity of that shared medium increases.

And the short answer.....Yes.

This issue came up again in a discussion with some friends.  My understanding of how this stuff works is really clashing with your empirical observations, and I want you to change your observations, err, I mean, I'd really like to understand what's going on here. :)

Within limits, TCP is designed to be robust in the face of packet loss.  Do wireless connections really drop all packets for long enough that TCP times out?

Inconsistent latency looks like packet loss, except that if the sender retransmits, the receiver will get duplicate packets.  Again, TCP is supposed to handle this.  Does this fail somehow?

What does "jitter" mean in this context?

[Christopher Chen]

On Mon, Mar 8, 2010 at 12:48 AM, Jim Blandy <ji...@red-bean.com> wrote:
> This issue came up again in a discussion with some friends.  My
> understanding of how this stuff works is really clashing with your empirical
> observations, and I want you to change your observations, err, I mean, I'd
> really like to understand what's going on here. :)
>
> Within limits, TCP is designed to be robust in the face of packet loss.  Do
> wireless connections really drop all packets for long enough that TCP times
> out?
>
> Inconsistent latency looks like packet loss, except that if the sender
> retransmits, the receiver will get duplicate packets.  Again, TCP is
> supposed to handle this.  Does this fail somehow?
>
> What does "jitter" mean in this context?

So why not try it out?

The issue is not TCP, but assumptions made by protocols that run on
top of it (is this a crazy out of left field guess? YOU BETCHA!)
Granted, SSHd does have tunables, and you can play with keepalive
packets, but really, why not come up with your own empirical
observations rather than trying and browbeat people on the list?

As a former clearwire subscriber, I can say that I noticed some very
strange behavior with SSH and HTTP. I always thought that perhaps it
had to do more with firewall/transparent proxy "foo" in the black box
rather than latency (although I wasn't a fan of the latency either).

cc

--
Chris Chen <muff...@gmail.com>
"The fact that yours is better than anyone else's
is not a guarantee that it's any good."
-- Motivational Poster

[Christopher Chen]

I realize that I may have been a bit unkind on that last email, and I apologize.

[Jim Blandy]

On Mon, Mar 8, 2010 at 11:10 AM, Christopher Chen <muff...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 10:45 AM, Christopher Chen <muff...@gmail.com> wrote:
>> So why not try it out?

I use streamy protocols over wifi every day, all day long, and don't
usually have any problems. But that's wifi to a Comcast cable modem
connection.

>> observations rather than trying and browbeat people on the list?

Well, if I came across as wanting to browbeat anyone, that was my
mistake; I apologize. That was meant to be a joke about being
unwilling to revise theory ("TCP takes care of that!") in the face of
uncomfortable facts ("my SSH sucks over wireless"). The reason I went
over specific points was to make it easier for someone to say, "Oh,
you'd think so, but actually..."

[Christopher Chen]

Yes, I think you might be right. Something's definitely going on, but
I think it has to do more with network (mis)management.

I wouldn't be surprised that in addition to packet loss, Clearwire's
doing some sort of transparent proxying/firewalling, and
long-TCP-session users get caught in the fray, either by way of some
state table timeout, or what-have-you.

Again, sorry for accusing you of being a mean person.

cc

[Russell Senior]

>>>>> "Jim" == Jim Blandy <ji...@red-bean.com> writes:

Jim> That was meant to be a joke about being
Jim> unwilling to revise theory ("TCP takes care of that!") in the
Jim> face of uncomfortable facts ("my SSH sucks over wireless"). The
Jim> reason I went over specific points was to make it easier for
Jim> someone to say, "Oh, you'd think so, but actually..."

I remember being surprised by this also. I learned in my TCP/IP class
that the whole reason for TCP was to provide reliability on an
unreliable medium. However, empirically, I found that when there was
very much packet loss my ssh sessions went quickly to hell. I still
don't really have a good model for why this runs counter to my
expectations for TCP. I doubt this has to do with proxying, because I
used to see it in contexts where there probably wasn't any, but where
there was lots of packet loss. This very problem is how I learned
about ~. to escape out of an ssh session, from practical necessity.

Maybe Mr. Google knows the answer ...

http://ask.metafilter.com/74630/packet-loss-wreaks-more-havoc-than-it-ought-to-on-ssh-sessions

--
Russell Senior, President
rus...@personaltelco.net

[Rick Lindahl]

Russell, et al, (pardon the length!)

Here's my take on the situation; taking into account radio protocols as
well as TCP/IP.

TCP/IP operates in a collision domain and has been designed to put
up with retransmissions nicely which means that most packets are handled
"nicely."

UDP and other non-acknowledged protocols and packets; Here is where
the latency and jitter (variable latency) becomes a big problem. A single
stream of voice/video can be buffered and this can clean up some of the
problems but when you have a bidirectional (live) stream (VoIP/Video
Conference) these delays and variables create packets out of order and drop
outs. This is further compounded by more latency and jitter.

Session persistence: Now things get interesting...different session
types and protocols have different tolerances for latency and jitter and
this is where SSH, VPN's and other persistent sessions become unreliable.
This is why satellite networks won't work for most VPN sessions.

NOW, take all of this information together with a very important other
problem:

RF and radio protocols

Most RF sessions also have their own ack (acknowledge)
packet which is "on top of" the TCP/IP packet structure. So...the radios are
also recombining packets, transmitting, requesting, acknowledging and
sending other information along with the TCP/IP packets. You've got packets
inside packets inside packets...

RF medium:

WLAN/Wifi... operates in unlicensed frequencies (mostly 2.4 & 5GHz)
and was designed and works pretty well in an indoor LAN type environment.
I've been able to get around 135mbps using 802.11n access points and
standard clients...but this is indoors. It was also designed for clients to
hear each other and this is an important point. Also, each access
point/wireless router has a limited amount of bandwidth which is SHARED by
all clients. As the bandwidth demands grow the latency and jitter
exponentially increases and there is no "device" within the Wifi/IEEE
protocols to change this.

WAN/WiMAX/3G/4G... mainly licensed RF medium with POLLING protocols
that handle the TIMING of packets very nicely and help to reduce latency and
jitter but NOT eliminate it. Because these are still point-to-multipoint
networks with limited backhaul capacity there is a degradation of throughput
as the demand grows for subscribers and bandwidth in any given coverage
area.

Now combine the issues above with each client having a different
receive signal strength (RSL/RSSI), modulation type for transmission,
transmit power and in the mobile world, hand-offs and roaming and you can
see that latency and jitter will be all but impossible to completely
control. What we need is more configurable timing variations in SSH, VPN and
other sessions. This would be one way to deal with poor session performance
in a highly variable mobile client world.

off soap box now...

Rick Lindahl
Invictus Networks, LLC
503-635-2562, F503-635-9207
www.invictusnetworks.com
www.invictuswireless.com

http://ask.metafilter.com/74630/packet-loss-wreaks-more-havoc-than-it-ought-
to-on-ssh-sessions

--
The Personal Telco Project - http://www.personaltelco.net/
Donate to PTP: http://www.personaltelco.net/donate
Archives: http://news.gmane.org/gmane.network.wireless.portland.general/

Etiquette: http://www.personaltelco.net/index.cgi/MailingListEtiquette
List information: http://lists.personaltelco.net
To post to this group, send email to ptp-g...@googlegroups.com
To unsubscribe from this group, send email to
ptp-general...@googlegroups.com

[Robert Hall]

> --
> The Personal Telco Project - http://www.personaltelco.net/
> Donate to PTP: http://www.personaltelco.net/donate
> Archives: http://news.gmane.org/gmane.network.wireless.portland.general/
> Etiquette: http://www.personaltelco.net/index.cgi/MailingListEtiquette
> List information: http://lists.personaltelco.net
> To post to this group, send email to ptp-g...@googlegroups.com
> To unsubscribe from this group, send email to
> ptp-general...@googlegroups.com

My understanding, from having read Andrew Tanenbaum's _Computer
Networks_, and refreshed via Wikipedia
(http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_over_wireless_networks)
is that since TCP was designed for wired protocols, some of the
optimization algorithms don't work well with wireless protocols. In
fact, some of the algorithms make things worse.

[Robert Hall]

Like, when packets are lost on a wired network, it's because of
congestion, and the best strategy is to back off. But on a wireless
network, it's (most likely) due to interference, and the best strategy
is to send more.

[Patrick J. Timlick]

One clue to your quality of service is to run

http://myvoipspeed.visualware.com/

For comparison, my Verizon nominal 10Mbs DSL just gave .3ms jitter, 0 packet loss to Vancouver BC.

Packet loss would be more critical to SSH than jitter IMHO.  

ifconfig gives packet loss counts too.  I see no packet loss in 10^6 packets.

-- Pat

--
The Personal Telco Project - http://www.personaltelco.net/
Donate to PTP: http://www.personaltelco.net/donate
Archives:  http://news.gmane.org/gmane.network.wireless.portland.general/
Etiquette: http://www.personaltelco.net/index.cgi/MailingListEtiquette
List information: http://lists.personaltelco.net
To post to this group, send email to ptp-g...@googlegroups.com
To unsubscribe from this group, send email to
ptp-general...@googlegroups.com

--
p.j.t...@ieee.org
www.timlick.com
503-476-3119
10990 NE Paren Springs Rd.
Dundee OR 97115

[Jim Blandy]

On Mon, Mar 8, 2010 at 11:43 AM, Christopher Chen <muff...@gmail.com> wrote:
> Again, sorry for accusing you of being a mean person.

Oh, no offense taken. I've bought myself a copy of Not Being Mean For
Dummies, so I can do it better next time. :)

[Jim Blandy]

On Mon, Mar 8, 2010 at 11:57 AM, Robert Hall <robtheha...@gmail.com> wrote:
> Like, when packets are lost on a wired network, it's because of
> congestion, and the best strategy is to back off. But on a wireless
> network, it's (most likely) due to interference, and the best strategy
> is to send more.

Of course, my actual SSH connection crosses both wireless and wired
networks, so lost packets could be due to either congestion or
interference.

[Christopher Chen]

OR EVIL.