IETF Logo Mail Archive

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

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 14 January 2014 15:24 UTC

Return-Path: <jmh@joelhalpern.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 EBEEB1ADFB6; Tue, 14 Jan 2014 07:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pr7SUocXc_io; Tue, 14 Jan 2014 07:24:26 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A08111ADFAA; Tue, 14 Jan 2014 07:24:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9EE901BD695C; Tue, 14 Jan 2014 07:24:15 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-128.clppva.east.verizon.net [70.106.135.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4824E1BD6957; Tue, 14 Jan 2014 07:24:07 -0800 (PST)
Message-ID: <52D5568F.2070600@joelhalpern.com>
Date: Tue, 14 Jan 2014 10:23:59 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "Eggert, Lars" <lars@netapp.com>, Stewart Bryant <stbryant@cisco.com>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.com> <5933BB7D-2D2D-4145-A0B2-E92C8DA25844@netapp.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08242A8E@NKGEML512-MBS.china.huawei.com> <43B89809-F517-4BE2-BE1B-748A4B78FC7F@netapp.com> <52D01383.2080509@joelhalpern.com> <8DCFAFEE-2B06-4334-A5D7-7698D8D3081A@netapp.com> <CAPv4CP-iwoHEiV=xtNAd7qT4r8OYvfE1ZjnKE=wWY5VVcQ3x8w@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0824427A@NKGEML512-MBS.china.huawei.com> <A1F82D9D-F9D0-46C1-B666-0C13DB79A845@netapp.com> <52D40B91.8040101@joelhalpern.com> <CAPv4CP9R-6Dv9O_H8Ox_-uLWMSzqpx7Gn97TF8jceFkVKPLWTw@mail.gmail.com> <52D518D9.7010703@cisco.com> <CAPv4CP-eNJuOKv4vWxGkiUPUTMkYyqY4cbTmj8M4sn+jXzmCkw@mail.gmail.com> <CAPv4CP-DnNdSoVEFTg9N53xP=yOd6pNe97WxmXJeGHBPKC2h6w@mail.gmail.com> <52D547B2.1060302@cisco.com> <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com>
In-Reply-To: <DB6CF60F-FFBA-47DA-9FD6-7288CCB260A6@netapp.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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
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: Tue, 14 Jan 2014 15:24:29 -0000

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

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