Subject: RE: [Tsvwg] End point and association Address conflict

From: "Balani, Sandeep" <[email-masked]>
Date: Mon, 29 Apr 2002 15:15:40 -0700

Hi all,  

   I was looking at AddIP draft in which Section 4.1.1 has following RULE :

    R1) One and only one ASCONF Chunk MAY be in transit and
    unacknowledged at any one time.  If a sender, after sending an ASCONF
    chunk, decides it needs to transfer another ASCONF Chunk, it MUST
    wait until the ASCONF-ACK Chunk returns from the previous ASCONF
    Chunk before sending a subsequent ASCONF. Note this restriction
    binds each side, so at any time two ASCONF may be in-transit on any
    given association (one sent from each endpoint).

If thats the case, And let say we have an M3UA Endpoint at SGP node as E1 [
IP-A, 2905 ] & this SGP has associations with 100 ASP's .   And in this case
if i do ADDIP(IPb) on this Endpoint E1, than I have a major problem because
i have to send 100 ASCONF chunks one-by-one on all associations, which seems
very difficult & cumbersome taking in to consideration the race conditions
and scenarios mentioned in my previous mails. 

Any comments ???

thanks
sandeep  

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 1:58 PM
> To: Qiaobing Xie
> Cc: Qiaobing Xie; Tuexen Michael; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] End point and association Address conflict
> 
> 
> Qiaobing Xie wrote:
> > 
> > ...
> > > I don't agree with this rule.. just because a peer in a UDP model
> > > endpoint on one of its assocaitions is NOT capable of add-ip why
> > > should the rest be stuck. Yes you have an abnormality here in
> > > that that peer COULD send a INIT to the new address.. 
> again I repeat:
> > > 1) This is such a corner case it is almost silly.
> > > 2) If it happens it is not that hard to handle... Looking at
> > >    the code Peter and I wrote you would end up finding 
> the endpoint
> > >    (since the address WAS added there) and you would then LOOK at
> > >    its associations. This would then appear to be a 
> RESTART where the
> > >    peer added addresses. You would then SEND IT an ABORT 
> saying restart
> > >    while adding addresses. This would leave the other association
> > >    un-touched and would elimiate the error on the peers part...
> > 
> > Randy,
> > 
> > Let's walk through this example in detail:
> > Say, local endpoint E1 has two associations to different peers,
> > 
> >      E1             A1     E2
> > [IPA,IPB:Port1] <-------> [...]
> >      E1             A2     E3
> > [IPA,IPB:Port1] <-------> [IPZ:Port2]
> > 
> > We do add-ip (IPC) to E1. After sending ASCONF to both E2 and E3, we
> > succeeded with E2 but failed on E3.
> > 
> >      E1'               A1'     E2
> > [IPA,IPB,IPC:Port1] <-------> [...]
> >      E1'               A2'     E3
> > [IPA,IPB,IPC:Port1] <-------> [IPZ:Port2]  /* E3 rejected 
> add-ip and */
> >                                       /* hence knows nothg 
> about IPC */
> > 
> > My understanding is that you would like to allow this.
> > 
> > Now, several things could happen,
> > 
> > 1) E3 may get a packet from E1' with src addr=IPC. This packet will
> > becomes an OOTB to E3 and E3 will send back an ABORT to kill the
> > ill-fated A2'. This is ok.
> > 
> 
> Why would E1' use IPC... in this case it knows that it is NOT
> part of the association. So it MUST NEVER source things from
> IPC as long as this holds true .. no problem.. only if
> E1's implementation is so bad it sources from IPC that a
> problem will occur.
> 
> 
> > 2) E3 may send an INIT to IPC/Port1. Is this the corner case you
> > described above? If so, I can see E1'1 will find the 
> association A2' and
> > take this E3 INIT as a restart, but I don't see why E1' 
> will consider it
> > as a "restart with added address" (E3 didn't add any 
> address, it still
> > uses only IPZ).
> 
> Yes.. this is a very corner case.. 
> 
>  A) E3 must be very confused to want two associations.. so in
>     my mind this is a corner case.
> 
>  B) We would need to expand the rules that you must also check
>     the your addresses in a COOKIE-ECHO to see if you have
>     hit such a collision.. if so send an ABORT... 
> 
> I don't see this is a problem.. ABORTING your funny association
> with E3 should leave A2 alone and all should be well.
> 
> It seems to me we need to add this new rule for ADD-IP.
> 
> R
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: Peter Lei <[email-masked]>
Date: Mon, 29 Apr 2002 17:29:30 -0500

> and scenarios mentioned in my previous mails.

That should be one asconf outstanding per association; see the last sentence,
only two asconf's can be in-flight "on any given association".

--peter

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 29 Apr 2002 17:26:49 -0500

Hi, Sandeep,

This rule should be applied _per association_. So you are allowed one
ASCONF in-flight for each of the 100 fan-out associations in your
example. In other words, your local endpoint can fire out 100 ASCONFs,
each to a diffenrnt peer, at the same time. 

-Qiaobing