Subject: RE: [Tsvwg] SCTP Timestamps

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

> -----Original Message-----
> From: ext Armando L. Caro Jr. [mailto:[email-masked]]
> Sent: Wednesday, 16 July, 2003 21:21
> 
> Hei Ivan!!

	Hola Armando! See my comments below...

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

	Exactly, but I would say that a 12 bytes HB would make it... I don't think you should include anything else but a 32-bit identifier of the HB sent...

	At the sender you can keep all the needed information in order to make sense out of a received HB-ACK, such as TSNs included in the datagram and time sent...

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

	Well... You only need one HB per datagram, not per DATA chunk. But they are still 12 bytes you have to be ready to reserve in every packet sent... Or... no, maybe not...

	You are already reserve 16 bytes for the SACK chunk. So, if you don't need to include the SACK, let's say that the HB travels "for free".

	Moreover, I'm wondering if including such "timestamp HB" only when retransmitting something would be enough... This might make things more difficult to the data sender, since the peer could send the SACK and then the HB-ACK in a separate datagram, and the HB might even get lost and then... :-/ But probably this situation won't be worse than the current problem about losing a SACK...

	Also the SACK might come before the HB-ACK, so the sender should wait for some time before being sure that the HB-ACK won't arrive --> the SACK acknowledged the original datagram sent and not the retransmission (unless the HB-ACK was lost, of course).

	In the most common case you would be able to include a HB in every other datagram (when you don't include the SACK). If only one peer is sending data, then everything is perfect, you always have space... Of course, if there are TSNs lost, you might include SACKs in every datagram and then you won't be able to include HBs... However, in this case the SACK will be longer than 16 bytes, so you have the problem of space anyway and maybe you don't lack 12 bytes to put your HB inside the datagram, but have MTU-(16+12) extra bytes ... :-/

	My 0.02$

	BR Iván Arias Rodríguez

> ~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:54:36 -0400 (EDT)

On Wed, 16 Jul 2003 [email-masked] wrote:

> 	Well... You only need one HB per datagram, not per DATA chunk.
> But they are still 12 bytes you have to be ready to reserve in every
> packet sent... Or... no, maybe not...

Althogh packet reservation is an issue, that is not what my concern was
about. If a HB is included in each packet that contains DATA chunks, then
the receiver will send HB-ACKs for each of these packets. Thus, the point
of the delayed sack algorithm is lost.

~armando

0--                                                  --0

---

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

Armando,

Would the alternative approach (i.e., introducing a new timestamp and
echo chunk) change this situation? I seem to see no difference. Maybe I
missed something.

-Qiaobing

---

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

Timestamps, in of itself, doesn't make a difference. The difference is
when the receiver is aware of what the sender is trying to do. If the
sender is aware of the timestamps (or HBs), then the receiver can be sure
to bundle the timestamp echos only with SACKs.

~armando

0--                                                  --0

---

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

Armando,

Stange.  The DATA chunk might be difficult to extend without defining a
new EDATA chunk that contains a TS or rather complicated bundling rules for
bundling a some chunk containing TS with sent data, but the SACK chunk is
easy to extend.  There is no reason why any number of TLVs couldn't be tacked
onto the end of a SACK.

So why aggravate fragmentation and bundling on the way back?  Just tack a
TS TLV on the end of the SACK.  Didon't someone already define a TS TLV
(parameter not chunk).

Just a thought.

--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: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 16 Jul 2003 23:52:27 -0400 (EDT)

> TS TLV on the end of the SACK.  Didon't someone already define a TS TLV

Is that legal? Also, how does it alleviate frag/bundling issues?

~armando

0--                                                  --0

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 22:23:58 -0600

Armando,

> Is that legal? Also, how does it alleviate frag/bundling issues?

No, no, I didn't mean that it was legal now.  I meant that it is quite easy to
extend the SACK chunk because it has an internal length (number of gaps,
number of dups) that indicate the length of the content of the existing chunk.
Anything after the last dup TSN could be pretty much ignored.

Certainly an extension document would be required (one would anyway) and a
negotiation procedure for backwards compatibility.

The frag bundling it solves is what to do, for example, when a TS is bundled
with the wrong SACK.  Also, nowhere in 2960 does it say that two SACKs can't
be bundled in the same packet, although it is probably not done.  Having the
value in the SACK inexhorably binds it to the SACK to which it corresponds,
extinguishing all issues as to where what is in what message with respect to
the SACK.

It was just a thought.

--brian