Re: [RE] Sariowan comments to DRAFT Objectives 09/30/2004
That *might* work for single bridges, but not for cascaded bridges ... and
that is one of the objectives.
We need a scalable solution ... and any kind of pure scheduling solution has
conflicts with normal "best effort" traffic and with cascaded bridges.
On 10/1/04 12:29 PM, "Henry Sariowan" <Henry.Sariowan@PATH1.COM> wrote:
> I agree that the source will have queueing its because isochronous
> packets can only only be sent at regular intervals.
> However, with each sender has a network-wide clock reference, their
> transmission schedules from multiple senders can be coordinated such
> that there is available slot on the output ports; i.e. congestion free
> in the switch for the isochronous traffic.
>
> Henry
>
> -----Original Message-----
> From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
> On Behalf Of Michael Johas Teener
> Sent: Thursday, September 30, 2004 6:06 PM
> To: STDS-802-3-RE@listserv.ieee.org
> Subject: Re: [RE] Sariowan comments to DRAFT Objectives 09/30/2004
>
> 1) The source has queuing requirements (after all, it may already be
> transmitting another packet). Any intervening bridges will add queuing
> since the appropriate output port(s) may be busy. There will be queuing
> and delays.
>
> 2) *and* we forgot to add one more line in the objectives: Support for
> multiple bridges in the network (max hop count TBD, but probably limited
> to whatever gives us our worst case network delay time of 10ms) ... if
> we assume 250us per bridge, that still allows 40 hops ... probably good
> enough even for Bill Gates' house.
>
> On 9/30/04 7:51 PM, "Henry Sariowan" <Henry.Sariowan@PATH1.COM> wrote:
>
>> With time-slotting overlay over Ethernet and pre-determined schedules
>> for all synchronous traffic, the system/protocol should be designed
>> such that isochronous packets have a maximum of 1 packet
>> delay/queueing per hop. In fact, if "cut-through" switching is
>> implemented, the delay/queuing will just be size of the Ether header.
>>
>> Henry
>>
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]
>> On Behalf Of Michael D. Johas Teener
>> Sent: Thursday, September 30, 2004 4:19 PM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Sariowan comments to DRAFT Objectives 09/30/2004
>>
>> 1) What do you mean by "zero queuing for isochronous traffic"? All
>> traffic is queued in some way ... perhaps you mean "deterministic and
>> minimal queuing for isochronous traffic"?
>> 2) Interesting question, but I think the attempt will be made to
>> provide the facilities so Ethernet can provide a backbone for
>> 802.11e-enabled A/Ps that preserves all the QoS services.
>>
>>
>> On 9/30/04 6:07 PM, "Henry Sariowan" <Henry.Sariowan@PATH1.COM> wrote:
>>
>>> Looks good.
>>>
>>> Additional comment/question:
>>> 1. Consider adding: "Zero queueing for isochronous traffic"
>>> 2. What is it meant by "isochronous bridging to 802.11"?
>>>
>>> Henry Sariowan
>>> Path 1 Network Tech.
>>>
>>
>> --
>> ----------------------------------------------------------------
>> Michael D. Johas Teener - Mike@plumblinks.com PGP ID 0x3179D202
>> Plumblinks, 23 Acacia Way, Santa Cruz, CA 95062-1313
>> +1-831-247-9666, fax +1-831-480-5845
>> ------------------- www.plumblinks.com ------------------------
>>
>
--
----------------------------------------------------------------
Michael D. Johas Teener - Mike@plumblinks.com PGP ID 0x3179D202
Plumblinks, 23 Acacia Way, Santa Cruz, CA 95062-1313
+1-831-247-9666, fax +1-831-480-5845
------------------- www.plumblinks.com ------------------------