On 1 okt 2008, at 16:29, Templin, Fred L wrote:
We don't want segmentation/reassembly as a steady-state
condition; we only want it to bridge the gap between
what we have today and a future jumbo-clean Internet.
Unfortunately, things don't always work out that way. If you create
two ways to
Tony,
Obviously you can optimize, but even a naïve implementation
has to have a bound on the number of reassemblies that it can
have in progress at any given time. Again a trivial
implementation is to provide a max sized buffer for each such
reassembly.
A Linux box is a far cry from a
-Original Message-
From: Stephen Sprunk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 4:15 PM
To: [EMAIL PROTECTED]
Cc: Routing RG
Subject: Re: [RRG] A data point on transit MTU size
Tony Li wrote:
|The code for reassembly isn't hard, it's allocating the buffers
|The code for reassembly isn't hard, it's allocating the buffers to
|store the arrived fragments. That's nearly impossible in hardware.
Patently nonsense. Packet reassembly in hardware is very much
straightforward if one is willing to burn large buffers to do so. Imagine
taking an
Patently nonsense. Packet reassembly in hardware is very much
straightforward if one is willing to burn large buffers to do so.
Imagine
The willing part is the impossible part.
taking an implemention in C and simply converting it to Verilog.
Not at all
out of the question.
It
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 12:56 AM
To: [EMAIL PROTECTED]
Cc: 'Brian E Carpenter'; Templin, Fred L; 'RRG'
Subject: Re: [RRG] A data point on transit MTU size
Patently nonsense. Packet reassembly in hardware
Hi Fred, Dino,
| Patently nonsense. Packet reassembly in hardware is very much
| straightforward if one is willing to burn large buffers to do so.
| Imagine
|
|The willing part is the impossible part.
Well, that sounds like a personal problem. ;-)
|I'm not convinced as to how large the
Tony Li wrote:
|The code for reassembly isn't hard, it's allocating the buffers to
|store the arrived fragments. That's nearly impossible in hardware.
Patently nonsense. Packet reassembly in hardware is very much straightforward
if one is willing to burn large buffers to do so. Imagine
Dino,
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 3:13 PM
To: Brian E Carpenter
Cc: RRG
Subject: Re: [RRG] A data point on transit MTU size
We've argued here about whether it's reasonable to assume 1500 byte
MTU on transit links
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 3:13 PM
To: Brian E Carpenter
Cc: RRG
Subject: Re: [RRG] A data point on transit MTU size
We've argued here about whether it's reasonable to assume 1500 byte
MTU on transit links, when
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:11 AM
To: Templin, Fred L
Cc: Brian E Carpenter; RRG
Subject: Re: [RRG] A data point on transit MTU size
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED
On 22 sep 2008, at 23:49, Brian E Carpenter wrote:
We've argued here about whether it's reasonable to assume 1500 byte
MTU on transit links, when running a LISP-type solution.
Here's a data point about the real world, as far as Internet exchange
points at the southern end go:
Fred,
On 2008-09-24 03:25, Templin, Fred L wrote:
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:11 AM
To: Templin, Fred L
Cc: Brian E Carpenter; RRG
Subject: Re: [RRG] A data point on transit MTU size
-Original
Yes, we agree that sub-optimal implementations are a bad idea.
We also agree, I trust, that writing perfect reassembly code
is fairly hard (although I speak from 20 year old experience).
In particular the RFC 4459 and 4963 issues have to be handled.
I don't have an opinion whether SEAL is
Dino,
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 2:53 PM
To: Brian E Carpenter
Cc: Templin, Fred L; RRG
Subject: Re: [RRG] A data point on transit MTU size
Yes, we agree that sub-optimal implementations are a bad idea.
We also
We've argued here about whether it's reasonable to assume 1500 byte
MTU on transit links, when running a LISP-type solution.
And if the assumption doesn't hold, then you fragment before
encapsulate. That is specified in the main LISP spec.
Dino
Here's a data point about the real world, as
16 matches
Mail list logo
