Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Ed,
Inline, as well
Marek
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Monday, April 08, 2013 12:11 AM
To: Ed (Edward) Boyd; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Ed,
The lack of good practice is not an excuse for no such practice. I have an
issue with people showing up at the meeting and presenting material out of
the blue. First, we spent lots of time analyzing the material on the call,
that could be spent better discussing how the given presentation adds (or
not) to the work we have to do. Second, for the F2F meetings, we have
requirements to submit in advance to let people examine the materials in
advance and become prepared for discussion. It is just bad practice to
surprise people on the call, especially when we are expected to take
decisions. It has been preached over and over again that the foundation of
good progress is consensus building ? hard to do that when you see material
on the call for the first time.
[Ed] I?m not sure what to say. The ad hoc is a forum for discussion and I?m
open to people presenting new ideas at the last second. In all cases, the
decision will be made at a future meeting and people have an opportunity to
work on other proposals. If you want to make a procedural change for all of
the ad hocs, I recommend that we discuss and have a motion at the next
meeting.
My main goal for the proposal was not strictly adhering to motions but to
design something reliable. Something that has a standing chance to work
versus a bunch of motions passed without much foundation behind them. But
let?s deconstruct your email in more detail.
[Ed] The motions are solid and make sense. They were voted on by the group
with a strong consensus. I strong disagree with your statement above.
1) Your concern is that SFD should be part of the preamble and outside
of the FEC protection. However, that will make it vulnerable to bit errors
and potential frame misalignment. Knowing nothing of FEC so far (apart that
we will have FEC), there is no way to asses probability of such an event
actually taking place, and hence establishing whether you can do that or
not. I am not too attached to SFD at this position, though, so if it is
proven that SFD can be outside of the FEC protection, I am willing to accept
that. However, I need to see numbers to prove just that. Faith does not work
here.
I think the best way forward in here is to compare SFD location within or
outside the FEC protected area. If either one has accepted frame alignment
performance, then we can go either way. But choosing just based on faith is
not the right way to go.
[Ed] This doesn?t make sense to me. The Preamble with SFD allows you to
determine the start of the FEC block. You wouldn?t use the FEC to correct
bit errors in the preamble/SFD. We are requesting proposals for the
preamble. I don?t think that anyone is suggesting faith. We need a
preamble to find the PLC. Once we are locked on, the start of frame and FEC
block is known.
[mh0409] Let?s not get defensive. SFD denotes the start of frame delimiter,
and not necessarily start of the FEC codeword. You might have drawn the
equality sign between these two, without actually discussing it. It is just
step for here to say that we already agreed that FEC is frame-based ?
something that we did not discuss ? in my proposal, SFD is used as it is
used in Ethernet nowadays (to find start of incoming frame) once you remove
the FEC encoding from the incoming data stream. Please look in more detail
how it works in 10G-EPON ? SFD is not used there to find the start of the
FEC codeword ?
2) Configuration ID as you mentioned was not accepted at this time and
as such, I did not want to deal with it this time. I believe, though, it can
be dealt as a new TALV type without any problems. The structure is
extensible without any problems.
[Ed] I agree. It can be added.
[mh0409] Success !!! We agreed on one item ? let?s build from here J
3) FEC has been decided, indeed, though without any additional details
(what type, what payload rate etc. is largely missing). Until it is proven
that FEC alone can give you MTTFPA equal to or better than the age of the
Universe, I move you will need good CRC to prevent false packet acceptance
events, which can be disastrous for larger PLC frames carrying plenty of
register data. It is not a matter what occupies more or less bandwidth, but
a matter of statistics and bit error calculations. Before we take such a
decision, we need to (a) know details about the proposed FEC, and (b)
calculate MTTFPA for this link and (c) only then decide that we do not need
CRC. In the lack of evidence otherwise, I assume CRC is needed to guarantee
PLC reliability. I would further move that any proposals for FEC without bit
error calculations are not moving us in the right direction and choosing FEC
type based on bandwidth overhead is just the wrong way to go.
[Ed] I don?t disagree in general. We have proposals on FEC coming and I
think that we should consider CRC at the same time. The total overhead for
FEC+CRC should be evaluated for error correction/detection performance.
[mh0409] The point, I am trying to make here, is that when we examine the
FEC itself, we need to see specific parameters. Deciding just based on
bandwidth and resulting overhead is fine when you have two competing FEC
codes, with same bit error correcting and detecting properties, and we need
to decide between them. Picking between two different FEC codes just based
on bandwidth overhead is just wrong. We need to care about resilience of the
line first ? if it does not work reliably, nobody will care if we burn 10 or
50% of bandwidth on FEC overhead.
Also, CRC is not just a fancy addition to FEC ? it actually has function to
play by detecting up to a specific number of errors that were passed through
by FEC decoder and not detected. No FEC is perfect.
4) Yes, I was against repeating read/write requests as you presented it
and I still am. I was not against the concept in general ? please do not
misrepresent the position I presented at the last meeting. The format I
suggest has been already tested in OAM and works just great as long as FEC
and CRC do their job right. If you compare both proposals, you?ll see
differences in how addresses and read/write requests are lumped together (I
did not have time to draw hundreds of examples to show all possibilities).
Also, I would be very happy to drop it (read / write sequences) altogether
and just do things as OAM does ? one managed object at the time. That is the
most resilient approach and I would be happy if we agreed on this approach
[Ed] It would be great if you could highlight the differences on Wednesday.
It is not clear to me and it seems very different than the OAM format.
[mh0409] I will try to join the call on Wednesday, but I am already triple
booked at that time slot and I will have to look at the priorities and
perhaps jump between calls.
5) About the bandwidth usage itself: let?s not try to save bits on this
data channel in the name of saving bits, and for two reasons: (a) we added
FEC into it without any evidence that it will be really needed (I did not
hear your concerns about bandwidth waste then), (b) we have plenty of
bandwidth to go in this channel. We do not have to compete with user data
for access, and it is always available. Sending 1.1 Mbit/s worth of data
versus 1.0 Mbit/s of data and having extra reliability will pay off in the
longer run ? the PLC link has to be available (as you emphasized many times)
or there is no EPoC at all.
We are not bandwidth pressed in PLC and what I am suggesting does not
multiply bandwidth demand. I am truly baffled by this notion of concerns
about bandwidth usage when we do not know how much register data we will
have to transfer (our best estimates are nothing more than guesses, nobody
really knows this early in the process) and we have apparently agreed on
quite a generous PLC channel size, allowing us to establish quite a large
data pipe to CNUs. So I do not buy this argument
[Ed] I don?t agree with this paragraph. We selected a FEC so that we could
correct errors and provide burst error correction. A CRC would only detect
errors and we decided that we wanted to survive burst errors. We will
determine the cost (number of bits) versus performance (better SNR and burst
protection) when we select the FEC. Some think that we have enough
bandwidth and others believe that it is tight. I want to get the most out
of what we have. I think that it is enough bandwidth if we have an
efficient format. I don?t see any additional reliability in your format
proposal or any advantage. Please point out the advantages on Wednesday so
the bytes have value.
[mh0409] So in short, you disagree that we need reliable link operation.
Fine with me. I wonder then how we make PLC work.
In general, I am very much concerned with the fixed-size frame format that
seems to be behind your proposals so far. It seems to me ATM all over again,
with all of its pros and cons and I would like to understand what is so
attractive in a fixed-sized frame format, with bunch of noops in the middle
and how it saves us bandwidth on PLC link versus what I propose ?
[Ed] I don?t understand this paragraph. I have not proposed a fixed size
frame or anything like ATM. I?m not against a fixed size frame and I would
be happy to see it work since it would be simpler. The FEC block size
detection is much easier and we don?t need a post-amble. I don?t see
anything in your proposal that addresses this issue. The Duane/Hesham/Ed
proposal was a single slide on a variable instruction format to configure a
remote PHY. You argued that the variable size instruction was not reliable.
To address your issues with reliability, Qualcomm suggested a fixed format.
I don?t think that they suggested ATM.
[mh0409] Let me put into simpler terms, then. Can you think of any reason
why Ethernet does not use fixed-size frames? Why we do not send noop
commands over OAM link when there is nothing to send over the link?
Looking forward to more discussion on individual items.
Regards
Marek
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Monday, 08 April, 2013 1:51 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Marek,
Thanks for sending out the presentation in advance. On the earlier email,
you brought up the requirement to send presentations in advance of the ad
hoc call. While I agree that this is good practice, we have not required it
in the past. In fact, I don?t believe that any of the other presentations
were sent in advance. In most cases, I have asked people to send them out
after the call. We only have a week between calls and I don?t want to slow
down submissions by requiring the early submissions. The ad hoc call is an
opportunity to try ideas before the formal presentation at the main meeting.
I don?t think that the single slide proposal for an instruction format was a
surprise or inappropriate since we had asked for ideas for instruction
format on the previous call.
On your proposal, it isn?t fully consistent with the motions/straw polls
from the last meeting. We decided to lump the SFD into the preamble field
and passed that in a motion on the defined format. We are asking for
proposals for the format of the preamble that should include the SFD. I
think that the preamble isn?t QAM16 or covered by the FEC. It is minor
point but I think that we can drop the SFD from the payload. Unfortunately,
we didn?t have time for a motion but we had a straw poll to add the
configuration ID. You didn?t have it in your payload format. Again, it is
a minor point.
While we decided to include FEC, we didn?t decide on the need for an
additional CRC. I noticed that you included a CRC-32. I would like to see
justification for it when combined with the FEC. Are we better off with a
bigger FEC and not a CRC-32? A smaller FEC with a CRC-8/16/32? I?m not
sure. I know that others have more detailed presentations on this subject
in the works. I didn?t include the CRC-32 in the instruction format for
that reason.
On the Ad Hoc, you were against the proposed instruction format including an
address and repeating write data count. You argued that it was too
sensitive to errors that would come through the FEC/CRC. If I look at your
proposal, I see the same sensitivity. If you get a bit error in the type or
length, the frame can?t be decoded. As I mentioned on the call, I don?t
believe that there is any reason that an address or length is more critical
than write data. If a bit error is passed on almost any of the critical
write data, it would be a big problem. The wrong center frequency, upstream
PLC frequency, configuration ID, bit loading, exclusion band size, TDD/FDD
mode, etc would be a problem. With that said, I think that error
sensitivity is a topic related to the FEC/CRC decision and not the
instruction format. I would also note that only the configuration of the
upstream PLC frequency is required to be a write without verification. The
transmit power level and transmit offset will be checked by the CLT PHY.
Once the upstream PLC is up and running, the CLT PHY could decide to do
write/verify if was concerned about the configuration. Personally, I don?t
think that it is necessary and I would do unverified broadcast writes to
configure downstream channels.
The instruction format that you suggest has a much higher overhead. I
really don?t see the justification for the extra bytes. I also noticed that
you moved the PHY address into the instructions. I only had a single
address for each PLC frame since the read instructions should only trigger a
single PLC frame in response. Multiple reads could be confusing for the
upstream response.
Hope that is helpful and Thanks for the presentation.
Ed?
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Saturday, April 06, 2013 10:22 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Dear colleagues,
Attached please find an alternative (and more detailed) proposal for PLC
framing. I identified a number of areas that will need more discussion,
primarily associated with selection of PLC FEC and PLC CRC, PLC SFD
sequence, as well as decision on whether individual PLCS data frames are
fixed or variable size.
I also included proposal for the internal structure, addressing, and
flexible data access mechanism, allowing for OAM-like behavior over the PLC,
while allowing for direct addressing of individual registers (and bits
within the register) together with chained sequential read/write operations.
I would like to ask for feedback before the call so that the proposal can be
further polished and then hopefully discussed in more detail on the call
next week
Please note that I do not discuss any PLC PMD related topics, including
mapping into carriers, etc. I believe these should be discussed in parallel,
to simplify detection of PLC SFD. For example, PLC SFD should start always
in a known subcarrier relative to the start of the PLC channel, so that the
data decoder can optimize the search mechanism to limit acquisition time. It
is just a thought, but I believe we should not be discussing digital PLC and
OFDM PLC parts separately.
regards
Marek Hajduczenia, PhD
ZTE Portugal
Standard Development and Industry Relations
Edifício Amoreiras Plaza,
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A,
1070-374 Lisbon, Portugal
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, 03 April, 2013 11:26 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
Ed, et al.,
Since it is not recorded in the minutes, but it was brought up on the call,
I feel it is important enough to bring it up again. I would really
appreciate if there were no more surprise presentations brought forward for
discussion. It is hard enough to have to examine proposals on the fly on a
small screen, written in minuscule font, but it is also wasteful in terms of
time to have to formulate opinions on complex topics like PLC, its framing
etc., on the fly. I think we would be better served being able to preview
the presentations before the meeting.
With that said, I plan to develop an alternative framing proposal for the
next call and distribute the draft presentation by next Monday. I would
encourage everybody to follow similar approach and give other participants
at least one working day to go through the materials ahead of the call.
Regards
Marek Hajduczenia, PhD
ZTE Portugal
Standard Development and Industry Relations
Edifício Amoreiras Plaza,
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A,
1070-374 Lisbon, Portugal
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Wednesday, 03 April, 2013 9:31 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-EPOC] PHY Link Ad Hoc Notes
All,
I have attached the slides from today?s call. Here is the a summary of the
call.
1) Editor for PLC
a. Most of PLC will be in the PCS and handled by Marek (digital and
framing)
b. Saif/Joe will handle the rest of it in the PMA.
2) Huawei and Broadcom presented a Downstream Command Format proposal
(at the end of the slides)
a. Efficient method to set blocks of configuration registers in the
PHY.
b. Marek has concerns about errors in the PLC and impact to
incrementing address.
c. Do we need to have FEC and CRC in PLC? Do we need to worry about
undetected errors multiplying?
d. Qualcomm wants to consider no address and a fixed register set for
PLC.
3) Baseline Proposal Review (slides 34-35)
a. One or more PLCs in the downstream is not clear.
b. 1MHz granularity for setting PLC location
c. General support for 6MHz min size of EPoC spectrum around PLC.
Question on whether it could be 24MHz?
d. PLC hunting is a vendor specific algorithm but MDIO controls needs
to be define. Bill K will make presentation.
e. 8 or 16 carriers for PLC are adjacent.
Thanks,
Ed?
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: cid:image009.jpg@01CD505E.7B800DB0
Edward Boyd | Sr Technical Director
Broadcom Corporation | (O) 707-792-9008 | (M) 707-478-1146
<http://www.linkedin.com/company/broadcom> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image005 <http://twitter.com/#!/broadcom>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image002
<https://www.facebook.com/Broadcom> Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: image003
<https://plus.google.com/109188783526874806673/posts#109188783526874806673/p
osts> Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image004
<https://www.youtube.com/user/BroadcomCorporation> Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: image006 <http://blog.broadcom.com/> Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: image008 <http://broadcom.com/>
Description: Description: Description: Description: Description:
Description: Description: Description: Description: Description:
Description: Description: Description: Description: image007
_____
<="" 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
