外文翻譯--tcp友好的多播擁塞控制協(xié)議

1、<p><b>　　外 文 翻 譯</b></p><p>　　畢業(yè)設(shè)計(jì)題目：IP網(wǎng)絡(luò)中單速率多播擁塞控制</p><p>　　算法研究 </p><p>　　原文 1：TCP-Friendly Multicast Congestion </p><p>　　Control (

2、TFMCC): </p><p>　　Protocol Specification </p><p>　　譯文1：TCP友好的多播擁塞控制協(xié)議: </p><p>　　協(xié)議規(guī)范 </p><p>　　原文2：A Simple And Effecti

3、ve Single-Rate Multicast Congestion Control</p><p>　　譯文2：一種簡(jiǎn)單而有效的單速率多播擁塞控制方案 </p><p>　　TCP-Friendly Multicast Congestion Control (TFMCC):</p><p>　　Protocol

4、Specification</p><p>　　1. Introduction</p><p>　　This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a source-based, single-rate congestion control scheme that bui

5、lds upon the unicast TCP-Friendly Rate Control mechanism (TFRC). TFMCC is stable and responsive under a wide range of network conditions and scales to receiver sets on the order of several thousand receivers. To support

6、scalability, as much congestion control functionality as possible is located at the receivers. Each receiver continuously determines a</p><p>　　TFMCC is a building block as defined in RFC 3048. Instead of sp

7、ecifying a complete protocol, this document simply specifies a congestion control mechanism that could be used in a transport protocol such as RTP, in an application incorporating end-to-end congestion control at the app

8、lication level. This document does not discuss packet formats, reliability, or implementation-related issues.</p><p>　　TFMCC is designed to be reasonably fair when competing for bandwidth with TCP flows. A m

9、ulticast flow is ‘‘reasonably fair’’ if its sending rate is generally within a factor of two of the sending rate of a TCP flow from the sender to the slowest receiver of the multicast group under the same network conditi

10、ons.</p><p>　　In general, TFMCC has a low variation of throughput, which makes it suitable for applications such as streaming media where a relatively smooth sending rate is of importance. The penalty of hav

11、ing smooth throughput while competing fairly for bandwidth is a reduced responsiveness to changes in available bandwidth. Thus TFMCC should be used when the application has a requirement for smooth throughput, in particu

12、lar, avoiding halving of the sending rate in response to a single packet drop. For appl</p><p>　　as short a time as possible, PGMCC may be more suitable</p><p>　　2. Protocol Overview</p>

13、<p>　　TFMCC extends the basic mechanisms of TFRC into the multicast domain. In order to compete fairly with TCP, TFMCC receivers individually measure the prevalent network conditions and calculate a rate that is TCP

14、-friendly on the path from the sender to themselves. The rate is determined using an equation for TCP throughput, which roughly describes TCP’s sending rate as a function of the loss event rate, round-trip time (RTT), an

15、d packet size. We define a loss event as one or more lost or marked pac</p><p>　　Basically, TFMCC’s congestion control mechanism works as follows:</p><p>　　? Each receiver measures the loss even

16、t rate and its RTT to the sender.</p><p>　　? Each receiver then uses this information, together with an equation for TCP throughput, to derive a TCP-friendly sending rate.</p><p>　　? Through a d

17、istributed feedback suppression mechanism, only a subset of the receivers are allowed to give feedback to prevent a feedback implosion at the sender. The feedback mechanism ensures that receivers reporting a low desired

18、 transmission rate have a high probability of sending feedback.</p><p>　　? Receivers whose feedback is not suppressed report the calculated transmission rate back to the sender in so-called receiver reports.

19、 The receiver reports serve two purposes: they inform the sender about the appropriate transmit rate, and they allow the receivers to measure their RTT.</p><p>　　? The sender selects the receiver that repor

20、ts the lowest rate as current limiting receiver (CLR).</p><p>　　Whenever feedback with an even lower rate reaches the sender, the corresponding receiver becomes CLR and the sending rate is reduced to match t

21、hat receiver’s calculated rate. The sending rate increases when the CLR reports a calculated rate higher than the current sending rate.</p><p>　　The dynamics of TFMCC are sensitive to how the measurements ar

22、e performed and applied and what feedback suppression mechanism is chosen. We recommend specific mechanisms below to perform and apply these measurements. Other mechanisms are possible, but it is important to understand

23、how the interactions between mechanisms affect the dynamics of TFMCC.</p><p>　　3. Data Sender Protocol</p><p>　　The data sender multicasts a stream of data packets to the data receivers at a con

24、trolled rate. Whenever feedback is received, the sender checks if it is necessary to switch CLRs and to readjust the sending rate.</p><p>　　The main tasks that have to be provided by a TFMCC sender are:</

25、p><p>　　? adjusting the sending rate,</p><p>　　? controlling receiver feedback, and</p><p>　　? assisting receiver-side RTT measurements.</p><p>　　3.1. Sender Initializatio

26、n</p><p>　　At initialization of the sender, the maximum RTT is set to a value that should be larger than the highest RTT to any of the receivers. It should not be smaller than 500 milliseconds for operation

27、 in the public Internet. The sending rate X is initialized to 1 packet per maximum RTT</p><p>　　3.2. Determining the Maximum RTT</p><p>　　For each feedback packet that arrives at the sender, the

28、 sender computes the instantaneous RTT to the receiver as R_r = ts_now - ts_i’ </p><p>　　Where ts_now is the time the feedback packet arrived. Receivers will have adjusted ts_i’ for the time interval between

29、 receiving the last data packet and sending the corresponding report so that this interval will not be included in R_r . If the actual RTT is smaller than the resolution of the timestamps and ts_now equals ts_i’, then R_

30、r is set to the smallest positive RTT value larger than 0 (i.e., 1 millisecond in our case). If the instantaneous RTT is larger than the current maximum RTT, the </p><p>　　The maximum RTT is mainly used for

31、feedback suppression among receivers with heterogeneous RTTs. Feedback suppression is closely coupled to the sending of data packets and for this reason, the maximum RTT must not decrease below the maximum time interval

32、 between consecutive data packets: R_max = max(R_max, 8s/X + ts_gran) where ts_granis the granularity of the sender’s system clock</p><p>　　3.3. Adjusting the Sending Rate</p><p>　　When a feedba

33、ck packet from receiver r arrives at the sender, the sender has to check whether it is necessary to adjust the transmission rate and to switch to a new CLR. How the rate is adjusted depends on the desired rate X_r of the

34、 receiver report. We distinguish four cases:</p><p>　　1. If no CLR is present, receiver r becomes the current limiting receiver. The sending rate X is directly set to X_r, so long as this would result in a

35、 rate increase of less than 8s/R_max bits/s (i.e., 1 packet per R_max). Otherwise X is gradually increased to X_r at an increase rate of no more than 8s/R_max bits/s every R_maxseconds.</p><p>　　2. If receiv

36、er r is not the CLR but a CLR is present, then receiver r becomes the current limiting receiver if X_r is less than the current sending rate X and the receiver_leave flag of that receiver’s report is not set. Furthermore

37、, the sending rate is reduced to X_r .</p><p>　　3. If receiver r is not the CLR but a CLR is present and the receiver_leave flag of the CLR’s last report was set, then receiver r becomes the current limiting

38、 receiver. However, if X_r > X, the sending rate is not increased to X_r for the duration of a feedback round to allow other (lower rate) receivers to give feedback and be selected as CLR.</p><p>　　4 .If

39、 receiver r is the CLR, the sending rate is set to the minimum of X_r and X+ 8s/R_max bits/s. If the receiver has not yet measured its RTT but already experienced packet loss (indicated by the corresponding flags in the

40、receiver report), the receiver report will include a desired rate that is based on the maximum RTT rather than the actual RTT to that receiver. In this case, the sender adjusts the desired rate using its measurement of t

41、he instantaneous RTT R_r to that receiver:</p><p>　　X_r’ = X_r * R_max / R_r</p><p>　　X_r’ is then used instead of X_r to detect whether to switch to a new CLR.</p><p>　　If the TFMC

42、C sender receives no reports from the CLR for 4 RTTs, the sending rate is cut in half unless the CLR was selected less than 10 RTTs ago. In addition, if the sender receives no reports from the CLR for at least 10 RTTs, i

43、t assumes that the CLR crashed or left the group. A new CLR is selected from the feedback that subsequently arrives at the sender, and we increase as in case 3 above.</p><p>　　If no new CLR can be selected (

44、i.e., in the absence of any feedback from any of the receivers) it is necessary to further reduce the sending rate. For every 10 consecutive RTTs without feedback, the sending rate is cut in half. The rate is at most red

45、uced to one packet every 8 seconds. Note that when receivers stop receiving data packets, they will stop sending feedback. This eventually causes the sending rate to be reduced in the case of network failure. If the netw

46、ork subsequently recovers, a </p><p>　　3.4. Assisting Receiver-Side RTT Measurements</p><p>　　Receivers measure their RTT by sending a timestamp with a receiver report, which is echoed by the se

47、nder. If congestion control information is piggybacked onto data packets, usually only one receiver ID and timestamp can be included. If multiple feedback messages from different receivers arrive at the sender during the

48、 time interval between two data packets, the sender has to decide which receiver to allow to measure RTT. The same applies if separate congestion control messages allow to echo mul</p><p>　　The sender’s time

49、stamp echoes are prioritized in the following order:</p><p>　　1. a new CLR (after a change of CLR’s) or a CLR without any previous RTT measurements</p><p>　　2. receivers without any previous RTT

50、 measurements in the order of the feedback round echo of the corresponding receiver report (i.e., older feedback first)</p><p>　　3. non-CLR receivers with previous RTT measurements, again in ascending order

51、of the feedback round echo of the report</p><p>　　4. the CLR Ties are broken in favor of the receiver with the lowest reported rate.</p><p>　　It is necessary to account for the time that elapse

52、s between receiving a report and sending the next data packet. This time needs to be deducted from the RTT and thus has to be added to the receiver’s timestamp value.</p><p>　　Whenever no feedback packets a

53、rrive in the interval between two data packets, the CLR’s last timestamp, adjusted by the appropriate offset, is echoed. When the number of packets per RTT is so low that all packets carry a non-CLR receiver’s timestamp,

54、 the CLR’s timestamp and ID are included in a data packet at least once per feedback round.</p><p>　　4. Data Receiver Protocol</p><p>　　Receivers measure the current network conditions, namely R

55、TT and loss event rate, and use this information to calculate a rate that is fair to competing traffic. The rate is then communicated to the sender in receiver reports. Due to the potentially large number of receivers, i

56、t is undesirable that all receivers send reports, especially not at the same time.</p><p>　　In the description of the receiver functionality, we will first address how the receivers measure the network param

57、eters and then discuss the feedback process.</p><p>　　4.1. Receiver Initialization</p><p>　　The receiver is initialized when it receives the first data packet. The RTT is set to the maximum RTT

58、 value contained in the data packet. This initial value is used as the receiver’s RTT until the first real RTT measurement is made. The loss event rate is initialized to 0. Also, the flags receiver_leave, have_RTT , and

59、 have_loss are cleared.</p><p>　　4.2. Receiver Leave</p><p>　　A receiver that sends feedback but wishes to leave the TFMCC session within the next feedback round may indicate the pending leave b

60、y setting the receiver leave flag in its report. If the leading receiver is the CLR, the receiver leave flag should be set for all the reports within the feedback round before the leave takes effect.</p><p>

61、　　4.3. Measurement of the Network Conditions</p><p>　　Receivers have to update their estimate of the network parameters with each new data packet they receive.</p><p>　　5. Calculation of the Lo

62、ss Event Rate</p><p>　　Obtaining an accurate and stable measurement of the loss event rate is of primary importance for TFMCC. Loss rate measurement is performed at the receiver, based on the detection of lo

63、st or marked packets from the sequence numbers of arriving packets.</p><p>　　6. Security Considerations</p><p>　　TFMCC is not a transport protocol in its own right, but a congestion control mech

64、anism that is intended to be used in conjunction with a transport protocol. Therefore security primarily needs to be considered in the context of a specific transport protocol and its authentication mechanisms. Congestio

65、n control mechanisms can potentially be exploited to create denial of service. This may occur through spoofed feedback. Thus any transport protocol that uses TFMCC should take care to ensure that fee</p><p>

66、　　Congestion control mechanisms may potentially be manipulated by a greedy receiver that wishes to receive more than its fair share of network bandwidth. However, in TFMCC a receiver can only influence the sending rate i

67、f it is the CLR and thus has the lowest calculated rate of all receivers. If the calculated rate is then manipulated such that it exceeds the calculated rate of the second to lowest receiver, it will cease to be CLR. A g

68、reedy receiver can only significantly increase then transmissi</p><p>　　It is possible that a receiver sends feedback claiming it has a very low calculated rate. This will reduce the rate of the multicast se

69、ssion and might render it useless but obviously cannot hurt the network itself.</p><p>　　We expect that protocols incorporating ECN with TFMCC will also want to incorporate feedback from the receiver to the

70、sender using the ECN nonce [13]. The ECN nonce is a modification to ECN that protects the sender from the accidental or malicious concealment of marked packets.</p><p>　　Again, the details of such a nonce wo

71、uld depend on the transport protocol, and are not addressed in this document.</p><p>　　TCP友好的多播擁塞控制協(xié)議: 協(xié)議規(guī)范</p><p><b>　　引言</b></p><p>　　本文闡述了TCP友好多播擁塞控制(TFMCC)。TFMCC是一個(gè)以

72、源代碼為基礎(chǔ), 建立在單播TCP友好率控制機(jī)制(TFRC)基礎(chǔ)上的單頻擁塞控制方案。TFMCC是穩(wěn)定的并且在大范圍的網(wǎng)絡(luò)條件和規(guī)模下響應(yīng)一個(gè)接收器發(fā)送到幾千個(gè)接收器。為了支持可伸縮性,應(yīng)該設(shè)立盡可能多的多功能擁塞控制位于接收器附近。每個(gè)接收機(jī)不斷決定一個(gè)滿足需求的從發(fā)送方到接收方的TCP友好路徑作為接受頻率。然后由被選擇的接收器通過(guò)反饋數(shù)據(jù)包來(lái)報(bào)告發(fā)送者相應(yīng)的速率。</p><p>　　根據(jù)RFC 3048中的定

73、義TFMCC是一個(gè)構(gòu)建塊。本文只是闡述了一個(gè)可用于傳輸規(guī)范的擁塞控制機(jī)制而不是闡述一個(gè)完整的規(guī)范,如RTP,將端到端的擁塞控制在應(yīng)用級(jí)別的運(yùn)用。本文不討論數(shù)據(jù)包格式、可靠性、或執(zhí)行相關(guān)的問(wèn)題。</p><p>　　當(dāng)爭(zhēng)奪帶寬與TCP流時(shí)，TFMCC的設(shè)計(jì)是公平合理的。如果它的發(fā)送速率通常是在一個(gè)TCP流中兩個(gè)在同樣的網(wǎng)絡(luò)環(huán)境下從發(fā)送方發(fā)送到最慢的接收機(jī)的多播組下兩發(fā)送速率中的一個(gè)因子，那么這個(gè)多播流量是“公平合理

74、”的。</p><p>　　一般來(lái)說(shuō), TFMCC有一個(gè)低變化的吞吐量,這使它適合應(yīng)用程序，如流媒體中一個(gè)相對(duì)平穩(wěn)發(fā)送率是重要的。要使公平競(jìng)爭(zhēng)的帶寬條件下?lián)碛泄饣耐掏铝?，其代價(jià)是一個(gè)減少對(duì)于可用帶寬變化的反應(yīng)。因此特別是當(dāng)應(yīng)用程序要求光滑的吞吐量時(shí)，TFMCC應(yīng)該被使用, 應(yīng)避免減半發(fā)送速率作為一個(gè)單一丟包的回應(yīng)。對(duì)于那些多播中在短期內(nèi)只需要盡可能多數(shù)據(jù)的應(yīng)用程序，PGMCC可能更合適。</p>

75、<p><b>　　協(xié)議概述</b></p><p>　　TFMCC把TFRC的基本機(jī)制擴(kuò)展到了多播域。為了與TCP公平競(jìng)爭(zhēng),TFMCC接收器單獨(dú)測(cè)量普遍的網(wǎng)絡(luò)條件以及從發(fā)送方到他們自己的TCP友好路徑中的計(jì)算速度。這個(gè)速率是由使用一個(gè)大致描述TCP作為一個(gè)損失事件率函數(shù)的發(fā)送速度方程的TCP吞吐量，往返時(shí)間(RTT),和包的大小確定的。我們定義一個(gè)事件為損失事件當(dāng)一個(gè)或多個(gè)丟失或

76、在一個(gè)往返時(shí)間內(nèi)數(shù)據(jù)包中接收到的標(biāo)記的數(shù)據(jù)包，一個(gè)標(biāo)記的數(shù)據(jù)包，是指顯式擁塞通知（ECN）中的擁塞指示。多播傳輸速率的發(fā)送速率是適應(yīng)接收器經(jīng)歷的最嚴(yán)重的網(wǎng)絡(luò)條件。</p><p>　　基本上,TFMCC的擁塞控制機(jī)制的工作方式如下:</p><p>　　每個(gè)接收機(jī)測(cè)量損害的事件的發(fā)生率和給發(fā)送者的RTT。</p><p>　　然后每個(gè)接收機(jī)利用此信息,加上TCP吞吐

77、量的一個(gè)方程,來(lái)獲得一個(gè)TCP友好發(fā)送速率。</p><p>　　通過(guò)分布式反饋抑制機(jī)制,只有一個(gè)接收器的子集被允許反饋來(lái)防止發(fā)送者的反饋內(nèi)爆。反饋機(jī)制確保接收器報(bào)告一個(gè)低期望的傳輸速率能有一個(gè)高概率發(fā)送反饋。</p><p>　　接收器的反饋不抑制把計(jì)算出的傳輸速度報(bào)告回給那些所謂接收?qǐng)?bào)告的發(fā)送方。接收者報(bào)告有兩個(gè)目的:他們通知發(fā)送方關(guān)于適當(dāng)?shù)膫鬏斔俾室约八麄冊(cè)试S接收方來(lái)測(cè)量他們的RTT

78、。</p><p>　　發(fā)送方選擇報(bào)告速率最低的限流接收機(jī)(CLR)作為接收器。每當(dāng)反饋伴隨著一個(gè)更低的速率到達(dá)發(fā)件人時(shí),相應(yīng)的接收機(jī)變成CLR同時(shí)發(fā)送速率降低來(lái)匹配接收機(jī)的計(jì)算速度。當(dāng)CLR報(bào)告計(jì)算率高于當(dāng)前的發(fā)送率時(shí)發(fā)送速率增加。</p><p>　　TFMCC的動(dòng)力對(duì)于測(cè)量是如何表現(xiàn)和應(yīng)用以及選擇哪種反饋抑制機(jī)制是敏感。我們建議下面具體機(jī)制來(lái)執(zhí)行并應(yīng)用這些測(cè)量。其他機(jī)制是可能的,但是

79、理解動(dòng)力學(xué)機(jī)制影響TFMCC之間相互作用是很重要的。</p><p><b>　　數(shù)據(jù)發(fā)送協(xié)議</b></p><p>　　數(shù)據(jù)發(fā)送方以可控速度多播發(fā)送一連串的數(shù)據(jù)包到數(shù)據(jù)接收器。每當(dāng)收到反饋時(shí),發(fā)送方檢查是否有必要切換CLRs和調(diào)整發(fā)送速率。</p><p>　　必須由TFMCC發(fā)送方提供的主要任務(wù)有:</p><p>

80、;<b>　　1.調(diào)整發(fā)送速率。</b></p><p>　　2.控制接收器反饋。</p><p>　　3.輔助接收機(jī)側(cè)的RTT測(cè)量。</p><p><b>　　3.1發(fā)送方初始化</b></p><p>　　在發(fā)送方初始化過(guò)程中,最大RTT被設(shè)定的值應(yīng)該大于任何接收器最高的RTT。在操作在公共互

81、聯(lián)網(wǎng)時(shí)它不應(yīng)小于500毫秒。發(fā)送速率X初始化設(shè)定為1包每最大RTT。</p><p>　　3.2確定最大RTT</p><p>　　對(duì)于每個(gè)到達(dá)發(fā)件人的反饋數(shù)據(jù)包,發(fā)送方計(jì)算來(lái)自接收方的瞬時(shí)RTT：</p><p>　　R_r = ts_now - ts_i’</p><p>　　ts_now是反饋數(shù)據(jù)包到達(dá)的時(shí)間。接收機(jī)將調(diào)整ts_i在接收

82、上一個(gè)數(shù)據(jù)包并發(fā)送相應(yīng)的報(bào)告的時(shí)間間隔，這個(gè)間隔將不包括在r_r之間的時(shí)間間隔。如果實(shí)際RTT小于時(shí)間戳的分辨率和ts_now=ts_i’，那么r_r被設(shè)置為最小的正數(shù)RTT值大于0（在本文中即1毫秒）。如果瞬時(shí)RTT大于當(dāng)前最大的RTT，最大的RTT將增加到r_max = r_r，否則，如果在反饋輪中沒有反饋超過(guò)最大RTT的瞬時(shí)RTT，最大的RTT減少到r_max = max（r_max×0.9，r_peak），r_peak

83、是反饋輪中接收器RTT的測(cè)量峰值。</p><p>　　最大的RTT主要用于反饋抑制的異構(gòu)接收器之間的往返時(shí)間。反饋抑制是緊密耦合的發(fā)送數(shù)據(jù)包，因此，最大的RTT不低于連續(xù)的數(shù)據(jù)包之間的最大時(shí)間間隔：r_max = max（r_max，8S / x + ts_gran）ts_granis是發(fā)送者的系統(tǒng)時(shí)鐘的粒度。</p><p><b>　　3.3調(diào)整發(fā)送速率</b>

84、</p><p>　　當(dāng)一個(gè)反饋包從接收器R到達(dá)發(fā)件人時(shí),發(fā)送方必須檢查它是否有必要調(diào)整傳輸速率和切換到一個(gè)新的CLR。如何調(diào)整速率取決于預(yù)期接收機(jī)報(bào)告的速率X_ r。我們區(qū)分一下4種情況:</p><p>　　1.如果沒有CLR,接收機(jī)r成為限流接收機(jī)。只要這結(jié)果小于8 s / R_max/秒(即。1包/ r_ max)的增加速率，發(fā)送速率X可直接設(shè)置為x_ r。否則在不超過(guò)8 / r_

85、max比特/秒每r_maxseconds增加率下X將逐步上升到X_ r。</p><p>　　2.如果接收器r不是CLR但是CLR存在,那么如果X_ r小于當(dāng)前發(fā)送速率X并且接收機(jī)的報(bào)告receiver_leave標(biāo)志沒有設(shè)置時(shí)，接收機(jī)r成為當(dāng)前限制接收機(jī)。此外,發(fā)送速率減少到x_ r。</p><p>　　3.如果接收器r不是CLR但是CLR存在并且CLR的receiver_leave標(biāo)

86、志的最后報(bào)告已經(jīng)定下,那么接收機(jī)r成為當(dāng)前限制接收機(jī)。但是,如果r > X，那么在反饋期間發(fā)送速率沒有增加到X _r來(lái)允許其他(低利率)接收器給予反饋并且被選為CLR。</p><p>　　4.如果接收器r是CLR,發(fā)送速率設(shè)置為最小的X_ r和X +8 s / R_max/秒。如果接收器尚未測(cè)量其RTT但已經(jīng)經(jīng)歷了包丟失(在接收機(jī)的報(bào)告指定的相應(yīng)標(biāo)志),接收方報(bào)告將包括一個(gè)基于最大RTT而不是實(shí)際的RTT

87、的所需速度給接收機(jī)。在這種情況下,發(fā)送方使用其測(cè)量接收機(jī)的瞬時(shí)RTT r_ r來(lái)調(diào)整所需的速度。</p><p>　　X _r ' = x_ r * r_ max / R_ r</p><p>　　X_ r '然后以此來(lái)代替X_r來(lái)檢測(cè)是否要切換到一個(gè)新的CLR。</p><p>　　如果TFMCC發(fā)送方?jīng)]有從CLR 4實(shí)時(shí)傳輸系統(tǒng)收到報(bào)告,發(fā)送率將

88、減少一半除非CLR被選小于前10個(gè) RTT。此外,如果發(fā)送方?jīng)]有從CLR收到至少10RTT的報(bào)告,它假設(shè)CLR被毀了或離開團(tuán)體了。一個(gè)新的CLR將從反饋被選出來(lái),隨后到達(dá)發(fā)送方, 增加如同上述例子3。</p><p>　　如果沒有新的CLR可以選擇(即在沒有任何接收器的任何反饋)有必要進(jìn)一步減少發(fā)送速率。每10連續(xù)RTT沒有反饋,發(fā)送率減少一半。這個(gè)速率最多減少到一個(gè)包每8秒。注意,當(dāng)接收器停止接收數(shù)據(jù)包,他們會(huì)

89、停止發(fā)送反饋。最終使發(fā)送的發(fā)送速率減少來(lái)防止網(wǎng)絡(luò)故障。如果網(wǎng)絡(luò)隨后恢復(fù)了, CLR將線性提高計(jì)算速度變成8 s / R_max/秒每R_max。</p><p>　　3.4協(xié)助接收機(jī)測(cè)RTT量</p><p>　　接收器通過(guò)在接收機(jī)的報(bào)告中發(fā)送一個(gè)時(shí)間戳來(lái)衡量他們的RTT,它是呼應(yīng)發(fā)送方的。如果擁塞控制信息捎帶到數(shù)據(jù)包,通常只包含一個(gè)接收機(jī)ID和時(shí)間戳。如果多個(gè)反饋信息在兩個(gè)數(shù)據(jù)包的時(shí)間間

90、隔期間從不同的接收器到達(dá)發(fā)件人,發(fā)送方必須決定哪個(gè)接收器允許測(cè)量RTT。同樣如果單獨(dú)的擁塞控制消息允許同時(shí)呼應(yīng)多個(gè)接收器的時(shí)間戳但接收器，自上次的擁塞控制給予反饋消息超過(guò)了列表的大小的數(shù)目。</p><p>　　發(fā)送方的時(shí)間戳的反響是優(yōu)先按照以下順序:</p><p>　　1．一個(gè)新的CLR(改變后的CLR)或一個(gè)CLR沒有先前測(cè)量過(guò)任何RTT</p><p>　　

91、2．接收器為了報(bào)告圓形回音的反饋沒有做過(guò)任何先前的RTT測(cè)量 (即：年長(zhǎng)的反饋)</p><p>　　3．非CLR接收器與先前的RTT測(cè)量,再以升序排序的反饋報(bào)告的圓形回音</p><p>　　4．CLR鏈為了支持接收機(jī)與最低的報(bào)道率而破壞。</p><p>　　有必要考慮到接收和發(fā)送下一份報(bào)告數(shù)據(jù)包之間的時(shí)間間隔。需要扣除RTT的時(shí)間,因此必須添加到接收器的時(shí)間戳

92、值。</p><p>　　每當(dāng)沒有任何反饋數(shù)據(jù)包在間隔兩個(gè)數(shù)據(jù)包之間到達(dá)時(shí)，CLR的最后一個(gè)時(shí)間戳，通過(guò)適當(dāng)?shù)钠普{(diào)整，回蕩。當(dāng)每RTT的數(shù)據(jù)包數(shù)量太低使得所有的數(shù)據(jù)包帶來(lái)一個(gè)非CLR接收機(jī)的時(shí)間戳，每一輪的反饋中CLR的時(shí)間戳和ID都至少一次包含在一個(gè)數(shù)據(jù)包中。</p><p><b>　　4．?dāng)?shù)據(jù)接收協(xié)議</b></p><p>　　接收器

93、測(cè)量電流的網(wǎng)絡(luò)條件下,即RTT和損失事件率,并使用這個(gè)信息來(lái)計(jì)算的速度是公平競(jìng)爭(zhēng)的。然后速率以接受報(bào)告的形式和發(fā)送方交流。由于潛在大量的接收器,讓所有接收器發(fā)送報(bào)告是不可取的,尤其是在同一時(shí)間。</p><p>　　在描述接收機(jī)的功能方面,我們將首先考慮接收器如何測(cè)量網(wǎng)絡(luò)參數(shù)并且討論反饋過(guò)程。</p><p><b>　　4.1接收機(jī)初始化</b></p>

94、<p>　　接收方當(dāng)它接收到第一個(gè)數(shù)據(jù)包時(shí)開始初始化。這個(gè)RTT設(shè)置為包含在數(shù)據(jù)包中的最大RTT值。這個(gè)初始值用作接收器的RTT直到得到第一個(gè)真正的RTT測(cè)量數(shù)值。造成損害的事件的發(fā)生速率被初始化為0。同時(shí)receiver_leave, have_RTT 和 have_loss被清除。</p><p>　　一個(gè)接收器發(fā)送反饋但希望離開可以再接下來(lái)的反饋源TFMCC會(huì)話通過(guò)在其報(bào)告中設(shè)置接收器表明即將

95、離開。如果離開的接收機(jī)是CLR, 接收器的離開標(biāo)志應(yīng)設(shè)置為反饋輪內(nèi)所有的報(bào)告離開前生效。</p><p>　　4.3測(cè)量的網(wǎng)絡(luò)環(huán)境</p><p>　　接收器必須與每一個(gè)收到的新數(shù)據(jù)包更新其估計(jì)的網(wǎng)絡(luò)參數(shù)。</p><p>　　5．計(jì)算損失事件速率</p><p>　　對(duì)TFMCC來(lái)說(shuō)獲得一個(gè)準(zhǔn)確和穩(wěn)定的測(cè)量的損失事件率是頭等重要的。虧損率測(cè)

96、量是基于從順序到達(dá)的數(shù)據(jù)包中檢測(cè)丟失的或者標(biāo)記的序列號(hào)在接收機(jī)中進(jìn)行的。</p><p><b>　　6．安全注意事項(xiàng)</b></p><p>　　TFMCC不是一個(gè)以自己權(quán)利為核心的傳輸協(xié)議,但它是一個(gè)與傳輸協(xié)議結(jié)合使用的擁塞控制機(jī)制。因此安全主要是需要考慮上下文中的一個(gè)特定的傳輸協(xié)議以及它的權(quán)威驗(yàn)證機(jī)制。擁塞控制機(jī)制可能被利用來(lái)創(chuàng)建拒絕服務(wù)。這可能通過(guò)欺騙發(fā)生反饋

97、。因此任何使用TFMCC的傳輸協(xié)議應(yīng)該注意確保反饋只接受接收者的有效數(shù)據(jù)。但是實(shí)現(xiàn)這一目標(biāo)取決于傳輸協(xié)議本身的精確性。</p><p>　　擁塞控制機(jī)制可能是被一個(gè)希望獲得超過(guò)其公平份額的網(wǎng)絡(luò)帶寬的貪婪的接收機(jī)控制。然而, 在TFMCC中如果是CLR接收方可以只影響發(fā)送速率，因此在所有計(jì)算接收器中有最低速率。如果計(jì)算速率超過(guò)第二計(jì)算率最低的接收機(jī)，它將不再是CLR。一個(gè)貪婪的接收器如果是會(huì)話中唯一的參與者則只可以

98、顯著增加傳輸速率。如果這種情況被關(guān)注，可能對(duì)這種接收機(jī)的防御通常包括某種形式的杜撰，接收器必須反饋到發(fā)送者證明收到。然而,這樣的細(xì)節(jié)目前將取決于傳輸協(xié)議,特別是是否傳輸協(xié)議是可靠的和不可靠的。</p><p>　　有可能一個(gè)接收器發(fā)送反饋聲稱它有一個(gè)非常低的計(jì)算速度。這將降低組播會(huì)話的速率并且可能不起作用,但顯然不能傷害網(wǎng)絡(luò)本身。</p><p>　　我們預(yù)計(jì)，協(xié)議ECN與TFMCC協(xié)議也

99、將要利用從接收方到發(fā)送方的反饋來(lái)使用ECN。這個(gè)ECN是一個(gè)修改ECN的現(xiàn)實(shí)標(biāo)志來(lái)保護(hù)發(fā)送方不受意外或惡意的隱蔽的數(shù)據(jù)包的侵害。</p><p>　　再次，這種現(xiàn)實(shí)細(xì)節(jié)將會(huì)取決于傳輸協(xié)議，并沒有在本文中處理。</p><p>　　作者：Joerg Widmer ，DoCoMo歐洲實(shí)驗(yàn)室</p><p>　　地址：蘭茨貝格爾大街312號(hào),德國(guó)慕尼黑 widmer@ac

100、m.org</p><p>　　A Simple And Effective Single-Rate Multicast Congestion Control Scheme</p><p>　　Jiang Li, Shivkumar Kalyanaraman</p><p>　　Rensselaer Polytechnic Institute, 110 8th St

101、reet, Troy, NY12180</p><p>　　Abstract— Owing to the simplicity and ease of deployment, single-rate multicast congestion control is worthy of further exploration. In this article, we propose a new single-rate

102、 multicast congestion control scheme called ORMCC based on a new metric, TRAC (Throughput Rate At Conges-tion). The scheme is simple: states maintained at source and receivers are O(1); only simple computation is require