Re: [Tsvwg] SCTP Timestamps

[Stephan Baucke <[e-mail]>]

>> You have already mentioned one of the reasons: Detection of
>> spurious retransmissions using DSACK only works "after the fact",
>> whereas something like Eifel detects it early enough to avoid a
>> go-back-n-like behavior after a spurious timeout (also see RFC
>> 3522).
> 
> How about Pasi's F-RTO?  I have read Sourabh's questions about F-RTO.
> But I think F-RTO can be modified, possible making use of duplicate
> TSN, for SCTP to address those questions.

I have not really looked at F-RTO in depth, but seem to remember that it
only covers part of the cases that e.g. Eifel covers (perhaps Pasi can
comment on that?)

>> Also, DSACKs do not address the other issues mentioned in this
>> thread, such as the "path ambiguity" and RTTM. Note that DSACKs are
>> still useful and may be combined with Eifel; I think there is a
>> compelling case for introducing optional timestamps even if DSACKs
>> are already utilized.
> 
> I guess many people have pointed out that RTTM is not very crucial
> and

I am not convinced of that. While there is evidence questioning the
benefits of timing every packet for modest congestion window sizes 
(Allman/Paxson SIGCOMM '99), there is on the other hand evidence that it
can counter aliasing effects in case of large congestion windows (RFC
1323), and can help to reduce spurious timeouts in case of links with
highly variant RTTs, in particular wireless links (see e.g. RFC 3481,
section 4.8). Timestamps may also enable alternative RTO estimators in
the future.

> and there are implementation techniques which can make more RTT
> measurements without using timestamp.

But do these techniques also allow for the timing of retransmitted
packets? This still seems important to me, especially for obtaining a
better RTO on alternate paths. Without timestamps we would need some
other method to disambiguate retransmissions in order to achieve this.

> For the issue of path ambiguity, I guess we need to first understand
> why it happens.  And can it be avoided?  One case mentioned is that a
> retransmission takes place in an alternate path causing problem in
> cwnd growth.  We should first ask if retransmitting using an
> alternate path is always a good thing. There is a reason why RFC 2960
> does not require (MUST) an implementation to always retransmit using
> alternate path.  I guess we should first decide when an alternate
> path be used for retransmission to minimize the path ambiguity issue.
> 
I guess one could reduce the probability of the "path ambiguity" by
changing the SCTP retransmit policy, but nevertheless it seems sensible
to me to address problems that may arise from the standard policy
recommended by RFC 2960.

> Another path ambiguity issue mentioned is changeover by the app. A
> "simple" way to avoid that is for the implementation to withhold 
> sending packets before all outstanding packets to the original 
> primary destination address have been ack'ed.  This has the side 
> effect of discouraging an app to change often.  Granted, this
> "simple" solution prevents a lot of "experimentation" on, for
> example, load balancing and has obvious performance implication.  But
> I think at this point, there is no solid proposal in making using of
> alternate paths other than retransmission.  So I believe it is OK for
> now.

I think the performance implications would be serious. The failure
detection and failover mechanism are already too conservative for some
applications, and this would make them even more conservative.

> I guess we should try to avoid the problems first before trying to
> find a solution, timestamp in this case, to the problems.

I'll try to consolidate the issues:

1) Increasing the RTT sampling frequency: Benefits are still
controversial ([1] [2] [3]), could be achieved using either timestamps
or implementation techniques (at the cost of additional state at the sender)

2) RTO inflation on alternate paths due to inability to time
retransmissions [4]: Can be addressed by changed retransmission policy,
specially timed heartbeats, timestamps, or other method to resolve the
retransmission ambiguity ("retransmission bits")

3) Sequence number wrap-around within packet lifetime in high-speed
networks [1]: This affects SCTP equally as TCP (both use 32-bit seq.
number spaces), can be addressed by using timestamps (PAWS)

3) Incorrect congestion window growth due to crediting of SACKs to the
wrong destination address or unawareness of failover [5]: Can be
resolved by timestamps and/or Rhein algorithm (? not sure if these 
really cover the same problem space; Jana?)

4) Incorrect error counting due to crediting of SACKs to the wrong
destination address: Can be addressed using timestamps or other means to
resolve retransmission ambiguity (preferably for more than one
retransmission)

5) Detection and/or prevention of spurious retransmissions: Detection
possible using Eifel [6] (either with timestamps or new flags), Dup-TSNs
[7], or F-RTO [8]. Prevention possible with Eifel and F-RTO (?)


References:
[1] RFC 1323

[2] RFC 3481 (and citations [45], [52], [54], [60] therein)

[3] M. Allman, V. Paxson, "On Estimating End-to-End Network Path
Properties", SIGCOMM'99

[4] Armando L. Caro Jr., Paul D. Amer, Randall R. Stewart, "Transport
Layer Multihoming for Fault Tolerance in FCS Networks", MILCOM 2003
http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf

[5] Janardhan R. Iyengar, Armando L. Caro Jr., Paul D. Amer, Gerard J.
Heinz, Randall R. Stewart, "SCTP Congestion Window Overgrowth During
Changeover", SCI 2002
http://www.cis.udel.edu/~acaro/papers/2002.sci.iyengar.pdf

[6] RFC 3522

[7] draft-ietf-tsvwg-dsack-use-00.txt

[8] draft-sarolahti-tsvwg-tcp-frto-04.txt





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