This looks really impressive! However, the subversion browser appears
busted (is throwing a Python exception). I've checked out the code and it
looks really clean. A few questions about the congestion-control code:
1) I see you have a few different modules: TCP, VEGAS, DELAY, and
AGGRESSIVE. What's DELAY and AGGRESSIVE?
2) In TCP/VEGAS/DELAY mode, on a loss it seems to fall back as follows:
ssthresh = max( cwnd/2, CWND_MIN )
But spec (RFC2581, eq.3) recommends:
ssthresh = max( FlightSize/2, 2*SMSS )
I'm curious if it's intentional to fall back to half of cwnd versus half of
the in-flight count, or if this is a bug? If it's intentional, what is the
resulting effect?
3) I note you accept any subsequent sequence number for the RTO calculation,
rather than requiring the exact packet. Very clever; is this more stable in
a high-loss scenario?
4) What's all that power-computation business in the DELAY
congestion-control mode? Is this basically using changes in throughput to
trigger backoff rather than packet loss? Is this Fast TCP?
In your experience, which of the congestion modes gives the best results,
and under what scenarios? Have you done much testing on this?
-david
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:p2p-hackers-
> [EMAIL PROTECTED] On Behalf Of Bryan Ford
> Sent: Thursday, July 12, 2007 5:20 AM
> To: theory and practice of decentralized computer networks
> Subject: [p2p-hackers] Structured Stream Transport
>
> [Partly in response to David's note on UDT...]
>
> For anyone needing an application-linkable transport protocol library
> that implements congestion control, reliability, security, NAT
> traversal, and other cool features - and who isn't afraid of unstable
> bleeding-edge code - there's an early user-space prototype
> implementation of my "Structured Stream Transport" (SST) available here:
>
> http://pdos.csail.mit.edu/uia/sst/
>
> The SST protocol itself provides an enhanced transport abstraction
> that subsumes traditional streams and datagrams, and is described in
> more detail in a paper to appear in this year's SIGCOMM:
>
> Structured Streams: a New Transport Abstraction
> http://www.brynosaurus.com/pub/net/sst-abs.html
>
> I haven't widely announced the protocol or library "in the wild" yet
> because the code isn't quite ready for production use and the
> protocol spec is not yet complete or fully consistent with either the
> code or the SIGCOMM paper. So consider yourself warned. :) I'm
> hoping to fix most of the remaining barriers to real use within the
> next couple months. One immediate challenge for potential users of
> the code is that it relies on the Qt 4 toolkit - only the QtCore and
> QtNet libraries; note that it _doesn't_ need the monstrous ~7MB QtGui
> library - but any dependency on Qt means integrating the Qt event
> loop with whatever event loop your application uses (at least under
> Unix or Mac). This is obviously trivial if your application happens
> to be Qt-based but takes a bit of work (probably not too much)
> otherwise. I'm willing to help anyone seriously interested in using
> SST in a real application to smooth over these technical issues.
>
> Cheers,
> Bryan
>
>
> _______________________________________________
> 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
