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

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Wed, 22 January 2014 14:48 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 CFDE71A0113; Wed, 22 Jan 2014 06:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 57E7xIgE6j7u; Wed, 22 Jan 2014 06:48:11 -0800 (PST)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A94ED1A014B; Wed, 22 Jan 2014 06:48:10 -0800 (PST)
Received: by mail-oa0-f43.google.com with SMTP id h16so529625oag.30 for <multiple recipients>; Wed, 22 Jan 2014 06:48:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cSOPjB8N1Xa9jg5gO0+Pl1i9QqB3QlrEXfOCpxkD8q4=; b=iUAoblElrl8dMmEVwYfMu9/FZs2tzddvvfdns1uCvURIFZdOKA+4uD0ptXqocl3rDl iNuRDekWYe9MiJRKXOAJ/9mpwlYiPY+rHJBA6KVcSg/aqYi+HAvIOqwEo7drIOtVaElc dcP0ISNMnq3ooSkzBBh0uAkRUIuNuyScTOGzuBmBdNm5dzxLyFd9bPO1Ztc9Rc+UF3BW C32zN4PfrEjOkXpBK4MR8lv6veLVU9BcJzso9zMlpeKnO9MGF3m5yNncmCtvJsvPUFOR jxVKHpPWxBFZYg0ALKOkDTUNGYB9uUY2sm3Bs/qe77c2Dd5fYKLwlGK32sC5NKdPnM69 9KVw==
X-Received: by 10.182.22.33 with SMTP id a1mr1620189obf.60.1390402090123; Wed, 22 Jan 2014 06:48:10 -0800 (PST)
Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id oo13sm39900310oeb.0.2014.01.22.06.48.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 06:48:09 -0800 (PST)
Message-ID: <52DFDA26.2070103@gmail.com>
Date: Wed, 22 Jan 2014 08:48:06 -0600
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Scott Brim <scott.brim@gmail.com>, Ross Callon <rcallon@juniper.net>
References: <20140102151419.4692.48031.idtracker@ietfa.amsl.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> <52D5568F.2070600@joelhalpern.com> <3D9BA53E-F0F7-4B8B-8433-4DFE6852AF87@netapp.com> <52D811A2.9070606@bogus.com> <7865A4F7-F142-43FA-9E6B-94912F1BDC3A@netapp.com> <491c4cdfce7e4d688f8c054553901f39@CO2PR05MB636.namprd05.prod.outlook.com> <52DF1AC4.7080007@isi.edu> <c3c178b033114a4eba7c226293f451c1@CO2PR05MB636.namprd05.prod.outlook.com> <CAPv4CP9UJxf+w6yOwVq9=nDmig=br4x1qD3_sJpz+WpHaDd+Kw@mail.gmail.com>
In-Reply-To: <CAPv4CP9UJxf+w6yOwVq9=nDmig=br4x1qD3_sJpz+WpHaDd+Kw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 23 Jan 2014 10:57:52 -0800
Cc: "mpls@ietf.org" <mpls@ietf.org>, 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: Wed, 22 Jan 2014 14:48:13 -0000

For what it's worth ...

On 01/21/2014 10:03 PM, Scott Brim wrote:
> On Tue, Jan 21, 2014 at 9:40 PM, Ross Callon <rcallon@juniper.net> wrote:
>> If the upper layers (the thing that runs over the tunnel) involves applications over TCP over IP, or if it is otherwise responding to congestion in the same way that we expect anything running over IP to respond to congestion, then we don't want the tunnel to also independently try to respond to congestion (two independent cooks cooking the same meal does not necessarily lead to success).
>>
>> If the upper layer does not respond to congestion, then perhaps it shouldn't be running over the open Internet (with or without a tunnel), unless the *total* bandwidth that could be used is inherently quite low. On the other hand, it might want to run within a data center or internally to a service provider network with appropriate provisioning.
> To paraphrase: if this problem exists in the new encapsulation, then
> it exists already.
>
> Lars is right, this does allow traffic that was formerly run over
> provisioned paths in well-managed networks to possibly be part of
> general Internet traffic. It would be good if there were a way to be
> _sure_ there was e2e congestion control. But there is no signaling
> between this low-layer UDP encapsulation and anything above it that
> might already be reacting to congestion. There is no reasonably easy
> way for it to know what it is carrying. Yes there is a way to do
> congestion control at the bottom layer, but doing so could destroy
> performance if one (or more) layer(s) is already doing it up above. We
> have experience with that.
>
> I can't remember who said it, but an applicability statement might
> satisfy everyone, especially since it's been said (Curtis?) that this
> just isn't going to be used in situations where congestion will be a
> problem.

Alia Atlas made this suggestion.

Speaking as an AD who has been following this conversation with some 
interest ... that's gotta help.

> Alternatively, a paragraph laying out the problem and saying if this
> is used in a way that could impact ordinary traffic, a mechanism must
> be defined.

I would read such a paragraph with some interest ...

Spencer