Imported from previous forum
I was wondering why there is no FIX mechanism for flow control (Ala. XON/XOFF) which either end can send? Recently as part of Draft 4.2 a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Wouldn’t a throttling mechanism be a useful addition in the context of ever higher bandwidth networks?
Avner Gelb
SIAC
> I was wondering why there is no FIX mechanism for flow control (Ala. XON/XOFF) which either end can send? Recently as part of Draft 4.2 a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Wouldn’t a throttling mechanism be a useful addition in the context of ever higher bandwidth networks?
>
> Avner Gelb
> SIAC
>
Since you are considering a two-way scenario (not multicast IP), the flow control of the underlying TCP would be sufficient, wouldn’t it?
Opher Lekach
Optimark Technologies
The disadvantage of relying on TCP/IP to do flow control is that the communications buffers and catch of sending and receiving system must be full before throttling kicks in. Meanwhile the sending application assumes timely delivery of messages, even where the overloaded receiving system has not even catered to the session. This is especially aggravated in large network configuration where there can be many intermediate devices providing buffering. The application level is in a much better position to provide timely control, eliminates the problem of stale data, and reduces exposure of possibly large number of buffered transactions in system failures.
Avner Gelb
SIAC
> > I was wondering why there is no FIX mechanism for flow control (Ala. XON/XOFF) which either end can send? Recently as part of Draft 4.2 a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Wouldn’t a throttling mechanism be a useful addition in the context of ever higher bandwidth networks?
> >
> > Avner Gelb
> > SIAC
> >
>
> Since you are considering a two-way scenario (not multicast IP), the flow control of the underlying TCP would be sufficient, wouldn’t it?
>
> Opher Lekach
> Optimark Technologies
>
>
> The disadvantage of relying on TCP/IP to do flow control is that the communications buffers and catch of sending and receiving system must be full before throttling kicks in. Meanwhile the sending application assumes timely delivery of messages, even where the overloaded receiving system has not even catered to the session. This is especially aggravated in large network configuration where there can be many intermediate devices providing buffering. The application level is in a much better position to provide timely control, eliminates the problem of stale data, and reduces exposure of possibly large number of buffered transactions in system failures.
>
> Avner Gelb
> SIAC
>
>
> > > I was wondering why there is no FIX mechanism for flow control (Ala. XON/XOFF) which either end can send? Recently as part of Draft 4.2 a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Wouldn’t a throttling mechanism be a useful addition in the context of ever higher bandwidth networks?
> > >
> > > Avner Gelb
> > > SIAC
> > >
> >
> > Since you are considering a two-way scenario (not multicast IP), the flow control of the underlying TCP would be sufficient, wouldn’t it?
> >
> > Opher Lekach
> > Optimark Technologies
> >
> >
>
So you are actually not looking for flow control, but for two other things:
- Congestion control.
- Delay control, i.e. avoid sending if the receiving party will not be able to make use of it anyway.
I agree these need to be addressed at the application or session levels but perhaps by two different mechanisms, one for each of the concerns I listed above.
Opher Lekach
Optimark Technologies