Subject: RE: AW: [Tsvwg] SCTP Timestamps

From: Schruefer Wolfgang <[email-masked]>
Date: Mon, 21 Jul 2003 10:05:06 +0200

Armando,

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

I studied your paper with high interest, but my conclusion is that a mirrored Retransmission Flag would be a perfect solution for the scenario you describe in the paper.

With the mirrored Retransmission Flag you _can_ recalculate RTO on the second path. You just can not do it for the third or further paths. And here I think that the third path (resp. the a RTO calculation for the third transmission) may not be so important to improve.

Below I copied an extract from your paper, that could be witten similar for a Chunk Flag solution, but without the expense of additional overhead. 

>>>... Solution 3 introduces timestamps into each packet, thus allowing
a sender to disambiguate original transmissions from retransmissions.
By removing retransmission ambiguity, Karn's
algorithm can be eliminated, and successful retransmissions on the alternate path can be used to update the RTT estimate
and keep the RTO value more accurate. Solution 3 provides
more samples for alternate destination(s) to update their RTT
estimate at the expense of additional overhead in each packet...<<<

Wolfgang

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Mon, 21 Jul 2003 10:35:37 -0400 (EDT)

On Mon, 21 Jul 2003, Schruefer Wolfgang wrote:

> I studied your paper with high interest, but my conclusion is that a
> mirrored Retransmission Flag would be a perfect solution for the
> scenario you describe in the paper.
>
> With the mirrored Retransmission Flag you _can_ recalculate RTO on the
> second path. You just can not do it for the third or further paths.
> And here I think that the third path (resp. the a RTO calculation for
> the third transmission) may not be so important to improve.

Well, your one bit solution only works if the sender follows the
recommended mechanism for retransmissions. There hasn't been a consensus
that retransmitting on an alternate path is always the best policy. In
fact, I would argue that it isn't. I believe that for better performance
without affecting failover performance, fast retransmits should go to the
same destination and timeout retransmits should go to an alternate
destination [1].  With such a retransmission policy, one bit would
not be enough. Sure we could use 2 bits, but timestamps just seems
cleaner.

[1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf

~armando

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 21 Jul 2003 14:52:52 -0500

> [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf

In the paper cited, you fault the default SCTP behavior for assuming
"that loss indicates either that the destination address used is 
unreachable,
or the destination's network path is congested."

The implication is that the end-to-end algorithm is "giving up too 
quickly"
on a path, and thereby degrading performance.

As that I have seen this objection most often raised when the final hop
is a mobile and/or wireless link, I am tempted to turn that question 
around.

Isn't the real problem that the last hop is giving up on L2 delivery too
quickly, and creating an L3/end-to-end problem for something that
should have been handled locally?

Basically, is each downstream frequency *really* a path? Or should
the collective set of frequencies be viewed as a single L3 path
over which there may be L2 retries?

I designed a two-way CATV system to carry IP traffic through
set-top decoders while I was at Zenith Electronics. Whenever
the set-top needed to change frequency it would be deaf to
the headend for a short period. Realizing that dropping
packets during such a frequency shift would lead to very
poor end-to-end performance, we simply scheduled the
packet to be L2-delivered on a frequency as soon as it
was known, or on all frequencies if the receiver's status
was not known.

We certainly do not want to begin an L2 design debate
here, but I think it is a valid question -- is it a valid assumption
that L2 delivery should be dealing with truly transitory
problems and therefore packet loss really should be
taken to as an indication that the destination address used
is unreachable or the destination's network path is
congested?

Caitlin Bestler - [email-masked] - http://asomi.com/