Authors, WG,
This note closes the IETF DCCP WGLC on CCID 4. During the LC, comments
were received from Arjuna (below) and to this I would also like to add
the following two comments. Please could the authors now issue a revised
ID to address these issues?
Best wishes,
Gorry Fairhurst
DCCP Chair
---
Comments from WG Chair:
1) During the WG in San Francisco, the WG talked about whether the
dependency of this document on previous documents needs to be
clarified. Having re-examined the text, I can see there is scope
for a little more clarity in section 1.
RFC 4342 states:
3.1. Relationship with TFRC
The congestion control mechanisms described here follow the TFRC
mechanism standardized by the IETF [RFC3448]. Conforming CCID 3
implementations MAY track updates to the TCP throughput equation
directly, as updates are standardized in the IETF, rather than wait
for revisions of this document. However, conforming implementations
SHOULD wait for explicit updates to CCID 3 before implementing other
changes to TFRC congestion control.
CCID-4 in section 1 now writes:
"CCID 4 differs from CCID 3 in that CCID 4 uses TFRC-SP,
the Small-Packet variant of TFRC [RFC4828], while CCID 3 [RFC4342]
uses standard TFRC [RFC3448]. (At the time of writing of this
document, [RFC3448] has been obsoleted by [RFC5348]. However,
[RFC4342] predates [RFC5348], and refers instead to [RFC3448].) This
document assumes that the reader is familiar with [RFC4342], instead
of repeating from that document unnecessarily."
- Would the authors please consider reworking this a little?
- CCID 4 is derived from RFC 4342 and hence inherits from RFC 3448. But,
it is my understanding that TFRC-SP also includes an update from
TFRC.bis, now published as RFC 5348. We need to be clear whether CCID 4
assumes the updates in RFC5348 should also be applied when implementing
CCID 4.
---
2) I often use the formulation "CCID-3" and "CCID-4" when I write about
DCCP, but so far in standards documents we have not hyphenated the CCID
labels. Could the authors please update this document to consistently
use the non-hyphenated style?
---
Comments from Arjuna (as sent during WGLC):
The headings from page 10 are not aligned properly.
3.1 Relationship with TFRC and TFRC-SP
This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For
TFRC,
RFC 3448 [RFC3448] has been obsoleted by RFC 4342 [RFC4342].
--> Change to:
This document is based on CCID 3 [RFC4342], TFRC, and TFRC-SP. For TFRC,
RFC 3448 [RFC3448] has been obsoleted by RFC 5348 [RFC5348].
3.2. Example Half-Connection
This example differs from that for CCID 3 in [RFC4342] only in that the
allowed transmit rate is determined by [RFC4828] as well as by
[RFC5348].
--> Consider rephrasing. Change to something like:
This example differs from that of CCID 3 in [RFC4342] with respect to
allowed transmit rate which is determined by [RFC4828] as well as by
[RFC5348].
2. Each DCCP-Ack packet uses a sequence number, identifies the most recent
packet received from the sender,
--> Change to:
Each DCCP-Ack packet uses a sequence number, identifying the most
recent packet received from the sender,
3. The sender continues sending DCCP-Data packets as controlled by
the allowed transmit rate. Upon receiving DCCP-Ack packets, the
sender updates its allowed transmit rate as specified in [RFC5348]
(Section 4.3) and [RFC4828].
--> Remove extra space between Section 4.3 and [RFC4828].
Section 5:
Other Congestion Control Mechanisms
The other congestion control mechanisms such as slow-start, feedback
packets, and the like are exactly as in CCID 3, and are described in
the subsection on "Other Congestion Control Mechanisms" of Section 5
in [RFC4342].
--> Change to:
The other congestion control mechanisms such as slow-start, feedback
packets are exactly as in CCID 3, and are described in the subsection on
"Other Congestion Control Mechanisms" of Section 5 in [RFC4342].
Section 6.1: First para.
For short loss intervals of at most two round-trip times, TFRC-SP
computes the loss interval length as the data length divided by the number
of dropped or marked data packets, (rather than as the data length of the
loss interval).
--> Change to:
For short loss intervals of at most two round-trip times, TFRC-SP
computes the loss interval length as the data length divided by the number
of dropped or marked data packets (rather than as the data length of the
loss interval).
8.7. Dropped Packets Option (para 6)
This conservative assumption leads to the minimum send rate
for the corresponding loss intervals.
--> Is this maximum send rate?
