RE: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Hi Stewart,

*If*  you care about packet loss


I can say that, for air traffic communications at least, we do care very
much about packet loss.

then your only option is to probe the path with with
synthetic data that exactly mimics the live data


Yes, that is exactly correct - so, the probing must be on a per
(session,destination) basis and not just per-destination.

or not to probe at all and live with the 1280


That is the case for tunnels for sure, but many tunneling specs have
been published with an "optimistic" outlook assuming that the
network can support as much as 1500 minus the length of the 
encapsulation headers. Unless there is operational assurance of
some size X>1280, however, tunnels have to use fragmentation to
guarantee that - at a minimum - packets up to 1280 will get through.

As I said 1280 is pretty close to 1496 which is all most networks
will give you in practice.


Still, I wish for the day that we may eventually see larger path MTUs.
It seems that the only way for sources to safely discover them
however is to employ per-session RFC4821.

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

-----Original Message-----
From: Stewart Bryant [mailto:stewart(_dot_)bryant(_at_)gmail(_dot_)com]
Sent: Tuesday, February 14, 2017 8:45 AM
To: Templin, Fred L <Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com>; 
Stewart Bryant <stewart(_dot_)bryant(_at_)gmail(_dot_)com>; Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>; 
gen-art(_at_)ietf(_dot_)org
Cc: ipv6(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
draft-ietf-6man-rfc1981bis(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

Fred
*If*  you care about packet loss, then your only option is to probe the
path with with
synthetic data that exactly mimics the live data, or not to probe at all
and live
with the 1280. As I said 1280 is pretty close to 1496 which is all most
networks
will give you in practice.

When I think about the people asking for fast re-route to minimise
packet loss, it seems
very strange to deliberately induce loss to try to stretch the MTU by 15%.

- Stewart

On 14/02/2017 16:25, Templin, Fred L wrote:

Hi Stewart,

-----Original Message-----
From: Stewart Bryant [mailto:stewart(_dot_)bryant(_at_)gmail(_dot_)com]
Sent: Tuesday, February 14, 2017 8:13 AM
To: Templin, Fred L <Fred(_dot_)L(_dot_)Templin(_at_)boeing(_dot_)com>; 
Brian E Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>; 
Stewart Bryant
<stewart(_at_)g3ysx(_dot_)org(_dot_)uk>; gen-art(_at_)ietf(_dot_)org
Cc: ipv6(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
draft-ietf-6man-rfc1981bis(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04



On 14/02/2017 15:50, Templin, Fred L wrote:

As to you first point remember that the convergence process disrupts the
traffic flow as it does so, and that this will repeat every 10 mins as
it tries to re-optimise.

Yes, you are right. So, even in the case of RFC1981bis it might not be a
good idea to store discovered MTUs in the network layer when there
is ECMP in the path. (Which could be any time at all.)

Yes, I think if you really care about disruption due to packet loss your
best bet is
to go with the minimum supported MTU.

Forwarding performance is not a issue these days, and core link are over
provisioned
so you have to wonder how important the efficiency gain is in practice.
The efficiency
gain produced by this protocol in most networks (1276 vs 1496) is only
about 15% anyway.

So, that would leave us with RFC4821 plus per {session,destination}
probing instead of just per-destination probing. Or, just stick with the
IPv6 minMTU (1280)?

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

You briefly mentioned the authorship in your earlier post. As you well
know, the corporate affiliation of two of the authors no longer exists.

My concern was that some authors cannot take part in Auth48 due to not
providing
active email addresses.

- Stewart

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

- Stewart


On 10/02/2017 15:38, Templin, Fred L wrote:

Hi, about ECMP I think RFC1981bis should be OK even if ECMP is used in 
the
network as long as ICMP PTBs are not blocked. RFC1981bis will eventually
converge to the minimum MTU of all paths in the multipath, and so it is
still OK to store the MTU in the network layer where it would be shared
by all flows.

ECMP does present challenges for RFC4821, however. If a first transport
session discovers a large MTU and shares it with a second transport
session, the second session may take a very different path where there
is a smaller MTU and encounter a black hole. IMHO, it might be a good
idea to file an erratum to RFC4821 explaining how ECMP might cause
problems if discovered MTUs are shared between sessions.

Thanks - Fred
fred(_dot_)l(_dot_)templin(_at_)boeing(_dot_)com

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces(_at_)ietf(_dot_)org] On Behalf Of 
Stewart Bryant
Sent: Friday, February 10, 2017 2:21 AM
To: Brian E Carpenter 
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>; Stewart Bryant 
<stewart(_at_)g3ysx(_dot_)org(_dot_)uk>; gen-art(_at_)ietf(_dot_)org
Cc: ipv6(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
draft-ietf-6man-rfc1981bis(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04



On 10/02/2017 03:25, Brian E Carpenter wrote:

Stewart,

On 10/02/2017 04:19, Stewart Bryant wrote:
...

I wonder if we would best serve both our future and our heritage
if we declared RFC1981 as historic, and either left the idea there,
or declared it as historic and wrote a new text from a clean start?

I don't see that. It's a stable, widely deployed, interoperable
mechanism. That is rather orthogonal to the issue that has been 
raised,
which is that faulty ICMPv6 filtering blocks it on many, many paths
across the Internet.

I will not debate whether it is faulty or not, but it seems that in
practice the
Internet breaks the mechanism. However it breaks it is a way that seems
disruptive to some user traffic. The document is really guidance
one how hosts might use  ICMP for optimization, and arguable need
not be a standard at all.

My remark about heritage is that this vintage draft is very much a
product of
its time, and really needs modernizing, and after modernizing ought to
look quite different, and thus maybe we should employ a procedure
other than a simple replacement.

...

It is concerning that the draft does not talk in any detail about
how modern ECMP works, i.e. using the five tuple, and noting that
the PMTU may be different depending on the transport layer port
numbers.

Has this problem been analysed for, say, IPv4? And does the real world
contain ECMP setups with different MTUs on different paths?

I don't know if anyone has looked. Since the mechanism is
self-correcting albeit
with some disruption to user traffic it looks to the application and 
the
application
user, just like the Internet not working for a few moments.

In a well managed SP network there should not be, but neither should 
there
be asymmetric path costs, but there are. The less well manage private
networks are less well managed.

Given that a very large fraction of packets will traverse an MPLS
network at some point, I am surprised that there is no text talking
about the importance of providing support for this feature in the
MPLS domain. RFC3988 talks to this point, but is only experimental.

I don't understand. How does the fact that there might be some MPLS
segments along the path affect end-to-end PMTUD?

The point that RFC3988 makes is that MPLS looks like a single hop to IP
and the
PE has to fragment or has to reply with an ICMP error message to 
support
PMTUD. MPLS has ICMP extensions, but I don't know if they integrate to
result
in the right response at the end node.

My point is that the draft is silent on the subject, and perhaps it
should not be.

However your question make me ask a further question. The draft is also
silent
on NATs. Is there any advice needed for people designing and 
configuring
NATs?

======

       If flows [I-D.ietf-6man-rfc2460bis] are in use, an 
implementation
       could use the flow id as the local representation of a path. 
Packets
       sent to a particular destination but belonging to different 
flows may
       use different paths, with the choice of path depending on the 
flow
       id.  This approach will result in the use of optimally sized 
packets
       on a per-flow basis, providing finer granularity than PMTU 
values
       maintained on a per-destination basis.

SB> How widely is flow-id supported in networks? I thought that the
SB> current position was that it was unreliable as an ECMP indicator
SB> and thus routers tended to glean information from the packet 
themselves.

This is future-proofing. Agreed, usage today is limited.

(But it would be better to call it the Flow Label for consistency 
with other
recent RFCs.)

Well the question is whether it is simply limited today, or broken 
today
in a manner that
is irrecoverable? I don't know, but I do know that the mainstream ECMP
approach
is the five-tuple. There is something akin to the flow label being
deployed in MPLS. However
what distinguishes the MPLS Entropy Label is that it is inserted (and
removed) by the
service provider and is therefore trusted by the service provider.

I think your other comments are all valuable.

Thank you.

Stewart

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------