From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 30 2003 - 23:57:07 GMT-3
Again I would refer to the cisco:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00
800d6979.shtml#second
Note: PMTUD is only supported by TCP. UDP and other protocols do not support
it. If PMTUD is enabled on a host, and it almost always is, all TCP/IP
packets from the host will have the DF bit set.
So, conceptualy : Why UDP doesn't support it ?
> -----Original Message-----
> From: Volkov, Dmitry (IDS Canada) [mailto:dmitry_volkov@ca.ml.com]
> Sent: Monday, June 30, 2003 10:49 PM
> To: 'Howard C. Berkowitz'
> Cc: 'ccielab@groupstudy.com'
> Subject: RE: reaction on ICMP 3 4
>
>
> > -----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
>
>
> ______________________________________________________________
> _________
> 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