Ethereal-users: [Ethereal-users] Re:[Q-waaaayOT] Size of a trace and hub functions

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date: Fri, 9 Feb 2001 21:52:26 -0600
On 9 Feb 2001, at 13:53, Guy Harris wrote:

> > Actually my theory is that I have a "big pipe/small pipe" (Ethernet 
> > 100 Mbps --> 56 frame relay --> Ethernet 100 Mbps) type of 
> > environment/problem, and I think I am loosing (discarded) frames, 
> 
> ...and they're not getting retransmitted by TCP?  (See "end-to-end
> argument". :-))

	TCP "bullet-proof" reatransmission :-) ... you have to be kidding 
NOTE: see also some of the comments from Barry Margolin on the 
TCP/IP newsgroups in regards to his theory about even possible 
patterns of data resetting CSU/DSUs on their passage through 
frame circuits, making unusable any "retransmision" (as the data 
will always stay the same), unless changing the data pattern 
altogether (proven once on one of my circuits, when only changing 
some of the files made them transmittable). 
	In the specific case I am talking about now it looks like a too 
long "train" of not-yet ack-ed packets (because of big receiving 
window size) let to the dissapearance of one packet in the middle, 
never caught at the other end, thus never ack-ing the whole "train" 
... no retransmission being able to repair ... and FTP servers 
closing "cleanly" because of that. But I would like to have ethereal 
capture this ...
	I have - so far - decreased the receiving window size (obvious attempt), 
and I have reduced the number of failures, but I fear to go below 8K, as 
the delay caused by ack-ing more often than that is totally unacceptable 
(even with this window size, from the original 32K, I hear complaints about 
the additional delay). I have yet to see the TCP retransmission being of 
any help in such cases ... :-(

> Perhaps the FTP servers and clients you're using both suck, so that they
> won't report a "connection timed out" error (or perhaps the OS on one
> side or the other sucks and doesn't provide a "connection timed out"
> indication on reads or writes)
<snip>

I will have to admit that this might be the case ... but I am "stuck" 
with both ends - one being an OS/390 TCP/IP implementation (the 
"client" for FTP), and the other a Netware 5.x (latest) for the stack 
servicing either the Novell FTP server, or the Murkworks one (which 
makes me believe that FTP sever implementation itself has nothing 
to do wtih the problem - the more so that the Murkworks one is 
probably the best by-the-book/RFC FTP design I have seen).

Re-reading the above I think I went beyond any acceptable level for 
the ethereal list ... I am just hoping that these comments might 
raise somebody's awareness and/or knowldge ... thanks again for 
the extraordinary patience some of you had - so far - in listening to 
my "wining" and trying to help me ... if anybody thinks that the 
problem itself can be further discussed, I will dare to take this "off-
line", as it might not have anything to do with ethereal (if I find other 
means of capturing my data).

Thx again (especially to Guy Harris and Diana Eichert),
Stef