Subject: RE: [Tsvwg] EndPoint and Association Address conflict

From: "Balani, Sandeep" <[email-masked]>
Date: Tue, 30 Apr 2002 09:39:05 -0700

hi all, 
  my comments .. 

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 6:52 AM
> To: Jon Grimm
> Cc: Qiaobing Xie; Qiaobing Xie; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] EndPoint and Association Address conflict
> 
> 
> Jon Grimm wrote:
> > 
> > Randall Stewart wrote:
> > 
> > > Qiaobing Xie wrote:
> > >
> > >>R,
> > >>
> > >>A couple of comments...
> > >>
> > >>Randall Stewart wrote:
> > >>...
> > >>
> > >>>Now I have done a bit more thinking on this. The corner case that
> > >>>we were worried about was this (if I remember right):
> > >>>
> > >>>Host A                                          Host Z
> > >>>IP-A/IP-B                                       IP-Z
> > >>>(An UDP model Endpoint
> > >>> Listening on Port 2222)
> > >>>        IP-A:Port-2222<-----------------INIT(From IP-Z:Port 3333)
> > >>>        ----------INIT-ACK(IP-A,IP-B:Port 2222)-------->
> > >>>        <--------------COOKIE-ECHO----------------------
> > >>>        ----------------COOKIE-ACK---------------------->
> > >>>
> > >>>            Now at this point A-1 is up.
> > >>>
> > >>>Now along the line we do
> > >>>
> > >>>ifconfg New-Intf IP-C
> > >>>
> > >>>and magically do
> > >>>
> > >>>--------------ASCONF(ADD-IP:IP-C)------------------------>
> > >>>    <---------------------OperationalError(Unknown Chunk 
> ASCONF)-----
> > >>>
> > >>>So here we have a potential problem...
> > >>>
> > >>At this point, would our local stack (I am avoiding to 
> use endpoint
> > >>here) actually start to use IP-C as the source addr in 
> any outbound
> > >>packets in the current association? If so, that would 
> trigger an abort
> > >>from the peer and kill the current association. If not, 
> then strictly
> > >>speaking, IP-C has not yet been added to the local 
> **endpoint** that the
> > >>current associaiton is using. It has only been made 
> available to the
> > >>local stack for future use.
> > >>
> > >>
> > >>>                    now our silly peer does
> > >>>
> > >>> <------------------------IP-C:2222 INIT(IP-Z:Port 3333)
> > >>>
> > >>>What do we do?
> > >>>
> > >>> --------INIT-ACK(IP-A,IP-B,IP-C: Port 2222)---------->IP-Z:Port
> > >>>3333--->
> > >>>
> > >>When the local stack does this, it starts to manage two logically
> > >>different local endpoints - the one used by the old 
> association that has
> > >>only IP-A and IP-B; the other is intended for the new 
> association, as
> > >>advertised in this INIT-ACK, that has IP-A, IP-B, and IP-C.
> > >>
> > >>
> > >
> > > No it is managing two different assocaitions.. not endpoints...
> > >
> > > You are always allowed to have an ENDPOINT with a set of
> > > addresses... Associations have to be able to use subsets
> > > of the addresses... period.. otherwise forget IPv6..
> > >
> > >
> > 
> > I can't see if it matters or not, but how about the 
> delete-ip case?  If
> > an endpoint has multiple associations and a subset of the 
> associations
> > support delete-ip.   What should happens to the endpoint?  Is the
> > address really removed from the endpoint?  There are 
> associations still
> > using that address removed from some of the addresses.  I 
> can see where
> > I might want to keep the address in the endpoint until all 
> users of the
> > address have either ACKed the delete or have terminated.  
> In this case,
> > I wouldn't want to allow a new endpoint to form with that deleted
> > address.  Is this warped thinking?
> > 
> Jon:
> 
> well let see... I think the way we handled this is we DID
> remove it from the "endpoint" or listener... that way you
> will NOT accept new INIT's to this.. of course if the 
> address is truely removed from the system its a MOOT point :>
> 
> Now each association has its own list of addresses that are
> in this "present and not deleted state" or "added but not completed"
> state.
> That way if somehow a packet came in to that address we would
> locate the right association.
> 
> I think the big thing here that I have not stated is I don't
> believe we allow you to add/delete an IP address to a association.
> 
> You do a sctp_bindx() against an endpoint yes.
> 
> You have flags that say (default is on in most cases) DO ASCONF
> if you can.. So you get this behavior on all your fanned out
> associations.. but if I am adding an address and some association
> under my endpoint can't.. no big deal it just goes on a negative
> list saying.. don't use this address. (And we are in the kernel
> so we DO control the IP address that goes on the wire... if you
> can't control this address you are probably in rough shape and
> unable to do add-ip .. the more I think about it... of course
> if you can't control your IP address your stack is kinda broken :>)
> 
> But you CAN'T say ... add/delete this address to association X under
> this endpoint.
> 
> Now for the "connected/peeled-off" socket you can do this .. 
> since doing 
> a sctp_bindx() against the connected socket WOULD add it to the
> association.. but this of course does NOT change the listening
> endpoint... so it has no ramifications against future INIT's that
> arrive at the other endpoint that did NOT do a sctp_bindx() on the
> address.
> 

[ Sandeep] I think the case u just describe above is perfect case that an
Addition/deletion of IP address is based on an *ENDPOINT* not an association
[ i think that we all agree to that ], although i know that final
beneficiary is Association. 
But we don't need to confuse the readers that ADD/DELETE IP are happening on
an association. 

" We can always say that Addition/Deletion of  IP addresses are allowed on
an Endpoint. And because Source IP Address list is changing all the
association on that Endpoint need to modify their source IP address list and
indicate the same to the peer." 
  
any thoughts....

-thanks
sandeep 
> 
> R
> 
> 
> > 
> > <snipped everything else>
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 30 Apr 2002 14:10:37 -0500

Hi, all,

This discussion is going nowhere unless we all can agree on what we are
talking about :-< 

There are at least two parallel lines of thinking (i.e., socket
API-focused and protocol definition-focused) and three different views
of what an "endpoint" is (host-view, socket-view, association-view). We
don't even have an agreement on how these views differ (or whether they
actually differ), let alone what rules should be formulated. 

I hope someone can name these "things" first. Without these terms
clarified to all the participants, the discussion is IMO just a waste of
everybody's time.

-Qiaobing