> While the assumption of IP telephony driving the deployment of end- > to-end QoS might turn out to be correct, past history of Internet > technology deployment indicates this is not very likely. The > deployment of technologies that require changes to the Internet > infrastructure is often extremely slow, and may not be quick enough > for fast-growing applications. >>> The previous sentence could be rephrased as follows: > > The deployment of technologies that require changes to the Internet > infrastructure is subject to a wide spectrum of commercial as well > as technological considerations. Consequently, technologies that > can be deployed using only end-to-end peering without changes to > the infrastructure enjoy considerable advantages in terms of the > speed of deployment. ><< Done. Slightly rephrased. > RFC 2990 outlines some of the >>> insert: > technical >>> Done. > Often, interim measures that provide support for these > applications are adopted, and are successful enough at meeting the > need that the pressure for >>> insert: > ubiquitous >>> Done. > At least initially, and possibly for some time to come, IP telephony > is likely to be deployed over best-effort broadband connections to > public-access networks. >>> This sentence could be rephrased: > Comment: Not necessarily. Currently a number of carriers are looking > at deployment of a VOIP core using a dedicated IP network as a means > of addressing the looming end-of-service-life for SDH cores and > associated internal TDM switches. > > The rationale here is the lower capital and operational costs of > IP networks. > > The observation I would make is that while VOIP over public access > Internet remains the likely direction for various forms of what I > would term 'private' connections where the motivation is essentially > one of PSTN toll bypass in its most general sense (including > international call accounting settlement bypass), there is a further > driving factor for VOIP technologies which is essentially that of > a private internal carrier IP network that is used as an evolution > of the current PSTN SDH carriage core networks. > > The other area of VOIP deployment appears to be the last mile of > ADSL deployments. The current technique of band splitting, where > the low end spectrum is split to support the analogue PSTN handset > is a limiting factor in the radial distance of ADSL. Significantly > longer DSL distances, and higher DSL speeds can be achieved > by eliminating the band splitters, and using VOIP as an alternative > to the PSTN handset. Here themodel is that the VOIP traffic > is sitched out at the DSLAM and routed to a VOIP gateway > and mapped back into the PSTN. > > The conclusion I draw from these observations is what I would suggest > as an alternative phrasing of the sentence -namely: > > VOIP has a number of potential deployment scenarios. The scenario that > presents the greatest set of technical and commercial challenges > appears to be that of the deployment over the public Internet, > where the considerations of balancing the requirements of VOIP > traffic with existing traffic characteristics are of significant > interest. ><< I said this: "The deployment of IP telephony is likely to include best-effort broadband connections to public-access networks, in addition to other deployment scenarios of dedicated IP networks or of band splitting on the last mile of ADSL deployments." > There already exists a rapidly-expanding > deployment of VoIP services intended to operate over residential > broadband access links (e.g., [FWD, Vonage]). At the moment, >>> > many ><< Yep. > This > would result in a delay noticeable to users, with an increased > variation in delay as the bursty TCP traffic comes and goes. >>> suggest: > change "delay" to "call quality" ><< Done. > Nevertheless, VoIP usage over underprovisioned best-effort links is > likely to increase in the near future, regardless of VoIP's superior > performance with "carrier class" service. A best-effort VoIP > connection that persists in sending packets at 64 Kbps, consuming > half of a 128 Kbps access link, in the face of a drop rate of 40%, > with the resulting user-perceptible degradation in voice quality, is > not behaving in a network-friendly manner. >>> > The phrase "network-friendly" seems to me to be somewhat vague. I > suspect that what you are sayinghere is "not behaving in a way that > serves the interests of either the VOIP users or the other concurrent users > of the network, nor is it achieving efficient utilization of the network > itself. ><< Done. > As the Nairobi connection demonstrates, prescribing universal > overprovisioning as the solution to the problem is not an acceptable >>> > generic ><< Done. > However, this does not mean that universal overprovisioning is > acceptable as the only solution to congestion even in environments > where overprovisioning is the typical state of affairs. There will > always be occasional periods of high demand, e.g., in the two hours > after an earthquake or other disaster, and this is exactly when it is > important to avoid congestion collapse (in this case, in the form of > congested links wasting scarce bandwidth carrying packets that will > only be dropped downstream). There are two possible mechanisms for > avoiding this congestion collapse: call rejection during busy > periods, or the use of end-to-end congestion control. Because there > are currently no acceptance/rejection mechanisms for best-effort > traffic in the Internet, the only alternative is the use of end-to- > end congestion control. This is important even if end-to-end > congestion control is invoked only in those very rare scenarios with > congestion in the generally-overprovisioned network. >>> > Here I would see it to be logical to talk a little bit about > network resource management models: > > The rationale for this conclusion lies in consideration as to how > network resources are managed in a network. The QoS response attempts > to place the network into some loosely formulated role of resource > manager, without any specific directives as to how to actually perform > this role in an environment where applications may clearly signal their > future resource demands. Active network-bsed resource management mechanisms > do not readily scale to provide consistent and coherent end-to-end > behaviours. The alternative approach is to use the same mechanisms > that already are deployed in congestion-controlled applications, where > the network itself is neutral in terms of enforcing resource management, > and its the interaction of the applications' transport sessions that > mutually regulate the resource in a fair fashion. The corollary of this > is that the most effective way (both in terms of cost and utility) to > bring voice into this environment in a non-disruptive manner is to > focus attention on the codec and look at rate adaptation measures > that can successfully interoperate with existing transport behaviours, > while at the same time operate within a band that manages to preserve > the integrity of a real time analogue voice signal. ><< I didn't add all of this paragraph. We are not in this section talking about the pros, cons, or difficulties of QoS deployment, so I don't want to add the second and third sentences. (We are talking about best-effort traffic, and simply observing that there is no call rejection for best effort traffic.) I also modified it because this paper is not intended to focus attention mainly on the codec. Instead, it is intended to focus on the specific issue of minimum sending rates, and what happens when that minimum sending rate is not compatible with the current level of very high congestion. This issue applies equally to apps with a fixed sending rate, and to apps with an adaptive codec and a minimum sending rate. It is just that the smaller the minimum sending rate, the better the app can coexist in times of very high congestion. >3. Why are Persistent, High Drop Rates a Problem? > > Persistent, high packet drop rates are rarely seen in the Internet > today, in the absence of routing failures or other major disruptions. > This happy situation is due primarily to overprovisioning and the use > >>> replace "primarily to overprovisioning and the use" with: > to a number of factors, including widespread use of poorly tuned TCP/IP > stacks that back off due to host buffer exhaustion rather than as a > congestion-triggered rate backoff, as well as a deployment pattern > where many high volume sources are located behind relatively low capacity > access systems, network overprovisioning, and the use ><< I put in the second part, but not the first. The poorly tuned TCP/IP stacks are doing bad things, but they aren't contributing to high packet drop rates. High packet drop rates (10% or more) corresponds to average TCP congestion windows of just a few packets. The effects of poorly tuned TCP/IP stacks affects TCP connections with higher congestion windows than that. (That is, you could fix all of the TCP tuning problems, and it would not result in persistent, high packet drop rates in the Internet.) >3.2. User Quality. > > A second problem with persistent, high packet drop rates concerns > quality of service (lower case) to the users. >>> > "quality of service (lower case)" is somewhat clumsy as a term > would "service quality as delivered to end users" be a better > way of saying this? ><< Done. > Unfortunately, there is no obvious canonical round-trip time for > judging relative fairness of flows in the network. Agreement in the > literature is that the majority of packets on most links in the > network seem to experience round-trip times between 10 and 100 ms. >>> > This is perhaps view that is geographically defined. In my neck > of the woods the figure is more like 10 - 500 ms, and as a broad > generalization the figure across the globe sits in the range 10 - 800ms > (satellite) ><< The measurements that I know are at "http://www.icir.org/floyd/rtt-questions.html", in particular the paper by Jiang and Dovrolis, and they do cover more that just North America. But I am happy to say that "most of the packets have RTTs between 10 - 500 ms.", and to say that this excludes satellite links. > Similarly, there is no canonical packet size for judging relative > fairness between TCP connections. However, because the dominant > packet size for TCP data packets is 1460 bytes, >>> > netflow observations still see a bi-polar distribution of packet > sizes using MTUs of 1460 and 576, and we are seeing increasing > deployment of systems that will discover end-to-end paths that > support just under 9000 bytes MTU sizes. Perhaps if you replace > 'dominant' with 'commonly' I'd have less problem with this > assertion. ><< Done. > In the same way, while RFC 2988 specifies TCP's algorithm for setting > TCP's RTO, there is no canonical value for the minimum RTO, and the > minimum RTO heavily affects TCP's sending rate in times of high > congestion [RFC2988]. RFC 2988 specifies that TCP's RTO must be set > to SRTT + 4*RTTVAR, for SRTT the smoothed round-trip time, and for > RTTVAR the mean deviation. > >> replace "for..." with possibly: > where SRTT is the smoother round-trip timeand RTTVAR is the mean > variation of individual round trip time measurements. > << Done. > A separate claim that has sometimes been raised in terms of fairness > is that best-effort VoIP traffic is inherently more important that > other best-effort traffic (e.g., web surfing, peer-to-peer traffic, > or multi-player games), and therefore merits a larger share of the > bandwidth in times of high congestion. Our assumption in this > document is that TCP traffic includes pressing email messages, > business documents, and emergency information downloaded from web > pages, as well as the more recreational uses cited above. Thus, we > do not agree that best-effort VoIP traffic should be exempt from end- > to-end congestion control due to any claims of inherently more > valuable content. (One could equally logically argue that because > email and instant messaging are more efficient forms of communication > than VoIP in terms of bandwidth usage, as a result email and instant > messaging are more valuable uses of scarce bandwidth in times of high > congestion.) >>> > This paragraph skirts around the more basic obseration that the network > is incapable of making a judgement about the relative user value of any > particular traffic element. The assumption here is that all best-effort > traffic has equal value to the networkprovide4r and to the user. ><< Yep, I added that. > We can formulate a problem statement for the minimum sending rate in > the following way. Consider a best-effort, adaptive audio > application that is able to adapt down to a minimum sending rate of N > Bps >>> > Bps is defined as bytes per second in the next para - as this appears > to be the first use, its expansion should go here. ><< Done. > We assume, generously, that the limitation of the network is in > bandwidth in bytes per second (Bps), and not in CPU cycles in packets > per second (pps). If this assumption is correct, then all that > matters in terms of congestion is a flow's sending rate on the wire > in Bps. If this assumption of a network limitation in Bps is not > correct, then the sending rate in pps could contribute to congestion > even when the sending rate in Bps was quite moderate. While the > ideal would be to have a transport protocol that was able to detect > whether the bottleneck links along the path were limited in Bps or in > pps, and to respond appropriately when the limitation was in pps, > such an ideal is hard to achieve, and we would not like to delay the > deployment of congestion control for telephony traffic until such an > ideal could be accomplished. In addition, we note that the current > TCP congestion control mechanisms are themselves not very effective > in an environment where the limitation is in pps. While the TCP > mechanisms do provide an incentive to use large data packets, TCP > does not include any effective congestion control mechanisms for the > stream of small acknowledgement packets on the reverse path. Given > the arguments above, it seems reasonable to us to assume a network > limitation in Bps rather than in pps in considering the minimum > sending rate of telephony traffic. >>> > I'm not sure that I would see this as a generous assumption. I suppose > the distinction lies in the nature of the bottleneck resource as being > the tranmission components (Bps) or the switching systems (pps). > Switching system bottleneck is an issue at the high end of current > networking - most noteably in Internet architectures within POP > design. Perhaps some text here to motivate this discussion would > assist here. >>> I expanded upon this section. > One argument in response to this proposal is that users will just > hang up anyway with a high packet drop rate so there is no point in > enforcing a minimum acceptable rate. Users might hang up, but they > might also just leave the phone off-hook, with the occasional noise > getting though, for minutes or hours waiting for a short period of > clarity. >>> > I dont follow this reasining- leaving the phone off hook without > acttivity would imply silence supression, in which case the end > parties would then hear a 'clear' line and start to speak, hear > noise, stop, go into silence suppression, etc. My own experience > with congested VOIP in a telephone sense is to drop the call. You are right. I changed the example. > However the more basic consideration is that if an application > requires from the network a minimum service level in order to > operate, and the service is consistently not achieved, then > the application should terminate. ><< Thanks, I added that. >6.1. Drop Rates at 4.75 kbps Minimum Sending Rate >>> > I would suggest that the major theme of the document is advocating > a particular argument - that the most pragmatic way of implementing > VOIP on the public Internet is through adaptive applications that > behave with some form of congestion sensitivity that is compatible > with the overall manner of network resource control being achieved > through application interaction, rather than through QoS mediation. > > This section (6.1) and the following 6.2 and 6.3), which head off > into simulations and analyses of a simple case, could readily > be used as an appendix, as the flow of the argument in the document > is in some sense heading down a diversionary path in these sections. ><< The major theme is intended to be not that applications should be adaptive, but that if you are best-effort and have a minimum sending rate, then you have to terminate when the persistent packet drop rate exceeds some threshold. Sections 6.1, 6.2, and 6.3 are central to this argument. > Ultimately, attempting to run VoIP on underprovisioned, congested > links, even with adaptive rate codecs and minimum packet rates, is > likely to run into hard constraints due to the nature of real time > traffic >>> > in heavily congested scenarios ><< Done. > In the near term, VoIP services seem most likely to be deployed over > broadband best effort connections. >>> > As pointed out in a previous comment, this is not the only deployment > scenario. If you change "seem most likely" to "are likely", then > I believe you capture the sense of probable VOIP deployment more > accurately. ><< Done. > and transmission practice ignores congestion considerations, > resulting in the potential for trouble should VoIP become a broadly > deployed service in the near to intermediate term. User quality, > fairness to other VoIP users and TCP, and the potential for > congestion collapse are all potential problems that could result. > >> > Too many 'potential' in this sentence. > > how about altering the last section to read > > "...TCP, and the possibility of sporadic episodes of local > congestion collapse are some of the potential problems in this > scenario." ><< Done. > > These problems can be avoided in applications that use fixed-rate >>> > change "avoided" to "mitigated" ><< Done. > (2) The specified drop rate for the minimum sending rate should be > consistent with the use of Tables 1 and 2 as illustrated in this > document. >>> > I wonder about this as a recommendation. > > I would expect to see some comment and pushback on this recommendation > during IETF review, but I'm not sure that I have an alternate > recommendation that encompasses the sense of what is being proposed > here but refrains from being so explicit. ><< We will see. I left it in. > We note that this is a recommendation to the IETF community, as a > specific follow-up to RFC 2914 on Congestion Control Principles. > This is not a specific, detailed protocol specification. >>> > The inconsistency that strikes me is that Tables 1 and 2 are > quite prescriptive and read to me as a protocol specification. > > As I noted in the prev comment I'm not sure how to reword > this to make these two points consistent. ><< I changed it to say that this is not a specific, complete protocol description. > Codecs that are able to vary their bit rate depending on estimates of > congestion can be even more effective in providing good quality > service while reducing network load. >>> >change "reducing network load" to "maintaining network efficiency >under high load conditions." ><< Done. > Variable-bit-rate codecs are > therefore preferable, though currently the best variable-bit-rate > codecs are encumbered by IPR and therefore unattractive to low-cost > vendors and nonprofit or low-overhead providers. >>> > Is the encumbered IPR rider clause strictly necessary? > > I would prefer to see a more neutral: > > "Adaptive variable-bit-rate codecs are therefore preferable as a means > of supporting VOIP sessions on shared use Internet environments." ><< Done.