Lars, Scott and all,
IMHO and FWIW the problem is not between congestion control requirements being specified as SHOULD or MUST.
Specifying some functionality as SHOULD without describing (even in a non-normative way) how this functionality could be implemented because the protocol specified does not provide any hooks for it is indeed meaningless.
This is the way to guarantee that this functionality will never be implemented even if we discover that in some cases it is needed.
In the case of congestion control the minimal required hooks are:
1. Ability to detect congestion at the tail-end of the tunnel
2. Ability to pass this information to the head-end of the tunnel.
To the best of my understanding, proposed protocol does not provide any of these hooks. Hence specifying any requirements for congestion control does not make any sense to me regardless of the level of these requirements (MUST, SHOULD or MAY) - these requirements cannot be implemented without some redesign of the protocol.
I would also like to note that the declared purpose of the protocol is simplification of ECMP. One of the reasons to use ECMP is that the "fat" flow cannot get the required BW on any specific link...
Regards,
Sasha
Email: Alexander.Vainshtein@xxxxxxxxxxx
Mobile: 054-9266302
> -----Original Message-----
> From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of Scott Brim
> Sent: Tuesday, January 14, 2014 5:39 PM
> To: Eggert, Lars
> Cc: mpls@xxxxxxxx; IETF discussion list
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
>
> Lars, I know we're repeating arguments from the last decade. The choice is
> between (1) specifying congestion control around the substrate UDP that can
> be turned off if it causes problems, or (2) specifying nothing at this time and
> adding it later if operators want it.
>
> I guess if this can be written as a SHOULD, up to the implementor's
> discretion, then okay.
>
> Scott
>
> On Tue, Jan 14, 2014 at 10:29 AM, Eggert, Lars <lars@xxxxxxxxxx> wrote:
> > Hi,
> >
> > On 2014-1-14, at 16:23, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
> >> Isn't that basically the problem of the inner traffic sender, not the
> problem of the tunnel that is carrying the traffic?
> >
> > no, because the sender of the inner traffic may be blasting some L2 traffic,
> for an L2 where that is OK behavior. But that traffic is now being
> encapsulated inside UDP and can hence go anywhere on the net *without
> the sender being aware of this*.
> >
> >> Asking tunnel's to solve the problem of applications with undesirable
> behavior seems backwards.
> >
> > It is the *tunnel* that performs the encapsulation and allows that traffic to
> go places it couldn't before. And so it's the tunnel's responsibility to make
> sure that the traffic it injects into the Internet complies with the BCPs we
> have on congestion control.
> >
> > Lars
> _______________________________________________
> mpls mailing list
> mpls@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/mpls