SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Retransmission when congestion window is fu ll


Chronological Thread 
  • From: Michael Tüxen <Michael.Tuexen AT micmac.franken.de>
  • To: Guo Marc-YGUO1 <YGUO1 AT motorola.com>
  • Cc: discussion AT sctp.de, Wells Kris-KWELLS1 <Kris.Wells AT motorola.com>, Newton Michael-QA2938 <Michael.Newton AT motorola.com>, Boffa Stephen-QA4741 <boffa AT motorola.com>, Herga Sampath-A16058 <sampath AT motorola.com>
  • Subject: Re: [SCTP-Discussion] Retransmission when congestion window is fu ll
  • Date: Fri Sep 12 00:37:01 2003
  • List-id: SCTP Discussions <discussion.sctp.de>

Hi Marc,

thank you very much for the detailed report. We will look into this.

Best regards
Michael
On Thursday, Sep 11, 2003, at 19:19 Europe/Berlin, Guo Marc-YGUO1 wrote:

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

<rtx_problem>




Archive powered by MHonArc 2.6.19+.

Top of page