Subject: Re: [Lwip] "flow control" manipulation

From: Wesley Eddy <[email-masked]>
Date: Fri, 06 May 2011 14:22:30 -0400

On 3/29/2011 11:13 AM, Thomas Richter (TCD - DE/Dresden) wrote:
> Hi,
>
> I´m searching for a possibility to manipulate the "flow control" of TCP
> data handling.
> I know that there is the parameter "Window" in the TCP header (see
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure).
>
> My task is to transport TCP data over Ethernet interface and there are
> some needs to make an external flow control. In other words I get the
> information that the receiver supports two states: "Receive Ready" (RR)
> and "Receive Not Ready" (RNR).
>
> If the state "RNR" occurs the other side of the Ethernet connection
> needs this information and then it have to stop sending frames. Not
> until the state "RR" arised then the data processing shall be continued.
>
> For this I would using the parameter "window" in TCP header and set them
> to 0 with lwIP. But what can I do to generate this?
>
> Can anybody help me?
>

It isn't clear if you're asking about doing this in the end-host's
operating system, within the end application, or within some other
application on the end host, or whether you're talking about
re-writing the advertised receive window in packets crossing through
a router or other intermediary device.  In each case, it depends
heavily on the operating system and other specifics, and if you
really mean what you say about not sending *frames* then there
are severe layer violations going on since you're using layer-4
information about an application's ability to sink data to determine
at layer-2 whether the MAC should release frames.

Note that rewriting the receive window doesn't work at all for
traffic that's either protected by ESP or tunneled in ways that
the TCP header can't be touched.

It's hard to say much definitive without more information, but in
general this sounds like a bad idea that might have the unfortunate
property of sort-of working in some cases.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 May 2011 13:42:15 -0700

FWIW, what you're asking for is already supported using Ethernet "pause" 
frames.

The goal is to get ethernet to stop sending frames (pause) when the 
upstream *ethernet* device runs out of buffering.

None of this needs to interconnect with TCP signals - as Wes said, it's 
a bit of a layer mismatch to expect that anyway. Besides, there are many 
levels of buffering and corresponding stop/go signals involved:

	application buffers
	receiver socket buffers
	receiver kernel packet buffers
	receiver network interface buffers

at each L2 hop:
	switch output buffers
	switch input buffers

at each L3 hop:
	router output buffers
	router input buffers
	internal switching buffers

at the source:

	sender network interface buffers
	sender kernel packet buffers
	sender socket buffers
	application buffers

TCP could potentially help coordinate SOME of those uses - notably the 
socket and application buffers on the endpoints, but it may be 
impossible to get at TCP information elsewhere (e.g., if encrypted). 
It's also not particularly necessary.

TCP/IP is not a "hard realtime" protocol suite. IP is best effort, and 
TCP is reliable in-order *eventual* delivery. Optimizing the rest 
confuses TCP/IP for something it is not, IMO.

Joe

On 3/29/2011 8:13 AM, Thomas Richter (TCD - DE/Dresden) wrote:
> Thanks for any help.
> Best regards
> Thomas
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip