Chronological Thread 

< Chronological >      < Thread >

---

Mr. Tüxen

Attached, please find the sniffer log with the retransmission failure. As
you can see, TSN 307823 is lost but never been retransmitted. Finally, send
queue is full and our application abort the association.

After turning on debug, I think the sctplib handles congestion window
correctly. It might be the rwnd handling that causes retransmission problem.
See fc_check_for_txmit() in flowcontrol.c.

The stack gets the first data from transmission queue and checks whether
rwnd is 0.

if (peer_rwnd == 0 && fc->one_packet_inflight == TRUE) { /* section
6.1.A */
event_log(VERBOSE, "NOT SENDING (peer rwnd == 0 and already one
packet in flight ");
return 1;
}

It then picks data from the queue one by one and also checks whether peer's
rwnd is large enough.

while ((dat != NULL) &&
(total_size + obpa <
(fc->cparams[destination].cwnd+fc->cparams[destination].mtu-1)) &&
(
((dat->num_of_transmissions==0)&&(rtx_read_remote_receiver_window() >
chunk_len))||
(fc->one_packet_inflight == FALSE))) {
...
/* save the data in bu buffer and pick up next data */
}

I believe the pre-condition to check if there is one packet in flight is
that the data to be transmitted is new (dat->num_of_transmissions==0). For
retransmitted data, dat->num_of_transmissions>0. If traffic is heavy, it is
very possible that one_packet_inflight is TRUE at the retransmission time.
So both ((dat->num_of_transmissions==0)&&(rtx_read_remote_receiver_window()
> chunk_len)) and (fc->one_packet_inflight == FALSE) will be FALSE; and the
data will not be retransmitted even both cwnd and peer's rwnd are open.

In addition, if peer's rwnd is closed, should the retransmitted data still
be sent out? My understanding is that the retransmitted should be sent.
Otherwise, the association will be in deadlock. If this is true, then the
while statement can be simply changed to:

while ((dat != NULL) &&
(total_size + obpa <
(fc->cparams[destination].cwnd+fc->cparams[destination].mtu-1)) &&
(
((dat->num_of_transmissions==0)&&(rtx_read_remote_receiver_window() >
chunk_len))||
(fc->one_packet_inflight == FALSE) ||
(data_is_retransmitted) )) {
...
}

Correct me if I am wrong.

Thanks
Marc

-----Original Message-----
From: Michael Tüxen
[mailto:Michael.Tuexen AT micmac.franken.de]

Sent: Wednesday, September 10, 2003 5:14 PM
To: Guo Marc-YGUO1
Cc:
discussion AT sctp.de
Subject: Re: [SCTP-Discussion] Retransmission when congestion window is full


Hi Marc,

1. I'm not with Siemens anymore, I changed to the University of Applied
Sciences, Münster.
2. I do continue to work on the sctplib.
3. The sctplib you are using was never and is not 'Siemens SCTP' It is
a prototype
implementation which is a product of a cooperation between Siemens,
the University
of Essen and the University of Applied Sciences Münster.
4. We know that the retransmission stuff in pre19 has some bugs. 5. I got
(just a day ago) a detailed bug report regarding
retransmissions of a
packet dropped multiple times in the network. I will test this with
the upcoming
1.0.0 version.
6. Can you send a (small) tracefile (.pcap) to
tuexen AT fh-muenster.de
to
see what the exact
problem is?
7. 1.0.0 will be released at the end of september (I have a two week
vacation before that...)
8. Thank you very much for the report.

Best regards
Michael

On Friday, Sep 5, 2003, at 16:56 Europe/Berlin, Guo Marc-YGUO1 wrote:

> Hi,
>  
> I have a question about retransmission. In our system, we see that
> Siemens SCTP stops retransmission after a network congestion. The
> network traffic is heavy. End 1 with Siemens SCTP sends many packets
> to end 2 with other SCTP implementation. End 2  sends SACK back with
> some delay and end 1 receives these SACK's all together. The SACK
> reports that some data is lost. But end 1 only retransmit once or
> doesn't retransmit at all. End 1 can still send SACK back after
> receiving DATA from end 2. Eventually, our application resets the > link.
>  
> I find that the fast retransmission does be kicked off after 4 gaps in
> the SACK. However, the stack doesn't finish retransmission, since we
> don't see the retransmitted data on the sniffer. There are no major
> errors on the log. The other SCTP implementation on end 2 had similar
> problem before. It was found that the stack was holding up
> retransmissions when congestion window is full. Do you find the same
> flaw in Siemens SCTP? We are using version pre19. Thanks for the help.
>  
> Marc Guo
> Motorola, Inc

Attachment: rtx_problem
Description: Binary data

---

• RE: [SCTP-Discussion] Retransmission when congestion window is fu ll, Guo Marc-YGUO1, 09/11/2003
  • Re: [SCTP-Discussion] Retransmission when congestion window is fu ll, Michael Tüxen, 09/12/2003
    • Re: [SCTP-Discussion] Retransmission when congestion window is full, Andreas Jungmaier, 09/12/2003
      • SCTPLIB snapshot (was: [SCTP-Discussion] Retransmission when congestion window is full), Andreas Jungmaier, 09/16/2003

---

Archive powered by MHonArc 2.6.19+.