Guys, sorry I can’t make Beijing.
1-
I don’t think we should be adding any additional error correction above and beyond what is already done by Ethernet, besides a frame loss is impossible
to recover from, only solution there is just to perhaps replay last frame or something along those lines?
2-
I don’t think end to end encryption is practical here.
Peter
From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Marek Hajduczenia
Sent: Tuesday, June 02, 2015 11:43 AM
To: Richard Maiden
Cc: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: FEC & Security
Richard,
FEC is fine, but (a) it eats into the link budget, (b) there has to be agreement as to what FEC is being used (ton of options are out there), and (c) lots of Ethernet PHYs already include FEC of their own, at which case adding it at encapsulation
process kind of makes no sense. FEC is closely tied with the specific link type, data rate, PHY technology, etc. and doing FEC E2E makes little sense, since Ethernet transport will guarantee delivery at 10^-12 BER.
As far as E2E encryption is concerned, there are already plenty of mechanisms in place that allow end points to authenticate and encrypt traffic. Do we need to come up with a new one or just allow these mechanism to just work?
On 2 June 2015 at 10:06, Richard Maiden <rmaiden@xxxxxxxxxx> wrote:
Jouni et al,
I apologize if these topics have been discussed previously.
An FEC option might be valuable in this standard. In almost every scenario I can think of, we can not afford to retransmit a packet. But I believe there would be some value in being able to recover data which has some corrupted payload content. FEC clearly
adds some overhead and frankly it may not work at all if the FCS dumps the packet. I would at least like to explore this option though.
A second query is in security. Do we have any provision to encrypt packets? I wonder if operators have some concerns around security? Maybe this is out of scope because higher layers can encompass this? Again, I'm interested to hear opinions.
Thanks,
Richard
-----Original Message-----
From: Jouni Korhonen [jouni.korhonen@xxxxxxxxxxxx]
Sent: Tuesday, May 05, 2015 03:19 PM Pacific Standard Time
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: IEEE1904.3 meeting in June
Folks,
The first week of June will arrive soon. So, few things to remind about the coming meeting:
1) we have a lot of time to spend on input papers and discussions.
Plan for that. White boarding and onsite documentation is
something we going to do as well - it has proven to be efficient.
2) The input papers must be submitted 10 days before the meeting.
That means Saturday, May 23 is the deadline. Input papers after
the deadline will be treated as late contributions i.e. do not
necessarily have an assigned agenda slot.
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M:
+1-408-391-7160
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments,
is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.
|