Hello all,If the resulting flow will be CBR only, also when compressed and sending packets also in e.g. silent periods, there will not be possible to achieve any statistical multiplexing gain in the switches. I.e. multiplexing in lower quality packets into the ROE flow e.g. during silent periods, using FUSION or pre-emption. I think this can be seen as a clear benefit for carriers that want a high utilization degree of their infrastructure. However, benefits of variable size packets is not clear for me, any comments here?
Regarding packet sizes I think it is important to be aware that in the case of mixed traffic using FUSION or Pre-emption (for avoiding/minimizing packet jitter) for mixing lower priority traffic into an ROE stream, blocking and total throughput will strongly depend on the size of the packets. If you put e.g. a CBR 2.5G ROE stream into a 10GE stream:
1) Assuming ROE packets of 64 Byte length. Since the rate is CBR and 1/4, the gaps between the packets will be 3 X 64 B = 192 B. This is much shorter than the Ethernet MTU and will result in total blocking of lower priority traffic. 2) Assuming ROE packets of 550 Byte length. The gaps will be 3 X 550B = 1650 B. This is longer than the standard Ethernet MTU including any overhead added by VLAN tagging or e.g. PBB. Insertion of lower priority packets in between the higher priority ROE packets is then possible and capacity will then be available also for the lower priority traffic.
Hence when mixing traffic using FUSION or pre-emption, the longer the packets, the larger the gap between the packets, the higher the throughput for the lower priority traffic.
On the other hand, longer packets causes higher serialization delay. For switches and multiplexers NOT using timing-critical mechanisms like FUSION, preemption, time-triggered Ethernet, Scheduled Ethernet or similar, multiplexing any low-priority traffic into an higher priority ROE stream will cause packet-jitter in the ROE stream and the length of the lower priority packets will influence the amount of packet-jitter. The longer the low-priority packets, the higher the packet-jitter.
In pure ROE stream environments, packet-jitter will be induced if multiplexing several ROE streams into a larger capacity ROE stream (e.g. 2.5G into 10G). The amount of packet-jitter will then depend directly on the length of the ROE packets. The longer the ROE packets, the higher the packet-jitter.
I.e. Several trade-offs here. Perhaps 550 Byte packets may be a reasonable compromise?
Best regards
Steinar
Hi Jouni , Regarding packet/frame sizes (including both header and payload?), what are your thinking, variable, or fixed? If fixed, should it be a single fixed size for all cpri rates, or one per cpri rate? Any suggestion on what the packet/frame sizes might be ? Note that packet/frame size may have impact on delay and jitter. Cheers, Tao Good discussion. Regarding structure aware are you assuming that we would have variable packet sizes or variable rate for a given antenna flow? That is not something I had in mind.. I view the RoE sample flow as a CBR flow even when compression were used. - Jouni Here is how I see it ( based on my current understanding of the various bits and pieces ):
Structure agnostic requires a sequence number so that in the event of loss a dummy frame can be inserted. Strucutre agnostic requires SynchEth (or other) to .002ppm frequency precision (time of day not required). The output frames have to be generated at exactly their input frequency. Some amount of delay has to be artificially introduced to absorb jitter to ensure the output buffer always has packets to play out. early crude simulations indicate that say 500ns-1us is likely required and that pre-emption is required to be supported on all intermediate switches to keep the jitter in these bounds (card to card fabric jitter will make this worse and was not simulated). An interesting issue is how to 'learn' the correct amount of buffering. You want enough that new connections being added do not cause more buffer to be required.. i.e. has to be a worst case for the lifetime of the deployment so likely this has to be configured not learned. So here are two configured parameters already, output_rate and buffer_size.
Structure aware is a totally different animal. If there is any kind of compression or variable rate then time stamping is required and in this case SynchEth is not sufficient and time of day synch to single digit ns is required i.e. 1588++. Even small changes in transmit/receiver fiber lengths will effect the time synch and very precise one way measures of the fiber lengths will be required to get the proper clock offsets. I.e. 1/2 RTD won't cut it. Its possible even temperature changes will effect the time offsets enough to be a concern and possibly have to be tracked and corrected [Google CERN "White Rabbit Project"] showing temperature causing 2ns delay difference. Of course complete out of band time synch is possible for example GPS can yield +/- 10ns [Google "Common View GPS Time Transfer"] but GPS is not a good indoor solution for obvious reasons and we are trying to get away from it outdoor for expense and dependency reasons (it can be degraded at the push of a button).
Cheers,
Peter
________________________________________
From: Aleksandra Checko [amch@xxxxxxxxxxxxxx]
Sent: Tuesday, February 24, 2015 5:38 AM
To: Bross, Kevin; Jouni Korhonen; Steinar Bjørnstad; AshwoodsmithPeter
Cc: Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
Dear All,
As synchronization is seen as one of the main challenges for IQ over Ethernet transport I think it is important to identify possible synchronization solutions and make a room to accommodate them. It could be a flexible arrangement e.g. setting a flag whether the header will include a timestamp.
Otherwise the protocol may need additional solutions to be used.
Best Regards,
Aleksandra Checko
Industrial PhD Student
Networks Technology and Service Platforms
DTU Fotonik
Technical University of Denmark
Department of Photonics Engineering
Mobile +45 50395225
________________________________________
From: stds-1904-3-tf@xxxxxxxx [stds-1904-3-tf@xxxxxxxx] on behalf of Bross, Kevin [kevin.bross@xxxxxxxxx]
Sent: 24 February 2015 14:21
To: Jouni Korhonen; Steinar Bjørnstad; AshwoodsmithPeter
Cc: Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
Jouni,
I would encourage us to separate the encapsulation method from the node synchronization requirement. If both sides are somehow time-synchronized to atomic time (TAI), then we can minimize the synchronization needs for the protocol.
There are many different ways of getting each end node synchronized to TAI, including GPS and 1588. I think we should identify the expectations for how synchronized each side is to TAI, but that should be external to this protocol.
--kb
===================================================================
-----Original Message-----
From: Jouni Korhonen [mailto:jouni.korhonen@xxxxxxxxxxxx]
Sent: Monday, February 23, 2015 11:46 PM
To: Steinar Bjørnstad; AshwoodsmithPeter
Cc: Bross, Kevin; Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: RoE header and mapper thoughts: sequence numbering..
If your end points are already in "perfect" sync I do not think you need a timestamp for de-jitter - because you would send stuff in a TDM fashion anyway (at the end points). I can be convinced otherwise, though. On the other hand I could use timestamp for other purposes like measuring the end-to-end link propagation delay. The issue with timestamps is the size.. a meaningful timestamp takes quite a few bits (32 bits at nsec accuracy overflows in ~4 secs etc).
- Jouni
> -----Original Message-----
> From: Steinar Bjørnstad [mailto:Steinar.Bjornstad@xxxxxxxxxxxxxxx]
> Sent: Monday, February 23, 2015 11:22 PM
> To: AshwoodsmithPeter
> Cc: Bross, Kevin; Raz Gabe; Jouni Korhonen; STDS-1904-3-
> TF@xxxxxxxxxxxxxxxxx
> Subject: Re: RoE header and mapper thoughts: sequence numbering..
>
> Hello,
> Probably both a sequence number and time-stamping is required.
> Time-stamping is required for de-jittering if there are cases where
> the data rate varies (e.g. compression).
> Sequence numbering is required for detecting packet loss (packets out
> of order can be found from the time-stamping). As far as I have
> understood, CPRI is highly dependent on a low bit error rate.
> Any comments?
>
> Best regards
>
> Steinar
>
>
> 23. feb. 2015 kl. 16:33 skrev AshwoodsmithPeter
> <Peter.AshwoodSmith@xxxxxxxxxx>:
>
> > If you know exact frame generation rate and frame sizes then yes you
> > can use
> frame sequence number and ultra precise synch ethernet to generate
> them at the exact same rate at the egress but if compression is
> varying then you need absolute time and a time stamp.
> >
> > Peter
> >
> > ________________________________________
> > From: Bross, Kevin [kevin.bross@xxxxxxxxx]
> > Sent: Monday, February 23, 2015 7:17 AM
> > To: AshwoodsmithPeter; Raz Gabe; Jouni Korhonen; STDS-1904-3-
> TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > Alternatively, can a sequence number be a de-facto timestamp? If
> > both (all?)
> sides know how to correlate one sequence number to a timestamp, can
> subsequent timestamps at this deterministic rate serve as an entry
> from which the timestamp can be re-created?
> >
> > --kb
> >
> >
> =================================================================
> ==
> >
> >
> > -----Original Message-----
> > From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On
> > Behalf Of
> AshwoodsmithPeter
> > Sent: Monday, February 23, 2015 7:10 AM
> > To: Raz Gabe; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > Keep in mind that time stamping is going to be required to
> > de-jitter. So
> anything that can be done with a time-stamp should not be replicated
> by a sequence number.
> >
> > Peter
> >
> >
> >
> > ________________________________________
> > From: stds-1904-3-tf@xxxxxxxx [stds-1904-3-tf@xxxxxxxx] on behalf of
> > Raz
> Gabe [Raz.Gabe@xxxxxxxx]
> > Sent: Saturday, February 21, 2015 9:14 PM
> > To: Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RE: RoE header and mapper thoughts: sequence numbering..
> >
> > HI Jouni,
> > A sequence number is one the things that is missing in L2 protocol
> > (which been
> exists in higher layers...), I think that it is needed here .
> > About its size, at that step, I think that 20bits are better than
> > 16bits, based on
> your below arguments.
> >
> > Rgrds
> > --Raz
> >
> > -----Original Message-----
> > From: stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx] On
> > Behalf Of
> Jouni Korhonen
> > Sent: Saturday, February 21, 2015 12:04 AM
> > To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
> > Subject: RoE header and mapper thoughts: sequence numbering..
> >
> > Folks,
> >
> > I have been thinking about the RoE header and a need for sequence
> > number in
> it. There would be two uses for it, at least initially. First, we need
> that in the mapper to regenerate the CPRI HFN and BFN fields. Second,
> it would allow us to detect possible lost packet. Maybe there could be a case as well for reordering?
> Anyway, in the RoE example I had I reserved 16 bits for the sequence
> number space. That is enough to number >10ms worth of CPRI BFs and HFs
> for the mapper purposes. However, 16 bits is not enough to explicitly
> transport CPRI HFN and BFN information (that's 20bits worth data).
> Anyway, generating those missing 4 bits is not imho a big deal.. we
> already do that routinely with ESP etc (64bits extended sequence
> number but only transport low order 32bits). Again I am assuming the
> sequence number space is unique between two endpoints (whether mechanism we use to determine endpoints).
> >
> > Any thoughts?
> >
> > - Jouni
> >
> > --
> > Jouni Korhonen, Ph.D, Associate Technical Director CTO Office,
> > Networking,
> Broadcom Corporation
> > O: +1-408-922-8135, M: +1-408-391-7160
|