NODE c4a78db9Server congestion
Christian Wettergren <cwe@Csli.Stanford.EDU>Sun, 27 Aug 95 17:42:04 PDT
I talked about acks of acks in a previous message, and I guess is was
somewhat vague there.
What happened, according to my uninformed view, during the SSL2
challenge was that the server got congested, and had problems with
both answering to key allocation requests and ack replies. I guess
that the load of the machine was so high that it lost packets in the
input queues.
Client -----> UDP/Key allocation req ---->
Client -----> UDP/Key allocation req ---->
Client -----> UDP/Key allocation req ----> Server ---+
| alloc
Client <------- UDP/allocation reply ----------------+
|
| working...
|
Client ------- UDP/ack ------------------> ??
One problem was that the client believed that the ACK had arrived
at the server if it had sent it off, not counting with the possibility
of the ACK being lost on the way.
I instead propose that the Server sends a acknowledgement
back to the client once it has received an ACK from a client.
| working...
|
Client ------- UDP/ack ------------------> Server -+
|
Client <------ UDP/Server-ack ------------ Server -+
And then the client knows the server actually received the ACK
and has incorporated it into its table.
The client has to handle the case that either the Ack or the
Server-ack is lost. I propose it doesn't retransmit immediately,
but rather waits until next time it has to ack something, and
piggybacks the old ack onto the new one.
Client -----> UDP/Key allocation req ---->
Client -----> UDP/Key allocation req ---->
Client -----> UDP/Key allocation req ----> Server ---+
| alloc
Client <------- UDP/allocation reply ----------------+
|
| working...
|
Client ------- UDP/ack1 ------------------> ??
|
"oops, oh well, lets try later."
|
Client -----> UDP/Key allocation req ----> Server ---+
| alloc
Client <------- UDP/allocation reply ----------------+
|
| working...
|
Client ------- UDP/ack2/ack1 ------------> Server -+
|
Client <------ UDP/Server-ack {1,2} ------ Server -+
|
There are countermeasures if either part doesn't get messages for some
reason.
If the server doesn't see the ACK for a block, it might give that
block out to someone else.
If the client is unable to retrieve a block from the server, I suggest
it just picks a random block and starts working on it. I may very
well not be allocated to someone else, and then the client was able
to do something good in the meantime even though it didn't get a
proper key alloc.
/Christian
NODE 45f7c292Re: Server congestion
Piete Brooks <Piete.Brooks@cl.cam.ac.uk>Mon, 28 Aug 95 02:40:29 PDT
> I talked about acks of acks in a previous message, and I guess is was
> somewhat vague there.
... and maybe based on a false premis ?
> What happened, according to my uninformed view, during the SSL2
> challenge was that the server got congested, and had problems with
> both answering to key allocation requests and ack replies.
Correct.
> I guess that the load of the machine was so high that it lost packets in the
> input queues.
NO.
The load was very *LOW*.
The problem was that the single threaded server was spending most of its time
talking to clients which failed to complete their interactions, and timed out.
The earlier client "ACK" code didn't hang around long enough, and gave up.
Later code kept trying ....
> Client -----> UDP/Key allocation req ---->
Nope -- basic fault here !! TCP not UDP !!
> One problem was that the client believed that the ACK had arrived
> at the server if it had sent it off, not counting with the possibility
> of the ACK being lost on the way.
Not the case.
It uses a reliable bytestream, and the client does not consider a keyspace
ACKed until it get back the "OK" response from the server.
This makes it "at least once", but that isn't a problem.
> I instead propose that the Server sends a acknowledgement
> back to the client once it has received an ACK from a client.
It does, in the reliable bytestream ...
> The client has to handle the case that either the Ack or the
> Server-ack is lost.
As above -- "at least once" -- it just retries.
> I propose it doesn't retransmit immediately,
> but rather waits until next time it has to ack something, and
> piggybacks the old ack onto the new one.
brclient waits a bit and tries again, before asking for the next.
> If the client is unable to retrieve a block from the server, I suggest
> it just picks a random block and starts working on it. I may very
> well not be allocated to someone else, and then the client was able
> to do something good in the meantime even though it didn't get a
> proper key alloc.
Nah.
NODE 54ef7a6cRe: Server congestion
Christian Wettergren <cwe@Csli.Stanford.EDU>Mon, 28 Aug 95 09:46:47 PDT
| > I talked about acks of acks in a previous message, and I guess is was
| > somewhat vague there.
|
| ... and maybe based on a false premis ?
|
| > What happened, according to my uninformed view, during the SSL2
| > challenge was that the server got congested, and had problems with
| > both answering to key allocation requests and ack replies.
|
| Correct.
|
| > I guess that the load of the machine was so high that it lost packets in
the
| > input queues.
|
| NO.
|
| The load was very *LOW*.
| The problem was that the single threaded server was spending most of its ti
me
| talking to clients which failed to complete their interactions, and timed o
ut.
| The earlier client "ACK" code didn't hang around long enough, and gave up.
| Later code kept trying ....
|
| > Client -----> UDP/Key allocation req ---->
|
| Nope -- basic fault here !! TCP not UDP !!
Ok, I'll be quiet now. It's funny when you think you know
what is happening based on an uninformed view, and simply
shuts out all the other pieces of info that gets to you.
By the way, thanks a lot Piete for the effort you put in!
You did excellent, and it was real fun! 32 hours with
serious performance problems is simply amazing.
/Christian