RE: reaction on ICMP 3 4

From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 30 2003 - 21:11:23 GMT-3


> -----Original Message-----
> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> Sent: Monday, June 30, 2003 7:10 PM
> To: ccielab@groupstudy.com
> Subject: RE: reaction on ICMP 3 4
>
>
> At 6:14 PM -0400 6/30/03, Volkov, Dmitry (IDS Canada) wrote:
> > > I'm not clear where you are going. First, fragmentation
> puts lots of
> >> burden on the router, primarily processor but also
> memory, and also
> >> (depending on platform) on the forwarding path.
> >>
> >> The router should never change DF. It should respond
> with ICMP when
> >> there is a violation.
> >
> >Hmm, Maybe I missed something but as I said hosts send
> UDP/ICMP witth DF=0
> >(I look via Sniffer and don't see opposite)
> >("may fragment") It's why router in the middle doesn't
> respond with ICMP if
> >packet "too big" but is doing
> >defrag itself. It's why I changed DF bit on router to
> activate ICMP back and
> >to avoid defrag on routers
> >However host after it received icmp changed size properly but sending
> >fragments
> >
> >However everything is fine with TCP (host sending DF=1)
> >and PMTUD mechanism works fine
> >
> >> If the host is implemented reasonably, when it gets a
> fragmentation
> >> failed, it should auto-adjust the MTU, perhaps a couple of times
> >> until it stops getting ICMP 3 4. No burden on the router
> besides a
> >> few ICMPs.
> >
> >Host, for UDP traffic, changes MTU properly but sending fragmets.
> >No burden on routers but I don't understand why host
> fragments every paket
> >assuming I send 1500 bytes
> >into 2 fragments and continues to send it.
>
>
> Let me be clear. Your host MTU is 1500. It receives an ICMP 3/4. You
> are saying it generates true IP fragments, with the ID, offset, total
> length, etc. fields properly set to create two segments of
> approximately 700? bytes each?

Almost right, but not 700+700 but :

Host configured with 1460 bytes IP MTU (Standard Windows TCP/IP Stack)
Initialy sending 1488 bytes UDP , after receiving ICMP asking to use 1476
(because GRE tunnel ahead) 1476 bytes IP pack + 46 bytes IP pack (12 bytes
of previous payload + padding)
Both packets are fragments of one.
I attached small sniffer CAP fiile.
Maybe it's packet generator issue.

More interesting that real UDP (not from packet generator)
are always sending with DF = 0 hence no PMTUD for UDP !

>
> Without checking the Host Requirements RFC, I don't think this is
> required or even advisable behavior.
>
> >Actually I used Lan traffic generator www.zti-telecom.com -
> to generate TCP
> >and UDP traffic
> >I'm wondring maybe here is the reason of such "strange"
> behavior. Anyway I
> >sniffed different
> >real UDP traffic and DF was always 0.
> >
> >>
> >> >
> >> >I don't know if RFC exists explaining that or it's just
> >> vendor specific.
> >> >I'm wondering if it's normal behavior. I'm looking for conceptual
> >> >explanation.
> >> >
> >> >Probably because UDP/ICMP packets are "always" (i tested
> >> with windows only)
> >> >transmitted with "may fragment" - there is no reason for
> >> host to participate
> >> >in PMTU for udp/icmp traffic ?
> >>
> >> It's more fundamental than that. Every UDP transmission
> is a separate
> >> event and should not depend on previous state in the
> host. Knowing
> >> that you received ICMP 3 4 is previous state.
> >
> >Well, but TCP MSS is "negotiated" only within SYN, SYN-ACK packets
> >lowest is winner. I think PMTU mechanism doesn't care about
> stateful nature
> >of traffic.
> >UDP has characteristic of flow (source/destin IP, ports) -
> it's pretty
> >predictable as well.
>
> "Predictable" is very different than "stateful". TCP maintains
> considerable real-time information on every flow -- window sizes, ack
> timers, credits, etc. UDP remembers nothing about the previous
> packet in a flow or the state of the flow.
>
> >So why it wouldn't work, regarding PMTUD, as TCP does. Why
> packets have DF=0
> >?
> >eliminating PMTUD from the scope.
>
> Increasingly, I'm thinking you have a very strange host.

Two normal W2K PCs.
Again UDP packets are sending with DF =0. What about your hosts ?
I believe it's normal to send UDP with DF =0. I don't understand - Why ?

>
> > > >
> > > >> >Is it host/vendor depended or RFC ?
> >> >>
> >> >> If you think about it, it's architectural. TCP is
> stateful. UDP is
> >> >> not. For UDP to consider a previous signal, that
> would mean it is
> >> >> retaining state.
> >> >
> >> >Well, UDP stateless but again why to send fragments ;)
> >>
> >> I don't understand. Host UDP is stateless. IP
> decision-to-fragment is
> >> also stateless.
> >>
> >> If the host application wanted to avoid fragmentation,
> its IP should
> >> do route discovery, or set a conservative MTU.
>
>
> ______________________________________________________________
> _________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

[GroupStudy removed an attachment of type application/octet-stream which had a name of df8-UDP sized down and FRAGMENTSsmall.cap]



This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:15 GMT-3