glen herrmannsfeldt wrote:
> > I think ICMP Source has been deprecated for more than 20 years.  See
> > http://www.google.com/search?q=icmp+source+quench+deprecated
> 
> Is it that long ago?
> 
> I remember trying to ftp a new version of NCSA Telnet to a PC,
> (all the way from NCSA), the PC sending out source quench as
> fast as it could, as its buffers kept overrunning.  That would
> have been a little less than 20 years ago.
> 
> Many early PC ethernet cards had small buffers.

Geesh!  I just read a post by Dan Lanciani and it made me think of all
the installs I did with Crynwr pkt drivers and BYU's IPX.

Then I come here and I'm treated to another trip down the memory lane
with NCSA Telnet!  ;)

I wonder if I'll now run into someone asking a question about Pegasus
Mail, Spyder analyzers, and Coherent (Unix clone)  Or a flame war will
break about about Kermit being superior to NCSA Telnet!  ;)

-- 

hsb


"Somehow I imagined this experience would be more rewarding" Calvin
********************************************************************
Due to the volume of email that I receive, I may not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

Vernon Schryver wrote:
(snip)

> I think ICMP Source has been deprecated for more than 20 years.  See
> http://www.google.com/search?q=icmp+source+quench+deprecated

Is it that long ago?

I remember trying to ftp a new version of NCSA Telnet to a PC,
(all the way from NCSA), the PC sending out source quench as
fast as it could, as its buffers kept overrunning.  That would
have been a little less than 20 years ago.

Many early PC ethernet cards had small buffers.

-- glen

In article <PvGdnWVRAIdVE3_VnZ2dnUVZ_sninZ2d@comcast.com>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:

>Also, you can't accept route redirect or source quench,
>two others that would seem useful in some cases.

ICMP Redirect might be useful, but might involve a lot of machinery
given the target situations of no routers.
I think ICMP Source has been deprecated for more than 20 years.  See
http://www.google.com/search?q=icmp+source+quench+deprecated

For an application like this that might otherwise use raw Ethernet
packets, Source Quench is obviously useless.  In general, Source Quench
is of little use, because transport protocols that real networks can
tolerate have their own congestion avoidance and recovery machinery.
Even if your UDP or other datagram application doesn't have official
congestion management stuff, it ought to have some sort of pacing
machinery that responds to losses caused by losses, which tends to make
ICMP Source Quench irrelevant.  

Besides, ICMP Source Quench uses bandwidth, which can make a merely
marginal situation into a bad situation.  So we get things like TCP
Explicit Congestion Notification   http://www.google.com/search?q=tcp+ecn


Vernon Schryver    vjs@rhyolite.com

Vernon Schryver wrote:
(snip regarding generating UDP in an FPGA)

> My answer to the question at the start is that in the real world
> there are *always* situations where the absolutely guaranteed
> for certain always and forever promise that there will never be
> a router is broken.   Therefore the low the costs of slapping fake
> but servicable UDP/IP headers in front of the payload are so low that
> you can't afford not to pay them.  There are always test networks if
> the promises about no routers are always and forever met when the
> application is deployed...and the promises usually are broken in some
> deployed case.

But if you supply the MAC address of the router, it will even
work through a router.  The main problem it does have is that
if you change the net around it won't adapt to the change.

If you have no ability to receive you can't do ARP, anyway.
Also, you can't accept route redirect or source quench,
two others that would seem useful in some cases.

But networks do change...

-- glen

In article <gbribf$q3i$6@usenet01.boi.hp.com>,
Rick Jones  <rick.jones2@hp.com> wrote:

>Is the destination "always" going to be in the same broadcast domain
>as the FPGA?  If so, then why bother with IP and UDP?  The only value
>IP adds in this case would seem to be fragmentation and reassembly,
>but then only if you implement fragmentation in your FPGA.
>
>If the destination can be "remote" (on the other side of an IP router)
>then there are a rather large host (as it were) of things expected of
>an IP implementation besides just "slap a header on there and go"
>described in a number of the RFC's one can find at places such as
>www.ietf.org.

My answer to the question at the start is that in the real world
there are *always* situations where the absolutely guaranteed
for certain always and forever promise that there will never be
a router is broken.   Therefore the low the costs of slapping fake
but servicable UDP/IP headers in front of the payload are so low that
you can't afford not to pay them.  There are always test networks if
the promises about no routers are always and forever met when the
application is deployed...and the promises usually are broken in some
deployed case.


Vernon Schryver    vjs@rhyolite.com

Rick Jones wrote:
(snip)

>>Fred wrote:

>>>I've been tasked to write some code for an FPGA to interface to
>>>10BASE- T Ethernet using differential drivers and receivers.

(snip, then I wrote)
>>Normally you would use ARP to find the destination MAC given the IP
>>address.  Since you seem to already know it, you shouldn't need ARP.
>>If you don't need to receive, or the sender already knows your MAC
>>address then you don't need to receive and reply to ARP.  (Most will
>>add you to the ARP table on receiving your data.  The entry will
>>eventually time out, though.)

> Is the destination "always" going to be in the same broadcast domain
> as the FPGA?  If so, then why bother with IP and UDP?  The only value
> IP adds in this case would seem to be fragmentation and reassembly,
> but then only if you implement fragmentation in your FPGA.

It means you don't have to do so much work on the receiver
if it already has IP running.  In many cases, it isn't easy
to receive raw data on a host already running IP.

Adding the UDP header is pretty easy.  You can even put in
zero for the checksum to ignore it.  You still have to
generate the ethernet CRC, though.

> If the destination can be "remote" (on the other side of an IP router)
> then there are a rather large host (as it were) of things expected of
> an IP implementation besides just "slap a header on there and go"
> described in a number of the RFC's one can find at places such as
> www.ietf.org.

Well, you need the MAC address of the router instead of
the destination host.  Implementing route redirect would
be nice, but not needed.  Otherwise, just adding a UDP header
should work.  You might also want source quench or some
kind of flow control.  For transmit only you can't use the
reply packets for flow control.

-- glen

In comp.protocols.tcp-ip glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> (comp.protocols.tcp-ip added)

> Fred wrote:

> > I've been tasked to write some code for an FPGA to interface to
> > 10BASE- T Ethernet using differential drivers and receivers.

> > The information is one way, transmit only!  I will have an IP
> > address within the network range, give myself a MAC number and
> > know the MAC and IP address of the destination PC.

> > Do I require any ARP or any other protocol?  Will it just work,
> > with the destination PC receiving UDP packets?

> Normally you would use ARP to find the destination MAC given the IP
> address.  Since you seem to already know it, you shouldn't need ARP.
> If you don't need to receive, or the sender already knows your MAC
> address then you don't need to receive and reply to ARP.  (Most will
> add you to the ARP table on receiving your data.  The entry will
> eventually time out, though.)

Is the destination "always" going to be in the same broadcast domain
as the FPGA?  If so, then why bother with IP and UDP?  The only value
IP adds in this case would seem to be fragmentation and reassembly,
but then only if you implement fragmentation in your FPGA.

If the destination can be "remote" (on the other side of an IP router)
then there are a rather large host (as it were) of things expected of
an IP implementation besides just "slap a header on there and go"
described in a number of the RFC's one can find at places such as
www.ietf.org.

rick jones
-- 
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision.  - Jobert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

(comp.protocols.tcp-ip added)

Fred wrote:

> I've been tasked to write some code for an FPGA to interface to 10BASE-
> T Ethernet using differential drivers and receivers.

> The information is one way, transmit only!  I will have an IP address
> within the network range, give myself a MAC number and know the MAC
> and IP address of the destination PC.

> Do I require any ARP or any other protocol?  Will it just work, with
> the destination PC receiving UDP packets?

Normally you would use ARP to find the destination MAC given
the IP address.  Since you seem to already know it, you shouldn't
need ARP.  If you don't need to receive, or the sender already
knows your MAC address then you don't need to receive and
reply to ARP.  (Most will add you to the ARP table on receiving
your data.  The entry will eventually time out, though.)

You could also broadcast.  (Set the destination to X'ffffffffffff').
That isn't recommended if there are other hosts on the net, and it
might be that some IP implementations ignore broadcast packets
without a broadcast IP address.

-- glen

Fred wrote:
> I've been tasked to write some code for an FPGA to interface to
> 10BASE- T Ethernet using differential drivers and receivers.
>
http://www.fpga4fun.com/10BASE-T.html 

I've been tasked to write some code for an FPGA to interface to 10BASE-
T Ethernet using differential drivers and receivers.

The information is one way, transmit only!  I will have an IP address
within the network range, give myself a MAC number and know the MAC
and IP address of the destination PC.

Do I require any ARP or any other protocol?  Will it just work, with
the destination PC receiving UDP packets?

Fred