This is where sequence numbers provide simple ordering indicators with fewer computations/gates than are required to compare timestamps on a packet-by-packet basis.
--kb
===================================================================
From: Matsushima Satoru [mailto:satoru.matsushima@xxxxxxxxxxxxxxxx]
Sent: Wednesday, March 04, 2015 9:55 PM
To: Lars Ellegaard
Cc: Jouni Korhonen; Steinar Bjørnstad; AshwoodsmithPeter; Bross, Kevin; Raz Gabe; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: RoE header and mapper thoughts: sequence numbering..
Yes, it should be happened in transient situations.
But multi-path situation out there in stable situations that may cause reordering accidentally.
On Fri, Feb 27, 2015 at 9:59 PM, Lars Ellegaard <le@xxxxxxxxxxx> wrote:
Under stable conditions Ethernet switches/networks are not allowed to reorder packets.
It can occur in transient situations though
From:
stds-1904-3-tf@xxxxxxxx [mailto:stds-1904-3-tf@xxxxxxxx]
On Behalf Of Matsushima Satoru
Sent: 27 February 2015 09:27
To: Jouni Korhonen
Cc: Steinar Bjørnstad; AshwoodsmithPeter; Bross, Kevin; Raz Gabe;
STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: RoE header and mapper thoughts: sequence numbering..
I would imagine that when RoE packets are reordered caused by switches. I suppose BBU/RRH need to detect when it happened.
I suppose that current CPRI can't be tolerable because there's no packetalization now. So I think that RoE spec need
to take into account at least in the case of reorder detection.
Packet order assurance might be too much.
On Tue, Feb 24, 2015 at 4:45 PM, Jouni Korhonen <jouni.korhonen@xxxxxxxxxxxx> wrote:
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
|