Re: Initial I-D: draft-briscoe-tsvwg-byte-pkt-mark-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bob -

Some feedback on "Byte and Packet Congestion Notification",
draft-briscoe-tsvwg-byte-pkt-mark-00:

It seems odd to me to talk about RED in byte vs. packet mode, and
not to talk about the similar performance difference between
Drop-Tail queues in bytes vs. packets.  (Well, someone could
care about RED and not Drop-Tail because one cared only
about packet marks in an ECN environment, but for this document
it strikes me as quite odd to talk about RED in byte vs. packet mode,
and not to talk also about Drop-Tail queues in bytes vs. packets.)

I am enclosing some text from some 2/26/2007 email that I sent you
about this, in response to "draft-briscoe-tsvwg-byte-pkt-mark-00c".
(I didn't reread the new draft, but I did look at the diffs between
draft-briscoe-tsvwg-byte-pkt-mark-00 and
draft-briscoe-tsvwg-byte-pkt-mark-00c, and I didn't notice anything
added about Drop-Tail queues in bytes vs. packets.)

From my 2/26/2007 email:
----------------------------------------------------------------
"As is discussed at length and illustrated with simulations in [RFC
4828], drop-tail queues also have a wide range of possible behaviors,
in terms of dropping packets from a flow proportionally to the
sending rate in bits per second, or to the sending rate in packets
per second, or something else entirely.  For example, the abstract
of [RFC 4828] includes the following:"

    "Flows using TFRC-SP compete reasonably fairly with large-packet TCP
    and TFRC flows in environments where large-packet flows and small-
    packet flows experience similar packet drop rates.  However, in
    environments where small-packet flows experience lower packet drop
    rates than large-packet flows (e.g., with Drop-Tail queues in units
    of bytes), TFRC-SP can receive considerably more than its share of
    the bandwidth."

"This is discussed more in Section 4.5.1, and in Appendix B.3 of that draft."

"My understanding is that buffer architectures in routers can be
complex, but one buffer architecture is to have a fixed number of
slots for packet headers in the output queue, with the actual data
packet stored elsewhere in the router.  So in this design, the queue
would essentially have a fixed number of slots for packet headers,
with each packet taking exactly one packet-header slot, regardless
of the packet size in bytes.   Functionally, this would be equivalent
to a Drop-Tail queue in packets in NS.  But there could also be
routers whose Drop-Tail queues are more like the Drop-Tail queue
in bytes in NS, where small packets are more likely than large
packets to find a slot in the queue.  So the complications are not
only about AQM..."
----------------------------------------------------------------


As an aside, in the future should I forward feedback about this draft to
only one of the three mailing lists above?

- Sally
http://www.icir.org/floyd/



[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux