Here are a few comments to try to clarify things:
on 11/6/02 9:39 pm, Spencer Dawkins at spencer_dawkins@yahoo.com wrote:
> Hi, Joe, and thanks for a quick response.
>
> Comments/responses inline...
>
> Spencer
>
> --- Joe Touch <touch@ISI.EDU> wrote:
>> Spencer Dawkins wrote:
<<snip>>
>> ...
>>> 5 Broadcasting and Discovery
>>>
>>> Subnetworks fall into two categories:
>>> point-to-point and shared. A
>>> point-to-point subnet has exactly two endpoint
>>> components (hosts or
>>> routers); a shared link has more than two,
>> using
>>> either an inherent
>>> broadcast media (e.g., Ethernet, radio) or on a
>>> switching layer
>>> hidden from the network layer (switched
>> Ethernet,
>>> Myrinet [MYR],
>>> ATM). Switched subnetworks handle broadcast by
>>> copying broadcast
>>>
>>> Could this sentence say "by forwarding broadcast
>>> packets on all other
>>> interfaces to ensure..."?
>>
>> The current text implies "send TO each destination";
>> sending ON each
>> interface makes implications about the technology
>> which don't apply to
>> some multistage switched nets.
>
> Point taken (thanks!). I was mostly asking to replace
> "copying" with "forwarding".
>
"forwarding on all other interfaces" seems better,
recommend we change to this.
>>
>>> packets to ensure each end system receives a
>> copy
>>> of each packet.
>>>
>>> Could we insert "Centralized databases also insert
>> new
>>> failure points and
>>> scaling hot-spots into the network." before the
>> last
>>> sentence in the
>>> following paragraph?
>>
>> Sure. But it's somewhat obvious (i.e., do we really
>> need to say WHY
>> centralization is bad?).
>
> On this point, and a couple of others in my previous
> comments - the intended audience for LINK is
> subnetwork designers who don't have a lot of
> experience with TCP/IP (beyond surfing the net over
> lunch), so I'd like to call attention to scalability
> more explicitly in this document than would be
> appropriate for most I-Ds. For almost any other I-D, I
> would agree with your response here.
>
>>
>>> The lack of broadcast can impede the
>> performance of
>>> these protocols,
>>> or render them inoperable (e.g. DHCP). ARP-like
>>> link address lookup
>>> can be provided by a centralized database, but
>> at
>>> the expense of
>>> potentially higher response latency and the
>> need
>>> for nodes to have
>>> explicit knowledge of the ARP server address.
>>> Shared links should
>>> support native, link-layer subnet broadcast.
>>>
>>> 6 Multicasting
>>>
>>> Receivers also need to be designed to accept
>>> packets addressed to
>>> some number of multicast addresses in addition
>> to
>>> the unicast packets
>>> specifically addressed to them. How many
>> multicast
>>> addresses need to
>>> be supported by a host depends on the
>> requirements
>>> of the associated
>>> host; at least several dozen will meet most
>> current
>>> needs.
>>>
>>> The last phrase doesn't parse well for me. Is it
>>> saying "few hosts
>>> must accept multicast packets from more than a few
>>> dozen multicast
>>> addresses"?
>>
>> Yes. Since it appears to have worked, perhaps it's
>> sufficient. :-)
>
> OK, but while I may not be the brightest candle in the
> candleabra, some readers of this document may have
> more trouble figuring it out than I did, especially
> given the target audience.
>
> But my comment ALSO didn't do what I was trying to do
> - come up with a nearest-multiple-of-ten number, to
> say "few hosts must accept multicast packets from more
> than ___ hosts". "Few dozen" and "several dozen"
> probably do have the same number of significant
> digits!
>
> Any ideas (from anyone) on what a reasonable "minimum
> maximum" number would be for this sentence?
This is not easy. I recall we tried hard to better this.
The number you benefit from actually using depends on such
things as:
the number of groups in **active** use;
number of groups **required** by clients;
number of **link addresses** (i.e., actual overlap)
and the penalty for having to filter at a higher level.
10-30 would still seem ok --- but not sure it's improved the
text very much. For end hosts acting as routers, the
numbers may well differ.
Recommend we keep -11 wording.
>
>>
>>> On low-speed networks the multicast address
>>> recognition function may
>>> be readily implemented in host software, but on
>>> high speed networks
>>> it should be implemented in subnetwork
>> hardware.
>>> This hardware need
>>> not be complete; for example, many Ethernet
>>> interfaces implement a
>>> "hashing" function that passes all of the
>> multicast
>>> (and unicast)
>>> traffic to which the associated host
>> subscribes,
>>> plus some small
>>> fraction of multicast traffic to which the host
>>> does not subscribe.
>>> Host/router software then has to discard the
>>> unwanted packets that
>>> pass the hardware filter.
>>>
>>> There does not need to be a one-to-one mapping
>>> between subnetwork
>>> multicast address and IP multicast address. An
>>> address overlap may
>>> significantly degrade the filtering capability
>> of a
>>> receiver's
>>> hardware multicast address filter. A subnetwork
>>> supporting only
>>>
>>> Is this sentence saying "If more than one IP
>> multicast
>>> address makes into
>>> a subnetwork multicast address, this many-to-one
>>> mapping may significantly
>>> degrade the filtering capacity of a receiver's
>>> hardware multicast address
>>> filter", or something else? "Address overlap" is
>> too
>>> ambiguous for me...
>>>
>>> broadcast should use this service for multicast
>> and
>>> must rely on
>>> software filtering.
>>>
>>
>> The rest of the sentence explains it - hardware
>> stops being useful and
>> thus requires software.
>
> This probably was clear enough in version 11. I agree
> with your response.
>
> Again, thanks for all your help with this document!
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> _______________________________________________
> pilc mailing list
> pilc@ietf.org
> https://www1.ietf.org/mailman/listinfo/pilc
> http://www.ietf.org/html.charters/pilc-charter.html
> http://pilc.grc.nasa.gov/
>
Gorry Fairhurst
P.S. Still noticed some duplicate terms:
See the following:
end-host
end system
end systems
I recommend these are replaced by:
end host (or end hosts).
_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 05:42:32 EDT