Subject: Re: FW: ssthressh

From: Randall Stewart <[email-masked]>
Date: Wed, 29 Jun 2005 10:40:12 -0400

Haresign Lincoln wrote:
> OK...I think I understand.  Let me go back and look at my algorithms.
> 
> I have another question with regards to multihoming but related to
> congestion.  Let's assume that you have two destination addresses in a
> multi-homed association and you have experienced no retransmission.
> When sending data, should you always send over the "primary path"?  Or,
> everytime you want to send a packet, should you look at all the
> variables associated with each destination address (cwnd,
> bytes_in_flight, etc...) and choose the best path at that moment?
You should use the primary destination.. unless the Upper layer
as instructed you differently...

> 
> If I'm always sending over the primary, this means that I should only
> see heartbeats and retransmissions on the secondary short of a complete
> failure of the primary path.  

Yep... or if you go idle and have nothing to send the primary
may also get HB's
> 
> And another related question about bytes_in_flight.  Bytes_in_flight is
> being maintained per destination address.  If I am retransmitting data
> on a secondary path, I would increase bytes_in_flight on that path.  I
> would assume that at that time I should also decrease bytes_in_flight
> for the primary path since the bytes are probably lost in the network.
> Is that correct?
Well yes...

You have two cases..

1) You retransmit due to Fast Retransmit (FR)

or

2) Timeout.

If its <1>, and you do choose to retransmit to an alternate, then
you must decrease the number of bytes in flight to the old dest
and increase it to the new... However Aramando's PHD work as shown
that you are BETTER, performance wise, to let FR's go to the same
destination.. which would mean there would be no change in flight
size (if you do that).

If its <2> then the flight size at timeout on a destination
is set to 0.. since all data in-flight is considered lost
to that destination..

Hope that helps :-D

R

> 
> Thanks,
> Lincoln
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 29, 2005 9:42 AM
> To: Randall Stewart
> Cc: Haresign Lincoln; Terletsky Oleg
> Subject: Re: FW: ssthressh
> 
> 
> 
>>I don't know of any way for ssthresh to increase...  at least as far 
>>as I can remember it never does...
> 
> 
> ssthresh can increase, but not to infinity.  You well sketched why you
> would not want to return to that value (because ssthresh is, in some
> sense, a history and "infinity" means "I have no history").  However,
> say you have some cwnd of (just picking numbers) 100 segments and an
> ssthresh of infinity when you first observe loss.  So, ssthresh gets set
> to 50 segments.  Now we can slowly probe the network for additional
> capacity with congestion avoidance.  Say we get to 150 segments before
> observing another loss.  This indicates that there is now more capacity
> (say because there is less competing traffic).  Upon this second loss
> ssthresh is set to cwnd/2 or 75 segments and so increases.  But, it
> increases based on the probed capacity of the link.
> 
> 
>>he is a FAR greater expert in this arena then I :-D
> 
> 
> Ha!  Somehow I doubt it .... 
> 
> allman
> 
> 
> 
> ______________________________________________________________________
>   This email message has been scanned by PineApp Mail-Secure and has
> been found clean.
> 

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)