ietf
[Top] [All Lists]

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

2014-01-16 10:08:40

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(_at_)EXMB01CMS(_dot_)surrey(_dot_)ac(_dot_)uk>
l(_dot_)wood(_at_)surrey(_dot_)ac(_dot_)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(_at_)ietf(_dot_)org] On Behalf Of Curtis Villamizar 
[curtis(_at_)ipv6(_dot_)occnc(_dot_)com]
Sent: 15 January 2014 01:00
To: Eggert, Lars
Cc: mpls(_at_)ietf(_dot_)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(_at_)netapp(_dot_)com>
"Eggert, Lars" writes:
 
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
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

<Prev in Thread] Current Thread [Next in Thread>