[e2e] Re: Bursty traffic and TCP flows (was: TOEs and related issues)

Marko Zec zec at tel.fer.hr
Wed Mar 10 12:40:03 PST 2004


On Wednesday 10 March 2004 19:24, RJ Atkinson wrote:
> On Mar 09, 2004, at 11:50, Marko Zec wrote:
> > All of the
> > IBM's IP routers at that time were built in such a silly way that
> > their buffers were measured / limited in terms of number of
> > packets.
>
> Ah, so one product has a particular design strategy, therefore
> all products of that type must use that same design strategy.  Whew.
> Thanks for enlightening me.  I erroneously thought that different
> folks might make different design choices (good, bad, or sideways).


You asked for concrete examples, and I only provided one I was 100% sure 
of. What's wrong with that?


> > Furthermore, I guess
> > most of the today's Cisco routers are also suffering from the
> > similar silly (mis)design problem...
>
> It would be interesting to hear from someone with first-hand
> knowledge of what cisco's design(s) look(s) like today, so we could
> work with data rather than with speculation.


I can only join this appeal. However, it would be even more interesting 
to hear why people can't stop talking about "alternative designs" while 
avoiding to provide a pointer to a single example (vendor X router 
model Y) which _doesn't_ count buffer slots in # of packets?

On the other hand, as a newcomer to this list I find it sad to observe 
that only a few people tried to stick with the topic - on how bad can 
traffic bursts be hitting router queues built up by standard TCP flows, 
which seems much more of an e2e problem to me, than the indepths of the 
router design...

Cheers,

Marko


>
> > Regarding the other statement that implies on how unusual it must
> > be for
> > a TCP flow to build up a queue on a bottleneck link / router, I'd
> > rather not comment...
>
> I didn't imply any such thing; I just noted that the chain of
> assumptions
> had gotten pretty long -- without much validation that the
> assumptions were generally true today.  An invalid premise is
> generally unlikely to lead to a valid conclusion, so it is helpful to
> know whether or not those premises are likely to be valid.
>
> Ran




More information about the end2end-interest mailing list