Wireshark · Ethereal-dev: RE: [Ethereal-dev] TCP/IP Retransmission

[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

I don't want to add to the polemic, but I can add a note of what I've
personally seen in practice :)

The RST trick will do a "fine" job in most of the "well-behaved" networks...
where the TCP (client) protocol stack implements the state transition from
all states (different from SYN-RECEIVED) when receiving a RST.

>From the moment that you get network (or CPU) congestion, or multiple
routes, or you're talking about wireless links, you *cannot* guarantee the
in-sequence delivery of messages. As a result, if the server sends an ACK
segment and after some time a RST segment, the possibility that the RST
arrives to the client *before* the ACK has to be considered.

A) Packet swapping often occurs in temporary congestion scenarios where the
operation mode of some network equipment partly switches from queue (FIFO)
mode to stack (LIFO) mode.

B) Packet swapping is also very common in situations where connection load
balancing/distribution occurs as you *cannot* ensure that both routes will
have the same delay.

C) Last but not least, and this is really nasty, some web switches simply
drop out-of-order packets when running in specific operation modes, so the
end device will never receive the RST segment and it may be willing to
continue to use the connection that is still available to his knowledge.

These problems are really hard to track down. Of course, nobody forbids us
to be creative, but when the problems *are* known you may want to evaluate
the introduced risk. If you want to take this risk, you have to live with
the implied consequences. And if you're bound to a SLA in which performance
is described, you'll have serious problems in fixing the errors introduced
by the unexpected packet swapping as you'll have a decreased performance,
but that's leading us far from home :)

The funny thing is that people still try "optimizing" a protocol which is
already about a quarter of a century old, and it still surprises me that
there has not been a single major successful attempt at replacing TCP with a
more "efficient" reliable streaming protocol :)

Finally, I *personally* don't believe in a one-size-fits-all protocol that
is the best protocol in all situations. But I *personally* believe that a
well-designed protocol is an authoritative reference. Again, this paragraph
is my *personal* opinion and you may take it for what it's worth.

Best regards,

Olivier

|-----Original Message-----
|From: Scott Emberley
|
|Think about what's really happening.  The RST is after the client acks
|(if you actually took the time to look). I can serve 20% more 
|clients in
|the same time period (since we are talking about WEB servers).  Open
|your eyes and look at what's happening and its benefits rather that
|pissing about the fact that some piece of code was not written robustly
|enough to handle a procedure that is defined by the specification.
|
|Note: Those nice guys who put the pretty butterfly on your web 
|page were
|the first guys to use this process and others followed.
|
|Note: "Wrong" and "Stupid" is an attitude problem for software
|developers.  Creative, open minded and flexible attitudes would be more
|helpful and productive.
|
|-----Original Message-----
|From: ethereal-dev-bounces@xxxxxxxxxxxx
|[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Pia Sahlberg
|Sent: Friday, March 26, 2004 3:25 AM
|To: ethereal-dev@xxxxxxxxxxxx
|Subject: RE: [Ethereal-dev] TCP/IP Retransmission
|
|>"wrong" and "stupid" are funny terms for open source 
|developers to use 
|>when talking about someones efforts to improve performance 
|(even if you
|
|>do not agree with the procedures)...
|
|lets clarify with an example:
|It is wrong and stupid since it removes one of the nice features of TCP
|: 
|reliability.
|
|Without thinking an implementoir might think  lets just RST the session
|after i sent out the last segment to the other and performance will be
|better than doing it the real way with FIN.
|
|So he writes code that generates packets like :
|Server->Client   TCP last segment of the data pdu
|Server->Client   TCP RST
|
|Now,   will the server ever know if teh data was received reliably or
|not?
|Will it even work?
|Think packet reordering. When the RST arrives to the client before the
|data segment so the client kills the session before it has 
|even received
|the data it was waiting for. 
|Bad.
|This can not happen if you close the session using FIN.
|
|
|So essentially that implementation is now using unreliable tcp and no
|one 
|can figure out why there are sometimes "issues" causing the client to 
|reissue the commands across a new session.
|Worse, Server does not even know whether the client received 
|the data or
|
|not.
|whats the point in using TCP if not to know whether the data arrived
|safely 
|to the other end or not.
|
|_________________________________________________________________
|What's your house worth? Click here to find out:  
|http://www.ninemsn.realestate.com.au
|
|_______________________________________________
|Ethereal-dev mailing list
|Ethereal-dev@xxxxxxxxxxxx
|http://www.ethereal.com/mailman/listinfo/ethereal-dev
|
|____________________________
|This email has been scanned.
|
|_______________________________________________
|Ethereal-dev mailing list
|Ethereal-dev@xxxxxxxxxxxx
|http://www.ethereal.com/mailman/listinfo/ethereal-dev
|