Subject: Re: [Tsvwg] TCP Smart Framing

From: Mark Allman <[email-masked]>
Date: Tue, 22 Jan 2002 22:43:05 -0500

> They actually work about every different way you could imagine, so
> it's probably sound not to reason about them much one way or the
> other.

OK, I'll buy that advice.

So, to work at the real issue in question here: How do you set the
queue length?  Packets or bytes?  The last time I played with cisco
equipment it was in terms of packets (at least the defaults that
this stupid user was playing with).  So, regardless of the internals
my point regarding smart framing would still hold.  On the other
hand, the point is less valid if the router you are using ends up
queueing in terms of bytes.

allman

---
Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 22 Jan 2002 20:36:11 -0800

Mark,

Although memory impact would be less if allocation was done in bytes, the
overhead for such a scheme would include a more expensive allocation process
in addition to queue selections.  The fastest solution I could implement in
software was as you described for cable modem and wireless head-ends.  The
limits of these systems were packets per second and never bytes per second
as wire speed was possible if the average packet size was sufficient.
Memory conservation was not an issue, just per packet overhead against
system bus limitations.  It would be interesting to find the effect on
average packet size over a large network.

Doug

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 23 Jan 2002 21:19:35 -0500

> queue length?  Packets or bytes?

Either, depending on the box.  It's impossible for me to say whether
one is more common than the other.  As I suggested, I suspect bytes is
more common for newer gear, since that's the resource that is likely
to have a `physical' incarnation in the router.

RED-type algorithms (which give you probabilistic queue length limits)
operate on bytes.

With respect to routers, two small packets or one big one is probably
a toss up.  It is certainly a goal of new equipment (I think of
Juniper as being the beginning of `new' but I'm sure there's older
`news' than that), to make that the case.  Two small packets has
slightly more overhead in headers, and that's about as far as you can
go without stepping on to thin ice.

However, as far as current end stations are concerned, there's a big
difference between two small and one large.

Steph