Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-ipsecme-iptfs-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working on this specification. I found this spec to be a mix of transport and non-transport related topics and had to think a bit more due to lack of rational behind choices made. I would like to discuss - why there is no normative text (MUST/MUST NOT) for non-congestion controlled mode over operation in this specification that prohibits the use of non-congestion controlled mode out side of controlled environment? I am also supporting Lars's discuss on 3.1 ECN support. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The version of this specification changed quite frequently during the telechat review period, hence I am mentioning that I am reviewing the -17th version of this specification. I have following comments, which I believe will improve the specification if properly addressed - # Section 2.4: I would like to have rational behind the two mode of operations. what are the pros and cons and when would an implementer select one over another? if this is written somewhere else then having a point would be great benefit. # Section 2.4.1: I believe the assumption here is that the network is fully provisioned and no congestion related loss should occur hence here would not need to react to any loss. what would be source of the potential loss then? link failure only? if the loss is due to underestimation of bandwidth then 8084 need to be implemented as a last resort. It actually talks about circuit breakers in section 2.4.2.1 and somehow managed to say in addition to congestion control, the implementation that support non-congestion control mode should implement circuit breaker. This is where I am a bit lost, why is this written in section 2.4.2.1 and not in 2.4.1? is this the assumption that the implementation that have non-congestion control mode would not have congestion control mode? The failure correction due to the expected bandwidth under, where loss seems to be an indication, seems like a serious matter and but still there is no normative language requirements on the reporting the loss. I wonder how useful this could be. The last line actually makes me more confused. If ESP over TCP is in use then TCP would trigger the congestion control, thus this becomes a congestion controlled case and yes, you can then perhaps send out packets without thinking about congestion collapse. But then the assumption changes, then it becomes the case IP-TFS is expected to run over a congestion controlled transport. however, that is not the general assumption for the whole non-congestion controlled mode of operation. Here, I think we need to clarify a bit more on how to interpret the non-congestion controlled mode description. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
