Elisa,
Most of these responses look fine. I do think additional text
should be added on the topics of:
- warnings about when not to use unordered delivery
- explanation of when UDP use is appropriate
More details inline ...
Some responses also in line. I have deleted the stuff where
we have agreed.
We're getting close, but I think some more work on UDP guidelines
is still appropriate. As the existence of the UDP guidelines draft
indicates, this is a topic of current interest in the Transport Area.
> Section 6.1:
>
> There is an additional service provided by SCTP and useful in
> conjunction with PR-SCTP: unordered delivery. This also
works on a
> per-message basis by declaring that a given message should be
> delivered at the receiver as soon as it is received rather
than kept
> in sequence; however, it should be noted that unless
explicitly
> requested by the sender even messages sent partially reliably
will
> still be delivered in order.
>
> [1] Isn't this likely to cause problems when messages are
> processed out of order? If three messages are sent containing
> absolute counts of 45, 87, and 138, out of order processing
> combined with a delay to the first message could result in the
> count being 45 at the recipient after the three messages are
> processed, which seems rather wrong. Whose responsibility
> is it to prevent this? In contrast, partial reliability skips
> updates that would be generated by processing the dropped
> messages, and hence seems ok.
I propose adding the following text at the end of the paragraph (to
recommend not using unordered delivery when order may matter):
Unordered delivery SHOULD NOT be used when the order of IPFIX
Messages
may matter: e.g., a Template or Options Template.
I think some more explanation is in order about why ordering matters
for templates. I would also say that unordered delivery SHOULD
NOT be used when Total (absolute) Counters are used, as reordering
could result in the counter value decreasing at the Collecting
Process,
and even being left with a stale value if the last message processed
is stale.
ok, so the proposed text on unordered delivery is the following:
There is an additional service provided by SCTP and useful in
conjunction with PR-SCTP: unordered delivery. This also works on a
per-message basis by declaring that a given message should be
delivered
to the receiver as soon as it is queued rather than kept in sequence;
however, it should be noted that unless explicitly requested by the
sender even messages sent partially reliably will still be delivered
in
order.
Unordered delivery SHOULD NOT be used when the order of IPFIX Messages
may matter: e.g., a Template or Options Template. Unordered delivery
SHOULD NOT be used when Total (absolute) Counters are used, as
reordering could result in the counter value decreasing at the
Collecting Process, and even being left with a stale value if the last
message processed is stale.
(note that I've appended the sentence you proposed)
Looks good, here's one minor edit to what I wrote for consistency:
Total (absolute) Counters --> Total counters
> Section 6.2: UDP
>
> [2] I don't see any discussion of congestion control in here.
> Something needs to be done to avoid a high rate IPFIX protocol
> session over UDP worsening a congestion situation because not
> only is the IPFIX flow non-responsive to congestion, but
> congested conditions may increase the volume of IPFIX data
> to be reported. At the very least, this draft should repeat
> and reinforce the discussion in Section 10.3.1 of
> draft-ietf-ipfix-protocol-24.txt, which says that UDP should
> not be used over congestion sensitive network paths - I'm not
> thrilled about that approach, but the ipfix-protocol draft
> is already in the RFC Editor Queue. A general recommendation
> against UDP when TCP or SCTP is possible may be appropriate,
> and the first item in Section 10.1 is related to this concern,
> as it requires availability of a congestion-controlled protocol.
UDP is not the recommended protocol for IPFIX and is intended for
use in
cases in which IPFIX is replacing an existing NetFlow
infrastructure,
with the following properties:
1. a dedicated network
2. within a single administrative domain
3. where SCTP is not available due to implementation constraints
4. and the collector is as close as possible to the exporter.
Would you like to see this text in the document or is the current
text
at the beginning of 6.2 enough:
[ ... snip ... ]
Please put the above text into the document and explain "dedicated
network" in more detail - that is crucial to ensuring the additional
IPFIX traffic generated as a consequence of high traffic situations
does not make the situation worse from a congestion standpoint. In
writing this text, please review
draft-ietf-tsvwg-udp-guidelines-02.txt,
although I suspect that much of it will not be applicable to IPFIX
(it is not necessary to respond to the guidelines in that draft
point-by-point, but it would be good to mention any that do apply).
ok, so the (proposed) text at beginning of 6.2 now is:
UDP is useful in simple systems where an SCTP stack is not
available,
and where there is insufficient memory for TCP buffering.
However, UDP is not a reliable transport protocol, and IPFIX
messages
sent over UDP might be lost as with partially-reliable SCTP
streams.
UDP is not the recommended protocol for IPFIX and is intended for
use
in cases in which IPFIX is replacing an existing NetFlow
infrastructure, with the following properties:
o A dedicated network,
o Within a single administrative domain,
o Where SCTP is not available due to implementation constraints,
o And the collector is as close as possible to the exporter.
Note that because UDP itself provides no congestion control
mechanisms,
it is up to the applications that use UDP to incorporate congestion
avoidance mechanisms. [RFC2309] discusses the dangers of
congestion-unresponsive flows and [draft-ietf-tsvwg-udp-guidelines-02]
provides guidelines for the designers of such applications.
I don't think that treatment of the UDP guidelines draft works, because
(in a perfect world) that draft would have been guidance to the IPFIX
protocol designers. To be specific, how would an application using
IPFIX over UDP obtain the packet loss information needed to implement
TFRC as recommended in Section 3.1.1 of the UDP guidelines draft?
The IPFIX implementation guidelines draft says:
The Collecting Process SHOULD use the Sequence Number in the IPFIX
Message header to determine whether any messages are lost.
but I don't see how the Exporting Process can learn this information
in order to adjust its sending rate using TFRC (did I miss something?).
A discussion of how to implement TFRC or what to do on a dedicated
network when TFRC is not implemented would be useful. The fact that
there was a working NetFlow implementation might be helpful in
configuring IPFIX to not congest the dedicated network.
Beyond this, I would add recommendations on message size (cf. UDP
guidelines section 3.2) and checksums (SHOULD be used, cf. UDP
guidelines section 3.4). I think reliability is covered, and the
"dedicated network" applicability statement above may render most
of the middlebox concerns (section 3.5) inapplicable (administrator
should configure them appropriately), or the resend interval might
be adjusted to deal with this.
> The possibility of Exporter vs. Collector misconfiguration
> on template resend interval vs. template expiry time is
> unfortunate and (as described) can cause interoperability
> issues. Can IPFIX define a template for an Exporter to
> report its resend interval? That would enable a Collector
> to determine an appropriate expiry time for each Exporter,
> and might obviate the need for the packet-count-based
> resend mechanism discussion.
Do you plan to do anything about this?
Sorry, I missed this one.
Not in this document, because this feature is currently not present in
IPFIX (there's no appropriate Information Element for this)
Ok, such is life.
There was an additional comment I didn't answer in my previous email:
Section 4.2:
Although it is not explicitly mentioned in the protocol draft the
order of Information Elements within the Template MAY be changed
by
Exporting or Collecting Processes for example for alignment
purposes.
It looks like this allows a single Collecting implementation
(multiple Collecting Processes) to receive information from
multiple Exporting Processes using the same template but with
different ordering of information sent by each Exporting Process.
No it doesn't... This section is essentially a restatement of the
fact that ordering of multiple identical IEs is important. I'm afraid
that its potential for confusing people exceeds its usefulness...
After reading it again I wonder whether we should keep this section at
all. The importance of keeping order for IEs of the same type is
already
mentioned in 3.4. I propose to remove section 4.2.
That's fine.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf