Subject: RE: [NSIS] framework: proposal on fragmentation

From: [email-masked]
Date: Thu, 5 Jun 2003 16:39:29 +0300

Hi Maarten,

I don't see the reason for being able to shut-off the fragmentation
either. Some examples would be nice.

John

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 05 June, 2003 15:36
> To: Hancock, Robert
> Cc: Georgios Karagiannis; [email-masked]
> Subject: RE: [NSIS] framework: proposal on fragmentation
> 
> 
> My question was mainly related to the fact whether it should be
> possible to 'switch off' the fragmentation functionality at the NTLP,
> which was proposed in the mail of Georgios. I am not sure whether
> this is really needed.
> Opinions?
> 
> regards,
> Maarten
> 
> 
> 
> 
> 
> "Hancock, Robert" <[email-masked]>@ietf.org on 05/06/2003
> 14:11:46
> 
> Sent by:    [email-masked]
> 
> 
> To:    Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis
>        <[email-masked]>
> cc:    [email-masked]
> Subject:    RE: [NSIS] framework: proposal on fragmentation
> 
> 
> Hi Maarten,
> 
> > Hi Georgios, Robert,
> >
> > I would agree as well on proposal 2, i.e. to locate
> > the fragmentation into the NTLP. I am not sure
> > however why there would be a need to be able to
> > disable that functionality. Do you have a particular
> > scenario in mind that requires this?
> 
> no comment!
> 
> >
> > Furthermore, would that exlude the use of TCP and
> > SCTP as a transport protocol?
> 
> that was not the intention - really the functionality I am 
> talking about
> is 'handle big messages' and TCP/SCTP are clearly able to do that. (it
> might
> not be called 'fragmentation' in those protocols but the function is
> there.)
> in any case, what protocol/fragmentation mechanism is used in the NTLP
> should
> be invisible to upper layers.
> 
> cheers,
> 
> r.
> 
> >
> > regards,
> > Maarten
> >
> >
> >
> >
> >
> > "Georgios Karagiannis" <[email-masked]>@ietf.org on 
> 05/06/2003
> > 13:56:47
> >
> > Sent by:    [email-masked]
> >
> >
> > To:    "Hancock, Robert" <[email-masked]>, 
> <[email-masked]>
> > cc:
> > Subject:    Re: [NSIS] framework: proposal on fragmentation
> >
> >
> > Hi Robert
> >
> > Regarding your proposal (2) - fragmentation in NTLP.
> >
> > I will agree with your proposal if it will be posiible to
> > also switch this
> > featureoff when needed.
> > For example, suppose that in a scenario the NTLP will have to
> > support only
> > one type of NSLP
> > that uses small message types. In this situation the NTLP
> > fragmentation
> > feature could be switched off,
> > i.e., not applied at all.
> >
> > Best Regards,
> > Georgios
> >
> >
> > ----- Original Message -----
> > From: "Hancock, Robert" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, June 05, 2003 12:38 PM
> > Subject: [NSIS] framework: proposal on fragmentation
> >
> >
> > > dear all,
> > >
> > > Since we all seem agreed that bundling should be in the 
> NTLP (and in
> > fact,
> > it
> > > already apparently is), here is the second open issue on
> > 'transport-like
> > > functions' and where they should go in the NTLP/NSLP layer model.
> > >
> > > This is the question of fragmentation, i.e. where to handle
> > the fact that
> > > [NSLP message + NTLP encapsulation] may be bigger than the
> > MTU on the
> > path
> > > to the next NxLP node.
> > >
> > > There seem to me to be 3 main options:
> > > 1. leave it up to the IP layer.
> > > 2. do it in the NTLP.
> > > 3. do it (if needed) in the NSLP.
> > > My proposal is basically (2). Read no further if you agree...
> > >
> > > cheers,
> > >
> > > robert h.
> > >
> > >
> > ==============================================================
> > =============
> > > Here is the background:
> > >
> > > This issue is not handled in 2961 but discussed as a
> > potential problem
> > there;
> > > there is also some analysis in 
> draft-pan-nsis-rsvp-transport-01.txt
> > (section 2.3). There has been some discussion of this in the
> > past on this
> > mailing list, but I
> > > couldn't really detect an agreed conclusion to it. I have
> > tried to take
> > it
> > into
> > > account in this summary.
> > >
> > > The situation at the moment is that 'most' RSVP messages
> > are 'small', and
> > > this only tends not to be so in the case that it is used
> > over links where
> > > the MTU can be made large (9k is common for ATM/FR for 
> example). We
> > expect
> > that
> > > this will change in the future - i.e. *some* signalling
> > applications will
> > generate
> > > big messages (as we add more security credentials for
> > example), and we
> > don't want
> > > to restrict the range of link types that can be used.
> > >
> > > Reasoning about the choices:
> > >
> > > 1. Doing it in the IP layer is conceivable but probably
> > wouldn't work
> > well
> > for
> > > some awkward reasons, for example...
> > > a) IP fragmentation doesn't mix well with implicit 
> addressing + the
> > router
> > alert
> > > option (Ping pointed this out at the interim). [I can't
> > decide if this is
> > an
> > > implementation issue or specification issue, but it
> > certainly seems to be
> > an
> > > issue.]
> > > b) If NSIS messages use flow source addresses (like RSVP),
> > they would
> > have
> > > to make up their own IP-ID/fragmentation headers
> > independently of the
> > real
> > source
> > > node. This could lead to (theoretical) misassembly errors.
> > > c) We are trying (hard/a bit) to make NSIS NAT-friendly.
> > Relying on IP
> > layer
> > > fragmentation probably won't make this easier. (If you
> > demand every NAT
> > is
> > at least
> > > NTLP aware, maybe you are OK.)
> > > d) IP fragmentation increases the underlying message loss
> > rate (which
> > then
> > has to
> > > be recovered from).
> > >
> > > Maybe none of these are killing issues.
> > >
> > > 2. Doing it in the NTLP is a challenge for the NTLP designers...
> > > a) Only the NTLP knows its encapsulation overhead and so
> > how to split up
> > the
> > > NSLP messages.
> > > b) The best efficiency would gained from using some sort of
> > PMTU-d, and I
> > suspect
> > > only the NTLP can do this, since it controls IP layer
> > addressing and sees
> > the
> > > ICMP messages involved. It also knows when routes change
> > and rediscovery
> > is
> > > needed. (And PMTU-d would be useful anyway in the NTLP to
> > do bundling
> > best.)
> > > c) Fragmentation could be restricted to the particular 
> NTLP hop that
> > needs
> > it
> > > rather than doing it everywhere.
> > >
> > > I think the main objection to doing it in the NTLP is that it's a
> > function
> > that
> > > not many applications/scenarios 'really' need, and we are
> > overloading the
> > common
> > > component for a minority interest. We can't really evaluate
> > that argument
> > without
> > > seeing how difficult it is (currently, I am not convinced
> > by it). Also,
> > doing
> > > fragmentation without the ability to retransmit lost
> > fragments strikes me
> > as a bad
> > > thing, but since the current NTLP proposal has some form of
> > reliability
> > in
> > it
> > > this isn't relevant.
> > >
> > > 3. You can only do it in the NSLP if the NSLP knows what
> > fragment size to
> > use.
> > > As pointed out above, it doesn't, since there may be more
> > than one NTLP
> > hop to
> > > the next NSLP-aware node. (In theory, you could write an
> > NSIS signalling
> > > application - which used only small messages! - to discover this
> > information
> > > over the path and then use that. This strikes me as a interesting
> > theoretical
> > > possibility, but unlikely to lead to good results in practice.)
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> >  https://www1.ietf.org/mailman/listinfo/nsis
> >
> >
> >
> >
> _______________________________________________
> nsis mailing list
> [email-masked]
>  https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> 
> _______________________________________________
> 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, 5 Jun 2003 15:56:55 +0200

Hi John and Maarten

First of all if a message is fragmented has to be reassembled somewhere.
The NTLP will have to find out where the fragmentation and the reassembly
process has to be
accomplished. This will require additional processing, even if this it is
not needed.
In scenarios where performance in terms of processing delays, number of
states per flow, etc.,
is important, it should be possible that the fragmentation at NTLP layer
should be switched off and
either assure that the NSLP messages are small enough such that they will
not be fragmented
or do it in the NSLP if required.

Best Regards,
Georgios

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Jun 2003 11:10:02 -0400

There are only two possibilities for point of reassembly: after every NTLP hop, or 
where the message is being delivered to NSLP.  The latter is complicated by the 
possibility that one NTLP message may contain multiple NSLP messages.  On the other 
hand, it seems like a waste to reassemble messages hop by hop, only to break them 
down again for the next hop.  Of course, doing this means that lost fragments can be 
retrieved on a per hop basis rather than involving more nodes.

In any event, I expect Georgios is concerned that the receiving node has to execute 
logic checking for fragmentation for every packet received, even if fragmentation 
can't happen in that particular application.  If the reason fragmentation won't 
happen is a big MTU, I can almost follow his argument.  If the reason fragmentation 
won't happen is the particular NSLP, I don't buy the argument, because the other 
NSLPs may also be bundled in.

> or do it in the NSLP if required.
[snip]