Subject: RE: [Tsvwg] HEARTBEAT/cwnd

From: [email-masked]
Date: Thu, 25 Jul 2002 16:20:35 +0300

Tolga,

> -----Original Message-----
> From: ext Tolga Asveren [mailto:[email-masked]]
> Sent: 25. July 2002 16:05
> To: [email-masked]
> Subject: RE: [Tsvwg] HEARTBEAT/cwnd
> 
> 
> Ivan,
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Thursday, July 25, 2002 8:41 AM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [Tsvwg] HEARTBEAT/cwnd
> >
> >
> > 	Hi!
> >
> > 	With HEARTBEAT you are testing the reachability of the
> > addresses... With DATA chunks you are testing their capacity...
> [TOLGA] I agree using HEARTBEAT to avoid cwnd shrinking would 
> be using them
> for something, which is not the real intention.
> >
> > 	So, as far as you are not testing the capacity of the pipe,
> > you reduce your assumptions about the throughput... You might
> > know that it is still working, but you don't know how much can
> > you put there... maybe it got congested... :-/
> [TOLGA] But also with HEARTBEAT I am sending some amount of 
> bytes through
> the pipe. Let's say length of the DATA I send and my 
> HEARTBEAT are the same.
> Then what is the difference if they are sent with the same 
> period? In fact I

	Well... If you follow the rules (and recommendations) of RFC 2960 you will see that you are sending in average one HEARTBEAT every 31 seconds (heartbeat interval is 30, and the minimum RTO is 1 second)... You will shrink any possible increase in the cwnd much earlier than the next time you send a HEARTBEAT to that address (remember than you send one HEARTBEAT every 31 seconds for the whole association, so if you have more idle addresses this makes the whole thing every "worse").

	Even if you set HB.interval to 0, you are still sending one HB every one second... :-/

> understand your explanation but then why cwnd does not shrink 
> with user data
> of any length? RFC depends there just on the period. What 
> will happen if I
> send for some time a high volume traffic (and let's assume 
> cwnd grows) then
> the volume decreases, but still messages are sent with a 
> period lower than
> RTO. cwnd still stays the same. But based on your argument 
> again we are not
> sure whether the throughtput of the pipe is as much as before.

	I think you are right here... In fact this point was raised by Rainer Benedict some time ago, and he proposed some changes to the algorithm... Quickly, I think it was something like setting cwnd to some point between the flightsize and the present value of cwnd every RTO or so...

	After some discussion the idea was finally abandoned, I think...

	The subject of those messages (if there is any archive working) was "SCTP Max.burst and CWND", sent during the first days of March this year...

> > 	And about the period... Well, you send DATA chunks as long
> > as you have something to send... However, you just send
> > HEARTBEATs every now and then to addresses that do not have any
> > traffic... The idea is that you don't really send many
> > HEARTBEATs, so you don't flood the network with "useless" bytes
> > (I'm not saying they are useless, just that they don't carry any
> > user data)...
> [TOLGA] Yes, but to avoid cwnd to shrink, on the SCTP-user I 
> will need to
> generate some messages, which don't really contain usefull 
> information.

	Yes, you could do that in fact... I'm unsure now whether we should reopen the issue about the cwnd modification... :-/

	BR Iván Arias Rodríguez
> >
> > > -----Original Message-----
> > > From: ext Tolga Asveren [mailto:[email-masked]]
> > > Sent: 25. July 2002 15:47
> > > To: [email-masked]
> > > Subject: RE: [Tsvwg] HEARTBEAT/cwnd
> > >
> > >
> > > Ivan,
> > >
> > > Then what is the reason that HEARTBEAT does not prevent cwnd
> > > to shrink? What
> > > is the difference between HEARTBEAT and DATA from 
> congestion control
> > > procdures point of view, if they are sent with the same period?
> > >
> > >
> > >     Tolga
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]
> > > > Sent: Thursday, July 25, 2002 7:13 AM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: RE: [Tsvwg] HEARTBEAT/cwnd
> > > >
> > > >
> > > > 	Hi Tolga!
> > > >
> > > > 	See my comments inline...
> > > >
> > > > > -----Original Message-----
> > > > > From: ext Tolga Asveren [mailto:[email-masked]]
> > > > > Sent: 25. July 2002 3:03
> > > > > To: [email-masked]
> > > > > Subject: [Tsvwg] HEARTBEAT/cwnd
> > > > >
> > > > >
> > > > > In RFC2960 it is said at the end of page87:
> > > > > "When the endpoint does not transmit data on a given
> > > > > transport address, the
> > > > > cwnd of the transport address should be adjusted to
> > > > > max(cwnd/2), 2*MTU) per
> > > > > RTO"
> > > > >
> > > > > Does HEARTBEAT prevent cwnd to shrink if send in a period
> > > > > less than RTO or
> > > > > not? (Although it is RECOMMENDED to send HEARTBEAT at 
> a period of
> > > >
> > > > 	Nope... You must transmit data... A HEARTBEAT 
> might change
> > > > the "idle situation" of an address, but this is a different
> > > > thing... I.e., if you send a HEARTBEAT, you restart your "idle
> > > > timer" for that address, but the "shrinking timer" is still
> > > > running until you send some DATA chunk to that address...
> > > >
> > > > > HB.interval+RTO+jittering of +/- 50%, I assume I can send it
> > > > > with a lower
> > > > > period given that only RECOMMENDED keyword is used)
> > > >
> > > > 	Or you may even not send them at all...
> > > >
> > > > 	You are right, it is a recommendation (not to flow the
> > > > network with HEARTBEATs/ACKs), but you could use another method
> > > > if you think that it is more reasonable for your purposes...
> > > >
> > > > 	BR Iván Arias Rodríguez
> > > >
> > > > >     Tolga
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > tsvwg mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > > > >
> > >
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > >
> 
> 
> _______________________________________________
> 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: "Tolga Asveren" <[email-masked]>
Date: Thu, 25 Jul 2002 09:49:49 -0400

Ivan,

> Sent: Thursday, July 25, 2002 9:21 AM
> 	Well... If you follow the rules (and recommendations) of
> RFC 2960 you will see that you are sending in average one
> HEARTBEAT every 31 seconds (heartbeat interval is 30, and the
> minimum RTO is 1 second)... You will shrink any possible increase
> in the cwnd much earlier than the next time you send a HEARTBEAT
> to that address (remember than you send one HEARTBEAT every 31
> seconds for the whole association, so if you have more idle
> addresses this makes the whole thing every "worse").
>
[TOLGA] But the argument you are making here is about the period of sending
HEARTBEAT rather than why it shouldn't prevent cwnd to shrink. I understand
that in RFC the recommended values should be according to the (big I)
Internet, but for another IP network depending on the needs of applications
it is possible that people might use other parameter values.
> 	I think you are right here... In fact this point was raised
> by Rainer Benedict some time ago, and he proposed some changes to
> the algorithm... Quickly, I think it was something like setting
> cwnd to some point between the flightsize and the present value
> of cwnd every RTO or so...
>
> 	The subject of those messages (if there is any archive
> working) was "SCTP Max.burst and CWND", sent during the first
> days of March this year...
[TOLGA] IMHO, regardless of whether message length should play a role in
cwnd shrinking calculation or not, there is no difference between a user
data and HEARTBEAT of the same length and period, from congestion control
point of view.
> 	Yes, you could do that in fact... I'm unsure now whether we
> should reopen the issue about the cwnd modification... :-/
>
> 	BR Iván Arias Rodríguez
> > >

---

From: Arun Prasad <[email-masked]>
Date: Fri, 26 Jul 2002 14:55:34 +0100

Hi all,
    A small clarification:

* In IPV6 the intermediate routers will not fragment IP packets..
* There is nothing like DF bit in IPV6 Header.

    With the above two points, its clear that there is no DF bit funda to be carried
out for association involving IPV6 address.
Now the doubt is whether to completely rely on the IPV6 stack below for the
fragmentation of the packets ( When retransmitting an IP datagram to a remote
address for which the IP datagram appears too  large for the path MTU to that
address).. ie., in IPV4 case during this retransmission, we'll set the DF bit to 0...
allowing the IPV4 stack in the endpoint or the intermediate router to fragment
the packet.....
Since theres nothing to do in IPV6,  all the OS's IPV6 stack should
be capable of doing PMTU discovery and fragmenting the packet received from
above layer (of PMTU size)....  Is that right..... If any of the OS is not
doing this  (not sure whether any OS exist like this) , then SCTP will not be
supported in that OS right???

This is more of implementation Q... Hope the querry is clear ...

Thanks
-arun

---

From: Randall Stewart <[email-masked]>
Date: Fri, 26 Jul 2002 08:11:56 -0500

Replying to both you and Ivan... :>

> > addresses this makes the whole thing every "worse").

Here is a key point Ivan makes... you don't send them often enough
to preserve you cwnd... but I add more below :>

> > of cwnd every RTO or so...

Yes.. and I want Ivan to recall that we have jogged the implementors
guide to include Mark Allmans ideas on Max.Burst... i.e. it is
ALWAYS applied. So when you go to send you do the following:

*from the implementors guide:

"
   ---------
   New text: (Section 6.1)
   ---------

   D) When the time comes for the sender to transmit new DATA chunks,
the
      protocol parameter Max.Burst MUST first be applied to limit how
many
      new DATA chunks may be sent.  The limit is applied by adjusting
cwnd
      as follows:

      if((flightsize + Max.Burst*MTU) < cwnd)
	 cwnd = flightsize + Max.Burst*MTU

   E) Then, the sender can send out as many new DATA chunks as Rule A
      and Rule B above allow.

"

So even in Tolga's example here.. where you are only sending
one packet per RTT the cwnd is going to get collapsed down to
4 MTU's or so (whatever max.burst is).

Mark idea is quite clever... in fact I would think with this in
place one does not need to have a timer running to reduce the
cwnd since you DO end up effectively doing the shrink via the send :>

R

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 26 Jul 2002 08:15:13 -0500

Arun:

ALL IPv6 stacks do this fragmentation.. at least the ones
that I am aware of... There may be a broken stack somehwere
that does not.. but they SHOULD.. 

Now what happens is in comes a ICMP packet saying:
"packet to big.. mtu is X"

This goes to the IPv6 stack and is noted somewhere (usually the
route structure). It is also passed to SCTP who then makes
its adjustments..

Of course for a HUGE data chunk in queue (where Huge > x ) we
just resend it. Now when the IPv6 stack sees the packet sent
by SCTP it will do the fragmentation...

It is not a problem..

R