Re: ticket #38

I also agree "IP session" is not the right term. An alternative is to call it "application session" or just "session" if it is also not necessary for a requirement draft to introduce "flow". 

It is some "applications" that need session continuity. There is then no need to introduce "flow" for a requirement draft to keep it simple.

Then "IP session" in REQ1 can change to "application session"

"IP multicast session" in REQ7 can change to "multicast session"

Do we agree? If not, please suggest alternative text. 

H Anthony Chan

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brian Haberman
Sent: Thursday, August 01, 2013 2:35 PM
To: [email protected]
Subject: Re: [DMM] ticket #38

I agree with Charlie's request to move away from the term "session".  It really does not have much meaning in UDP-based applications.  However, the term "flow" does have some issues as well.  Are we using the term "flow" the way it is defined in RFC 5101?  If not, then it needs to be defined in this draft.

Regards,
Brian

On 8/1/13 8:09 AM, h chan wrote:
> Charles,
> Is the following change from "IP multicast sessions" to "multicast flows" okay?
>
> REQ7: Multicast:
> Version 06: DMM SHOULD consider multicast early so that solutions can 
> be developed not only to provide IP mobility to keep IP multicast sessions when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers.
>
> REQ7: Multicast:
> Version 07: DMM SHOULD consider multicast early so that solutions can 
> be developed not only to provide IP mobility to keep multicast flows when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers.
>
> H Anthony Chan
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Charles E. Perkins
> Sent: Saturday, April 27, 2013 2:19 AM
> To: [email protected]
> Subject: [DMM] Editorial suggestions for 
> draft-ietf-dmm-requirements-03
>
> Hello folks,
>
> Here are some editorial suggestions for the document.
>
> Check for missing articles.  For instance:
> "Gateway selection mechanism"  -->  "A gateway selection mechanism"
>
> "is also taking the"  -->  "also takes"
>
> Delete "However" before "assigning".
>
> Delete "Issues such as"
>
> Delete "When demand exceeds capacity,"  or else explain why the benefits are unavailable otherwise.
>
> "In particular, there is an increase in direct communications among
>      peers in the same geographical area."
>             --> there has always been such locality... in fact maybe less
>                   now than previously.  Otherwise, please provide a citation.
>
> Delete "While deploying"
>
> "today's mobile networks, service providers face"  -->
>              "Today's mobile networks present service providers with"
>
> Delete "more often than not,"
>
> Delete "Therefore it is not uncommon to observe that"
>
> "ever-increasing" -->  "unnecessary"
>
> "provided"  -->  "managed"
>
> "non-optimal"  -->  "unnecessary"
>
> Delete "Given this motivational background in this section,"
>
> "address these problems":  at this point in the document, the
>                   problems have not been identified.  As suggested earlier,
>                   there should be a section devoted to listing the problems,
>                   and then a cross reference to that section could go here.
>
> "changing IP address"  -->  "locator IP address"
>
> Insert "The" before "Gateway GPRS Support Node"
>
> "respectively, act"  -->  "all act"
>
> "SAE"  -->  "EPC"
>
> "closeby"  -->  "nearby"
>
> Center figure 2.  (and might as well center figure 1 too)
>
> "future flat IP-based"  -->  "flat IP-based"
>                   (unwise to predict the future)
>
> "states the requirements as follows" -->
>                                                  "identifies the following requirements"
>
> "Distributed deployment"  -->  "Distributed processing"
>                   ... also in "REQ1"
>
> "of IP sessions"  -->  "of some flows"
>
> "an optimal manner"  -->  "to avoid known bottlenecks"
>
> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the
>      following."
>                   ...  the following ?what?
>
> "each MN therein" .... the MNs are not "in" the tunnel, and they are
>                                                   not "in" the mobility anchor.
>
> "Centralized anchoring"  -->  "Centralized anchoring designs"
>
> "Distributing
>            the tunnel maintenance function and the mobility context
>            maintenance function among different network entities can
>            increase scalability."
>                   -->  only when the signaling protocol is properly designed.
>
> "is to be inline"  -->  "conforms"
>
> "may need to interoperate with a network or mobile hosts/
>             routers that do not support DMM protocols."
>                   ... this is technically infeasible.
> Suggested replacement:
> "may need to co-exist with a network or mobile hosts/
>             routers that do not support DMM protocols."
>
> Delete "The motivations of this requirement are"
>
> --
> Regards,
> Charlie P.
>
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm