Subject: Fwd: New Version Notification for draft-herbert-6man-icmp-limits-00.txt

From: Tom Herbert <[email-masked]>
Date: Mon, 8 May 2017 08:43:21 -0700

Hello,

This is a proposal for nodes (hosts or intermediate nodes) to send
ICMP errors when they drop packets because they're not able to process
headers because of processing limits.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, May 8, 2017 at 8:36 AM
Subject: New Version Notification for draft-herbert-6man-icmp-limits-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-6man-icmp-limits-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-6man-icmp-limits
Revision:       00
Title:          ICMPv6 errors for discarding packets due to processing limits
Document date:  2017-05-08
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-herbert-6man-icmp-limits-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-6man-icmp-limits/
Htmlized:       https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-6man-icmp-limits-00

Abstract:
   Network nodes may discards packets if they are unable to process
   protocol headers of packets due to processing constraints or limits.
   When such packets are dropped, the sender receives no indication so
   it cannot take action to address the cause of discarded packets. This
   document defines ICMP errors that can be sent by a node that discards
   packets because it is unable to process the protocol headers. A
   sender that receives such an ICMP error may be able to modify what it
   sends in future packets to avoid subsequent packet discards.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fred Baker <[email-masked]>
Date: Mon, 8 May 2017 12:11:48 -0700

Quick comment: The abstract talks about dropping packets due to "processing constraints", which I took to mean rate limitations (aka Source Quench), but the codes and body are about issues in extension header parsing/processing. I wonder if there is a different phrase that might be appropriate there?

> On May 8, 2017, at 8:43 AM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 May 2017 18:18:55 +0300

Tom,

I took a quick look at the draft.  The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback.  I found the text unconvincing.  I would like to hear more.

Thanks,
Bob

> On May 8, 2017, at 6:43 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 May 2017 09:59:57 -0700

> I took a quick look at the draft.  The biggest question I have have is how realistic do you think that a source host could do anything useful with this additional feedback.  I found the text unconv…
Hi Bob,

Thanks for looking at the draft!

I think the most likely first response would be to stop using
extension headers if we saw that they were causing packet drops. The
second level of action is to alert the administrator so that
configuration can be changed appropriately. The third level action,
would be to try to automatically scale back the extension headers to
be more palatable to whatever node is having a problem with them.

In any case, I think having more information about why nodes are
dropping packets can't be a bad thing even if we're just reporting
this to the user to get some visibility into what network nodes are
doing. Without this visibility and a significant chance of packets
being dropped, it's likely hosts simply won't use extension headers
and we'll continue to see alternate solutions that embed network layer
information in UDP (like Spud, OAM in encaps) and in TCP (like
proposals to write link characteristics into TCP options). I honestly
don't know if having these errors will provide enough insight to make
EH usable that we could consider it first class solution, but neither
to see how maintaining status quo of nodes silently dropping packets
with EH can move things forward either.

Tom

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 May 2017 10:13:10 -0700

I had similar questions. My first thought (looking at the abstract) was that you intended to re-propose Source Quench in some form, and having read it I'm concerned that this ICMP error would have the same problems. The issue with Source Quench, as I recall, was that it wasn't necessarily obvious to the sender what host to send it to (if it's a router with a VPN tunnel, you want to get back to the host using the VPN, not the router), it might not be obvious to the receiving host what application to hand it to, and if it managed to pick the right one, it might not be obvious what that application might propose to do. If it has a window, I suppose it can reduce it, and if the issue is extension headers, it can stop doing whatever it is doing. 

But that has issues. If it's segment routing, for example, segment routing operates from the assumption that the packet needs to visit one or more services en route to wherever it's going. "Stop doing that" means "don't visit those services". I think that eventually means "shut down the session". If the question is Nalini's packet sequence number, then she loses visibility into packet sequencing - and I don't know that the application would be aware it was happening or how to change it. Oh, you wanted to shut down IPsec? 

I think it winds up going back to the operator of the network. "Something smells out here".

Not opposed to the draft, mind you. I think the instrumentation may be valuable. But I think there are legitimate questions.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 May 2017 11:22:18 -0700

> I had similar questions. My first thought (looking at the abstract) was that you intended to re-propose Source Quench in some form, and having read it I'm concerned that this ICMP error would have…
Fred,

I think if the packet is being dropped because of an extensions header
limit then there is no ambiguity who should get the error-- it is
source host since that is the one that created the EH chain in the
first place (discounting the possibility that the EHs were inserted by
an intermediate node).

For the "headers too long case" I would agree that it's not
immediately obvious who is the culprit for making the header too long
in the case of tunneling (a tunnel ingress would get the error but is
may have been the encapsulated packet that was loaded up with headers
that put the length over the top). I suppose if the pointer is set in
some encapsulated then the error could be forwarded to the original
sender who might be able to act if the packet they sent contained
optional data.

> I think it winds up going back to the operator of the network. "Something smells out here".

I believe that's true to the extent that the network operator would
proactively cooperate with hosts and users to address the issue when
it detects packet are being dropped, but I suspect in practice that
doesn't happen until users start complaining about unexplained packet
loss.

Tom

---

From: Fred Baker <[email-masked]>
Date: Tue, 9 May 2017 11:26:53 -0700

Now that I think about it, if the router in question has enough visibility to whine about an IP header, it is processing that header. It may simply be parsing it (it has an ACL for a port number and is trying to go find it, perhaps), but we're not talking about an interior header. It's one the router is parsing.

> On May 9, 2017, at 11:22 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 May 2017 12:27:33 -0700

> Now that I think about it, if the router in question has enough visibility to whine about an IP header, it is processing that header. It may simply be parsing it (it has an ACL for a port number an…
Right. If the node does not parse into any encapsulation then any
packet loss because of a processing limit should be caused by
extension headers (either they're too long or the is an unknown Next
Header type). So the "headers too long" code should only be used when
a node is parsing into encapsulation protocols and hits a limit (like
parsing buffer size).

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 May 2017 11:35:43 +1200

On 10/05/2017 04:59, Tom Herbert wrote:
> I think the most likely first response 

I think the zero'th level is for someone attempting to debug
code using a given (possibly new or experimental) extension
header. We shouldn't neglect that usage, because a probable
scenario is to test a new header in the lab and declare it
working, without being aware that it will be dropped on 25%
of real-world paths.

However, I think the fact that unrecognised ICMP messages
are known to be dropped on many paths is a basic challenge
for this idea. Unless we also add an ICMP message to
report that an ICMP message has been dropped. [Half ;-)]

> would be to stop using

This sounds like Happy Eyeballs on steroids. I do think that
diagnosis is the most important use of this idea.

    Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 May 2017 17:16:25 -0700

> report that an ICMP message has been dropped. [Half ;-)]
Are there any good statistics on ICMP being dropped in the Internet?

> diagnosis is the most important use of this idea.

Actually, I think we're trying to avoid having to do Happy Eyeballs
for extension headers. The equivalent mechanism right now would be
something like applications sending packets with different extensions
headers, detecting loss, and so trying to reverse engineer based on
packet loss (which requires transport layer input) which extension
headers are allowed on the path to a destination and which aren't. I
don't think any host implementation would ever actually implement
that, it is far easier just to not use extension headers at all.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 May 2017 12:58:08 +1200

In a current RFC1981bis thread Suresh Krishnan wrote:
> 
> http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf
> 
> shows about ~1% packet loss in ICMPv6 PTB messages compared to about
> 4-6% for ICMPv4 PTB messages.

   Brian

---

From: [email-masked]
Date: Wed, 10 May 2017 13:17:01 +0200

> that, it is far easier just to not use extension headers at all.

Since it would take some time before all routers on all paths implemented this, wouldn't applications have to deal with the smallest common denominator anyway?

If there is an application class that can chose based on received ICMP if an extension header should be included or not, why wouldn't it not send EH ever?

I do see the point for troubleshooting though.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 11:06:28 -0700

>> that, it is far easier just to not use extension headers at all.

Hi Ole,

> Since it would take some time before all routers on all paths implemented this, wouldn't applications have to deal with the smallest common denominator anyway?
Maybe, but I don't think that we want to wait for all routers to
implement it. The path to getting some real usage of extension headers
would probably start in local networks (like SR might be used to get
packets across a proprietary network).

> If there is an application class that can chose based on received ICMP if an extension header should be included or not, why wouldn't it not send EH ever?
Because the EH may be optional information. For instance, if a host
can set SR maybe hop by hop options maybe it can get optimized routing
or better service, without those maybe packets still flow but in a
sub-optimal manner.

Tom