Hi all,
Thanks a lot to Stuart Cheshire for helping with the notes!
The minutes are now posted:
https://datatracker.ietf.org/doc/minutes-118-intarea-202311091400/
Best,
Juan-Carlos & Wassim
(IntArea WG chairs)
___
Int-area mailing list
Int-area@ietf.
Here is something everyone should read and become familiar with taken from
Section 5 of the latest
version of "IP Parcels and Advanced Jumbos":
https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
A new link service model is offered that will be essential for supporting
air/land/sea/
Hi Tom, see below for responses:
> -Original Message-
> From: Int-area On Behalf Of Tom Herbert
> Sent: Monday, November 13, 2023 12:39 PM
> To: Templin (US), Fred L
> Cc: int-area@ietf.org
> Subject: [EXTERNAL] Re: [Int-area] A new link service model for the Internet
> (IP Parcels and
On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
wrote:
>
> Hi Tom, see below for responses:
>
> > -Original Message-
> > From: Int-area On Behalf Of Tom Herbert
> > Sent: Monday, November 13, 2023 12:39 PM
> > To: Templin (US), Fred L
> > Cc: int-area@ietf.org
> > Subject: [EXTERNAL
Hi Tom,
On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
wrote:
>
> Hi Tom, see below for responses:
>
> > -Original Message-
> > From: Int-area On Behalf Of Tom Herbert
> > Sent: Monday, November 13, 2023 12:39 PM
> > To: Templin (US), Fred L
> > Cc: int-area@ietf.org
> > Subject:
Top posting two small but important points to Fred:
1) Changing Ethernet CRC behavior is up to IEEE. IETF is not free to
redefine that.
2) There are approaches for links with long delays (sometimes even
longer than the 8 minutes to which you refer). If you want to propose
different mechani
Hi, thank you for this but the minutes that tried to capture what was said in
my talk
have some distortions that need to be clarified:
“Fred Templin presented graphs showing that on a 100GB/s point-to-point
Ethernet link between two machines connected back-to-back, Licklider
Transmission Protocol
On Mon, Nov 13, 2023, 4:41 PM Templin (US), Fred L <
fred.l.temp...@boeing.com> wrote:
> Hi Tom,
>
> On Mon, Nov 13, 2023 at 1:11 PM Templin (US), Fred L
> wrote:
> >
> > Hi Tom, see below for responses:
> >
> > > -Original Message-
> > > From: Int-area On Behalf Of Tom Herbert
> > > Sen
The NICs I have worked on have a mode that allows packets with CRC failures to
be delivered with a status bit indicating the CRC error. If I remember
correctly, CRC logic amounts to just a handful for gates; so, arranging to
disable it would not be worth the effort at the standardization level.
Tom, I think to put this discussion into proper contest we need to remember
that this is about
IP parcels and advanced jumbos, and not about ordinary IP packets. An IP parcel
is a ready-made
vehicle for FEC since it includes up to 64 transport layer segments – simply
include multiple copies
of t
Thank you for this, Herbie – exactly what you describe below would be an
acceptable solution. Let the
CRC gates do their work, but deliver packets with CRC failures with a status
bit to the driver and/or IP
layer. Yes, that would satisfy the need.
About CRCs larger than 32 bits for larger frame
There has to be something better than MD5 these days. It’s actually slower to
implement than some newer hashes and overkill at the same time (because it was
designed for crypto).
For that matter, CRCs are really cheap to implement in hardware (a shift
register and a few gates), but they are ha
I don’t mind entertaining alternatives to MD5 – SHA1?
I looked, but could not find a standard for CRC128 – maybe doesn’t exist?
Fred
From: Robinson, Herbie
Sent: Monday, November 13, 2023 2:25 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: RE: [Int-area] [EXTERNAL] Re: A new link s
Joel, I don't mind leaving the IEEE specs alone and allowing the receiver to
deliver errored
frames to upper layers along with a CRC error flag. The CRC error flag would
also make for
a good indication to the IP layer of when the IP addresses and port numbers
should be
checked for consistency so
You seem to be asking that every router in the Internet deliver frames
with bad Ethernet CRCs.(which may have bad destination addresses, since
routers do not check upper layer checksums) This is asking every router
and eveyr link to pay a significant in the hope that sometimes someone
may be a
Joel, I am asking this only for IP parcels and advanced jumbos over links that
support them natively.
When a router with a link that supports IP parcels and advanced jumbos natively
receives an
ethernet frame with bad CRC, it first checks to see if it is an IP
parcel/advanced jumbo. If so, the
r
Herbie, what in your opinion would be the more preferable solution – use MD5
for which standards
and implementations are widely deployed, or define new standards and
implementations for CRC128
where there is currently no deployment? I think SHA1 is overkill for what we
need, but open to other
op
I don’t really know of anything, but it’s not my area of expertise. CRC is
designed to be cheap and easy to implement in hardware that is dealing with a
serial bit stream. It is cumbersome to implement in software. MD5 is intended
for cryptographic use and it’s relatively slow to implement pe
Thank you for this – useful insights, and appreciated.
Fred
From: Robinson, Herbie
Sent: Monday, November 13, 2023 3:25 PM
To: Templin (US), Fred L
Cc: int-area@ietf.org
Subject: RE: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT emai
Fred,
MD5 is insecure, see RFC 9155 for the details.
Cheers,
Andy
On Mon, Nov 13, 2023 at 6:08 PM Templin (US), Fred L wrote:
> Herbie, what in your opinion would be the more preferable solution – use
> MD5 for which standards
>
> and implementations are widely deployed, or define new standar
On Mon, Nov 13, 2023, 6:01 PM Templin (US), Fred L wrote:
> Joel, I am asking this only for IP parcels and advanced jumbos over links
> that support them natively.
> When a router with a link that supports IP parcels and advanced jumbos
> natively receives an
> ethernet frame with bad CRC, it fir
Hi Fred,
I'm somewhat confused and it would be good to clearly formulate which
problem you are trying to solve (Hi Radia!).
Requiring to turn off checksumming of Ethernet Frames may be useful
for the particular _solution_ you propose, but this usually does not
apply to all links in the Internet.
22 matches
Mail list logo
