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

[Tony Przygienda]

well, e'thing can be improved. I found what I suggesed since Les asked
works well enough ... As they say, your mileage may vary

whatever you suggest as absolute value in MaxLPSTx will not hold up the
test of time, 10/sec was a great value in 80s ...

--- tony

On Tue, Mar 10, 2020 at 3:39 PM Christian Hopps  wrote:

>
>
> > On Mar 10, 2020, at 11:22 AM, Tony Przygienda 
> wrote:
> >
> > Hey Christian, MaxTX is not that hard to derive since it's basically
> limited by the local system and its CPU/prioritization/queing architecture.
>
> Well so the value is "Fast as you can?" then? It's a specific value
> "MaxLSPTx" in the algorithm in the document though and it doesn't say "fast
> as you can" :)
>
> Maybe "Fast as you can" is OK, as long as we have some way to quickly
> adjust that and not keep returning to it so much that we lose more than we
> gain when the receiver has no way to handle it. This flooding traffic can
> be very bursty so taking too long to reach optimal isn't very good I would
> guess.
>
> For the rest, I wasn't actually being serious about using TCP, and your
> points are valid. I think there's some good stuff to maybe be paid
> attention to in those TCP friendly algorithms, but they don't fit our needs
> close enough for copying. FWIW I did add the necessary on wire data and
> documentation to IPTFS (ipsecme) to actually implement the DCCP style
> congestion control, and will probably end up coding it, hopefully in less
> than 10k LOC -- I'll let you know. :)
>
> My main reason for the mail was I do think the algorithm in the document
> can be improved, and the first and last part of my mail were some questions
> in that direction.
>
> Thanks,
> Chris.
> [as wg member]
>
> > For the rest of your email, in short, you have my observations in the
> previous email what I think is useful and can be done ... BTW, timestamps
> are useless unless you synchronize clocks and with all the queing that ISIS
> does through the system normally to get stuff done it is very hard to
> account for delays between packet being generated (or rx'ed on interface)
> and last queue it's pulled from usually. More musings below backed by good
> amount of work & empirical experience ;-)
>
>
>
> >
> > If we try to punt to TCP (like BGP did in its time which I argued wasn't
> the optimal idea that has bitten us back endless amount of times for the
> shortcut it was ;-) then de facto, no real heavy duty IP box is using stock
> TCP stack, at least in the scope of experience I have across bunch of
> leading vendors. If you worked on mod'ing TCP for convergence speed with
> BGP and cute little things like GR/NSR you will know the practical problems
> and also why stock TCP is actually fairly underwhelming when it comes to
> push large amounts of control data around (mod' distro, mod rusty 2c, mod
> etc but that's my data).
> >
> > And agreed, control theory is a wonderful thing and transfer windowing
> protocols etc are long research if you know where to look and lots of the
> stuff is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340
> and so on. All of them are quite a lot of stuff to put into ISIS/link-state
> and mostly do not do precisely what we need or precondition things we can't
> afford under heavy load (very fast, non slip timers which are absolutely
> non trivial if you're not in kernel). On top of that you'd need to drag 2
> protocol transports around now with old ISIS flooding with RE-TX and and
> the new thing that should be doing the stuff by itself (and negotiate
> transport on top and so on). To give you a rought idea DDCP which is
> probably smallest is ~ 10KLOC of C in user space in BETA and zero docs ;-)
> I looked @ the practically existing stuff 2+ years ago in detail when doing
> RIFT ;-) and with all what I practically found I ended up carving out the
> pieces we need for fast flooding without introducing fast-acks which IMO
> would be a non-starter for high scale link-state or rather, if we really
> want that, the loop closes and we should go practically speaking to TCP (or
> 4340 which looked like a better choice to me but  just like e.g. Open-R did
> and be done with it) or wait for the mythical QUIC all-singing-all-dancing
> public domain implementation maybe. For many reasons I do not think it
> would be a particularly good development entangling a control protocol
> again with a user transport in the whole ball of yarn that IP is already.
> >
> > kind of all I had to say, next thing ;-)
> >
> > --- tony
> >
> > On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps 
> wrote:
> >
> > Les Ginsberg (ginsberg)  writes:
> >
> > > Tony –
> > >
> > > If you have a suggestion for Tx back-off algorithm please feel free to
> share.
> > > The proposal in the draft is just a suggestion.
> > > As this is a local matter there is no interoperability issue, but
> certainly documenting a better algorithm is worthwhile.
> >
> > [as WG member]
> >
> > The main thing I'm afraid of is we're just making u

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Les Ginsberg (ginsberg)]

Chris/Acee -



I strongly agree with Peter.



There is no point in creating a protocol specific registry for behavior values 
which are protocol agnostic.

This only adds duplication (which is NOT the same as redundancy 😊 ).



What I find unfortunate is that the table in Section 10 of 
draft-ietf-lsr-isis-srv6-extensions-06.txt  has a "Behavior Endpoint Codepoint" 
column. That should be removed.

The legal behaviors to be advertised by IS-IS are then defined by name in 
column 1. If you want to find the numerical value(s) associated with that name 
then you refer to the registry created by 
draft-ietf-spring-srv6-network-programming.



   Les





> -Original Message-

> From: Lsr  On Behalf Of Christian Hopps

> Sent: Tuesday, March 10, 2020 4:51 AM

> To: Peter Psenak (ppsenak) 

> Cc: lsr@ietf.org; Christian Hopps ; Acee Lindem (acee)

> ; draft-ietf-lsr-isis-srv6-extensi...@ietf.org; Peter Psenak

> 

> Subject: Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-

> extensions-06.txt]

>

>

> Peter Psenak mailto:ppse...@cisco.com>> writes:

>

> > Hi Acee,

> >

> > On 09/03/2020 14:49, Acee Lindem (acee) wrote:

> >> Hi Peter, Chris,

> >>

> >> I agree that a number of IS-IS IANA registries have this level of

> specification. For example:

> >>

> >> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-

> codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223

> >

> > above is an ISIS specific registry and all external documents just updates

> this

> > protocol specific registry - e.g. the same link attribute defined in some

> > external document has different value in ISIS, OSPF, OSPFv3, etc.

> >

> > SRv6 SID behaviors are different, because they are not ISIS (protocol)

> specific

> > values - they apply to other protocols (OSPF, BGP-LS, ...). As such a 
> > protocol

> > independent registry defines them and each protocol just refers to it.

>

> The equivalent to these IS-IS sub-TLV registries would be to add "carried in

> IS-IS sub-TLV/OSPF-Sub-TLV/etc" columns to the SRv6 protocol-agnostic

> behavior registry. This does not seem the correct path to me as now you

> have various transport protocols adding columns to the protocol agnostic

> registry. Instead, I'm suggesting that we create protocol specific registries

> along-side the behavior value registry to document the protocol specific use,

> leaving a reference to these protocol registries in the behavior registry to 
> link

> them.

>

> Registries are non-normative, and you're not usurping or duplicating the role

> of the SRv6 behavior value registry by tracking additional protocol specific

> restrictions elsewhere by using one. Registries are there to help us keep

> track of stuff. In all the above cases (what goes where) it also helps make

> sure people *have* normatively documented *somewhere* all the cases

> they need to when adding new values/tvls.

>

> Do you think its better to modify the SRv6 registry directly and add protocol

> specific columns to it?

>

> Thanks,

> Chris.

> (as WG member)

>

> >

> > thanks,

> > Peter

> >

> >>

> >> Thanks,

> >> Acee

> >>

> >> On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps" 
> >> mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20cho...@chopps.org>

> boun...@ietf.org on behalf of 
> cho...@chopps.org>
>  wrote:

> >>

> >>> On Mar 9, 2020, at 6:36 AM, Peter Psenak

> >> mailto:ppsenak=40cisco@dmarc.ietf.org>>
> >>  wrote:

> >>  >

> >>  > Hi Chris,

> >>  >

> >>  > On 07/03/2020 15:46, Christian Hopps wrote:

> >>  >> 1) I think we should have an IANA registry instead of just a table

> defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06.

> >>  >> The registry could be cross-referenced by and to "SRv6 Endpoint

> Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...).

> If/when new behaviors are added they could then update where they are

> supposed to be advertised in the underlying protocols.

> >>  >

> >>  > why do we need a protocol specific registry to advertise values that

> are defined in another protocol independent registry? I have never seen

> such a duplication. Looks completely redundant to me.

> >>   You are creating some new sub TLVs (End, End.X, LAN End.X), and

> you

> >> are restricting and directing which externally defined behaviors (values)

> can

> >> be advertised in which of these TLVs. The registry would keep track of this

> >> (e.g., "Valid behaviors for sub-TLVs End, End.X, LAN End.X")

> >>   What happens when new behaviors are defined (externally), which

> TLVs

> >> are they su

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

[Christian Hopps]

> On Mar 10, 2020, at 11:22 AM, Tony Przygienda  wrote:
> 
> Hey Christian, MaxTX is not that hard to derive since it's basically limited 
> by the local system and its CPU/prioritization/queing architecture. 

Well so the value is "Fast as you can?" then? It's a specific value "MaxLSPTx" 
in the algorithm in the document though and it doesn't say "fast as you can" :)

Maybe "Fast as you can" is OK, as long as we have some way to quickly adjust 
that and not keep returning to it so much that we lose more than we gain when 
the receiver has no way to handle it. This flooding traffic can be very bursty 
so taking too long to reach optimal isn't very good I would guess.

For the rest, I wasn't actually being serious about using TCP, and your points 
are valid. I think there's some good stuff to maybe be paid attention to in 
those TCP friendly algorithms, but they don't fit our needs close enough for 
copying. FWIW I did add the necessary on wire data and documentation to IPTFS 
(ipsecme) to actually implement the DCCP style congestion control, and will 
probably end up coding it, hopefully in less than 10k LOC -- I'll let you know. 
:)

My main reason for the mail was I do think the algorithm in the document can be 
improved, and the first and last part of my mail were some questions in that 
direction.

Thanks,
Chris.
[as wg member]

> For the rest of your email, in short, you have my observations in the 
> previous email what I think is useful and can be done ... BTW, timestamps are 
> useless unless you synchronize clocks and with all the queing that ISIS does 
> through the system normally to get stuff done it is very hard to account for 
> delays between packet being generated (or rx'ed on interface) and last queue 
> it's pulled from usually. More musings below backed by good amount of work & 
> empirical experience ;-)



> 
> If we try to punt to TCP (like BGP did in its time which I argued wasn't the 
> optimal idea that has bitten us back endless amount of times for the shortcut 
> it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, 
> at least in the scope of experience I have across bunch of leading vendors. 
> If you worked on mod'ing TCP for convergence speed with BGP and cute little 
> things like GR/NSR you will know the practical problems and also why stock 
> TCP is actually fairly underwhelming when it comes to push large amounts of 
> control data around (mod' distro, mod rusty 2c, mod etc but that's my data).
> 
> And agreed, control theory is a wonderful thing and transfer windowing 
> protocols etc are long research if you know where to look and lots of the 
> stuff is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340 and 
> so on. All of them are quite a lot of stuff to put into ISIS/link-state and 
> mostly do not do precisely what we need or precondition things we can't 
> afford under heavy load (very fast, non slip timers which are absolutely non 
> trivial if you're not in kernel). On top of that you'd need to drag 2 
> protocol transports around now with old ISIS flooding with RE-TX and and the 
> new thing that should be doing the stuff by itself (and negotiate transport 
> on top and so on). To give you a rought idea DDCP which is probably smallest 
> is ~ 10KLOC of C in user space in BETA and zero docs ;-) I looked @ the 
> practically existing stuff 2+ years ago in detail when doing RIFT ;-) and 
> with all what I practically found I ended up carving out the pieces we need 
> for fast flooding without introducing fast-acks which IMO would be a 
> non-starter for high scale link-state or rather, if we really want that, the 
> loop closes and we should go practically speaking to TCP (or 4340 which 
> looked like a better choice to me but  just like e.g. Open-R did and be done 
> with it) or wait for the mythical QUIC all-singing-all-dancing public domain 
> implementation maybe. For many reasons I do not think it would be a 
> particularly good development entangling a control protocol again with a user 
> transport in the whole ball of yarn that IP is already. 
> 
> kind of all I had to say, next thing ;-)
> 
> --- tony 
> 
> On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps  wrote:
> 
> Les Ginsberg (ginsberg)  writes:
> 
> > Tony –
> >
> > If you have a suggestion for Tx back-off algorithm please feel free to 
> > share.
> > The proposal in the draft is just a suggestion.
> > As this is a local matter there is no interoperability issue, but certainly 
> > documenting a better algorithm is worthwhile.
> 
> [as WG member]
> 
> The main thing I'm afraid of is we're just making up some new overly simple 
> congestion control algorithm (are there CC experts reviewing this?); maybe 
> simulate it a few ways, deploy it, and have it work poorly or make things 
> worse. In any case, damn the torpedos...
> 
> In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx 
> is too high? If its too low we could be missing a much 

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

[Tony Przygienda]

On Tue, Mar 10, 2020 at 9:43 AM  wrote:

> With regards to punting to TCP, I think that TCP (stacks) enforce packet
> ordering.
>
> i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1
> until you receive packet 2. In the meantime, you cannot use the (N-2)
> packets that you did received.
>
> That seems like a regression for IS-IS which doesn’t requiring LSPs
> ordering. (vs BGP).
>

well, TCP is a windowing protocol and they're hard and very
bandwidth*delay/loss/jitter sensitive and yes, TCP is reliable transport
and not unreliable like ISIS flooding is ... Having said that, insane
amount of work has been done on TCP variants in all kind of stacks &
flavors coming full circle from fast start to slow start to fast start
again ;-)

Stepping back a bit, what we have in ISIS is basically a DHT and the
fastest way to synchronize that AFAIS is bittorrent transport ;-) When
doing RIFT I looked @ their transport & one can learn a lot from that but
it's a brave new world compared to the esteemed 10589 ;-) If one does that
kind of transport well, it blows TCP perf away in good scenario but then,
if we look for something 'download-open-source-and-plugin' kind except some
10 years old DCCP code you ain't gonna find anything massively hardened,
small or easily pluggable into an ISIS implementation. modulo open source
quic i didn't check the state off for last year or so or some secret sauce
someone found or maybe some of the p2p code got modularized and documented
;-) ...


>
> Also, from what I’ve been told from BGP implementers, TCP is not magic and
> can’t be treated as a black box (if you want scale/performance).
>

that's a mild understatement if you ask me after having lived in the
trenches since 1995 or so ;-)  On the other hand, the work has been done
often already and could be piggy-backed on but then, we buy ourselves
mandatory IP addressing into ISIS transport and lots of other interesting,
undesirable things TCP does since it's not a hop-by-hop transport but
"something that always tries to find a way". And next thing we'll need
TCP-AO so beware what you wish for ;-)

--- tony
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[bruno.decraene]

With regards to punting to TCP, I think that TCP (stacks) enforce packet 
ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until 
you receive packet 2. In the meantime, you cannot use the (N-2) packets that 
you did received.
That seems like a regression for IS-IS which doesn’t requiring LSPs ordering. 
(vs BGP).

Also, from what I’ve been told from BGP implementers, TCP is not magic and 
can’t be treated as a black box (if you want scale/performance).

1 cent
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Tuesday, March 10, 2020 4:23 PM
To: Christian Hopps
Cc: lsr@ietf.org; tony...@tony.li; Tony Li; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hey Christian, MaxTX is not that hard to derive since it's basically limited by 
the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the previous 
email what I think is useful and can be done ... BTW, timestamps are useless 
unless you synchronize clocks and with all the queing that ISIS does through 
the system normally to get stuff done it is very hard to account for delays 
between packet being generated (or rx'ed on interface) and last queue it's 
pulled from usually. More musings below backed by good amount of work & 
empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't the 
optimal idea that has bitten us back endless amount of times for the shortcut 
it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, 
at least in the scope of experience I have across bunch of leading vendors. If 
you worked on mod'ing TCP for convergence speed with BGP and cute little things 
like GR/NSR you will know the practical problems and also why stock TCP is 
actually fairly underwhelming when it comes to push large amounts of control 
data around (mod' distro, mod rusty 2c, mod etc but that's my data)..

And agreed, control theory is a wonderful thing and transfer windowing 
protocols etc are long research if you know where to look and lots of the stuff 
is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340 and so on. 
All of them are quite a lot of stuff to put into ISIS/link-state and mostly do 
not do precisely what we need or precondition things we can't afford under 
heavy load (very fast, non slip timers which are absolutely non trivial if 
you're not in kernel). On top of that you'd need to drag 2 protocol transports 
around now with old ISIS flooding with RE-TX and and the new thing that should 
be doing the stuff by itself (and negotiate transport on top and so on). To 
give you a rought idea DDCP which is probably smallest is ~ 10KLOC of C in user 
space in BETA and zero docs ;-) I looked @ the practically existing stuff 2+ 
years ago in detail when doing RIFT ;-) and with all what I practically found I 
ended up carving out the pieces we need for fast flooding without introducing 
fast-acks which IMO would be a non-starter for high scale link-state or rather, 
if we really want that, the loop closes and we should go practically speaking 
to TCP (or 4340 which looked like a better choice to me but  just like e.g. 
Open-R did and be done with it) or wait for the mythical QUIC 
all-singing-all-dancing public domain implementation maybe. For many reasons I 
do not think it would be a particularly good development entangling a control 
protocol again with a user transport in the whole ball of yarn that IP is 
already.

kind of all I had to say, next thing ;-)

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps 
mailto:cho...@chopps.org>> wrote:

Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> writes:

> Tony –
>
> If you have a suggestion for Tx back-off algorithm please feel free to share.
> The proposal in the draft is just a suggestion.
> As this is a local matter there is no interoperability issue, but certainly 
> documenting a better algorithm is worthwhile.

[as WG member]

The main thing I'm afraid of is we're just making up some new overly simple 
congestion control algorithm (are there CC experts reviewing this?); maybe 
simulate it a few ways, deploy it, and have it work poorly or make things 
worse. In any case, damn the torpedos...

In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx 
is too high? If its too low we could be missing a much faster convergence 
capability.

What if we had more quality information from the receiver, could we do a better 
job here? Maybe faster ACKs, or could we include a timestamp somehow to 
calculate RTT? This is the type of data that is used by existing CC algorithms 
(https://tools.ietf.org/html/rfc4342, https://tools.ietf.org/html/rfc5348). Of 
course going through these documents (which I've had to do for in another area) 
can start making one think "Punt to TCP" :)

What would be nice, if we're going to attempt CC

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

[Tony Przygienda]

Hey Christian, MaxTX is not that hard to derive since it's basically
limited by the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the
previous email what I think is useful and can be done ... BTW, timestamps
are useless unless you synchronize clocks and with all the queing that ISIS
does through the system normally to get stuff done it is very hard to
account for delays between packet being generated (or rx'ed on interface)
and last queue it's pulled from usually. More musings below backed by good
amount of work & empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't
the optimal idea that has bitten us back endless amount of times for the
shortcut it was ;-) then de facto, no real heavy duty IP box is using stock
TCP stack, at least in the scope of experience I have across bunch of
leading vendors. If you worked on mod'ing TCP for convergence speed with
BGP and cute little things like GR/NSR you will know the practical problems
and also why stock TCP is actually fairly underwhelming when it comes to
push large amounts of control data around (mod' distro, mod rusty 2c, mod
etc but that's my data).

And agreed, control theory is a wonderful thing and transfer windowing
protocols etc are long research if you know where to look and lots of the
stuff is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340
and so on. All of them are quite a lot of stuff to put into ISIS/link-state
and mostly do not do precisely what we need or precondition things we can't
afford under heavy load (very fast, non slip timers which are absolutely
non trivial if you're not in kernel). On top of that you'd need to drag 2
protocol transports around now with old ISIS flooding with RE-TX and and
the new thing that should be doing the stuff by itself (and negotiate
transport on top and so on). To give you a rought idea DDCP which is
probably smallest is ~ 10KLOC of C in user space in BETA and zero docs ;-)
I looked @ the practically existing stuff 2+ years ago in detail when doing
RIFT ;-) and with all what I practically found I ended up carving out the
pieces we need for fast flooding without introducing fast-acks which IMO
would be a non-starter for high scale link-state or rather, if we really
want that, the loop closes and we should go practically speaking to TCP (or
4340 which looked like a better choice to me but  just like e.g. Open-R did
and be done with it) or wait for the mythical QUIC all-singing-all-dancing
public domain implementation maybe. For many reasons I do not think it
would be a particularly good development entangling a control protocol
again with a user transport in the whole ball of yarn that IP is already.

kind of all I had to say, next thing ;-)

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps  wrote:

>
> Les Ginsberg (ginsberg)  writes:
>
> > Tony –
> >
> > If you have a suggestion for Tx back-off algorithm please feel free to
> share.
> > The proposal in the draft is just a suggestion.
> > As this is a local matter there is no interoperability issue, but
> certainly documenting a better algorithm is worthwhile.
>
> [as WG member]
>
> The main thing I'm afraid of is we're just making up some new overly
> simple congestion control algorithm (are there CC experts reviewing this?);
> maybe simulate it a few ways, deploy it, and have it work poorly or make
> things worse. In any case, damn the torpedos...
>
> In this current algorithm how does MaxLSPTx get set? What happens if
> MaxLSPTx is too high? If its too low we could be missing a much faster
> convergence capability.
>
> What if we had more quality information from the receiver, could we do a
> better job here? Maybe faster ACKs, or could we include a timestamp somehow
> to calculate RTT? This is the type of data that is used by existing CC
> algorithms (https://tools.ietf.org/html/rfc4342,
> https://tools.ietf.org/html/rfc5348). Of course going through these
> documents (which I've had to do for in another area) can start making one
> think "Punt to TCP" :)
>
> What would be nice, if we're going to attempt CC, is that the algorithm
> would be good enough to send relatively fast to start, adjust quickly if
> need be, and allow for *increasing* the send rate. The increasing part I
> think is important, if we take this work on, and I don't think it's
> currently covered.
>
> I also don't have a good feel for how quickly the current suggested
> algorithm adjusts its send rate when it needs to. The correct value for
> Usafe seems very much dependent on the receivers partialSNPInterval. It's
> so dependent that one might imagine it would be smart for the receiver to
> signal the value to the transmitter so that the transmitter can set Usafe
> correctly.
>
> Thanks,
> Chris.
> [as WG member]
>
>
>
> >
> >Les (claws in check 😊 )
> >
> >
> > From: Tony Przygienda 
> > Sent: Wednesday, February 19, 2020 11:25 AM
> 

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

[Christian Hopps]

Les Ginsberg (ginsberg)  writes:


Tony –

If you have a suggestion for Tx back-off algorithm please feel free to share.
The proposal in the draft is just a suggestion.
As this is a local matter there is no interoperability issue, but certainly 
documenting a better algorithm is worthwhile.


[as WG member]

The main thing I'm afraid of is we're just making up some new overly simple 
congestion control algorithm (are there CC experts reviewing this?); maybe 
simulate it a few ways, deploy it, and have it work poorly or make things 
worse. In any case, damn the torpedos...

In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx 
is too high? If its too low we could be missing a much faster convergence 
capability.

What if we had more quality information from the receiver, could we do a better job here? 
Maybe faster ACKs, or could we include a timestamp somehow to calculate RTT? This is the 
type of data that is used by existing CC algorithms (https://tools.ietf.org/html/rfc4342, 
https://tools.ietf.org/html/rfc5348). Of course going through these documents (which I've 
had to do for in another area) can start making one think "Punt to TCP" :)

What would be nice, if we're going to attempt CC, is that the algorithm would 
be good enough to send relatively fast to start, adjust quickly if need be, and 
allow for *increasing* the send rate. The increasing part I think is important, 
if we take this work on, and I don't think it's currently covered.

I also don't have a good feel for how quickly the current suggested algorithm 
adjusts its send rate when it needs to. The correct value for Usafe seems very 
much dependent on the receivers partialSNPInterval. It's so dependent that one 
might imagine it would be smart for the receiver to signal the value to the 
transmitter so that the transmitter can set Usafe correctly.

Thanks,
Chris.
[as WG member]





   Les (claws in check 😊 )


From: Tony Przygienda 
Sent: Wednesday, February 19, 2020 11:25 AM
To: Les Ginsberg (ginsberg) 
Cc: Peter Psenak (ppsenak) ; Tony Li 
; lsr@ietf.org; tony...@tony.li
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Having worked for last couple of years on implementation of flooding speeds 
that converge LSDBs some order of magnitudes above today's speeds  ;-) here's a 
bunch of observations

1. TX side is easy and useful. My observation having gone quickly over the 
-ginsberg- draft is that you really want a better hysterisis there, it's bit 
too vertical and you will generate oscillations rather than walk around the 
equilibrium ;-)
2. Queue per interface is fairly trivial with modern implementation techniques 
and memory sizes if done correctly. Yes, very memory constrained platforms are 
a mildly different game and kind of precondition a different discussion.
3. RX side is possible and somewhat useful but much harder to do well depending on 
flavor. If we're talking about the RX advertising a very static value to cap the 
flooding speed that's actually a useful knob to have IMO/IME. Trying to cleverly 
communicate to the TXer a window size is not only fiendishly difficult, incurs back 
propagation speed (not neglectible @ those rates IME) but can easily lead to subtle 
flood starvation behaviors and lots of slow starts due to mixture of control loop 
dynamics and implementation complexity of such a scheme. Though, giving the TXer 
some hint that a backpressure is desired is however not a bad thing IME and can be 
derived failry easily without needs for checking queue sizes and so on. It's 
observable by looking @ some standard stats on what is productive incoming rate on 
the interface. Anything smarter needs new TLVs on packets & then you have a 
problem under/oversampling based on hellos (too low a frequency) and ACKs (too 
bursty, too batchy) and flooded back LSPs (too unpredictable)

For more details I can recommend rift draft of course ;-)

otherwise I'm staying out from this mildly feline spat ;-)

--- tony

On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Tony -

Peter has a done a great job of highlighting that "single queue" is an 
oversimplification - I have nothing to add to that discussion.

I would like to point out another aspect of the Rx based solution.

As you need to send signaling based upon dynamic receiver state and this 
signaling is contained in unreliable PDUs (hellos) and to be useful this 
signaling needs to be sent ASAP - you cannot wait until the next periodic hello 
interval (default 10 seconds) to expire. So you are going to have to introduce 
extra hello traffic at a time when protocol input queues are already stressed.

Given hellos are unreliable, the question of how many transmissions of the 
update flow info is enough arises. You could make this more deterministic by 
enhancing the new TLV to include information received from the neighbor so that 
each side would know when the neighbor had received the up

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Christian Hopps]

Peter Psenak  writes:


Hi Acee,

On 09/03/2020 14:49, Acee Lindem (acee) wrote:

Hi Peter, Chris,

I agree that a number of IS-IS IANA registries have this level of 
specification. For example:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223


above is an ISIS specific registry and all external documents just updates this
protocol specific registry - e.g. the same link attribute defined in some
external document has different value in ISIS, OSPF, OSPFv3, etc.

SRv6 SID behaviors are different, because they are not ISIS (protocol) specific
values - they apply to other protocols (OSPF, BGP-LS, ...). As such a protocol
independent registry defines them and each protocol just refers to it.


The equivalent to these IS-IS sub-TLV registries would be to add "carried in IS-IS 
sub-TLV/OSPF-Sub-TLV/etc" columns to the SRv6 protocol-agnostic behavior registry. 
This does not seem the correct path to me as now you have various transport protocols 
adding columns to the protocol agnostic registry. Instead, I'm suggesting that we create 
protocol specific registries along-side the behavior value registry to document the 
protocol specific use, leaving a reference to these protocol registries in the behavior 
registry to link them.

Registries are non-normative, and you're not usurping or duplicating the role 
of the SRv6 behavior value registry by tracking additional protocol specific 
restrictions elsewhere by using one. Registries are there to help us keep track 
of stuff. In all the above cases (what goes where) it also helps make sure 
people *have* normatively documented *somewhere* all the cases they need to 
when adding new values/tvls.

Do you think its better to modify the SRv6 registry directly and add protocol 
specific columns to it?

Thanks,
Chris.
(as WG member)



thanks,
Peter



Thanks,
Acee

On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps"  wrote:

   > On Mar 9, 2020, at 6:36 AM, Peter Psenak
 wrote:
 >
 > Hi Chris,
 >
 > On 07/03/2020 15:46, Christian Hopps wrote:
 >> 1) I think we should have an IANA registry instead of just a table 
defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06.
 >> The registry could be cross-referenced by and to "SRv6 Endpoint 
Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). If/when new 
behaviors are added they could then update where they are supposed to be advertised in the 
underlying protocols.
 >
 > why do we need a protocol specific registry to advertise values that are 
defined in another protocol independent registry? I have never seen such a 
duplication. Looks completely redundant to me.
  You are creating some new sub TLVs (End, End.X, LAN End.X), and you
are restricting and directing which externally defined behaviors (values) can
be advertised in which of these TLVs. The registry would keep track of this
(e.g., "Valid behaviors for sub-TLVs End, End.X, LAN End.X")
  What happens when new behaviors are defined (externally), which TLVs
are they supposed to be advertised in? Either the document that defines the
new behavior or a related LSR document will have to indicate where this new
behavior should be advertised too. That new document would update this
registry to track that. Keeping track of this stuff is what registries are
for.
  Your table literally looks like a template for the initial content
of a registry. :)
  Later in your IANA section you are updating other registries that
bear a striking resemblance to this (e.g., what sub-TLV types are valid to
advertise in what TLVs).
  >> 2) It's odd that we are referring to the section as "Legal
Behaviors" in the TLV definitions, and then in the actual section using "MAY"
terms and no "MUST"/"MUST NOT", but then using "Yes" and "No" in the table.
 >
 > a) Legal Behavior - refers to the set of values defined in the 
[I-D.ietf-spring-srv6-network-programming] which can be advertised in a particular 
TLV
 >
 > b) We can not use MUST in section 10, as all these TLVs are optional
  What's wrong with "If this behavior is advertised it MUST only be
advertised in the TLV[s] as indicated by "Y" in the table below, and MUST NOT
be advertised in the TLV[s] as indicated by "N" in the table below." or
something like that.
  Thanks,
 Chris.
 (as WG member)
   > c) Yes/No means whether the particular behavior is allowed in
the particular END-SID TLV.
 >
 >> Are these suggestions or are they documenting the required behavior?
 >
 > these are limitations as to which behavior is allowed to be advertised 
in which TLV.
 > thanks,
 > Peter
 >
 >> Thanks,
 >> Chris.
 >
 > ___
 > Lsr mailing list
 > Lsr@ietf.org
 > https://www.ietf.org/mailman/listinfo/lsr
 >
  ___

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Peter Psenak]

Chris,

On 09/03/2020 13:26, Christian Hopps wrote:




On Mar 9, 2020, at 6:36 AM, Peter Psenak  
wrote:

Hi Chris,

On 07/03/2020 15:46, Christian Hopps wrote:

1) I think we should have an IANA registry instead of just a table defined in 
section 10 of draft-ietf-lsr-isis-srv6-extensions-06.
The registry could be cross-referenced by and to "SRv6 Endpoint Behaviors" for 
each protocol carrying these behaviors (IS-IS, OSPFv3, ...). If/when new behaviors are 
added they could then update where they are supposed to be advertised in the underlying 
protocols.


why do we need a protocol specific registry to advertise values that are 
defined in another protocol independent registry? I have never seen such a 
duplication. Looks completely redundant to me.


You are creating some new sub TLVs (End, End.X, LAN End.X), and you are restricting and 
directing which externally defined behaviors (values) can be advertised in which of these 
TLVs. The registry would keep track of this (e.g., "Valid behaviors for sub-TLVs 
End, End.X, LAN End.X")

What happens when new behaviors are defined (externally), which TLVs are they supposed to be advertised in? Either the document that defines the new behavior or a related LSR document will have to indicate where this new behavior should be advertised too. 


yes.


That new document would update this registry to track that. Keeping track of 
this stuff is what registries are for.

Your table literally looks like a template for the initial content of a 
registry. :)


I still do not see a need for an ISIS (or any protocol specific) registry.



Later in your IANA section you are updating other registries that bear a 
striking resemblance to this (e.g., what sub-TLV types are valid to advertise 
in what TLVs).


2) It's odd that we are referring to the section as "Legal Behaviors" in the TLV definitions, and then in the actual section 
using "MAY" terms and no "MUST"/"MUST NOT", but then using "Yes" and "No" in the table.


a) Legal Behavior - refers to the set of values defined in the 
[I-D.ietf-spring-srv6-network-programming] which can be advertised in a 
particular TLV

b) We can not use MUST in section 10, as all these TLVs are optional


What's wrong with "If this behavior is advertised it MUST only be advertised in the TLV[s] as indicated 
by "Y" in the table below, and MUST NOT be advertised in the TLV[s] as indicated by "N" 
in the table below." or something like that.\


sure, I can update the text as above.

thanks,
Peter


Thanks,
Chris.
(as WG member)



c) Yes/No means whether the particular behavior is allowed in the particular 
END-SID TLV.


Are these suggestions or are they documenting the required behavior?


these are limitations as to which behavior is allowed to be advertised in which 
TLV.
thanks,
Peter


Thanks,
Chris.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr







___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] "Legal" endpoint behaviors [draft-ietf-lsr-isis-srv6-extensions-06.txt]

[Peter Psenak]

Hi Acee,

On 09/03/2020 14:49, Acee Lindem (acee) wrote:

Hi Peter, Chris,

I agree that a number of IS-IS IANA registries have this level of 
specification. For example:

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223


above is an ISIS specific registry and all external documents just 
updates this protocol specific registry - e.g. the same link attribute 
defined in some external document has different value in ISIS, OSPF, 
OSPFv3, etc.


SRv6 SID behaviors are different, because they are not ISIS (protocol) 
specific values - they apply to other protocols (OSPF, BGP-LS, ...). As 
such a protocol independent registry defines them and each protocol just 
refers to it.


thanks,
Peter



Thanks,
Acee

On 3/9/20, 8:28 AM, "Lsr on behalf of Christian Hopps"  wrote:

 
 
 > On Mar 9, 2020, at 6:36 AM, Peter Psenak  wrote:

 >
 > Hi Chris,
 >
 > On 07/03/2020 15:46, Christian Hopps wrote:
 >> 1) I think we should have an IANA registry instead of just a table 
defined in section 10 of draft-ietf-lsr-isis-srv6-extensions-06.
 >> The registry could be cross-referenced by and to "SRv6 Endpoint 
Behaviors" for each protocol carrying these behaviors (IS-IS, OSPFv3, ...). If/when new 
behaviors are added they could then update where they are supposed to be advertised in the 
underlying protocols.
 >
 > why do we need a protocol specific registry to advertise values that are 
defined in another protocol independent registry? I have never seen such a 
duplication. Looks completely redundant to me.
 
 You are creating some new sub TLVs (End, End.X, LAN End.X), and you are restricting and directing which externally defined behaviors (values) can be advertised in which of these TLVs. The registry would keep track of this (e.g., "Valid behaviors for sub-TLVs End, End.X, LAN End.X")
 
 What happens when new behaviors are defined (externally), which TLVs are they supposed to be advertised in? Either the document that defines the new behavior or a related LSR document will have to indicate where this new behavior should be advertised too. That new document would update this registry to track that. Keeping track of this stuff is what registries are for.
 
 Your table literally looks like a template for the initial content of a registry. :)
 
 Later in your IANA section you are updating other registries that bear a striking resemblance to this (e.g., what sub-TLV types are valid to advertise in what TLVs).
 
 >> 2) It's odd that we are referring to the section as "Legal Behaviors" in the TLV definitions, and then in the actual section using "MAY" terms and no "MUST"/"MUST NOT", but then using "Yes" and "No" in the table.

 >
 > a) Legal Behavior - refers to the set of values defined in the 
[I-D.ietf-spring-srv6-network-programming] which can be advertised in a particular 
TLV
 >
 > b) We can not use MUST in section 10, as all these TLVs are optional
 
 What's wrong with "If this behavior is advertised it MUST only be advertised in the TLV[s] as indicated by "Y" in the table below, and MUST NOT be advertised in the TLV[s] as indicated by "N" in the table below." or something like that.
 
 Thanks,

 Chris.
 (as WG member)
 
 
 > c) Yes/No means whether the particular behavior is allowed in the particular END-SID TLV.

 >
 >> Are these suggestions or are they documenting the required behavior?
 >
 > these are limitations as to which behavior is allowed to be advertised 
in which TLV.
 > thanks,
 > Peter
 >
 >> Thanks,
 >> Chris.
 >
 > ___
 > Lsr mailing list
 > Lsr@ietf.org
 > https://www.ietf.org/mailman/listinfo/lsr
 >
 
 ___

 Lsr mailing list
 Lsr@ietf.org
 https://www.ietf.org/mailman/listinfo/lsr
 






___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

[wangyali]

Dear Les,

Thanks a lot for your comments. I will take your suggestion to add description 
on how to use the IFIT Capability information when the submission is opened.

As described in my reply to Acee, following is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One network 
domain may consists of multiple IFIT domain. Within the IFIT domain, one or 
more IFIT-options are added into packet at the IFIT-enabled head node that is 
referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY be 
updated by IFIT transit nodes that the packet traverses. Finally, the data 
fields are removed at a device that is referred to as the “IFIT decapsulating 
node”.

The IFIT data fields must not leak to other domains. So, the IFIT encapsulating 
node need to know if the decapsulating node is able to support the IFIT 
capability. So that it can decide whether to add the IFIT-option or not.

The solution is similar to RFC8491. We use IGP to advertise the capability, so 
that head node can use. By using BGP-LS, a centralized controller can also 
learn the IFIT Capability of nodes to determine whether a particular IFIT 
Option type can be supported in a given network.

Best regards,
Yali

发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2020年3月10日 5:07
收件人: wangyali ; lsr@ietf.org
主题: RE: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Yali �C

What is missing for me is an explanation of why IFIT Capability information is 
something that is appropriate to be sent using IGP Router Capability 
advertisements.

Generally speaking, we prefer to restrict IGP advertisements to information 
which is of direct use to the protocol. However, it is fair to say that we have 
relaxed this restriction in some cases e.g.:

https://www.iana.org/go/rfc7883
https://www.iana.org/go/rfc8491

However, even in these cases the information advertised is of value to some 
entity executing on the protocol peers �C even if not directly by the IGP 
itself.

I see no such value add here i.e., the IFIT capability information may well be 
of value to a controller but I do not see any use case for any entity on 
protocol peers.
So why should we use IGPs to send this information to all other IGP peers when 
none of them can make use of this information?

Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
wangyali
Sent: Monday, March 09, 2020 1:21 AM
To: lsr@ietf.org
Subject: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

Dear all,

I’m Yali. Following is a new version of I-D, 
draft-liu-lsr-isis-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>

Name:   draft-liu-lsr-isis-ifit-node-capability

Revision:  02

Title:  IS-IS Extensions for Advertising IFIT Node Capability

Document date:   2020-03-09

Group:   Individual Submission

Pages:   7

URL:
https://www.ietf.org/internet-drafts/draft-liu-lsr-isis-ifit-node-capability-02.txt

Status: 
https://datatracker.ietf.org/doc/draft-liu-lsr-isis-ifit-node-capability/

Htmlized:   
https://tools.ietf.org/html/draft-liu-lsr-isis-ifit-node-capability-02

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-liu-lsr-isis-ifit-node-capability

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-liu-lsr-isis-ifit-node-capability-02



Abstract:

   This document defines a way for an Intermediate System to

   Intermediate System (IS-IS) routers to advertise IFIT(in-situ Flow

   Information Telemetry) capabilities.  This document extends a new

   optional sub-TLV in the IS-IS Router CAPABILITY TLV [RFC7981], which

   allows a router to announce its IFIT node capabilities within an IS-

   IS level or the entire routing domain.  Such advertisements enable

   IFIT applications in the network domain.


Best Regards,
Yali WANG
E: wangyal...@huawei.com

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: New Version Notification for draft-wang-lsr-ospf-ifit-node-capability-02

[wangyali]

Dear Acee,

Thanks a lot for your comments. I have revised the title of drafts and will 
take your suggestion to add more text on how to use the IFIT Capability 
information, once the submission is opened. Here is my quick reply:

IFIT is deployed in a specific domain referred as the IFIT domain. One network 
domain may consists of multiple IFIT domain. Within the IFIT domain, one or 
more IFIT-options are added into packet at the IFIT-enabled head node that is 
referred to as the “IFIT encapsulating node”. Then IFIT data fields MAY be 
updated by IFIT transit nodes that the packet traverses. Finally, the data 
fields are removed at a device that is referred to as the “IFIT decapsulating 
node”. 

The IFIT data fields must not leak to other domains. So, the IFIT encapsulating 
node need to know if the decapsulating node is able to support the IFIT 
capability. So that it can decide whether to add the IFIT-option or not.

The solution is similar to RFC8491. We use IGP to advertise the capability, so 
that head node can use. By using BGP-LS, a centralized controller can also 
learn the IFIT Capability of nodes to determine whether a particular IFIT 
Option type can be supported in a given network.

Best regards,
Yali

-邮件原件-
发件人: Acee Lindem (acee) [mailto:a...@cisco.com] 
发送时间: 2020年3月9日 18:30
收件人: wangyali ; lsr@ietf.org
主题: Re: [Lsr] New Version Notification for 
draft-wang-lsr-ospf-ifit-node-capability-02

Hi Yali,

A couple of very basic comments on these drafts. They are definitely not ready 
for consideration. 

1. IFIT is never expanded as an acronym. Seems it should be as early as the 
title. 

  OSPF extensions for Advertising In-Situ Flow Information Telemetry 
(IFIT) Capability

   2. You probably could come up with a more succinct acronym for IFIT. 

   3. The has no specification of how the capabilities are used. Are they 
purely informational? 

Thanks,
Acee

 


On 3/9/20, 4:33 AM, "Lsr on behalf of wangyali"  wrote:

Dear all,

I'm Yali. Following is a new version of I-D, 
draft-wang-lsr-ospf-ifit-node-capability-02 I submitted recently.

Please let me know your questions and comments. Thank you.

>>>
Name:   draft-wang-lsr-ospf-ifit-node-capability
Revision:   02
Title:  Extensions to OSPF for Advertising IFIT Node Capability
Document date:  2020-03-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-ifit-node-capability-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-ifit-node-capability/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-ospf-ifit-node-capability-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-ospf-ifit-node-capability
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-ospf-ifit-node-capability-02

Abstract:
   This document defines a way for an Open Shortest Path First (OSPF)
   router originating the RI LSA to announce IFIT node capabilities
   within the entire routing domain.  A new optional TLV is extended to
   the OSPF RI Opaque LSA [RFC7770] to carry the IFIT node capability
   information.  Such advertisements enable IFIT applications in an
   operational network domain.  Here, the term "OSPF" includes both
   OSPFv2 and OSPFv3.

Best regards,
Yali WANG
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr