Subject: Re: [Bier] draft-venaas-bier-mtud

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 May 2018 13:58:08 -0700

Hi Stig,
sorry for such long delay to respond.
I think that in closing in Section 3 we've anticipated the idea of SMTU:
   o  a BFR MAY use defined per BIER sub-domain MTU value as initial MTU
      value for discovery or use it as MTU for this BIER sub-domain to
      reach BFERs;

I agree with you suggestion to add to PMTUD draft text about ECMP
environment. Section 3 describes the PMTUD mechanism and I think it is the
most appropriate place. Please consider text I'd like to add:
OLD TEXT

   A BFIR selects a set of BFERs for the specific multicast
   distribution.  Such a BFIR determines, by explicitly controlling
   subset of targeted BFERs and transmitting series of probe packets,
   the MTU of that multicast distribution tree.

NEW TEXT
   A BFIR selects a set of BFERs for the specific multicast
   distribution.  Such a BFIR determines, by explicitly controlling
   subset of targeted BFERs and transmitting series of probe packets,
   the MTU of that multicast distribution tree. In case of ECMP, BFIR
   MAY test each path by variating the value in Entropy field.

There are many scenarios that may trigger BFIR to re-running PMTUD. We
refered to them as "locally defined" in
   o  a BFIR MUST have a locally defined of PMTUD probe retransmission
      procedure.

Appreciate your consideration, comments.

Regards,
Greg

On Thu, Mar 29, 2018 at 9:56 AM, Stig Venaas <[email-masked]> wrote:

> Hi
>
> On Wed, Mar 28, 2018 at 10:16 PM, Greg Mirsky <[email-masked]>
> wrote:
> > Hi Stig,
> > thank you for your kind consideration of my comments. I think that
>
> Thanks, I appreciate your feedback as well.
>
> > sub-domain MTUD and PMTUD methods are complementary (I'd characterize
> > sub-domain method as "conservative" rather than "pessimistic" :) ).
>
> Yes, conservative sounds better, thanks!
>
> I agree the solutions can be complimentary. In a very diverse network
> with a few "thin" links, and with flows with big packets that are
> unlikely to hit the think links, PMTUD might be better. One
> possibility could be that for a new flow one starts with what is the
> sub-doman MTU (SDMTU), then one can optionally infrequently perform
> PMTU probing to see if the flow MTU  (FMTU) is indeed larger than the
> SD MTU. If an FMTU > SDMTU is detected, one can allow the FMTU to be
> used for that particular flow and do more frequent probing in case the
> FMTU should become smaller due to receiver/topology changes.
>
> My main concern with FMTU probing is that there can be packet drops
> when the actual MTU is reduced and until the next probe is sent. Hence
> one need to do fairly frequent probing. By knowing the SDMTU, one can
> avoid the frequent probing in some cases, as I wrote above.
>
> > Couple notes on use cases you've mentioned:
> >
> > yes, when a new receiver added, PMTUD to it may be performed;
>
> I think this is important as the MTU might change whenever the
> receiver set changes. In traditional multicast I would call it the
> Tree MTU. With BIER we don't have any explicit trees, so a Flow MTU
> might be a better term.
>
> > in the ECMP environment PMTUD will use the same Entropy field value as
> the
> > flow for which the MTU to be discovered.
>
> Right. I was initially thinking that if different flows had the same
> receiver set, there was no need to probe for each of the flows, but at
> least with ECMP one would need to probe for each entropy value being
> used. The easiest is probably to just do the probing for each flow.
>
> I think it would be good to have more text in the PTMUD draft
> explaining the above. Also, some discussion about the probe frequency.
> How it is helpful to use a high frequency, but there is a trade-off (I
> think) between how quickly you need to discover a lower MTU and the
> scale (the number of flows that you need to probe).
>
> Stig
>
> >
> > Regards,
> > Greg
> >
> > On Thu, Mar 29, 2018 at 1:14 AM, Stig Venaas <[email-masked]> wrote:
> >>
> >> Hi
> >>
> >> I can certainly work on the wording. Perhaps the more important
> >> discussion, which you also brought up, is whether it is worth doing a
> >> pessimistic MTU in the sense that it is sub-domain wide, rather than a
> >> path MTU that can be more optimal. One problem with path MTU and
> >> multicast, is that it changes as the receiver set changes. For a
> >> particular (S,G) an ingress router needs to consider the path MTU
> >> towards each of the egress routers. This means that you need to
> >> discover the path MTU at least each time a new receiver is added (a
> >> new BIER bit is set) for the (S,G). Also, at any time there can be a
> >> routing change lowering the MTU, and packets would get dropped until
> >> the new path MTU is discovered.
> >>
> >> A sub-domain MTU is more pessimistic, but I think it is more robust
> >> than probing. There is less risk of packet drops (from when actual
> >> path MTU is reduced and until it is discovered by a probe), and there
> >> is no need of rediscovering path MTU each time a new receiver is
> >> added. It is also easier to implement.
> >>
> >> I'm also wondering how probing is supposed to work with ECMP. Would
> >> the ingress router need to do a new probe each time it encapsulates
> >> packets with a new entropy?
> >>
> >> Stig
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Mar 19, 2018 at 10:33 AM, Greg Mirsky <[email-masked]>
> >> wrote:
> >> > Dear Authors, et. al,
> >> > I understand the idea of aggregating MTU in the given BIER sub-domain
> >> > but
> >> > I'm concerned that if there are interfaces with significantly
> different
> >> > MTUs, that the proposed approach may result in lower MTU being
> enforced
> >> > on
> >> > paths capable of larger MTU. The BIER PMTUD draft does provide per
> path
> >> > information.
> >> >
> >> > Regards,
> >> > Greg
> >> >
> >> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda <[email-masked]
> >
> >> > wrote:
> >> >>
> >> >> Comments:
> >> >>
> >> >> a)  "
> >> >> Every BIER router, for each sub-domain with at least
> >> >>    one local BIER interface in the sub-domain, per the above
> definition
> >> >>    of a BIER interface, determines the largest payload that can be
> sent
> >> >>    BIER encapsulated out of any of its BIER interfaces in the sub-
> >> >>    domain.
> >> >> "
> >> >>
> >> >> The language here is unclear. Is that the MIN(all used subdomain
> >> >> interface
> >> >> MTUs) ? If so, then it makes sense.
> >> >>
> >> >> b) May merit a section saying that albeit this is much lighter-weight
> >> >> than
> >> >> I-D.ietf-bier-path-mtu-discovery of course it can be widely
> pessimistic
> >> >> since it always picks up the smallest link in the whole subdomain
> >> >>
> >> >> c) "MTU in octets" is seriously underspecified. We have ether mtu,
> link
> >> >> mtu, interface mtu and so on. The draft should specifiy what the
> >> >> precise way
> >> >> is to advertise the "BIER MTU" here IMO ...
> >> >>
> >> >> --- tony
> >> >>
> >> >> _______________________________________________
> >> >> BIER mailing list
> >> >> [email-masked]
> >> >> https://www.ietf.org/mailman/listinfo/bier
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > BIER mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/bier
> >> >
> >
> >
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 9 May 2018 14:44:36 -0700

Hi Greg

This looks good. I completely missed that the PMTUD draft mentioned
BIER sub-domain MTU.

Thanks, I'll update my draft soon, and I can then also reference this
discussion in your draft.

Stig

On Thu, May 3, 2018 at 1:58 PM, Greg Mirsky <[email-masked]> wrote:
>> >> > On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda
>> >> > <[email-masked]>
>> >> > wrote:
>> >> >>
>> >> >> Comments:
>> >> >>
>> >> >> a)  "