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 #1, where there is an excess of capacity between the two end points. It also
IMO addresses the ability to burst and then close a shorter term connection.
Thus, I think that your issue is mostly the #2 problem
and the problem that most CA algorithms IMO always try to increase capacity and
thus at some point must exceed capacity. TCP must find a range of capacity per
flow (assuming a consistent a number of packets per sec). However, what is
maybe missed (I missed it in the document) is the ability not to overshoot the
TCP threshold point and trigger multiple initial congestion events in/exiting
the slow-start phase.
FYI: My implementations tend to try to identify a connection of
packets-per-sec with a range using prime numbers, and possibly identify excess
capacity and subdivide that capacity into future multiple connections. This
type of implementation is much easier to do from a server, that implements the
#1 scenario above where the server is one of the end points.
Mitchell Erblich
erbli...@earthlink.net
> On Apr 30, 2020, at 6:57 AM, Henk Smit <henk.i...@xs4all.nl> wrote:
>
>
> 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 to
> optimize ISIS flooding speed, we'll end up with our own version of TCP.
> I think most people here have a good general understanding of TCP.
> But if not, this is a good overview how TCP does it:
> https://en.wikipedia.org/wiki/TCP_congestion_control
>
>
> What does TCP do:
> ====
> TCP does 2 things: flow control and congestion control.
>
> 1) Flow control is: the receiver trying to prevent itself from being
> overloaded. The receiver indicates, through the receiver-window-size
> in the TCP acks, how much data it can or wants to receive.
> 2) Congestion control is: the sender trying to prevent the links between
> sender and receiver from being overloaded. The sender makes an educated
> guess at what speed it can send.
>
>
> The part we seem to be missing:
> ====
> For the sender to make a guess at what speed it can send, it looks at
> how the transmission is behaving. Are there drops ? What is the RTT ?
> Do drop-percentage and RTT change ? Do acks come in at the same rate
> as the sender sends segments ? Are there duplicate acks ? To be able
> to do this, the sender must know what to expect. How acks behave.
>
> If you want an ISIS sender to make a guess at what speed it can send,
> without changing the protocol, the only thing the sender can do is look
> at the PSNPs that come back from the receiver. But the RTT of PSNPs can
> not be predicted. Because a good ISIS implementation does not immediately
> send a PSNP when it receives a LSP. 1) the receiver should jitter the PSNP,
> like it should jitter all packets. And 2) the receiver should wait a little
> to see if it can combine multiple acks into a single PSNP packet.
>
> In TCP, if a single segment gets lost, each new segment will cause the
> receiver to send an ack with the seqnr of the last received byte. This
> is called "duplicate acks". This triggers the sender to do
> fast-retransmission. In ISIS, this can't be be done. The information
> a sender can get from looking at incoming PSNPs is a lot less than what
> TCP can learn from incoming acks.
>
>
> The problem with sender-side congestion control:
> ====
> In ISIS, all we know is that the default retransmit-interval is 5 seconds.
> And I think most implementations use that as the default. This means that
> the receiver of an LSP has one requirement: send a PSNP within 5 seconds.
> For the rest, implementations are free to send PSNPs however and whenever
> they want. This means a sender can not really make conclusions about
> flooding speed, dropped LSPs, capacity of the receiver, etc.
> There is no ordering when flooding LSPs, or sending PSNPs. This makes
> a sender-side algorithm for ISIS a lot harder.
>
> When you think about it, you realize that a sender should wait the
> full 5 seconds before it can make any real conclusions about dropped LSPs.
> If a sender looks at PSNPs to determine its flooding speed, it will probably
> not be able to react without a delay of a few seconds. A sender might send
> hunderds or thousands of LSPs in those 5 seconds, which might all or
> partially be dropped, complicating matters even further.
>
>
> A sender-sider algorithm should specify how to do PSNPs.
> ====
> So imho a sender-side only algorithm can't work just like that in a
> multi-vendor environment. We must not only specify a congestion-control
> algorithm for the sender. We must also specify for the receiver a more
> specific algorithm how and when to send PSNPs. At least how to do PSNPs
> under load.
>
> Note that this might result in the receiver sending more (and smaller) PSNPs.
> More packets might mean more congestion (inside routers).
>
>
> Will receiver-side flow-control work ?
> ====
> I don't know if that's enough. It will certainly help.
>
> I think to tackle this problem, we need 3 parts:
> 1) sender-side congestion-control algorithm
> 2) more detailed algorithm on receiver when and how to send PSNPs
> 3) receiver-side flow-control mechanism
>
> As discussed at length, I don't know if the ISIS process on the receiving
> router can actually know if its running out of resources (buffers on
> interfaces, linecards, etc). That's implementation dependent. A receiver
> can definitely advertise a fixed value. So the sender has an upper bound
> to use when doing congestion-control. Just like TCP has both a flow-control
> window and a congestion-control window, and a sender uses both. Maybe the
> receiver can even advertise a dynamic value. Maybe now, maybe only in the
> future. An advertised upper limit seems useful to me today.
>
>
> What I didn't like about our own proposal (flooding over TCP):
> ====
> The problem I saw with flooding over TCP concerns multi-point networks (LANs).
>
> When flooding over a multi-point network, setting up TCP connections
> introduces serious challenges. Who are the endpoints of the TCP connections ?
> Full mesh ? Or do all ISes on a LAN create a TCP-connection to the DIS ?
> There is no backup DIS in ISIS (unlike OSPF). Things get messy quickly.
>
> However, the other two proposals do not solve this problem either.
> How will a sender-side congestion-avoidence algorithm determine whether
> there were drops ? There are no acks (PSNPs) on a LAN. We assume most LSPs
> that are broadcasted are received by all other ISes on the LAN. There are
> no acks. Only after the DIS has sent its periodic CSNPs, ISes can send
> PSNPs to request retransmissions. It seems impossible (or very hard) to
> me for all ISes on a LAN to keep track of dropped LSPs and adjust their
> sending speed accordingly.
>
> When flooding on a LAN, the receiver-side algorithm seems best. Because
> all ISes can see what the lowest advertised sending-speed is. And make
> sure they send slow enough to not overload the slowest IS. I'm not sure
> this is a good solution, but is seems easier and more realistic than
> ISIS-flooding-over-TCP or sender-side congestion-avoidance.
>
>
> My conclusion:
> ====
> Sender-side congestion-control won't work without specifying in more
> detail how and when to send PSNPs.
> Receiver-side flow-control will certainly help. I dont' know if it's
> good enough. I don't know if advertising a static value is good enough.
> But it's a start.
>
> I still think we'll end up re-implementing a new (and weaker) TCP.
>
>
> henk.
>
> _______________________________________________
> 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
