TB w/o burst support is very simple to implement and it works well for simulation purposes.
 
Alex


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barrett
Sent: Friday, October 27, 2006 1:18 PM
To: 'theory and practice of decentralized computer networks'
Subject: RE: [p2p-hackers] Re: UDP Behavior in the Real World

Ah, perfect, thanks for the link. 

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Florent THIERY
Sent: Friday, October 27, 2006 12:56 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] Re: UDP Behavior in the Real World

 

Depends on congestion mitigation technique chosen. Typical mecanisms are RED (random realy drop) http://en.wikipedia.org/wiki/Random_early_detection. Probability to drop the incoming packet is increasing with the occupation of the queue.

You have RIO too, which does that on both interfaces, Fair queuing mecanisms...

But it's really the choice of the ISP.

2006/10/27, David Barrett < [EMAIL PROTECTED]>:

Incidentally, can you summarize how routers choose which packets to forward
and which to drop?  I ask because while testing my congestion control
module, I've made a little fake internet simulator, and I realize I have no
idea how routers do it.

My current approach is to define a link by "latency" and "maximum pipe
size", which implicitly limits the connection to:

        Bandwidth = # packets in flight allowed / latency

This seems to work well and is much simpler than trying to calculate and
enforce bandwidth caps directly, as I simply reject any incoming packet that
exceeds the link's maximum pipe size.  However, I'm curious if this is how
it's actually done in the real world.  Do routers maintain an actual packet
queue for each flow they manage (enqueuing on one side and dequeuing on the
other), and simply fill and empty the queue as fast as possible?

-david

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:p2p-hackers-
> [EMAIL PROTECTED]] On Behalf Of Alexander Pevzner
> Sent: Friday, October 27, 2006 10:08 AM
> To: [email protected]
> Subject: [p2p-hackers] Re: UDP Behavior in the Real World
>
> There is yet another case when reordering may happen. If there is a
> traffic shaper in the path, and it calculates traffic in a term of
> bytes, not packets, it may periodically pass short packets before the
> long packets.
>
> So if packets have different size, the reordering probability grows. In
> my experiments I observed few reordering occurrences per every few
> hundred packets - often enough to be noticeable.
>
> Alex Pankratov wrote:
> > Regarding (1) - reordering does happen.
> >
> > First of all it happens in L2 load-balanced scenarios, ie when the
> traffic
> > goes through virtualized servers or server clusters. It also happens
> when
> > the traffic goes through multi-CPU routers and finally It happens
> (though
> > less frequently) due to route flips.
> >
> > There is an anecdotal evidence that reordering also happens more
> > frequently over Gigabit links, but I suspect that this is hardware
> specific
> > and it has something to do with NIC drivers flipping between interrupt
> and
> > poll-based modes.
> >
> > Alex
> >
> > ------------------------------------------------------------------------
> > *From:* [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] ] *On Behalf Of *David
> Barrett
> > *Sent:* Friday, October 20, 2006 4:14 PM
> > *To:* 'theory and practice of decentralized computer networks'
> > *Subject:* [p2p-hackers] UDP Behavior in the Real World
> >
> >     So I'm working on a TCP over UDP layer and I'm wondering about the
> >     following; what have you seen?
> >
> >
> >
> >     1)       _How often does out-of-order packet delivery happen in the
> >     real world?_  My reading and experience indicates it's actually very
> >     rare, but I'm curious if you concur.
> >
> >     2)       _How often does duplicate packet delivery happen in the
> >     real world?_  Again, I'm of the impression it's even more rare than
> >     out-of-order, but I'd like your thoughts.
> >
> >     Clearly, these happen and need to be accounted for.  But I'm curious
> >     to what degree they happen, as this affects performance
> >     characteristics of the implementation.
> >
> >
> >
> >     -david
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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

_______________________________________________
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

Reply via email to