Subject: [Tsvwg] Re: [dccp] Initial I-D: draft-briscoe-tsvwg-byte-pkt-mark-00

From: Sally Floyd <[email-masked]>
Date: Thu, 19 Jul 2007 16:30:31 -0700

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/

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 01 Aug 2007 03:02:41 +0100

Sally,

Again, catching up on my backlog - apologies for delayed reply...

>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.

>"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.

>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

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.

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, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196