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

[Gregory Mirsky <[e-mail]>]

Hi Toerless,
thank you for your detailed response. Couple questions to clarify and notes in-line and tagged GIM>>.

	Regards,
		Greg

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Sunday, November 08, 2015 2:16 AM
To: Gregory Mirsky
Cc: BIER ([e-mail])
Subject: Re: draft-ietf-bier-oam-requirements-00: PMTUD requirement in BIER OAM Requirements

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.
GIM>> I don't know what you mean by "offline OAM". The PMTUD proposed as on-demand OAM operation that can be triggered by an operator or central controller. I don't see the need or benefit of running PMTUD as proactive OAM.

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.
GIM>> As discussed at the meeting, one may list any subset of BFIRs in the given domain. I don't see what gets lost with such flexibility.

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.
GIM>> AFAIK, "proactive OAM" usually identifies an operation that is continuous. Do you suggest to run the PMTUD continuously with some intervals? Haven't thought about benefit of this mode though the PMTUD method would not preclude one from using it in this manner.

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]