[mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: Scott Brim [mailto:[e-mail]]
> 发送时间: 2014年1月11日 0:32
> 收件人: Eggert, Lars
> 抄送: Joel Halpern; [e-mail]; Xuxiaohu; IETF
> 主题: Re: Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP)
> to Proposed Standard
> 
> I don't think it's right to try to solve this in MPLS, because MPLS is not a
> forwarding protocol - it's a connectivity protocol. In any use of UDP, congestion
> control is either left to something above UDP or ignored (left to queue
> management). Similarly, you want the client of MPLS to be responsible for
> managing its traffic. MPLS gives you paths, it doesn't push packets over them.

Fully agree. The congestion control should be performed either by the UDP tunnel itself or the client of MPLS. In the former case, it'd better to specify the practical congestion control mechanisms (if there were any) in a generic draft (e.g., RFC5405bis) and then any use of the UDP tunnel could refer to that generic draft with regard to congestion control. In the latter case, if the client of MPLS is TCP-friendly, that is great. Otherwise (e.g., circuit emulation service), it shouldn't be deployed on the Internet at all, just as has been pointed out in RFC3985, therefore there is no need for any specific congestion control mechanism on the client.
   
  "... In essence, this requirement states that it is
   not acceptable to deploy an application (using PWE3 or any other
   transport protocol) on the best-effort Internet, which consumes
   bandwidth arbitrarily and does not compete fairly with TCP within an
   order of magnitude." (quoted from Section 6.5 of RFC3985)

The above choice seems no conflict with the following congestion control guidelines as quoted from Section 3.1.1 of RFC5405, as those non-TCP-friendly traffic would be transported over a provisioned path, rather than on the Internet.

   "...Finally, some bulk transfer applications may choose not to implement
   any congestion control mechanism and instead rely on transmitting
   across reserved path capacity.  This might be an acceptable choice
   for a subset of restricted networking environments, but is by no
   means a safe practice for operation in the Internet."

Best regards,
Xiaohu

> Scott
> 
> 
> On Fri, Jan 10, 2014 at 11:09 AM, Eggert, Lars <[e-mail]> wrote:
> > Hi,
> >
> > On 2014-1-10, at 16:36, Joel M. Halpern <[e-mail]> wrote:
> >> Maybe I am completely missing things, but this looks wrong.
> >> If the MPLS LSP is carrying fixed rate pseudo-wires, adding
> >> congestion control will make it more likely that the service won't
> >> work.  Is that really the goal?
> >>
> >> We do not perform congestion control on MPLS LSPs.
> >> Assuming that a UDP tunnel is carrying just MPLS and was established
> >> just for MPLS, why would we expect it to behave differently than an
> >> MPLS LSP running over the exact same path, carrying the exact same traffic?
> >
> > we've been rehashing this discussion several times over the years, e.g., for
> PWE, AMT, etc. In order to carry fixed-rate or otherwise
> non-congestion-controlled traffic over unprovisioned general Internet paths,
> there needs to be some sort of basic congestion control mechanism, like a
> circuit breaker.
> >
> > The whole point of running MPLS is to create networks in which paths are
> provisionable, so this is usually not an issue. But if you start sticking MPLS inside
> of UDP, those packets can go anywhere on the net, so you need mechanisms to
> control the rate of that traffic if it causes congestion, or at the very least you
> need to be able to stop the traffic if it creates severe congestion.
> >
> > Lars