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

Lloyd,

Suggesting MPLS over TCP brings us back to the X.25 comment.

You can do PPP in TCP.  It has the benefit of getting a tunnle past
firewalls.  It has the drawback of TCP over IP over PPP over TCP where
the upper and lower TCPs don't know about each other and interact,
with the upper TCP doing redundant retransmits and a lot of
unnecessary retransmits when the lower TCP is stalled.  As a host
solution this particular tunnel over TCP serves a purpose.

As a router solution, a tunnel over TCP would cause massive redundant
or unnecessary retransmits due to lots of TCP running over it unaware
that retransmits are occurring at a lower layer.

Another problem is the TCP state that would have to be held in
hardware.  Normally the router functions that use TCP are in the
control plane and in software.  All packets would also have to be
bufferred in hardware until acknowledged.

There are the save feasibility issues with a TCP checksum in most high
end hardware.

MPLS over TCP would likely be only feasible if done in software and
therefore is not an appropriate solution for the deployment scenarios
considered for MPLS over UDP.

There are congestion control mechanisms that would be feasible for
MPLS over UDP but mostly involve feedback, the programming of a leaky
bucket, aka traffic shaper, and (preferably) some form of AQM on the
shaper queue.  This would involve no retransmissions and use the types
of hardware building blocks available in forwarding chips.

Curtis

In message <290E20B455C66743BE178C5C84F1240847E63346CA@EXMB01CMS.surrey.ac.uk>
l.wood@surrey.ac.uk writes:
> 
> this draft should be about mpls in TCP - a TCP tunnel.
>  
> That will fix all congestion concerns.
>  
> I look forward to reading justification of why TCP checksums can be turned off.
>  
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: mpls [mpls-bounces@ietf.org] On Behalf Of Curtis Villamizar [curtis@ipv6.occnc.com]
> Sent: 15 January 2014 01:00
> To: Eggert, Lars
> Cc: mpls@ietf.org; Scott Brim; IETF discussion list
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>  (Encapsulating MPLS in UDP) to Proposed Standard
>  
> In message <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com>
> "Eggert, Lars" writes:
>  
> > Hi,
> >
> > On 2014-1-14, at 16:23, Joel M. Halpern <jmh@joelhalpern.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
> > L2traffic, for an L2 where that is OK behavior. But that traffic is
> > nowbeing encapsulated inside UDP and can hence go anywhere on the
> > net*without the sender being aware of this*.
>  
> That application would be a PW application and it would be more
> appropriate to fix that in PW if there is consensus for a need to do
> so, which afaik there is not.
>  
> > > Asking tunnel's to solve the problem of applications with
> > > undesirablebehavior seems backwards.
> >
> > It is the *tunnel* that performs the encapsulation and allows
> > thattraffic to go places it couldn't before. And so it's the
> > tunnel'sresponsibility to make sure that the traffic it injects into
> > theInternet complies with the BCPs we have on congestion control.
> >
> > Lars
>  
> If it is a service provider encapsulating traffic within their own
> network, then they know what they are doing.  That is the anticipated
> use and among that community there is no consensus for need for
> congestion control.
>  
> If it is some hostile hosts trying to send MPLS over UDP over IP,
> they, being hostile, are going to disable any congestion control.
> Besides, no hostile host has a T1 to tunnel over the Internet so they
> would be sending the same traffic they would normally just send of UDP
> over IP.
>  
> Anything made up of frames (Ethernet, ATM, FR) over PW over MPLS is
> carrying IP and if frames drop, the IP applications see the drop and
> behave just as they would for any drop.  (ATM shreadding thread to
> /dev/null please).
>  
> If congestion aware or using a congestion aware transport, the top
> level applications are still congestion aware.  If congestion
> ignoreant, they are still congestion ignoreant.  If hostile, they are
> still hostile.
>  
> Back to draft-ietf-mpls-in-udp.  I think the most recent text proposed
> by the author is fine.
>  
> Curtis
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls