Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt

Joe Touch <touch@isi.edu> Mon, 28 March 2016 21:27 UTC

Return-Path: <touch@isi.edu>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5312D116; Mon, 28 Mar 2016 14:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 4NucbIFEprS1; Mon, 28 Mar 2016 14:27:50 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2400512D0BD; Mon, 28 Mar 2016 14:27:50 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u2SLQpcc024245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Mar 2016 14:26:54 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
References: <A741874C-0E2C-4905-9FD3-D29B4B94A9C0@ifi.uio.no> <56F3212B.5020408@isi.edu> <20F3E6FF-DED4-46BD-BFD5-C76F8A6A8D40@ifi.uio.no> <56F32C47.6080707@isi.edu> <271375F3-2B9D-4C61-9C6E-468E6423A1A4@ifi.uio.no> <56F427D9.9030208@isi.edu> <C6E55B03-FD33-4EAB-B814-8A4C3E9657EA@ifi.uio.no> <56F5538D.3040408@gmail.com> <CALx6S34n8iz4KgZeop3TRqJWtHR=eAOt37=s7K8aZKy388Hkhg@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <56F9A19B.9010702@isi.edu>
Date: Mon, 28 Mar 2016 14:26:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CALx6S34n8iz4KgZeop3TRqJWtHR=eAOt37=s7K8aZKy388Hkhg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/LRydvTjX3V8087GwynhvnVF8FeE>
Cc: stackevo-discuss@iab.org, "nvo3@ietf.org" <nvo3@ietf.org>, touch@isi.edu
Subject: Re: [Stackevo-discuss] New Version Notification for draft-welzl-irtf-iccrg-tcp-in-udp-00.txt
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2016 21:27:52 -0000


On 3/25/2016 10:05 AM, Tom Herbert wrote:
>> On another hand, this problem of multiplexing at multiple levels makes
>> > it that there is no 'traceroute' program that meaningfully reports
>> > number of hops through tunnels.  This is a universal tool for network
>> > debugging, maybe as loved as ping is.
>> >
> I believe https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-01
> is the proposed solution for that.

I would not recommend that doc as an example of how to handle this issue
- it has more than a few issues:

- the reason that IP hopcounts of payloads should not be decremented in
a tunnel is because hopcount is a measure of time at routers, not time
in links. Because a tunnel is a link, the encapsulated packets
experience no forwarding themselves. This has nothing to do with whether
the source and dest IP are in the same IP subnet (end Sec 1).

- TTLs are decremented when forwarding; it makes no sense to decrement
the outer TTL upon encapsulation. That decrement happens later in the
path inside the tunnel. Otherwise, a packet whose hopcount is 0 might be
discarded at the ingress, even though it can legitimately reach its
destination over the tunnel link.

- The decrement of the inner packet might be done to correspond to the
cost of the link itself, as noted. In that case, the error goes back to
the inner packet's source host -- never to the tunnel ingress. ICMPs go
to the tunnel ingress if the encapsulation header TTL falls below zero
along the tunnel path only.

- RFC1122 does not ensure that there is enough information to relay
tunnel ICMPs back to the origin source. Packets could be fragmented to
traverse the tunnel (lacking an inner header altogether) or could have
too much encapsulation to allow that.

These issues are all discussed in intarea-tunnels, which should have
been cited there. FWIW.

Joe