Replying to COMMENT here..
Given a few of the comments I think it's useful to point this out at the top. This document defines a constant send rate tunnel of OUTER packets, the actual data encapsulated is not constant rate and so can and will be encapsulated along with padding in the outer packets. Lars Eggert via Datatracker <nore...@ietf.org> writes:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
## Comments
### Section 2, paragraph 0
```
2. The AGGFRAG Tunnel
```
This description in this section doesn't seem to accurately reflect the
availability of a congestion-controlled mode of operation, it's only about CBR.
### Section 2.2.3.1, paragraph 1
```
When the tunnel bandwidth is not being fully utilized, a sender MAY
pad-out the current encapsulating packet in order to deliver an inner
packet un-fragmented in the following outer packet. The benefit
```
If this MAY is not followed, the tunnel isn't a CBR tunnel anymore. Permitting
that seems to contradict one of the main premises of this approach?
This is only talking about where to place the required padding. Padding will always be required when the outer packet bandwidth is not fully utilized by inner packet data. This is pointing out that one could put the padding before available inner packet data in order to avoid fragmenting the inner packets.
### Section 2.2.5.2, paragraph 0
```
2.2.5.2. ECN value
```
RFC6040 has updated the guidance in RFC4301 for ECN (see above, too.)
### Section 2.4.2, paragraph 1
```
The required inputs for the TCP friendly rate control algorithm
described in [RFC5348] are the receiver's loss event rate and the
sender's estimated round-trip time (RTT). These values are provided
by IP-TFS using the congestion information header fields described in
Section 3. In particular, these values are sufficient to implement
the algorithm described in [RFC5348].
```
RFC5348 like most IETF congestion control mechanisms are sender-side. Is there a
good reason to flip this around and do the computation on the receiver, which
complicates the actual use of RFC5348?
Yes b/c it greatly reduces the amount of data that needs to be sent back to the sender, and thus increases the available tunnel bandwidth -- a stated goal. No preference is given to where to do the loss rate calculation in the required/referenced CC RFCs.
### Section 2.4.2, paragraph 2
```
the available tunnel bandwidth. An implementation choosing to always
send the data MAY also choose to only update the LossEventRate and
RTT header field values it sends every RTT though.
```
Why? Sending known stale data is worse than not sending any data.
It's not stale data, it is sending the most recent calculation. Always sending allows for the bandwidth calculations to be deterministic.
### Section 4.1, paragraph 1
```
Bandwidth is a local configuration option. For non-congestion-
controlled mode, the bandwidth SHOULD be configured. For congestion-
controlled mode, the bandwidth can be configured or the congestion
control algorithm discovers and uses the maximum bandwidth available.
No standardized configuration method is required.
```
For congestion-controlled mode, what is the point of configuring bandwidth? The
CC algorithm will not use this at all.
CC is about slowing down from the target send rate when there is congestion. The user is still going to want to be able to specify what the constant send rate should be when there is no congestion.
### Section 4.3, paragraph 1
```
Congestion control is a local configuration option. No standardized
configuration method is required.
```
I don't understand what this is supposed to express?
Would it make more sense to simply drop the second sentence? It's just referring to the fact that the document isn't requiring any specific configuration values.
### Section 6.1.2, paragraph 8
```
E:
A 1-bit value that if set indicates that Congestion Experienced
(CE) ECN bits were received and used in deriving the reported
LossEventRate.
```
What is the reason for signaling this? CC does not depend on this.
ECN affects how the Loss Event Rate is calculated and thus the actual rate of a CC'd tunnel. Given the special circumstances of ECN and IPsec, this information could be vary valuable to the sending side as well as the receiver. Thanks, Chris.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
