The very good introduction can be found here:
http://en.wikipedia.org/wiki/Leaky_bucket
http://en.wikipedia.org/wiki/Token_bucket
This is very important to note, that traffic shaper has a fixed size
queue and limited output rate. If packet cannot be forwarded
immediately, it will be added to the queue. Only when queue size reaches
its limit, router begins to drop the packets.
This approach has two consequences, important for the flow control
algorithms:
1) While traffic is lower that router allows, the queue is empty and
propagation time may be very low
2) When traffic reaches the limit, the queue begins to grow, and
latency may increase dramatically.
So you can't assume that you have a constant latency.
David Barrett wrote:
> 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
