Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[EFM] RE: [EFM-P2MP] MPCP: Report message



Hi David,
 
Re: item 1...  It makes me a little nervous  when you say that the EFM transceiver costs the same as the FSAN compliant one...  isn't that exactly what we're trying to avoid?   Economics is one of EPON's claims to fame. 
 
I hope we can learn from FSAN in that we should avoid putting aggressive requirements on the optics and end up with a costly solution that no one can afford.  We should be able to come up with a simple solution that works effectively with inexpensive optics.
 
Thanks,
 
Vincent
 
 
-----Original Message-----
From: David Levi [mailto:david@broadlight.com]
Sent: Monday, February 11, 2002 3:18 AM
To: vincent.bemmel@alloptic.com; stds-802-3-efm-p2mp@ieee.org; stds-802-3-efm@ieee.org
Subject: RE: [EFM-P2MP] MPCP: Report message

 

 

All,

 

I just want to clear things concerning to Burst mode transceivers.

 

1. FSAN compliant 1.25Gbps D/S and U/S transceiver with 3 or 12 bytes  (several nsec) overhead cost the same as transceiver with (10 usec? overhead or 1 usec). This is because Laser Driver ASIC that can handle short turn on delay cost the same as continues Laser Driver (LD), where probably the same LD that support continues mode will support burst mode with several nsec turn on delay.

 

2. FSAN compliant transceiver cost the same as 802.3ah transceiver. The transceiver costs lies on the optic (BIDI, Laser Diode, PIN ), and definitely not on the Laser Driver ASIC, where 802.3ah transceiver uses the same optical components (two or three port bidi)as FSAN transceiver.

 

3. 8 bytes overhead, which represents turn on delay of several nsecs provides almost 150Mbps bandwidth more over the link than 1usec turn on delay. Turn on /off of 1usec is 156byets times 64 for TDM voice per ONU resulting in 10000 bytes + 64* 156 for DBA + 70 ( for 1500buts per slot)*156 = 31000 bytes. 31000 bytes in 1 msec is around 200Mbps. 8 OH bytes only eat 64Mbps.

 

 

The price for end to end 8 bytes OH cost the same as 156 bytes OH.

 

 

 

Regards

 

 

David

 

-----Original Message-----

From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org]On Behalf Of vincent.bemmel@alloptic.com

Sent: Friday, February 08, 2002 2:20 AM

To: stds-802-3-efm-p2mp@ieee.org

Subject: RE: [EFM-P2MP] MPCP: Report message

 

 

 

All,

 

I'd like to follow up on some of the discussions re: scheduling and REPORTs.

 

So far we have identified two approaches to assigning timeslots: 

 

1. Static timeslot assignments -- no REPORTs are generated by ONUs for BW

management.

- The OLT sets up a  static timeslot scheduling plan, and generates GATEs

for each ONU

Two options:

- Each ONU receives a grant for a fixed timeslot at a time, or

- Each ONU recieves a grant for multiple fixed timeslots for a period of

time (multi-cycle grant)

 

A TDM scheme is best implemented through this approach.   For jitter/delay

sensitive TDM traffic, some of us strongly believe multi-cycle granting is

the best way to go.

 

2. Dynamic timeslot assignments --  REPORTs may be used to provide the DBA

feedback loop. 

- The OLT now dynamically schedules timeslots, and generates GATEs for each

ONU accordingly. 

- Each ONU receives a grant for a fixed timeslot at a time.  It may

optionally communicate it's BW needs to the OLT via REPORTs.

 

Notice that DBA designs are proprietary, and may desire a wide range of

parameters in the feedback loop.   Fortunately this is (and should remain)

out of our scope.  However, even in its simplest form, the upstream BW

efficiency is negatively  affected in order to support REPORTs upstream.

Here is an example (assuming 64-Byte REPORTs).

 

      In order to have ONUs responsive with a granularity of 1ms, the

overhead for a 64-split is 64x64B/(0.001s) = 32.8 Mbps + timeslot framing

overhead.   As Bob pointed out, the latter can easily be in the order of

multiple usecs. 

      E.g., 3 usec = 600% overhead on a 64Byte (0.512 usec) frame.

      So *very* conservatively we can easily eat up  > 20% of the upstream

BW just to make DBA work. 

      (That would be > 60% BW overhead if the framing overhead was 10

usec). 

      Note: numbers may look slightly better (statistically) with upstream

piggybacking of REPORTs in the case of higher upstream traffic loads.

 

The tendency will be to reduce these numbers by putting tighter constraints

on the lasers and clock recovery mechanisms a la FSAN.  This equates to more

expensive components.

 

Now consider a solution, based on DBA, that includes TDM services... The ONU

now has  to do  the following:

- wait for a GATE poll

- send a REPORT (requesting TDM BW)

- wait for a GATE (w/details of Timeslot to transmit TDM data)

- wait for actual time to send its data...

... and repeat this for EVERY TIMESLOT.

The actual overhead needed to manage this mechanism is significant to say

the least.

 

Fortunately, today we are faced with a 'glut' of bandwidth and the

need/requirement for dynamic bandwidth provisioning is unnecessary.

Furthermore, burdening the upstream bandwidth with a constant request for

bandwidth is not warranted.

 

We have the opportunity to introduce a more cost effective approach.  That

translates to a solution that will win acceptance in the marketplace, and

that is good for all of us. 

 

Static mapping of upstream bandwidth is sufficient, and TDM traffic can be

transported expediently.  It means a less complex OLT and ONU. 

 

The nature of the optics will limit the number of ONUs to 64.  Once again,

this isn't a 2000-modem DOCSIS system,  nor does it exhibit the dynamics of

a cellular phone system, so the standard Aloha-based algorithms are not

required.   This is not to say that they should be dismissed,  but it is

important that multiple methods of bandwidth scheduling should be allowed in

the protocol. 

 

Vincent

 

 

-----Original Message-----

From: Horne, David M [mailto:david.m.horne@intel.com]

Sent: Wednesday, February 06, 2002 7:55 PM

To: 'vincent.bemmel@alloptic.com'; dolors@broadcom.com;

ariel.maislos@passave.com

Cc: yoshi@ansl.ntt.co.jp; onn.haran@passave.com;

stds-802-3-efm-p2mp@ieee.org

Subject: RE: [EFM-P2MP] MPCP: Report message

 

 

re: Especially if the intention is to have the OLT be responsive to ONU

requests

in near real-time,...

 

Can you define "near real time?" Could be 6000-7000 timestamps elapse just

from transit delay. How would we put a bound on processing and scheduling

delay at OLT if we are not specifying scheduling algorithm?

 

There are many ways to address the provision of upstream bandwidth requests,

but no one wants any level of complexity or contention slots. That pretty

much means waste is a given. This isn't necessarily a bad thing if it saves

complexity and doesn't encroach on needed bandwidth. Have to show

quantitatively that the waste is too excessive. It will be hard to do that,

given that unused reservations don't follow any regular pattern.  

--Dave

 

-----Original Message-----

From: Dolors Sala [mailto:dolors@broadcom.com]

Sent: Wednesday, February 06, 2002 2:48 PM

To: ariel.maislos@passave.com

Cc: Osamu Yoshihara; onn.haran@passave.com; Stds-802-3-Efm-P2mp

Subject: Re: [EFM-P2MP] MPCP: Report message

 

 

 

Ariel,

 

We have several requests on the table. Vincent is really interested in

supporting well TDM-like services. Osamu is concerned on TCP data

transmission.

My argument is that if you have to support both in the same system

(triple-play

is a requirement by some service providers) the MAC client will be using

more

than one priority queue. In this case, Osamu's dual request parameter is not

enough.

 

If we assume that more than one priority queue is used, trying to avoid

fragmentation in a grant only makes sense if the actual frames that

generated

the request are the ones transmitted in the corresponding grant. Otherwise,

there is a size mismatch. And the indication of a max and min size does not

help

on it.

 

I am not sure we want to go to the detail of trying to avoid this

fragmentation.

But if we want to enable this capability, I think we should specify a

general

approach. It is equally painful to send an additional parameter upstream

than

downstream.

 

Note that sending several consecutive requests would allow to indicate frame

boundaries to the OLT without additional parameters. If we are concerned on

a

single queue case, then we do not need the parameter.

 

In summary, when the discussion relates to the scheduling algorithm there

are a

lot of things that can be done. Passing the appropriate information helps

tuning

particular implementations to one or other application. The only information

missing on the system is the priority in the grant. We have discussed this

and

we had not decided about it yet. We should probably make the decision

together

with this request. I think this parameter is a more general solution for

Osamu's

request. But I may be interpreting wrong what he is suggesting. Osamu,

please

comment.

 

We can discuss more during the call,

 

Dolors

 

 

 

 

 

Ariel Maislos wrote:

 

> Dolors,

>

> I do not think the concept of per-priority granting is appropriate. It

looks

> too much like DOCSIS service-flows to me.

>

> What you are suggesting makes priorities meaningless. By definition,

> granting priority 4 while there is a pending packet of priority 1, (1 is

> higher than 4) will transmit the packet having priority 1. Behaving

> otherwise makes priorities meaningless.

> Operating otherwise looks like DOCSIS service-flows, and not like 802.1p.

>

> The original presentation by Yoshihara-san tried to minimize fragmentation

> by granting exactly up to a FRAME BOUNDARY. This was suggested in the

> context of a flat FIFO queue.

> I would suggest the appropriate way to do this is by using an additional

> field in the report (optional of course) that will give the number of

bytes

> at a frame boundary waiting in the queue. This number will be lower than a

> set threshold, while the threshold can be set statically or dynamically.

>

> Ariel

>

> -----Original Message-----

> From: owner-stds-802-3-efm-p2mp@majordomo.ieee.org

> [mailto:owner-stds-802-3-efm-p2mp@majordomo.ieee.org] On Behalf Of Dolors

> Sala

> Sent: Sunday, February 03, 2002 5:53 PM

> To: Osamu Yoshihara

> Cc: onn.haran@passave.com; Stds-802-3-Efm-P2mp

> Subject: Re: [EFM-P2MP] MPCP: Report message

>

> Osamu,

>

> I think  you are bringing up a good point here. I think we can

> consolidate

> the two request types by modifying the interpretation of the request

> size.

>

> If I interpret you correctly, you are looking for a requesting mechanism

> that exactly matches with the frames to be sent (and avoid left over

> space in the grant). Since the ONU is the one sending the request and

> knowing about the size of the packets in the queue, it is the one that

> can compute exactly how much bandwidth is needed to send a certain set

> of packets. Therefore I think we can achieve what you want by saying

> that

> "the request indicates the amount of bandwidth (bytes) needed for a

> given priority". The ONU can compute the number by calculating the

> amount of bytes needed by adding for each packet all the

> bandwidth components (the size of the packet,  plus the interframe gap,

> plus the phy overhead). This way, the request exactly corresponds to

> the grant size needed to transmit the packets the ONU had selected

> to request for bandwidth.

>

> The buffer threshold in your presentation could be an ONU policy

> parameter. The ONU will decide how many packets to consider in a

> particular request based on a policy and a (potential) maximum

> request size (due to limit of the field size).

>

> I think to achieve what you want, you also need the OLT to specify the

> priority of the grant. And this information should be sent up to the MAC

> client at the ONU when the grant arrives. Right now we had provision

> passing grant information from the MAC-control to the MAC client and

> this would be an example.

>

> Would this do it?

>

> Dolors

>

> Osamu Yoshihara wrote:

>

> > Onn,

> >

> > Thank you for the summary.

> > I have one suggestion about REPORT content.

> >

> > I'd like to allow ONU to send 2 or more REQUESTs(number of bytes

> > requested for queue) per priority queue in a REPORT frame.

> > For example, "minimum number of bytes requested for queue #n" and

> > "maximum number of bytes requested for queue #n".

> >

> > I made a presentation about this suggestion in Austin.

> >

>

(http://grouper.ieee.org/groups/802/3/efm/public/nov01/yoshihara_1_1101.pdf)

> >

> > We as NTT intend to use EPON system for TCP/IP data traffic mainly.

> > To yield high TCP throughput, low upstream delay is necessary, and

> > to keep upstream delay low, short grant cycle should be required.

> > When only "size of total buffered frames" is conveyed per priority

queue,

> > OLT can't always allocate exact requested bytes. It's because granted

> bandwidth

> > per ONU becomes smaller when many ONUs transmit REQUESTs.

> > In this case bandwidth can't be allocated efficiently because bandwidth

> > wastage per ONU (maximum wastage per ONU is maximum MAC frame size)

isn't

> > negligible when grant cycle is short.

> > To address this issue, we suggested to convey "frame boundary

information"

> > for high priority traffic in addition to "size of total buffered

frames".

> >

> > OLT receives two types of request information, and chooses appropriate

one

> > as the granted bandwidth by a proprietary DBA algorithm. For example,

when

> > many ONUs transmit REQUESTs, "minimum number of bytes requested

> > for queue" is chosen as "frame boundary information". In this case

> > there are no bandwidth wastage except guardband because the next ONU can

> > transmit data frames just after the previous ONU finishes transmitting.

> >

> > To send multiple REQUESTs ,"size of total buffered frames" and

> > "frame boundary information" ,is quite useful to yield high TCP

throughput

> > ,low upstream delay and high bandwidth efficiency for high priority

> traffic.

> > And it is also useful for TDM traffic because low delay can be achieved.

> > (page 17 of

>

http://grouper.ieee.org/groups/802/3/efm/public/sep01/yoshihara_1_0901.pdf)

> >

> > Osamu Yoshihara

> > NTT

> >

> > 2002.01.31 Onn Haran wrote:

> > >The following presentation summarizes report message suggestion.

> > >

> > >Onn.