Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Les Ginsberg (ginsberg)
quot;reinvent TCP" - but I do think you have provided a useful perspective for us to consider as we progress on this topic, Thanx. Les > -Original Message- > From: Lsr On Behalf Of Henk Smit > Sent: Thursday, April 30, 2020 6:58 AM > To: lsr@ietf.org > S

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Christian Hopps
> On May 4, 2020, at 5:47 AM, Henk Smit wrote: > > I'm looking forward to seeing (an outline of) your algorithm. I'm not trying to push any particular algorithm, we already have some proposals. My intention was only to suggest that we not disregard solutions too aggressively. The argument

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Henk Smit
Mitchel wrote: IS-IS has two levels of neighbors via hello level 1s (LSAs) and hello level 2s :, so immediate is somewhat relative.. As Tony said, Level-2 neighbors are still directly adjacent. There might be layer-2 switches between them. But there are never layer-3 routers between 2

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Henk Smit
On Friday I wrote: I still think we'll end up re-implementing a new (and weaker) TCP. Christian Hopps wrote 2020-05-04 01:27: Let's not be too cynical at the start though! :) I wasn't trying to be cynical. Let me explain my line of reasoning two years ago. When reading about the

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Mitchell Erblich
Inline… Mitchell Erblich Implementation of IS-IS for Extreme Networks in what seems Eons ago… erbli...@earthlink.net > On May 3, 2020, at 11:12 PM, tony...@tony.li wrote: > > > Mitchell, > >> I think we/you are looking at two different problems: >> 1) a hop count of 1

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread tony . li
Mitchell, > I think we/you are looking at two different problems: > 1) a hop count of 1 or maybe two between the two end points 2) and the > multiple / many hop count between the two end points. IS-IS adjacencies are always between immediate L3 neighbors, ignoring

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-03 Thread Mitchell Erblich
Group, I think we/you are looking at two different problems: 1) a hop count of 1 or maybe two between the two end points 2) and the multiple / many hop count between the two end points. RFC3649 does a “ship-in-the night” type implementation of

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-03 Thread Christian Hopps
> On Apr 30, 2020, at 9:57 AM, Henk Smit wrote: > > I still think we'll end up re-implementing a new (and weaker) TCP. Hi Henk, Thanks for the thoughtful writeup. Let's not be too cynical at the start though! :) I'd note that our environment is a bit more controlled than the end-to-end

[Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-04-30 Thread Henk Smit
Hello all, Two years ago, Gunter Van de Velde and myself published this draft: https://tools.ietf.org/html/draft-hsmit-lsr-isis-flooding-over-tcp-00 That started this discussion about flow/congestion control and ISIS flooding. My thoughts were that once we start implementing new algorithms