RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
Peter,
Thanks for converting this from a "they told us" political
to a more more quantifiable technical argument.
I'm really don't understand what is the difference between
a client initiated control function and a client-initiated
"normal" data transfer.
If you could help clarify the difference, that would be
most appreciated. My current concerns are that:
1) If they are the same, why are we arguing?
2) If they are different, what are the "gotchas".
Suppose, for example, that the answer was (2), and the control
passed through different queues, then there could be significant
concers related to maintaining expected ordering or performance.
Of course, the higher level question I still haven't
understood is: why the resistance to delivering to the client
its own self-addressed unicast frames? If client sent them to itself,
it clearly wanted them back. It it didn't want to send them,
they could have been easily prefiltered at the client.
DVJ
David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor, Bldg #3
3901 North First Street
San Jose, CA 95134-1599
Work: +1.408.545.7560
Cell: +1.650.954.6906
Fax: +1.408.456.1962
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
> -----Original Message-----
> From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
> Sent: Thursday, May 16, 2002 8:44 AM
> To: 'Castellano, Robert'; Peter Jones; David James (E-mail)
> Cc: John Lemon; Steven Wood (E-mail)
> Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
>
>
> Robert,
>
> My comment still stands.
>
> A packet flush is a control function, not a normal data transfer. The
> decision to do a packet flush is done by the bridge control
> entity, not as a
> side effect of sending some packet to yourself in the normal
> course of data
> transfer.
>
> Another example of this would be measuring the RTT (another use
> for sending
> a packet to yourself).
>
> I haven't yet seen anyone demonstrate a real example of a "normal data
> transfer" where we want the MAC to reflect (either locally or by going
> around the ring) a packet back to the originating client.
>
> Regards
> Peter
>
> -----Original Message-----
> From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
> Sent: Thursday, May 16, 2002 6:10 AM
> To: 'Peter Jones'; Castellano, Robert; David James (E-mail)
> Cc: John Lemon; Steven Wood (E-mail)
> Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
>
>
> Peter,
>
> I'm not sure there are any practical reasons for reflecting
> a packet in the MAC without placing on the media. The BAH has
> definitely determined an application where a station may need
> to be able to insert a packet on the media, and receive back
> to itself. This scenario is a packet flush. A packet flush
> may be needed to avoid packet duplication / misordering issues.
> While we have not yet concluded the ability to flush a packet
> is absolutely required, it is under consideration. If it is
> required, we will need the appropriate support by the MAC.
> This capability is unique to 802.17 media. The nature of
> other 802 MACs did not have this sort of issue.
>
>
> thanks,
>
> robert
>
>
>
> -----Original Message-----
> From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
> Sent: Thursday, May 16, 2002 12:50 AM
> To: 'Castellano, Robert'; David James (E-mail)
> Cc: John Lemon; Peter Jones; Steven Wood (E-mail)
> Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
>
>
> David & Robert,
>
> If you have a look at the attached emails checking the comments from Mick
> Seaman, Steve Haddock & Pat Thaler, the common thread is to avoid the MAC
> clients talking to themselves via the MAC.
>
> My proposal to 802.1 got the following response from Tony Jeffree
>
> Peter -
>
> As you say, no-one has objected, so it looks like this is a
> reasonable
> course of action.
>
> Regards,
> Tony
>
> Since MAC clients don't normally talk to themselves via the MAC, I propose
> that we build our MAC to handle the normal case, and support functions to
> determine delay around the ring (also supports suspending data
> transmission
> for a RTT) using a control interface, not the normal MAC client interface.
> This would use an interface similar to that proposed for the echo
> request/reply functions.
>
> We should remember that we need a appropriate level of software (aka a
> driver) in between the MAC hardware and the MAC clients to support a multi
> client solution where we have both bridge and station MAC clients active
> simultaneously. In the case all transmission from the local
> station have to
> be presented to the bridge entity, and the bridge entity also has
> to be able
> to pass frames to the local station entity.
>
> I also don't see why the reception rules would be different
> between unicast
> and multicast (group address or broadcast) transmissions. Either
> the MAC is
> reflective (all frames transmitted are passed back the local clients(s) if
> the DA is local, multicast or broadcast), or it isn't. Even if the MAC is
> reflective as a matter of course, I would argue that it should
> locally turn
> the frames around, rather than send them around the ring. For
> data transfer,
> why incur the RTT delay. You only want to go around the ring to perform a
> control function, not a data transfer function.
>
> Regards
> Peter
>
> -----Original Message-----
> From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
> Sent: Tuesday, May 14, 2002 6:19 AM
> To: 'djz@xxxxxxxxxxx'; John Lemon; Peter Jones; David James (E-mail)
> Cc: Castellano, Robert
> Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
>
>
> David,
>
> We also need to consider how bridge traffic is handled.
> Bridge traffic cannot return to the same port which originally
> transmitted the traffic. We have a bit of a problem
> since bridge traffic in RPR does not have an explicit
> station ID associated with the traffic. There is no
> way to tell which station originated the traffic.
>
> thanks,
>
> robert
>
> -----Original Message-----
> From: David James [mailto:djz@xxxxxxxxxxx]
> Sent: Monday, May 13, 2002 8:55 PM
> To: John Lemon; Peter Jones; David James (E-mail)
> Cc: RCastellano@xxxxxxxxx
> Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
>
>
> Guys,
>
> I read Peter's email, which mainly seemed to confirm
> that there was no reason to outlaw returning client initiated
> traffic that the client has intentionally sent to itself.
>
> Its true that the client doesn't want to be bothered
> with broadcast frames that are sent to itself (rather than
> its upstream neighbor, for convenience).
>
> That is why the (previous to) last meeting decided that only matches
> of destinationMacAddresses should be forwarded to the client.
>
> I see no reason to change that. While one might be able
> to argue that this could be done indirectly through
> control messages, that argument is spurious and applies
> equaally to all data frames (which could, in theory,
> also be sent via this tortuous path...).
>
> Flushing outstanding frames is something that has to
> happen from the client and has to happen quickly for
> the purposes of recoverying after topology changes.
> Lets not pervert this implemenation for a (as yet)
> unspecified reason rumored to be in a lengthy email
> thread...
>
> While I must appologize for not tracking all email threads,
> and thereby missed the early opportunity to object, I don't
> think that is a good reason to change things. After all,
> I was rather busy updating clause 6 text that (I believe)
> reflects the destinationMacAddress returning to the client.
>
> And, BTW, its not really more complex, as sometimes erroneously
> implied...
>
> DVJ
>
>
> David V. James, PhD
> Chief Architect
> Network Processing Solutions
> Data Communications Division
> Cypress Semiconductor, Bldg #3
> 3901 North First Street
> San Jose, CA 95134-1599
> Work: +1.408.545.7560
> Cell: +1.650.954.6906
> Fax: +1.408.456.1962
> Work: djz@xxxxxxxxxxx
> Base: dvj@xxxxxxxxxxxx
>
> > -----Original Message-----
> > From: John Lemon [mailto:JLemon@xxxxxxxxxxxx]
> > Sent: Monday, May 13, 2002 1:48 PM
> > To: Peter Jones; David James (E-mail)
> > Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question
> >
> >
> > I specifically worded clause 6 to allow for control frames to go
> > around the
> > ring, but not client frames, with this in mind. I also started to
> > added some
> > supporting ideas in clause 8 for control frames being able to be
> > sent at any
> > service class (to allow, e.g. flushing by sending a class C
> > control frame).
> >
> > Hopefully this behavior of control frames should be sufficient.
> > If we decide
> > that it is not, then I would listen to an argument for reflectivity for
> > unicast frames, but not for any frame with a group address. But I doubt
> > we'll really need this for client frames. And it would certainly
> > add to the
> > receive frame complexity.
> >
> > -----Original Message-----
> > From: Peter Jones
> > Sent: Monday, May 13, 2002 12:19 PM
> > To: David James (E-mail)
> > Cc: John Lemon
> > Subject: FW: [RPRWG] RE: Fwd: RE: 802.1 architecture question
> >
> >
> > David,
> >
> > Here is the mail I sent to the reflector about whether
> transmission from a
> > given MAC client should ever come back to the client.
> >
> > Have a look through the trail and let me know if you still have some
> > questions.
> >
> > If the issue is to be able to send a message around the ring to act as a
> > flush (e.g. so that you don't get mis-ordering when changing ringlet
> > selection), it seems to me that we should probably do this as a control
> > frame.
> >
> > Regards
> > Peter
> >
> > -----Original Message-----
> > From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
> > Sent: Monday, April 15, 2002 5:48 PM
> > To: 'Jim Mollenauer'; 'Steven Wood'
> > Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; 'Tom Alexander'; John Lemon;
> > Dot17 (E-mail)
> > Subject: [RPRWG] RE: Fwd: RE: 802.1 architecture question
> >
> >
> > Jim & Steve,
> >
> > Please see the attached mail from Tony Jeffree regarding the issue I was
> > chasing down - my work item from the last meeting.
> >
> > The essence of this is that I propose the 802.17 draft states something
> > like:
> > "802.17 MAC is NOT reflective (i.e. does not pass
> > transmissions from the MAC client back to the MAC client)."
> >
> > With supporting text as required.
> >
> > I think this should be sufficient to let us go forward.
> >
> > regards
> > Peter
> >
> > -----Original Message-----
> > From: John Lemon
> > Sent: Friday, April 05, 2002 10:06 AM
> > To: 'Jim Mollenauer'
> > Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
> > 'Tom Alexander'
> > Subject: RE: Fwd: RE: 802.1 architecture question
> >
> >
> > Jim,
> >
> > Please re-read all the attachments to see all the information Peter
> > collected, especially Mick's message. You really don't want to
> > give clients
> > back their sourced frames in many cases, so the safe thing to
> do is never
> > give them back.
> >
> > This behavior is completely different for MAC Control Sublayer
> originated
> > frames. If any diagnostics need this behavior, they can be implemented
> > through a request to the MAC Control Sublayer and an associated
> response.
> >
> > jl
> >
> > -----Original Message-----
> > From: Jim Mollenauer [mailto:jmollenauer@xxxxxxxxxxxxxxxxxxxxx]
> > Sent: Friday, April 05, 2002 4:50 AM
> > To: John Lemon
> > Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
> > 'Tom Alexander'
> > Subject: Re: Fwd: RE: 802.1 architecture question
> >
> >
> > I'd like to thank Peter for his hard work on this item, but John
> > has a valid
> > point. There are times when it is desirable to send a packet
> all the way
> > around
> > the ring, for diagnostic and network management purposes. In fact, the
> > diagnostic application is more likely to exist as a client than
> within the
> > MAC
> > itself. Think of traceroute in IP as an example. Another
> > example would be
> > the
> > token rotation time, used in FDDI as a priority mechanism; the token (a
> > control
> > packet) goes around continuously and provides information on the current
> > traffic
> > load.
> >
> > My suggestion would be to set TTL to n-1 in broadcast messages
> (where n is
> > the
> > number of nodes on the ringlet) but to allow TTL=n in specified unicast
> > control
> > requests. In the latter case the returned message should be sent
> > back up to
> > the
> > client.
> >
> > Jim
> >
> >
> >
> > John Lemon wrote:
> >
> > > While I agree with everything Peter writes here, I just want to be
> > explicit
> > > that this should apply only to the interaction with the client.
> > I believe
> > we
> > > have identified at least one control message that would need to
> > be sent to
> > > oneself (all the way around the ring, not a local drop off :-).
> > >
> > > jl
> > >
> > > -----Original Message-----
> > > From: Peter Jones
> > > Sent: Thursday, April 04, 2002 7:24 PM
> > > To: Steven Wood (E-mail)
> > > Cc: Mike Takefman (E-mail); jmollenauer@xxxxxxxxxxxxxxxxxxxxx; Raj
> > > Sharma; Jason Fan; Tom Alexander (E-mail)
> > > Subject: FW: Fwd: RE: 802.1 architecture question
> > >
> > > Steve,
> > >
> > > I think I'm making progress on my work item (A8: Contribution
> to verify
> > > whether or not 802.17 resolution to comment 14 is consistent
> with other
> > 802
> > > MACs and FDDI) - it's just taken a while.
> > >
> > > It looks like the answer will be that the MAC should not pass a frame
> > > transmitted by the client back to the client. See below for
> gory details
> > of
> > > discussions. It looks like we don't have to support this - so
> we should
> > > simplify our lives and not bother.
> > >
> > > regards
> > > Peter
> > >
> >
> >
> > -------- Old History removed---
> >
> >
> > ______________________________________________________
> > Peter Jones Luminous Networks
> > Principal Engineer 10460 Bubb Road
> > Cupertino, CA, 95014
> > USA
> > Direct: +1 408 342 2513 Main: +1 408 342 6400
> > mailto:pjones@xxxxxxxxxxxx Fax: +1 408 863 1148
> > ______________________________________________________
> >
> >
>