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:46 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 0B7541AE1C9; Tue, 14 Jan 2014 16:46:42 -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 RS8B2miUdmOu; Tue, 14 Jan 2014 16:46:41 -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 BA3E81AE1B0; Tue, 14 Jan 2014 16:46:40 -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 s0F0kQr8005435; Tue, 14 Jan 2014 19:46:26 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401150046.s0F0kQr8005435@maildrop2.v6ds.occnc.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Tue, 14 Jan 2014 10:23:59 -0500." <52D5568F.2070600@joelhalpern.com>
Date: Tue, 14 Jan 2014 19:46:26 -0500
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Eggert, Lars" <lars@netapp.com>, IETF discussion list <ietf@ietf.org>, Scott Brim <scott.brim@gmail.com>
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:46:42 -0000

In message <52D5568F.2070600@joelhalpern.com>
"Joel M. Halpern" writes:
 
> Isn't that basically the problem of the inner traffic sender, not the 
> problem of the tunnel that is carrying the traffic?
> Asking tunnel's to solve the problem of applications with undesirable 
> behavior seems backwards.
>  
> Yours,
> Joel


Or perhaps the job of some form of very fair AQM like SFQ.

Any tunneling complicates the AQM notion of what a flow is and
therefore may affect its assessment of what is fair in bad ways.

This too is out of scope for a draft-ietf-mpls-in-udp discussion.

Curtis


> On 1/14/14 10:20 AM, Eggert, Lars wrote:
> > 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

v2.23.0 | Report a Bug | By Email