Re: A few comments on LINK version 11

Here are a few comments to try to clarify things:

on 11/6/02 9:39 pm, Spencer Dawkins at [email protected] wrote:

> Hi, Joe, and thanks for a quick response.
> 
> Comments/responses inline...
> 
> Spencer
> 
> --- Joe Touch <[email protected]> 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
> [email protected]
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/