Subject: Re: [Tsvwg] SCTP Timestamps

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Mon, 04 Aug 2003 09:03:06 -0500

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
> [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: Mon, 4 Aug 2003 11:22:38 -0400 (EDT)

Just a minor comment.

> don't think are required..

Congestion window overgrowth caused by retransmission ambuiguity will not
be solved by CACC in [5]. I believe that changeover specific
cwnd overgrowth is solved by [5].

-Sourabh

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Wed, 06 Aug 2003 14:50:32 -0500

Sourabh/Stephan:

I have been contemplating the timestamp issue and I am beginning to lean
toward using the already defined HB for this. Could you tell me if
this would work for your eifel algorithm?

First Transmission

----Normal DATA-no-HB------>

----Normal HB-To-Alternate(ts/other stuff)--->

T3-Timeout

---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data------->

If I hit another T3

---HB(ts/flag=retran#/tsn.. no other stuff)+Bundled-Data------>

Now. One of a number of things will occur.

1) The peer does NOT bundle things together... in that case a time-stamp 
chunk
     would have the same problems as a HB-ACK i.e. it would get lost in
     the network from say the SACK that will come back ack'ing the data.

2) A loss occurred and thus the HB-ACK will be sent right away possibly
    bundled with the SACK not showing any duplicates and showing gaps.

3) A loss did NOT occur and a HB-ACK will be bundled with a SACK showing
    a duplicate (if a duplicate is present a SACK is sent right away 
with no delay)

4) A loss occured and there are no gaps so the delay timer is started.. thus
    the HB-ACK would go stand alone.. and then a bit later the SACK would
    be sent based of the delay timer.

Now if the HB-ACK comes bundled with a SACK showing duplicates you have
detected a false retransmission.

In ANY event you can always calculate the RTT since the HB has when it
was sent.. .and if you are really nervous about the missing delay (200ms 
or whatever)
you can add it in .. of course ALL HB's to alternates have this issue as 
well :>

It seems to me that the HB/as long as bundling occurs with the HB-ACK will
accomplish the same purposes... Or what is missing from this detection?

Brian as pointed out that it "changes the nature of the HB" but I don't 
think
so.. since a HB is used to:

1) Test reachablility
and
2) calculate RTT's

And a bundled HB like this is doing both of those... its just that by when
you send it you get more information...

What am I missing?

R

R

---
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Stephan Baucke <[email-masked]>
Date: Thu, 07 Aug 2003 13:38:21 +0200

>     the network from say the SACK that will come back ack'ing the data.

I think this would cause a serious problem for Eifel. A SACK for a 
retransmission without a HB (i.e. the HB was not bundled and lost or 
reordered relative to the SACK) would be falsely interpreted as a SACK 
for the original transmission, so Eifel would wrongly assume that the 
timeout was spurios and undo congestion control. This is the worst case.

In essence, if Eifel cannot be sure whether a SACK without HB really 
refers to the original transmission, it can never apply the Eifel response.

>    a duplicate (if a duplicate is present a SACK is sent right away with 
> no delay)
> 

I agree that HBs are sufficient for the RTT measurement, but unless 
reliably bundled, they are not sufficient to resolve the retransmission 
  ambiguity.

> accomplish the same purposes... Or what is missing from this detection?

I think some sort of startup negotiation is the best solution so that 
(1) both sides can be sure whether the peer is able to do the bundling, 
and (2) room can be reserved in a timestamp-enabled session for HBs/TSs 
when doing fragmentation. But if we do a negotiation, we can just as 
well use a new chunk type rather then overloading HBs with new 
functionality (and thus avoid changes to the regular HB processing).

Stephan.