Subject: RE: [Tsvwg] SCTP Timestamps

From: [email-masked]
Date: Wed, 16 Jul 2003 21:04:00 +0300

Hi all!

	I have been following this topic and I have one comment or two...

> From: ext Armando L. Caro Jr. [mailto:[email-masked]]
> Sent: Wednesday, 16 July, 2003 20:35

...

> 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

	But... The HB-ACK itself acts as the SACK, you don't need the SACK at all... I'm not sure whether I'm missing anything... :-/

	You might include in the HB information the TSN, and the time when it was sent, as it has been already said. That uniquely identifies the HB-ACK when it arrives as having been produced after the reception of one specific DATA chunk...

	So you send your DATA+HB and wait for either the SACK or the HB-ACK. Any of these (or better, both in the same datagram) will tell you about the reception of the DATA chunk.

	I think this might be a way to solve the problem... The cost, however, would be 16-20 bytes per DATA chunk (depending on how many bytes takes the time information). In any case 4 more bytes (the ones of the Heartbeat Information header) than using a special chunk...

	You could always include, let's say, the last 24 bits of the TSN plus 8 bits (or less) indicating how many times you have already retransmitted this TSN, instead of including the time value. This would also uniquely identify the HB-ACK... Now that I think about this, a specific chunk might use the Chunk Flags for this, so only 8 extra bytes would be needed...

	Or even better, you don't need at all to include the TSN inside the HB, just an unique identifier, as in the IP header...

	BR Iván Arias Rodríguez

> 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

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

---

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

Hei Ivan!!

Yes, you are right. The HB-ACK becomes like another SACK. I like these
ideas. Since the information contained in the HB is actually sender
implementation specific, each implementation can embed what ever info they
find most useful. It's up to that implementation to be effecient with
overhead tradeoffs.

I guess the only concern left is avoiding too many HB-ACKs on the wire.
I'm not sure how much Eifel detection will by affected by reducing the
number of bundled HBs.

~armando

0--                                                  --0

---

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

On Wed, 16 Jul 2003, Sourabh Ladha wrote:

> I do not agree at all if this is a "clean" way to proceed if a timestamp
> information per packet is required. The cost that you incur by
> this is a whole new definition of SACK, HB-ACK and rules associated with
> these. (For example you would still need SACKs along with HB-ACKs if an
> out of order, duplicate chunk is recieved)
>
> I still think if needed an optional timestamp chunk is the best way to go
> if such an information is required.

Like I said, using HBs is good enough for gathering more RTT measurements
on alternate paths, but _may_ not be good enough for Eifel detection. I
think that using HBs would be almost as good as the timestamp chunk if we
could figure out how to solve the HB-ACKing every packet problem. I do
agree that an optional timestamp chunk is the best way, because the
timestamp is guaranteed to be bundled. However, if we can get most of the
gains with just the HBs, that would be a big plus. It's always nice when
only one end has to be modified to get the improvment.

~armando

0--                                                  --0

---

From: Sourabh Ladha <[email-masked]>
Date: Wed, 16 Jul 2003 14:44:05 -0400 (EDT)

-Sourabh

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 16 Jul 2003 18:18:45 -0500

With a new optional chunk, you still need to pay the cost for adding
negotiation at init, new procedures, changes to the receiver for using
this feature. This IMO would cost even more.

-Qiaobing

---

From: Janardhan Iyengar <[email-masked]>
Date: Wed, 16 Jul 2003 22:10:45 -0400 (EDT)

Hi all,

I just got through the entire thread; an attempt to consolidate broadly
the solutions being discussed - there seem to be two possibilities:

1. Negotiation during association setup.
Upside: Timestamps option can be negotiated.
Downside: Receiver knowledge required; new chunk types required (TS,
          TS-ECHO).

2. No negotiation during setup.
Upside: Sender-side mods only; use existing chunk types (HB, HB-ACK).
Downside: Possible increased traffic on return path; heuristics required
	  to detect spurious retransmits.

As far as either of these solutions is concerned, the overhead of
reserving space in datagrams for either Timestamps or HBs exists; the
sender has to take into consideration space needed for either a TS or HB
chunk when fragmenting user data. IMHO, the difference in bit overhead
between the two options is trivial. In fact, if negotiation is done, the
sender can fragment data accordingly, i.e, reserve space or not in the
datagram.

Given that space is available in the datagram, the sender has to figure
out reliable mechanisms of using HB-ACK information to reliably infer
spurious retransmits. Since the receiver's response is not known for
certain, the sender may have to use heuristics to infer this information.

I'm not certain why a TS option was not proposed, given that it exists for
TCP (maybe because of packetization problems?). This point biases my view,
because it seems to me that a TS chunk can have uses beyond the immediate
Eifel algorithm on hand. (I may be wrong here; but not having a TS option
seems like removing an option that has existed with TCP; I do not see a
replacement in SCTP). Further, if a TS chunk is used for Eifel, the sender
_may_ be certain about the response from the receiver, _possibly_ free
from ambiguity.

I am leaning towards specifying a TS option; I do not think that option
negotiation at setup should become a bottleneck. At the same time, Ivan's
comment also seems appropriate that it is a good idea to have an inference
mechanism in case the receiver does not recognize the TS option.  So,
maybe two algorithms should be considered.

In case of purely sender-side mods, I have a thought in mind:

On detection of a loss through an RTO, the sender sends a HB bundled with
the next three datagrams that are sent. These HBs can carry whatever
information is required by the sender to disambiguate the HB-ACKs from one
another, and other timing information as well. If the sender receives
alternating SACKs and HB-ACKs or SACKs bundled with HBs, the sender should
be able to infer that the SACKs received were for rtxs. Three HBs (or half
cwnd) may be good enough in the face of loss on the return path. Of
course, this is another heuristic.

Caitlin's point about Video on Demand servers sounds interesting, but I
have a feeling that the solution needs more accurate time measurements in
the kernel. I'm in no capacity to comment on the complexity involved here.
Maybe somebody more capable could comment?

Comments? (I apologize for the lack of brevity)

regards,
jana

On Wed, 16 Jul 2003, Qiaobing Xie wrote:

> 7bit
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 7bit
>

-----------------------------------------------------------------------
Janardhan R. Iyengar		       http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab			 University of Delaware
-----------------------------------------------------------------------

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 21:38:05 -0600

Sourabh,

I agree that HEARTBEAT/ACK is not a good way to do this.  Although the
opaque data in the chunk looks attractive, there are rather narrow rules
for the handling of HB/ACK that have a rather different purpose.  SCTP
relies on the HB mechanism for recovery of unavailable destinations in
the multihomed environment and is also important for detection of lost
ABORTs.  There are some items concerning HB that was discovered in interop
testing that showed that rather special rules were required to accomodate
implementations that could not (or did not) control source address vs. those
that did.

I think that by overloading HB/ACK for the purpose of doing more frequent
RTT measurements would break the original purpose of HB/ACK: testing the
availability of desintations, keeping RTO current on idle destinations, and
detecting lost ABORT chunks.

I too would prefer to see a different chunk, (TS chunk) bundled with all
outgoing packets containing DATA and use an extension of the SACK chunk to 
return pertinent timestamps.  (SACK is the right place to put it on the
return anyways.)

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 17 Jul 2003 14:12:27 -0500

Brian,

You made a good point and you convinced me that a separate TS chunk is
cleaner if this feature is really worthwhile to add.

-Qiaobing