Subject: RE: [NSIS] attempted summary of fragmentation discussion

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Jun 2003 12:50:44 +0100

hi georgios,

how and why?

i.e. it would be helpful (at least to me) if you could
a) define (4) in a bit more detail about how the layers and nodes would
interact to achieve it, and
b) explain why this functionality would justify the additional complexity.

cheers,

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 12 June 2003 12:37
> To: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] attempted summary of fragmentation discussion
> 
> 
> Hi Robert
> 
> Please combine (3) and (4) in a more strict way!
> 
> Best regards,
> Georgios
> ----- Original Message -----
> From: "Hancock, Robert" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, June 12, 2003 11:21 AM
> Subject: [NSIS] attempted summary of fragmentation discussion
> 
> 
> > dear all,
> >
> > in attempting to summarise where we are so far, this is 
> what i think the
> > situation is:
> >
> > 1) no-one really likes relying on IP fragmentation
> > 2) no-one wants to force all responsibility into the NSLPs
> > 3) everyone [almost?] is happy with the NTLP doing 
> fragmentation as a
> > default
> > 4) there is a proposal to make it possible to signal the 
> NTLP not to do
> > fragmentation and have the NSLP do it (in some 
> still-to-be-defined way)
> >
> > personally, i fail to see the benefit of (4) over (3), 
> which may be a
> > symptom of a deeper problem (with me or the proposal).
> >
> > however, i believe it is not ruled out even if we used as an initial
> > position:
> > *) make the NTLP do fragmentation when it is needed; 
> ideally, do it in
> such
> > a way that reassembly is only needed at the receiving NSLP.
> >
> > in later stages of the protocol work, and after some experience with
> > applications, we could presumably "enhance" the NTLP in the 
> direction of
> > option 4, i.e. give it the ability not to do fragmentation 
> as well. after
> > all, this would appear to be an intrinsically backwards compatible
> > extension.
> >
> > have i missed anything?
> >
> > robert h.
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 12 Jun 2003 14:02:58 +0200

Hi Robert

I proposed many solutions to this in previous e-mails.
The main advantage of having this feature is that the performance of the
node in terms of processing delays will be enhanced
when the node does not have to perform fragmentation.

Best regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Georgios Karagiannis'" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 12, 2003 1:50 PM
Subject: RE: [NSIS] attempted summary of fragmentation discussion

> --
> Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and any attachments is
confidential to
> Roke Manor Research Ltd and must not be passed to any third party without
> permission. This communication is for information only and shall not
create or
> change any contractual relationship.
>

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 12 Jun 2003 14:14:59 +0200

I think a possible way is as in v4 set the Don't fragment bit. If 
fragmentation occurs get an error back. It would be the task of the NSLP to 
detect the possible MTU size.

What I have not hear so far is the cost of having fragmentation built into 
NTLP. Georgios and myself are concerned that the NTLP gets too fat for 
high-speed processing, so we try to avoid to design for the rare cases such 
as fragmentation.

Marcus

>> > all, this would appear to be an intrinsically backwards compatible

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
Mobile: +49 (0) 163 275 17 43
personal home page: http://www.brubers.org/marcus

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Jun 2003 12:15:42 -0400

> What I have not hear so far is the cost of having
> fragmentation built into NTLP. Georgios and myself are
> concerned that the NTLP gets too fat for high-speed
> processing, so we try to avoid to design for the rare
> cases such as fragmentation.

Obviously we don't want to allow IP to fragment the packets,
since this will remove our ability to support middlebox
traversal.  That means that either we don't allow any
fragmentation or we handle fragmentation ourselves.  If we
handle fragmentation ourselves it's pretty clear that it
needs to be handled lower in the stack rather than higher in
the stack, primarily because we need to know the entire
packet size in order to make correct fragmentation
decisions.  "Entire packet size" may include bundling but
will certainly include authentication-related data, which
can be quite large.  Additionally there may be other TLVs
in the header (for example, related to reliable delivery)
that the upper layers will not know about and therefore not
be able to factor into a fragmentation decision.

Adding support for fragmentation will certainly increase the
code load, which may be an issue in memory-constrained
devices, but it will not meaningfully lengthen the execution
path since it's a quick check to see if you need to fragment
(if packet_length > pmtu) on the sender side and a quick
check to see if reassembly is required (if (frag_bit_is_set)) 
on the receiver side.  Path MTU will need to be determined
regardless of where fragmentation occurs and is a constant
cost unless there's a decision not to fragment at all, which
brings with it its own costs (and, for that matter, will
require PMTU discovery as well).

Melinda

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 13 Jun 2003 09:48:43 +0200

--On Donnerstag, 12. Juni 2003 12:15 -0400 Melinda Shore <[email-masked]> 
wrote:

> traversal.

I do not see how NSIS is able to pass through a standard NAT and still work 
correctly. I think there needs to be an NSIS specific adaption of the NAT 
anyway.

> That means that either we don't allow any
> decisions.

RFC 2205 proposes for the future the notion of semantic fragmentation, 
which means that it must be higher in the stack, because the high you are 
the more you know about the semantic.

     "The most likely direction will
      be to perform "semantic fragmentation", i.e., break the path or
      reservation state being transmitted into multiple self-contained
      messages, each of an acceptable size."

Marcus

---

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Jun 2003 17:10:12 -0400

> Does PMTU (re)discovery always have to be from 
> end host to end host?

What's an "end host" in this context?

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Fri, 13 Jun 2003 14:14:28 -0700 (PDT)

> What's an "end host" in this context?

The host at which the reservation is turned
around?  Ie, the thing that takes a PATH and
generates a RESV.

	    Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 13 Jun 2003 14:04:50 -0700 (PDT)

Mike