Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[Tony Przygienda]

On Wed, Apr 22, 2020 at 11:03 AM  wrote:

> Tony, all,
>
>
>
> Thanks Tony for the technical and constructive feedback.
>
> Please inline [Bruno]
>
>
>
> *From:* Tony Przygienda [mailto:tonysi...@gmail.com]
> *Sent:* Wednesday, April 22, 2020 1:19 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* DECRAENE Bruno TGI/OLN; lsr@ietf.org
> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
>
>
> neither am I aware of anything like this (i.e. per platform/product
> flooding rate constants) in any major vendor stack for whatever that's
> worth. It's simply unmaintanable, point. All major vendors have extensive
> product lines over so many changing hardware configuration/setups it is
> simply not viable to attempt precise measurements (and even then, user
> changing config can throw the stuff off in a millisecond). There may have
> been here and there per deployment scenario some "recommended config"
> (not something I immediately recall either) but that means very fixed
> configuration of things & how they go into networks and even then I'm not
> aware of anyone having had a "precise model of the chain in the box". yes,
> probes to measure lots and lots of stuff in the boxes exist but again,
> those are chip/linecard/backplane/chassis/routing engine specific and
> mostly used in complex test/peformance scenarios and not to derive some
> kind of equations that can predict anything much ...
>
> [Bruno] Good points.
>
> Yet, one of the information that we propose to advertise by the LSP
> receiver to the LSP sender is the Receive Window.
>
> -  This is a very common parameter and algorithm. Nothing fancy
> nor reinvented. In particular it’s a parameter used by TCP.
>
> -  I would argue that TCP implementations also run on a variety
> of hardware and systems, must wider range than IS-IS platform. And those
> TCP implementations on all those platform manage to advertise this
> parameter (TCP window)
>
> -  I fail to understand that when some WG contributors proposed
> the use of TCP, nobody said that determining and advertising a Receive
> Window would be an issue, difficult or even impossible. But when we propose
> to advertise a Receive Window in an IS-IS TLV, this becomes difficult or
> even impossible for some platforms. Can anyone help me understand the
> technical difference?
>
>
>

Bruno, I was waiting for that ;-) Discounted for the fact that I'm not a
major TCP expert: TCP is a very different beast. it has a 100-200msec fast
timer & 500msec slow (which have to be quite accurate, it's really one
timer for all connections + mbuf and other magic) and it sends a _lot_ of
packets back and forth with window size indications so the negotiation can
happen very quickly.  Also, TCP can detect losses based on sequence number
received contrary to routing protocols (that's one of the things we added
in RIFT BTW) and it can retransmit quickly when it sees a "hole". Contrary
to that in ISIS ACKs may or may not come, they may be bundled, hellos may
or may not come and we can't retransmit stuff on 100msec timers either.
It's an utterly different transport channel.

In more abstract terms, TCP is a sliding N-window protocol (where N is
adjusted all the time & losses can be efficiently detected) whereas LSR
flooding is not a windowing protocol (or rather LSDB-size window protocol
with selective retransmission but no detection of loss [or only very slow
based on lack of ACK & CSNPs]). Disadvantage of something like TCP (I think
I sent out the RFC with UDP control protocol work to make it more TCP like)
is that you are stuck when you put something into the pipe, no
prioritization possible and if receiver is slow you may have multiple
obsolete copies in the pipe waiting & lots retransmission BW when holes are
punched into the data through loss. And plain TCP  is actually quite bad
for control protocol traffic @ scale, almost all vendor run special version
of it for BGP for that reason. Why that is is out of scope of this list I
think ... Flooding is really good to send lots of data prioritized/in
parallel but on losses re-TX is slow.


> Bruno, if you're so deeply interested in that stuff we can talk 1:1
> off-line about implementation work on rift towards adapatable flooding
> rate
>
> [Bruno] Sure. My pleasure. Please propose me some timeslot offline. Please
> note that I’m based in Europe (CEST), so a priori during your morning and
> my evening.
>
> If you can also extend the offer to discuss the implementation work on the
> IS-IS implementation of your employer with regards to adaptable flooding
> rate, and/or how network operator can configure the CLI parameters of the
> LSP senders so as to improve flooding rate without overloading the Juniper
> receiver (possibly depending on the capability of the receiver, its number
> of IS-IS neighbors… and/or whatever parameter that you feel are relevant)
> that would be most appreciated. And if you believe that the Juniper LSP
> receiver can 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Les,

Please see inline

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, April 21, 2020 11:48 PM
To: DECRAENE Bruno TGI/OLN
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Bruno -

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
[Bruno] I don't think so. What makes you think so?
In all cases, that is not my assumption, and for multiple reasons.

That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment - 
though in my experience this knob is rarely used.
[Bruno] I would agree on both. More interestingly is the why: why aren't those 
existing sending parameters tuned, while we  agree that default configuration 
are suboptimal?
My take is that:

-  We don't want to overload the receiver and create loss of LSP (as 
this will delay the LSDB synchronization and decrease the goodput). Hence this 
(the parameters) is receiver dependent (e.g., platform type,  number of IGP 
adjacencies, ...).

-  We don't know which value to configure : difficult for the network 
operator to evaluate without a significant knowledge of the receiver 
implementation (in particular QoS parameters for incoming LSP), vendors are not 
really proposing value or guidance, especially since the sending behavior is 
not standardized and slightly different between vendors. So everyone stay safe 
with default 20 years old values.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn't the most appropriate, but historically 
the concern has been to avoid flooding too fast - not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change - 
which is something I think we have consensus on.

I have provided a description in my recent response as to why it is difficult 
to derive an optimal value on a per platform basis. You may disagree - but 
please do not claim that we actually have been doing this for years. We haven't 
been.
[Bruno] I'm not sure how to rephrase my below email so that we could understand 
each other, have an answer from your side (I mean employer side), and progress.
More succinctly: How do network operator correctly configure the flooding 
parameters value on the implementation of your employer? In particular given 
the variety of conditions on the LSP receiver side.

--Bruno

  Les

From: bruno.decra...@orange.com 
Sent: Monday, April 20, 2020 4:47 AM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

After nearly 2 months, can we expect an answer from your side?

More specifically, the below question

[Bruno] _Assuming_ that the parameters are static, the parameters proposed in 
draft-decraene-lsr-isis-flooding-speed are the same as the one implemented 
(configured) on multiple implementations, including the one from your employer.
Now do you believe that those parameters can be determined?

§  If yes, how do you do _today_ on your implementation? (this seems to 
contradict your statement that you have no way to figure out how to find the 
right value)

§  If no, why did you implement those parameters, and ask network operator to 
configure them?


Thank you,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Wednesday, February 26, 2020 8:03 PM
To: 'Les Ginsberg (ginsberg)'
Cc: lsr@ietf.org
Subject: RE: Flow Control Discussion for IS-IS Flooding Speed

Les,

Please see inline[Bruno]

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, February 19, 2020 3:32 AM
To: lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Base protocol operation of the Update process tracks the flooding of
LSPs/interface and guarantees timer-based retransmission on P2P interfaces
until an acknowledgment is received.

Using this base protocol mechanism in combination with exponential backoff of 
the
retransmission timer provides flow control in the event of temporary overload
of the receiver.

This mechanism works without protocol extensions, is dynamic, operates
independent of the reason for delayed acknowledgment (dropped packets, CPU
overload), and does not require additional signaling during the overloaded
period.

This is consistent with the recommendations in RFC 4222 (OSPF).

Receiver-based flow control (as proposed in 
https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ )
requires protocol extensions and introduces additional signaling during
periods of high load. The asserted reason for this is to optimize throughput -
but there is no evidence 

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[bruno.decraene]

Tony, all,

Thanks Tony for the technical and constructive feedback.
Please inline [Bruno]

From: Tony Przygienda [mailto:tonysi...@gmail.com]
Sent: Wednesday, April 22, 2020 1:19 AM
To: Les Ginsberg (ginsberg)
Cc: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

neither am I aware of anything like this (i.e. per platform/product flooding 
rate constants) in any major vendor stack for whatever that's worth. It's 
simply unmaintanable, point. All major vendors have extensive product lines 
over so many changing hardware configuration/setups it is simply not viable to 
attempt precise measurements (and even then, user changing config can throw the 
stuff off in a millisecond). There may have been here and there per deployment 
scenario some "recommended config" (not something I immediately recall either) 
but that means very fixed configuration of things & how they go into networks 
and even then I'm not aware of anyone having had a "precise model of the chain 
in the box". yes, probes to measure lots and lots of stuff in the boxes exist 
but again, those are chip/linecard/backplane/chassis/routing engine specific 
and mostly used in complex test/peformance scenarios and not to derive some 
kind of equations that can predict anything much ...
[Bruno] Good points.
Yet, one of the information that we propose to advertise by the LSP receiver to 
the LSP sender is the Receive Window.

-  This is a very common parameter and algorithm. Nothing fancy nor 
reinvented. In particular it’s a parameter used by TCP.

-  I would argue that TCP implementations also run on a variety of 
hardware and systems, must wider range than IS-IS platform. And those TCP 
implementations on all those platform manage to advertise this parameter (TCP 
window)

-  I fail to understand that when some WG contributors proposed the use 
of TCP, nobody said that determining and advertising a Receive Window would be 
an issue, difficult or even impossible. But when we propose to advertise a 
Receive Window in an IS-IS TLV, this becomes difficult or even impossible for 
some platforms. Can anyone help me understand the technical difference?

Bruno, if you're so deeply interested in that stuff we can talk 1:1 off-line 
about implementation work on rift towards adapatable flooding rate
[Bruno] Sure. My pleasure. Please propose me some timeslot offline. Please note 
that I’m based in Europe (CEST), so a priori during your morning and my evening.
If you can also extend the offer to discuss the implementation work on the 
IS-IS implementation of your employer with regards to adaptable flooding rate, 
and/or how network operator can configure the CLI parameters of the LSP senders 
so as to improve flooding rate without overloading the Juniper receiver 
(possibly depending on the capability of the receiver, its number of IS-IS 
neighbors… and/or whatever parameter that you feel are relevant) that would be 
most appreciated. And if you believe that the Juniper LSP receiver can handle 
any rate from any reasonable (e.g. 50)  number of IGP neighbors, without 
(significantly) dropping the received LSPs, that would be even simpler, please 
advise.

--Bruno
(algorithm you see in the -02 draft Les put out is a _very rough_ approximation 
of that BTW. I joined as co-author after we had some very fruitful discussions 
and I consider the draft close to what can be _realistically_ done  today in 
ISIS. I don't consider further details generic enough to merit wide forum 
discussions). And RIFT put a couple of things into packet formats we can't put 
into ISIS (I talked with Les about it) to improve the adaptability of the 
flooding rate BTW and some interesting, coarse indication from receiver. Again, 
this is not a constant that is calculated, it's all adaptive driven almost 
completely from the transmitter side and the feedback it gathers.

all my very own 2c

-- tony

On Tue, Apr 21, 2020 at 2:48 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Bruno –

You have made an assumption that historically vendors have tuned LSP 
transmission rates to a platform specific value.
That certainly is not true in the case of my employer (happy to hear what other 
vendors have been doing for the past 20 years).

The default value is based on minimumBroadcastLSPTransmissionInterval specified 
in ISO10589.
A knob is available to allow tuning (faster or slower) in a given deployment – 
though in my experience this knob is rarely used.

We already discuss in 
https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 
that this common interpretation isn’t the most appropriate, but historically 
the concern has been to avoid flooding too fast – not to optimize flooding 
speed.
Obviously, we are revisiting that approach and saying it needs to change – 
which is something I think we have consensus on.

I have provided a description in my recent response as to 

Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Acee Lindem (acee)]

Speaking as WG member:

In the past, we developed protocol encodings that afforded future 
extendibility. I don't see the problem with the including the SID structure 
sub-sub-TLV and would support progression.

Thanks,
Acee

On 4/10/20, 2:45 AM, "Lsr on behalf of Derek Yeung"  wrote:

Hi,

We at Arrcus have implemented support for this draft including the SID 
Structure sub-sub-TLV.
The proposed encodings for the SID Structure sub-sub-TLV is flexible and 
works fine.

Thanks,
Derek

Derek Yeung
de...@arrcus.com
Main: 408.884.1965



2077 Gateway Place, Suite 400
San Jose, CA.  95110

The contents of this message, together with any attachments, are intended 
only for the use of the individual or entity to which they are addressed and 
may contain information that is confidential and proprietary to Arrcus. If you 
are not the intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this message, or any attachment, is strictly 
prohibited. If you have received this message in error, please notify the 
original sender immediately by telephone or by return E-mail and delete this 
message, along with any attachments, from your computer. Thank you.


On 4/6/20, 4:03 AM, "Lsr on behalf of Peter Psenak"  wrote:

Chris,

On 01/04/2020 21:58, Chris Bowers wrote:
> Peter,
> 
> There seem to be two disconnects in this discussion.
> 
> 1) The response below implies that the encodings in 
> draft-ietf-lsr-isis-srv6-extensions are supposed represent the case 
> where the locators are allocated from several different IPv6 address 
> blocks (for example, blocks S1/s1 through Sn/sn). However, 
> draft-ietf-spring-srv6-network-programming and 
> draft-ietf-6man-segment-routing-header only discuss the case where 
the 
> locators are allocated from a single block (S/s).  If an 
implementation 
> is expected to properly encode the case where locators are allocated 
> from several different IPv6 address blocks, then I think that case 
> should be explicitly described in these documents.


There is no statement in draft-ietf-spring-srv6-network-programming 
that 
the block is unique. As an example, Iliad authorized me to indicate 
that 
their SRv6 deployment involves several blocks.


> 
> 2)   The response below says "To be able to find out where the func 
and 
> arg are located, you need to know the LOC length, e.g. Block and Node 
> length."  However, the SRv6 SID Structure Sub-Sub-TLV is carried 
within 
> the SRv6 End SID, SRv6 End.X SID, and the SRv6 LAN End.X SID 
Sub-TLVs, 
> which are carried within the SRv6 Locator TLV.  

not really. SRv6 End.X SID, and the SRv6 LAN End.X SID Sub-TLVs are 
advertised in the IS Reachability TLVs (22, 23, 222, 223, 141), not in 
SRv6 Locator TLV.

thanks,
Peter


> The  SRv6 Locator TLV 
> has a Loc-Size field.  Why would the value of the LOC length computed 
as 
> the sum of the Block and Node length ever be different from the value 
in 
> the Loc-Size field?
> 
> Chris
> 
> 
> On Wed, Mar 25, 2020 at 9:49 AM Peter Psenak  > wrote:
> 
> Chris,
> 
> please see inline:
> 
> 
> On 23/03/2020 17:39, Chris Bowers wrote:
>  > Peter,
>  >
>  > The proposed SRv6 SID Structure Sub-Sub-TLV has several 
problems.
>  >
>  > 1) As discussed in item#3 below, it is not clear that flooding 
LB
>  > Length, LN Length, Fun. Length, and Arg. Length to all ISIS
> speakers is
>  > really the right approach.  However, if the WG determines that 
it
> is the
>  > right approach, the current encodings of this information in 
the
>  > proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As
> discussed
>  > earlier in this thread, a network operator may choose to not
> allocate
>  > all locators from a single block, so LB Length and LN Length 
may
> not be
>  > well-defined.
> 
> I'm not sure what do you mean by not "well defined". For every 
SID you
> need to know the LOC (B+N) part. If you guarantee that it is the
> same on
> all nodes, you know it from the local config, otherwise, you 
advertise
> it with a SID.
> 
>  > The current encoding of the SRv6 SID Structure
>  > Sub-Sub-TLV makes it difficult to represent this situation.  
The
> simple
>  > thing to do for nodes that don't have a