Screamer - TCP RST

wow4life said:
Agreed - I have given up accessing work applications from home and drive into the office instead (even when it means going there late in the evening if I need to collaborate with colleagues in the US).
Click to expand...

I know EXACTLY how you feel.

My work requires me to remote onto client machines based around the world.
When I lose the connection, I find it somehow difficult to explain to my client that it's not my fault (after all, they pay me for a service, not an excuse).

"We had a major hit on our Helderkruin tower and the techies are working on it as we speak and should have it replaced by tomorrow morning."

That's not exactly a comfort-enducing reply. When did it go down?
I still don't have any answers.

wow4life and I are paying customers. We expect service.
I just hope your announcement on Monday is something truly groundbreaking amazing.
 
wow4life said:
It was considerably better last night - would like to know what changes were made though
Click to expand...

Hi W

There is soooo much going on at the moment that it could have been one of hundreds of things but I have informed the engineers about the items affecting some of our gamers and they are also getting to them.

Please let me know if you get any futher resets.

Thanks
 
cda said:
http://en.wikipedia.org/wiki/Change_Management_(ITSM)

Time to implement some?
Click to expand...

LOL.....
Maybe my response was somewhat limited. What I meant was that WOWforlifes disconnects are mysterious and there is a lot of work going on at Screamer which might or might not have affected his/her random disconnects.

Change management is somewhat of a swearword with our techies because they are forced to comply with it and they feel it cramps their creative styles:erm:

Our monitoring of his/her connection shows that our network is very stable as is evidenced by the superior upload and download speeds and pings. The disconnects are happening somewhere upstream near WOW's servers.

Our bulk broadband engineers are trying to identify his/her disconnects
 
howzit said:
LOL.....
Maybe my response was somewhat limited. What I meant was that WOWforlifes disconnects are mysterious and there is a lot of work going on at Screamer which might or might not have affected his/her random disconnects.

Change management is somewhat of a swearword with our techies because they are forced to comply with it and they feel it cramps their creative styles:erm:

Our monitoring of his/her connection shows that our network is very stable as is evidenced by the superior upload and download speeds and pings. The disconnects are happening somewhere upstream near WOW's servers.

Our bulk broadband engineers are trying to identify his/her disconnects
Click to expand...

This isn't entirely true.

I disconnect from several other applications as well including:
* Ventrillo
* Virtual Worlds
* Second Life
* LotusLive
* Skype
 
howzit said:
LOL.....
Maybe my response was somewhat limited. What I meant was that WOWforlifes disconnects are mysterious and there is a lot of work going on at Screamer which might or might not have affected his/her random disconnects.

Change management is somewhat of a swearword with our techies because they are forced to comply with it and they feel it cramps their creative styles:erm:

Our monitoring of his/her connection shows that our network is very stable as is evidenced by the superior upload and download speeds and pings. The disconnects are happening somewhere upstream near WOW's servers.

Our bulk broadband engineers are trying to identify his/her disconnects
Click to expand...

In an alternate reality - yes.

Since Screamer uses Neotel, Seacom and Satan.. Why not switch Myself and wow4life onto SAIX?

Could elaborate on the "somewhere upstream near WOW's servers"?

Surly that has nothing to do with Remote Desktop?

Please Howzit, I am almost close to begging on my knees. The last step would be sexual favours, though neither yourself , nor I would want that.
:(
 
Thanks for the clarification. I will get onto this now.
 
iDenTiTy said:
Please Howzit, I am almost close to begging on my knees. The last step would be sexual favours, though neither yourself , nor I would want that.
:(
Click to expand...

That's one hellavu threat :D

I have given up accessing work applications from home. My online gaming days are largely over as I can't do arenas and the only person happy about all of this is my wife ....
 
I have spent some more time understanding this issue.

First, lets start with a definition:
According to RFC 793, which specifies an Option in the Flags portion of the TCP header called Reset (or RST). The Reset bit is designed to allow a station to abort the TCP connection with another station. This can happen for a number of reasons.

If a station involved in a TCP session notices that it is not receiving acknowledgements for anything it sends, the connection is now unsynchronized, and the station should send a reset. This is a half-open connection where only one side is involved in the TCP session. This cannot work by definition of the protocol.

Now I noticed that all my resets (TCP RST flag set) are followed by a retransmission of a packet (3x in fact). This is considered normal TCP behaviour but my clients don't like it as they consider that connection half-open and thus disconnect.

Here is my current hypothesis:
(1) "Something" is causing data being sent from the server to be lost. I can't prove this as I monitor from my client and obviously only see what data hits my machine.

(2) The server tries several times (I don't see it as I monitor from my client) to resend this information.
(2.1) If my client receives the retransmission then all continues happily else (2.2)
(2.2) The server sends a reset and then retries to send the lost data.

(3) My client receives the TCP RST.
(3.1) If my client receives the retransmission soon enough after the RST then all continues fine. (I have cases where this happens i.e. RST received then retransmitted data and all continues) or
(3.2) If my client receives the retransmitted data too late after the RST then it closes the connection (In most cases the client closes the connection as the retransmissions are received too late).

(4) Conclusion - Lost packets are bad for online, interactive, applications.
 
So I am being bumped - always thought that it was a contention issue of some sort as my experience late at night is considerably better than during the day.
 
wow4life said:
So I am being bumped - always thought that it was a contention issue of some sort as my experience late at night is considerably better than during the day.
Click to expand...

Isn't the 802.16e standard (Wimax) supposed to work around the contention issue?

If a station is too 'busy' isn't it supposed to switch you around to a better one?
 
iDenTiTy said:
Isn't the 802.16e standard (Wimax) supposed to work around the contention issue?

If a station is too 'busy' isn't it supposed to switch you around to a better one?
Click to expand...

has nothing to do with the wimax side of things, it's their provider edge between them and the upstream.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X