Subject: RE: [Tsvwg] SCTP Timestamps

From: "Duke, Martin" <[email-masked]>
Date: Wed, 16 Jul 2003 09:53:33 -0700

> On Wed, 16 Jul 2003, Sourabh Ladha wrote:
> 
> > I remember earlier having thought of using HB's for 
> timestamp purposes.
> > The problem is that while timestamp information is useful 
> for the sender, it
> > does requires intelligence at the reciever. I.E. The 
> reciever will have to
> > be aware  which timestamp to echo (e.x. In case a duplicate 
> chunk, in case of
> > delayed SACKS, etc [please see rfc1323). And so the need 
> for defining a
> > timestamp chunk.

I'm not sure the concerns in RFC 1323 apply here.  There are two cases where the most recent 
received timestamp isn't sent.  I would summarize them as follows:

A) To capture the delayed ACK timer in the RTT measurement, ack the 1st unacknowledged packet: since HEARTBEAT-ACKs have a 1:1 relationship to HEARTBEATs, this isn't really relevant.  If you like, one could delay the HB-ACK by the maximum delayed ACK time (500 ms), or add it at the measuring endpoint.

B) If there's a "hole" in sequence numbers, assume congestion and echo an old timestamp to be conservative: The value of this is arguable in any case, but as HBs don't have sequence numbers anyway there's no way for the receiver to detect a "hole."  You'll still get an accurate measurement of the RTT, rather than an inflated one produced in an effort to be "conservative."

C) DATA that is previously fully acknowledged: some argue that this is actually a bug in the RFC, but either way, I'm not convinced that this can cause a significant problem with HBs.  A HB duplicated in the network and long-delayed might trigger a single extremely high measurement, but this is a pathological case, and will hardly have catastrophic effects.

Then Armando wrote:
> Two more points why HBs may not work well:
> 
> 1. The sender would send HBs in almost every packet, which 
> could make the
> failure detection algorithm trickier.
> 
> 2. If data transmission is bi-directional, then a packet 
> which has SACK
> and DATA chunks will need two HBs. On the other hand, a 
> single Timestamp
> chunk is needed since it has a "timestamp" and "timestamp echo" field.
> 
> ~armando
> 

1)  There will have to be a change to the treatment of HBs sent out bundled with DATA.  It's probably impractical to have a timer running for each one, and to wait 30sec (or whatever) for the timer to expire.  However, we want to keep these features for testing paths that aren't busy, so I would suggest that the timer is not run for HBs bundled with data; the data being sent on that path is fully adequate for testing the path for failure.

2) Assuming the MTU is ~1500 bytes, you're talking about a 12? Byte HB and 12 byte HB-ACK, vs. a 10 byte TS.  So it's a 0.7% vs. 1.6% overhead, whereas using HBs requires no negotiation and stack modifications only on the side that wishes to do the measuring.  I think this outweighs a few bytes of overhead.

-Martin

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

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 16 Jul 2003 13:34:41 -0400 (EDT)

Martin,

You present some valid points (I especially like argument 1), but there is
still one problem. If the overloaded functionality of HBs are used without
negotiation, then the receiver will not delay HB-ACKs. Since HBs would be
bundled with each packet containing DATA chunks, the result will be
similar to that of turning off the delayed ack algorithm for SACKs.

I do like the idea of sender only changes. To avoid the above problem, the
HBs can be bundled every other packet to avoid so many HB-ACKs.

Like I said above, I like your argument 1. I was also thinking about
something like this... bundled HBs don't need timers or state, and if lost
the sender doesn't care.  Since DATA is bundled with the HBs, the data
would also be lost and that would help towards failure detection.

At the same time, HBs can still go to idle destinations the same way.
These HBs have timers and contribute towards failure detection.

All this works fine for gathering more RTT measurements for alternate
paths, but more complexity is needed to solve the problem that Stephan and
Sourabh brought up. They want a more robust method of detecting spurious
retransmits. HBs could be used, but the sender has to do more work at
putting the puzzle together. Since negotiation would not used, the
receiver may not bundle HB-ACKs with SACKs. Thus, it may not always be
possible to correlate timestamps in HB-ACKs with newly acked TSNs in
SACKs.  Also, if HBs are bundled with every other packet, then not all
spurious retransmits can be detected with equal accuracy. Some TSNs will
not have timestamps.

~armando

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

On Wed, 16 Jul 2003, Duke, Martin wrote:

> 1)  There will have to be a change to the treatment of HBs sent out
> bundled with DATA.  It's probably impractical to have a timer running
> for each one, and to wait 30sec (or whatever) for the timer to expire.
> However, we want to keep these features for testing paths that aren't
> busy, so I would suggest that the timer is not run for HBs bundled
> with data; the data being sent on that path is fully adequate for
> testing the path for failure.
>
> 2) Assuming the MTU is ~1500 bytes, you're talking about a 12? Byte HB
> and 12 byte HB-ACK, vs. a 10 byte TS.  So it's a 0.7% vs. 1.6%
> overhead, whereas using HBs requires no negotiation and stack
> modifications only on the side that wishes to do the measuring.  I
> think this outweighs a few bytes of overhead.
>
> -Martin
>