Re: [lwip-users] [TCP raw API] Nagle + tcp_output interaction (behavior in 24 throughput tests)

[vr roriz]

>Ok, so the application *never* calls tcp_output() but you leave this 
>completely to the stack? That might work somehow, but will lead to totally 
>unpredictive performance, as you have measured.

That's my point, I thought it would be totally unpredective. But after
some certain amount of data is periodically queued, the RTT starts to
go down again and the throughput is achieved. That is what I would
like to understand. Do you think it would be a good idea to call
tcp_output from some custom timer? (Since the poll callback has a very
high resolution).

>Also, even if you don't call tcp_output(), that doesn't always ensure two 
>segments get sent together. Trying to achieve something like that is just not 
>what TCP is like. TCP is a streaming protocol, which is what people tend to 
>not understand. You can try to work around its streaming nature and make it 
>datagram like, but once you think you got it working like you want to, don't 
>be surprised if it doesn't in the next version.

I agree, it does not ensure, I used it as an argument and they are
aware of it. However, according to them, they need this due to a bug
with TLS in a analysis tool they are using. It is only for debugging
and when the software is deployed I doubt they will set send_now = 0.

MfG,
Vitor
Em qui, 11 de out de 2018 às 21:11, goldsimon <address@hidden> escreveu:
>
>
>
> vr roriz wrote:
> >[..]
> >Then, I added the send_now control option, letting tcp_output (with
> >send_now = 0) to be called by lwip itself.
>
> Ok, so the application *never* calls tcp_output() but you leave this 
> completely to the stack? That might work somehow, but will lead to totally 
> unpredictive performance, as you have measured.
>
> Also, even if you don't call tcp_output(), that doesn't always ensure two 
> segments get sent together. Trying to achieve something like that is just not 
> what TCP is like. TCP is a streaming protocol, which is what people tend to 
> not understand. You can try to work around its streaming nature and make it 
> datagram like, but once you think you got it working like you want to, don't 
> be surprised if it doesn't in the next version...
>
> Simon
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users