From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Mon Jun 30 2003 - 23:13:30 GMT-3
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.
>
> > >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.
>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.
> > >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.
>
>>
>> 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.
> > >
>> >>
>> >> >
>> >> >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.
> > >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.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:15 GMT-3