[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[Joe Touch]

Detlef Bosau wrote:
> Joe Touch wrote:
...
>> Case in point - if the intermediary ACKs data and continues to buffer
>> it, and the window wraps, and then the intermediary goes down, the
>> endpoints think the data reached the buffer correctly but it really
>> did not.
> 
> Of course. But, assumed we can overcome the window wrap problem, to my
> understanding spoofing boxes must not spoof CLOSE ACK, so that the
> sender is not notified that all data has reached the final receiver
> until this happens.
> 
> Of course, we don´t know anything of intermediate states and of course
> we run into a problem if a spoofing box fails.

Right - that's the other case where problems occur.

>>> What we do not know is whether the data has reached
>>> the application.
>>>     
>>
>> TCP is a reliable transport protocol; it is not a reliable application
>> protocol. Actions outside of TCP are not ensured by TCP.
>>
>>   
> Fine :-)
> 
> Then one could even argue with an end to end argument: When a tranport
> protocol cannot assure that sent data has been read successfully by the
> receiving application, we do need an acknowledgement scheme at the
> application level anyway.

The E2E argument applies to the ends in question. In this case, the
transport protocol is the endpoint, not the application.

...
> All I want to say is that there may be situations, e.g. extremely large
> delay bandwidth products where one perhaps really wants to have an
> alternative to AIMD probing to have an acceptable startup behaviour,

Agreed.

> where proxies / splitters / spoofing boxes should be considered very
> seriously.

I do NOT agree with that conclusion. If you want to change AIMD, proceed
as Lars suggested in a separate post - within TCP or within a link- or
network-consistent PEP, or within an application-visible proxy.

You may need to read the transport packets to implement such a PEP, but
you should not (MUST NOT, actually) need to spoof transport packets to
accomplish the result.

...
>>> To my understanding that´s one reason why we use
>>> acknowledgements on application level when it is necessary to know
>>> whether an application has received all data.
>>
>> Agreed, but we do know some other things. As a *receiver*, when we issue
>> a CLOSE, we keep reading until there is no more data. If we do so, AND
>> we receive a "no more data", then we *know* all the data has been
>> received correctly.
> 
> O.k., so we can detect an error: The sender sent a CLOSE and there is
> trailing data afterwards. In that case (I don´t know what the RFCs say
> here) we can issue an error message , e.g. a RST.

There are two cases:
	- the sender still has data to send already buffered
	in the socket
		TCP won't ACK the received FIN in that case

	- the sender has emptied its buffer and ACK'd the FIN
		TCP won't accept further SEND calls (socket writes)
		from the sending application in that case

> So, let´s take the
> sender´s view then: How long shall a sender wait for a possible error
> message like that? Doesn´t this lead to the problem that a missing NAK
> is not equivalent to an ACK?

The sender can wait all it wants. All it will ever know is that the
receiving TCP has correctly received the data; it needs a separate
signal from the application to know it has actually been read.
Otherwise, both TCPs could close with data in the receive buffers and if
their corresponding applications die, the data is just lost.

>> I.e., the semantics of who knows what are receiver-driven, not sender.
> 
> However, in a reliable connection the sender wants to know when all data
> has been completely delivered.

Not necessarily. The sender wants to know that IF the data is received,
it is received correctly, and that IF the receiver thinks it has all the
data, then it will be correct.

There's nothing in TCP semantics that ensure that the sender knows
anything other than that the receiving TCP has accepted all the data
correctly, though. All that knowledge stops at the TCP layer.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070111/9a5838ee/signature.bin