Hi Lars, > -----邮件原件----- > 发件人: Eggert, Lars [mailto:lars@xxxxxxxxxx] > 发送时间: 2014年1月10日 16:48 > 收件人: Xuxiaohu > 抄送: IETF; mpls@xxxxxxxx > 主题: Re: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) > to Proposed Standard > > Hi, > > that sounds good. What congestion control are you going to be specifying for > your tunnel? IMHO, this is a common issue with any other encapsulations for MPLS and even other applications of UDP tunnels . Of course, the following text could be added if we believe it's necessary: "...applications that uses the encapsulation as specified in this document SHOULD monitor the packet loss rate to ensure that it is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path under the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than that of the MPLS-in-UDP flow. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. In essence, this requirement states that it is not acceptable to deploy an application using the encapsulation specified in this document on the best-effort Internet, which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. One method of determining an acceptable bandwidth is described in [RFC3448]. " Best regards, Xiaohu > Lars > > On 2014-1-10, at 4:46, Xuxiaohu <xuxiaohu@xxxxxxxxxx> wrote: > > > Hi Lars, > > > > Thanks a lot for your comments. > > > > I wonder whether the following modified text for Congestion Consideration > section is OK from your point of view: > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to be forwarded > through "UDP tunnels", the congestion control guidelines for UDP tunnels as > defined in Section 3.1.3 of [RFC5405] SHOULD be followed. Specifically, MPLS > can carry a number of different protocols as payloads. When the payload traffic > is IP-based and congestion-controlled, the UDP tunnel SHOULD NOT employ its > own congestion control mechanism, because congestion losses of tunneled > traffic will already trigger an appropriate congestion response at the original > senders of the tunneled traffic. When the payload traffic is not known to be > IP-based, or is known to be IP-based but not congestion-controlled, the UDP > tunnel SHOULD employ an appropriate congestion control mechanism. > Furthermore, because UDP tunnels are usually bulk-transfer applications as far > as the intermediate routers are concerned, the guidelines as defined in Section > 3.1.1 of [RFC5405] SHOULD apply. > > > > Best regards, > > Xiaohu > > > >> -----邮件原件----- > >> 发件人: mpls [mailto:mpls-bounces@xxxxxxxx] 代表 Eggert, Lars > >> 发送时间: 2014年1月8日 18:22 > >> 收件人: IETF > >> 抄送: mpls@xxxxxxxx > >> 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > >> (Encapsulating MPLS in UDP) to Proposed Standard > >> > >> Hi, > >> > >> On 2014-1-2, at 16:14, The IESG <iesg-secretary@xxxxxxxx> wrote: > >>> - 'Encapsulating MPLS in UDP' > >>> <draft-ietf-mpls-in-udp-04.txt> as Proposed Standard > >> > >> > >> this document needs to describe how it addresses the issues raised in > >> BCP145 (RFC5405). It already contains some text about messages sizes > >> and congestion considerations, which is great. Unfortunately, the > >> text about congestion considerations is not fully in line with RFC5405. > >> > >> Lars