HDTenEightyP/NetNews huggingface dataset:
From: mbt@ESD.3Com.COM (Brad Turner)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 6 Oct 92 15:25:50 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Doesn't every (reasonable) TCP implementation start with an MSS,
>Maximum Segment Size, option in the first TCP header, along with the
>SYN flag?  Isn't the value of the MSS no larger than the local MTU, the
>maximum transmission size?  In other words, on every reasonable TCP/IP
>implementation, whether the application is for a "bulk transfer" or
>not, the two ends of the virtual circuit will choose the minimum of
>each end's max transmit.  size.

I won't hazzard to guess about all the different TCP implementations out
there. What is the concensus/experience of folks in comp.dcom.lans.fddi
etc?

-brad-

--
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner | 5400 Bayfront Plaza  | Marketing Engineer   | (408) 764-5261
3Com Corp.  | Santa Clara CA, 95052| mbt@NSD.3Com.Com     | (408) 764-5002 fax
From: adam@sparkle.uucp (Adam Shostack)
Newsgroups: comp.dcom.lans.fddi
Subject: FAQ or intro to FDDI?
Keywords: FAQ, intro
Date: 6 Oct 92 20:46:46 GMT
Article-I.D.: das.1992Oct6.204646.22037
Organization: Dept of Radiology, Brigham & Womens Hospital, Boston

Is there a FAQ for this qroup, or a good introductory reading?

I have read through rfc 1188, but I'm looking for something at a
higher level.  I don't need to know about the details yet.

Thanks in advance,

Adam



Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all.  How true that is.      
Xref: sparky comp.dcom.lans.fddi:655 comp.protocols.nfs:2415
From: rmwise@mcigate.apdev.mci.com (Bob_Wise)
Subject: Re: Can NFS over FDDI work properly?
Date: Wed, 30 Sep 1992 15:08:56 GMT
Organization: MCI
Keywords: NFS, FDDI

I've been following this packet-fragmentation-when-using-NFS-over-FDDI
thread with some interest.

I've got two IBM RS/6000 950's which are shortly to become 970's, plus
I've got another 2 970's coming.  We do a lot of NFS over ethernet,
and I am about to move that NFS traffic over to a small FDDI ring that
only has the 970 servers on it.

Is the fragmentation problem present with this scenario, or is
fragmentation only a problem with bridges and routers?

Do I need to consider adjusting packet sizes?

Thanks,

-Bob



-- 
---------------------------------------------------------------------------
| Bob Wise          | INET:622-1322 | MCIMail:rmwise | Pager:719-577-1928 |
| Unix Consultant   |-----------------------------------------------------|
| Consultant to MCI | Phone:719-592-1322 | Internet:rmwise@apdev.mci.com  |
From: chicken@npac.syr.edu (Mark R. Levinson)
Newsgroups: comp.dcom.lans.fddi
Subject: Booting diskless DECstation over FDDI?
Date: 28 Sep 92 15:41:38 GMT
Organization: NPAC, Syracuse University - Syracuse, New York (USA)


	Could anyone tell me if it's possible to boot a diskless DECstation
5000 (running Ultrix 4.2a) over FDDI rather than ethernet? If so, how is it
done? I've tried using the command "boot #/mop" from the monitor where # is
the slot of the FDDI card (which seemed like an obvious solution), but the
machine just hangs and syslog on the boot server shows no record of a dumpload
request from the client's FDDI address.

	If anyone can offer ideas, I'd appreciate it. Thanks!

--
Mark R. Levinson
Northeast Parallel Architectures Center
Syracuse University
From: mbt@ESD.3Com.COM (Brad Turner)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 5 Oct 92 22:32:26 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>In article <mbt.718307170@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
>> 
>I don't know about XNS or IPX, and I can't find any equivalent to the
>IP offset or MF bits in the "Internet Protocol" described in my old
>Xerox XNS documents.
 
Ahhh now we are talking about the same thing, my basic point is that "you
can't get there from here" within the context of bridging IPX or XNS
from FDDI to ethernet. The primative building blocks that exist within
IP that allow you to frag packets simply don't exist within the all
other protocol suites.
 
>The TCP sequence numbers have absolutely nothing to do with fragmenting
>TCP/IP, UDP/IP, or any other current IP protocol.  IP fragmenting is
>done entirely within the IP datagram, and is based on the 8-byte
>"offset" and the "more fragments" flag.
 
You're correct, I'm mixing my layers here, but the basic point about not
being able to fragment all protocols still hold true.
 
>The only IP fragmenting that an FDDI-ether bridge will usually need to
>do is of UDP packets.  UDP packets are datagrams, and have no sequence
>numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
>initial MSS negotiation in TCP will pick 1500.  This is consistent with
>the TCP/IP lore (and RFC) that considers fragmenting harmful.
 
Hmmm what about bulk transfers (e.g. FTP, SMTP) that are TCP based? If a
connection is to a local station (i.e. same net/subnet) won't the node
attempt to use max size packets of the native media for the TCP connection?
For example a FTP transfer from a FDDI station to an ethernet station that
is bridged. Won't the FDDI node attempt to use max size FDDI frames for the
transfer since the IP address of the destination is on the same net/subnet
as the FDDI station?
 
>Vernon Schryver,  vjs@sgi.com
 
 
-brad-
 

--
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner | 5400 Bayfront Plaza  | Marketing Engineer   | (408) 764-5261
3Com Corp.  | Santa Clara CA, 95052| mbt@NSD.3Com.Com     | (408) 764-5002 fax
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Concentrator(?)
Date: 5 Oct 92 19:18:06 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Oct5.163841.26267@e2big.mko.dec.com>, pettengill@cvg.enet.dec.com () writes:
> ...
>                                                 While not `legal', I suppose
> that some implementations will support rings with more than two SAS nodes,
> although I suspect that they would more legitimately be called `A' ports.


You cannot build a ring of more than 2 stations using 'A' ports.
Each A, B, M, or S port expects both a transmitting fiber going
to the neighbor and a receiving fiber from same neighbor for CMT
signalling.  I think the largest ring you can building involving
single attached stations and no concentrators is 3 stations, using
a DAS between two SAS's.


There was the old "class C" (I think that was a semi-official name)
before CMT signaling.  You could build as big a ring as you please,
with a single PHY in each station.

Today, if you're willing to do a little kludging and standard breaking,
you can still put a station with a single PHY into one side of the dual
ring.  Just have the station repeat all line states except ILS, and do
normal FDDI tokens and frames the rest of the time.  The neighboring
stations will CMT signal just fine.  The only oddity will be in the
ring maps.  You can do this trick even if you cannot turn off the
"repeat filter" in the PHY chip you use.  You can put more than one
such sneaky station between a pair of unsuspecting dual-attached
stations.

This is not academic; I've done it.  However, there's no market or need
for such a facility once you get CMT up and running.


Vernon Schryver,  vjs@sgi.com
From: rasp@xlnt.com (Ron Perloff)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: 10 byte fragments on fddi - a sign of trouble?
Date: 6 Oct 92 00:22:02 GMT
Article-I.D.: xlnt.1215
Organization: xdi

In article <ON7T+38+F@linac.fnal.gov> crawdad@fncent (Matt Crawford) writes:
>While looking at one of our fddi rings I saw a fair number of 10 byte
>fragment frames which had just the initial frame code byte, a valid
>local destination address, and half of a source address.  Is this
>"normal"?

Yes! In FDDI networks, each source node is responsible
for stripping frames it has sent. If the node is not a
bridge, it recognizes frames it has stripped by seeing
its own MAC address in the source address field. Because
nodes must minimize latency, they have already retransmitted
the first several bytes of the frame before they have received
the complete source address field, so it is too late to
strip the entire frame. That is okay, however, because
MACs 'know' not to receive partial frames.

Ron

Ronald S. Perloff     rasp@xlnt.com
XLNT Designs, Inc.  (XDI)
15050 Avenue of Science
Suite 106
San Diego, CA  92128
619 487 9320   -   FAX: 619 487 9768
Newsgroups: comp.dcom.lans.fddi
From: crawdad@fncent (Matt Crawford)
Subject: 10 byte fragments on fddi - a sign of trouble?
Organization: FERMILAB, Batavia, IL
Date: Sat, 3 Oct 1992 15:55:07 GMT

While looking at one of our fddi rings I saw a fair number of 10 byte
fragment frames which had just the initial frame code byte, a valid
local destination address, and half of a source address.  Is this
"normal"?  My analyzer was set to select only LLC frames to or from a
certain address, and the ring has 2 concentrators (cascaded), 2 fddi-
to-ether bridges, 2 big vaxes and an sgi machine.  I was selecting on
the sgi's address.
_________________________________________________________
Matt Crawford       crawdad@fncent.fnal.gov      Fermilab

Newsgroups: comp.dcom.lans.fddi
From: jsims@uswest.com (John Sims)
Subject: Re: SBUS FDDI Cards for TCP/IP & SunOS
Organization: U S WEST Advanced Technologies
Date: Thu, 1 Oct 1992 20:03:35 GMT

In article <1992Sep30.183832.3906@meaddata.com>, rfrink@meaddata.com (Rick Frink) writes:
> 
>     Does anybody know of a vendor who currently (or plans to) offers an SBUS
>   FDDI card (SAS) that has some of the upper-level protocol stack resident
>   on the card ?  This would relieve some of the host burden and possibly
>   enable TCP/IP over FDDI to run faster.  Also, some sort of MTU discovery 
>   (based on destination network) would be nice, too.
>     Is this realistic.  Any responses are appreciated.  Thanks.
> 
> 
> 
> -- 
> Rick Frink                                              (513) 865-1645
> Mead Data Central                             Telecomm/Campus Networks
> P.O. Box 933                                       rfrink@meaddata.com
> Dayton, Ohio  45401                          ...!uunet!meaddata!rfrink

I'd like to see the same thing.  We have Sbus cards from Network Peripherals
and CMC/Rockwell.  Some benchmarking here shows the TCP performance to
be ~25Mbps (the NP card can transmit faster than the CMC card, but the
CMC card receives faster, go figure).  Our numbers are CPU bound on a Sparc2.
The SGI folks, claim ~70Mbps on their cards for Indigo's (of course, we've had our order in for several months and to date no FDDI cards have been seen from SGI).

SGI aside, many applications run in Sun environments and I would hope that
someone's doing a good implementation for the Sbus?  I just received one of
Sun's SAS cards, who knows maybe they will have better numbers.  Any additional
info on Sbus cards would be appreciated.

John Sims
U S WEST Advanced Technologies
4001 Discovery Dr.
Boulder, CO 80303
jsims@advtech.uswest.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 1 Oct 92 20:55:18 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <mbt.717961736@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> ...
> >That's a reasonable statement.  Why does 3Com allow their boxes
> >to do FDDI-ethernet bridging?  When they drop 4K IP FDDI packets?
> 
> Because in some instances it solves real customer problems. As a vendor
> it is our challenge to educate/advise customers as to the pros and cons
> of various methods of interconnecting networks and help them design
> the best solution to fit their specific needs. In some instances
> translation bridging is a valid solution.


I understand that kind of pressure.  There are always salescreatures
who find multi-million dollar deals that the system (yours or mine)
does not quiet fit.  The salescritters I deal with never, and even some
management often does not understand my concern that while doing the
deal is good for this quarter's revenue numbers and this month's
commission check, selling a bad solution now can prevent ever selling
anything to that account again.  Or even selling anything other
accounts which have in future years hired someone who worked at the
first account.  I don't even try to convey my fear and loathing for the
support hassles, arguments, and verbal abuse generated by such a bad
fit.

For a typical example, I have watched customers of fancy ethernet hubs
decide network problems were the fault of the hubs, and refuse to ever
deal with the vender again under any circumstances, even though the
problems were not really caused by the hubs.

There are several companies selling FDDI-ether bridges that do not work
in the presense of real FDDI hosts using UDP.  I continue to wonder
what their customers think after they discover they have purchased
bridges that work "some of the time for some traffic."  No matter how
great the bridge may be otherwise, do they ever deal with that vendor
again?

I know that I would be skeptical of any company that tried to sell me
an FDDI-ether bridge that just dropped 4K UDP/IP/FDDI packets, because
if the bridge vendor does not understand the importance of 4K FDDI
packets and just tells me to "change the MTU", then the bridge vendor
may not understand other, more important issues.


Vernon Schryver,  vjs@sgi.com
From: jost@jake.prz.tu-berlin.de (Jost Weinmiller)
Newsgroups: comp.dcom.lans.fddi
Subject: XTP-forum???
Date: 30 Sep 92 14:47:06 GMT
Followup-To: comp.dcom.lans.fddi
Organization: TU-Berlin TUBKOM, Germany

This is not really a FDDI subject, but 
I guess this is the closest newsgroup to my problem: 

Is there any mailing list about XTP? 

i would desperatly need information on the structure
of the interfaces from XTP  to the upper (application) layer
and to the lower layer, maybe someone could give me some 
pointers, where to search successful.
(we want to implement XTP over Ethernet & FDDI on a 
sun sparc 2 ) 

Thank you all

jost
 
-- 
jost weinmiller                
markelstrasse 41              
1000 berlin 41               
030/7933164
From: thomas@lkg.dec.com (Matt Thomas)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Date: 5 Oct 92 20:24:52 GMT
Article-I.D.: nntpd.1992Oct5.202452.5287
Reply-To: thomas@lkg.dec.com
Organization: Digital Equipment Corporation


In article <mbt.718307170@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
|>vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|>>In article <mbt.717984230@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
|>>> IP aside how does SGI deal with ether to FDDI translation bridging
|>>> of protocols that don't use byte level acks? Just courious...
|>
|>>I don't know what is meant by "byte level acks".  Protocols such as TP4
|>>or XNS with records?  What problems special do they have?
|>
|>A bridge can't fragment a 4K XNS/IPX datagram the way it can a IP
|>datagram. The only reason you can frag an IP packet is because the
|>seq numbers are at the byte level. With XNS et. al. since the seq
|>numbers correlate to packet number a bridge can't really fragment
|>packet number 2 into packet number 2 and packet 2.5. The end node
|>is going to send out packet seq number 3 after 2. So how can the
|>bridge fragment?

Wrong.  IP works not because of the byte level acks (which obviously
don't exist in UDP), but because the IP network layer supports the
fragmentation of IP packets.  The destination system will gather the
fragments, rebuild the IP packet and then process it.  The upper layers
(TCP/UDP/...) don't even (have to) know that fragmentation happened.

CLNS supports fragmentation of its packets so a bridge could fragment
them and TP4 wouldn't care (even though it uses segment based acks).

Protocols such as LAT, XNS, or DECnet Phase IV which don't support
fragmentation must either restrict themselves to using 1500 byte packets
or use "some" method of determining whether packets to the remote target
system traverse an Ethernet.
--
Matt Thomas                     Internet:   thomas@lkg.dec.com
DECnet-ULTRIX Development       UUCP:       ...!decwrl!thomas
Digital Equipment Corporation   Disclaimer: This message reflects my own
Littleton, MA                               warped views, etc.
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Can NFS over FDDI work properly?
Keywords: NFS, FDDI
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 6 Oct 1992 02:31:57 GMT

In article <mbt.718324346@Able.MKT.3Com.Com>, mbt@ESD.3Com.COM (Brad Turner) writes:
> ...
> >The only IP fragmenting that an FDDI-ether bridge will usually need to
> >do is of UDP packets.  UDP packets are datagrams, and have no sequence
> >numbers of any kind.  If you don't have FDDI-ether-FDDI networks, the
> >initial MSS negotiation in TCP will pick 1500.  This is consistent with
> >the TCP/IP lore (and RFC) that considers fragmenting harmful.
>  
> Hmmm what about bulk transfers (e.g. FTP, SMTP) that are TCP based? If a
> connection is to a local station (i.e. same net/subnet) won't the node
> attempt to use max size packets of the native media for the TCP connection?
> For example a FTP transfer from a FDDI station to an ethernet station that
> is bridged. Won't the FDDI node attempt to use max size FDDI frames for the
> transfer since the IP address of the destination is on the same net/subnet
> as the FDDI station?


Doesn't every (reasonable) TCP implementation start with an MSS,
Maximum Segment Size, option in the first TCP header, along with the
SYN flag?  Isn't the value of the MSS no larger than the local MTU, the
maximum transmission size?  In other words, on every reasonable TCP/IP
implementation, whether the application is for a "bulk transfer" or
not, the two ends of the virtual circuit will choose the minimum of
each end's max transmit.  size.

This has nothing to do with the hallowed recommendation that if the
remote end is not on the same IP network (sometimes subnetwork), your
TCP implementation should propose to use 512 or a similar number (e.g.
576) for the max. segment size.  Please notice that 512 and 576 are far
smaller than 1500, and have unfortunate effects on bulk transfers.  I
understand from what I've been told and from some experiments that the
old 512 restriction no longer applies in most of the Internet.


vjs
Xref: sparky comp.dcom.lans:1932 comp.os.msdos.misc:5412 comp.protocols.tcp-ip:4574
Organization: Middle East Technical University - Computer Center
Date: Tuesday, 29 Sep 1992 19:00:23 TUR
From: Cevdet Dengi <CEVDET@TRMETU.BITNET>
Newsgroups: comp.dcom.lans,comp.os.msdos.misc,comp.protocols.tcp-ip
Subject: Clarkson Token-Ring Packet Driver on PcRoute ver 2.4

I use pcroute (ver 2.4) software for ip routing between two ethernet
LAN s. Now I need also a token-ring connection. I have an IBM token-ring
card and Clarkson packet driver for token-ring cards. I installed
the packet driver and changed the pcroute configuration but
it didn't run correctly. Does anybody arround who has tried to
use Token-Ring packet driver with pcroute software. Any information will
be appreciated.


Cevdet Dengi

TUBITAK Software Center
Newsgroups: comp.dcom.lans,comp.protocols.appletalk
From: mucm000@uxa.ecn.bgu.edu (Fred Seaton)
Subject: PCRoute and LocalTalk (and NuvoTech routers)
Organization: Educational Computing Network
Date: Fri, 2 Oct 1992 02:58:13 GMT

Hello net,

I recently installed PCRoute v2.4 in a machine with an Ethernet (WD8003E
look-alike) and an APple LocalTalk PC card.  The Ethernet side is a
TCP/IP network and the LocalTalk side contain about 7 different
LocalTalk zones separated by NuboTech routers (TurboBridges).  

The problem I'm having is that Macs using MacTCP 1.1 in any zone outside
of the zone in which the PCRouter is located can't access anything.
("Host or gateway not responding")

I was told to see if a mac in one zone could telnet to a mac in another
zone (i.e., without going through the PCRouter.  

so,to verify that things were working properly, I started telnet on one mac
and tried to ftp to it from another mac.  This worked fine, so long as
the two macs were in the same localtalk zones.  However, I could not
perform the same test across zones, even if I changed the setup for
MacTCP to say that the location of the router was in a different zone
(through the zon pop-up menu in MacTCP under the localtalk icon).

My guess is that maybe there is an incompatibility between MacTCP and
the NuvoTech routers.  Can anyone offer any suggestions or supporting
evidence?

Thanks in advance.  As I'm not a regular reader of this group, please
respond directly to me (F-Seaton@bgu.edu) and I will summarize for the
list.

Fred Seaton
Apple Support Coordinator
Western Illinois University
F-Seaton@bgu.edu

Newsgroups: alt.heraldry.sca
From: trifid@agora.rain.com (Roadster Racewerks)
Subject: Re: OK and the sca
Organization: Open Communications Forum
Date: Sun, 4 Oct 1992 12:01:28 GMT

In article <1alqr6INNcoh@usenet.INS.CWRU.Edu> ch571@cleveland.Freenet.Edu (Cat Fitzgerald) writes:
>
>hello? is ther anybody out there? does anyone have a # for the SCA
>in Norman, Oklahoma?
>or tulsa for that matter....
>
>not-so-new-newbie



Well, Cat, the traffic has moved to rec.heraldry and this group is *supposed*
to be dead!

Unfortunately I don't know what's available in Oklahomah. Maybe you ought to
try rec.org.sca....

Moreach NicMaolain/Suze
trifid@agora.rain.com

ps,

My boyfriend is a Fitzgerald from Oklahomah, I wonder if you're related?
From: ch571@cleveland.Freenet.Edu (Cat Fitzgerald)
Newsgroups: alt.heraldry.sca
Subject: OK and the sca
Date: 4 Oct 1992 04:10:14 GMT
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
NNTP-Posting-Host: hela.ins.cwru.edu


hello? is ther anybody out there? does anyone have a # for the SCA
in Norman, Oklahoma?
or tulsa for that matter....

not-so-new-newbie
From: ez007856@hamlet.ucdavis.edu
Newsgroups: alt.save.the.earth
Subject: INFO REQUESTED
Date: 5 Oct 92 03:57:09 GMT
Organization: Computing Services, UC Davis

I would appreciate any information on hydrogen sulphide emissions and its
effect to the environment/health.  I am particulary interested in any informa-
tion on community struggles againtst industrial waste treatment plants that
emit high levels of hydrogen sulphide which affect their environment and
health.  The information will serve to benefit a particular community which
has undergone exposure to such emmissions while EPA has remained in the 
sidelines.  The emmissions at hand are products of a waste treatment plant
that underwent a "conversion" and suddenly was disponsing tons of pharmaceuti- 
cal wastes which oxidize and emit the gas, affecting a poplation of about 
10,000.  I've gotten plenty of technical date but am in need of the experiences
of other interested parties in fighting simmilar polluters. Thanks in
advance.

Edelmiro Salas
easalas@ucdavis.edu
From: dth2@cunixb.cc.columbia.edu (David T Ho)
Newsgroups: alt.save.the.earth
Subject: Re: Recycling
Date: 7 Oct 92 01:03:07 GMT
Reply-To: dth2@cunixb.cc.columbia.edu (David T Ho)
Organization: Columbia University

In article <1992Oct2.111259.1@woods.ulowell.edu> cotera@woods.ulowell.edu writes:
>It seems to me that recycling is not only more expensive, but that it puts
>people out of work.  To what end? To solve a crisis that probably doesn't
>exist.
>--Ray Cote

What do you mean when you say that recycling puts people out of work?
What about the jobs that are created by recycling?  What is this
crisis to which you referred?  (Our diminshing resources or increasing
garbage problem?)


--
David T. Ho                       
dth2@cunixb.cc.columbia.edu