Re: [Tsvwg] SCTP Timestamps

Stephan/all:

Ok I have now read through this entire thread and I will
use Stephan's consolidated issues to comment on things...

One large META comment I have to this discussion.. One thing
we were VERY careful NOT to do is to require that a Sender Bundle
chunks together. It IS required that a receiver understand how to
"un-bundle" chunks.. but it is NEVER required that a sender bundle
chunks... This is one problem I have with the Time-stamp chunk that
has been talked about so-far.. it requires in some aspects that the
TS-Response be bundled with SACK's .... near as I can tell... this
I do NOT like...

Now it is true that most implementations that I have
tested with DO bundle things together.. but if I remember right there
as been one or two at past bake-offs that did NOT do any bundling... these
may have changed but I hate to see such a restriction show up... i.e. that
we add something that MUST be bundled...

Now on to comments below :>

Stephan Baucke wrote:

>
> 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) 

Yep, I would imagine that HB's can do a similar job (as mentioned by 
others) to
estimate more often the RTT.. not that I am sure we need this...

>
>
> 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") 

I think this can be solved as well by sending a HB after doing a
retransmission to an alternate path... I put this in the KAME stack
a while ago when Armando and I were "debating" some of the "merits"
of retransmitting to the same address :>

>
>
> 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)

Hmm I do wonder about this... if I am sending 1440 bytes in
each data chunk this means the 32 bit TSN space will need 1440 * 2^32  * 
8(bits)
to wrap... doing a bit of napkin scratch.. on a 10Gigabit ethernet thats
more than 4000 seconds before a sequence wrap... would this really be an
issue?

>
> 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?)

This can be solved with a sender side algorithm.. the KAME stack
includes such a solution that we developed while working on [5]. I don't
see that a TS would be needed for this.. they are an alternative 
method.. but I
don't think are required..

>
> 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) 

Yes, a TS could do this.. but so could sending a keyed HB a key
for each transmission.. lots of state by the sender and yes there is
the issue of how many HB's are being sent... but I am not
yet convinced about adding a TS chunk...

>
>
> 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 (?)

It seems that a TS is needed for [6] but that [7] and [8] (as you point out)
also address this problem... and so I am still not convinced that
we need a TS-Chunk :-0

There may even be some other method of doing an Eifel like detection with
HB's and or some combination of what as been discussed in this thread.. not
sure yet.. I have a lot of catching up to do.. and thinking on this..

But for the moment I don't see a compelling need for a TS-chunk yet...

R

>
>
> 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
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
>
>

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg