Subject: Re: [Sigtran] Comment on M2PA - Slow Start

From: Tom George <[email-masked]>
Date: Thu, 01 Aug 2002 16:52:35 -0500

Comments below....

Tolga Asveren wrote:
  [...]
> [TOLGA]In addition to the three cases you mentioned(alignment, changeover,
> path failure) there migth be problems, even when traffic is flowing, if the
> volume is changing. I didn't notice this before asking to Tsvwg but SCTP IG
> Page 30 says:
> " if ((fligthsize + Max.Burst*MTU) < cwnd)
>   cwnd = flightsize + Max.Burst*MTU       "
> So, I assume we should send messages like FISU (also for non-primary paths).
> An alternative would be to have a big Max.Burst value, but for that IMO one
> has to has a network, which is overengineered for the real traffic.

This convinces me that I need to have a general warning about slow start
rather than trying to talk about it in 4 (or more) places in the draft.

I think you are right about the overengineered network. But I think that
will be the normal case. I hope no one is planning to run SS7 traffic
over the public Internet. 

> 
> In fact, what does it mean exactly "to go through slow start"? I assume we
> want to assure that we have a specific amount of bandwith available(?). But
> if we "reserve" that bandwith (either by not caring about congestion control
> or by sending some dummy messages or by setting  Max.Burst to a large
> value), are we really making use of the resource sharing principle of packet
> networks?

IMHO it is a tradeoff. To work around the slow start, you give up
something else, such as the possibility of a large burst, or continual
transmission of dummy messages. To SS7, waiting through a slow start
after a changeover might be very bad. 

> 
> I assume you don't like the idea that SCTP emulates layer1( that it is a
> perfect wire), but then why do we try to go through slow start and increase
> cwnd of SCTP? IMO, this corresponds to have a wire with the bandwith of the
> desired cwnd. But as i said, if we don't want to see SCTP as the perfect
> wire, why not to say that there will be an implementation dependednt
> congestion detection mechanism on SCTP? When there is congestion, SCTP can
> inform M2PA and if necessary M2PA can inform MTP3.

I am not sure if I follow what you are saying. If possible, I would like
for SCTP to be able to start sending M2PA's traffic promptly after a
changeover, rather than getting congested and notifying M2PA.

> 
> From my queries in Tsvwg, I failed to understand the difference between
> heartbeat and data with the same length and period, from congestion control
> point of view. But current situation is, heartbeat does not play a role in
> cwnd calculation. Utilizing heartbeat for that purpose could be nice because
> some parameters to keep cwnd around a predefined value are dependent on RTO
> and flightsize and actual values of those parameters are not known to
> SCTP-user. I think, M2PA should somehow know those parameters and generate
> dummy messages according to them to preserve a desired cwnd value.
  [...]

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 2 Aug 2002 10:14:40 -0400

Tom,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tom George
> Sent: Thursday, August 01, 2002 5:53 PM
> Cc: [email-masked]
> Subject: Re: [Sigtran] Comment on M2PA - Slow Start
>
>
> Comments below....
>
> Tolga Asveren wrote:
>   [...]
[TOLGA] The main reason of my proposal about to use one stream for all
messages was to emulate layer1 with SCTP and layer2 with M2PA. The current
approach emulates some functionality of layer2 in M2PA and some in SCTP, at
least in my interpretation. Now, based on the current model, why do we need
to declare congestion to M2PA user, when we can't send messages from local
SCTP because of slow start -or congestion control- algorithm? IMHO, deciding
for congestion might be left as an implementation dependent logic. First,
SCTP can buffer some unsent messages and M2PA also has its own buffers. So,
personally I don't see the reason, why M2PA user should be informed about a
congestion as soon as messages can't be send because of cwnd, and also
similarly does SCTP need to declare congestion to M2PA, as soon as it can't
send messages becuse of congestion control?. Of course, changeover, path
failure etc... might cause at the end a congestion to be indicated to M2PA
user, but not directly and not always. If no special care is taken to keep
cwnd on a predefined value, situations like changeover etc... the messages
will be delayed more than the usual case for some period but this shouldn't
cause congestion all the times.
IMO, it could be nice to set congestion mechanism as implementation
dependent (at both SCTP and M2PA)-and probably to put some warning about
congestion control mechanims of SCTP itself-.

---

From: Tom George <[email-masked]>
Date: Fri, 02 Aug 2002 10:39:17 -0500

Tolga Asveren wrote:
  [...]
    [Tom G wrote:]

> least in my interpretation. 

Yes, that is correct. The intent of the M2PA draft is to divide MTP2's
functions between M2PA and SCTP. SCTP already provides some of the MTP2
functionality, so I did not want to duplicate that in M2PA. M2PA is
supposed to "make up the difference" between MTP3 and SCTP. 

>                             Now, based on the current model, why do we need
> for congestion might be left as an implementation dependent logic. 

Receive congestion is implementation-dependent in M2PA. For transmit
congestion, there are the requirements in Q.704, section 3.8. IMHO it is
unfortunate that these requirements are in Q.704 rather than Q.703,
because they look like MTP2 requirements to me. 

That said, I think there is some implementation wiggle room as to what
constitutes buffer occupancy for M2PA/SCTP.

>                                                                   First,
  [...]

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 2 Aug 2002 12:20:35 -0400

Tom,
> supposed to "make up the difference" between MTP3 and SCTP.
[TOLGA] Now it looks to me more like M2PA does almost everyhting MTP2 does
and SCTP behaves as an error-free transmission facility, -except using
multiple streams-. But O.K., I think we discussed this already and everybody
wrote her/his opinions and arguments.
> because they look like MTP2 requirements to me.
[TOLGA] Q.704 3.8 is the reason, why I would think transmit congestion
implementation dependent.
Q.704 3.8.2.1
"The location and setting of the congestion thresholds are considered to be
implementation-dependent"

---

From: Tom George <[email-masked]>
Date: Fri, 02 Aug 2002 16:39:32 -0500

Then is the draft OK? It says that receive congestion is implementation
dependent. And it says that transmit congestion follows Q.704, which as
you say is implementation dependent.

tomG.

Tolga Asveren wrote:
  [...] 
    [Tom G. said:]