Subject: [NSIS] framework: proposal on fragmentation

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 5 Jun 2003 13:56:47 +0200

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

> 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

---

From: "Lars.Westberg" <[email-masked]>
Date: Thu, 05 Jun 2003 14:17:38 +0200

Hi!
That may be a good default behaviour. However, I think it is neccessary to support the third method as well.
I think that can be controlled  by an simple primitive to the NTLP-layer.

Regards Lasse

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Jun 2003 09:41:38 -0400

I'd really like to see optional (probably optional-to- use,
mandatory-to-implement) support for fragmentation, and I
think it's pretty clear that the only reasonable place to
put it is in the NTLP.  I don't think it's healthy to be
inflexible about layer separation but this is a case in
which it would be a lot messier to do it anywhere but in the
NTLP, because it's the NTLP that "knows" what the actual
packet sizes are.  (Note also that relying on IP layer
fragmentation can cause NAT failures).  I'm very much in
agreement.

Melinda

---

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

Hi Melinda

I agree with your proposal! Actually this is also what I meant in my
previous e-mails, i.e.,  optional use of fragmentation at the NTLP layer!

Best regards,
Georgios

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Jun 2003 10:54:14 -0400

> previous e-mails, i.e.,  optional use of fragmentation at the NTLP layer!

Not to be fickle, but in reading the recent traffic on the
mailing list I now agree that I don't see what's achieved by
having fragmentation be optional.  We're probably at the
point where the argument would benefit from specifics.  I
can't think of a circumstance in which you'd want to turn it
off, myself.  At any rate it seems to me that the discussion
of what happens when you've got a packet that's too small to
require fragmentation is probably less interesting right now
than the question of what would happen if you've got a
packet that's large and requires fragmentation.

Melinda