IETF Logo Mail Archive

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

Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 15 January 2014 00:40 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21FE1AE194; Tue, 14 Jan 2014 16:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8fZwABG8QJj; Tue, 14 Jan 2014 16:40:54 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10B7F1ADF47; Tue, 14 Jan 2014 16:40:53 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0F0eZXj005169; Tue, 14 Jan 2014 19:40:35 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401150040.s0F0eZXj005169@maildrop2.v6ds.occnc.com>
To: "Eggert, Lars" <lars@netapp.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Tue, 14 Jan 2014 15:20:17 +0000." <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com>
Date: Tue, 14 Jan 2014 19:40:34 -0500
Cc: "mpls@ietf.org" <mpls@ietf.org>, Scott Brim <scott.brim@gmail.com>, IETF discussion list <ietf@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 00:40:56 -0000

In message <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com>
"Eggert, Lars" writes:
 
> On 2014-1-14, at 15:20, Stewart Bryant <stbryant@cisco.com> wrote:
> > Yes, the inner (real) transport header is the only meaningful place
> > to apply congestion avoidance.
>  
> But what if the inner traffic isn't congestion controlled?
>  
> Lars


Lars,

The exact same thing will happen in all of the following cases:

  NON-congestion controlled application --over--
  UDP --over-- IP --over-- L2

  NON-congestion controlled application --over--
  UDP --over-- IP --over-- MPLS --over-- L2

  NON-congestion controlled application --over--
  UDP --over-- IP --over-- MPLS --over-- UDP --over-- IP --over-- L2

The non-congestion controlled application is what needs fixing.

It would be wrong to try to put congestion control at every layer
underneath the non-congestion controlled application except perhaps as
a transparent replacement for UDP and that is out of scope for a
draft-ietf-mpls-in-udp discussion.

Curtis

v2.23.0 | Report a Bug | By Email