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

From: "Daniel Warren" <[email-masked]>
Date: Thu, 5 Jun 2003 15:05:17 +0100

From Georgios's mail...

'I will agree with your proposal if it will be posiible to also switch this
feature off 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'

Is it just me or is the ability to 'switch fragmentation off' a bit of a
spurreous debate?  If a NSLP message plus NTLP 'stuff' is smaller than the
MTU, then you don't fragment it, if it's bigger you do.  Thats not switching
it off so much as having it on but not needing to apply it.   I guess it all
depends how small the 'small message types' are...

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 05 June 2003 13: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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 5 Jun 2003 16:18:49 +0200

RE: [NSIS] framework: proposal on fragmentationHi Daniel

What I meant is that the fragmentation at NTLP layer should be optional and not mandatory.

Best regards,
Georgios
  ----- Original Message ----- 
  From: Daniel Warren 
  To: [email-masked]' ; Hancock, Robert 
  Cc: Georgios Karagiannis ; [email-masked] 
  Sent: Thursday, June 05, 2003 4:05 PM
  Subject: RE: [NSIS] framework: proposal on fragmentation

  From Georgios's mail... 

  'I will agree with your proposal if it will be posiible to also switch this feature off 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'

  Is it just me or is the ability to 'switch fragmentation off' a bit of a spurreous debate?  If a NSLP message plus NTLP 'stuff' is smaller than the MTU, then you don't fragment it, if it's bigger you do.  Thats not switching it off so much as having it on but not needing to apply it.   I guess it all depends how small the 'small message types' are...

  Dan 

  -----Original Message----- 
  From: [email-masked] [mailto:[email-masked]] 
  Sent: 05 June 2003 13:36 
  To: Hancock, Robert 
  Cc: Georgios Karagiannis; [email-masked] 
  Subject: RE: [NSIS] framework: proposal on fragmentation 

  regards, 
  Maarten 

  Hi Maarten, 

  no comment! 

  cheers, 

  r.