Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Matt: Yes, CableLabe EPoC system using FCU instead of OCU; if this is what IEEE is going forward to use we need have an agreement.
In principle an OLT could has multiple FCUs or OCUs; one FCU to an OLT is a special case. As far as rate adaption and service providing are concerned MMP in reference to OLT is much more feasible than MMP in reference to FCU/OCU.
Thanks,
Eugene
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 4:57 PM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Eugene,
Completely agree on the need for more investigation on rate adaptation - you and others have brought up some valid points there, and it's something I'm concerned about as a result (even beyond MMP).
Also agree that the service provider needs to have control, or at least the ability to take control if they want it (I'd also like to leave room for vendors to come up with cool approaches that could make life easier for operators).
Regarding your scenarios... Actually, in an architecture of an OLT to an FCU (we changed from OCU to FCU) to CNUs, I had never actually considered having multiple profiles on the OLT to FCU link (and I'm not sure I want to :-) ). I was more thinking that on the coax link - from the FCU to the CNUs - you would either one have profile (SMP) or more than one (MMP).
However, you raise a point that was mentioned on a call recently, and I think is a very interesting one: what if you have multiple FCUs on a single OLT port? In that case, does every one of those FCUs have to use an identical SMP? Or can each of them have a different SMP? If the latter, how does this affect rate adaptation? And once you solve that problem, how much more of a leap would it be to allow multiple profiles on that single FCU?
Anyway, some points to consider.
Thanks!
Matt
From: <Dai>, "Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>>
Date: Monday, January 7, 2013 2:49 PM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Matt:
You brought some valid points. First, rate adaption; it is one of the most important issue for EPoC, however, it has not been thoroughly discussed yet. It is not rate decouple but pipeline rate adaption. We discussed the MMP issue with rate adaption in some details at San Antonio; I don't see any change for that part. So for the January meeting we need seriously get into rate adaption and trying to have a base line on it.
Second, for the service providing with MMP, there are two scenarios in general. One is MMP to an OCU and the other is SMP to an OCU but different OCU could have different SMP, one can loosely call it MMP in reference to different OCUs. Certainly we can provision different OCU with different MP according to previously known plant conditions, in this case MSO do have control. In the case that an OCU have MMP that determined at boot up time, the MMP is not controlled by service providers. Generally speaking, a service provider needs to have full control of their network elements in order to provide deterministic services.
To move forward, we need to discuss:
1. Rate adaption
2. Define outside plant conditions for EPoC
Thanks,
Eugene
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, January 07, 2013 4:19 PM
To: Dai, Eugene (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Eugene,
Thanks for the note, which is useful both for getting all thoughts on the table and ensure we're thinking of the same thing when we refer to this feature.
For example, while I would agree with you that there is no direct correlation between MMP and SLA, and that end-users would likely not get a higher provisioned tier of service as a result of this feature, might it be possible that they would see some benefit at congested times because there's more bandwidth to share around?
Also, you mentioned in your email that service providers do not have direct control of the feature, and I'm curious what specifically you're thinking of in that case. My assumption has been that while we would not want to preclude the ability for a CLT/FCU to make autonomous changes to a profile, it would be something that was both not required and configurable by the operator. In that sense, the operator has full control over what profiles are available. Further, while we'll certainly want to have some autonomous mechanisms for switching between profiles - and we'll need to defer to the CLT to decide how to schedule things, at least to some degree - I don't think it would be unreasonable (and likely in fact a very good idea) to allow the operator to define a progression order for the profiles (if you have to leave one profile, then you go to this other one next, etc.), and maybe even some high level bounds around when to switch (again, allowing room for vendors to develop their own algorithms). In those ways, I was thinking that the operator would have a large degree of control, which they could choose to use or not. Did you have something else in mind?
As for economic feasibility, that will be driven by a combination of the potential economic gain from the feature vs. its cost. The former is very much derived from analysis of use cases (IMHO), which is why I think they do have relevance; the latter is driven by technical feasibility and complexity.
What I would be very interested in seeing is more details on why people believe it is not technically feasible to do MMP with EPoC. I'm not saying that it is or it isn't - I don't regard myself as enough of an expert on EPON to render an opinion there. However, when I hear one group say it is feasible, and another say it isn't, that makes me want to understand better why one side or the other thinks it is or isn't feasible. Does that make sense?
Thanks!
Matt
From: <Dai>, "Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>>
Reply-To: "Dai, Eugene (CCI-Atlanta)" <Eugene.Dai@xxxxxxx<mailto:Eugene.Dai@xxxxxxx>>
Date: Monday, January 7, 2013 1:34 PM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Jorge:
Sorry for missing the last meetings, I was at Pacific Time zone. Now I am back to East time zone, I'll try to join tomorrow's meeting.
The fundamental question of MMP is its technical and economic feasibility under the EPON MAC framework; I didn't think use cases will help at this point. We have presented detailed analysis of both technical and economic challenges of MMP at the San Antonio meeting; I believe everything we have presented still hold. Although I do not believe re-present the old material will help moving forward, I am willing re-present the main points (of San Antonio presentation) tomorrow if necessary; it seems this was what other people did anyway.
A few summary points:
From service providing point of view:
* End-users do not get notable benefit from MMP
* Service providers do not have direct control of MMP
* There is no direct relationship between MMP and SLA
From technical feasibility point of view:
MMP introduce significant complexity at PHY, MAC and system levels, especially for EPON to coax rate adaption.
From outside plant point of view:
A network reference model is needed that including outside plant and in-home-networks that provide base outside plant conditions reference for the future EPoC.
Thanks,
Eugene
From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
Sent: Monday, January 07, 2013 2:51 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Ed,
Perhaps, given that you're having difficulty getting to the ad hoc calls, you could enumerate your issues here on the exploder. That would at least open the dialog and we could debate the issues you see. Personally I don't see anything that cannot be addressed.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Monday, January 07, 2013 2:29 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Hi Jorge,
I hope that you had a great holiday. Sorry but I'm a little behind on things due to the time off.
I agree with Marek. I presented issues with the MMP at the last meeting. I looked over the Qualcomm presentation from the Ad Hoc and I didn't see any difference from the last IEEE meeting. The issues that I raised at the meeting still exist. If you like, I can repeat those issues to the Ad Hoc.
As we discussed before, I'm not able to attend the Ad Hoc based on the time selected. I can try to call in from 6am to 7am on tomorrow's call.
Take care,
Ed...
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Friday, January 04, 2013 4:47 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Jorge,
I was under the impression that presentations on the topic of technical challenges associated with MMP implementation have been already presented and discussed in detail at the meetings. I am not sure how presenting the same material in a new form helps move us forward in any way.
Perhaps a list of questions on specific aspects of already presented technical challenges would be a better way to move forward? That would give time to prepare concise and comprehensive answers to the benefit of this ad-hoc. I fear that we if we start discussion on the phone, we'll get lost in details again.
Regards
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]<mailto:[mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]>
Sent: Friday, January 04, 2013 05:46
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] Materials from 1/2/13 MMP Ad-hoc and plan for 1/4/13 MMP Ad-hoc
Folks,
Thanks to those that were able to attend the meeting yesterday. We did not have any presentations on why MMP could not be implemented, so we took the opportunity to review the diagram outlining the use case we reviewed before the holidays (see below for reference). We had lots of discussion about this use case, but did not arrive to any specific conclusions. I attached a transcript of the discussion that Joe Solomon kindly recorded.
Given the discussion, and to help the continuation of this discussion, I expanded the use case into 4 slides, each progressively more complex. We will review these slides during our meeting tomorrow.
HOWEVER, our focus is on determining why and/or how is MMP not possible to implement. To that end, we are seeking presentations that would outline that specific topic. So, if there are any presentations that address why and/or how MMP can not be implemented we will give those presentations the priority.
Thanks!
Jorge
[cid:image001.jpg@01CDECF9.0BFEEB40]
________________________________
________________________________
<="" p="">
________________________________
<="" p="">
________________________________
<="" p="">
________________________________
<="" p="">
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
