Re: issue 19 -- same addresses for both directions?

"Mohan Parthasarathy" <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <019e01c56649$3ddbd4f0$6601a8c0@adithya>
 
> 
> I wrote earlier tha the decision on issue 20 (who decides)
> also has a big impact on issue 19. If we had decided in 20
> that the decisions  are independent, then it might in fact
> have been very hard to  ensure that the two directions
> use the same addresses. As a result, allowing different
> addresses would make  more sense in this scenario.
> 
> But we ended up with "initiator decides". Therefore the
> deciding entity knows enough about the situation to be
> able to use the same address pairs in both directions.
> 
> Of course, this does not necessarily have to be done.
> We could develop a protocol that provides independent
> addresses, yet would be controlled by the initiator.
> (Probably with some cost in terms of complexity.
> And I'm not quite sure how to deal with NATs and
> keepalives in that kind of a scenario.)
> 
Hmm.. we chose the "initiator decides" option because it works
well with NAT. So, i am not sure i understand the issue here.
Here, the initiator finds two sets of addresses (one for
upstream and one for downstream traffic) and updates the
peer providing information about which address pair to be used
for downlink and which address to be used for up link.
I would assume that it is the initiator's responsibility for sending
keep alives. So, what is the issue here with NATs ? 

If the initiator is multi-homed and connected simultaneously to more
than one access (e.g. UMTS and WLAN) at the same time, there
might be some usefulness in having different paths for upstream and
downstream traffic though i don't know really what it is :-)  

-mohan


> How do you folks feel about this? Please post your
> comments by Friday, June 3rd.
> 
> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.