Subject: Re: [DMM] ticket #38

From: h chan <[email-masked]>
Date: Thu, 1 Aug 2013 12:09:44 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: Saturday, April 27, 2013 2:19 AM
To: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/dmm

---

From: Brian Haberman <[email-masked]>
Date: Thu, 01 Aug 2013 08:35:05 -0400

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

---

From: h chan <[email-masked]>
Date: Thu, 1 Aug 2013 15:06:57 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Thursday, August 01, 2013 2:35 PM
To: [email-masked]
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:
> 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
>

---

From: h chan <[email-masked]>
Date: Thu, 1 Aug 2013 15:42:39 +0000

Let me try to revise again if it helps to clarify the meaning:

"IP session" in REQ1 (in version 03) can change to "application session" (in version 07 to be uploaded today)

REQ7: Multicast:
Version 07: DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility to keep multicast application 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.

Or simply (less words)

REQ7: Multicast:
Version 07: DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility support to multicast applications 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: h chan 
Sent: Thursday, August 01, 2013 5:07 PM
To: 'Brian Haberman'; [email-masked]
Subject: RE: [DMM] ticket #38

H Anthony Chan

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

Regards,
Brian

---

From: h chan <[email-masked]>
Date: Fri, 2 Aug 2013 08:24:09 +0000

I am uploading version 07 with the following:

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not need to traverse centrally deployed
          mobility anchors and thereby avoid non-optimal routes.

(deleted IP session)

   REQ7:  Multicast considerations

          DMM SHOULD consider multicast early so that solutions can be
          developed not only to provide IP mobility support 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.

(deleted IP multicast session)

H Anthony Chan

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

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 02 Aug 2013 04:36:29 -0400

I am fine with this text.

Brian

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 2 Aug 2013 11:56:27 +0300

Looks OK to me.

- Jouni

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 2 Aug 2013 10:05:40 +0100

Hi Anthony,

I agree on the changed REQ1 title from distributed deployment to distributed
processing, in the sense that the main points in DMM lies on how effectively
DMM can distribute workload processing concentrated at single anchor.

If my sense is right, looking at the text, "~ so that traffic does not need
to traverse ... avoid non-optimal routes." doesn't seem to fit in well with
the title.
If we say "distributed processing", it has a meaning for load balancing,
which can be implemented in a centralized mobility management.

In conclusion, "distributed processing" and "optimal routes" come to me as
two different subjects. The latter can be achieved through the former or in
CMM. My opinion is not to get back to the previous title, but we need to
distinguish them clearly.

Regards,
Seil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Friday, August 02, 2013 9:24 AM
To: Brian Haberman; [email-masked]
Subject: Re: [DMM] ticket #38

(deleted IP session)

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian
Haberman
Sent: Thursday, August 01, 2013 2:35 PM
To: [email-masked]
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:
> 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.
> 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.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 02 Aug 2013 02:08:03 -0700

Hello Anthony,

I think the revised text looks very good, and resolves the issue.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 2 Aug 2013 13:00:53 +0300

And all remember to update the issue tracker.

- JOuni