Subject: AW: [Tsvwg] SCTP Timestamps

From: Schruefer Wolfgang <[email-masked]>
Date: Fri, 18 Jul 2003 16:32:46 +0200

> >> and (2) whether losing the additional benefits of timestamps
> >> (RTTM
> >
> > Why do we loose RTTM? The timestamps (transmission and 
> retransmission) are
> > stored locally.
> 
> I think the whole purpose of using timestamp (even applicable for TCP)
> rather than storing timestamps locally for RTTM was to avoid 
> this added
> state at the sender.

I am not sure what you mean by 'added state'.
Is it that you want to avoid a locally stored timestamp and instead you store it in the network by a Timstamp ping-pong?
When I compare the costs of both alternatives I can not imagine that a ping-pong is more effective (think of 4 times checksum calculation, reduced payload and net bandwith, ...). 

> 
> >
> >> and the ability to distinguish not only between original
> >> transmission and retransmission, but between an arbitrary number of
> >> consecutive retransmissions as well
> >
> > Here I doubt that it makes sense to enhance the 
> communication if more than
> > one retransmission is needed for a significant number of packets.
> >
> 
> I think I am missing something here? I think if we do intend 
> to "enhance
> communication" we do it correctly and for all possible cases we can,
> rather than restrict ourselves to the case of "one 
> retransmission". Note
> that the consecutive retransmissions that Stephan was 
> referring to can go
> on different paths (destinations). I can still think (while using
> retransmission bit) scenarios where an SCTP sender can break packet
> conservation, do congestion window overgrowth and potentially harm the
> network.

When I go at the beginning of the thread, Stephen showed up the problems:

> - Allowing for better and more frequent RTT measurements
> 
> - Resolving the "path ambiguity" in a multihomed association: If an ACK 
> arrives for a chunk that has been retransmitted one or more times on 
> alternating paths, it is not possible to safely determine which 
> destination the ACK should be credited to (this is briefly mentioned in 
> section 8.2 of RFC 2960). This may result in resetting the wrong error 
> counter (delaying the detection of an inactive path), or in unfair 
> behavior if the congestion window of the wrong path is adapted as a 
> result of the ACK.

>  - Resolving the retransmission ambiguity, i.e. enabling the sender to 
> determine whether an ACK refers to the original transmission or a 
> retransmission of a chunk. This is a necessary precondition for 
> implementing the Eifel algorithm for SCTP (which we are currently 
> looking at).

And all of the points are enhanced significantly by implementation of the retransmission bit, because a single path failure and a single retransmission can be handled 100% correct.
Also for multiple retransmissions the retransmission bit may prevent us from harming the network, because a very late SACK for an original Packet can be identified.
 
If it is considered that one bit is not to be enough, a second bit may be used. I just wanted to express that I think for the problem of spurious retransmissions one retransmission bit seems for me to be enough. 

Wolfgang

> -Sourabh

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 18 Jul 2003 12:05:57 -0400 (EDT)

On Fri, 18 Jul 2003, Schruefer Wolfgang wrote:

> If it is considered that one bit is not to be enough, a second bit may
> be used. I just wanted to express that I think for the problem of
> spurious retransmissions one retransmission bit seems for me to be
> enough.

I disagree. Remember that if the peer SCTP endpoint has multiple
destination IP addresses, each retransmission may go on a different path.

So you are saying that it is enough to only be able to detect spurious
retransmissions the first time, which only helps the cwnd and RTO of the
primary destination. If the first retransmission spuriously times out,
then we don't care according to you. We _may_ not care that the cwnd gets
cut unnecessarily, because the cwnd generally stays pretty small on
alternate paths. But, we DO care that the RTO is left doubled, because
there isn't much traffic on an alternate path to bring that RTO down
again. So the next time a timeout occurs (whether spurious or not) on that
alternate path, it will take that much longer.

If you are not following this argument, _please_ read at least section 3
of our paper. It's a short read. The full paper is only 5 pages.
http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0