[e2e] Some questions about TCP.

[Noel Chiappa]

    > From: Detlef Bosau <detlef.bosau at web.de>

    >>> "A TCP receiver MUST NOT generate more than one ACK for every incoming
    >>> segment ..."

    >> That is poorly phrased. It should say 'more than one ACK-only packet'

    > However, this does not solve my problem.

Well, it does clear up issue you had, where you thought it was incorrect for
a TCP to issue more than one acknowledgement for a particular place in the
stream...


    > In a bidirectional flow, it is well possible that one segment sent from
    > a to be can see several acknowledgements in packets from b to a.

Yes, the indirect meaning (as far as indicating missing segments) of the
acknowledgement fields in bidirectional flows is definitely less clear.

    > The question is: How can a sender determine whether he sees a "normal"
    > number of acknowledgements for a packet or "more then DUPACKTHRESH",
    > hence the sender has to retransmit the packet and must do recovery
    > actions?

I do not have a definite answer to this (in the case above, where multiple
data+ack packets are coming in from the other end). Perhaps one of the TCP
experts here can help?


    >> Just as long as one does not send multiple ACK-only packets in
    >> response to a single data-containing packet.

    > Hm. I don't get the clue...... ;-)

Sorry, I did not understand that?


    > I'm working at a very simple tiny simulator at the moment - and
    > anything was fine and worked as the RFC told - as long as I did not
    > send any data full duplex.

I would not be surprised if some TCPs do not work well when there is
simultaneous bidirectional traffic.

This is because the rule about 'only send an ack-only packet in response to
an incoming data packet' does not apply in that case (since one is sending
packets which contain data _and_ an ACK, and hence are not covered by that
rule). It is that rule which allows one to infer, when one sees multiple
ACK-only packets in a row, that the other end _has_ seen multiple data
packets arrive, BUT is _also_ missing the next one in sequence. And that
signal (of a packet loss) is what drives a lot of other stuff (e.g. fast
retransmit).

When you see a packet with data _and_ an ACK, you cannot draw any such
conclusions about what packets the other end has seen, from that packet alone,
without any other information - all you know is that the other end _has_ seen
packets up through that indicated in the ACK field.

    > As soon as both parties started to send, the party was over and both
    > peers throttled their windows down to a single segment due to duplicate
    > acknowledgements.

It sounds like the code is treating _all_ packets with an acknowledgment as
usable as an indication of packet loss (as above), when it it seem to me that
it should _ignore_ packets with data in them for that purpose, because they
are not covered by the 'only send when an incoming packet arrives' rule..

Do the TCP experts here agree with that supposition?


    > and when I see 10 or 15 data carrying segments which acknowledge A?

Like I said, "you have to look at the larger situation ... Adding timers
allows you to make even better estimations of what it going on". For
instance, as an example, there is probably something you can do if you know
the time at which A and succeeding segments are sent, and you have a good
estimate of the RTT.

For instance, if A was sent at T, A+100 at T+10, A+200 at T+20, etc, and the
RTT is R, then if you get you first ACK for A at T+R+<epsilon>, and at
T+R+100+<3*epsilon> (3 is picked out of the air - I don't know what the right
value needs to be, perhaps it should be based on the RTT variation) you start
to get a bunch of segments which contain data and an ACK for A, you can
_guess_ that A+100 has been lost, and resend it.

	Noel