Hi Tony,
> I am assuming that there is no link layer flow control. I can’t recall
> working on a system that supports X.25 since about 1995, so I don’t think
> that’s a common use case today.
>
I was more thinking along the lines of leveraging IEEE 802.3x or 802.1Qbb
standard not necessarily sug
Hello Les,
Les Ginsberg (ginsberg) schreef op 2019-07-24 07:17:
There is something to be said for simply “flooding fast” and not
worrying about flow control at all (regardless of whether TX or RX
mechanisms would be used). Some packets would be dropped, but
retransmission timers will insure th
Hello Les,
Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17:
If you accept that, then it makes sense to look for the simplest way
to do flow control and that is decidedly not from the RX side. (I
expect Tony Li to disagree with that 😊 – but I have already
outlined why it is more complex to do
Hey Henk & all,
If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long as
Tony mentioned the full flooding as Tony said may take 33 sec - is this
really a problem ?
Remember we are not talking about protocol convergence after link flap or
node going down. We are talking about serio
Hello Robert,
Tony brought up the example of a partioned network.
But there are more examples.
E.g. in a network there is a router with a 1000 neighbors.
(When discussing distributed vs centralized flooding-topology
reduction algorithms, I've been told these network designs exist).
When such
Hi,
Yes indeed while I was reading your richly connected node restart problem
use of overload-bit should be explored, proposed, implemented.
For the partition problem I have two general comments:
a) If network partitions is likely to happen more often in the case of
dynamic flooding perhaps as a
I'm under the impression the whole discussion got triggered by my rather
loose remark during the dinner based on, admittedly, my quite dated
implementation experience (with 2 disjoint distributed SPTs to reduce
flooding). I realized it seems not clearly spelled out on the thread. So to
hopefully cl
Les Ginsberg (ginsberg) schreef op 2019-07-23 22:29:
It is a mistake to equate LSP flooding with a set of independent P2P
“connections” – each of which can operate at a rate independent
of the other.
Of course, if some routers are slow, convergence in parts of the network
might be slow. But as
Robert,
Nothing has changed about the probability of network partitioning. That was
simply a use case selected to motivate the discussion about flooding speed.
The entire discussion is almost orthogonal to dynamic flooding. Let’s please
take that out of the discussion.
Tony
> On Jul 24, 20
Robert,
> The second part of the question was really about at what layer it makes most
> sense to provide this control loop.
To me, the obvious thing to do is to make minor revisions to the protocol. We
need to:
- Add a TLV so that the receiver can provide feedback. IMHO, this should be in
Tony –
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:39 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
I also think we all agree on the goal - which is to flood significantly faster
than many im
*[Les:] At the cost of convergence. Not a good tradeoff.*
Hi Les - why at the cost of convergence ? No one as I see it is proposing
the same rate to every peer. Quite contrary -- per peer rate of flooding.
So if you keep flooding high speed on fast links the convergence will not
be any slower with
More inline…
From: Tony Li On Behalf Of tony...@tony.li
Sent: Tuesday, July 23, 2019 10:56 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
There is something to be said for simply “flooding fast” and not
Henk -
Welcome to the discussion.
Inline.
> -Original Message-
> From: henk.i...@xs4all.nl
> Sent: Wednesday, July 24, 2019 5:34 AM
> To: Les Ginsberg (ginsberg)
> Cc: stephane.litkow...@orange.com; Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow control for flooding
>
>
> H
Les,
> Optimizing the throughput through a slow receiver is pretty low on my list
> because the ROI is low.
Ok, I disagree. The slow receiver is the critical path to convergence. Only
when the slow receiver has absorbed all changes and SPFed do we have
convergence.
> First, the rate that
Henk -
Inline.
> -Original Message-
> From: Henk Smit
> Sent: Wednesday, July 24, 2019 6:18 AM
> To: Les Ginsberg (ginsberg)
> Cc: stephane.litkow...@orange.com; Tony Li ; lsr@ietf.org
> Subject: Re: [Lsr] Dynamic flow control for flooding
>
>
> Hello Les,
>
> Les Ginsberg (ginsberg)
Les,
Can’t we use from a transmitter point of view, the lack of ACKs from the
receiver as a signal that the transmitter should slow down ?
I agree that depending on the exact bottleneck/issue, the IS-IS stack of the
receiver may not be aware that something bad is happening and can’t provide
fee
Tony –
I have NEVER proposed that the flooding rate be determined by the slowest node.
Quite the opposite.
Flooding rate should be based on the target convergence time and should be
aggressive because most topology changes involve much fewer than 1000 LSPs
(arbitrary number). So even w a slow n
Les,
Ok, let me reset. I’ve re-read your slides.
I don’t see anything in there about changing the PSNP signaling rate. From
your comments to Henk, I infer that you’re open to changing that rate.
As soon as you do that, you’re now providing receiver based feedback and
creating flow control.
Tony –
This thread reminds me of how easy it is to miscommunicate – and I bear some of
the responsibility for that.
Inline.
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 1:07 PM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for
Les,
> This thread reminds me of how easy it is to miscommunicate – and I bear some
> of the responsibility for that.
Communications takes two. The receiver must also be focused on the input. My
bad too.
> I don’t see anything in there about changing the PSNP signaling rate. From
> your
> Whether a BCP draft is desired is something I am open to considering.
Process nit: what we’re talking about doing, regardless of how we do it, is
overriding 10589. As that’s a normative reference, overriding that requires
that we have a standards track document.
I don’t believe that even
Les,
> If you disagree please take things bullet-by-bullet:
>
> LSP input queue implementations are typically interface independent FIFOs
Very true. It would not be unreasonable for an implementation to report free
space in the FIFO (in number of PDUs) divided by the number of active
adjac
Tony -
From: Tony Li On Behalf Of tony...@tony.li
Sent: Wednesday, July 24, 2019 3:37 PM
To: Les Ginsberg (ginsberg)
Cc: stephane.litkow...@orange.com; lsr@ietf.org
Subject: Re: [Lsr] Dynamic flow control for flooding
Les,
If you disagree please take things bullet-by-bullet:
* LSP inpu
Les,
> Very true. It would not be unreasonable for an implementation to report free
> space in the FIFO (in number of PDUs) divided by the number of active
> adjacencies. Everyone gets their fair share.
>
> [If dynamic flooding is enabled, this could be based on the number of
> adjacencie
25 matches
Mail list logo
