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

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Mar 2018 16:24:22 +0000

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 19 Mar 2018 17:33:21 +0000

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
<https://tools.ietf.org/html/draft-ietf-bier-path-mtu-discovery-03>does
provide per path information.

Regards,
Greg

On Mon, Mar 19, 2018 at 4:24 PM, Tony Przygienda <[email-masked]>
wrote:

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Mar 2018 15:14:29 -0700

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:
> paths capable of larger MTU. The BIER PMTUD draft does provide per path
> information.
>
> Regards,
> Greg
>
>>    of a BIER interface, determines the largest payload that can be sent
>> The language here is unclear. Is that the MIN(all used subdomain interface
>> MTUs) ? If so, then it makes sense.
>>
>> mtu, interface mtu and so on. The draft should specifiy what the precise way
>> is to advertise the "BIER MTU" here IMO ...
>>
>> --- tony
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 28 Mar 2018 22:23:51 +0000

Hi Stig, 
I agree that you should compute a domain wide MTU. In fact, if you have to know the exact MDT to compute the minimum path MTU, you are taking away one of the main advantages of BIER. 

Thanks,
Acee

On 3/28/18, 6:14 PM, "BIER on behalf of Stig Venaas" <[email-masked] on behalf of [email-masked]> wrote:

    Hi

    
    
    Stig

---

From: Xiejingrong <[email-masked]>
Date: Thu, 29 Mar 2018 01:41:44 +0000

Hi Stig,

What I am worried about is that, when a new router is add to the network, and unfortunately some of its link has a minimal MTU, then all the running sessions would have to change.

Also for the condition when some link with min MTU being brought up.

Though Yes, when the network is stable enough, then "there is no need of rediscovering path MTU each time a new receiver is added" is a benefit to me as well.

So I think the most pessimistic MTU, is still a configured one, or a compulsive one like what IPv6(RFC8200) defined --value 1280.

Thanks,
Jingrong

-----Original Message-----
From: BIER [mailto:[email-masked]] On Behalf Of Stig Venaas
Sent: Thursday, March 29, 2018 6:14 AM
To: Greg Mirsky <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] draft-venaas-bier-mtud

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
>
>> 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
>>

---

From: <[email-masked]>
Date: Thu, 29 Mar 2018 10:02:09 +0800 (CST)

Hi Stig,

The sub-domain wide MTU makes sense to me. 

IMO the MTU per sub-domain can get balance between robust and advertisement/ implementation complexity.

Thanks,

Sandy

原始邮件

发件人：StigVenaas <[email-masked]>
收件人：Greg Mirsky <[email-masked]>
抄送人：BIER WG <[email-masked]>
日 期 ：2018年03月29日 06:14
主 题 ：Re: [Bier] draft-venaas-bier-mtud

Hi

Stig

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 29 Mar 2018 08:16:17 +0300

Hi Stig,
thank you for your kind consideration of my comments. I think that
sub-domain MTUD and PMTUD methods are complementary (I'd characterize
sub-domain method as "conservative" rather than "pessimistic" :) ).
Couple notes on use cases you've mentioned:

   - yes, when a new receiver added, PMTUD to it may be performed;
   - in the ECMP environment PMTUD will use the same Entropy field value as
   the flow for which the MTU to be discovered.

Regards,
Greg

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

> than

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Mar 2018 09:56:25 -0700

Hi

> thank you for your kind consideration of my comments. I think that

Thanks, I appreciate your feedback as well.

> 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.

> 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

>> > but

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Mar 2018 10:01:07 -0700

Hi

> So I think the most pessimistic MTU, is still a configured one, or a compulsive one like what IPv6(RFC8200) defined --value 1280.

I agree that this can be a problem. I would argue that this
"pessimistic" or rather "conservative" MTU is still better than just
using say
1280 though. The new links on that new router would hopefully not have
an MTU less than 1280.

I don't have a good solution to this. I guess an administrator should
be careful what MTUs are configured before bringing up the
interfaces. As I just wrote in another email, if you have a diverse
network where a few links are much "thinner" (must less
MTU) than the rest, then the downside of the sub-domain MTU is
certainly that you cannot take advantage of your "thicker"
links, since the MTU will be determined by the "thinnest" link.

Stig

---

From: Xiejingrong <[email-masked]>
Date: Fri, 30 Mar 2018 12:10:55 +0000

Exactly. 

It is honest to say "It can be a problem" :-)

Maybe it is helpful to list such problems and some operation advice into a paragraph in the draft to make the audience clear, as the 'BIER-MTU' defined in RFC8296 that do not using a provisioning:

   Each BFIR is expected to know the Maximum Transmission Unit (MTU) of
   the BIER domain.  This may be known by provisioning, or by some other
   method outside the scope of this document.

Thanks
Jingrong

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Friday, March 30, 2018 1:01 AM
To: Xiejingrong <[email-masked]>
Cc: BIER WG <[email-masked]>
Subject: Re: [Bier] draft-venaas-bier-mtud

Hi

> So I think the most pessimistic MTU, is still a configured one, or a compulsive one like what IPv6(RFC8200) defined --value 1280.

I agree that this can be a problem. I would argue that this "pessimistic" or rather "conservative" MTU is still better than just using say
1280 though. The new links on that new router would hopefully not have an MTU less than 1280.

I don't have a good solution to this. I guess an administrator should be careful what MTUs are configured before bringing up the interfaces. As I just wrote in another email, if you have a diverse network where a few links are much "thinner" (must less
MTU) than the rest, then the downside of the sub-domain MTU is certainly that you cannot take advantage of your "thicker"
links, since the MTU will be determined by the "thinnest" link.

Stig

>>> 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
>>>
>>> link mtu, interface mtu and so on. The draft should specifiy what 
>>> the precise way is to advertise the "BIER MTU" here IMO ...
>>>
>>> --- tony
>>>