headers
James M. Polk | 2 May 2006 20:50
Picon
Favicon

Fwd: IETF Meeting Survey

TSVWG

Please take the time (5-8 minutes) to fill out this survey.... these shape 
future meetings (food, snacks, layout, room set-ups, etc)

Thank you

>Date: Mon, 01 May 2006 11:24:42 -0400
>From: Ray Pelletier <rpelletier <at> isoc.org>
>Subject: IETF Meeting Survey
>
>All;
>It has been suggested that if I really wanted to get feedback on the 
>Meeting Survey (and I do)  I should have it forwarded by the WG Chairs to 
>the working groups - so this is a request that you ask members of the 
>working groups to complete a short survey that focuses primarily, but not 
>exclusively, on their meeting experience in Dallas.
>I truly want the info to make the changes members of the community want, 
>if possible and greatly appreciate your assistance in this regard.
>
>Those interested in taking the survey can find it at:
>http://www.surveymonkey.com/s.asp?u=649182049947
>
>Thanks
>Ray Pelletier
>IETF Admininstrative Director
Permalink | Reply | 0 comments |
headers
Randall Stewart | 3 May 2006 02:24

Joint SCTP and RSERPOOL inter-op

All:

Please find the attached link, thanks Alan Wagner, for
the SCTP interop... we will also be holding a
mini-rserpool interop

http://www.cs.ubc.ca/~wagner/SCTP/

Happy SCTP'ing

R

--

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)
Permalink | Reply | 0 comments |
headers
devayya | 5 May 2006 17:47
Picon

[Fwd: Re: [Sigtran] multi-homing association]

I thought the question now will be for tsvwg group So I am forwarding it here.

Please clarify below comments.

Thanks,
devayya

-------- Original Message -------- Subject: Date: From: To: CC: References:
Re: [Sigtran] multi-homing association
Fri, 05 May 2006 19:24:19 +0530
devayya <devayya.bopaiah <at> alcatel.com>
"Santiago Muñoz (E2/EEM)" <santiago.munoz <at> ericsson.com>
Michael Tuexen <Michael.Tuexen <at> lurchi.franken.de>, sigtran <at> ietf.org
<9B1B7ED672B346458A88F024D474D8550200ABBF <at> eesmdmw020.eemea.ericsson.se>


Hi ,
 Please find my inline comments

regards,
devayya

Santiago Muñoz (E2/EEM) wrote:
Hi, In the RFC2960 clause 10 it is suggested a upper layer to SCTP layer interface (API), in fact clause 10.1 B) is about the establishment of an association, and there it is said that a list of possible destination IP addresses can be specified. Though the API method is just a suggestion and the list of destination addresses may only consist of one, so to know several destination IP addresses by the upper layer is just optional, though I dare say desirable (at least two for the case you describe). If the SCTP upper layer knows several destination addresses, the most optimal implementation of the API should be to specify them all in the ASSOCIATE method to SCTP so it is in charge of trying all specified addresses in the establishment, off loading of such task to the upper layer.
Does this mean that the if SCTP sends a INIT on first IP address and upon not getting the response from destination within the T1 timer, SCTP tries with the second destination IP address?
What if, the first destination Ip address responds with INIT or INIT ACK? Should we accept it after T1? And what about OOTB INIT ACK processing?  Doesnt it mean that we are entering a endless loop.
In case only one is indicated to SCTP, if it is down then the association is never established. How the upper layer knows about the destination addresses, I think it depends on the upper layer implementation, local manual configuration, DNS resolution, any dynamic discovery procedure are valid methods through which the SCTP can knows the destination IP addresses. Best regards, Santi -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen <at> lurchi.franken.de] Sent: viernes, 05 de mayo de 2006 14:25 To: devayya Cc: sigtran <at> ietf.org Subject: Re: [Sigtran] multi-homing association Hi, see my comments in-line. Best regards Michael On May 5, 2006, at 1:59 PM, devayya wrote:
Hi, I have question, Is it possible or mandatory for the upper layer to know that the SCTP endpoints(source and destination) are multi- homed? and also the list of destination ip address available with the SCTP multi-homed destination?
The interface between SCTP and its upper layer is not specified in an RFC. However, there is an ID describing the socket API which is implemented by some SCTP stacks like the one in *BSD, Linux (LKSCTP), and Solaris.
Consider if the SCTP layer is multi-homed(source and peer end) and the upper layer knows only about a single address, through which the upper layer asks the SCTP to initiate a association. Suppose during this initiation if the peer end address through which initiation is happening, is down. Is there any approach where the upper layer knows the list of multihomed destination ip addresses, and it tries to initate the through the other destination ip addresses?
If the initiating endpoint knows more than one address of the peer, it can use the connectx() or sendx() call to make use of this knowledge. It is up to the implementation how to make use of it.
If not possible, is it that the association between these to endpoints will never come up untill the known destination ip address comes up?
If the endpoint knows only one address of the peer and that address is not reachable, than the association can not be setup. However, in the SIGTRAN environment is is pretty common (at least from my experience) that an endpoint knows all the addresses of the peer in advance (by configuration) and can make use of it even during associations setup.
Please clarify... Thanks and regards, devayya _______________________________________________ Sigtran mailing list Sigtran <at> ietf.org https://www1.ietf.org/mailman/listinfo/sigtran
_______________________________________________ Sigtran mailing list Sigtran <at> ietf.org https://www1.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 501 comments |
headers
Mark Butler | 5 May 2006 20:40

Re: [Fwd: Re: [Sigtran] multi-homing association]

devayya wrote:

Santiago Muñoz (E2/EEM) wrote:
If the SCTP upper layer knows several destination addresses, the most optimal implementation of the API should be to specify them all in the ASSOCIATE method to SCTP so it is in charge of trying all specified addresses in the establishment, off loading of such task to the upper layer.
Does this mean that the if SCTP sends a INIT on first IP address and upon not getting the response from destination within the T1 timer, SCTP tries with the second destination IP address?
Yes.  This is described in RFC2960 Section 4 Note 2 and RFC2960 Section 6.4.

What if, the first destination Ip address responds with INIT or INIT ACK? Should we accept it after T1?
Yes.  See RFC2960 Section 4.  It doesn't matter what the source address is, as long as it is known to the initiator, and the verification tag matches.  Properly speaking, addresses do not respond, endpoints do.

And what about OOTB INIT ACK processing?  Doesnt it mean that we are entering a endless loop.
No.   A true OOTB INIT ACK causes an abort. (c.f. RFC2960 Section 8.4).  An otherwise unexpected or duplicate INIT ACK is ignored. (c.f. RFC2960 Section 5.2.3)

- Mark B.
Permalink | Reply | 501 comments |
headers
rfc-editor | 6 May 2006 02:42
Favicon

RFC 4495 on A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4495

        Title:      A Resource Reservation Protocol (RSVP) 
                    Extension for the Reduction of Bandwidth 
                    of a Reservation Flow 
        Author:     J. Polk, S. Dhesikan
        Status:     Standards Track
        Date:       May 2006
        Mailbox:    jmpolk <at> cisco.com, 
                    sdhesika <at> cisco.com
        Pages:      21
        Characters: 44983
        Updates:    RFC2205
        See-Also:   

        I-D Tag:    draft-ietf-tsvwg-rsvp-bw-reduction-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4495.txt

This document proposes an extension to the Resource Reservation
Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an
existing reservation.  This mechanism can be used to affect
individual reservations, aggregate reservations, or other forms of
RSVP tunnels.  This specification is an extension of RFC 2205.  
[STANDARDS TRACK]

This document is a product of the Transport Area Working Group
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of 
the Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...
Permalink | Reply | 0 comments |
headers
Kanand | 8 May 2006 13:12
Picon

- Heart Beat interval

hi,
   As per RFC 2960 and present implementation of SCTP stack, HEARTBEAT 
interval is calculated  as mentioned in  
   section 8.3
              i,e  heartbeat interval = RTO + jittering of ± 50% of  
heartbeat interval

   As per  implementors  Guide in section 8.3,  hearbeat interval is 
calculated as follows,

    heartbeat interval = RTO + jttering of ± 50% of  RTO
    i,e  jttering of ± 50% of  RTO not  jttering of ± 50% of  HEARTBEAT

  do we need to implement  this calculation  in present stack according 
to implementor's guide?
  If so  what is the purpose of  doing this  change?.

regards
kalpana
Permalink | Reply | 4 comments |
headers
Brian F. G. Bidulock | 8 May 2006 13:32
Favicon

Re: - Heart Beat interval

Kanand,

Kanand wrote:                                   (Mon, 08 May 2006 16:42:44)
> hi,
>    As per RFC 2960 and present implementation of SCTP stack, HEARTBEAT 
> interval is calculated  as mentioned in  
>    section 8.3
>               i,e  heartbeat interval = RTO + jittering of ± 50% of  
> heartbeat interval
>   
>    As per  implementors  Guide in section 8.3,  hearbeat interval is 
> calculated as follows,
> 
>     heartbeat interval = RTO + jttering of ± 50% of  RTO
>     i,e  jttering of ± 50% of  RTO not  jttering of ± 50% of  HEARTBEAT
> 
>   do we need to implement  this calculation  in present stack according 
> to implementor's guide?

Yes, eventually.

>   If so  what is the purpose of  doing this  change?.

The jitter is to keep many hosts from sending at the same instant.  The
RFC 2960 calculation does not acheive that (±50% of a fixed, known value
is not a jitter at all).  The IG calculation, being ±50% of a variable
value that can vary widely from host to host, acheives the purpose.

--brian

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 3 comments |
headers
devayya | 8 May 2006 13:31
Picon

Re: - Heart Beat interval

Brian,

But the HBInterval is re-calculated based on path RTO. So how can HB interval can be a fixed value? Please clarify.

thanks,
devayya

Brian F. G. Bidulock wrote:
Kanand, Kanand wrote: (Mon, 08 May 2006 16:42:44)
hi, As per RFC 2960 and present implementation of SCTP stack, HEARTBEAT interval is calculated as mentioned in section 8.3 i,e heartbeat interval = RTO + jittering of ± 50% of heartbeat interval As per implementors Guide in section 8.3, hearbeat interval is calculated as follows, heartbeat interval = RTO + jttering of ± 50% of RTO i,e jttering of ± 50% of RTO not jttering of ± 50% of HEARTBEAT do we need to implement this calculation in present stack according to implementor's guide?
Yes, eventually.
If so what is the purpose of doing this change?.
The jitter is to keep many hosts from sending at the same instant. The RFC 2960 calculation does not acheive that (±50% of a fixed, known value is not a jitter at all). The IG calculation, being ±50% of a variable value that can vary widely from host to host, acheives the purpose. --brian
Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 8 May 2006 14:33
Favicon

Re: - Heart Beat interval

devayya,

See rfc4460 section 2.10.1 "Description of the problem".

--brian

devayya wrote:                                                    (Mon, 08 May 2006 17:01:52)
> 
>    Brian,
>    But  the  HBInterval is re-calculated based on path RTO. So how can HB
>    interval can be a fixed value? Please clarify.
>    thanks,
>    devayya
>    Brian F. G. Bidulock wrote:
> 
> Kanand,
> 
> Kanand wrote:                                   (Mon, 08 May 2006 16:42:44)
>   
> 
> hi,
>    As per RFC 2960 and present implementation of SCTP stack, HEARTBEAT 
> interval is calculated  as mentioned in  
>    section 8.3
>               i,e  heartbeat interval = RTO + jittering of ± 50% of  
> heartbeat interval
>   
>    As per  implementors  Guide in section 8.3,  hearbeat interval is 
> calculated as follows,
> 
>     heartbeat interval = RTO + jttering of ± 50% of  RTO
>     i,e  jttering of ± 50% of  RTO not  jttering of ± 50% of  HEARTBEAT
> 
>   do we need to implement  this calculation  in present stack according 
> to implementor's guide?
>     
> 
> Yes, eventually.
> 
>   
> 
>   If so  what is the purpose of  doing this  change?.
>     
> 
> The jitter is to keep many hosts from sending at the same instant.  The
> RFC 2960 calculation does not acheive that (±50% of a fixed, known value
> is not a jitter at all).  The IG calculation, being ±50% of a variable
> value that can vary widely from host to host, acheives the purpose.
> 
> --brian
> 
>   

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 0 comments |
headers
Mark Butler | 8 May 2006 18:35

Re: - Heart Beat interval

Brian F. G. Bidulock wrote:
Kanand, Kanand wrote: (Mon, 08 May 2006 16:42:44)
hi, As per RFC 2960 and present implementation of SCTP stack, HEARTBEAT interval is calculated as mentioned in section 8.3 i,e heartbeat interval = RTO + jittering of ± 50% of heartbeat interval As per implementors Guide in section 8.3, hearbeat interval is calculated as follows, heartbeat interval = RTO + jttering of ± 50% of RTO i,e jttering of ± 50% of RTO not jttering of ± 50% of HEARTBEAT do we need to implement this calculation in present stack according to implementor's guide?
Yes, eventually.
If so what is the purpose of doing this change?.
The jitter is to keep many hosts from sending at the same instant. The RFC 2960 calculation does not acheive that (±50% of a fixed, known value is not a jitter at all). The IG calculation, being ±50% of a variable value that can vary widely from host to host, acheives the purpose.
The proper concept of "jitter" here is not to add one of two fixed values, but rather to add a random value that is within the specified range.  Given a suitable random number generator, the Implementor's Guide rule is much more stable and responsive - the previous formula can take an considerable amount of time to adapt to a decreasing RTO for example, not to mention produce negative results.

 - Mark B.



Permalink | Reply | 0 comments |

Gmane