Hello Les,
Jumping in since I have some insight as well.
Le 29/07/2021 à 08:51, Les Ginsberg (ginsberg) a écrit :
Bruno –
Resuming this thread…
I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.
Your slides show indeed we have the same goal, and we agree on one way
to deal with the matter (congestion control).
Looking forward to the WG discussion on Friday.
To get some discussion going in advance – if you have time to do so
(which I know is challenging especially during IETF week) – I call
your attention to slides 15-18 in the presentation we have prepared:
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00
<https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00>
I do not intend to present these slides during my portion of the
presentation time – but I included them as potential points of
discussion during the discussion portion of the meeting (though the WG
chairs will decide how best to direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the
functional elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue
sizes to punt rates, etc. that play a significant role in delivery of
incoming IS-IS PDUs to the protocol running in the control plan.
Your slides –
https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
<https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00>
focus only on the direct input queue to IS-IS in the control plane. I
do not see how the state of the other staging elements on the path
from PDU ingress to IS-IS implementation reading the PDUs in the
control plane is known and/or used in determining the flow control
state signaled to the transmitting neighbor. If, for example, PDUs
were being dropped on ingress and never made it to IS-IS in the
control plane, how would your algorithm be aware of this and react to
this?
In my experience, the state of these lower level staging elements
plays a significant role.
I can imagine that some form of signaling from the dataplane to the
control plane about the state of these lower level elements could be
possible – and that signaling could be used as input to a receiver
based control algorithm. However, given the differences as to how
individual platforms implement these lower level elements, I see it
as challenging to get each platform to provide the necessary signaling
in real time and to normalize it in a way so that IS-IS flow control
logic in the control plane can use the data in a platform independent
way. I believe this represents a significant bar to successful
deployment of receiver-based flow control.
That's one point we want to clarify, the flow control algorithm does not
focus on the "IO path" between the line card and the control plane.
There is no magic there, it does not directly deals with congestion on
the IO path. It happens it has some nice properties even in case of
drops before reaching the control plane, but it's arguably not
sufficient. That's why we also propose a congestion control algorithm.
While it is not necessary to establish a standard since it's only local,
it helps having a baseline if one does not want to spend time
re-developing its own algorithm.
Our slides also show the result of our congestion control algorithm,
which is the part that deals with IO path losses. Very much like your
algorithm, ours sees this IO path as a black box.
This is one major reason why we prefer a Tx based flow control
mechanism. Tx based flow control simply focuses on the relative rates
of LSP transmission and reception of Acknowledgments. Whether slower
acks are due to PDU drops at ingress, slow punt path operation, lack
of CPU time for IS-IS to process the incoming packets, etc. matters
not. Whatever the reason, if acks are not keeping pace with
transmission we know we have to slow down.
As you can see in the slides & draft, we also have a congestion control
algorithm and we show the results. This congestion control algorithm
only works with the ACKs (like yours), and gives results in the case of
"IO congestion" (like yours).
Flow and congestion control are not mutually exclusive; in fact it is
almost certain it will be necessary to have both at some point. The main
benefit of limiting the number of unacked packets inflight is to avoid
loosing packets in case of CPU contention. As this should be a common
situation (in part for reasons in your slide 15), flow control as we
propose seems very relevant.
For example, in your Slowing Down scenario, if the slowing down occurs
at the Control Plane, a congestion control algorithm will lose packets.
If on top of your algorithm, you limit the number of unacked LSPs (flow
control), these losses cannot occur anymore as the sender will stop
sending before overflowing the socket buffer. It's an (almost) free win.
In addition, slide 17 talks about signalling in real time; I am unsure
of your point. As the socket size is static (or at least long lived),
there is no need to change the advertised value in real time. Maybe the
previous explanations helped in clarifying the proposed changes. I don't
really understand the point of slide 18 neither. I would be interested
in more details.
Thanks for your remarks,
Guillaume
Please comment on these points as you have time.
Thanx.
Les
*From:* [email protected] <[email protected]>
*Sent:* Monday, July 12, 2021 1:48 AM
*To:* Les Ginsberg (ginsberg) <[email protected]>; [email protected]
*Cc:* [email protected]
*Subject:* RE: draft-decraene-lsr-isis-flooding-speed & IETF 111
Les,
Faster flooding may be achieved without protocol extension. But if we
are at changing flooding, it would be reasonable to try to make it
good (rather than just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the receiver is busy/congested (either by
flooding, or any CPU computation including not coming from IS-IS)
- avoiding/minimizing the parameters that the network operator is been
asked to tune
- avoiding/minimizing the loss of LSPs
- robust to a wide variety of conditions (good ones and bad ones)
You seem to agree on changing the flooding behaviour on both the
sender and the receiver so that they can better cooperate. That’s
protocol extension to me (and IMHO much bigger than the sending of
info in one TLV)
Bruno
*From:*Les Ginsberg (ginsberg) [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Friday, July 9, 2021 7:49 PM
*To:* DECRAENE Bruno INNOV/NET <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* RE: draft-decraene-lsr-isis-flooding-speed & IETF 111
Bruno –
Neither of us has presented anything new of substance in the last few
IETFs.
There were two presentations recently - one by Arista and one by
Huawei – each of which simply demonstrated that it is possible to
flood faster - and that in order to do so it is helpful to send acks
faster - both points on which there is no disagreement.
To have a productive discussion we both need to present new data -
which is why having the discussion as part of the meeting at which the
presentations occur makes sense to me.
We removed the example(sic) algorithm from our draft because it was
only an example, is not normative, and we did not want the discussion
of our approach to be bogged down in a debate on the specifics of the
example algorithm.
Based on your response, seems like we were right to remove the
algorithm. 😊
Regarding WG adoption, one of the premises of our draft is that faster
flooding can be achieved w/o protocol extensions and so there is no
need for a draft at all. I am sure we do not yet agree on this - but I
do hope that makes clear why adopting either draft at this time is
premature.
Les
*From:* [email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]>>
*Sent:* Friday, July 9, 2021 9:15 AM
*To:* Les Ginsberg (ginsberg) <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* RE: draft-decraene-lsr-isis-flooding-speed & IETF 111
Les,
> *From:*Les Ginsberg (ginsberg) [mailto:[email protected]
<mailto:[email protected]>]
[…]
> I also think it would be prudent to delay WG adoption
For how long exactly would it be “prudent to delay WG adoption”? (in
addition to the past two years)
Until what condition?
It’s been two years now since draft-decraene-lsr-isis-flooding-speed
brought this subject to the WG (and even more in private discussions).
Two years during which we have presented our work to the WG, discussed
your comments/objections, been asked to provide more data and
consequently worked harder to implement it and obtain evaluation results.
What’s precisely the bar before a call for WG adoption be initiated?
We have data proving the benefit, so after those two years, what are
your clear and precise _/technical/_ objections to the mechanism
proposed in draft-decraene-lsr-isis-flooding-speed?
Coming back to draft-decraene-lsr-isis-flooding-speed,
we have a specification and the flow control part is stable.
We have an implementation and many evaluations demonstrating that flow
control alone is very effective in typical conditions.
we have an additional congestion control part which is still been
refined but this part is a local behavior which don’t necessarily
needs to be standardized and which is mostly useful when the receivers
of the LSP is not CPU-bound which does not seem to be the case from
what we have seen. (in most of the cases, receivers are CPU bound. In
fact, we needed to artificially create I/O congestion in order to
evaluate the congestion control part) .
Regarding your draft, in the latest version of your draft, published
yesterday, you have removed the specification of your proposed
congestion control algorithm… Based on this, I don’t see how technical
discussion and comparison of the specification can be achieved.
You have an implementation. This is good to know and we are ready to
evaluate it under the same conditions than our implementation, so that
we can compare the data. Could you please send us an image? We may be
able to have data for the interim.
--Bruno
*From:*Les Ginsberg (ginsberg) [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Friday, July 9, 2021 5:00 PM
*To:* DECRAENE Bruno INNOV/NET <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]>; [email protected] <mailto:[email protected]>
*Subject:* RE: draft-decraene-lsr-isis-flooding-speed & IETF 111
As is well known, there are two drafts in this problem space:
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/
<https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/>
and
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/
<https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/>
Regarding the latter, we also have a working implementation and we
also have requested a presentation slot for IETF 111 LSR WG meeting.
I agree with Bruno that the time available in the WG meeting will
likely be inadequate to present full updates for both drafts. In
addition, I think it is important that the WG have
an opportunity to discuss publicly in an interactive way, the merits
of each proposal. The likelihood that time will be available in the
scheduled WG meeting for that discussion as well seems low.
I therefore join w Bruno in suggesting that an interim meeting
dedicated to the flooding speed topic be organized.
Given the short time available before IETF 111, I would suggest that
we look at scheduling an interim meeting after IETF 111 - but I leave
it to the WG chairs to decide when to schedule this.
I also think it would be prudent to delay WG adoption calls for either
draft until after such an interim meeting is held. In that way the WG
can make a more informed decision.
Les
*From:* Lsr <[email protected] <mailto:[email protected]>> *On
Behalf Of *[email protected] <mailto:[email protected]>
*Sent:* Friday, July 9, 2021 2:01 AM
*To:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*Subject:* [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111
Hi chairs, WG,
Over the last two years, we have presented and the WG discussed
draft-decraene-lsr-isis-flooding-speed at IETF 105 and “107”
IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsr
<https://datatracker.ietf.org/meeting/105/proceedings#lsr> Note:
that the presentation is in first slot/video but a large part of the
discussion is in the second one.
IETF 107/interim:
https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html
<https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html>
The goal is to improve flooding performance and robustness to make it
both faster when the receiver have free cycles, and slower when the
receiver is congested.
In addition to technical discussions, a feedback was that
implementation and tests/evaluation would be good in order to evaluate
the proposal.
We are reporting that we have an implementation of [1] based on the
open source Free Range Routing implementation.
We are now ready to report the evaluation to the WG. We have a lot of
data so ideally would need around an hour in order to cover the whole
picture.
We have requested a slot for IETF 111 LSR meeting. If the IETF 111
slot is short, we’d like to request for an interim meeting. In order
to keep the context, the sooner/closer to IETF 111 seems the better.
Since we have an implementation, we have requested for a code point,
in order to avoid squatting on one. This is currently under review by
the designed experts.
Finally, given the two-years work, the specification, the
implementation and extensive evaluation, we’d like to ask for WG adoption.
Thanks,
Regards,
--Bruno
[1]
https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed
<https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed>
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
This message and its attachments may contain confidential or
privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
