Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion

From: "Daniel Warren" <[email-masked]>
Date: Wed, 18 Jun 2003 09:49:01 +0100

I was midway through drafting an almost identical mail.  NTLP is a generic
part that spans all NSLP's so just 'turning off' fragmentation for one NSLP,
does not mean the functionality required to fragment messages vanishes
altogether.  It is only functionally less complex for that one NSLP, but
makes NTLP algorithmically more complex at least because a 'does this NSLP
want fragmentation?' check has to be included (among other things).  Then
for the case where the response is Yes, all of the fragmentation
functionality in the NTLP still has to be present.  But for the case where
the answer is 'No', then either PMTU reporting is required so that the NSLP
canensure that it's message fits in the pipes its going down, or there is a
need for a lot more error handling when the PMTU is exceeded.

Not surprisingly, I still support option 2, and I'd refer you back to my
last mail for my rationale about why the 'flag' would be redundant anyway.

Dan

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: 18 June 2003 09:39
To: 'Georgios Karagiannis'; [email-masked]
Subject: RE: [NSIS] yet another attempted summary of fragmentation
discuss ion

georgios,

(4) is more complex than (2) because
*) both need fragmentation capability in the NTLP
*) only (4) needs MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the NSLP
*) only (4) needs setting/processing of a 'DF' bit

(4) is more complex than (3) because
*) both need fragmentation capability in the NSLP
*) both need MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the NTLP
*) only (4) needs setting/processing of a 'DF' bit

it may be that what I understand by (4) is not the same as what you 
are proposing; I'm afraid that can only be fixed by you actually 
defining what you are proposing in a form which other people
can understand and evaluate. however, a pre-emptive point:

if you are proposing a solution which allows *some* NSLP (i.e. not
the one you are interested in, but someone else's) to generate a
message that would need NTLP fragmentation, then I believe that the
consequence is that *all* NTLP implementations will have to support
fragmentation to be compliant with the standard we write. this is
a general consequence of the "we don't design protocols for closed
environments" attitude (see also the 'I in IETF' comment a few emails
back). In other words, you can't just say 'well, the NSLP I care
about only produces small messages so I won't bother with fragmentation
at all'. 

Other people might like to comment on whether this assumption is
sensible.

cheers,

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: Wednesday, June 18, 2003 09:04
> To: Hancock, Robert; [email-masked]
> Subject: Re: [NSIS] yet another attempted summary of fragmentation
> discussion
> 
> 
> Hi Robert
> 
> I do not see how you came to the conclusion in
> (E) that option (4) is the most algorithmically functionally 
> complex of all
> the
> solutions for both layers.
> 
> If a NSLP chooses to use the NTLP fragmentation then the complexity is
> the same as (2) and if a NSLP does not need fragmentation then the
> complexity
> is actually reduced.
> 
> I am still in favour of option (4).
> 
> Best regards,
> Georgios
> 
> ----- Original Message -----
> From: "Hancock, Robert" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, June 18, 2003 12:32 AM
> Subject: [NSIS] yet another attempted summary of 
> fragmentation discussion
> 
> 
> > Dear all,
> >
> > Here is another attempt to summarise the fragmentation issues
> > (for those who are still following).
> >
> > We have basically the same 4 options on the table:
> > 1. Leave it up to the IP layer
> > 2. Do it only in the NTLP
> > 3. Do it only in the NSLP (NTLP provides information about how
> > big fragments are allowed to be)
> > 4. Combination of (2) and (3) - how a message is treated depends
> > on a flag in it (for example).
> >
> > Arguments basically revolve around on concerns about the complexity
> > and processing burden on the NTLP at nodes which wouldn't otherwise
> > have to worry about fragmentation.
> >
> > Some factoids (the most interesting/controversial ones only):
> > A) There are enough trivial/minor/annoying/insuperable concerns
> > about relying on IP level fragmentation to rule out (1).
> > B) For all the others, PMTU discovery has to be done at least
> > at the NTLP level. For (3) and (4) it has to be done at the
> > NSLP level as well (so there is some additional error handling
> > needed in the NTLP).
> > C) It's possible to implement the fragmentation so that reassembly
> > is only needed at the destination NSLP node (whichever layer it
> > actually takes place in). So, the processing cost we are 
> moving around
> > relates only to the fragmentation part.
> > D) I believe that the processing cost tradeoff between (2) and (3)
> > is just as likely to favour (2) as (3) so far as the 'vulnerable'
> > NTLP node is concerned, and favours (2) for the other nodes on the
> > path (see separate emails), especially when interactions 
> with bundling
> > are taken into account. I certainly don't believe the 'fragmentation
> > is obviously expensive' argument.
> > E) (4) is the most algorithmically functionally complex of all the
> > solutions for both layers.
> > F) Fragmentation itself as functionality is not complex (it takes
> > about 5 pages to describe the BSD code for IP in its full glory in
> > Stevens).
> > G) Fragmentation amplifies message loss rates. If you think that
> > message loss is a problem, then fragmentation makes it a 
> bigger problem;
> > however, if you think that message loss is a problem, you probably
> > believe in some kind of recovery (retransmission), which solves
> > the problem anyway.
> >
> > As might come across, I'm still a fan of (2) as a resolution of the
> > argument; I certainly don't see many stones left un-turned in the
> > discussion so far.
> >
> > I'd like to move on to the next open issue (congestion and 
> flow control,
> > IMHO much more tricky and interesting). Any ideas on how to do that
> > sooner rather than later?
> >
> > cheers,
> >
> > 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: [email-masked]
Date: Wed, 18 Jun 2003 09:49:17 +0100

your assumption seems perfectly sensible to me, otherwise you are not
building 2 protocols at all.

btw (4) seems the most complex to me

Lou 

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: 18 June 2003 09:39
To: 'Georgios Karagiannis'; [email-masked]
Subject: RE: [NSIS] yet another attempted summary of fragmentation
discussion

georgios,

cheers,

r.

---

From: [email-masked]
Date: Wed, 18 Jun 2003 10:52:25 +0200

Robert,

Your assumption that the protocols should not be designed
for closed environment -or one particular NSLP- seems very
sensible to me.
Option 2 is my preference as well for reasons already detailed
by you in previous mails.

regards,
Maarten

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

Sent by:    [email-masked]

To:    "'Georgios Karagiannis'" <[email-masked]>, [email-masked]
cc:
Subject:    RE: [NSIS] yet another attempted summary of fragmentation
       discuss    ion

georgios,

cheers,

r.

---

From: "Avella, Alejandro" <[email-masked]>
Date: Wed, 18 Jun 2003 09:34:46 -0600

Hi John,

Not sure if the RFCs below may be of use to this fragmentation discussion...

>I believe that
>there are a number of mechanisms available, and would note that there
>are a number of mechanisms for doing PMTU discover (for example, see 
>the end of message).

McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
http://www.ietf.org/rfc/rfc1981.txt?number=1981

Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
http://www.ietf.org/rfc/rfc1191.txt?number=1191

Alejandro Avella

======================================================

A new IETF working group has been proposed in the Transport Area.
The IESG has not made any determination as yet. The following description
was submitted, ans is provided for informational purposes only:

 Path Maximum Transmission Unit Discovery (pmutd)
 ------------------------------------------------

 Current Status: Proposed Working Group

 Chair(s):

 Matt Mathis <[email-masked]>
 TBD

 Transport Area Directors(s):

 Allison Mankin <[email-masked]>
 Jon Peterson <[email-masked]>

 Transport Area Advisor:

 Allison Mankin <[email-masked]>

 Mailing List (temporary):

 General Discussion: [email-masked]
 Subscribe: [email-masked] with "subscribe mtu" in the body
 Archive: http://www.psc.edu/~mathis/MTU/mbox.txt

 (This is to be moved to the IETF as soon as chartered).

 Description of Working Group:

 The goal of the PMTUD working group is to specify a robust method for
 determining the IP Maximum Transmission Unit supported over an
 end-to-end path. This new method is expected to update most uses of
 RFC1191 and RFC1981, the current standards track protocols for this
 purpose. Various weakness in the current methods are documented in
 RFC2923, and have proven to be a chronic impediment to the deployment
 of new technologies that alter the path MTU, such as tunnels and new
 types of link layers.

 The proposed new method does not rely on ICMP or other messages from
 the network. It finds the proper MTU by starting a connection using
 relatively small packets (e.g. TCP segments) and searching upwards by
 probing with progressively larger test packets (containing application
 data). If a probe packet is successfully delivered, then the path MTU
 is raised. The isolated loss of a probe packet (with or without an
 ICMP can't fragment message) is treated as an indication of a MTU
 limit, and not a congestion indicator.
 
 The working group will specify the method for use in TCP, SCTP, and
 will outline what is necessary to support the method in transports
 such as DCCP. It will particularly describe the precise conditions
 under which lost packets are not treated as congestion indications.
 The work will pay particular attention to details that affect
 robustness and security.

 Path MTU discovery has the potential to interact with many other parts
 of the Internet, including all link, transport, encapsulation and
 tunnel protocols. Thereforethis working group will particularly
 encourage input from a wide cross section of the IETF to help to
 maximize the robustness of path MTU discovery in the presence of
 pathological behaviors from other components.

*************************************************************************
This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is 
confidential or legally privileged.  If you are not the intended 
recipient, or a person responsible for delivering it to the 
intended recipient, you are hereby notified that you must not 
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or 
attached to this transmission is strictly prohibited.  If you have 
received this transmission in error, please immediately notify the 
sender by telephone or return e-mail and delete the original 
transmission and its attachments without reading or saving them 
in any manner.  Thank you.
*************************************************************************

---

From: "Attila Bader (ETH)" <[email-masked]>
Date: Thu, 19 Jun 2003 10:43:17 +0200

Hi John and Robert,

Yes you are right, I was thinking in advance. 

So I think framework should contain that fragmentation is done in NTLP but NSLP is able to prevent NTLP to do fragmentation.

Regards, Attila

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, June 18, 2003 4:59 PM
> To: [email-masked]; [email-masked]
> Hi Attila,
> > I agree that NTLP has to have responsibility for 
> > fragmentation generally. However, the cost of 'do not 
> > fragment' is 1 bit, which makes it possible that an NSLP that 
> > do not want fragmentation in underlying layers get an error 
> > message and do fragmentation itself or do something else to 
> > solve the problem. I would not exclude this option, so I 
> > propose to include DF bit.
> 
> A short note - I think that the DF bit is out of scope of the 
> Framework draft - it is a solution ...
> 
> John
>

---

From: "Attila Bader (ETH)" <[email-masked]>
Date: Mon, 23 Jun 2003 11:31:17 +0200

Hi Bob,

Sorry for stretching this thread further, I try to be short:

The difference between the two approaches is how to handle error. Let's assume that fragmentation/reassembly (not only in local node) causes false operation for an NSLP (because of timing or other reasons). For this NSLP, to discover that a message was/will be fragmented is complex, or even worse, NSLP may not be aware that fragmentation/reassembly occurred. On the other hand, if NTLP had to send larger message than MTU and it could not be fragmented it is a clear situation.

I think, if NSLP wants to avoid fragmentation/reassembly, it should be possible to ask such a service from NTLP. It is another question what to do if this service can not be provided.

Best regards, Attila

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Bob
> Braden
> Sent: Thursday, June 19, 2003 9:25 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I don't get why an NSLP should be able to disable NTLP fragmentation.
> What happens if the NSLP did disable it?  A message that exceeds the
> local MTU must then be black-holed by the NTLP, since it cannot be
> fragmented (I believe there was a consensus against IP fragmentation.)
> That does not make sense.  If the NSLP want to avoid fragmentation, it
> must itself make sure it sends messages smaller than the local MTU.
> But if it does that, then any fragmentation mechanism in the 
> NTLP won't
> be invoked anyway, so there is no need to explicitly tell the NTLP not
> to fragment.
> 
> What am I missing?
> 
> Bob Braden
> 
> 
> 
>

---

From: Bob Braden <[email-masked]>
Date: Mon, 23 Jun 2003 11:01:35 -0700 (PDT)

Attila,

Your argument about fragmentation is supported by the analogy of the
Don't Fragment (DF) bit in the IP header.  The same argument I made for
NSIS could be applied to the DF bit [I did, and I was wrong... DF did
turn out to be useful in triggering an error signal.  I guess we don't
always learn from our mistakes.]

So I accept that there is an argument for a DF bit in the NSLP <-> NTLP
interface.

Bob Braden

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Jun 2003 00:24:22 +0100

dear all,

so, what do others think?

one point i would emphasise is that this would be a feature we add to the
NTLP
for the benefit of signalling applications that might want it; it doesn't
do anything to protect NTLP implementations from fragmentation load. 

at the moment I can't see a signalling application that would want this 
facility (which is primarily a performance optimisation), but on the other
hand we are supposed to be designing for the future.

the one circumstance where i could see this facility being useful would be
where a signalling application needed to transfer gigantic amounts of data
between peers (an authorisation object containing a video clip?) and wanted
to discover the best size to which to segment its own data. but then i think
we'd be better to define a mandatory-to-implement signalling MTU discovery 
NSLP which would return the answer in one go, rather than some trial and 
error mechanism.

r.

PS. while the IP experience may be relevant, i don't see that the
conclusions
have to be the same. after all, one of the main points of DF in IP is to
allow TCP streams to segment their data optimally, since TCP is far better
at
reassembly than IP is. if the NTLP is that bad at reassembling fragments -
essentially through unreliability - then we should probably change
something.

why else is DF used?

> From: Bob Braden [mailto:[email-masked]]
> Sent: Monday, June 23, 2003 19:02
> To: [email-masked]
> Cc: [email-masked]

---

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

Hi Bob,

I appreciate your experience. 

In my mind there is a light-weight application which is sensitive to timing, e.g. using sliding window method for better performace, using stateless interior nodes for scalability. It may not allow for an intermediate node to wait for fragments. If the application sends small messages and it may never be fragmented in practice and may never cause problem.

I agree with John that this discussion should be continued in design phase. What I would like to achieve is that we should not close the window for this kind of applications.

Best regards, Attila

> Sent: Monday, June 23, 2003 8:02 PM