Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPL

On 1/14/14, 7:29 AM, Eggert, Lars 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.
There seems assertion on the part of transport that tunnel endpoints
should be aware of congestion on intermediate hops. This seems to be the
assertion here, it certainly is with respect to AMT.  This  certainly
not a property that we demand of routers in other contexts.

my observations

  These tunnels are stateless

  The endpoints not the encapsulators have visibility into the
end-to-end loss
  latency properties of the path.

  the encapsulator is an intermediate hop, similar to any other router
in the path.


> Lars

signature.asc
Description: OpenPGP digital signature