Subject: [Tsvwg] delayed SACK when sender is retransmitting

From: venkat venkatsubra <[email-masked]>
Date: Mon, 01 Apr 2002 14:51:07 -0600

Dear All,

When a receiver receives a retransmitted DATA chunk that advances
the cumulative TSN Ack number, isn't it good to send the SACK
immediately
instead of delaying it ? Otherwise what we see is the sender when
retransmitting stalling waiting for this SACK before it can proceed
further.
Since the rfc (2960) requires you to SACK immediately on receiving
the first DATA chunk, a similar rule could help in case of receiving
retransmitted DATA chunks i.e. on receiving a DATA chunk that fills a
hole and advances the cumulative TSN Ack.  Or,  is this left to the
implementation ?
Thanks!

Venkat

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Arun Prasad <[email-masked]>
Date: Tue, 02 Apr 2002 08:11:27 +0530

hi Venkat,
    comments inline....

> retransmitting stalling waiting for this SACK before it can proceed

        How will the receiver know whether a Data chunk is retransmitted chunk???
We can say a data chunk received might be a retransmitted one, for the following
conditions.... But in all the below conditions a SACK is to be generated according
to Rfc....

1) GAP:
"6.7 Report Gaps in Received DATA TSNs

   Upon the reception of a new DATA chunk, an endpoint shall examine the
   continuity of the TSNs received.  If the endpoint detects a gap in
   the received DATA chunk sequence, it SHOULD send a SACK with Gap Ack
   Blocks immediately.   "

2)DUPLICATE:
"   When a packet arrives with duplicate DATA chunk(s) and with no new
   DATA chunk(s), the endpoint MUST immediately send a SACK with no
   delay.  If a packet arrives with duplicate DATA chunk(s) bundled with
   new DATA chunks, the endpoint MAY immediately send a SACK. "

> hole and advances the cumulative TSN Ack.  Or,  is this left to the

Thanks
-arun

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************

---

From: Randall Stewart <[email-masked]>
Date: Tue, 02 Apr 2002 06:16:44 -0600

Venkat:

I think Arun has mad the correct observation here.

It is really impossible to tell the difference between
a retransmission and a network delayed packet. The
receiver has no idea (even when a GAP exists) if 
the packets are just received out of order OR the
GAP filling packet is a fast-retransmit or T3-Timeout.

Adding the 200ms delay I don't think will be a problem since:

1) If it is a retransmission then there is a good chance
   the network is related to congestion and slowing down
   might not be such a bad thing.

2) If it is a normal but re-ordered transmission the peer
   may be doing a RTO measurement on the packet and getting
   the 200ms delay put into the time recorded (the normal
   delay) is a good thing.

All in all it is a good thing :>

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 3 Apr 2002 00:45:20 -0600

Venkat,

> retransmitting stalling waiting for this SACK before it can proceed

Why is your retransmitting sender stalling waiting to
receive a SACK?  Normally RTO.Min >> max SACK delay,
so a retransmit means that either a packet was lost
or the SACK was lost.

I don't understand what problem you are seeing...

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦