[e2e] Some questions about TCP.

[Jon Crowcroft]

I suggest you read thru W Richard Stevens TCP/IP Illustrated, esp. vol
2 where he goes thru the code...

basically, while all TCP packets can carry data,
there is a notion of a "pure ack" implicit in
a packet that is triggered internally by TCP even when there isn't
data which acks cumulatively received sequence number space (or
(inclusive or) notifies the far end that there's more window space...

you don't have to ack every packet, but if a packet is "new" 
(e.g.  carries new data) then you probably should ack it soon ...

if you see a new packet (i.e. it carries new data), but its sequence 
is not the _expected_ one (i.e. next chunk), then you might dupack
the oldest one received so far...

I think this is all beautifully explained by Stevens, so I will now
await whhile you go and read it:)

In missive <4B0A453D.4000607 at web.de>, Detlef Bosau typed:

 >>Noel Chiappa wrote:
 >>>     > From: Detlef Bosau <detlef.bosau at web.de>
 >>>
 >>>     > How can I prevent to mistake several segments with the same ack n=
 >>umber
 >>>     > as duplicate acknowledgements?
 >>>
 >>> If they contain no data, by definition they _are_ duplicate acknowledge=
 >>ments.
 >>> That is not necessarily a problem, though.
 >>>  =20
 >>;-)
 >>
 >>
 >>>
 >>>     > RFC 2581 Section 4.2
 >>>     >
 >>>     >   A TCP receiver MUST NOT generate more than one ACK for every in=
 >>coming
 >>>     >   segment, other than to update the offered window as the receivi=
 >>ng
 >>>     >   application consumes new data [page 42, Pos81][Cla82].
 >>>
 >>> That is poorly phrased. It should say 'more than one ACK-only packet', =
 >>or
 >>> something like that.
 >>>  =20
 >>
 >>However, this does not solve my problem.
 >>
 >>In a bidirectional flow, it is well possible that one segment sent from=20
 >>a to be can see several acknowledgements in packets from b to a. Imagine=20
 >>a simple asymmetric connection with 2 MBit/s throughput in the one=20
 >>direction and 500 kBit/s in the other.
 >>
 >>The question is: How can a sender determine whether he sees a "normal"=20
 >>number of acknowledgements for a packet or "more then DUPACKTHRESH",=20
 >>hence the sender has to retransmit the packet and must do recovery action=
 >>s?
 >>
 >>
 >>>     > So, when a node sends several segments without receiving new ones=
 >>, it
 >>>     > will repeat the same ack number several times.
 >>>
 >>> Yes, that is OK. Just as long as one does not send multiple ACK-only pa=
 >>ckets
 >>> in response to a single data-containing packet.
 >>>  =20
 >>
 >>Hm. I don't get the clue...... ;-)
 >>
 >>>
 >>>     > my problem is: When it is possible for a sender, to have the same
 >>>     > packet acknowledged by several packets from the peer, not to mist=
 >>ake
 >>>     > these for e.g. da Triple Duplicate Acknowledgement, which will ca=
 >>use
 >>>     > the sender to go into fast retransmission and fast recovery?
 >>>
 >>> I'm not an expert in this area of TCP, but I think you have to look at =
 >>the
 >>> larger situation - i.e. look to see what exactly you have outstanding, =
 >>etc.
 >>>  =20
 >>
 >>The problem is quite simple. I'm working at a very simple tiny simulator=20
 >>at the moment - and anything was fine and worked as the RFC told - as=20
 >>long as I did not send any data full duplex.
 >>
 >>As soon as both parties started to send, the party was over and both=20
 >>peers throttled their windows down to a single segment due to duplicate=20
 >>acknowledgements.
 >>
 >>And now, I'm simply looking for the correct way to handle this=20
 >>situation.....
 >>
 >>> E.g. if you send segments A, A+100, A+200, and A+300, and you get back
 >>> ACK-only packets for A, A, A then you can be fairly sure that A+100 has=
 >> been
 >>> lost, and you need to re-send it.
 >>
 >>O.k., and when I see 10 or 15 data carrying segments which acknowledge A?
 >>
 >>You will observe this with an arbitrary ADSL line!
 >>
 >>Detlef
 >>
 >>--=20
 >>Detlef Bosau            Galileistra=DFe 30        70565 Stuttgart
 >>phone: +49 711 5208031  mobile: +49 172 6819937 skype: detlef.bosau    =20
 >>ICQ: 566129673          detlef.bosau at web.de     http://www.detlef-bosau.d=
 >>e                     =20
 >>
 >>

 cheers

   jon