Subject: RE: [Tsvwg] Congestion window init

From: [email-masked]
Date: Mon, 18 Mar 2002 19:18:51 +0200

Hi Arun!

> Hi all, 
>     This is the Scenario.... Iam setting the 
> Local Rwnd = 1500 ..... 

	Local? Do you mean your own buffer?

	I imagine that you mean your peer's buffer...

> Since its recomended that SSThresh should be equal to Rwnd at Init time... 
> Ssthresh = 1500 
> Now the initial Cwnd = 2* MTU (say 3000) 
>     Now its in the condition that in the init time itself (Cwnd  > SsThreshold).. So 
> directly the state goes to "Congestion Avoidance" (as Cwnd >SsThreshold).... 
>     Ya, its wrong to have Cwnd >SSthresh at Init time..... But how should I ensure 
> that the Ssthreshold is set to a bigger value..... Any  other recomended value for 
> Ssthreshold is there ?? 

	I don't know why it is wrong to have cwnd>sshtresh at the init time... Yeah, it is kind of weird, but the rwnd is weird too...

	I don't think it really matters at all if you are in slow start or congestion avoidance, you will always be restricted by rwnd, not cwnd...

>     ( We can very well have the minimum limit of Ssthreshol be greater than 
>         2*MTU..... But curious to know what can be this value.... if Rwnd is less 
>         than 2 *MTU)... 

	But which would be the difference then?

	Ok, you start, and send one MTU... and nothing else since rwnd is already limiting you... When you receive the ack, you are not using the whole cwnd, so in either case (slow start or congestion avoidance) you would not increase your cwnd... And no matter if you increase cwnd or not, rwnd will be there limiting (ok, it could matter if the peer later dedicates more buffer space for this association).

	The point is that you are not going to be able to increase cwnd no matter which of the two algorithms you use... so it does not matter...

	BR Iván Arias Rodríguez
	
> From Rfc 2960: 
> " The initial cwnd before DATA transmission or after a sufficiently 
>       long idle period MUST be <= 2*MTU." 
> "   o  The initial value of ssthresh MAY be arbitrarily high (for 
>       example, implementations MAY use the size of the receiver 
>       advertised window)." 
> " A SCTP receiver MUST be able to receive a minimum of 1500 bytes in 
>    one SCTP packet.  : 
> Thanks 
> -arun 
> -- 

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

---

From: Arun Prasad <[email-masked]>
Date: Wed, 20 Mar 2002 16:12:14 +0530

Hi Ivan,
    Ya, I got ur point.... thanks for that.......

    I have one more question for you...

From your thesis  "Stream Control Transmission Protocol .The design of a new reliable transport protocol for IP networks" :

"An attacker could easily send us any of those ICMP messages to affect our
sending capabilities reducing our throughput. Therefore, the SCTP header was
designed so the Verification Tag is present in the ICMP messages. When
processing a received ICMP packet, the association affected is determined by
using the Source Address and Destination Address fields (carried in the IP header
inside the ICMP message), and the Source Port Number and Destination Port
Number (carried in the first 4 bytes of the SCTP header also included in the ICMP
message). Then, to validate that this ICMP packet was not sent by an attacker, the ICMP message is validated by comparing the SCTP
Verification Tag also carried in the ICMP message and checking that it is
the right one."

    The Verification Tag validation, which is specified above should be mentioned
in the RFC .... atleast with a MAY condition right.....( I think I didnt miss this in
the Rfc).....
     Since the point of validating the VTag for an ICMP message is very important
( in terms of an attacker...) the implementer of the SCTP should be informed about
validating it right!!!

Thanks
-arun

--
****************************************************************
V.Arun Prasad
HCL Technologies Ltd.
51, Jawaharlal Nehru Road,
Ekkattuthangal,
Guindy Industrial Estate,
Chennai - 600097.

Contact # : 9144 - 2334174
            9144 - 2334181
            extn : 233
****************************************************************