Hi, On 2022-8-23, at 19:56, Christian Hopps <cho...@chopps.org> wrote: > 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.
thanks - I do understand this, but the outer traffic is only CBR if congestion-controlled TFRC mode is *not* used, correct? > 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. But the MAY in the current text allows to not pad at all. If that is not an option that should be permitted, rephrase the RFC2119 language to not allow this? >> ### 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. You're defining a padded tunnel that by definition needs to increase bandwidth overhead to reduce traffic observability, and at the same time you worry about control traffic overhead on the order of a few bytes per second? >> ### 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. Sorry, I don't follow. How does the rate calculation become non-deterministic when CC data isn't always sent? >> ### 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. Oh, so the target rate is a cap on the bandwith the tunnel will use in CC mode? That isn't clear from the document at all. Please make this much more clear. >> ### 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. Probably. Is this intending to say that whether CC mode is used is configurable, or that if CC mode is used, that there are parameters that need to be configured, or both? >> ### 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. Sure. But why does the sender need to know that the receiver used ECN information when calculating the rate? What's it supposed to do with the information? > Given the special circumstances of ECN and IPsec, this information could be > vary valuable to the sending side as well as the receiver. Please say more? Thanks, Lars
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
