Sally,
Again, catching up on my backlog - apologies for delayed reply...
At 00:30 20/07/2007, Sally Floyd wrote:
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.)
After I had posted the draft, I realised I still hadn't taken this point
you made into account. Sorry about that - it will be in the -01 update.
I tried to make up for this at least in my presentation in Chicago, where I
warned people not to turn off RED altogether (actually, I hadn't read this
latest email from you before last week's presentation, but I had remembered
this excellent point you had made in your previous offlist email).
But I accept, there's a lot more to this issue that I need to address
properly in the next draft.
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 immediate thought was that, if a vendor is implementing AQM, they are
offering an alterantive to drop tail, so I was giving advice on whether to
take a packet's size into account when deciding whether to drop it _in an
AQM algorithm_.
You are right that my line of reasoning leads to the conclusion that I made
- that transports should take account of packet size, not AQM algorithms.
You are right that transports using small packets will see less drop from
unmodified (drop tail) queues. So if such transports scale down their
response to smaller dropped packets (as TFRC-SP proposes), they will go
faster than transports sending large packets that compete for the same
drop-tail queue.
My reasoning then goes that we, the IETF, need to decide unequivocally
where this bias should be reversed:
a) treat the cause, by recommending AQM with packet-mode drop wherever
possible?
b) treat the symptom, by recommending transports don't take account of
packet size?
The more successful we are at a), the more b) type solutions will be
incorrect, and we will instead want transports to take account of packet size.
If we believed b) was the right approach, we shouldn't have ever
recommended a). But it's too late to turn back, because we already
recommended a) - largely because we wanted to remove the bias towards small
packets of drop tail. And I believe RED is now very widely deployed (BT
have certainly deployed it, and I believe it is common elsewhere).
I also believe a) was (and still is) the better path. I believe we should
press on with a), encouraging AQM. Not turn back now. I also don't believe
we can expect the industry to follow both paths, without adding
considerable complexity to the Internet.
"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.
This is surely the question of how to measure the queue length in order to
decide an interim drop probability, not how to determine whether to modify
the interim drop probability dependent on the size of the packet currently
being considered for drop.
I believe I correctly reflected your advice on queue measurement in my
sections 4 & 6.1.
Functionally, this would be equivalent
to a Drop-Tail queue in packets in NS.
I don't believe this is correct.
- As an overloaded drop tail queue forwards packets to the line, at any one
time it is more likely to have made space for an arriving small packet than
a large one. So the drop rate of larger packets will be greater.
- As an overloaded queue of fixed size headers forwards packets to the
line, no more space is needed for the header of a large packet than a small
one, so the drop rate of large and small packets will be the same (assuming
the buffer for the payloads held elsewhere is not the limiting resource)
Am I missing something?
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..."
The general point is true, that the complications are not only about AQM.
Even tho I think the specific sentence I objected to above is wrong, it
doesn't invalidate your general argument that this isn't only about AQM,
which I hope I have addressed now, and I will also try to address more
rigorously in the -01 update of this draft.
----------------------------------------------------------------
As an aside, in the future should I forward feedback about this draft to
only one of the three mailing lists above?
I think tsvwg will be enough (as requested in the draft). I was just
hiliting the existence of this draft to the other lists it was relevant to,
but discussion not specific to one of the other w-gs need only be on tsvwg.
I've cc'd them one last time, so anyone who wants to follow this discussion
knows where it has gone.
Cheers
Bob
____________________________________________________________________________
Bob Briscoe, <bob.briscoe@xxxxxx> Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
