Re: [RE] Sariowan comments to DRAFT Objectives 09/30/2004
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 ------------------------
>