From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 30 2003 - 23:48:36 GMT-3
> -----Original Message-----
> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
> Sent: Monday, June 30, 2003 10:14 PM
> To: ccielab@groupstudy.com
> Subject: RE: reaction on ICMP 3 4
>
>
> At 8:11 PM -0400 6/30/03, Volkov, Dmitry (IDS Canada) wrote:
>
> I'm lost. Under normal circumstances, any host should send DF=0,
> regardless of the IP payload, on the theory that it's better to
> fragment than not communicate. An obvious exception is MTU path
> discovery, and there are some very special cases like Cisco Fast
> Sequenced Transport for RSRB.
RFC 1191:
"Normally, the host continues to set DF in all
datagrams, so that if the route changes and the new PMTU is lower, it
will be discovered."
And this is the case for TCP traffic. All packets are sending with DF=1.
(well I shouldn't say all - but so far I don't recall that I saw TCP with
"may fragment")
PMTDU happens between 2 hosts. Each new session to another host requires
new MTU discovery process.
So it's logically always to send DF =1 (for consistency ;).
TCP is doing like that.
> > > >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.
>
> If DF is off, the router is doing exactly what it is supposed to.
I don't think that it's router's task to do frags. End hosts should take
care about that.
In case of UDP traffic - routers in the middle are doing frags (because UDP
traffic has DF=0)
in case of TCP - hosts lower MTU size (because DF=1). Why does such
difference exist ?
> >It's why I changed DF bit on router to
> >> activate ICMP back and
> >> >to avoid defrag on routers
>
> Do you mean frag or defrag? A router should never defragment unless
> it is the destination.
Sorry, Frag of course.
>
> > > >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 !
>
> In a typical implementation, Path MTU Discovery should take place at
> IP interface initialization, not constantly. It should have already
> happened before the host tries to send any TCP _or_ UDP.
Yes. I agree. However it doesn't explain why UDP traffic is sending with
DF=0
Actually I don't quite understand what do You mean IP interface
"initialization"
PMTDU happens, only if You set DF=1, in the beginning of any new flow
(communication between two ip addresses)
UDP or TCP. Windows record it by putting host route to destination.
>
> >
> >>
> >> 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.
>
> So far, I'm still not seeing anything I'd call strange.
Well, differnet PMTUD behavior for UDP (routers frags because DF is always
0)
and TCP (hosts adjust MTU according to icmp) - This is strange for me. Why
here should be deference ?
>
> > > >
> >> >>
> >> >> >
> >> >> >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.
>
> Again, I don't think we are communicating. PMTUD should take place
> before any TCP.
PMTUD takes place within 6 first pakets for TCP (3 handshake, 4th packet
Big, icmp unreach, 5 packet
retransmitted 4th but lower size, 6th ACK from receiver) - This is how I
understand.
>
> > > >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 ?
>
> What do you see as the problem in sending DF=0? Seems perfectly
> reasonable to me.
Fragmentation happens on routers in case of havy UDP packets.
Each 1500 bytes UDP packet going through GRE is fragmented on router.
Maybe havy UDP is not happen so often...
>
> ______________________________________________________________
> _________
> 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
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:15 GMT-3