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(_dot_)Vainshtein(_at_)ecitele(_dot_)com
Mobile: 054-9266302
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Scott Brim
Sent: Tuesday, January 14, 2014 5:39 PM
To: Eggert, Lars
Cc: mpls(_at_)ietf(_dot_)org; 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(_at_)netapp(_dot_)com>
wrote:
Hi,
On 2014-1-14, at 16:23, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls