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

From: [email-masked]
Date: Thu, 5 Jun 2003 14:58:43 +0300

Hi Robert,

> 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...

If we want NTLP to run over IPv6, I suppose we would like to handle
it at the NTLP layer.

John
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Thu, 5 Jun 2003 14:07:49 +0200

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?

Furthermore, would that exlude the use of TCP and
SCTP as a transport protocol?

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
> 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.)

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 5 Jun 2003 13:11:46 +0100

Hi Maarten,

> scenario in mind that requires this?

no comment!

> 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.

> MTU on the

---

From: [email-masked]
Date: Thu, 5 Jun 2003 14:36:04 +0200

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

To:    Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis
       <[email-masked]>
cc:    [email-masked]
Subject:    RE: [NSIS] framework: proposal on fragmentation

Hi Maarten,

no comment!

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.

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 5 Jun 2003 15:07:35 +0100

Georgios,

I don't really follow the argument. if an NSLP generates a small message, 
it won't need to be fragmented anywhere. what is the cost? if it generates a

big message, why is it easier to do it at the upper layer.
[In other words, I agree with Dan's email, just received.]

I think the only cost here is implementation effort in the NTLP - but it
should
be possible to implement fragmentation support so if it isn't needed it has
(effectively) no performance impact. And in fact, the implementation effort
to
provide the feature might be less than what's needed to handle the resultant

error cases properly...

robert h.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 05 June 2003 14:57
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 05, 2003 3:39 PM
> > 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]

---

From: [email-masked]
Date: Thu, 5 Jun 2003 16:37:13 +0200

Hi Georgios,

If we decide to make the fragentation mandatory for an NTLP
implementation why should we make the use of it optional?

If it is implemented it will not put a performance burden in case
the message does not need fragmentation as mentioned in
the previous e-mails of Daniel and Robert. So it seems
that both the implementation and the use of fragmentation should
be mandatory.

regards,
Maarten

16:18:49

To:    "Daniel Warren" <[email-masked]>
cc:    <[email-masked]>
Subject:    Re: [NSIS] framework: proposal on fragmentation

Hi 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.

> mailing list, but

---

From: [email-masked]
Date: Fri, 6 Jun 2003 09:52:32 +0200

Hi,

Functionality and use of e.g. message bundeling should be transparent
to the NSLP layer. I do not see any benefit in making the NSLP
aware of e.g. bundling. It seems to me that these are local
decisions of the NTLP layer.

Maarten

"Lars.Westberg" <[email-masked]>@ietf.org on 06/06/2003
09:32:02

To:    Tom Taylor <[email-masked]>
cc:    Georgios Karagiannis <[email-masked]>, "Hancock, Robert"
       <[email-masked]>, [email-masked]
Subject:    Re: [NSIS] framework: proposal on fragmentation

Isn't the functionality in NTLP dependent on NSLP. If a certain NSLP do not
want to
have
bundling and fragementation. Should that not be supported by NTLP ?

The selection of NTLP-functionality may be coupled to a certain NSLP-type.
In that case you I think that you do not need to have negotiation between
different
NTLP-instances or.. ?

regards Lasse
Tom Taylor wrote:

> Optionality doesn't work unless it is negotiated, which makes the
protocol a lot
> more complicated.  I can say my node doesn't support bundling, but what
if the
> upstream node won't cooperate and sends me a bundled message?
>
> Georgios Karagiannis wrote:
>
> > Hi Robert
> >
> >
> >>FWIW I had assumed that reassembly would probably take place at
> >>each NSIS-aware node. Apart from anything else, an NSIS-aware node
> >>probably couldn't work out what to do with a fragment (either whether
> >>to deliver it locally to an application or forward it, and if so even
> >>who to forward it to) without doing the reassembly.
> >
> >
> > Yes, but this is additional fragmentation/reassembly functionality that
will
> > require  additional
> > processing, thus the performance behaviour of a node could be affected.
> >
> > Now if nodes do not support NTLP bundling and if the NSLP is designed
in
> > such a way that
> > NTLP fragmentation is not needed,  then the NTLP reassembly
functionality,
> > mentioned above, even if it is not needed, will affect negativelly the
> > performance behaviour of the node.
> >
> > What I am actually proposing is that any NSLP should be able to specify
if
> > NTLP fragmentation/reassembly must be
> > supported or not!
> > Therefore, I am proposing that the NTLP fragmentation/reassembly
feature
> > should be optional.

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 6 Jun 2003 08:55:15 +0100

georgios,

i think the answer to your question would be provided by adopting
the alternative fragmentation strategy in my email, which i'll
reproduce here (since you deleted it): 
"...you could also put enough data in each 
fragment to make them independently forwardable; that could be a
Good Thing." - so in other words, reassembly takes place only
where (at whatever node) it is needed by the application, and we are 
just talking about which layer to do it in.

It would probably be sensible in this case to make a (not unreasonable)
design decision that an NTLP instance shouldn't fragment a bundled message,
it should unbundle it first. But these are all points about designing
an efficient NTLP, they don't affect the definition of the layer split.
As Maarten has just pointed out, the NSLP shouldn't even be aware that
bundling is taking place, and I'd like the same to apply to fragmentation
also.

cheers,

r.

> Sent: 05 June 2003 17:41
> Yes, but this is additional fragmentation/reassembly 
> functionality that will
> require  additional
> Now if nodes do not support NTLP bundling and if the NSLP is 
> designed in
> such a way that
> What I am actually proposing is that any NSLP should be able 
> to specify if
> Therefore, I am proposing that the NTLP 
> fragmentation/reassembly feature
> should be optional.
> 
> Best regards,
> Georgios
>

---

From: [email-masked]
Date: Fri, 6 Jun 2003 18:41:40 +0300

Hi all,

> > Use IP-fragmentation
> 
> IP fragmentation is a problem for NATs.  That's a problem
> for a discovery (addressed end-to-end) message, which in
> turn is a problem for us if we wish to support a middlebox
> application.

Agreed. Also, handling fragmentation does not imply a connection-oriented
protocol.

John

---

From: [email-masked]
Date: Fri, 6 Jun 2003 19:01:00 +0300

Lars,

> The generality of NTLP is a difficutl issue. My point is that I can
> forsee application that is so simple that an UDP-style of operation is good enough.

Some aspects of UDP may be sufficient for NTLP, but there are well known 
problems of UDP-based protocols transiting middleboxes, so we should try
to limit such problems.  Fragmentation is one well known one. 

A possible solution could be a NTLP running over UDP, where NTLP
did the fragmentation.  

John

---

From: [email-masked]
Date: Fri, 6 Jun 2003 19:10:53 +0300

Hi Lasse,

> My proposal is that we trying to develop two modes of NTLP-operation:
> 
> - RSVPover SCTP
> - RSVPoverUDP

This is not relevant to the framework, I think.  I think the framework
should not be specifying the transport protocol, but rather the NTLP
document.

thanks,
John

---

From: [email-masked]
Date: Tue, 10 Jun 2003 10:53:59 +0200

During the last meeting it has been decided to use 2205 and
2961 as a starting point for the NTLP work. This allows for
raw IP and UDP as transport protocols. However, as you
mentioned, about the use of other (connection oriented)
transport protocols no decision was taken either way.

2961 adds congestion control and reliable delivery functionality
to RSVP. However, the authors have indicated that there
is room for improvement. Connection oriented transport
protocols can provide the functionality as well. This will
allow for reusing existing protocols.
Hence, we support to allow for connection oriented transport
protocols like TCP.

kind regards,
Maarten

Melinda Shore <[email-masked]>@ietf.org on 06/06/2003 17:27:13

To:    "Lars.Westberg" <[email-masked]>
cc:    "Geib, Ruediger" <[email-masked]>, [email-masked]
Subject:    Re: [NSIS] framework: proposal on fragmentation

> I would recommend that we have two modes of operation in mind:
> RSVPoverSCTP
> RSVPover UDP

We reached an agreement at the last meeting, confirmed on
the mailing list, that we'd run over a connectionless
protocol - that we would gut 2205 and 2961 and use that as
the basis for an NTLP.  If you go back and look at John's
slides from the meeting there was no agreement even to make
a connection-oriented protocol available as an option (that
is to say, no decision was made either way).  One of the
things that's killing progress in a number of IETF working
groups is the unfortunate tendency to want to go back and
revisit and revisit and revisit and revisit decisions that
we don't agree with.  We need to put a stop to that.

That said, I think that we can almost certainly put an NTLP
over a connection-oriented protocol, but that we do not want
to do this in the baseline.  Unless there's new information
today that wasn't available in March, however, revisiting
the decision that was made then seems like an incredibly bad
idea.

Melinda

---

From: "Attila Bader (ETH)" <[email-masked]>
Date: Tue, 10 Jun 2003 10:59:10 +0200

Hi Robert,

Please consider the following: 

Considering current applications and RFCs 2205 and 2961 as bases, fragmentation is needed for bundling in practice. Since bundling is reasonable to do by NTLP, NTLP should be responsible for fragmentation of bundle messages.

If a future NSLP produces large MTUs, it can be defragmented by that NSLP, or by IP. 

So my proposal for fragmentation is 

NTLP for Bundle Message 
NSLP+IP for future NSLP functions

Best regards,  Attila Bader

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hancock, Robert
> Sent: Friday, June 06, 2003 5:43 PM
> To: 'Lars.Westberg'
> Cc: Tom Taylor; Georgios Karagiannis; [email-masked]
> OK - this was option 1 in the original email summary. There seemed to
> be some resistance to it from several places and a preference to the
> NTLP approach.
> 
> What I can imagine you suggesting is: try to get the NSLP to 
> create messages
> which don't require fragmentation at all (by doing the fragmentation
> itself); 
> in the [hopefully rare] cases where something goes wrong, 
> rely on the IP 
> layer to handle it.
> 
> That's an approach - I think it's a much more credible approach than 
> relying on the NSLP alone, but given the unpleasantness about 
> doing it 
> at either IP or NSLP, I still prefer the NTLP option. Anyway, people 
> need to make the argument about which is better and why:
> IP only
> NTLP only
> NSLP only
> IP+NSLP
> 
> The other point is: since we are arguing about the 
> fragmentation aspect
> (rather than the reassembly aspect) .... just how difficult is it to 
> chop up a message and put a common header on each part? And how much
> complexity is
> it worth putting in the rest of the network architecture to 
> save doing it?
> 
> cheers,
> 
> r.
> 
> > From: Lars.Westberg [mailto:[email-masked]]
> > Sent: 06 June 2003 16:27
> > To: Hancock, Robert
> > Cc: Tom Taylor; Georgios Karagiannis; [email-masked]
> > -lasse
> > "Hancock, Robert" wrote:
> > > aha!
> > > > No, I trying to explain it:
> > > > If you have a network element without knowledge of the NSLP:s
> > > > requirment, the
> > > > default should be to forward it to the next hop without doing
> > > > anything to the
> > > > NSLP-messages.
> > >
> > > *** and what if the message is too big to forward? ***
> > > [which is where we started...]
> > >
> > > >
> > > > regards Lasse
> > > >
> > >
> > > r.
> > >
> > >   
> > --------------------------------------------------------------
> > ----------
> > >                           Name: RMRL-Disclaimer.txt
> > >    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
> > >                       Encoding: 7bit
> >

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 10 Jun 2003 11:18:32 -0400

Georgios,

I think it is a very reasonable proposal. It means that every NTLP
implementation must support fragmentation in the following manner: optional
to fragment those messages that do have "Do Fragmentation" flag set but
mandatory to re-assembled already fragmented messages.

Regards,
Ilya

 -----Original Message-----
From: 	Georgios Karagiannis [mailto:[email-masked]] 
Sent:	Tuesday, June 10, 2003 10:35 AM
To:	Hancock, Robert
Cc:	[email-masked]
Subject:	Re: [NSIS] framework: proposal on fragmentation

Hi Robert

What I actually propose is that when the NSLP is not in favour of NTLP
fragmentation,
then the NTLP should not do fragmentation. If the NSLP activates the
"Do Fragmentation" bit then the NTLP is allowed to do fragmentation.
Otherwise if the NSLP switches off the "Do Fragmentation" bit then the
NTLP will not do fragmentation. Please note that in this situation the NSLP
is
aware of the fragmentation issues and it will either rely on the IP
fragmentation
or try to solve the fragmentation issues by its own.

Best Regards,
Georgios

----- Original Message -----
From: "Hancock, Robert" <[email-masked]>
To: "'Georgios Karagiannis'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 10, 2003 3:51 PM
Subject: RE: [NSIS] framework: proposal on fragmentation

> indeed.
>
> however, even 576 doesn't guarantee that fragmentation won't be needed
> (for IPv4 the MTU could be as low as 68), and in any case, you also have
to
> take out the NTLP encapsulation overhead.
>
> doing unnecessary fragmentation as the NSLP will increase network load,
> because you have more more messages. i suppose you could allow the NTLP to
bundle
> the fragments back together [i did originally consider this option but
> discarded it as just too ugly to propose] but the result would still be
> bigger than the original could have been, especially if the per-fragment
overhead
> is large.
>
> i still don't see this as preferable to having the NTLP able to chop up
messages.
> why is that so hard????
> > Sent: 10 June 2003 13:25
> > > ok, so [i think] you propose that there should be an
> > minimum size NSLP
> > > message that all NTLP instances should be able to transmit
> > (presumably,
> > > regardless of IP version or whatever encapsulation the NTLP
> > itself adds,
> > to
> > > avoid the need to discover things dynamically). anything
> > bigger, the NSLP
> > > itself must fragment before providing it to the NTLP.
> > > would you like to make a suggestion for how big that number
> > should be?
> > >
> >
> > For example, look into Section 4.2.2.7 of RFC 1812:
> >     " A common trick used by some implementations of TCP/IP is to
> >       fragment an IP datagram into IP fragments that are no
> > larger than
> >       576 bytes when the IP datagram is to travel through a router.
> >       This is intended to allow the resulting IP fragments to pass the
> >       rest of the path without further fragmentation. " ,
> > from RFC1812.
> >
> > Best regards,
> > Georgios
> >
> > >
> > > > Sent: 10 June 2003 11:41
> > > > The NTLP should be able to transport a message with a
> > > > minimum MTU without  fragmenting it.
> > > >
> > > > Best Regards,
> > > > Georgios
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To: "'Georgios Karagiannis'" <[email-masked]>;
> > > > "'Lars.Westberg'"
> > > > <[email-masked]>
> > > > Cc: <[email-masked]>
> > > > Sent: Tuesday, June 10, 2003 10:59 AM
> > > > > in your solution, what happens when an NTLP node gets a
> > > > too-big message
> > > > > with DF set?
> > > > >
> > > > > r.
> > > > >
> > > > > > Sent: 10 June 2003 08:50
> > > > > > To: Hancock, Robert; 'Lars.Westberg'
> > > > > > Cc: [email-masked]
> > > > > > What I actually propose is to enhance the flexibility of
> > > > > > the NTLP protocol by giving the ability to a NSLP to
> > > > > > request or not to request the NTLP fragmentation feature.
> > > > > > A possible method of doing this is as follows:
> > > > > >
> > > > > > First of all the NTLP protocol has to use some
> > > > information, e.g., a
> > > > > > fragmentation bit, to specify that
> > > > > > fragmentation is allowed or not.
> > > > > > Now, if the sender NSLP (NI) informs its NTLP instance to
> > > > > > switch off the
> > > > > > fragmentation, then this NTLP instance
> > > > > > will switch off the fragmentation bit. In this way all the
> > > > > > intermediate NTLP
> > > > > > nodes will know that fragmentation is
> > > > > > not allowed.
> > > > > > Note that in this case NTLP negotiation is not needed!
> > > > > >
> > > > > > Best regards,
> > > > > > Georgios
> > > > > >
> > > > > >
> > > > > > To: "'Lars.Westberg'" <[email-masked]>
> > > > > > Cc: "Tom Taylor" <[email-masked]>; "Georgios
> > > > Karagiannis"
> > > > > > <[email-masked]>; <[email-masked]>
> > > > > > Sent: Friday, June 06, 2003 5:42 PM
> > > > > > > What I can imagine you suggesting is: try to get the
> > > > NSLP to create
> > > > > > messages
> > > > > > > relying on the NSLP alone, but given the unpleasantness
> > > > > > about doing it

---

From: [email-masked]
Date: Wed, 11 Jun 2003 11:29:43 +0200

Hi all,

I fully agree with Robert. I cannot see any relevance of a fragmentation
bit
either. Dropping messages because they are too large and have
the 'do not fragment' bit set does not seem a nice approach to me. Indeed,
as pointed out by Robert this will lead to unnecessary error conditions,
which should be avoided in my opinion.

regards,
Maarten

"Hancock, Robert" <[email-masked]>@ietf.org on 11/06/2003
10:42:33

To:    "'Thanh Tra LUU'" <[email-masked]>, Tom Taylor
       <[email-masked]>, Georgios Karagiannis
       <[email-masked]>
cc:    [email-masked]
Subject:    RE: [NSIS] framework: proposal on fragmentation

dear all,

what i am missing at the moment is a complete picture of how this 'optional
fragmentation scheme' (or schemes?) would really work in practice,
including
(as Tom says) what really happens to too-big non-fragmentable messages
(generate
an error and route it back to the originating NSLP? fragment at IP level?)
and
so on.

since this scheme still has the fragmentation functionality in the NTLP,
i'm
struggling (i'm trying, but i'm really struggling) to see how it is more
attractive
than just saying 'the NTLP does the fragmentation if it needs to'. my
expectation
would be that all NSLPs would set 'fragmentation allowed' on their
messages,

because the NSLP designer can't see any benefit in creating an extra error
case
to handle and doesn't want to invent his own PMTU-like discovery
mechanisms.
in
that case it reduces in practice to the previous case anyway, while
polluting the
protocol with more error conditions and optional parts.

cheers,

r.

> From: Thanh Tra LUU [mailto:[email-masked]]
> Sent: 11 June 2003 09:07
> To: Tom Taylor; Georgios Karagiannis
> Cc: [email-masked]
> hi Tom,
> I think we can do as you said that a next NTLP uses a
> notification of  error
> (like ICMP). When  a NTLP receives this notification, it
> notifies NSLP to
> reduce the NSLP message's length. So NSLP must be able to fragment its
> messages.
>
> Georgios said that NSLP message's length is too small to need
> fragmenting by
> NTLP so this function can be switched off, but how NSLP can know its
> message's length is small enough to not need fragmenting ?
>
> I don't think NTLP notifies NSLP about the max length is a
> good way. Because
> it looks like PMTU mechanism, so I think we let NTLP does it
> all. NTLP can
> set the bit "Don't Fragement" or not (for some useful
> purposes of NTLP), but
> it must do it by itself and this is opaque to NSLP.
>
>
> Nary Tra
> ENST, Paris
>
>
>
> From: "Tom Taylor" <[email-masked]>
> To: "Georgios Karagiannis" <[email-masked]>
> Cc: "Hancock, Robert" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, June 10, 2003 10:32 PM
> > You haven't answered Robert's earlier question: what happens if an
> intermediate NTLP
> > node receives a "don't fragment" message which is too big
> to pass on.  The
> obvious
> > treatment is to drop the message.  Must the intermediate
> NTLP node also
> send a
> > message back indicating that the forward message was dropped.
> >
> > > NTLP will not do fragmentation. Please note that in this
> situation the
> NSLP
> > > is

---

From: [email-masked]
Date: Thu, 12 Jun 2003 07:07:05 +0300

Hi Michael,

This is what should be, in general, captured in the 
framework, i.e. - the big picture.

John
> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: 11 June, 2003 20:28
> To: Lars.Westberg
> Cc: Geib, Ruediger; [email-masked]
> Lars.Westberg writes:
>  > forsee application that is so simple
>  > that an UDP-style of operation is good enough.
> 
> []
> 
> I really think it might be useful to take a more
> systemic look at things on all of these
> discussions. That is, what are we trying to use
> NSIS for, and what are the design constraints in
> that system. In isolation the notion of UDP-based
> communication is good since you don't need hard
> state, blah, blah, blah. My personal acid test is
> in the realm of mobility and handoffs: could an
> NSIS be used to gain favorable treatment of
> packets on a lossy and insecure medium where fast
> handoffs are necessary to keep connectivity?
> 
> The two principle things that come to my mind are:
> 
> 1) Security -- rationing a scarce resource
> 2) Speed -- completing the allocation in a timely
>             fashion so as to be useful
> 
> If either of these conditions are not met, then
> NSIS is likely to not be used, opting instead for
> the time-honored tradition of brute force and
> ignorance, or used in a way such that the setup
> time is not in the critical path. 
> 
> In this particular scenario, connectionless
> transport doesn't tell the whole story; the desire
> to have a command/response kind of 2 message
> protocol (on the first hop, that is) is an obvious
> win over needing to first need to create a
> session, but the access control aspect of (1) is a
> significant consideration as well. In particular,
> identity credentials have a tendency to be large,
> and CPU complexity especially for public key
> operations tends to be high. Both considerations
> push you in the direction of creating hard state
> of some kind (cf IKE main mode, TCP). At the very
> least, it's fairly obvious that any underlying
> transport which wants to use X.509 type identities
> is going to have to deal with the message
> fragmentation problem, and frankly IP-layer
> fragmentation is just a non-starter, IMO, if
> that's the norm.
> 
> So in at least some of the interesting cases we
> know that we won't be able to have our coveted
> command/response protocol (assuming the MTU-pixie
> doesn't wave its wand over the Internet): three or
> more messages may be necessary.
> 
> Which leads us to the next questions:
> 
> 1) how interesting is this case? (ie, how likely)
> 2) does more than 2 messages in and of itself blow 
>    our time budget for (1) above?
> 
> Neither are especially clear at this point: the
> deployed base of RSVP -- such as it is -- isn't
> using RFC 2752 identities that I'm aware of, so
> that's no help. Or maybe it's instructive... take
> your pick. And (2) is highly dependent on the air
> interface and its characteristics. For current 3G
> cellular just about anything beyond a single
> command and response for *everything* is likely to
> blow your time budget, and 802.11 while better
> isn't dramatically better. 
> 
> Which is to say, that it's not entirely clear that
> for, oh say, VoIP with current radio technologies
> intersected with access control requirements that
> this is going to work well enough during handoffs
> in the naive break-before-make handoff that's an
> unfortunate necessity. I'm sure somebody will find
> this debatable, but that's not really my point
> here.
> 
> So, I'm not sure where I'm going with this except
> to try to ground these discussions into some sort
> of reality check of what we're trying to
> accomplish here. In my particular example,
> depending on how you tweak the parameters,
> connectionless establishment may be a large win,
> or it may be a non-starter. Also: if you believe
> that X.509 or other large byte identities are
> going to see widespread deployment for access
> control for wireless, then it's pretty much a
> given that we're going to need to deal with
> transport fragmentation in a sensible (read:
> non-L3) way. That in turn informs the debate
> whether fragmentation based on a non-threeway
> handshake protocol (tcp/sctp) is useful (or
> possible, some might argue). 
> 
> Finally, finesse is required here. It's easy to
> say that x.509 identities are required therefore
> fragmentation trumps all. That way lies insanity,
> IMO. We have to be careful to not overengineer
> solutions for marginal problems. The track record
> of PKI deployment is not good, so it's probably
> wise to consider the case where it is not part of
> the solution and provide optimization around that
> design criteria.
> 
> Which is why I'm muddled about this.
> 
> 	Mike
>

---

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

hi all,

anyone who wants to propose f/w text on the big picture regarding mobility
issues (or comment on the current text) is ***more*** than welcome.

FWIW, my suspicion on the rapid handoff issues that mike mentions is that
solutions will have to be based on state (and it doesn't matter if it is
hard or soft or set up using a connectionless or connection-oriented protocol)
being transferred within the network. This is not really a matter of message
sizes, simply that authentication/authorisation actions can't be done at
high enough speed within the network anyway. This means interacting somehow
with a CT protocol, section 5.2.5. (In fact, there was a more detailed discussion 
in the previous version.)

On the more general process point, my feeling is that at the moment we are 
not trying to set down the last word on what functionality is needed where,
just trying to work out the best direction to set off in as the protocol work
starts. I am pretty certain that some of the decisions we are making at the
moment are wrong or missing details, we just don't know in what way; however, 
we need a starting point which isn't too influenced by solving only the immediate 
problems.

Actually, the fragmentation issue doesn't seem like a particularly
hard one, in that:
*) we know there are good uses for certificates in authentication - and, more
importantly authorisation - which are the hardest part of the NSIS problem
space at the system level. We should do what we can to make these easy.
*) the non-use of 2752 (or indeed 3182) doesn't tell us very much - maybe it
isn't used because it makes messages too big...
*) fragmentation/reassembly is not rocket science, and fragmentation IMHO is
not a likely cause of processing overload
*) there seems to be an obvious place to do it

i'll try to send a summary of what i perceive as the current state of the 
argument shortly.

cheers,

robert h.

> From: [email-masked] [mailto:[email-masked]]
> Sent: 12 June 2003 05:07
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]