[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[tsvwg] Some detailed comments on draft-ietf-tsvwg-byte-pkt-congest-01.txt (Oct 2009)
Revived draft: draft-ietf-tsvwg-byte-pkt-congest-01.txt
Bob,
I've been reading the recently revived draft and sent some general
comments and questions. This particular email contains some detailed
comments on the current draft text, and in particular on the structure
and clarity, suggesting that some reorganisation and reduction may
clarify the IETF implications. I hope these are helpful in preparing
your next revision of the draft.
Best wishes
Gorry
-----------------------------------------------------------------------------
Abstract:
- I found this hard to parse:
"Reducing drop
of small packets has some tempting advantages: i) it drops less
control packets, which tend to be small and ii) it makes TCP's bit-
rate less dependent on packet size."
- Please could this be phrased easier for reading...
"There are advantages in a network dropping..." etc.
---
- This seems rather awkward and philosophical:
"However, there are ways of
addressing these issues at the transport layer, rather than reverse
engineering network forwarding to fix specific transport problems."
_ can you rephrase to say something like: "equivalent" methods at the
transport layer that ...
---
- I agree, but this could also be clearer, because we don't say what
fewer means:
"should not be used to drop fewer small packets"
- Are you saying should drop packets as an indication of congestion, and
should not drop a higher proportion...
- That is recommend not to implement deliberate preferential treatment
for small packets in AQM algorithms
---
I think it is traditional to say the RFC number that is to be updated if
this is a specific update, but you can cite a reference in the abstract.
-----------------------------------------------------------------------------
Introduction:
---
- Could you simplify the start of this sentence?
" Note that the byte vs. packet dilemma concerns congestion.."
---
- Resource here is normally router in an internet context?
"load on a resource depends"
---
- Buffers
"Some machine architectures.."
- I agree buffer memory may be managed in either way. I didn't see the
reason for the word "machine" - could we say router? in this example?
---
"Note that information is generally processed or transmitted with a
minimum granularity greater than a bit (e.g. octets). The
appropriate granularity for the resource in question SHOULD be used,
but for the sake of brevity we will talk in terms of bytes in this
memo."
- Do you differentiate between bytes and octets here?
- This paragraph starts as a note and ends as a SHOULD. It seem odd to
make a standards statement in the introduction, and to me the
requirement is not clear.
----
" Measuring congestion When the congested resource decides locally how
to measure how congested it is. (Should the queue be measured in
bytes or packets?);"
"In RED, whether to use packets or bytes when measuring queues"
"RED can measure the resource queue in units of bytes (byte-mode) or
packets (packet-mode)"?
Can you think about whether you could simplify these phrases perhaps, to
make it easier to read?
e.g. something like... Measuring congestion: The process by which a
resource measures congestion in units of bytes or packets.
---
"The controversy is mainly around "
- I missed the controversy - is this still the dilemma, which I did not
understand, or is it the design choice of what to signal? Consider
simplifying English?
---
There is a list of motivations, please omit points, if not needed, e.g.:
(3) seems a repetition of (2)
(4) doesn't seem a strong actual reason to do this (could omit this?)
(5) Is rather awkwardly written, but seems valid to me.
(6) This is rather long, and the note does not seem clear to me.
----
"This memo is initially concerned with how we should correctly scale
congestion control functions"
- This paragraph could be condensed and would be more readable.
---
- The final paragraph appears to use a paper structure, rather than
appropriate to an RFC?
---
Section 2:
- This section seems verbose - Is it possible to reduce the length and
also to tighten and simplify the language?
---
Section 3:
- I wonder if this section is needed?
- E/L is defined but not used.
- Can we omit this section completely?
---
Section 4:
- I'm not sure this discussion is needed in the body of the RFC.
4.1.1 para 2 could be made easier to read.
---
Section 5:
- I do not see the need for the current description here. Discussions on
encoding are on-going within PCN, and I would rather not conflict with
their charter. My own preference would be to drop this section, although
you may wish to move some of this to the appendix to see if others wish
to contribute on developing this?
---
Section 6:
- Please check the assertions, e.g.:
" Any AQM
^^^
algorithm on such a buffer will be oversensitive to high proportions
of small packets, e.g. a DoS attack, and undersensitive to high
proportions of large packets"
- I think there could be configurations that are not particularly
sensitive, but I
could believe that AQM configurations may over estimate
---
- What is the guidance here:
"But an operator can safely keep such a
legacy buffer because any undersensitivity during unusual traffic
^^^^^^^^^^^^^
mixes cannot lead to congestion collapse given the buffer will
eventually revert to tail drop, discarding proportionately more large
packets."
- What is a "legacy buffer", and are you saying such a buffer size
distribution is safe in that it is unlikely to contribute to congestion
collapse? - or something else?
---
- I'm not sure what this saying:
" This may merely be an
administrator-interface preference, not altering how the queue itself
is measured but on some hardware it does actually change the way it
measures its queue."
- I did not understand: Are you saying can determine the size of the
allocated buffer, and on some platforms may also change the way the
queue size is reported?
---
- Why is this implementation recommendation so strong:
"Whether a resource is bit-congestible or packet-
congestible is a property of the resource, so an admin SHOULD NOT
ever need to, or be able to, configure the way a queue measures
itself."
- I can think of cases where an upstream router directly feeds a layer 2
interface that is bit-congestible, and other cases where it does not.
Are you saying that the IETF should strongly discourage operators to
allow me to set this?
---
- What does "fairly well understood" mean here - is there still some
lack of consensus here that the IETF needs to ask about? I think we
should change the language of this paragraph if the next sentence is true.
"We believe the question of whether to measure queues in bytes or
packets is fairly well understood these days. "
---
I found 6.2.1 and 6.2.2 (with the exception of the last para of 6.2.2 to
be mainly a review of what others say, that could be OK, but I think
there are important lessons here.
- I wonder if the word "bias" in the section headings here, looks like
an analysis, rather than justification for the later guidance.
- Encouraging the transport do the right thing seems a good goal.
- The earlier analogy to PMTUD could be useful?
---
6.2.3:
" Although no proposals exist as far as we know, it would also be
possible and perfectly valid to make control packets robust against
drop by explicitly requesting a lower drop probability using their
Diffserv code point [RFC2474] to request a scheduling class with
lower drop."
- I wonder if this would also need an accompanying note that this could
induce reordering between control and data packets?
---
6.2.3:
" Although not brought to the IETF, a simple proposal from Wischik..."
- but if the WG chooses to highlight this, then we must also be careful
to note that the increased level of control traffic could negatively
impact some lower-layers, e.g. impacting dynamic bandwidth/channel
assignment at layer 2.
---
6.2.4:
"A survey has been conducted of 84 vendors to assess how widely drop
probability based on packet size has been implemented in RED."
If this is a WG draft, can we be sure that the interpretation here
matches that of the WG. I'm a little worried whether the reported
surveys leading to conclusions were conducted with visibility within the
IETF or in some other process. What happened in this case?
- Para 3 of the conclusion follows this.
---
Section 7:
To me, this seems to be the work that the IETF needs to do.
"We should also note that, strictly, packet-congestible resources are
actually cycle-congestible because load also depends on the
complexity of each look-up and whether the pattern of arrivals is
amenable to caching or not."
- Is this always so? I'm not sure what this claims.
"Further, this reminds us that any
solution must not require a forwarding engine to use excessive
processor cycles in order to decide how to say it has no spare
processor cycles."
- Motherhood and apple pie?
"The problem of signalling packet processing congestion is not
pressing,"
- I'd agree in most cases for the general Internet, but I'd be hesitant to
make a claim for all network technologies. Do we need to be so general?
Section 8: Security - may need to be reviewed later.
Section 9: Conclusions
- Please remove strong - the IETF doesn't differentiate conclusions in
this way.
- The current document says:
"The strong conclusion is that AQM algorithms such as RED SHOULD NOT
use byte-mode drop."
- To me this recommendation is to the Internet Area, please use
packet-mode by default?
- Is this so, even if the network resource is specifically
byte-congestible? i.e. are in the specific case where the RED-queue
being policed is byte-congestible, e.g. a low-speed link that is
constrained by capacity, and not by forwarding rate.
---
- Is it possible that this is the same message that continues at the end
of the second para?
"But we SHOULD NOT hack the network
layer to improve or fix certain transport protocols. No matter how
predominant a transport protocol is (even if it's TCP), trying to
correct for its failings by biasing towards small packets in the
network layer creates a perverse incentive to break down all flows
from all transports into tiny segments."
---
- It currently says:
"More generally, the Internet's congestion
notification protocols (drop, ECN & PCN) SHOULD take account of
packet size when the notification is read by the transport layer, NOT
when it is written by the network layer."
- I think the SHOULD is directed at the transport area, that is we
SHOULD design protocols that account for packet size.
- Could you please rephrase the second phrase with the "NOT"?
---
- It says:
"This approach offers
sufficient and correct congestion information for all known and
future transport protocols"
^^^^^^^^^^^^^^^^^^^^^^^^^^
- I may be persauded this is a safe basis for future transport protocol
designs, but I'd be unhappy to say that it is sufficient for all
yet-to-be-invented approaches. Please consider rephrasing.
---
Please consider if you could reorganize the text to provide a short
section on middlebox/firewall implications. To me, the document would
have been clearer if the core of the document focussed on AQM/RED in
routers and then explicitly had a section for middleboxes, and whatever
else that addresses the implications in these cases. I don't anticipate
middlebox and applications developers parsing through the whole document
to see what they should do.
---
I'll review the appendices and security considerations in the next revision.
---