In the general case, delay across a
network path depends not only on distance, but also a number of
variable components such as the route and the level of buffering in
intermediate devices.Its is more the contending/conflicting traffic rather than the buffering, or perhaps the time spent in queues, but “buffering” is a link a transport colloquial term. Since our wide-area network paths are best
effort, packet loss is a regular occurrence. No the best effort Internet experiences this. There ate many well engineered WAN that do not. What I am not seeing is clearer text that distinguishes between user traffic and “engineering” traffic that is used to make the network work, and between the end to end traffic and traffic within an AS that may be there for other purposes (high value service also offered by the provider) and WANs that are well engineered. Perhaps we could include a clearer disclaimer regarding the non-best-effort-internet-end-to-end traffic? You have some text on this down in section 2 but it is a bit buried. Perhaps something early on of the form: This document is specially concerned with end to end behaviour over the best effort Internet. As noted in section 2 it may not me applicable to other types of WAN, or to the traffic used in affecting the operation of the Internet itself. An exception to this rule is if an IETF standardized mechanism
determines that a particular loss is due to a non-congestion
event (e.g., packet corruption). That is a bit heavy. It should be “a protocol” there than an IETF standardarized mechanism. The IETF does not have a monopoly on pre-blessing protocols before they are deployed.
As I note above from a routing and packet transport (as opposed to the transport layer) perspective I think we should more clearly recognise at the beginning the fact that this is for the worst case network, not for well engineered (WAN and DC) networks and the mechanisms fundamental to the operation of the network itself.
In some cases you cannot tell the cause, but it is more important to ignore the loss. OAM being a particularly good example.
We are getting there, but I would ask that you take the transport hat off and look again from an infrastructure and packet transport perspective. Best regards Stewart |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
