windowing seemed to work the best for me; it acts like a value, or japanese garden water wheel...when both sides are in perfect sync its fast; but its also reliable;
in this situation when, where you're running your own network; like me also...see www.tamago.us I LOVE TO SPAM BABY :) routing is probably a big deal; and the speed in between...also the traffic on the internet will play havoc also...
this is probably why you asked "David" about finding the shortest/fastest path between two nodes; before.
Serguei Osokine <[EMAIL PROTECTED]> wrote:
On Monday, October 23, 2006 David Barrett wrote:
> I'm only looking for near-parity with mainstream TCP implementations,
> so anything truly experimental is probably beyond my needs.
Speaking of mainstream vs experimental - there was this small
startup company called Orbital Data that was recently acquired by
Citrix, so I'm not sure whether you'd call it experimental or not
by now. Anyway, its business is to make appliances that sit between
your LAN and Internet and optimize the bulk TCP transfers between
your LAN and the LAN of your branch office on the other coast or on
another continent, provided that this branch office has the same
appliance. These appliances are sold under Citrix brand now.
To achieve that, they are doing some pretty extensive TCP
changes, giving these appliances total control over TCP stream -
ACKs, window size, and such - and they claim some very serious
throughput improvements for bulk transfers: this article describes
a factor of 16 file transfer speed improvement over the overseas
link:
http://www.digitalmediadesigner.com/articles/viewarticle.jsp?id=26213-1
They also have a software version of the same. So if I were
you, I'd go to the patent application database at uspto.gov/patft
and have a look at what these guys are doing. (Even being me, I did
the same, but I was not particularly interested in the details.)
Sounds like these folks have roughly the same TCP goals as you
do, so maybe their solutions will be good for you, too. Maybe you can
even just license their stack and save yourself a lot of effort
(though that was probably much simpler to do before the Citrix
acqusition for purely logistical reasons).
Best wishes -
S.Osokine.
23 Oct 2006.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of David Barrett
Sent: Monday, October 23, 2006 10:58 AM
To: 'theory and practice of decentralized computer networks'
Subject: RE: [p2p-hackers] TCP over UDP "magic number" questions
Nice graph. So based on all of this, does anyone on this list actually
recommend implementing Mills, or is it still an open research question? I'm
only looking for near-parity with mainstream TCP implementations, so
anything truly experimental is probably beyond my needs.
-david
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:p2p-hackers-
> [EMAIL PROTECTED] On Behalf Of Serguei Osokine
> Sent: Monday, October 23, 2006 10:42 AM
> To: theory and practice of decentralized computer networks
> Subject: RE: [p2p-hackers] TCP over UDP "magic number" questions
>
> On Monday, October 23, 2006 David Barrett wrote:
> > I like Mill's nonlinear filter, but I'll need to do more research
> > on it.
>
> Right. Keep in mind that Mills filter, among other things, also
> tends to increase the average estimate; to illustrate that, attached
> is the sample run of normal RTT estimate and Mills' estimate with the
> values he used in RFC 889: "After a number of trials I concluded that
> values of F1 = 15/16 and F2 = 3/4 (with G = 2) gave the best all-
> around performance." (this "F" is the "a" value in the chart title)
>
> The chart shows the averaging results of both filters for a
> random RTT in the range 0-10 with a uniform distribution. This is,
> of course, a simplification, but it does show the expected effect
> - Mills' estimate is consistently higher than the "normal" one with
> the same base alpha (or F1, in RFC 889 terms) value.
>
> Even more interesting are the plots of estimate*G (with G=2,
> as in RFC 889), that are plotted on the same chart. As you can see,
> several RTT samples exceed this value for a "normal" 15/16 estimate,
> which basically means that TCP would have about five retransmissions
> on that interval (if it would really encounter such a nutty RTT
> variation, of course). Mills' estimate, on the contrary, exceeds
> all the RTT values in the sequence, so no retransmissions would be
> necessary.
>
> However, this appears to be simply the result of the higher
> estimate value provided by Mills - the nonlinear filtering as such
> does not seem to have any special influence on this result. As a
> matter of fact, simply increasing G (retransmission factor threshold)
> would have pretty much the same effect. It is nteresting that Mills
> himself did not found the increase of G to have any positive effect
> for his data samples; I'm not entirely sure why this would be the
> case. Maybe that was because real-life RTTs are not really random
> (much less have a uniform distribution), as in the attached chart,
> but are correlated (large RTTs tend to be followed by the large
> RTTs), and non-linear filtering would really have some benefits
> independent of the increased retransmission threshold.
>
> So I'm providing this chart not to say that Mills' filtering
> does not have any positive effects aside from the simple RTT estimate
> increase, but rather just to give a simple visual example of what is
> happening when Mills' filter is used.
>
> Best wishes -
> S.Osokine.
> 23 Oct 2006.
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David Barrett
> Sent: Monday, October 23, 2006 12:58 AM
> To: 'theory and practice of decentralized computer networks'
> Subject: RE: [p2p-hackers] TCP over UDP "magic number" questions
>
>
> Wow, 4614 is a godsend. 2988 is also particularly useful. Ok, so I think
> I'll start with a basic NewReno implementation with Karn's algorithm for
> RTT
> measurement (with fixed x2 backoff) and Van Jacobon's technique of SRTT
> calculation. I like Mill's nonlinear filter, but I'll need to do more
> research on it. Nagle is out. Hopefully this'll get me a good start and
> I
> can get crazy after that. Thanks for all your help!
>
> -david
>
>
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Spencer Dawkins
> Sent: Saturday, October 21, 2006 5:24 PM
> To: theory and practice of decentralized computer networks
> Subject: Re: [p2p-hackers] TCP over UDP "magic number" questions
>
> If you're trying to figure out what TCP is really, you might also look at
> http://www.ietf.org/rfc/rfc4614.txt, which is the IETF's best shot at
> hacking
> through the 100 or so RFCs that talk about TCP.
>
> I note that RFC 889 doesn't seem to be listed. I think you can ignore it
> (unless the functionality got picked up in RFC 1122, which tried to
> capture
> the working lore several years after TCP was redesigned for congestion
> avoidance, etc.).
>
> And it's also worth mentioning that TCP will WORK, for some value of
> "work",
> with a lot of simplifying assumptions. I'm not sure Nagle matters for
> anything except Telnet/FTP control channel-style communication, and you
> may
> not even know anyone who uses these protocols anymore - they are *so*
> last-century :-). There just aren't that many protocols that rely on
> server-end echos any more, and that's the problem Nagle was solving.
>
> Thanks,
>
> Spencer
> ----- Original Message -----
> From: Michael Parker
> To: theory and practice of decentralized computer networks
> Sent: Saturday, October 21, 2006 6:16 PM
> Subject: Re: [p2p-hackers] TCP over UDP "magic number" questions
>
> I think Mill's nonlinear filter was a proposed modification to TCP as
> described in RFC 889 that never made it. I suspect Van Jacobson's simple
> linear filter won out either because it was easy to implement or it
> produced
> better results in trials. (But it could be worth grepping for Mills in the
> Linux source code just to make sure.) Don't forget, none of these papers
> are
> very current -- both Nagle's and Van Jacobson's papers appeared in the
> 1987
> proceedings of SIGCOMM. So if you don't see it in the latest RFCs (e.g.,
> 2581), it probably didn't stand up to the test of time.
>
> As for Karn's algorithm, I think some BSD flavors go through empirically
> determined backoffs. I'm pretty sure the book TCP/IP Illustrated Volume 2
> spells them out (indeed, all of the TCP/IP implementation) in their gory
> details. But just to get it running, I don't think doubling is a bad
> solution
> at all, as unless your connection is really hosed you won't be stepping
> through that many backoffs anyway.
>
> In a file transfer scenario, you can probably do without Nagle's
> algorithm.
> It's more useful in an interactive environment like a terminal, where it
> drastically increases the ratio of payload to header bytes. (Although some
> programs, to appear more responsive when echoing from a server, will turn
> it
> off through the TCP_NODELAY socket option.)
>
> - Mike
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
You don't get no juice unless you squeeze
Lemon Obrien, the Third.
http://www.tamago.us
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
