Re: [Bier] draft-ietf-bier-oam-requirements-00: PMTUD requirement in BIER OAM Requirements

["[e-mail]" <[e-mail]>]

Thanks, Greg

To repeat and refine my points made at the mike @yokohama:

If we intend to support PMTUD for BIER, it should be accordingly
described, but not as an OAM operation. If it's meant as an
offline OAM operation, thats a different discussion.

There is no agreed upon PMTUD mechanism for IPv4/IPv6 multicast
today, the extended socket API explicitly recommend to stick to min-MTU
for IPv4 multicast (1280) to avoid PMTUD issues with IP multicast.

As long as you do probing to do PMTUD, it does not matter what transport
(native, MPLS, BIER, FOOBAR) you use, you will always have to deal with
the problem of potentially getting a humunguous amount of PMTUD
replies (eg: ICMP) back, and this does not scale, and network operators
are worried about the signaling overhead created by badly written
multicast apps. Remember that most PMTUD in unicast is done by few
TCP stacks in OS, but not in apps (little UDP apps trying to use
PMTUD AFAIK).

Just having some segment of an end-to-end IP(v4v6) multicast path be
BIER does not change that probing problem for the end-to-end path.

If we ignore IP multicast and just think about end-to-end BIER, the
picture changes somewhat. We do know explicitly know the set of receivers,
and its < 64k. But: One key benefit of BIER is the ability to change
the set of receivers WITHOUT SIGALING. If we where to do probing based
PMTUD in BIER, we would loose this benefit of BIER.

Aka: Technically i'd be interested to evaluate if we could do proactive
PMTUD for end-to-end BIER. Aka: via signaling of link-MTU in the IGP
that BIER uses - and calculating the path MTU to each BFER from it.
Or just calculating network-wide min-MTU from link-MTU in the IGP.

But: Use-case wise i really don't know how important this is. Ultimately,
this is not a different problem to MPLS: You do not want to do fragmentation,
so you want to send with a sufficiently small MTU, so well controlled
networks (MPLS, BIER) will get configured with the right MTU. And
applications written for IP in mind will not use MTU > 1280 anyhow.

The best case i can think of for BIER is that we get a strong use-case
that shows well improved throughput for jumbo-packets, and we see
sufficient benefits for auto-configuration of that jumbo-packet MTU
for end-to-end BIER.

The use case Caitlin Bessler told me about might fit this profile.
To make it reliable in a DC it would probably want to discover MTU,
and to be highest throughput it might want to use jumbo packets (8192
at least).

Aka: As long as i don't see different use-case descriptions, i'd
primarily be only interested in MTU > 1280 for end-to-end BIER in
this DC network storage use-case environment.

Cheers
    Toerless

On Fri, Nov 06, 2015 at 10:48:08AM +0000, Gregory Mirsky wrote:
> Hi Toerless,
> perhaps I wasn't clear at the mike today. PMTUD is clearly not for OAM but it is OAM service to determine OAM on particular path (the same as PMTUD in p2p, right?). I believe that the fact that PMTUD over multicast in MPLS or IPv4/IPv6 doesn't scale is another indication of advantage BIER technology presents us with.
> I'll be glad to continue our discussion on the list.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Friday, November 06, 2015 1:29 PM
> To: Gregory Mirsky
> Cc: BIER ([e-mail])
> Subject: draft-ietf-bier-oam-requirements-00: PMTUD requirement in BIER OAM Requirements
> 
> Thanks, Greg.
> 
> I was looking just for PMTU or MTU in the text and could not find it.
> 
> I do not agree to this requirement in the OAM requirement draft as of now.
> 
> Why is it needed for BIER ? AFAIK, there is no PMTUD for OAM in any of the prior IP multicast transport options - native IP or MPLS. True ?
> Any reason why BIER would need this more than those prior options ?
> Any reason why BIER would make it a lot easier  than the prior options ?
> 
> This should IMHO be discussed in the draft.
> 
> If we get PMTUD, would it only be for OAM and only for the BIER path, eg:
> not the end-to-end path ? If so, it should be called different (BP-MTUD or the like). 
> 
> If someone proposes that it should be end-to-end, then this needs to go back to MBoned, because it would ask to introduce PMTUD into eg: PIM path segments.
> 
> Wrt. the protocols proposed in your PMTUD draft proposal: I would like to understand why we would not want to proactively signal MTU intead of probing it. There seems to have been some work in the past around this in unicast, not sure how successful.
> 
> Cheers
>     Toerless
> 
> On Fri, Nov 06, 2015 at 01:02:10AM +0000, Gregory Mirsky wrote:
> > Hi Toerless,
> > I'd like to bring requirement #9 in the BIER WG document OAM Requirements for BIER<https://tools.ietf.org/html/draft-ietf-bier-oam-requirements-00>:
> > BIER OAM MUST support Path Maximum Transmission Unit discovery.
> > Hope that addresses your question why are we doing PMTUD.
> > 
> >                 Regards,
> >                                 Greg

-- 
---
Toerless Eckert, [e-mail]