Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Juliusz,

This is not about congestion control. Congestion control is something that has a control loop and is based on feedback. This is not possible and not required here. However, limiting the total load a protocol can induce on a network is a common safety mechanism that I usually look for in all protocols including routing protocols. As explained already e.g OSPF has a limit because all interval values are in units of seconds, however, this is not the case here.

Even if the communication is link local, overloading that one link and the respective endpoint (or actually all neighbours) can have an impact on the network as a whole as this can also push away all other traffic. Even if the traffic rate generated by the protocol is low, you still have to make sure that it is lower than the local link capacity. That seems straight forward to us maybe but still some good advise to give in the spec.

Further if misconfigured it is still possible that the babel traffic does not stay local. So even for this unlikely error case we must insure that babel can’t crash the network.

I know this seem overly cautious because these are unlikely cases, however, that’s still makes it important to discuss them in proposed standard spec.

I don’t really understand the whole discussion here to be honest because I actually don’t ask for much. Why is it such a problem to recommend the one value set that you have tested and works well for all scenarios? Again, of course that doesn’t mean that all implementations have to use this and that was never what I asked for. And why do you think it is a problem to add more text in the spec that explains better the network impact of choosing these value, e.g. like calculating the load that is expected by the choice of certain value?

I don’t think we will make any progress here, as I have the feeling you are just unwilling to make any further changes to the document, and would like to ask Martin as the responsible AD to intervene and provide further guidance to both of us!

Mirja



> On 8. Jan 2020, at 16:15, Juliusz Chroboczek <[e-mail]> wrote:
> 
>> The smaller the time interval are that you use, the higher is the load
>> on the network. That means certain configuration would endanger the
>> integrity of the network if the network capacity is below the load that
>> is generated by the updates and hello.
> 
> Mirja -- this is not a transport-layer protocol that is deployed over
> a heterogeneous Internet; it's a signalling protocol that is deployed over
> the local link.  Since there are no intermediate routers to congest,
> congestion control issues are very different from what you are used to.
> 
> The amount of signalling traffic that a Babel node generates is minuscule,
> on the order of a few hundred bytes per second, a few kB/s in large
> networks.  Since there are no intermediate routers to congest, the only
> limiting factor is the speed of the local link.
> 
>> This is not discussed in appendix B.
> 
> Neither does RFC 5340.
> 
> There is no concensus whether congestion control for link-local signalling
> protocols is a real issue.  If you believe that it is an issue, then
> I encourage you to create a WG to deal with the issue in a general manner,
> one that applies to OSPF, IS-IS, Babel and even DHCPv6 and ND.  (I know at
> least one person who thinks like you, and would probably be interested in
> participating; I, for one, would be interested in reviewing any documents
> you produce.)
> 
> Requiring us to solve this (real or imagined) problem within the Babel WG
> is not reasonable, just as it would not be reasonable to request that it
> be solved within the OSPF WG.
> 
> -- Juliusz
> 
>