Subject: RE: [Tsvwg] FRTO

From: "Sourabh Ladha (AC/EED)" <[email-masked]>
Date: Thu, 17 Jul 2003 13:54:08 +0200

Pasi,

I had read the FRTO document some time back. On the SCTP front I was wondering if the following are applicable:

* Multihoming: If the delay spike on the primary path is greater than (1 RTO(primary) + 2 RTT(alternate)), I would believe that FRTO will not be able to detect a timeout spurious. (complying with the current spec that retransmissions SHOULD go to alternate destination)

* Chunk Bundling: FRTO assumes that on a timeout the sender will retransmit only one segment("I think chunk will be appropriate in SCTP terminology"). This may not be true in SCTP. If the association is multihomed and the PMTU's on the primary and alternate path differ by a factor of two or more then, then I think the sender may be able to retransmit more than one unacknowledged chunk on a timeout (bundled in a single packet). This can also be true if the app is writing small chunks such that on a timeout more than one of such chunks can be bundled in a single packet and retransmitted. I remember having noticed a couple of side effects of this which could lead FRTO to declare the timeout spurious while it was not. 

Comments?
(Others shoot in if I missed something)

A question I have is:
Section 3- step 3(b): When you refer to an ACK which acknowledges data (above spurious threshhold or previously unacknowledged), do you refer to acknowledging {via cum-ack point} or {via SACK blocks} or {either of these two}?

-Sourabh

> -----Original Message-----
> From: Pasi Sarolahti [mailto:[email-masked]]
> Sent: Thursday, July 17, 2003 12:52 PM
> To: Armando L. Caro Jr.
> Cc: [email-masked]
> Subject: Re: [Tsvwg] SCTP Timestamps
> 
> 
> Hi,
> 
> On Wed, 16 Jul 2003, Armando L. Caro Jr. wrote:
> 
> > The second motivation was to use timestamps for Eifel detection. A
> > spurious timeout retransmit can be detected if the 
> retransmitted TSN gets
> > acked with a timestamp earlier than the timestamp bundled with the
> > retransmission. This purpose does require a timestamp in 
> each packet (I
> > think).
> 
> Aside from this timestamp discussion, but since spurious RTOs were 
> mentioned: We have proposed a scheme for detecting spurious 
> RTOs without 
> timestamps in draft-sarolahti-tsvwg-tcp-frto-04.txt. I solicited for 
> comments on it in early June, but unfortunately got no 
> answer. It would be 
> nice to hear whether the SCTP community would find that useful.
> 
> The idea in short is that after an RTO the sender would try 
> to send some
> new data and check if there are acks of non-retransmitted segments
> arriving after that, in which case the RTO is considered to 
> be spurious.
> This should work with SCTP as well as with TCP as far as I can see. I
> believe Markku Kojo will have a short presentation about the 
> draft in the
> tsvwg meeting.
> 
> Thanks,
> - Pasi
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: Sourabh Ladha <[email-masked]>
Date: Thu, 24 Jul 2003 17:26:08 -0400 (EDT)

Talk about reordering and delay spikes..I had send this email a week back
(17th July) :->

-Sourabh