[p2p-hackers] Hard question....

Daniel Stutzbach agthorr at cs.uoregon.edu
Sun Apr 2 05:07:51 UTC 2006


Saturation is the goal.  Wasted bandwidth is bad.

Super-saturation, where you application is blasting everything else
into oblivion, is what you need to avoid (and you should specifically
test how your app competes with TCP).

In practice you typically oscillate around the saturation point,
sometimes leaving a little bandwidth unused, sometimes
super-saturating and causing packets to queue (increasing RTT and
eventually packet loss).  You can't really avoid this because the
saturation point moves depending on what other applications are doing.

On Sat, Apr 01, 2006 at 06:28:25PM -0800, David Barrett wrote:
> That makes sense, but it's a bit of a catch-22:
> 
> In order to not saturate the connection you need to know what's available.
> But to know what's available, you need to saturate the connection.
> 
> I'm curious if there's another way.
> 
> -david
> 
> > From: gbildson at limepeer.com [mailto:gbildson at limepeer.com]
> > Sent: Saturday, April 01, 2006 6:14 PM
> > To: Peer-to-peer development.; David Barrett
> > Cc: 'Peer-to-peer development.'
> > Subject: RE: [p2p-hackers] Hard question....
> > 
> > I've missed part of this conversation but here is my two cents on this
> > specific
> > question -  just keep increasing the amount of data that you are sending
> > in
> > bursts and the speed of those bursts until you achieve a certain target
> > error
> > rate.  i.e. 2% or whatever.  After bumping up against failures, you should
> > be
> > able to get a sense of an optimal rate.  Be sensitive to TCP congestion at
> > the
> > same time.  I back off if the round trip time starts spiking.
> > 
> > Thanks
> > -greg
> > 
> > 
> > Quoting David Barrett <dbarrett at quinthar.com>:
> > > > From: coderman
> > > > Sent: Saturday, April 01, 2006 5:20 PM
> > > > To: Peer-to-peer development.
> > > > Subject: Re: [p2p-hackers] Hard question....
> > > >
> > > > On 4/1/06, David Barrett <dbarrett at quinthar.com> wrote:
> > > > > ...
> > > > > Incidentally, how are you measuring "available bandwidth"?
> > > >
> > > > right now i pass the buck and let the user pick a suitable limit.  if
> > > > excessive loss is detected continuously the stack can cut by half or
> > > > exit with error.
> > > >
> > > > i'm still looking for better ways to do this; ideally it would be tied
> > > > to kernel level shaping and based on a historical view of channel
> > > > capacity.
> > >
> > > Got it.  Has anyone else had good experience trying to measure this
> > > automatically in the real world?
> > >
> > > -david
> > >
> > >
> > > _______________________________________________
> > > p2p-hackers mailing list
> > > p2p-hackers at zgp.org
> > > http://zgp.org/mailman/listinfo/p2p-hackers
> > > _______________________________________________
> > > Here is a web page listing P2P Conferences:
> > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> > >
> > 
> 
> 
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
> 

-- 
Daniel Stutzbach                           Computer Science Ph.D Student
http://www.barsoom.org/~agthorr                     University of Oregon



More information about the P2p-hackers mailing list